From jhildebr@cisco.com Mon Feb 18 12:01:23 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1830D21F8C86; Mon, 18 Feb 2013 12:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRqDlBztQ3IG; Mon, 18 Feb 2013 12:01:22 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 21E9421F8C84; Mon, 18 Feb 2013 12:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1004; q=dns/txt; s=iport; t=1361217676; x=1362427276; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=+8QzgxuCG7XPxuwv+GslP8WOuKbsW+QVuHuqrS7jd54=; b=HLTIdDA+CoDtbi4NQwO1e3KCsWCrmmoPrDODeCFK5DBfluIYoQLNgJyu mhhluZxqMhoznv2ceKna9dJ6ESH1QCIoYAS6fZJFGVgY1VZVWbjQh4mRP FRCwa3PgdyKI7Y6rsrL9cLczj0miId/UacVxbd6AS4UVS2TqJdYe9CKdy k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFABOIIlGtJXG+/2dsb2JhbABEhgK6IIEEFnOCIQEEAQEBNy0EAx0BKhQ3CycEARIIiAoMwQ6PBoMXYQOXSY87gweCJw X-IronPort-AV: E=Sophos;i="4.84,690,1355097600"; d="scan'208";a="178465579" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 18 Feb 2013 20:01:08 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1IK17YM024703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Feb 2013 20:01:07 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 14:01:07 -0600 From: "Joe Hildebrand (jhildebr)" To: "apps-discuss@ietf.org" , "json@ietf.org" Thread-Topic: JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3g== Date: Mon, 18 Feb 2013 20:01:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Json] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 20:01:23 -0000 We're planning on doing a BoF in Orlando to discuss starting up a JSON working group. The BoF is currently planned for Monday afternoon at 1300 in Carribean 6. A very preliminary version of a charter can be found here: http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON But obviously we'll need to build consensus on what it should actually contain. Please discuss on the json@ietf.org mailing list: https://www.ietf.org/mailman/listinfo/json As a start, we know there are a couple of things we'd like to fix about RFC 4627: - move to standards track - an ABNF indentation typo in section 2.2 - change SHOULD to MUST for the uniqueness of names in an object A *very* important goal would be to minimize change, and to ensure strict backward-compatibility. There are likely adjunct JSON topics that would make sense to tackle once we've got the experts together, but the goal would be to keep that list short, focused, and general-purpose. --=20 Joe Hildebrand From fgaliegue@gmail.com Mon Feb 18 13:02:33 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAD221F8688; Mon, 18 Feb 2013 13:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPDe10UsB9YX; Mon, 18 Feb 2013 13:02:33 -0800 (PST) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0896021F8CA2; Mon, 18 Feb 2013 13:02:22 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id a13so2698002eaa.35 for ; Mon, 18 Feb 2013 13:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0r2YvWqWOyJerBQtXZ0emtEwIxgSNei6/ON5VHv07Jw=; b=YJIJDmb1KH5bz4S0TkpkqxpHO9moB1Grpjmm4ZfNfMja1r6hegr/FK42Spnl6Jr+wb 5PtHtBYUiMMGY0mIt4hy/WEs8ChzoKJIRsACrh5RhPxploZ67sXIl6HQt0DAy1YfmWM6 8+t1xyeBxB6Cz2KFLUDc2LL0HicuxkKR7BFi/3XI0JHvZzlwOhjZxRGLDNkVBiq4ticS 0xJhHlcY7W7jAiEoQRzMj6AtWpRdclF2A70yYQ9V7rMEaaaS2S18lfCzU11ALET8xnAB lOf7TuvCHeqSCKKM45ynt8AgrJ8aLam4NpSLd6V7ePB6mpjfq+1i0IPg1NC6ylFcNfgY ytXw== MIME-Version: 1.0 X-Received: by 10.14.183.67 with SMTP id p43mr48602495eem.10.1361221342154; Mon, 18 Feb 2013 13:02:22 -0800 (PST) Received: by 10.14.1.7 with HTTP; Mon, 18 Feb 2013 13:02:21 -0800 (PST) In-Reply-To: References: Date: Mon, 18 Feb 2013 22:02:21 +0100 Message-ID: From: Francis Galiegue To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 21:02:33 -0000 Hello, On Mon, Feb 18, 2013 at 9:01 PM, Joe Hildebrand (jhildebr) wrote: > We're planning on doing a BoF in Orlando to discuss starting up a JSON > working group. The BoF is currently planned for Monday afternoon at 1300 > in Carribean 6. A very preliminary version of a charter can be found here: > > http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON > JSON Schema is missing from this page (it has been updated recently and is now three specifications). -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From cabo@tzi.org Mon Feb 18 13:35:32 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63E821F8C74; Mon, 18 Feb 2013 13:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.237 X-Spam-Level: X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPBONTWnHWbH; Mon, 18 Feb 2013 13:35:32 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E3A9B21F8C68; Mon, 18 Feb 2013 13:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r1ILZAhc017789; Mon, 18 Feb 2013 22:35:10 +0100 (CET) Received: from [192.168.217.105] (p548937E4.dip.t-dialin.net [84.137.55.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AD9873BB6; Mon, 18 Feb 2013 22:35:09 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 18 Feb 2013 22:35:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <338D1DA7-AEB4-4731-8BC0-B8D2602396F6@tzi.org> References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 21:35:32 -0000 On Feb 18, 2013, at 21:01, "Joe Hildebrand (jhildebr)" = wrote: > adjunct JSON topics One such topic might be roundtripping to/from some simple binary format = for JSON-structured values. draft-bormann-apparea-bpack-00.txt Gr=FC=DFe, Carsten From jhildebr@cisco.com Mon Feb 18 15:47:19 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3608B21E8094; Mon, 18 Feb 2013 15:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4QY5LkDOyFl; Mon, 18 Feb 2013 15:47:18 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D24C021E808F; Mon, 18 Feb 2013 15:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=532; q=dns/txt; s=iport; t=1361231235; x=1362440835; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SEi9fFDhnLwDNdg8A3WfntM7JU9VROXkRPCzBs/cVmc=; b=bjoRSuY+zuYShkbOsdw/8x3yLqUR0lRsmB684Jge87707GUb6zXhk9Rh meg3RyA6HNupmi7ul7UW+fIIPeyp0RRN4UsmOH3GncVRTJW7ZrqdVgVXl /4Mibnt3BTfU0vrXAMy6oKdfY5qgo4peZ/oyAk8Ra7J0XPkOd0e5Eq/4r A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAIq8IlGtJXG8/2dsb2JhbABEhgK6IoEFFnOCHwEBAQQ6NAsSAQgOCgoUQiUCBA4FCIgKwTuOfTEHY4F8YQOnBIJ6DYIn X-IronPort-AV: E=Sophos;i="4.84,691,1355097600"; d="scan'208";a="178466262" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 18 Feb 2013 23:47:13 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1INlDOi000667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Feb 2013 23:47:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 17:47:13 -0600 From: "Joe Hildebrand (jhildebr)" To: Carsten Bormann Thread-Topic: [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piAiBQA//+vjYA= Date: Mon, 18 Feb 2013 23:47:13 +0000 Message-ID: In-Reply-To: <338D1DA7-AEB4-4731-8BC0-B8D2602396F6@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 23:47:19 -0000 On 2/18/13 2:35 PM, "Carsten Bormann" wrote: >On Feb 18, 2013, at 21:01, "Joe Hildebrand (jhildebr)" > wrote: > >> adjunct JSON topics > >One such topic might be roundtripping to/from some simple binary format >for JSON-structured values. > >draft-bormann-apparea-bpack-00.txt As an individual, I'm +1 on that. I love msgpack, and don't mind the addition of UTF8 as a separate type. Was frsyuki involved in the draft, or at least know that it happened? --=20 Joe Hildebrand From jhildebr@cisco.com Mon Feb 18 15:52:29 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357AF21E8087; Mon, 18 Feb 2013 15:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dHQjGgR4UVs; Mon, 18 Feb 2013 15:52:28 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9A521F8D39; Mon, 18 Feb 2013 15:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=666; q=dns/txt; s=iport; t=1361231545; x=1362441145; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NFjddzjdNZf/54qUItK/GMPZ2PxAJg7Eu1G/juh59E8=; b=b4IWH4m0yPMAsdH/kB2mOJOeDfFfqQUSt7XcMrM5zt66wpL6mxU2bCzp hroiy5G7Eo9EqAKlgVXvGQA03bQhBp26oIGojm6PR/T4nAfHxme8GCtqD a9fdR/Eo31+rptmS9ELYHpZKHMUmv+tEhffMj6KjdffwtgtcR3W/w8U7S 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAJu9IlGtJXG+/2dsb2JhbABEhgK6IoEFFnOCIQEEOjQLEgEIDhQUMRElAgQOBQiHeAMPDLdJDYlajFCCLTEHY4F8YQOUUYJ4iiaFFYJ6DYIn X-IronPort-AV: E=Sophos;i="4.84,691,1355097600"; d="scan'208";a="178521988" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 18 Feb 2013 23:52:25 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1INqOTV018930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Feb 2013 23:52:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 17:52:24 -0600 From: "Joe Hildebrand (jhildebr)" To: Francis Galiegue Thread-Topic: [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piAfuyA//+6JQA= Date: Mon, 18 Feb 2013 23:52:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 23:52:29 -0000 On 2/18/13 2:02 PM, "Francis Galiegue" wrote: >>http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON > >JSON Schema is missing from this page (it has been updated recently >and is now three specifications). As an individual. I'd say that a way to unambiguously specify further standards that use JSON seems reasonable. Whether it's json-schema or json-content-rules, or something else seems like a fertile ground for discussion. I like Cyrus's argument that all we need is the ABNF of the JSON world, and that any attempt to get more complicated than that will likely lead us down the XSD rathole. --=20 Joe Hildebrand From fgaliegue@gmail.com Mon Feb 18 16:13:35 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D30321E8094; Mon, 18 Feb 2013 16:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9ZQdXlYEN3L; Mon, 18 Feb 2013 16:13:34 -0800 (PST) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBBF21E8051; Mon, 18 Feb 2013 16:13:34 -0800 (PST) Received: by mail-ea0-f182.google.com with SMTP id a12so2532395eaa.27 for ; Mon, 18 Feb 2013 16:13:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6cpnPVgFhd4i//EpE/2sC4Rv15kVPHoz7gX9qYLpndU=; b=Xy7S8JFVZBivQ9V+8n/wPwJaiqvfbla4mpQpEKFDrS7ZlbPhhvXuPDGhLQLHEaKE9i aTToa1oUD8hH77R4xe/19pqds1jOYsBBtzDDPDem/EvkW/47Dltan0pp7hMHoGXAGhQR p4yWdbIRZOUaQiupOh/b+kIy0HocrbGIrUEwpCjvV7f6MNYeEa5aHjXlQgPu//oGviK9 LWOc4T3S7Wviu+JH7ye91/p0VG+yVXWqszthTbaNsaCbyZth7EVstcRGnD9dAEV5C63i tQB4SP/wbw3Loi/37Rvopf8HRGjrCLKCWaGhBCbyFVXI8pkEj34NeiV7o66dJ9I+Oh5e 3e8w== MIME-Version: 1.0 X-Received: by 10.14.183.67 with SMTP id p43mr50201198eem.10.1361232811387; Mon, 18 Feb 2013 16:13:31 -0800 (PST) Received: by 10.14.1.7 with HTTP; Mon, 18 Feb 2013 16:13:31 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Feb 2013 01:13:31 +0100 Message-ID: From: Francis Galiegue To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 00:13:35 -0000 On Tue, Feb 19, 2013 at 12:52 AM, Joe Hildebrand (jhildebr) wrote: > On 2/18/13 2:02 PM, "Francis Galiegue" wrote: > >>>http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON >> >>JSON Schema is missing from this page (it has been updated recently >>and is now three specifications). > > As an individual. > > I'd say that a way to unambiguously specify further standards that use > JSON seems reasonable. Whether it's json-schema or json-content-rules, or > something else seems like a fertile ground for discussion. > > I like Cyrus's argument that all we need is the ABNF of the JSON world, > and that any attempt to get more complicated than that will likely lead us > down the XSD rathole. > Well, I'd like to hear the reasoning behind this argument ;) I have really struggled to make this specification useful, and witnessing the users of my library alone, it looks like the pure validation part of JSON Schema already has quite a few users... I also make the best efforts not to repeat XSD's mistakes, and right now JSON Schema is young enough that it cannot have made such mistakes (I _think_). But in order not to repeat such mistakes, advice from external people is of course needed. Which is why reviews are always welcome! -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From jhildebr@cisco.com Mon Feb 18 17:07:38 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B663A21E8063; Mon, 18 Feb 2013 17:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8pb5SJy13hb; Mon, 18 Feb 2013 17:07:38 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 27BC321E8044; Mon, 18 Feb 2013 17:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1160; q=dns/txt; s=iport; t=1361236058; x=1362445658; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0Ydq1sRzavbAoylHxitDzc666BHZbUMPpfAW+bX6b+k=; b=R8stN0XRA3kTzytfWM2BnMvTezEF2BlIG0WDR2zXRHwHTEKFrHsSh/eF 1M229qR4sVSijbIRdTBhVWToeoW5WcLcxL4+JT0cTEmZ0Cm4LORG4TQkN 7HvflvylNUYEslM/oTEY1ARwdHX3tBHDHPoEe0NqpzNMHZjw4L35QTqSN s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANTPIlGtJXG+/2dsb2JhbABEwCmBBRZzgh8BAQEDATo0CwUNAQgOFBQxESUCBA4FCId4AwkGsUCGDw2JWoxQgi0xB4JfYQOSbYFkjR6FFYMHgWskGA X-IronPort-AV: E=Sophos;i="4.84,692,1355097600"; d="scan'208";a="178504137" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 19 Feb 2013 01:07:37 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1J17bI8031648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 01:07:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 19:07:37 -0600 From: "Joe Hildebrand (jhildebr)" To: Francis Galiegue Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piAfuyA//+6JQCAAHtEgP//mcEA Date: Tue, 19 Feb 2013 01:07:36 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 01:07:38 -0000 On 2/18/13 5:13 PM, "Francis Galiegue" wrote: >I have really struggled to make this specification useful, and >witnessing the users of my library alone, it looks like the pure >validation part of JSON Schema already has quite a few users... > >I also make the best efforts not to repeat XSD's mistakes, and right >now JSON Schema is young enough that it cannot have made such mistakes >(I _think_). But in order not to repeat such mistakes, advice from >external people is of course needed. Oh! Sorry, I didn't mean to imply that I didn't like json-schema, just that there are several different approaches that have been proposed, and it makes sense to have a conversation about what our requirements are and if we think we're meeting them with one of those proposals. Charter-wise, setting the requirement to be "as simple as possible, but no simpler" is probably something we can all agree on; agreeing on what constitutes "simple" is likely to be more complex. :) > Which is why reviews are always welcome! I certainly need to review the latest versions before having an opinion. --=20 Joe Hildebrand From jhildebr@cisco.com Mon Feb 18 17:12:32 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AA621E8063 for ; Mon, 18 Feb 2013 17:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Vve90y2mqRw for ; Mon, 18 Feb 2013 17:12:31 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id CE60A21E8044 for ; Mon, 18 Feb 2013 17:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1393; q=dns/txt; s=iport; t=1361236352; x=1362445952; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=QJGCay99J4uNkWk/dlVpvVt+SPBrxWBpSsful4txjps=; b=FAnZhSqLf3ugwIFv56gGxLozP6ohFpHPVBRglw6XRqCjOZH0xka8FsyR et2+KnuTD8nrViefnCuQaADvnOuWZxll1wleHkn/urhIxnXIkNJ1ezLln 9jniVcfiDcWL0ns8PGxVRyOjIXnhg3YKQHwfgo9jY64Kdr2DOOP++c8O8 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8WAGfQIlGtJV2b/2dsb2JhbABEoEGfaIEFFnOCHwEBAQQ6NAsSAQgOCgoUQiUCBA4FCId4Aw+xP492jFCCLTEHgl9hA6cEgweCJw X-IronPort-AV: E=Sophos;i="4.84,692,1355097600"; d="scan'208";a="175512556" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 19 Feb 2013 01:12:31 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1J1CVZe010680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 01:12:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 19:12:31 -0600 From: "Joe Hildebrand (jhildebr)" To: Bjoern Hoehrmann Thread-Topic: [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piAt/6A//+XeIA= Date: Tue, 19 Feb 2013 01:12:30 +0000 Message-ID: In-Reply-To: <1ah5i81al3ug4qgmgjqgjnl5evf6jc1qnq@hive.bjoern.hoehrmann.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 01:12:33 -0000 On 2/18/13 5:26 PM, "Bjoern Hoehrmann" wrote: >* Joe Hildebrand (jhildebr) wrote: >>A *very* important goal would be to minimize change, and to ensure strict >>backward-compatibility. > >A Working Group will also likely have to look at revising the rules to >detect the character encoding in application/json resources (there is a >lack of consensus whether to auto-detect UTF-32 and whether to honour a >Unicode signature, whether to support UTF-32 when it is detected, and so >on, partly due to how people load JSON resources; a generic "load text" >API for instance might detect and remove a Unicode signature before the >data is passed to a JSON parser; this used to be true for XMLHttpRequest >for instance, I haven't checked the current situation there though). (individual) Yeah, that probably needs to be dealt with. If 4627 had been written as "JSON SHALL always be encoded as UTF-8 when transmitted or stored", then this would not be a problem. I wonder if it's too late for that? If we said that the backward-compatibility rule was that any document that was valid 4627bis would be correctly parsed by a 4627 parser, going all-in on UTF-8 would be ok. Since this is currently valid and proposed to no longer be valid: {"foo": "bar", "foo": "baz"} clearly the reverse is not going to be true anyway. --=20 Joe Hildebrand From fgaliegue@gmail.com Mon Feb 18 17:15:16 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5A121E8053; Mon, 18 Feb 2013 17:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmFcGqIZ-YXG; Mon, 18 Feb 2013 17:15:16 -0800 (PST) Received: from mail-ea0-f171.google.com (mail-ea0-f171.google.com [209.85.215.171]) by ietfa.amsl.com (Postfix) with ESMTP id C646021E8044; Mon, 18 Feb 2013 17:15:15 -0800 (PST) Received: by mail-ea0-f171.google.com with SMTP id c13so2547101eaa.30 for ; Mon, 18 Feb 2013 17:15:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=R7I2vmOLFVliJAyFE4XM5zSP8/0Tqha4+mVIivB2+UQ=; b=gHYJeMoO1A0utRhUTleOUrEvywikxfjgE03/nFRbQX3hvDPSux/XyiIU+Pd59ovo2U NTIlSKqqyIOgwFv5fVcYnSwc0gMt4vQcAUr3Z4P9D1LvggMueGZUR+bfASjaYeanXIsg BfoyIG9zuO6anm0SJt8cmpygXNEpI77ZP5bixp+mUD4wYdeZqLExutfOsek1N9qurWrl 4R0vZjWYCNmWTgq+I7ZJ7TcyLTljvOkNsHRfPD7HTJZ7a/EKallJobem2Lua+FScePBx 1EnyHgCctEAWrCiH9nKhb/9xlgPDLfTy9bZFme8qkSIO6TiRbc/Ja15JYvtzduVa2sg1 RDPQ== MIME-Version: 1.0 X-Received: by 10.14.183.67 with SMTP id p43mr50721333eem.10.1361236514813; Mon, 18 Feb 2013 17:15:14 -0800 (PST) Received: by 10.14.1.7 with HTTP; Mon, 18 Feb 2013 17:15:14 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Feb 2013 02:15:14 +0100 Message-ID: From: Francis Galiegue To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 01:15:17 -0000 On Tue, Feb 19, 2013 at 2:07 AM, Joe Hildebrand (jhildebr) wrote: [...] > > Oh! Sorry, I didn't mean to imply that I didn't like json-schema, just > that there are several different approaches that have been proposed, and > it makes sense to have a conversation about what our requirements are and > if we think we're meeting them with one of those proposals. > I'd certainly like to have a digest of this discussion! I have my own needs, and even my own implementation, so I cannot be partial here -- just be a witness on my use case. > Charter-wise, setting the requirement to be "as simple as possible, but no > simpler" is probably something we can all agree on; agreeing on what > constitutes "simple" is likely to be more complex. :) > >> Which is why reviews are always welcome! > > I certainly need to review the latest versions before having an opinion. > Looking forward to this! Have fun, -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From derhoermi@gmx.net Mon Feb 18 17:41:18 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A3F21E805A for ; Mon, 18 Feb 2013 17:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wpe0oWwtHBhL for ; Mon, 18 Feb 2013 17:41:18 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id E014821E8044 for ; Mon, 18 Feb 2013 17:41:17 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MDjlo-1U5ypW2nZG-00H9Fv for ; Tue, 19 Feb 2013 02:41:16 +0100 Received: (qmail invoked by alias); 19 Feb 2013 01:41:16 -0000 Received: from p54B4E14B.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [84.180.225.75] by mail.gmx.net (mp031) with SMTP; 19 Feb 2013 02:41:16 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+/yAxCSxq/MM/uYYMoFEz4TFciDEK6m5Fe6eLrOk 2Hk65OWDsqiLvw From: Bjoern Hoehrmann To: "Joe Hildebrand (jhildebr)" Date: Tue, 19 Feb 2013 02:41:17 +0100 Message-ID: <78l5i81cpnbq0f21p1vvdia496err839vi@hive.bjoern.hoehrmann.de> References: <1ah5i81al3ug4qgmgjqgjnl5evf6jc1qnq@hive.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 01:41:19 -0000 * Joe Hildebrand (jhildebr) wrote: >On 2/18/13 5:26 PM, "Bjoern Hoehrmann" wrote: >>A Working Group will also likely have to look at revising the rules to >>detect the character encoding in application/json resources (there is a >>lack of consensus whether to auto-detect UTF-32 and whether to honour a >>Unicode signature, whether to support UTF-32 when it is detected, and so >>on, partly due to how people load JSON resources; a generic "load text" >>API for instance might detect and remove a Unicode signature before the >>data is passed to a JSON parser; this used to be true for XMLHttpRequest >>for instance, I haven't checked the current situation there though). > >(individual) > >Yeah, that probably needs to be dealt with. If 4627 had been written as >"JSON SHALL always be encoded as UTF-8 when transmitted or stored", then >this would not be a problem. A practical problem is that some people include a Unicode Signature in their JSON documents, and their code works in some environments either by accident or because someone made a deliberate choice to support the Unicode Signature even though the RFC does not permit one, but it would break in more strict implementations. I would expect the Working Group to investigate whether the "UTF-8 BOM" should be allowed and how JSON documents with one should be handled, even if it decides to limit JSON to UTF-8. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From stpeter@stpeter.im Mon Feb 18 17:44:36 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CAE21F8B63 for ; Mon, 18 Feb 2013 17:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpPwRNT7a6UJ for ; Mon, 18 Feb 2013 17:44:34 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D67EA21F8B36 for ; Mon, 18 Feb 2013 17:44:34 -0800 (PST) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4B81B403CD; Mon, 18 Feb 2013 18:51:57 -0700 (MST) Message-ID: <5122D904.4020308@stpeter.im> Date: Mon, 18 Feb 2013 18:44:36 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <1ah5i81al3ug4qgmgjqgjnl5evf6jc1qnq@hive.bjoern.hoehrmann.de> <78l5i81cpnbq0f21p1vvdia496err839vi@hive.bjoern.hoehrmann.de> In-Reply-To: <78l5i81cpnbq0f21p1vvdia496err839vi@hive.bjoern.hoehrmann.de> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 01:44:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/18/13 6:41 PM, Bjoern Hoehrmann wrote: > * Joe Hildebrand (jhildebr) wrote: >> On 2/18/13 5:26 PM, "Bjoern Hoehrmann" >> wrote: >>> A Working Group will also likely have to look at revising the >>> rules to detect the character encoding in application/json >>> resources (there is a lack of consensus whether to auto-detect >>> UTF-32 and whether to honour a Unicode signature, whether to >>> support UTF-32 when it is detected, and so on, partly due to >>> how people load JSON resources; a generic "load text" API for >>> instance might detect and remove a Unicode signature before >>> the data is passed to a JSON parser; this used to be true for >>> XMLHttpRequest for instance, I haven't checked the current >>> situation there though). >> >> (individual) >> >> Yeah, that probably needs to be dealt with. If 4627 had been >> written as "JSON SHALL always be encoded as UTF-8 when >> transmitted or stored", then this would not be a problem. > > A practical problem is that some people include a Unicode Signature > in their JSON documents, and their code works in some environments > either by accident or because someone made a deliberate choice to > support the Unicode Signature even though the RFC does not permit > one, but it would break in more strict implementations. I would > expect the Working Group to investigate whether the "UTF-8 BOM" > should be allowed and how JSON documents with one should be > handled, even if it decides to limit JSON to UTF-8. Yeah, limiting things to UTF-8 these days would be a good thing. But, as Bjoern notes, we might want to have a section about interoperability with existing implementations. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRItkDAAoJEOoGpJErxa2pwXAP/1qdfzmrRxcGhbflPtpQCb9X iUdSUcj4OZFBulTahfLDy7jfuPtk+NUJ/3f6sxu/rmIKI+jJ9179wJdcEWXz4iou BuouOwB7J/YKAGXMHYv9g/ocdJJkWf+ERkPaM1mb+7Ew46qZct0pE1dw+OCfv59G Ojr+F5dUpxkfP7BDnNvu7PUrVF5MJTaQRHbKkWqXz+RXjQYK7kir5JRdXujZAYwQ p4hdKpgrCNhqYYrDklzxxS7weUnH9GN5SFpn4j/iCgWuT1XfpCaTGcG63gLatazR SM84zaMfSQ8+N236di2rNVJTCWnsEwSTp9dJ8rQjvZdLgANfz/l9V/lxKMpPYWtn Id7RrCr8HT5e/KVPEhTtZ8uzH5r8oohh5pBcJDANjnXBLZGDRvhFlvA3z2LYAfjw ushyG/D7jAMrKJzJRnYC/NWV5XkIyxfA8y3dSEUq/lHM0dK3xje8oirHy5kFFzKR noJdBkEBQb0X6l129Munb8vU2+tlHS6mpfb60ftK3MCwm+klX2lbtbHQHs1Yw79d w3q4IFZQuWb/iQn0jB9NqLrYlz4eE3ATrw9Mz6EhkL0IGA0+xKBt04M5crvfjfp0 7ayxsvecYoBnMm2G3RHuD7ceHNgJWx7cwjoFCC6lDD5WB1pl8os1HjrDcBTQmynl ucOo5ja5+BquWGYSMcc3 =+WRL -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Mon Feb 18 18:03:01 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAA921E805E for ; Mon, 18 Feb 2013 18:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYR9RBien7ZG for ; Mon, 18 Feb 2013 18:03:01 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0F021E8053 for ; Mon, 18 Feb 2013 18:03:01 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1J22xHg008210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 18 Feb 2013 19:03:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Mon, 18 Feb 2013 18:02:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: json@ietf.org X-Mailer: Apple Mail (2.1499) Subject: [Json] Upgrading SHOULD to MUST X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 02:03:01 -0000 On Feb 18, 2013, at 5:12 PM, Joe Hildebrand (jhildebr) = wrote: > On 2/18/13 5:26 PM, "Bjoern Hoehrmann" wrote: >=20 >> * Joe Hildebrand (jhildebr) wrote: >>> A *very* important goal would be to minimize change, and to ensure = strict >>> backward-compatibility. >>=20 >> A Working Group will also likely have to look at revising the rules = to >> detect the character encoding in application/json resources (there is = a >> lack of consensus whether to auto-detect UTF-32 and whether to honour = a >> Unicode signature, whether to support UTF-32 when it is detected, and = so >> on, partly due to how people load JSON resources; a generic "load = text" >> API for instance might detect and remove a Unicode signature before = the >> data is passed to a JSON parser; this used to be true for = XMLHttpRequest >> for instance, I haven't checked the current situation there though). >=20 > (individual) >=20 > Yeah, that probably needs to be dealt with. If 4627 had been written = as > "JSON SHALL always be encoded as UTF-8 when transmitted or stored", = then > this would not be a problem. >=20 > I wonder if it's too late for that? =20 > If we said that the > backward-compatibility rule was that any document that was valid = 4627bis > would be correctly parsed by a 4627 parser, going all-in on UTF-8 = would be > ok. Since this is currently valid and proposed to no longer be valid: >=20 > {"foo": "bar", "foo": "baz"} >=20 > clearly the reverse is not going to be true anyway. If we are supposed to be keeping backwards compatibility, then yes, it's = too late. The same is true for changing SHOULD not have duplicate names = in objects. OTOH, if we want a cleaner standard going forwards, by all means let's = take out the over-cautious SHOULDs, and make a clear statement in the = Introduction where we changed the requirements. I'm strongly in favor of the latter. --Paul Hoffman= From mnot@mnot.net Mon Feb 18 19:12:19 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BF221E804B for ; Mon, 18 Feb 2013 19:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.426 X-Spam-Level: X-Spam-Status: No, score=-105.426 tagged_above=-999 required=5 tests=[AWL=-2.827, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdGgmdD0Z-fX for ; Mon, 18 Feb 2013 19:12:14 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id CE87F21F8CBF for ; Mon, 18 Feb 2013 19:12:14 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.197.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 30D31509B9; Mon, 18 Feb 2013 22:12:12 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Tue, 19 Feb 2013 14:12:08 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <5F517CD8-1A28-46A5-8E34-01B0E51BE37D@mnot.net> References: To: Paul Hoffman X-Mailer: Apple Mail (2.1499) Cc: json@ietf.org Subject: Re: [Json] Upgrading SHOULD to MUST X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 03:12:19 -0000 On 19/02/2013, at 1:02 PM, Paul Hoffman wrote: >=20 > If we are supposed to be keeping backwards compatibility, then yes, = it's too late. The same is true for changing SHOULD not have duplicate = names in objects. >=20 > OTOH, if we want a cleaner standard going forwards, by all means let's = take out the over-cautious SHOULDs, and make a clear statement in the = Introduction where we changed the requirements. >=20 > I'm strongly in favor of the latter. >=20 > --Paul Hoffman you ARE going to get Crockford involved in this process somehow, right? Cheers, -- Mark Nottingham http://www.mnot.net/ From derhoermi@gmx.net Mon Feb 18 16:26:38 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9512621E804B for ; Mon, 18 Feb 2013 16:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCop1cfHggup for ; Mon, 18 Feb 2013 16:26:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id B2D7A21E8039 for ; Mon, 18 Feb 2013 16:26:37 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Mh7vz-1UTosv2ED3-00MHfp for ; Tue, 19 Feb 2013 01:26:36 +0100 Received: (qmail invoked by alias); 19 Feb 2013 00:26:36 -0000 Received: from p54B4E14B.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [84.180.225.75] by mail.gmx.net (mp027) with SMTP; 19 Feb 2013 01:26:36 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19YkEZcy7pYmF/kh176LU5qupG38vwm9DtFxPbiQu czS6uFbzJ6nWGL From: Bjoern Hoehrmann To: "Joe Hildebrand (jhildebr)" Date: Tue, 19 Feb 2013 01:26:37 +0100 Message-ID: <1ah5i81al3ug4qgmgjqgjnl5evf6jc1qnq@hive.bjoern.hoehrmann.de> References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Mon, 18 Feb 2013 21:42:26 -0800 Cc: "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 00:26:38 -0000 * Joe Hildebrand (jhildebr) wrote: >As a start, we know there are a couple of things we'd like to fix about >RFC 4627: > >- move to standards track >- an ABNF indentation typo in section 2.2 >- change SHOULD to MUST for the uniqueness of names in an object > >A *very* important goal would be to minimize change, and to ensure strict >backward-compatibility. A Working Group will also likely have to look at revising the rules to detect the character encoding in application/json resources (there is a lack of consensus whether to auto-detect UTF-32 and whether to honour a Unicode signature, whether to support UTF-32 when it is detected, and so on, partly due to how people load JSON resources; a generic "load text" API for instance might detect and remove a Unicode signature before the data is passed to a JSON parser; this used to be true for XMLHttpRequest for instance, I haven't checked the current situation there though). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From tbray@textuality.com Mon Feb 18 23:05:44 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092F521F8D75 for ; Mon, 18 Feb 2013 23:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.29 X-Spam-Level: X-Spam-Status: No, score=-3.29 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izTHrjtXdpgQ for ; Mon, 18 Feb 2013 23:05:43 -0800 (PST) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC9F21F8D70 for ; Mon, 18 Feb 2013 23:05:43 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id wy12so2079270pbc.35 for ; Mon, 18 Feb 2013 23:05:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=LgrNtjIwAoyWSVG7axv42QAGkArEdi7729f2T1+6f5c=; b=G8bBi67BXi9bbEPLRuIKBHSeQUbezIPJxdlNH3uXPPOYs+Ml8VUwr39Aavyh4W5bIL Y+sTT6+Zu78F1HDOgEf2hh7SqFK+AXn/tPc57Yly/p9X5/AEHyjxteF/zZf2zu0h3bU/ 4OWNg7N2p0O+dLAv8kDFDxNQJQ1UbN+2T6+y4nBKp1GFLTdS2/y5uc0rgTVdwM7xoOl3 MuedHpuv8kOhQXPhl8kKoljeTg73mk7LZuqoA2pxnk6ELhXv8yh/w/+oNE0d4CLD6u0k xBaa0xkIEFtNGEFe2gkjh2gE5yokuac8UW1O21a5RnrP7ttTWEftsgE6FKCCXMcssivE K6cA== MIME-Version: 1.0 X-Received: by 10.68.7.106 with SMTP id i10mr37526504pba.43.1361257542655; Mon, 18 Feb 2013 23:05:42 -0800 (PST) Received: by 10.66.249.129 with HTTP; Mon, 18 Feb 2013 23:05:42 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <1ah5i81al3ug4qgmgjqgjnl5evf6jc1qnq@hive.bjoern.hoehrmann.de> References: <1ah5i81al3ug4qgmgjqgjnl5evf6jc1qnq@hive.bjoern.hoehrmann.de> Date: Mon, 18 Feb 2013 23:05:42 -0800 Message-ID: From: Tim Bray To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=bcaec5314a1f47204204d60e784a X-Gm-Message-State: ALoCoQlfgR16fvCnO831xFMWHuvyKwFymp1IgCAVx7RXNRXiSWwBbfyppOalziNce8aNRKoPR2ys Cc: "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 07:05:44 -0000 --bcaec5314a1f47204204d60e784a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Easily solved: =93In all instances when JSON is transmitted over a network, it MUST be encoded in UTF-8; a charset argument on the Content-type MAY be provided, but its value MUST be utf-8.=94 -T On Mon, Feb 18, 2013 at 4:26 PM, Bjoern Hoehrmann wrote= : > * Joe Hildebrand (jhildebr) wrote: > >As a start, we know there are a couple of things we'd like to fix about > >RFC 4627: > > > >- move to standards track > >- an ABNF indentation typo in section 2.2 > >- change SHOULD to MUST for the uniqueness of names in an object > > > >A *very* important goal would be to minimize change, and to ensure stric= t > >backward-compatibility. > > A Working Group will also likely have to look at revising the rules to > detect the character encoding in application/json resources (there is a > lack of consensus whether to auto-detect UTF-32 and whether to honour a > Unicode signature, whether to support UTF-32 when it is detected, and so > on, partly due to how people load JSON resources; a generic "load text" > API for instance might detect and remove a Unicode signature before the > data is passed to a JSON parser; this used to be true for XMLHttpRequest > for instance, I haven't checked the current situation there though). > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= .de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --bcaec5314a1f47204204d60e784a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Easily solved: =93In all instances when JSON is trans= mitted over a network, it MUST be encoded in UTF-8; a charset argument on t= he Content-type MAY be provided, but its value MUST be utf-8.=94

=A0-T


On Mon, Feb 18, 2013 at 4:26 PM, Bjoern Hoehrmann <<= a href=3D"mailto:derhoermi@gmx.net" target=3D"_blank">derhoermi@gmx.net= > wrote:
* Joe Hildebrand (jhildebr) wrote:
>As a start, we know there are a couple of things we'd like to fix a= bout
>RFC 4627:
>
>- move to standards track
>- an ABNF indentation typo in section 2.2
>- change SHOULD to MUST for the uniqueness of names in an object
>
>A *very* important goal would be to minimize change, and to ensure stri= ct
>backward-compatibility.

A Working Group will also likely have to look at revising the rules to
detect the character encoding in application/json resources (there is a
lack of consensus whether to auto-detect UTF-32 and whether to honour a
Unicode signature, whether to support UTF-32 when it is detected, and so on, partly due to how people load JSON resources; a generic "load text= "
API for instance might detect and remove a Unicode signature before the
data is passed to a JSON parser; this used to be true for XMLHttpRequest for instance, I haven't checked the current situation there though). --
Bj=F6rn H=F6hrmann =B7 mailto:bjoern= @hoehrmann.de =B7 http://bjoern.hoehrmann.de
Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld.de
25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.de/
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--bcaec5314a1f47204204d60e784a-- From jhildebr@cisco.com Tue Feb 19 07:21:51 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95E721F880F for ; Tue, 19 Feb 2013 07:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCrCFsmyvGpe for ; Tue, 19 Feb 2013 07:21:47 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id AA4C521F882D for ; Tue, 19 Feb 2013 07:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=281; q=dns/txt; s=iport; t=1361287307; x=1362496907; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=3e7JukT+CxsSymPhKu54u8eVyK9M81K5YuE1QJ1rsTo=; b=FsIpOSRtjhjAW7QqY3qHYHxdTdIDGnx/8FLIPNUGZp2s8UAoVZ7Z0jGV jVvPawLb3sQCCbAXdQTVjSdCQO7Lo4xMjFVZYJQHO34JwkhnbE9Pn8PnO yri0fHZeNCxpgCUMt/U4jgLKffyJ/4dvjJQYviiGse/zJjd9iyyFov+TX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAMqXI1GtJXG//2dsb2JhbABFhgK6PYEKFnOCIQEEOj8SAQgOFBRCJQIEAQ0FCIgKsDCQHo1agQMxB4JfYQOnA4MHgWs8 X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; d="scan'208";a="178745174" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 19 Feb 2013 15:21:47 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1JFLlYd003929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 15:21:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 09:21:47 -0600 From: "Joe Hildebrand (jhildebr)" To: Mark Nottingham , Paul Hoffman Thread-Topic: [Json] Upgrading SHOULD to MUST Thread-Index: AQHODkVBd7XjDv18rkKeUKb+YwfKZ5iA5dcAgABWgQA= Date: Tue, 19 Feb 2013 15:21:46 +0000 Message-ID: In-Reply-To: <5F517CD8-1A28-46A5-8E34-01B0E51BE37D@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <76E8B026DFA6B549AC9EE029797F53A6@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Upgrading SHOULD to MUST X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 15:21:51 -0000 On 2/18/13 8:12 PM, "Mark Nottingham" wrote: >you ARE going to get Crockford involved in this process somehow, right? I contacted him before the list was formed, but I'll reach out again to make sure he's got the right coordinates. --=20 Joe Hildebrand From jhildebr@cisco.com Tue Feb 19 07:25:15 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4699721F8DBB for ; Tue, 19 Feb 2013 07:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d0U-9nONy2d for ; Tue, 19 Feb 2013 07:25:13 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 68B8C21F8C12 for ; Tue, 19 Feb 2013 07:25:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=550; q=dns/txt; s=iport; t=1361287513; x=1362497113; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Qa5fMRNnm/Lv0Cxq2PSSatMK0oZ6lWaIqXN19t9CtbQ=; b=iqCKnkLy/pZnr7QqK9gHimCo6OPSlmPr2jp4UlM+uxPinRc1hzv8J/FB vNBf79wCVVCEDnDoKsJ5Z0lXbzPKrwuIirfHxAHlD4QQe/daKORsY+Spb 8bwhyfmbJza981zcbhN8oa6cUBSUC/PdjwCIs9oBU9udJKuY6Qc9yaP3R 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAMqXI1GtJV2c/2dsb2JhbABFhgK6PYEKFnOCIQEEbgsSAQgOFFYlAgQBDQUIiAqwMJAejlsCMQeCX2EDiDCeU4MHgic X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; d="scan'208";a="178746368" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 19 Feb 2013 15:25:09 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1JFP9t1009782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 15:25:09 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 09:25:08 -0600 From: "Joe Hildebrand (jhildebr)" To: Tim Bray , Bjoern Hoehrmann Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piAt/6AgABvgQCAABYvAA== Date: Tue, 19 Feb 2013 15:25:08 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <418F8E0A3D2F7449A3489FEBF10813B1@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 15:25:15 -0000 On 2/19/13 12:05 AM, "Tim Bray" wrote: >Easily solved: =B3In all instances when JSON is transmitted over a network= , >it MUST be encoded in UTF-8; a charset argument on the Content-type MAY >be provided, but its value MUST be utf-8.=B2 Could we change section 3 to explain that if you want to liberal in what you accept you can parse according to the older rules (including dealing with a BOM), but that you MUST always generate UTF-8 with no BOM if you're going to be 4627bis compliant? --=20 Joe Hildebrand From gsalguei@cisco.com Tue Feb 19 07:59:30 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E624B21F8DF7 for ; Tue, 19 Feb 2013 07:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.508 X-Spam-Level: X-Spam-Status: No, score=-10.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zx8IzZKtF7iC for ; Tue, 19 Feb 2013 07:59:29 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 2476721F8DF1 for ; Tue, 19 Feb 2013 07:59:29 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1JFxSCK028313 for ; Tue, 19 Feb 2013 10:59:28 -0500 (EST) Received: from rtp-gsalguei-8917.cisco.com (rtp-gsalguei-8917.cisco.com [10.116.132.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1JFxRFC025146; Tue, 19 Feb 2013 10:59:28 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Gonzalo Salgueiro In-Reply-To: Date: Tue, 19 Feb 2013 10:59:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <28432E24-E917-4510-9F23-DF563B38032E@cisco.com> References: To: Joe Hildebrand (jhildebr) X-Mailer: Apple Mail (2.1499) Cc: Bjoern Hoehrmann , Tim Bray , json@ietf.org Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 15:59:30 -0000 On Feb 19, 2013, at 10:25 AM, Joe Hildebrand (jhildebr) = wrote: > On 2/19/13 12:05 AM, "Tim Bray" wrote: >=20 >> Easily solved: =B3In all instances when JSON is transmitted over a = network, >> it MUST be encoded in UTF-8; a charset argument on the Content-type = MAY >> be provided, but its value MUST be utf-8.=B2 >=20 > Could we change section 3 to explain that if you want to liberal in = what > you accept you can parse according to the older rules (including = dealing > with a BOM), but that you MUST always generate UTF-8 with no BOM if = you're > going to be 4627bis compliant? I think that is reasonable, and it maintains the backwards compatibility = you stressed as critical to this effort. Gonzalo >=20 > --=20 > Joe Hildebrand >=20 >=20 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 From cabo@tzi.org Tue Feb 19 08:39:21 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B7421F8DF4; Tue, 19 Feb 2013 08:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OElAZYuL1P5X; Tue, 19 Feb 2013 08:39:21 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7C121F8C17; Tue, 19 Feb 2013 08:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r1JGdCKB020547; Tue, 19 Feb 2013 17:39:12 +0100 (CET) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E31BE317C; Tue, 19 Feb 2013 17:39:11 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 19 Feb 2013 17:39:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7EB82E7A-F664-46F8-8137-83DF0C3F5536@tzi.org> References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 16:39:22 -0000 On Feb 19, 2013, at 00:47, "Joe Hildebrand (jhildebr)" = wrote: > As an individual, I'm +1 on that. I love msgpack, and don't mind the > addition of UTF8 as a separate type. Was frsyuki involved in the = draft, > or at least know that it happened? I tried to involve him. Frsyuki doesn't like what I did with the binary strings vs. UTF-8, = though. I didn't quite catch whether he is just focusing on maintaining = compatibility with what's out there (today's msgpack) or whether he = really doesn't see why that is a good idea. (For me, maintaining 100 % compatibility won't work anyway, because in = the end that won't be the only change we'll want to make. =20 If we look a bit outside the space that msgpack is being applied to = today, we might want to support, say, 16-bit floating point.) Gr=FC=DFe, Carsten From jhildebr@cisco.com Tue Feb 19 09:31:44 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2471C21F8E71; Tue, 19 Feb 2013 09:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7B0QLag1y+a; Tue, 19 Feb 2013 09:31:43 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3EF21F8E6E; Tue, 19 Feb 2013 09:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=330; q=dns/txt; s=iport; t=1361295103; x=1362504703; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=oAyK8c+oCDHveRYPtbpizypGerFHk5PIvI8zf+4bFzg=; b=ZSdv/hgjwJai1iJO/FTjR1Ehl6YhPZsobUYpmoZplTI+8xkhyEzIEbbl cC7G0tdJwkWkn0EEoc9WkLodFF33sSck0VvQshdGtTowJDm8v0QNKUDwk JiKRp8UV4jNvF1VP2AAcNS8ud3VP2VD4yOmSY+XAz/0fElnc+f2ch2Bcx s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAD62I1GtJV2c/2dsb2JhbABEhgK6OoEMFnOCIQEEOjQLEgEIDhQUQiUCBA4FCIgKsE2QHo5dMQeCX2EDpwODB4In X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; d="scan'208";a="178841480" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 19 Feb 2013 17:31:43 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1JHVhZn019920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 17:31:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 11:31:43 -0600 From: "Joe Hildebrand (jhildebr)" To: Carsten Bormann Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piAiBQA//+vjYCAAZAYgP//mVEA Date: Tue, 19 Feb 2013 17:31:42 +0000 Message-ID: In-Reply-To: <7EB82E7A-F664-46F8-8137-83DF0C3F5536@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.82] Content-Type: text/plain; charset="us-ascii" Content-ID: <4062FD20F3656645BBBE52B51F1407D1@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 17:31:44 -0000 On 2/19/13 9:39 AM, "Carsten Bormann" wrote: >If we look a bit outside the space that msgpack is being applied to >today, we might want to support, say, 16-bit floating point.) and potentially Date. If we were going to standardize this, the IETF would need full change control. --=20 Joe Hildebrand From fgaliegue@gmail.com Tue Feb 19 09:37:35 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCDE21F8DF2; Tue, 19 Feb 2013 09:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub0I6Zom5Z-O; Tue, 19 Feb 2013 09:37:24 -0800 (PST) Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id C434121F8B83; Tue, 19 Feb 2013 09:37:23 -0800 (PST) Received: by mail-ea0-f174.google.com with SMTP id 1so2937644eaa.33 for ; Tue, 19 Feb 2013 09:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/1050v0OHHVI6tl9cznJfv0TC0TpoWImcQlCarHffps=; b=lUTAUvaZP7EZPNVZLBnGbuqyAJhtL4Sg6/NcEqJ5NB5ESOnWLiIg37ZsqiPt1Lv9Vh 4i+B6cbSYLMFggURSO4J/u7OoX1UNdF+fvLqjulfU002iUlcNyL6qv9hy8TyDD6lOIgj zdlgsFcrP+v+3rkpiAvvsLeXrD6zL5yqXqwv+kKGYqNoCBN/YQARgxi+r31FKS2dLhUd ivzct2YUmJgAK4K14srnfy0P4BlAvs+A1zQZcpQwCdwl2WEjxoRIYH7M3+Ud565YVMwi p6JdCqa18xl+YIYhW1NzaCyrDiPewmraBVOh6NMdjO5nQgcWvZxGzzDo2pRGN5Hh0TvV lJcg== MIME-Version: 1.0 X-Received: by 10.14.183.198 with SMTP id q46mr59595060eem.1.1361295443003; Tue, 19 Feb 2013 09:37:23 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 09:37:22 -0800 (PST) In-Reply-To: References: <7EB82E7A-F664-46F8-8137-83DF0C3F5536@tzi.org> Date: Tue, 19 Feb 2013 18:37:22 +0100 Message-ID: From: Francis Galiegue To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: Carsten Bormann , "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 17:37:36 -0000 On Tue, Feb 19, 2013 at 6:31 PM, Joe Hildebrand (jhildebr) wrote: [...] > > and potentially Date. > > If we were going to standardize this, the IETF would need full change > control. > Another unrelated point: I see no reason why a transmitted JSON document (called a "JSON text") has to be a "container" and not any JSON value. What was the motivation behind this in the RFC in the first place? -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From mamille2@cisco.com Tue Feb 19 12:33:18 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E718A21F8658; Tue, 19 Feb 2013 12:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.528 X-Spam-Level: X-Spam-Status: No, score=-10.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QdebbXIlXkL; Tue, 19 Feb 2013 12:33:17 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E8C1621F84E9; Tue, 19 Feb 2013 12:33:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1788; q=dns/txt; s=iport; t=1361305991; x=1362515591; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Drd6s5ZvuG2mgNKfIq+jcA+UtF3Ak3ObPUOmLYvOkx0=; b=ZHqOFsC4hw26j0oog65VRrkNjEy5PvCbQgOHeULcTWK9O2d+Ww+qxgd7 3++/y7nfxdgEpq//YGw0WtKSBzoJrLasa7KoM50oHCF4OdvTcaYcOQlMq 4Ne3uuxghZyiq4fYlThs6eCi2EP0f8unMiRcA6rdf1x74wv746vNeKHjT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJ/gI1GtJXHB/2dsb2JhbABFwDuBDRZzgh8BAQEDAQEBATctBAMLBQsCAQgiFBAnCyUCBA4FCAGIAwYMsDOQJ41NgQ4CMQIFgl9hA5dIjzuDB4FyNQ X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178900590" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 19 Feb 2013 20:33:10 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1JKXAGM011800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 20:33:10 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 14:33:10 -0600 From: "Matt Miller (mamille2)" To: "Joe Hildebrand (jhildebr)" Thread-Topic: [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piCCRiA Date: Tue, 19 Feb 2013 20:33:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.55] Content-Type: text/plain; charset="us-ascii" Content-ID: <2350A2168A8B494C9EAD3849DB8EB7D6@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 20:33:19 -0000 Another topic that might worth discussing is canonicalization. It's come u= p in JOSE a couple of times[1], and it would be helpful to standardize an a= pproach. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [1] The most recent discussing starts at < http://www.ietf.org/mail-archive= /web/jose/current/msg01575.html >, instigated by < http://www.ietf.org/mail= -archive/web/jose/current/msg01553.html > On Feb 18, 2013, at 1:01 PM, Joe Hildebrand (jhildebr) = wrote: > We're planning on doing a BoF in Orlando to discuss starting up a JSON > working group. The BoF is currently planned for Monday afternoon at 1300 > in Carribean 6. A very preliminary version of a charter can be found her= e: >=20 > http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON >=20 >=20 > But obviously we'll need to build consensus on what it should actually > contain. Please discuss on the json@ietf.org mailing list: >=20 > https://www.ietf.org/mailman/listinfo/json >=20 >=20 > As a start, we know there are a couple of things we'd like to fix about > RFC 4627: >=20 > - move to standards track > - an ABNF indentation typo in section 2.2 > - change SHOULD to MUST for the uniqueness of names in an object >=20 > A *very* important goal would be to minimize change, and to ensure strict > backward-compatibility. >=20 > There are likely adjunct JSON topics that would make sense to tackle once > we've got the experts together, but the goal would be to keep that list > short, focused, and general-purpose. >=20 > --=20 > Joe Hildebrand >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From jhildebr@cisco.com Tue Feb 19 12:47:11 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58A721F87E1; Tue, 19 Feb 2013 12:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU3CjMYjPTQi; Tue, 19 Feb 2013 12:47:11 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3936721F87CD; Tue, 19 Feb 2013 12:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=490; q=dns/txt; s=iport; t=1361306831; x=1362516431; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=4HPDbE1USdcalLQJb+v6YopTd4bfAaeS69d+gnK5vcs=; b=XIcNtLdACd1AsImR/TXVocw6RxXOekXF7aAdiCoVQLARc7CA8yYp+/n2 +PoHu7AHaUEoFx6iRH2bfN4YMm8ttPJU/MoYfLnsvk/TUigOFA4XW99Di o7N/6LqC4cdBUgCkpS+XP+obHGm0MmhMd/PyMunOjfUs8uCD942j8FooD w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAE3jI1GtJV2c/2dsb2JhbABEhgK6OYENFnOCIQEEOj8SASoUQiUCBA4FCIgKsDCQKI5dMQeCX2EDpwODB4In X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178874370" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 19 Feb 2013 20:47:10 +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 r1JKlA4d001373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 20:47:10 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 14:47:10 -0600 From: "Joe Hildebrand (jhildebr)" To: "Matt Miller (mamille2)" Thread-Topic: Canonicalization Thread-Index: AQHODuJJD2QYqWyDNUmeQU+v/Kxthg== Date: Tue, 19 Feb 2013 20:47:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.82] Content-Type: text/plain; charset="us-ascii" Content-ID: <766D6830FEA94B45A46B821B238A5CF2@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 20:47:11 -0000 On 2/19/13 1:33 PM, "Matt Miller (mamille2)" wrote: >Another topic that might worth discussing is canonicalization. It's come >up in JOSE a couple of times[1], and it would be helpful to standardize >an approach. (individual) Do you think draft-staykov-hu-json-canonical-form is a valid starting point? My biggest beef with it is that the number syntax uses capital E and JavaScript's toExponential() generates a lowercase e. --=20 Joe Hildebrand From Michael.Jones@microsoft.com Tue Feb 19 12:47:35 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5871D21F8806; Tue, 19 Feb 2013 12:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmiLsFIsQ5iy; Tue, 19 Feb 2013 12:47:34 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.26]) by ietfa.amsl.com (Postfix) with ESMTP id 860E421F87E1; Tue, 19 Feb 2013 12:47:34 -0800 (PST) Received: from BL2FFO11FD015.protection.gbl (10.173.161.202) by BL2FFO11HUB029.protection.gbl (10.173.161.53) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 19 Feb 2013 20:47:32 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 19 Feb 2013 20:47:31 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Tue, 19 Feb 2013 20:47:03 +0000 From: Mike Jones To: "Matt Miller (mamille2)" , "Joe Hildebrand (jhildebr)" Thread-Topic: [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piCCRiA//+eqLA= Date: Tue, 19 Feb 2013 20:47:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(51704002)(13464002)(189002)(199002)(24454001)(65816001)(79102001)(53806001)(80022001)(16406001)(54316002)(56776001)(46406002)(76482001)(51856001)(50986001)(46102001)(55846006)(56816002)(4396001)(47736001)(47976001)(50466001)(49866001)(31966008)(74662001)(63696002)(54356001)(5343655001)(47446002)(15202345001)(5343635001)(66066001)(74502001)(77982001)(23726001)(44976002)(59766001)(20776003)(33656001)(47776003); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB029; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0762FFD075 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 20:47:35 -0000 I'm strongly against canonicalization. The XML canonicalization experience= was horrible and resulted in more interop bugs than any other aspect of XM= L DSIG, XML ENC, etc. Let's not repeat the mistakes of our elders. ;-) I also haven't seen a clear use case that canonicalization solves that can'= t be more easily solved another way. -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Matt Miller (mamille2) Sent: Tuesday, February 19, 2013 12:33 PM To: Joe Hildebrand (jhildebr) Cc: apps-discuss@ietf.org; json@ietf.org Subject: Re: [apps-discuss] JSON mailing list and BoF Another topic that might worth discussing is canonicalization. It's come u= p in JOSE a couple of times[1], and it would be helpful to standardize an a= pproach. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [1] The most recent discussing starts at < http://www.ietf.org/mail-archive= /web/jose/current/msg01575.html >, instigated by < http://www.ietf.org/mail= -archive/web/jose/current/msg01553.html > On Feb 18, 2013, at 1:01 PM, Joe Hildebrand (jhildebr) = wrote: > We're planning on doing a BoF in Orlando to discuss starting up a JSON=20 > working group. The BoF is currently planned for Monday afternoon at=20 > 1300 in Carribean 6. A very preliminary version of a charter can be foun= d here: >=20 > http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON >=20 >=20 > But obviously we'll need to build consensus on what it should actually=20 > contain. Please discuss on the json@ietf.org mailing list: >=20 > https://www.ietf.org/mailman/listinfo/json >=20 >=20 > As a start, we know there are a couple of things we'd like to fix=20 > about RFC 4627: >=20 > - move to standards track > - an ABNF indentation typo in section 2.2 > - change SHOULD to MUST for the uniqueness of names in an object >=20 > A *very* important goal would be to minimize change, and to ensure=20 > strict backward-compatibility. >=20 > There are likely adjunct JSON topics that would make sense to tackle=20 > once we've got the experts together, but the goal would be to keep=20 > that list short, focused, and general-purpose. >=20 > -- > Joe Hildebrand >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From jhildebr@cisco.com Tue Feb 19 13:27:58 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E35821F8A85; Tue, 19 Feb 2013 13:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BR3EpGrBtgKX; Tue, 19 Feb 2013 13:27:49 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 07B1B21F88D8; Tue, 19 Feb 2013 13:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=602; q=dns/txt; s=iport; t=1361309261; x=1362518861; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=yri0lOJk7ruFBiWtO6P0Us5YGh4IPZr17yp12sVTNCc=; b=SLiPXwNQPlmSInk2u3NYZ2UEEXz4Xu1Tgyb/xHLJJL3RjaKH+oux4GuA 8SHILUY9mHptowbAF6hQQsbA//FcRUq/p++oK1QjQvrxxeCfIOjuyJ9pp h/FJEaKh6jvP2xp3q2yKYQ3roaDUmL5ESdl2vdY667gqkHBpK1UnFW+L8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAOvtI1GtJV2a/2dsb2JhbABEhgK6OoENFnOCIQEEOjQLEgEIDhQUQiUCBAENBQiICrAzkCqOXTEHgl9hA6cDgweCJw X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178889060" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 19 Feb 2013 21:27:39 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1JLRdte017405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 21:27:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 15:27:38 -0600 From: "Joe Hildebrand (jhildebr)" To: Mike Jones , "Matt Miller (mamille2)" Thread-Topic: [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piCCRiA//+eqLD///s2AA== Date: Tue, 19 Feb 2013 21:27:38 +0000 Message-ID: In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.82] Content-Type: text/plain; charset="us-ascii" Content-ID: <02496F7EBBA94347B4FBD3E8780A9AC0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 21:27:59 -0000 On 2/19/13 1:47 PM, "Mike Jones" wrote: >I'm strongly against canonicalization. The XML canonicalization >experience was horrible and resulted in more interop bugs than any other >aspect of XML DSIG, XML ENC, etc. Let's not repeat the mistakes of our >elders. ;-) > >I also haven't seen a clear use case that canonicalization solves that >can't be more easily solved another way. I somewhat agree, but have you at least read draft-staykov-hu-json-canonical-form? It's pretty straightforward, and nowhere near as scary as xmlenc. --=20 Joe Hildebrand From jhildebr@cisco.com Tue Feb 19 13:29:03 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0743C21F888A; Tue, 19 Feb 2013 13:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2ONUP5TJQMl; Tue, 19 Feb 2013 13:29:02 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3AED321F8441; Tue, 19 Feb 2013 13:29:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=321; q=dns/txt; s=iport; t=1361309342; x=1362518942; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=U/u/cCmLvJA/1XnJsMcN/XlpveLxUpgCUJhZZXoVy/8=; b=la7i9cYZ1rqTUtUP88DNhPkVThwgCS2R320pO2WAI/CLeoB1W14F+u6+ yxns0uWjFiEzDVhzCzI4r42ejXFJYXXhHqL0jD+iH8SVyv7gLD0yw8MkO D+lFF/J0JlLVWNa6wCjXY2o5wkeFrRM2xXowKR1tVdNTCv9lRsVqbF2l5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAEbtI1GtJV2b/2dsb2JhbABEhgK6OoENFnOCIQEEOjQLEgEIDhQUQiUCBAENBQiICrAwkCqOXTEHgl9hA6cDgweCJw X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178893679" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 19 Feb 2013 21:29:00 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1JLT0fL014844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 21:29:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 15:29:00 -0600 From: "Joe Hildebrand (jhildebr)" To: Mike Jones , "Matt Miller (mamille2)" Thread-Topic: [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piCCRiA//+eqLD///uWgA== Date: Tue, 19 Feb 2013 21:28:59 +0000 Message-ID: In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.82] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 21:29:03 -0000 On 2/19/13 1:47 PM, "Mike Jones" wrote: >I also haven't seen a clear use case that canonicalization solves that >can't be more easily solved another way. I needed it for a light use case recently; I wanted to use a serialized object as the key into a hash. --=20 Joe Hildebrand From tbray@textuality.com Tue Feb 19 13:34:52 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20ACE21F89B2 for ; Tue, 19 Feb 2013 13:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doHykc1U7LfK for ; Tue, 19 Feb 2013 13:34:51 -0800 (PST) Received: from mail-da0-f48.google.com (mail-da0-f48.google.com [209.85.210.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4117021F8996 for ; Tue, 19 Feb 2013 13:34:51 -0800 (PST) Received: by mail-da0-f48.google.com with SMTP id v40so3197769dad.7 for ; Tue, 19 Feb 2013 13:34:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=2lul2OGJK1NbLp9hsfqPqs21/ZvW9XphqB2bJw5K9MQ=; b=F8kMl2z15DPUZnv9SST+kqhjtTSGoWVsv4N3ZA3Ye3kDRM2iWbqMU7Og8BwfAP6+gj s64HAuyvQfRdl/iTGNN86hVsm/7eXqvWAkcTb+oTVt9T6dKgvof6FIk/pGS38pps4/uh 3hYGry0FEQCWgaPXvRNg9Ah6hFrdkYEwyyR9udRCvlz5w2zHuzJkJFntvDO/mnhxqDTL rpZb7pOpp5ijB+udMopPMj2R+F99POyYlphMzjRCUK90Yz/Begcp8u1fN/M/UXQjoXg9 LJH1JOqcxv+g8eSp48AJkdw9GLlaIgHtXZJuQbA4I2L2fIDLz9D9qOVWGws+P2O55Q/q HzcA== MIME-Version: 1.0 X-Received: by 10.69.2.133 with SMTP id bo5mr44155031pbd.70.1361309691004; Tue, 19 Feb 2013 13:34:51 -0800 (PST) Received: by 10.66.249.129 with HTTP; Tue, 19 Feb 2013 13:34:50 -0800 (PST) X-Originating-IP: [172.29.161.33] In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 13:34:50 -0800 Message-ID: From: Tim Bray To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=047d7b5d8de78fc5bd04d61a9c6f X-Gm-Message-State: ALoCoQmI/V6YN1hZQl1wyklZ9c06CWbt1XEETIjMJY46prGd8vS4vC+agRNX1yge3YH5mSMLuMfq Cc: Mike Jones , "json@ietf.org" , "apps-discuss@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 21:34:52 -0000 --047d7b5d8de78fc5bd04d61a9c6f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable re draft-staykov-hu-json-canonical-form: Looks sensible. One gripe: Why can=92t you sign NaN and INF? They do in fact occur in the field, and it=92s not as though a noncanonical representation is possible. -T (who still hasn=92t decided if this is actually a good idea) On Tue, Feb 19, 2013 at 1:27 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 2/19/13 1:47 PM, "Mike Jones" wrote: > > >I'm strongly against canonicalization. The XML canonicalization > >experience was horrible and resulted in more interop bugs than any other > >aspect of XML DSIG, XML ENC, etc. Let's not repeat the mistakes of our > >elders. ;-) > > > >I also haven't seen a clear use case that canonicalization solves that > >can't be more easily solved another way. > > I somewhat agree, but have you at least read > draft-staykov-hu-json-canonical-form? It's pretty straightforward, and > nowhere near as scary as xmlenc. > > -- > Joe Hildebrand > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b5d8de78fc5bd04d61a9c6f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
re draft-staykov-hu-json-canonical-form:
Looks sensibl= e. One gripe:=A0 Why can=92t you sign NaN and INF?=A0 They do in fact=A0 oc= cur in the field, and it=92s not as though a noncanonical representation is= possible.=A0

-T (who still hasn=92t decided if this is actually a good idea)


On Tue, Feb= 19, 2013 at 1:27 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com&g= t; wrote:
On 2/19/13 1:47 PM, "= Mike Jones" <Michael= .Jones@microsoft.com> wrote:

>I'm strongly against canonicalization. =A0The XML canonicalization<= br> >experience was horrible and resulted in more interop bugs than any othe= r
>aspect of XML DSIG, XML ENC, etc. =A0Let's not repeat the mistakes = of our
>elders. ;-)
>
>I also haven't seen a clear use case that canonicalization solves t= hat
>can't be more easily solved another way.

I somewhat agree, but have you at least read
draft-staykov-hu-json-canonical-form? =A0It's pretty straightforward, a= nd
nowhere near as scary as xmlenc.

--
Joe Hildebrand



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

--047d7b5d8de78fc5bd04d61a9c6f-- From nico@cryptonector.com Tue Feb 19 13:41:41 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A078E21F8A33; Tue, 19 Feb 2013 13:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.608 X-Spam-Level: X-Spam-Status: No, score=-3.608 tagged_above=-999 required=5 tests=[AWL=-1.631, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0fhK0a3fdfz; Tue, 19 Feb 2013 13:41:41 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD7621F8A0D; Tue, 19 Feb 2013 13:41:41 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 891A4594074; Tue, 19 Feb 2013 13:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=fzASUCRbln4lHgmbPZv+S3pcksA=; b=Uw6EkdwQ/Ha F6wWwzbzN78ydMFZwg/o5YYMKji+OaCG8QaolmycQox67fsf2URlnQzWFZUlXkCW WE+99QY1eX791ZwFqCbYyh+eipeDeMfmWV9i85m+QewwBZerHkcByp8L2Fn7FJax hBGICOFMPMWvkw10aqnEEmD1aHjptWuI= Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id B67DB594058; Tue, 19 Feb 2013 13:41:29 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id k14so5914958wer.25 for ; Tue, 19 Feb 2013 13:41:28 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.84.165 with SMTP id a5mr30482493wiz.6.1361310087977; Tue, 19 Feb 2013 13:41:27 -0800 (PST) Received: by 10.216.254.217 with HTTP; Tue, 19 Feb 2013 13:41:27 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 15:41:27 -0600 Message-ID: From: Nico Williams To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mike Jones , "json@ietf.org" , "apps-discuss@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 21:41:41 -0000 On Tue, Feb 19, 2013 at 3:27 PM, Joe Hildebrand (jhildebr) wrote: > I somewhat agree, but have you at least read > draft-staykov-hu-json-canonical-form? It's pretty straightforward, and > nowhere near as scary as xmlenc. Indeed. Lexicographic sorting... makes me wonder about Unicode normalization. Before your heads explode, what is the ECMAScript rule regarding normalization of object keys? Are the two normalization forms of 'fo=C3=B3' allowed as distinct keys in an object? Nico -- From mamille2@cisco.com Tue Feb 19 13:42:18 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C9A21E8050; Tue, 19 Feb 2013 13:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.543 X-Spam-Level: X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TyRTKBxiZeo; Tue, 19 Feb 2013 13:42:17 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 799D321E803A; Tue, 19 Feb 2013 13:42:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1273; q=dns/txt; s=iport; t=1361310137; x=1362519737; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BDdK+KgOT9Z79uRebWEnsYWeE+8o15OnEUMNb5MPu+Y=; b=R9HqbXlx94NZNdmObehROXY22r3Z3aAgz0Hbd48ltvY6m4xMMw+bM/VS aogikTGdF6xA4jWZ11eU6S/0lsEnI9hytoBRw1Uu3/DPTQ41K2qGK8yiF Uc51SXWRqxBsDXt39GSM71JFTy4PU63bm713ufsWjYKMCmgm9msF9dw6A U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKPwI1GtJXG+/2dsb2JhbABEwDyBDRZzgh8BAQEDATo/BQsCAQgYChQQMiUCBA4FCIgEBrA0kCiOWwIxB4JfYQOnA4MHgic X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="175901333" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 19 Feb 2013 21:42:17 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1JLgGld007668 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 21:42:16 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 15:42:16 -0600 From: "Matt Miller (mamille2)" To: "Joe Hildebrand (jhildebr)" Thread-Topic: Canonicalization Thread-Index: AQHODuJJdWjMn+WyCECfYKD2BiK4E5iCGsgA Date: Tue, 19 Feb 2013 21:42:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.55] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 21:42:18 -0000 On Feb 19, 2013, at 1:47 PM, Joe Hildebrand (jhildebr) = wrote: > On 2/19/13 1:33 PM, "Matt Miller (mamille2)" wrote: >=20 >> Another topic that might worth discussing is canonicalization. It's com= e >> up in JOSE a couple of times[1], and it would be helpful to standardize >> an approach. >=20 > (individual) >=20 > Do you think draft-staykov-hu-json-canonical-form is a valid starting > point? My biggest beef with it is that the number syntax uses capital E > and JavaScript's toExponential() generates a lowercase e. >=20 Assuming I think canonicalization is something that ought to be done, I thi= nk it is a decent start that needs to be expanded. The first thing that ca= me to my mind is string normalization, and how that relates to escape seque= nces. However, while not as violently opposed as some, I am hesitant. XML canoni= calization has bitten me hard in the past, so I am carrying a bias into thi= s conversation. Maybe a starting point can be "don't rely on canonicalizat= ion unless you really really really have to," and we can come up with a set= of those "really really really have to" scenarios. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. From tbray@textuality.com Tue Feb 19 13:53:09 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA6621E803A for ; Tue, 19 Feb 2013 13:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkZ31lwPvhq0 for ; Tue, 19 Feb 2013 13:53:07 -0800 (PST) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 695F321F87D7 for ; Tue, 19 Feb 2013 13:53:07 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id kq12so3620911pab.1 for ; Tue, 19 Feb 2013 13:53:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=si8j9K6NlZL9nwEaXz0myQj409qMk750tzLqXnyISi8=; b=WNvydtBV46w3CrUtxDTQkf2F/NF/AeE9JrBFErArSO+5hq0b8HWvxmMqtVFCuviGH8 5X44tP1+QnVnPjYjZYHgpwDUCx7VQ18B926Ba9KOqmVty0iCwHcOrvIE/zN99RPbuJi4 nXtQf5DPkaI4VL0+gGAYPV98l5x9xeTMpN/H+tUNb7SWk6CbN/cUMxR+gfXotWp+G6Eq fRFtKbNq4/Z/osOyT0y522ForSaN38VSxKXOpM1JvOb9Yg+NxOGmVgt1et+t6Ri486Q3 WKSrcz4Ss7eYEGgUM1ynms3V1lFLr3ht1tWtdgK880KlxCIw20JHf8QrthbtQd0f7VMN WCrA== MIME-Version: 1.0 X-Received: by 10.68.129.41 with SMTP id nt9mr13469815pbb.20.1361310787196; Tue, 19 Feb 2013 13:53:07 -0800 (PST) Received: by 10.66.249.129 with HTTP; Tue, 19 Feb 2013 13:53:07 -0800 (PST) X-Originating-IP: [172.29.161.33] In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 13:53:07 -0800 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=047d7b10cfe9e6585b04d61add00 X-Gm-Message-State: ALoCoQk1MlJhYoz72xjgGWdhjnLYOTMOB28vNqo/3wKMyNA0K55xTXyIRZOy2a9T9eHvK7xhaXYY Cc: Mike Jones , "Matt Miller \(mamille2\)" , "apps-discuss@ietf.org" , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 21:53:09 -0000 --047d7b10cfe9e6585b04d61add00 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would argue that normalization should be out of scope. I.e. the two forms of =93fo=F3=94 are different strings, that=92s all. =93Doctor! It hurts when I do this!=94 =93So, don=92t do that!=94 -T On Tue, Feb 19, 2013 at 1:41 PM, Nico Williams wrote= : > On Tue, Feb 19, 2013 at 3:27 PM, Joe Hildebrand (jhildebr) > wrote: > > I somewhat agree, but have you at least read > > draft-staykov-hu-json-canonical-form? It's pretty straightforward, and > > nowhere near as scary as xmlenc. > > Indeed. > > Lexicographic sorting... makes me wonder about Unicode normalization. > Before your heads explode, what is the ECMAScript rule regarding > normalization of object keys? Are the two normalization forms of > 'fo=F3' allowed as distinct keys in an object? > > Nico > -- > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b10cfe9e6585b04d61add00 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I would argue that normalization should be out o= f scope.=A0 I.e. the two forms of =93fo=F3=94 are different strings, that= =92s all.=A0
=93Doctor! It hurts when I do this!=94
=93S= o, don=92t do that!=94

-T


On Tue, Feb 19, 2013 at 1:41 PM, Nico Williams <nico@cryptonector.c= om> wrote:
On Tue, Feb 19, 2013 at 3:= 27 PM, Joe Hildebrand (jhildebr)
<jhildebr@cisco.com> wrote:=
> I somewhat agree, but have you at least read
> draft-staykov-hu-json-canonical-form? =A0It's pretty straightforwa= rd, and
> nowhere near as scary as xmlenc.

Indeed.

Lexicographic sorting... makes me wonder about Unicode normalization.
Before your heads explode, what is the ECMAScript rule regarding
normalization of object keys? =A0Are the two normalization forms of
'fo=F3' allowed as distinct keys in an object?

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

--047d7b10cfe9e6585b04d61add00-- From jhildebr@cisco.com Tue Feb 19 13:55:40 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C0F21E80AF; Tue, 19 Feb 2013 13:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOCyfdSDp2ay; Tue, 19 Feb 2013 13:55:38 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EE3D821E80A7; Tue, 19 Feb 2013 13:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=375; q=dns/txt; s=iport; t=1361310938; x=1362520538; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=i1QO1aOHT6ABx280Phy+T5AmEQcoZMG8wUAl+to5p68=; b=Uuo5kUUKGz6doF5VK47mG9+ZGG0ZtnJqC3LIL/THVIE7fIbH85goYwl/ gwfeljOOFVUlRC6Ff4RfeGpXeoLXCUsnZ3Y4LqzRV02aI1lKYNjB+nScC iXfBFfEIE27soZCUIBLeehilrlgMjU8JnHHH3FXbsLnYn6rT8colN1wpu U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAOjzI1GtJXG8/2dsb2JhbABFhgK6P4ENFnOCIQEEbgsSAQgOFFYlAgQOBQiICrAlkCuOXTEHgl9hA4gwnlODB4In X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178877746" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 19 Feb 2013 21:55:37 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1JLtbxT022768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 21:55:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 15:55:37 -0600 From: "Joe Hildebrand (jhildebr)" To: Tim Bray Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piCCRiA//+eqLD///s2AIAAd14A//+Qc4A= Date: Tue, 19 Feb 2013 21:55:37 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mike Jones , "json@ietf.org" , "apps-discuss@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 21:55:40 -0000 On 2/19/13 2:34 PM, "Tim Bray" wrote: >re draft-staykov-hu-json-canonical-form: >Looks sensible. One gripe: Why can=B9t you sign NaN and INF? They do in >fact occur in the field, and it=B9s not as though a noncanonical >representation is possible. I can figure out how to generate a -INF, but how do I get a -NaN? --=20 Joe Hildebrand From paul.hoffman@vpnc.org Tue Feb 19 13:59:53 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D23E21F886A; Tue, 19 Feb 2013 13:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnLruYV3TKq9; Tue, 19 Feb 2013 13:59:53 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id ECB4021F8815; Tue, 19 Feb 2013 13:59:52 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1JLxgKi050999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2013 14:59:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Tue, 19 Feb 2013 13:59:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "apps-discuss@ietf.org Discuss" X-Mailer: Apple Mail (2.1499) Cc: json@ietf.org Subject: [Json] Two lists? [ Was: JSON mailing list and BoF ] X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 21:59:53 -0000 The JSON list seems active already. Do we need to have this thread on = both lists? --Paul Hoffman= From nico@cryptonector.com Tue Feb 19 13:59:59 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F40321F8860; Tue, 19 Feb 2013 13:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=-1.599, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJ1zhNtUAwFv; Tue, 19 Feb 2013 13:59:58 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id B01D821F86D9; Tue, 19 Feb 2013 13:59:58 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 87FFA264070; Tue, 19 Feb 2013 13:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=mUVBvabPMNh0eWa04xPiffKWJoU=; b=yVroJ6bZHpA iP9oicyRqIAnMLMc0Lbbktg3BESq+5VdEh20jZCJTqXpwAUXXyHG+Iqz84gBjIaf zDMMkBVtZic7M597HbFgBjw6XYBpaiYfDXrCwR8agD8OqIbdnjm/m1WuI4ATrSxa U4KrPiFS7fFBz+9iHbpunXi+NfJHALIM= 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-a88.g.dreamhost.com (Postfix) with ESMTPSA id 0A36B26406C; Tue, 19 Feb 2013 13:59:57 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id e12so5775892wge.34 for ; Tue, 19 Feb 2013 13:59:56 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.108.229 with SMTP id hn5mr26777017wib.28.1361311196718; Tue, 19 Feb 2013 13:59:56 -0800 (PST) Received: by 10.216.254.217 with HTTP; Tue, 19 Feb 2013 13:59:56 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 15:59:56 -0600 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mike Jones , "Matt Miller \(mamille2\)" , "apps-discuss@ietf.org" , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 21:59:59 -0000 On Tue, Feb 19, 2013 at 3:53 PM, Tim Bray wrote: > I would argue that normalization should be out of scope. I.e. the two fo= rms > of =E2=80=9Cfo=C3=B3=E2=80=9D are different strings, that=E2=80=99s all. > =E2=80=9CDoctor! It hurts when I do this!=E2=80=9D > =E2=80=9CSo, don=E2=80=99t do that!=E2=80=9D That's fair. In that case this I-D looks simple enough that I can't really oppose it. I do think we should give advice as to how to avoid the need for canonicalization (c14n?) in the first place. From fgaliegue@gmail.com Tue Feb 19 14:01:04 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D8721F886E; Tue, 19 Feb 2013 14:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWKEIfthpcY3; Tue, 19 Feb 2013 14:01:02 -0800 (PST) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id D4CEF21F8815; Tue, 19 Feb 2013 14:01:00 -0800 (PST) Received: by mail-ee0-f52.google.com with SMTP id b15so3553970eek.39 for ; Tue, 19 Feb 2013 14:00:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=zGELp6lsnoCSPuD8g287CwcwiFLU02sMbgnW3NuRK1s=; b=B7NtJQCf+VmqwsDqUEa4BMSoVF5L3PSQ+iqY7Mr6BX2JY8XY5H3YpJdPqPqS6ZYC50 0KLQSWMXNQ8R0L0so1kkKIiQV/qpd0Hbu+CI6p7Oxq1bOrEr7gt+oz3JwThByiXIBQ5h J3M+sc03GOP9b4zHOaA+Nv3JE1lNsBbVSQ74CVK6GP348F5KHj8dBS2wanV+1od+9Q45 7TNQEd5+OyuQthmKCm9Sxm2BVWxLCOKWX6ZT25NTMFTRNaiG2uS6grSOGTxPVKNJ4Pan VEMmSVTKytWB5Vr0S86UiNIOmsDh0ZHzaSl3jgxrTtwFFP4g4jB/EYkgwzYa8C2wwdk9 pLuw== MIME-Version: 1.0 X-Received: by 10.14.193.134 with SMTP id k6mr61462837een.37.1361311259738; Tue, 19 Feb 2013 14:00:59 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 14:00:59 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 23:00:59 +0100 Message-ID: From: Francis Galiegue To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Nico Williams , "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:01:04 -0000 On Tue, Feb 19, 2013 at 10:53 PM, Tim Bray wrote: > I would argue that normalization should be out of scope. I.e. the two fo= rms > of =E2=80=9Cfo=C3=B3=E2=80=9D are different strings, that=E2=80=99s all. > =E2=80=9CDoctor! It hurts when I do this!=E2=80=9D > =E2=80=9CSo, don=E2=80=99t do that!=E2=80=9D > (as a not very well educated individual on this matter...) If _that_ is what normalization is about, then I strongly condemn it being even a subject at all. The current RFC does a pretty good job at defining what a JSON String can be, fabricating some sort of injective function so that one JSON value is equal to another is sick. OK, I say that, but on the other hand, JSON Schema mandates that JSON values "1.0" and "1" be considered equal for numeric validation. This could also be viewed as a form of normalization... --=20 Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From nico@cryptonector.com Tue Feb 19 14:01:20 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0559721E808F; Tue, 19 Feb 2013 14:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=-1.569, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQOVUxPXY-Cq; Tue, 19 Feb 2013 14:01:16 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 00B0121E80B2; Tue, 19 Feb 2013 14:01:11 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 4A4AF2F4060; Tue, 19 Feb 2013 14:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=UYXt5Qle53zlHLK4EABgUfQ5BkI=; b=r7xHOVGz1da E1tNcbJ3bh1NK3AaypAmwhaBbCQay4pNaeee8//fyPLqffihrwq56/hefBlSu2rX D9j6oMSR8uuprMDpUgUdgD0J2H/YTAcKiUUluwzcVR/yQZmoyicWPTQdd90nT2gm phurjTwnHU7CTmbEH2w0m5YQp3mFD0Lg= Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id A3DB12F406A; Tue, 19 Feb 2013 14:01:10 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fm10so5803688wgb.21 for ; Tue, 19 Feb 2013 14:01:09 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.81.42 with SMTP id w10mr18986262wix.28.1361311269349; Tue, 19 Feb 2013 14:01:09 -0800 (PST) Received: by 10.216.254.217 with HTTP; Tue, 19 Feb 2013 14:01:09 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Feb 2013 16:01:09 -0600 Message-ID: From: Nico Williams To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mike Jones , "Matt Miller \(mamille2\)" , Tim Bray , "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:01:20 -0000 On Tue, Feb 19, 2013 at 3:55 PM, Joe Hildebrand (jhildebr) wrote: > On 2/19/13 2:34 PM, "Tim Bray" wrote: > >>re draft-staykov-hu-json-canonical-form: >>Looks sensible. One gripe: Why can=C2=B9t you sign NaN and INF? They do= in >>fact occur in the field, and it=C2=B9s not as though a noncanonical >>representation is possible. > > I can figure out how to generate a -INF, but how do I get a -NaN? In JS? 1/0 -> INF, 0/0 -> NaN. From fgaliegue@gmail.com Tue Feb 19 14:05:15 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046FD21F89A3; Tue, 19 Feb 2013 14:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTH1PPTN1j-Z; Tue, 19 Feb 2013 14:05:14 -0800 (PST) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 825AB21F8815; Tue, 19 Feb 2013 14:05:09 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id b47so3660830eek.15 for ; Tue, 19 Feb 2013 14:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VmMPrUWxsrfSadz5WAqK0wpjSPpMA1JMlS81TlqR5/A=; b=fDrsKXz9oJ6kgjsOzt6/REW23pppl50TbMhVExO19b3WLqNEFHFWy2fNQuatJnR/yo hlFmwS2+rDWxU2Dg2kC2LQA0dANtn9tDgPynSq/I2/hMQdAlsCv+65Hidhi16nGxE0Hz AHO/VxsI7jUpDsmkZsveeM4AKrE9ZEv0b7D5NxK5Bu3wdc9zaO+jJzwjcXJRbjK8Oxfo h5AhIEzXsYlbeSgFJrdCZfOxOaCMCL+aTOwhWkDipn9gd8sr9iC8OVBA1b+eGyyFKF/i 5SLgcSafZj6epDiw3XZvqWK7TqFvQ/K9pwr7+QdNa5BUtpz7yiQSmcQjDMnVrZR4KRJh x6Hg== MIME-Version: 1.0 X-Received: by 10.14.183.198 with SMTP id q46mr61937203eem.1.1361311508874; Tue, 19 Feb 2013 14:05:08 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 14:05:08 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Feb 2013 23:05:08 +0100 Message-ID: From: Francis Galiegue To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: Mike Jones , "Matt Miller \(mamille2\)" , Tim Bray , "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:05:15 -0000 On Tue, Feb 19, 2013 at 10:55 PM, Joe Hildebrand (jhildebr) wrote: [...] > > I can figure out how to generate a -INF, but how do I get a -NaN? > The current JSON specification doesn't mandate any limit to the precision and/or scale of numeric instances, and I was particularly attentive to this aspect of JSON when writing the JSON Schema specs, since my first use case for using JSON Schema was the ability to use keywords such as "minimum", "maximum", "multipleOf" to validate arbitrary numerical JSON instances. The JSON Schema validation specs (OK, these are my words) says this: http://tools.ietf.org/html/draft-fge-json-schema-validation-00#section-3.2 I _do believe that JSON itself should not define NaN. JSON can express arbitrary data and should not care about the capabilities of language A or B in a transacation. Only recommendations and/or warnings can be given at that point. -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From nico@cryptonector.com Tue Feb 19 14:07:29 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE9121F886E; Tue, 19 Feb 2013 14:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.81 X-Spam-Level: X-Spam-Status: No, score=-3.81 tagged_above=-999 required=5 tests=[AWL=-1.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zL6eSlkm8CUU; Tue, 19 Feb 2013 14:07:28 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id A38F421F8815; Tue, 19 Feb 2013 14:07:28 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id A6CB56B007B; Tue, 19 Feb 2013 14:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=bEdPwENzm+I+yWoAWYFXxwU1Sf4=; b=jKM0ic5cuQb iZWEKRHjsGtw6JeyTJiZ8AgmT6JQcfH8Z4MqTnb754XKo68f8Fsatr+QGcd6mOVo b6lsiyqWcdumSj/Kxg1BOtdW6PCgbJ5QlD4atajWNn5JQJas59p0M7vu+Sesaoou oWBPvvQNHJAdRr0/jnvf7ZB8ZHGS0gAo= Received: from mail-ia0-f174.google.com (mail-ia0-f174.google.com [209.85.210.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 780F86B0059; Tue, 19 Feb 2013 14:07:27 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id u20so2453537iag.33 for ; Tue, 19 Feb 2013 14:07:26 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.43.62.12 with SMTP id wy12mr8278870icb.19.1361311646933; Tue, 19 Feb 2013 14:07:26 -0800 (PST) Received: by 10.64.102.201 with HTTP; Tue, 19 Feb 2013 14:07:26 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 16:07:26 -0600 Message-ID: From: Nico Williams To: Francis Galiegue Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Tim Bray , "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:07:29 -0000 On Tue, Feb 19, 2013 at 4:00 PM, Francis Galiegue wro= te: > On Tue, Feb 19, 2013 at 10:53 PM, Tim Bray wrote: >> I would argue that normalization should be out of scope. I.e. the two f= orms >> of =E2=80=9Cfo=C3=B3=E2=80=9D are different strings, that=E2=80=99s all. >> =E2=80=9CDoctor! It hurts when I do this!=E2=80=9D >> =E2=80=9CSo, don=E2=80=99t do that!=E2=80=9D >> > > (as a not very well educated individual on this matter...) > > If _that_ is what normalization is about, then I strongly condemn it > being even a subject at all. > > The current RFC does a pretty good job at defining what a JSON String > can be, fabricating some sort of injective function so that one JSON > value is equal to another is sick. Oh, well, the RFC (4627) says nothing about normalization. And if you think the notion is sick wait till you hear the details! But as you read what you find when you search for "Unicode normalization" you should keep one thing in mind: this sickness isn't Unicode's fault -- it's our (humans', that is) fault. > OK, I say that, but on the other hand, JSON Schema mandates that JSON > values "1.0" and "1" be considered equal for numeric validation. This > could also be viewed as a form of normalization... Indeed. Nico -- From mamille2@cisco.com Tue Feb 19 14:08:27 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B03521F842A for ; Tue, 19 Feb 2013 14:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZIz72yw4ZpC for ; Tue, 19 Feb 2013 14:08:07 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id EDCF621F8815 for ; Tue, 19 Feb 2013 14:08:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1413; q=dns/txt; s=iport; t=1361311687; x=1362521287; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zswmIll5B7z5WjvctxPoQ6+l9JLRv3QvipuvflnRQPo=; b=YCwGPGcx5fgkGOXr3TcZ35xVPs8oaUZMaEOjSh1eZRFd1os4ExyOhZHP EthiS4KHPQZxHxEu2lOWdFPwW/aTv5rTfrXz0WFpQkzdVO9yszR5kWRnD VRNFd96XCFjjDzHH1t5QNa1FGgL58nynnKcxrl6lWPT9LMDKGlKt5uy0h M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALr2I1GtJV2d/2dsb2JhbABFwEKBDRZzgh8BAQEDAW4LBQsCAQgOCgokIRElAgQOBQiHeAMJBrAvhkENiVqMN4IkAjEHgl9hA5RQjR6FFYMHgWskGA X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178908471" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 19 Feb 2013 22:08:06 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1JM86g7023337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 22:08:06 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 16:08:06 -0600 From: "Matt Miller (mamille2)" To: Francis Galiegue Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODuyeaWrVXZbFS02Fp/sYLgqW+5iCIeqA Date: Tue, 19 Feb 2013 22:08:05 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.55] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Nico Williams , Tim Bray , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:08:27 -0000 [Thank you Paul; removing apps-discuss@] On Feb 19, 2013, at 3:00 PM, Francis Galiegue wrote: > On Tue, Feb 19, 2013 at 10:53 PM, Tim Bray wrote: >> I would argue that normalization should be out of scope. I.e. the two f= orms >> of =93fo=F3=94 are different strings, that=92s all. >> =93Doctor! It hurts when I do this!=94 >> =93So, don=92t do that!=94 >>=20 >=20 > (as a not very well educated individual on this matter...) >=20 > If _that_ is what normalization is about, then I strongly condemn it > being even a subject at all. >=20 > The current RFC does a pretty good job at defining what a JSON String > can be, fabricating some sort of injective function so that one JSON > value is equal to another is sick. >=20 > OK, I say that, but on the other hand, JSON Schema mandates that JSON > values "1.0" and "1" be considered equal for numeric validation. This > could also be viewed as a form of normalization... >=20 And furthermore, "fo=F3" versus "\u0066\u006f\u00f3" (or "\u0066\u006f\u006= f\u00b4"?). I think most of us clearly think the former is better than the= latter, but it does need to be called out. I also do think some level of discussion on unicode normalization, even if = the result is "this is out-of-scope," needs to take place. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. From jhildebr@cisco.com Tue Feb 19 14:18:19 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBF221F87B9; Tue, 19 Feb 2013 14:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhdtVEGIKWxK; Tue, 19 Feb 2013 14:18:18 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DCD0621F86EC; Tue, 19 Feb 2013 14:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=299; q=dns/txt; s=iport; t=1361312298; x=1362521898; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=zA1IV8T/1lkeyUo/0P189ZZHkbTZD/2Bp0xJCYbBoy8=; b=lcZvml3RHf8NN6vmBdwOcTEm5a/9xZckSEiT4cortLtTOFQw47ePr2XU j7+EenLTIvIFjegr8oAZlOCrvD5PizQkxzg7wCZ2oJYn8mwJ3pEAMuxRo FpCiCurTbLDv+FHErNFiNUG7Ixu3MYvdKoEH6fEUlvOqaGx2/iHXiiQ41 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAFL4I1GtJXG9/2dsb2JhbABFhgK6QIENFnOCIQEEOjQLEgEIIhRCJQIEAQ0FCIgKsDGQJY5dMQeCX2EDpwODB4In X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178907984" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 19 Feb 2013 22:18:15 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1JMIFgE028055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 22:18:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 16:18:15 -0600 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman , "apps-discuss@ietf.org Discuss" Thread-Topic: [apps-discuss] Two lists? [ Was: JSON mailing list and BoF ] Thread-Index: AQHODux01Q87ih+JTEmWhe6ECK8cy5iBr2eA Date: Tue, 19 Feb 2013 22:18:14 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <43ABB84C2B6F5D42A04219BF79E0AB90@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] [apps-discuss] Two lists? [ Was: JSON mailing list and BoF ] X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:18:19 -0000 On 2/19/13 2:59 PM, "Paul Hoffman" wrote: >The JSON list seems active already. Do we need to have this thread on >both lists? Nope. After this message, I'll start pruning and re-directing, since I think we've got a quorum on the json list. --=20 Joe Hildebrand From jhildebr@cisco.com Tue Feb 19 14:19:48 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAB221F88B9 for ; Tue, 19 Feb 2013 14:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbePVFnIysJT for ; Tue, 19 Feb 2013 14:19:48 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 10F6121F8860 for ; Tue, 19 Feb 2013 14:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=250; q=dns/txt; s=iport; t=1361312388; x=1362521988; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=boJ6ccPyXQeYV97SXZx/DjINtnLxvyJWAz7+1obzDUI=; b=IPcTffuAnG8Ko7pqXv5dAwhzA12r4LnyIIvx2lMFnfAq48rJD1FeSgef WuHXx1Sjm21xRS2U4IsQPvq/9/JWhQy/tnwrsDaTSC8qSw/CVoHxZ9GFr oTfb9O3yl2/T1mW95Ku+Q/E2atnYfLfJWJuIOPj3VWwP0uwgzYYMVrtwn Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIFAEv5I1GtJXG9/2dsb2JhbABFhgK6QIENFnOCHwEBAQMBJxM0CxIBCCIUQiUCBA4FCIgEBrAwkCWOXTEHgl9hA6cDgweCJw X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178885863" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 19 Feb 2013 22:19:47 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1JMJlon029589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 22:19:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 16:19:47 -0600 From: "Joe Hildebrand (jhildebr)" To: Nico Williams Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piCCRiA//+eqLD///s2AIAAd14A//+Qc4AADtz1gP//j9gA Date: Tue, 19 Feb 2013 22:19:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mike Jones , "Matt Miller \(mamille2\)" , Tim Bray , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:19:48 -0000 On 2/19/13 3:01 PM, "Nico Williams" wrote: >> I can figure out how to generate a -INF, but how do I get a -NaN? > >In JS? =20 Yes. >1/0 -> INF, 0/0 -> NaN. -1/0 -> -Infinity ? -> -Nan? --=20 Joe Hildebrand From fgaliegue@gmail.com Tue Feb 19 14:20:12 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE8321F88BC; Tue, 19 Feb 2013 14:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuaCHwbuNoEl; Tue, 19 Feb 2013 14:20:11 -0800 (PST) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB2821F8860; Tue, 19 Feb 2013 14:20:11 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id a13so3072123eaa.7 for ; Tue, 19 Feb 2013 14:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=biFVXEYynVlzkyxybflbdPYzP34rC82Vi0NBWr/vygo=; b=eaueSO40OasDQC+3svhOVHv1kayOq3jWQmRe3zahF8XSFxz/o6k1UgQ5ERBTfpzuAl bhBGCjjszWWtlGVpYfbXLFRecn7ATclQgBBxojFm2tvyn5bji1ZlNOHpq5+TfjopOXHf zzGZeA52RtC80uiLfH49f61hlBA/R8Zd6xohC6Q9fXCLdg8XNzHoBzgZ2u/DgyvUHkaA W0XhlMMl9tLXJ8xiWr+8qZeZqvK1TOK02PckTgmLorA1k/TtKq/ara3rXfOh2vaUuPRR /ngyYWZeNSwDa/VAGh2MAOCKOGylZTVH7W3yxIQc/1AYpP69cD7ijVdJnB2UPR7CD9KJ Szfw== MIME-Version: 1.0 X-Received: by 10.14.209.131 with SMTP id s3mr61292462eeo.26.1361312410625; Tue, 19 Feb 2013 14:20:10 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 14:20:10 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 23:20:10 +0100 Message-ID: From: Francis Galiegue To: Nico Williams Content-Type: text/plain; charset=UTF-8 Cc: Tim Bray , "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:20:12 -0000 On Tue, Feb 19, 2013 at 11:07 PM, Nico Williams wrote: [...] > >> OK, I say that, but on the other hand, JSON Schema mandates that JSON >> values "1.0" and "1" be considered equal for numeric validation. This >> could also be viewed as a form of normalization... > > Indeed. > Note however that JSON Schema is not the only I-D in that case. JSON Patch says this too (http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10#section-4.6). -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From tbray@textuality.com Tue Feb 19 14:20:30 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198BD21F896B for ; Tue, 19 Feb 2013 14:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrcDik30Lzys for ; Tue, 19 Feb 2013 14:20:29 -0800 (PST) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id B010121F8951 for ; Tue, 19 Feb 2013 14:20:28 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id kp6so3623238pab.8 for ; Tue, 19 Feb 2013 14:20:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Mk78B9xv5G96tmg/oDYnMLLsyblEMGJyd5CiAhM81GQ=; b=bA7n7IWnHPE1jyPB9ndcc5P8L6wqrumQFoih79S5sRV4LesTFsBVLqabLbIXTcptK4 RXpcusUBoPeJu0m64CUMRasJowiFUfKgxnzsQp2i47hrRYQE8AWY/3VsM7yfoMrG6O1b jbT2HSxd5YKXAI/AtSg9sRmZfo3cxkA5xwa6Dq5/YKpw4E/R0s+er3YnudYLsvY618V/ ghbQfVu/JHbuczuVOqBbh/YMm8ubRR1wD9umEBXMqQxmTekIr89Xa8J7I6A7cinIwBlH me/CA2AZSKIwtvxNnz40mzwP0hMrOauMoETMfh20Sxi4lnIICTwRVe9PAG/ZY5IjkE+8 kl0g== MIME-Version: 1.0 X-Received: by 10.66.27.241 with SMTP id w17mr25976537pag.59.1361312420510; Tue, 19 Feb 2013 14:20:20 -0800 (PST) Received: by 10.66.249.129 with HTTP; Tue, 19 Feb 2013 14:20:20 -0800 (PST) X-Originating-IP: [172.29.161.33] In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 14:20:20 -0800 Message-ID: From: Tim Bray To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=bcaec529982740bb3204d61b3f2a X-Gm-Message-State: ALoCoQlzBF7Y90fHK+pRRuzypMO9QrcT2tKkwR88F8oHw1Q+B50Ku3XGkTv0Z/AKUP3aG6cqSZ7E Cc: Mike Jones , "json@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:20:30 -0000 --bcaec529982740bb3204d61b3f2a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Oops, I was wrong, NaN & INF aren=92t in JSON. D=92oh. -T On Tue, Feb 19, 2013 at 1:34 PM, Tim Bray wrote: > re draft-staykov-hu-json-canonical-form: > Looks sensible. One gripe: Why can=92t you sign NaN and INF? They do in > fact occur in the field, and it=92s not as though a noncanonical > representation is possible. > > -T (who still hasn=92t decided if this is actually a good idea) > > > On Tue, Feb 19, 2013 at 1:27 PM, Joe Hildebrand (jhildebr) < > jhildebr@cisco.com> wrote: > >> On 2/19/13 1:47 PM, "Mike Jones" wrote: >> >> >I'm strongly against canonicalization. The XML canonicalization >> >experience was horrible and resulted in more interop bugs than any othe= r >> >aspect of XML DSIG, XML ENC, etc. Let's not repeat the mistakes of our >> >elders. ;-) >> > >> >I also haven't seen a clear use case that canonicalization solves that >> >can't be more easily solved another way. >> >> I somewhat agree, but have you at least read >> draft-staykov-hu-json-canonical-form? It's pretty straightforward, and >> nowhere near as scary as xmlenc. >> >> -- >> Joe Hildebrand >> >> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > --bcaec529982740bb3204d61b3f2a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Oops, I was wrong, NaN & INF aren=92t in JSON.=A0 D=92= oh.=A0 -T


On Tue, Feb 19, 2013 at 1:34 PM, Tim Bray <tbray@textuality.com> wrote:
re draft-staykov-hu-json-ca= nonical-form:
Looks sensible. One gripe:=A0 Why can=92t you sign NaN an= d INF?=A0 They do in fact=A0 occur in the field, and it=92s not as though a= noncanonical representation is possible.=A0

-T (who still hasn=92t decided if this is actually a good idea)

On Tue, Feb 19, 2013 at 1:27 PM, Joe Hildebran= d (jhildebr) <jhildebr@cisco.com> wrote:
On 2/19/13 1:47 PM, "Mike Jones&qu= ot; <Mi= chael.Jones@microsoft.com> wrote:

>I'm strongly against canonicalization. =A0The XML canonicalization<= br> >experience was horrible and resulted in more interop bugs than any othe= r
>aspect of XML DSIG, XML ENC, etc. =A0Let's not repeat the mistakes = of our
>elders. ;-)
>
>I also haven't seen a clear use case that canonicalization solves t= hat
>can't be more easily solved another way.

I somewhat agree, but have you at least read
draft-staykov-hu-json-canonical-form? =A0It's pretty straightforward, a= nd
nowhere near as scary as xmlenc.

--
Joe Hildebrand



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


--bcaec529982740bb3204d61b3f2a-- From jhildebr@cisco.com Tue Feb 19 14:24:00 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884A121F88C7 for ; Tue, 19 Feb 2013 14:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pB40-PHoZS28 for ; Tue, 19 Feb 2013 14:23:54 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BC66421F8A6F for ; Tue, 19 Feb 2013 14:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1573; q=dns/txt; s=iport; t=1361312632; x=1362522232; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ahDDGcR9bYoKcumiOuZdm/xkvqWTyk4ZnedQ86pjW3I=; b=J8wOkpFQCxRzr5ANi0kT8Mi1lBb5McXwnr26RktQ8P+gXPpERfhj7/Do uhcZbe/O7mLX8RuHpnf3bbcTWK2Mqa/sy1GfFjlURvf4qKC7HyusDlVcg tSXO8hmlPpENIfjrYask67NpfIhb/w9zC3n6QrZK+VQ0Mru6iaLVHCtit 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAO75I1GtJXHB/2dsb2JhbABFwEKBDRZzgh8BAQEEAQEBawsSAQgOCgpLCyUCBA4FCIgKDLAlkCEEjU2BEDEHgl9hA4gwnlODB4FyNQ X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178940938" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 19 Feb 2013 22:23:51 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1JMNpGH006651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 22:23:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 16:23:50 -0600 From: "Joe Hildebrand (jhildebr)" To: Tim Bray Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piCCRiA//+eqLD///s2AIAAd14AgAAMtgD//4uegA== Date: Tue, 19 Feb 2013 22:23:49 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <758524F6843CCB46B916FEE8073B3D00@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mike Jones , "json@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:24:00 -0000 And reading your mail more carefully, I thought "sign" here meant +/-, which is why that other part of this thread is down in the weeds. On 2/19/13 3:20 PM, "Tim Bray" wrote: >Oops, I was wrong, NaN & INF aren=B9t in JSON. D=B9oh. -T > >On Tue, Feb 19, 2013 at 1:34 PM, Tim Bray > wrote: > >re draft-staykov-hu-json-canonical-form: >Looks sensible. One gripe: Why can=B9t you sign NaN and INF? They do in >fact occur in the field, and it=B9s not as though a noncanonical >representation is possible. > > >-T (who still hasn=B9t decided if this is actually a good idea) > > > >On Tue, Feb 19, 2013 at 1:27 PM, Joe Hildebrand (jhildebr) > wrote: > >On 2/19/13 1:47 PM, "Mike Jones" wrote: > >>I'm strongly against canonicalization. The XML canonicalization >>experience was horrible and resulted in more interop bugs than any other >>aspect of XML DSIG, XML ENC, etc. Let's not repeat the mistakes of our >>elders. ;-) >> >>I also haven't seen a clear use case that canonicalization solves that >>can't be more easily solved another way. > > >I somewhat agree, but have you at least read >draft-staykov-hu-json-canonical-form? It's pretty straightforward, and >nowhere near as scary as xmlenc. > >-- >Joe Hildebrand > > > >_______________________________________________ >json mailing list >json@ietf.org >https://www.ietf.org/mailman/listinfo/json > > > > > > > > > > > > > > > --=20 Joe Hildebrand From tbray@textuality.com Tue Feb 19 14:24:00 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAAA21F896B for ; Tue, 19 Feb 2013 14:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inQ8m7jFLyQb for ; Tue, 19 Feb 2013 14:23:54 -0800 (PST) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id A9F6921F89AE for ; Tue, 19 Feb 2013 14:23:52 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id hz10so3605179pad.35 for ; Tue, 19 Feb 2013 14:23:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=P4elsQn6qpbXJp0o8qu/UKwHq5miZc1JdjwLXssSBvI=; b=YFc27tRTmw4gIsohQllggwxjVjSOodJOcSb9CXfufC7nkatBhMgHE3PMFm8HMgdMKX R+YBJSyHA6HY/WfgnnyAD/K0UENFcX7lqRrm/IIdjlbFm8tEdFd7Bhs8CMxrS8QQXXh6 VqDNNAHK3IFoXVYOfVmAEcIxaMHFQ4hhYUnKt23O3CRDAQpwO7y9SCzmiBN0BP18iG/f WzQ194D+r4EU5Wz0gaKde+3waMUqZDw8dMFndTqz0lOoh6Bd0mHgOY8rUe68D+hgTfhb hySXkAJfFIuXlKX5qkssvAM6yIFY38CJflNt1HtWvE+yNRK1xopxqRqmR8m/gtk74I6N DZTw== MIME-Version: 1.0 X-Received: by 10.66.52.79 with SMTP id r15mr49614216pao.46.1361312632015; Tue, 19 Feb 2013 14:23:52 -0800 (PST) Received: by 10.66.249.129 with HTTP; Tue, 19 Feb 2013 14:23:51 -0800 (PST) X-Originating-IP: [172.29.161.33] In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 14:23:51 -0800 Message-ID: From: Tim Bray To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=bcaec543094cdc0c6104d61b4b21 X-Gm-Message-State: ALoCoQmVtTVj1p468y5xi30jbCskcf+++ASuDzKoSww6hfOH5CDCXCKwl1W7gCDlV5dYvq5u5DoC Cc: Francis Galiegue , "json@ietf.org" , Nico Williams Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:24:00 -0000 --bcaec543094cdc0c6104d61b4b21 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Options for \uxxxx - forbid it - argue that comparisons MUST be Unicode-codepoint by Unicode-codepoint, and specify that \uxxxx specifies a single codepoint Latter is probably better. -T On Tue, Feb 19, 2013 at 2:08 PM, Matt Miller (mamille2) wrote: > [Thank you Paul; removing apps-discuss@] > > On Feb 19, 2013, at 3:00 PM, Francis Galiegue > wrote: > > > On Tue, Feb 19, 2013 at 10:53 PM, Tim Bray wrote= : > >> I would argue that normalization should be out of scope. I.e. the two > forms > >> of =93fo=F3=94 are different strings, that=92s all. > >> =93Doctor! It hurts when I do this!=94 > >> =93So, don=92t do that!=94 > >> > > > > (as a not very well educated individual on this matter...) > > > > If _that_ is what normalization is about, then I strongly condemn it > > being even a subject at all. > > > > The current RFC does a pretty good job at defining what a JSON String > > can be, fabricating some sort of injective function so that one JSON > > value is equal to another is sick. > > > > OK, I say that, but on the other hand, JSON Schema mandates that JSON > > values "1.0" and "1" be considered equal for numeric validation. This > > could also be viewed as a form of normalization... > > > > And furthermore, "fo=F3" versus "\u0066\u006f\u00f3" (or > "\u0066\u006f\u006f\u00b4"?). I think most of us clearly think the forme= r > is better than the latter, but it does need to be called out. > > I also do think some level of discussion on unicode normalization, even i= f > the result is "this is out-of-scope," needs to take place. > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > --bcaec543094cdc0c6104d61b4b21 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Options for \uxxxx
- forbid it
- argue that comparisons MUST be Unicode-codepoint by Unicode-codepoint, = and specify that \uxxxx specifies a single codepoint

Latter is proba= bly better. -T


On Tue,= Feb 19, 2013 at 2:08 PM, Matt Miller (mamille2) <mamille2@cisco.com&= gt; wrote:
[Thank you Paul; removing apps-discuss@]

On Feb 19, 2013, at 3:00 PM, Francis Galiegue <fgaliegue@gmail.com>
=A0wrote:

> On Tue, Feb 19, 2013 at 10:53 PM, Tim Bray <tbray@textuality.com> wrote:
>> I would argue that normalization should be out of scope. =A0I.e. t= he two forms
>> of =93fo=F3=94 are different strings, that=92s all.
>> =93Doctor! It hurts when I do this!=94
>> =93So, don=92t do that!=94
>>
>
> (as a not very well educated individual on this matter...)
>
> If _that_ is what normalization is about, then I strongly condemn it > being even a subject at all.
>
> The current RFC does a pretty good job at defining what a JSON String<= br> > can be, fabricating some sort of injective function so that one JSON > value is equal to another is sick.
>
> OK, I say that, but on the other hand, JSON Schema mandates that JSON<= br> > values "1.0" and "1" be considered equal for numer= ic validation. This
> could also be viewed as a form of normalization...
>

And furthermore, "fo=F3" versus "\u0066\u006f\u00f3&qu= ot; (or "\u0066\u006f\u006f\u00b4"?). =A0I think most of us clear= ly think the former is better than the latter, but it does need to be calle= d out.

I also do think some level of discussion on unicode normalization, even if = the result is "this is out-of-scope," needs to take place.


- m&m

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


--bcaec543094cdc0c6104d61b4b21-- From fgaliegue@gmail.com Tue Feb 19 14:27:36 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564C621F8AD1 for ; Tue, 19 Feb 2013 14:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BySk+WK0tilK for ; Tue, 19 Feb 2013 14:27:35 -0800 (PST) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id 77CB021F8A99 for ; Tue, 19 Feb 2013 14:27:35 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so3820274eei.21 for ; Tue, 19 Feb 2013 14:27:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gzWN6AkrjgOSeirzEqIbtCu+cDhkGw1KSlKkIqq5aqM=; b=z0hekbH2pnOt4hM9Y3PtON+DDmxhm9ZrTljjmAIJuIo6oFC2oQcBiYqJGa7vECXp10 mO2s0Ss2mpsNgLTRAACigyv48BYGJ+J3rQKZEFmsqux9DoiDTFCk1BT59gUh685VTj3c lBFOG5sbwYZhPtQrdf7fEqhgnAciWOCCEopRjtKLdljGrcIS743cNRWsgeeBuX3iyEq0 TrhX9n44HmbeOVUa96xn6s34AZuTUhLfXH2cHiQRnTnHlRvN3e7wejM4SBjzeJCB0Fi0 PfqwaKQTjlT/ksRcR9fVpz+YP5gxc39KZjpA+RmtjcMJvMj3E1lLl8+5kkxdpaXN6WJ0 7Teg== MIME-Version: 1.0 X-Received: by 10.14.194.198 with SMTP id m46mr61406218een.8.1361312854287; Tue, 19 Feb 2013 14:27:34 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 14:27:34 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 23:27:34 +0100 Message-ID: From: Francis Galiegue To: Tim Bray Content-Type: text/plain; charset=UTF-8 Cc: Nico Williams , "json@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:27:37 -0000 On Tue, Feb 19, 2013 at 11:23 PM, Tim Bray wrote: > Options for \uxxxx > - forbid it > - argue that comparisons MUST be Unicode-codepoint by Unicode-codepoint, and > specify that \uxxxx specifies a single codepoint > > Latter is probably better. -T > imho, option 2 is what "should" happen, but isn't this what is currently enforced already? -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From jhildebr@cisco.com Tue Feb 19 14:29:46 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A0021F8AF8 for ; Tue, 19 Feb 2013 14:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj+0LauQF32r for ; Tue, 19 Feb 2013 14:29:46 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C8A0321F8830 for ; Tue, 19 Feb 2013 14:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1029; q=dns/txt; s=iport; t=1361312985; x=1362522585; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LzwVoMW5e2hJV9AeK57IlBcQtAe7kmE+6w6Ug+LRr2c=; b=L6vOseUIZg0uYEl9T6LIIRC/GPKZ51Dfo/b0aDXQjhyi0NgN3O2HkCm/ 8qH3HSoxSsjxRS8WriMW9mgdD9SEmX5kRxxM9MhcOeJC3QY0qs7cNWADM BbHYR76dWBjeG8RceHWeMMOHJKQtvffTE5REGDREv7Umga0L0do8P0RuD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKX7I1GtJV2a/2dsb2JhbABFwEKBDRZzgiEBBG4LEgEIIlYlAgQBDQUIiAqwOZAojl0xB4JfYQOIMJ5TgweCJw X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="175917064" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 19 Feb 2013 22:29:45 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1JMTjSU016098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 22:29:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 16:29:44 -0600 From: "Joe Hildebrand (jhildebr)" To: "Matt Miller (mamille2)" , Francis Galiegue Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODuyeUCJbUuD1WEmc1GY8/86Ra5iCIeqA//+QsgA= Date: Tue, 19 Feb 2013 22:29:43 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <47AFC4BD63F22041AB49C26D3792B492@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Nico Williams , Tim Bray , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:29:46 -0000 On 2/19/13 3:08 PM, "Matt Miller (mamille2)" wrote: >And furthermore, "fo=F3" versus "\u0066\u006f\u00f3" (or >"\u0066\u006f\u006f\u00b4"?). I think most of us clearly think the >former is better than the latter, but it does need to be called out. > >I also do think some level of discussion on unicode normalization, even >if the result is "this is out-of-scope," needs to take place. One of the things we should also consider adding to the scope of a potential WG is a set of design guidelines for protocols that use JSON. One of those guidelines might be to avoid using human-language text as the keys in an object, for this and other reasons. However, I immediately thought of a counter-example: if you wanted to encode a translation dictionary, you might want to do this: { "Hello": { "en-US": "Howdy" } } It might be awkward to do this instead: [ { "word": "Hello", "translations": { "en-US": "Howdy" } } ] --=20 Joe Hildebrand From jhildebr@cisco.com Tue Feb 19 14:31:50 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC4A21F8830 for ; Tue, 19 Feb 2013 14:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf6mrS0zBVEy for ; Tue, 19 Feb 2013 14:31:50 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4925321F882C for ; Tue, 19 Feb 2013 14:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1887; q=dns/txt; s=iport; t=1361313110; x=1362522710; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=s8/R0veNB3uqogd3R9aXkA8VEFn9At3GWVdy/qofNPc=; b=DamSEZgbx1FuQt60nF2PQkzHioT9kD7tRzohVVdz4yIQ86IlbrETbyfz Zk7FcuUGJPsVPM7BGmHBPymH/nDruKW7N4W4ubhPfGJCXDfipK1g5aoMP NW4tezvoIjxKnJsms+Yo37xSfSn2RkM+b9ZufE+K/uQUunU3bb6BopUJ6 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFz8I1GtJXG//2dsb2JhbABFwEKBDRZzgh8BAQEEbgsSAQgOCgpFESUCBAENBQiHeAMPsDqGQQ2JWow3giYxB4JfYQOIMIwgjR6FFYMHgWskGA X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178914641" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 19 Feb 2013 22:31:49 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1JMVnRj002850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 22:31:49 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 16:31:49 -0600 From: "Joe Hildebrand (jhildebr)" To: Tim Bray , "Matt Miller (mamille2)" Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODu/VV0zn7u2LJ02Uk/kU6xbmZ5iBsyqA Date: Tue, 19 Feb 2013 22:31:48 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Francis Galiegue , Nico Williams , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:31:50 -0000 \u0000 is an exception. On 2/19/13 3:23 PM, "Tim Bray" wrote: >Options for \uxxxx > >- forbid it=20 > >- argue that comparisons MUST be Unicode-codepoint by Unicode-codepoint, >and specify that \uxxxx specifies a single codepoint > >Latter is probably better. -T > > > >On Tue, Feb 19, 2013 at 2:08 PM, Matt Miller (mamille2) > wrote: > >[Thank you Paul; removing apps-discuss@] > >On Feb 19, 2013, at 3:00 PM, Francis Galiegue > wrote: > >> On Tue, Feb 19, 2013 at 10:53 PM, Tim Bray wrote: >>> I would argue that normalization should be out of scope. I.e. the two >>>forms >>> of =B3fo=F3=B2 are different strings, that=B9s all. >>> =B3Doctor! It hurts when I do this!=B2 >>> =B3So, don=B9t do that!=B2 >>> >> >> (as a not very well educated individual on this matter...) >> >> If _that_ is what normalization is about, then I strongly condemn it >> being even a subject at all. >> >> The current RFC does a pretty good job at defining what a JSON String >> can be, fabricating some sort of injective function so that one JSON >> value is equal to another is sick. >> >> OK, I say that, but on the other hand, JSON Schema mandates that JSON >> values "1.0" and "1" be considered equal for numeric validation. This >> could also be viewed as a form of normalization... >> > > >And furthermore, "fo=F3" versus "\u0066\u006f\u00f3" (or >"\u0066\u006f\u006f\u00b4"?). I think most of us clearly think the >former is better than the latter, but it does need to be called out. > >I also do think some level of discussion on unicode normalization, even >if the result is "this is out-of-scope," needs to take place. > > >- m&m > >Matt Miller < mamille2@cisco.com > >Cisco Systems, Inc. > > > > > > > > > --=20 Joe Hildebrand From mamille2@cisco.com Tue Feb 19 14:32:24 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9990A21F8830 for ; Tue, 19 Feb 2013 14:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttZMt01UgXWC for ; Tue, 19 Feb 2013 14:32:20 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2E021F882C for ; Tue, 19 Feb 2013 14:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2519; q=dns/txt; s=iport; t=1361313140; x=1362522740; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+WpzzbtEWXhx5ABeCCiscbqLjNJF6lm8YUSkymhbD3I=; b=NCKN+1h8MBbi51K9+si91NlLKMc9EQ7Jabs3P6OM4HkMysPKxHtDQOJF 0bCfqBqRCPifeNyP/GyqIO/BlHp01Quf7SIUjuJKr/pjHC5Jr7oKzFf3R U8grc6HWM5YSgjZytjuMsLLjU1hKjvQig2+E8zjw6PF7Qa43+swzoyetW Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKX7I1GtJXG9/2dsb2JhbABFwEKBDRZzgh8BAQEDAQEBAWsLBQsCAQgOCgokIQYLJQIEDgUIh3gDCQYMsC2GQQ2JVgSMN4EQgRQCMQeCX2EDlFCNHoUVgweBaQIeBhg X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178910565" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 19 Feb 2013 22:32:19 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1JMWJCJ011295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 22:32:19 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 16:32:19 -0600 From: "Matt Miller (mamille2)" To: Tim Bray Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODu/V5YssxwUVfUeUjv2Nmoh4G5iCKKmA Date: Tue, 19 Feb 2013 22:32:18 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.55] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Francis Galiegue , Nico Williams , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:32:24 -0000 On Feb 19, 2013, at 3:23 PM, Tim Bray wrote: > Options for \uxxxx > - forbid it > - argue that comparisons MUST be Unicode-codepoint by Unicode-codepoint, > and specify that \uxxxx specifies a single codepoint >=20 > Latter is probably better. -T Assuming that canonicalization is as much about what's on the wire as what = is logically, I don't think the latter is enough. However, the former might be acceptable with some *very* limited exceptions= : * NULL (\u0000) * QUOTE (\u0022) * REVERSE SOLIDUS (\u005c") There's probably a couple of others that have to be there, but I think that= list is rather short. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. >=20 >=20 > On Tue, Feb 19, 2013 at 2:08 PM, Matt Miller (mamille2) > wrote: >=20 >> [Thank you Paul; removing apps-discuss@] >>=20 >> On Feb 19, 2013, at 3:00 PM, Francis Galiegue >> wrote: >>=20 >>> On Tue, Feb 19, 2013 at 10:53 PM, Tim Bray wrote= : >>>> I would argue that normalization should be out of scope. I.e. the two >> forms >>>> of =93fo=F3=94 are different strings, that=92s all. >>>> =93Doctor! It hurts when I do this!=94 >>>> =93So, don=92t do that!=94 >>>>=20 >>>=20 >>> (as a not very well educated individual on this matter...) >>>=20 >>> If _that_ is what normalization is about, then I strongly condemn it >>> being even a subject at all. >>>=20 >>> The current RFC does a pretty good job at defining what a JSON String >>> can be, fabricating some sort of injective function so that one JSON >>> value is equal to another is sick. >>>=20 >>> OK, I say that, but on the other hand, JSON Schema mandates that JSON >>> values "1.0" and "1" be considered equal for numeric validation. This >>> could also be viewed as a form of normalization... >>>=20 >>=20 >> And furthermore, "fo=F3" versus "\u0066\u006f\u00f3" (or >> "\u0066\u006f\u006f\u00b4"?). I think most of us clearly think the form= er >> is better than the latter, but it does need to be called out. >>=20 >> I also do think some level of discussion on unicode normalization, even = if >> the result is "this is out-of-scope," needs to take place. >>=20 >>=20 >> - m&m >>=20 >> Matt Miller < mamille2@cisco.com > >> Cisco Systems, Inc. >>=20 >>=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From fgaliegue@gmail.com Tue Feb 19 14:39:05 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B81621F89AE for ; Tue, 19 Feb 2013 14:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKIPFhoaMC0v for ; Tue, 19 Feb 2013 14:39:03 -0800 (PST) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1316721F896B for ; Tue, 19 Feb 2013 14:39:02 -0800 (PST) Received: by mail-ea0-f179.google.com with SMTP id d12so3078679eaa.10 for ; Tue, 19 Feb 2013 14:39:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DuoDFtIYCQJ32KT72AkgNyHFT2e5/DTebdNmHGXyaec=; b=aAVx0+m9Y3sfFUNZ2vav9PJ6y75jeko86yRWpTokSSvcTDGLJyXNxn5nQwAnt5JxkG 5hYUKDuUjSbqYWdQOapAd3Uw5+slEn7CFJFtYXYue5FMRGEUCQZGTWs+6926gygjdSia 2KPdlEYFEwnrtKDk1tu5bt0cbhMOxqY7To395FlYJEPG5U16EP+hdf2/UyvcR1Y/dajX LFmmcaZyobAH9IXsNxv2eX8io7kj6sp2DHc0krECsGHifL8aYD/xejk4xDTiC6h2zMq2 pdYKkYrNDDXnSfT9BxYGsPc1kmDzhWqD0XF+qAznR0/V4Pmkq0ncybSqu1sarfMVdenx T5Iw== MIME-Version: 1.0 X-Received: by 10.14.179.5 with SMTP id g5mr61778022eem.41.1361313541889; Tue, 19 Feb 2013 14:39:01 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 14:39:01 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Feb 2013 23:39:01 +0100 Message-ID: From: Francis Galiegue To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: Nico Williams , "json@ietf.org" , Tim Bray , "Matt Miller \(mamille2\)" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:39:05 -0000 On Tue, Feb 19, 2013 at 11:31 PM, Joe Hildebrand (jhildebr) wrote: > \u0000 is an exception. > Why? It is a perfectly legal Unicode code point... -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From tbray@textuality.com Tue Feb 19 14:40:43 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24FD021F89AE for ; Tue, 19 Feb 2013 14:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuBZscR5SjFa for ; Tue, 19 Feb 2013 14:40:42 -0800 (PST) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 24C4721F89A3 for ; Tue, 19 Feb 2013 14:40:42 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id m1so6355072ves.36 for ; Tue, 19 Feb 2013 14:40:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=5gTSDoYC9hsAEblVKJwx0sn0dhwUOGMr70JbOXTyHGY=; b=dkJhpWJa97FAOqfrlYOmMWo6OPXQJiLEtxINVST9chpa7SIAht4o+sObehVwThORIg O6VCPOh4/jSd9Wc1clDzgLS+76D8l8goUistVoOyynvzkdVLFRxjn4ZZTcCULzRbd3QC j2bDOWfzvc9/JWjBfu/rz2d9zulJjaDczMRRfoMiQJS47Mq9Joc7/RIQNUTdDwdI6EMO MzvGAoksNFflxtlRXOX24tQCsijEWDzNQzpR3R/h3aBdYW1ffQC5k95co4IdHJWSjCn3 n1c6iKmS+7zFR1hk6mYIbWfuWhb6K1TRGF9byS3SmMKUkq+c13U0PQhKstX3BjLVNDq3 fosw== MIME-Version: 1.0 X-Received: by 10.52.73.73 with SMTP id j9mr19876964vdv.124.1361313641353; Tue, 19 Feb 2013 14:40:41 -0800 (PST) Received: by 10.220.164.74 with HTTP; Tue, 19 Feb 2013 14:40:41 -0800 (PST) X-Originating-IP: [172.29.161.33] In-Reply-To: References: Date: Tue, 19 Feb 2013 14:40:41 -0800 Message-ID: From: Tim Bray To: Francis Galiegue Content-Type: multipart/alternative; boundary=bcaec501c5bc0551c504d61b8813 X-Gm-Message-State: ALoCoQkmKqs67WA48OgqU4Aie4WNmBm5f6ugWtkboQlJSgJqYCGlUqqIKBmTnbUtwF9UusWcDJUe Cc: Nico Williams , "json@ietf.org" , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:40:43 -0000 --bcaec501c5bc0551c504d61b8813 Content-Type: text/plain; charset=ISO-8859-1 JSON, unlike XML, does not exclude U+0000 On Tue, Feb 19, 2013 at 2:39 PM, Francis Galiegue wrote: > On Tue, Feb 19, 2013 at 11:31 PM, Joe Hildebrand (jhildebr) > wrote: > > \u0000 is an exception. > > > > Why? It is a perfectly legal Unicode code point... > > -- > Francis Galiegue, fgaliegue@gmail.com > Try out your JSON Schemas: http://json-schema-validator.herokuapp.com > --bcaec501c5bc0551c504d61b8813 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
JSON, unlike XML, does not exclude U+0000


On Tue, Feb 19, 2013= at 2:39 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:=
On Tue, Feb 19, 2013 at 11:31 PM, Joe Hildeb= rand (jhildebr)
<jhildebr@cisco.com> wrote:=
> \u0000 is an exception.
>

Why? It is a perfectly legal Unicode code point...

--
Francis Galiegue, fgaliegue@gmail.co= m
Try out your JSON Schemas: http://json-schema-validator.herokuapp.com

--bcaec501c5bc0551c504d61b8813-- From mamille2@cisco.com Tue Feb 19 14:42:46 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3743C21F89AE for ; Tue, 19 Feb 2013 14:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULOwcZlZ5CBs for ; Tue, 19 Feb 2013 14:42:45 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B438E21F89A3 for ; Tue, 19 Feb 2013 14:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=422; q=dns/txt; s=iport; t=1361313764; x=1362523364; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Y39N6FOLtcorPdgENq57DCOlort4QLP8ooRmj27dAto=; b=jxbIVowK16Ir+boUElWOFnBXxJU9IA3EIJmEdby8O1e02+r6iJbXyvPo biy1cVomTKcP0lDuC8p1MLIHnmIC4PfqEpDgSQ4VA+ytk7dYTnK8YPAQo 7HNgYso3EvgjHU7UGmBXTOgSucjYI1wFanZfCfXZ84vX7KvjRtVXTjT1u E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMFABb/I1GtJXG+/2dsb2JhbABFhgK6QYENFnOCHwEBAQMBOjQLBQsCAQgOCgoUECERJQIEDgUIh3gDCQawOIZBDYlajDeCJjEHgl9hA5RQjR6FFYMHgic X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178917699" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 19 Feb 2013 22:42:44 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1JMgihl015084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 22:42:44 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 16:42:44 -0600 From: "Matt Miller (mamille2)" To: Francis Galiegue Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODu/V5YssxwUVfUeUjv2Nmoh4G5iCKIQAgAACBICAAAEJgA== Date: Tue, 19 Feb 2013 22:42:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.55] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Nico Williams , Tim Bray , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:42:46 -0000 On Feb 19, 2013, at 3:39 PM, Francis Galiegue wrote: > On Tue, Feb 19, 2013 at 11:31 PM, Joe Hildebrand (jhildebr) > wrote: >> \u0000 is an exception. >>=20 >=20 > Why? It is a perfectly legal Unicode code point... He means "\u0000 is an exception to Tim's proposed 'forbid escaping' rule". - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. From fgaliegue@gmail.com Tue Feb 19 14:55:26 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975D621F88EA for ; Tue, 19 Feb 2013 14:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eqkWvAdZc3v for ; Tue, 19 Feb 2013 14:55:26 -0800 (PST) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id A633C21F88E8 for ; Tue, 19 Feb 2013 14:55:25 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id b47so3676852eek.15 for ; Tue, 19 Feb 2013 14:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Z0X1EC3b1oi8N0M4xpl+Mg2ZAnBqD322tbirtBTIFo8=; b=ux6B7Ed5CIjM4uMJFhpn02ggdXMHTViyL6atP9Qo654QTaR1c84dFekOjmFCc1SluY h/cbM0SZjh+8NsqrWHjNRUkZVS8BnqbaKuIfLV6QLQf+adH7rg/gEsHmFJRX/9AuQz2U TzLDu5w4cnM95QHtDqX3i/+ve4xfePzs8av+no2m55neRnkKEcz5l+R/ohu3y6ywckh0 Ixhe/fcTtdAgIkg8a/RSfv36OXlgxSgNLkQ1ybIrkGzutmKxJUOXOtFDLLcDBx1ppRxp UXvTaJNYtpEi8leqBq5vIuxqylR1JG85Ru8/a1ZHDlqTzNvgIiDGl2O9dNpjARQOD4b0 VkDw== MIME-Version: 1.0 X-Received: by 10.14.175.129 with SMTP id z1mr62304265eel.7.1361314524889; Tue, 19 Feb 2013 14:55:24 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 14:55:24 -0800 (PST) Date: Tue, 19 Feb 2013 23:55:24 +0100 Message-ID: From: Francis Galiegue To: json@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [Json] About JSON equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:55:26 -0000 The subject has been brought, even though somewhat indirectly, in another thread on this list, so here I will give a digest of what JSON Schema came up with. The definition of JSON value equality, as defined by the core specification, is as such (link: http://tools.ietf.org/html/draft-zyp-json-schema-04#section-3.6): ---- Two JSON values are said to be equal if and only if: both are nulls; or both are booleans, and have the same value; or both are strings, and have the same value; or both are numbers, and have the same mathematical value; or both are arrays, and: have the same number of items; and items at the same index are equal according to this definition; or both are objects, and: have the same set of property names; and values for a same property name are equal according to this definition. ---- This definition is only lacking for strings. On some other draft which I cannot remember off the top of my head, two JSON String values are to be considered equal if, position wise, their Unicode code points are the same (and THAT INCLUDES \u0000). Now, what is the value of defining equality of two JSON values in the general case (see also my mail about why having to restrict JSON representations to container instances)? Of course, there is also the problem that for numeric instances, some programming languages/parsers cannot guarantee that, since they cannot reliably represent said instances in a reliable manner, but then this is why the validation spec explicitly mentions this: http://tools.ietf.org/html/draft-fge-json-schema-validation-00#section-3.2 About strings and the famous "zero character", this same specification also says: http://tools.ietf.org/html/draft-fge-json-schema-validation-00#section-3.1 Yes, nothing forbids "\u0000" in a JSON string. All this to say, should an equality definition find its place in a potentially revised JSON RFC? Personally, I'm not so sure... -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From fgaliegue@gmail.com Tue Feb 19 15:02:17 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A824721F891D for ; Tue, 19 Feb 2013 15:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbKfqfUNVe+p for ; Tue, 19 Feb 2013 15:02:17 -0800 (PST) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id C219321F8919 for ; Tue, 19 Feb 2013 15:02:16 -0800 (PST) Received: by mail-ee0-f43.google.com with SMTP id c50so3797477eek.2 for ; Tue, 19 Feb 2013 15:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UFzs2lz3V+BaXOiqdb9p/h4UBTZhc9AImaqWwZRMmUo=; b=z8mBRcd2hiP03D6LYUWXL2bSKCo9ZVdJiE40qDFVefiahQHoQ3pzl1MGHvMvRIL/6a f5yhHF906w6pypPsJmt50eB8gPVPOiJwlUbXFV1KdBdEWZ3ibxTSd5mCY257pf0Fner/ 3GE8Xg0xH+k0Lw1NdgZE8W48E5DTEwTjJmpqRfRbBoS/FAX3ry7FJUztWaoKdZENTgoh KYOa4YLSzSka2rgJ3L3Ktie6Vn3sen6lGlFeUAZpd2gzfj24xgTiZervjMEAAzFPFUQm juVIicJyzlUPyUinXVEvOyTST2bwK1Ul+p1iM0CdKqDD+lpsqLWvVeqGAJtYG2hB/lWz 0n0w== MIME-Version: 1.0 X-Received: by 10.14.183.67 with SMTP id p43mr61667787eem.10.1361314936023; Tue, 19 Feb 2013 15:02:16 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 15:02:15 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 00:02:15 +0100 Message-ID: From: Francis Galiegue To: Tim Bray Content-Type: text/plain; charset=UTF-8 Cc: Nico Williams , "json@ietf.org" , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 23:02:17 -0000 On Tue, Feb 19, 2013 at 11:40 PM, Tim Bray wrote: > JSON, unlike XML, does not exclude U+0000 > And is there any valid reason as to why JSON should forbid this particular code point? IMHO, no. Although it will certainly be a _very_ rare code point in real life, I see no valid reason to explicitly disallow it since it _is_ representable, after all. -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From jhildebr@cisco.com Tue Feb 19 15:08:34 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E3721F882A for ; Tue, 19 Feb 2013 15:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90fiLWruwOGy for ; Tue, 19 Feb 2013 15:08:33 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 89BA421F87F6 for ; Tue, 19 Feb 2013 15:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=684; q=dns/txt; s=iport; t=1361315313; x=1362524913; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MPZAXBoEFugPr4RYZ5Qyq7FXlMCS2/xcHYnHEOn+MUw=; b=cr/bJ6PmjxcsvZmywe34Rp/WS5fLOp8Lj1Y8upZ781jnpj3XH1cboCG7 dxo1iUDiFB3Mw8Oqxrtl9W5vQp4O+B9w4wdmz/iGTIG7EPrlaIPqeY0M7 x00EzccLnizK6lciet/5/7UNwa56WLnZhb8ppCZWRsgZg+pMg+87Y603D s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIFAEwFJFGtJXG//2dsb2JhbABFhgK6QoENFnOCHwEBAQQ6NAsSAQgYChQxESUCBAENBQiHeAMPsDuGQA2JWow3giYxB4JfYQOUUI0ehRWDB4In X-IronPort-AV: E=Sophos;i="4.84,698,1355097600"; d="scan'208";a="178965489" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 19 Feb 2013 23:08:33 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1JN8XSc029753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 23:08:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 17:08:32 -0600 From: "Joe Hildebrand (jhildebr)" To: "Matt Miller (mamille2)" , Francis Galiegue Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODu/VV0zn7u2LJ02Uk/kU6xbmZ5iBsyqAgAB3XoCAAAEJgP//kdsA Date: Tue, 19 Feb 2013 23:08:32 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Nico Williams , Tim Bray , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 23:08:34 -0000 On 2/19/13 3:42 PM, "Matt Miller (mamille2)" wrote: >On Feb 19, 2013, at 3:39 PM, Francis Galiegue > wrote: > >> On Tue, Feb 19, 2013 at 11:31 PM, Joe Hildebrand (jhildebr) >> wrote: >>> \u0000 is an exception. >>>=20 >>=20 >> Why? It is a perfectly legal Unicode code point... > > >He means "\u0000 is an exception to Tim's proposed 'forbid escaping' >rule". Exactly. It's the only code point that I know of that MUST be escaped using \uxxxx notation when serialized (either canonically or otherwise). All of the other codepoints that need to be escaped have \x versions. --=20 Joe Hildebrand From jhildebr@cisco.com Tue Feb 19 15:10:20 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1622A21F89B2 for ; Tue, 19 Feb 2013 15:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0QWCMC+DABC for ; Tue, 19 Feb 2013 15:10:18 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 975B221F8A33 for ; Tue, 19 Feb 2013 15:10:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2708; q=dns/txt; s=iport; t=1361315418; x=1362525018; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=vHshpDFXWPo6QZlr+d6InoDPDpB17cYOuJl1GIQq51g=; b=DsUavTmSHpNbTkiwJxq6pKUNwytN2z3P7kkoD7qnjmYVgLwFAjVS4HfC pbSy52VHcTBhL++v8QgtfVGWdD6s1VJwqiQzxSfZRONh5xwCF9VZhnumo HDInc85YeEuv5fnYlxqJ6aJ9Oiz+7ySPP8CeGUJaQR8L3k/qtD5lwGGAB I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPwEJFGtJXG9/2dsb2JhbABFwESBDRZzgiEBBAEBATc0HQEIDhQUMQYLJQIEARIIh3gDDwywLoZADYlajDeCJjiCX2EDlFCCeIomhRWDB4FrJBg X-IronPort-AV: E=Sophos;i="4.84,698,1355097600"; d="scan'208";a="178900143" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 19 Feb 2013 23:10:15 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1JNAFbN016589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 23:10:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 17:10:15 -0600 From: "Joe Hildebrand (jhildebr)" To: Francis Galiegue , "json@ietf.org" Thread-Topic: [Json] About JSON equality Thread-Index: AQHODvQ9KLrAMZlmKEWR9MVVfm4fnJiBvd6A Date: Tue, 19 Feb 2013 23:10:14 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <24CE2E45CED9124B9D3C150CBFFBD3E8@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] About JSON equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 23:10:20 -0000 Are you proposing that this be added to 4627bis, or that it be in a separate document? Adding it to the existing spec expands that document's scope somewhat, which we may want to avoid for a variety of reasons. On 2/19/13 3:55 PM, "Francis Galiegue" wrote: >The subject has been brought, even though somewhat indirectly, in >another thread on this list, so here I will give a digest of what JSON >Schema came up with. > >The definition of JSON value equality, as defined by the core >specification, is as such (link: >http://tools.ietf.org/html/draft-zyp-json-schema-04#section-3.6): > >---- >Two JSON values are said to be equal if and only if: > > both are nulls; or > > both are booleans, and have the same value; or > > both are strings, and have the same value; or > > both are numbers, and have the same mathematical value; or > > both are arrays, and: > > have the same number of items; and > > items at the same index are equal according to this definition; > or > > both are objects, and: > > have the same set of property names; and > > values for a same property name are equal according to this > definition. >---- > >This definition is only lacking for strings. On some other draft which >I cannot remember off the top of my head, two JSON String values are >to be considered equal if, position wise, their Unicode code points >are the same (and THAT INCLUDES \u0000). > >Now, what is the value of defining equality of two JSON values in the >general case (see also my mail about why having to restrict JSON >representations to container instances)? > >Of course, there is also the problem that for numeric instances, some >programming languages/parsers cannot guarantee that, since they cannot >reliably represent said instances in a reliable manner, but then this >is why the validation spec explicitly mentions this: >http://tools.ietf.org/html/draft-fge-json-schema-validation-00#section-3.2 > >About strings and the famous "zero character", this same specification >also says:=20 >http://tools.ietf.org/html/draft-fge-json-schema-validation-00#section-3.1 > >Yes, nothing forbids "\u0000" in a JSON string. > >All this to say, should an equality definition find its place in a >potentially revised JSON RFC? Personally, I'm not so sure... > >-- >Francis Galiegue, fgaliegue@gmail.com >Try out your JSON Schemas: http://json-schema-validator.herokuapp.com >_______________________________________________ >json mailing list >json@ietf.org >https://www.ietf.org/mailman/listinfo/json > --=20 Joe Hildebrand From fgaliegue@gmail.com Tue Feb 19 15:13:52 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D9421F8890 for ; Tue, 19 Feb 2013 15:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03hrCLQBxIIa for ; Tue, 19 Feb 2013 15:13:52 -0800 (PST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3B98D21F8554 for ; Tue, 19 Feb 2013 15:13:16 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e52so3639589eek.20 for ; Tue, 19 Feb 2013 15:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=eozzrAx87rS3Vaj5cFL2j/z/rMktSzTEeJxt8H+pMDg=; b=CuQkJpLBWWXf5hqhxhWpPXS4eyGUaKUOavlv+rPpLxpkwGMXw34JelcnmIskt6H6s0 IBQTNnMuSHnDcOUM/QPM/FpyrK1jpR5vSsSpwuKGTcs95OGcq3ECDpaLXbII4qHIRIgc ULnJF2/9usawPEZk5NPxYK9jk1lgzJ1jCyN8aC1xEMKrUX1eoZm2ZEf/T2oxM7IDgl9/ YQDkNCzrWH24y2bRXCnIU0gjzG/mdbh4xx07ljHF4vzM0qu5boMtmOzciyZ0+N0Opn1D 3dOT7neNUCTBw6OmzoKU0sHhculOP6J43khQX01PZAatJ/dvEvwZ41F5HZd8e6CpcQX2 4r6Q== MIME-Version: 1.0 X-Received: by 10.14.179.5 with SMTP id g5mr62047805eem.41.1361315595439; Tue, 19 Feb 2013 15:13:15 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 15:13:15 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 00:13:15 +0100 Message-ID: From: Francis Galiegue To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: Nico Williams , "json@ietf.org" , Tim Bray , "Matt Miller \(mamille2\)" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 23:13:52 -0000 On Wed, Feb 20, 2013 at 12:08 AM, Joe Hildebrand (jhildebr) wrote: [...] >> >> >>He means "\u0000 is an exception to Tim's proposed 'forbid escaping' >>rule". > > Exactly. It's the only code point that I know of that MUST be escaped > using \uxxxx notation when serialized (either canonically or otherwise). > All of the other codepoints that need to be escaped have \x versions. > OK, but why should it be considered illegal at all? Any ASCII character is representable by such a sequence, it just happens that 0 can where ASCII can't... I don't see this as a reason to outlaw this particular sequence... Or there is something I don't understand in your argument. -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From fgaliegue@gmail.com Tue Feb 19 15:19:55 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820DC21F8AD8 for ; Tue, 19 Feb 2013 15:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKU17lKwipFX for ; Tue, 19 Feb 2013 15:19:54 -0800 (PST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7D121F8952 for ; Tue, 19 Feb 2013 15:19:54 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e52so3604910eek.6 for ; Tue, 19 Feb 2013 15:19:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aIXa3J8XTWXShwzIMXgnG/2YDbEOLuPDclXx8mFE30U=; b=ri73tVCrwlVddHGQKGUipcQrd42E8oHow14A3pGujD7kXkvz0aEVqxpOBtwYw7ugJd QuG8zdBd0joykER3tlNgJVNkhEUbx7dzJHMb9/oIquapDy+n5CzU6xu5TLIExBBVIbvL ZkClxL9roLCQS1XBYExxE2idAzpPumQIXUAF4gSpJiVPtwcBOuygm/PAvnnfzQxEg/dQ /hpwA+JsOmTOOPZDegUMCspxDXId+jJFQWKZ33AL6lCxko01RZaPOCtIjbKbSgm1YmUR 9N9SILKWYkzSQlfYhkarmhbEUHLgozGo51hGuJ4kAWF5n/khTvmLMfnpYFUn4yoVrK93 hHEg== MIME-Version: 1.0 X-Received: by 10.14.183.67 with SMTP id p43mr61817876eem.10.1361315993780; Tue, 19 Feb 2013 15:19:53 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 15:19:53 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 00:19:53 +0100 Message-ID: From: Francis Galiegue To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] About JSON equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 23:19:55 -0000 On Wed, Feb 20, 2013 at 12:10 AM, Joe Hildebrand (jhildebr) wrote: > Are you proposing that this be added to 4627bis, or that it be in a > separate document? > That is what I am asking. I believe the more JSON is used, the more people will want to "compare" JSON values, whatever they may be (and a hint again: please make RFC 4627bis allow to transfer _any_ JSON value, not just arrays and objects). There are two problems here: strings and numbers. For strings, Unicode code points and their representation in whatever encoding should be considered equal, and parsers should be able to handle whatever they are fed with. For numbers, there is the much more annoying limitation that all humanly representable numbers just cannot be represented in programming languages, and that JSON (at least to my eyes) should not feel compelled to represent NaN (since it is, essentially, language dependent) nor infinity (since it is an abstract concept and not even a number). But both of these problems can be at least formulated as being present -- the JSON Schema validation spec does. The real question becomes, will future uses of JSON rely on value equality? -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From nico@cryptonector.com Tue Feb 19 15:37:38 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3379421F8873 for ; Tue, 19 Feb 2013 15:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.744 X-Spam-Level: X-Spam-Status: No, score=-3.744 tagged_above=-999 required=5 tests=[AWL=-1.767, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoSf2M5Wlsjj for ; Tue, 19 Feb 2013 15:37:37 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF7F21F886F for ; Tue, 19 Feb 2013 15:37:37 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 5D72C2C806D for ; Tue, 19 Feb 2013 15:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=yHj8EaBQNuxtOYS8l263 nd6kwCw=; b=HvOfqZSgq2cJ3/OE/KsQEV0a8NE7tcJTHyjYoAIHEwhZK0nvvSFc iTiMBFKt5XPAGwqR4OkdSg+Ru+MD97LIv2+RDlRHSBvAanYJbEI1a62C5QNC0YaV UuoueJE9mRYtgKCbFIoZ1FP81ZSfEY19AOdoc90cnPk4Ihe5y/T10OM= Received: from mail-ia0-f180.google.com (mail-ia0-f180.google.com [209.85.210.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 3A7532C806B for ; Tue, 19 Feb 2013 15:37:37 -0800 (PST) Received: by mail-ia0-f180.google.com with SMTP id f27so6550133iae.39 for ; Tue, 19 Feb 2013 15:37:36 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.170.36 with SMTP id aj4mr10066479igc.67.1361317056640; Tue, 19 Feb 2013 15:37:36 -0800 (PST) Received: by 10.64.102.201 with HTTP; Tue, 19 Feb 2013 15:37:36 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Feb 2013 17:37:36 -0600 Message-ID: From: Nico Williams To: Francis Galiegue Content-Type: text/plain; charset=UTF-8 Cc: json@ietf.org Subject: Re: [Json] About JSON equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 23:37:38 -0000 On Tue, Feb 19, 2013 at 4:55 PM, Francis Galiegue wrote: > This definition is only lacking for strings. On some other draft which > I cannot remember off the top of my head, two JSON String values are > to be considered equal if, position wise, their Unicode code points > are the same (and THAT INCLUDES \u0000). String equality is definitely a case where normalization does come in. In practice most Unicode strings are in NFC (normalization form composed) by accident: it's what input methods typically produce. But it doesn't have to be that way. For some scripts it almost certainly isn't always that way (I'm thinking of Hangul in particular). And then there's the dreaded HFS+, which, for some unknown [to me] reason that I cannot fathom, normalizes to NFD on create(!). So, suppose you were creating a JSON representation of file names in a filesystem. If that filesystem were HFS+ then you're guaranteed to have NFD. If it's any other filesystem (except, perhaps, other filesystems on OS X, like at least one port of ZFS to it) then chances are very high that the file names will be in NFC. This is not really a contrived example -- I really, really wish it were, but I think it more than likely that we'll have such uses of JSON. So, if you want to be able to compare JSON strings for equality, you do need to specify whether you care about normalization. Normalization-insensitive string comparison is *not* that expensive for mostly ASCII strings: the trivial optimization is to have a fast path that compares characters in logical two-byte windows that move one byte at a time, and a slow path that gets triggered only whenever one of those bytes is non-ASCII. But it's still a PITA. Nico -- From pbryan@anode.ca Tue Feb 19 15:38:36 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CB721F87D6 for ; Tue, 19 Feb 2013 15:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6A6v6b0dudLw for ; Tue, 19 Feb 2013 15:38:35 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 68F7121F87D1 for ; Tue, 19 Feb 2013 15:38:35 -0800 (PST) Received: from [10.126.22.27] (unknown [204.14.239.147]) by maple.anode.ca (Postfix) with ESMTPSA id DECEF6174 for ; Tue, 19 Feb 2013 23:38:34 +0000 (UTC) From: "Paul C. Bryan" To: json@ietf.org In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-afOp0xjJoXp/A/PsoDk/" Date: Tue, 19 Feb 2013 15:38:33 -0800 Message-ID: <1361317113.9790.31.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Subject: Re: [Json] About JSON equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 23:38:36 -0000 --=-afOp0xjJoXp/A/PsoDk/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Tue, 2013-02-19 at 23:55 +0100, Francis Galiegue wrote: > This definition is only lacking for strings. On some other draft which > I cannot remember off the top of my head, two JSON String values are > to be considered equal if, position wise, their Unicode code points > are the same (and THAT INCLUDES \u0000). See http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10#section-4.6 Paul --=-afOp0xjJoXp/A/PsoDk/ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 2013-02-19 at 23:55 +0100, Francis Galiegue wrote:

This definition is only lacking for strings. On some other draft which I cannot remember off the top of my head, two JSON String values are to be considered equal if, position wise, their Unicode code points are the same (and THAT INCLUDES \u0000).

See http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10#section-4.6

Paul --=-afOp0xjJoXp/A/PsoDk/-- From tbray@textuality.com Tue Feb 19 15:42:47 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F082521F8881 for ; Tue, 19 Feb 2013 15:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFAP66TXSC4j for ; Tue, 19 Feb 2013 15:42:47 -0800 (PST) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1681521F887F for ; Tue, 19 Feb 2013 15:42:47 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id b10so6341939vea.16 for ; Tue, 19 Feb 2013 15:42:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=RWvjJkquajKFq8adDMV8qD+BMHp0vlUhWMw2HFtwvFQ=; b=mpqZbjXCa5jaVLAqfcMyK+20N1hV4JbopWfVbwZi1BMpSpZ+ptJDKg+1zNRTfoUJNm iH4O5uRaf4yf8EMYLkpsrbMp8BAQ054yMia6F0VPqa3vRB263mFMGXrc68/lxm42c7tz NmkTDakCpSvYRBbsR0vPh9OYYJR9HZ5z4nch84BXkgzmgWyqtbqBi4kYcrxpxhewabao a3DuYQREbDou8bw2BrFcH8hd6N28fSbF4zdeXS9/I4wyMQEyIrecNuX0CeurXjWQwWEh 51bZ0clt3EMTCh0ehr50pjTQxpAJwikXTJ5nJO2fsC1Hb67hwXAIl/dQij1bb45NODsH Bgvg== MIME-Version: 1.0 X-Received: by 10.52.32.69 with SMTP id g5mr16509197vdi.81.1361317366497; Tue, 19 Feb 2013 15:42:46 -0800 (PST) Received: by 10.220.164.74 with HTTP; Tue, 19 Feb 2013 15:42:46 -0800 (PST) X-Originating-IP: [172.29.161.33] In-Reply-To: References: Date: Tue, 19 Feb 2013 15:42:46 -0800 Message-ID: From: Tim Bray To: Francis Galiegue Content-Type: multipart/alternative; boundary=bcaec51d25760e834d04d61c6642 X-Gm-Message-State: ALoCoQmptMhLSgu7uPjboUcTWt1wclJVyaVmWuXhWNxgDa0jHwj+L766/eOxpDKJKbfOPe01HjLg Cc: Nico Williams , "json@ietf.org" , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 23:42:48 -0000 --bcaec51d25760e834d04d61c6642 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I haven=92t heard anyone saying U+0000 should be illegal in JSON. It=92s t= oo late to redesign JSON. -T On Tue, Feb 19, 2013 at 3:13 PM, Francis Galiegue wrot= e: > On Wed, Feb 20, 2013 at 12:08 AM, Joe Hildebrand (jhildebr) > wrote: > [...] > >> > >> > >>He means "\u0000 is an exception to Tim's proposed 'forbid escaping' > >>rule". > > > > Exactly. It's the only code point that I know of that MUST be escaped > > using \uxxxx notation when serialized (either canonically or otherwise)= . > > All of the other codepoints that need to be escaped have \x versions. > > > > OK, but why should it be considered illegal at all? Any ASCII > character is representable by such a sequence, it just happens that 0 > can where ASCII can't... I don't see this as a reason to outlaw this > particular sequence... Or there is something I don't understand in > your argument. > > -- > Francis Galiegue, fgaliegue@gmail.com > Try out your JSON Schemas: http://json-schema-validator.herokuapp.com > --bcaec51d25760e834d04d61c6642 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I haven=92t heard anyone saying U+0000 should be illegal i= n JSON.=A0 It=92s too late to redesign JSON. -T


On Tue, Feb 19, 2013 at 3:13 PM= , Francis Galiegue <fgaliegue@gmail.com> wrote:
On Wed, Feb 20, 2013 at 12:08 AM, Joe Hildeb= rand (jhildebr)
<jhildebr@cisco.com> wrote:=
[...]
>>
>>
>>He means "\u0000 is an exception to Tim's proposed 'fo= rbid escaping'
>>rule".
>
> Exactly. =A0It's the only code point that I know of that MUST be e= scaped
> using \uxxxx notation when serialized (either canonically or otherwise= ).
> All of the other codepoints that need to be escaped have \x versions.<= br> >

OK, but why should it be considered illegal at all? Any ASCII
character is representable by such a sequence, it just happens that 0
can where ASCII can't... I don't see this as a reason to outlaw thi= s
particular sequence... Or there is something I don't understand in
your argument.

--
Francis Galiegue, fgaliegue@gmail.co= m
Try out your JSON Schemas: http://json-schema-validator.herokuapp.com

--bcaec51d25760e834d04d61c6642-- From jhildebr@cisco.com Tue Feb 19 15:52:41 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB5E21F88B9 for ; Tue, 19 Feb 2013 15:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJdvLt3o0L5H for ; Tue, 19 Feb 2013 15:52:40 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4122721F889A for ; Tue, 19 Feb 2013 15:52:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1910; q=dns/txt; s=iport; t=1361317955; x=1362527555; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=aK+2IBeM7EOyjH7OCVNpdjvWwY1t3FzYmQOhHoE0BuI=; b=EIrYbOSjs0/VCN4a8l1G+Dr0gLQkRXuGysNyKFlKYS34TZY2A6ZCze8J nXjZP38sjJkM3IrnLH1KoK306Gcu1ChjBFCljkHDv/Hs75A5Y791f0c1n YrqRvkJzIUkG2h5tZXiGXksHOUZsko8RmHGZnK54/ZG28mQhiN27lyUC+ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABEPJFGtJXHB/2dsb2JhbABFwESBDRZzgh8BAQEEbgsSAQgOCgpFESUCBAENBQiHeAMPDLAlhkINiVqMN4IkAjEHgl9hA4gwjCCNHoUVgweBayQY X-IronPort-AV: E=Sophos;i="4.84,698,1355097600"; d="scan'208";a="175938452" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 19 Feb 2013 23:52:34 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1JNqYeT002654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 23:52:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 17:52:34 -0600 From: "Joe Hildebrand (jhildebr)" To: Tim Bray , Francis Galiegue Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODu/VV0zn7u2LJ02Uk/kU6xbmZ5iBsyqAgAB3XoCAAAEJgP//kdsAgAB2rYCAAAg/AP//jWIA Date: Tue, 19 Feb 2013 23:52:34 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.21.119.56] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <99D1A35882B1F44AAE12D63DAFBA3C30@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Nico Williams , "json@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 23:52:41 -0000 Nor was I suggesting we do so. I was suggesting that if you want to get \u0000 - \u001f, excluding \u0008(\b), \u0009(\t), \u000a(\n), \u000c(\f), and \u000d(\r) into the canonicalized output, you have to use the \u notation, which means we can't outlaw \u notation entirely in the canonicalized form, as some of us thought Tim had suggested in the first place. Note, I was wrong about \u0000 being the only codepoint we care about. >From section 2.5 of 4627: "All Unicode characters may be placed within the quotation marks except for the characters that must be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F)." On 2/19/13 4:42 PM, "Tim Bray" wrote: >I haven=B9t heard anyone saying U+0000 should be illegal in JSON. It=B9s = too >late to redesign JSON. -T > > > >On Tue, Feb 19, 2013 at 3:13 PM, Francis Galiegue > wrote: > >On Wed, Feb 20, 2013 at 12:08 AM, Joe Hildebrand (jhildebr) > wrote: >[...] >>> >>> >>>He means "\u0000 is an exception to Tim's proposed 'forbid escaping' >>>rule". >> >> Exactly. It's the only code point that I know of that MUST be escaped >> using \uxxxx notation when serialized (either canonically or otherwise). >> All of the other codepoints that need to be escaped have \x versions. >> > > >OK, but why should it be considered illegal at all? Any ASCII >character is representable by such a sequence, it just happens that 0 >can where ASCII can't... I don't see this as a reason to outlaw this >particular sequence... Or there is something I don't understand in >your argument. > >-- >Francis Galiegue, fgaliegue@gmail.com >Try out your JSON Schemas: >http://json-schema-validator.herokuapp.com > > > > > > > > > --=20 Joe Hildebrand From tbray@textuality.com Tue Feb 19 16:02:15 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AED21F8750 for ; Tue, 19 Feb 2013 16:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIR8ri11yrQ9 for ; Tue, 19 Feb 2013 16:02:14 -0800 (PST) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1659B21F8740 for ; Tue, 19 Feb 2013 16:02:13 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id fa15so4696816vbb.11 for ; Tue, 19 Feb 2013 16:02:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=rsjP6D0Knk1D+/9XpwhsB46air49csYS6U+gjOm6vHg=; b=OjyLsSeqI2mywWl7WED+rsT+9Gi3+rXXBQXOxQ5pnFQ/wHaGU0pucxcWeysTEQh5zp nusFH7fKQOx/baF2Js/2xrlX5F2dEQA3sjDo4xJJeWr2tOUF7inDRfOXYmuUrD4mrU0H MbVvm9JHdF73EiVrvWsY+ZiDblOFvFsY0NnAm5q3PFXjA4KO6ImZITr3gZmtdLJtj2/N faibKoj4SmAIohtDgrvEjDY+FgOr8LchRwpAmZmIaa5JDT+ZWD9Qs4Rwspy5TQ6dyYZe szNFFNJa4AtUd+FwkhseJkDI5aNQ1o7h+RoXB88GOJuvjry4Y8bxp+i1nqeGI+6v87HV RZiA== MIME-Version: 1.0 X-Received: by 10.220.156.68 with SMTP id v4mr22992362vcw.10.1361318525332; Tue, 19 Feb 2013 16:02:05 -0800 (PST) Received: by 10.220.164.74 with HTTP; Tue, 19 Feb 2013 16:02:05 -0800 (PST) X-Originating-IP: [172.29.161.33] In-Reply-To: References: Date: Tue, 19 Feb 2013 16:02:05 -0800 Message-ID: From: Tim Bray To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=f46d043892e120ee7204d61cabec X-Gm-Message-State: ALoCoQny7ihcqJ/r4hlfkkl6YXuSDm5e+fzxEH9cbybIiNtS+hmaPVhXxVDPkXiIaSbIx6gnRTpT Cc: "json@ietf.org" , Francis Galiegue , Nico Williams , "Matt Miller \(mamille2\)" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 00:02:15 -0000 --f46d043892e120ee7204d61cabec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, I guess I did sort of strawman-suggest banning \uxxxx. Which clearly doesn't fly. So, two suggestions: - \uxxxx is only allowed for chars that must be escaped per the JSON spec - \uxxxx is freely allowed, but the \uxxxx is considered to represent a single codepoint, and all comparison/hashing operations have to be conducted codepoint-by-codepoint I think I probably support the first, because it does allow comparison using strcmp() or equivalent. That's assuming that c14n is in fact worth doing. -T On Tue, Feb 19, 2013 at 3:52 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > Nor was I suggesting we do so. > > I was suggesting that if you want to get \u0000 - \u001f, excluding > \u0008(\b), \u0009(\t), \u000a(\n), \u000c(\f), and \u000d(\r) into the > canonicalized output, you have to use the \u notation, which means we > can't outlaw \u notation entirely in the canonicalized form, as some of u= s > thought Tim had suggested in the first place. > > Note, I was wrong about \u0000 being the only codepoint we care about. > From section 2.5 of 4627: > > "All Unicode characters may be placed within the > quotation marks except for the characters that must be escaped: > quotation mark, reverse solidus, and the control characters (U+0000 > through U+001F)." > > > > On 2/19/13 4:42 PM, "Tim Bray" wrote: > > >I haven=B9t heard anyone saying U+0000 should be illegal in JSON. It=B9= s too > >late to redesign JSON. -T > > > > > > > >On Tue, Feb 19, 2013 at 3:13 PM, Francis Galiegue > > wrote: > > > >On Wed, Feb 20, 2013 at 12:08 AM, Joe Hildebrand (jhildebr) > > wrote: > >[...] > >>> > >>> > >>>He means "\u0000 is an exception to Tim's proposed 'forbid escaping' > >>>rule". > >> > >> Exactly. It's the only code point that I know of that MUST be escaped > >> using \uxxxx notation when serialized (either canonically or otherwise= ). > >> All of the other codepoints that need to be escaped have \x versions. > >> > > > > > >OK, but why should it be considered illegal at all? Any ASCII > >character is representable by such a sequence, it just happens that 0 > >can where ASCII can't... I don't see this as a reason to outlaw this > >particular sequence... Or there is something I don't understand in > >your argument. > > > >-- > >Francis Galiegue, fgaliegue@gmail.com > >Try out your JSON Schemas: > >http://json-schema-validator.herokuapp.com > > > > > > > > > > > > > > > > > > > > > > -- > Joe Hildebrand > > > > --f46d043892e120ee7204d61cabec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, I guess I did sort of strawman-suggest bann= ing \uxxxx.=A0 Which clearly doesn't fly.=A0 So, two suggestions:
- \uxxxx is only allowed for chars that must be escaped per the JSO= N spec
- \uxxxx is freely allowed, but the \uxxxx is considered to represent= a single codepoint, and all comparison/hashing operations have to be condu= cted codepoint-by-codepoint

I think I probably support the first, be= cause it does allow comparison using strcmp() or equivalent. That's ass= uming that c14n is in fact worth doing. -T


<= br>
On Tue, Feb 19, 2013 at 3:52 PM, Joe Hildebra= nd (jhildebr) <jhildebr@cisco.com> wrote:
Nor was I suggesting we do so.

I was suggesting that if you want to get \u0000 - \u001f, excluding
\u0008(\b), \u0009(\t), \u000a(\n), \u000c(\f), and \u000d(\r) into the
canonicalized output, you have to use the \u notation, which means we
can't outlaw \u notation entirely in the canonicalized form, as some of= us
thought Tim had suggested in the first place.

Note, I was wrong about \u0000 being the only codepoint we care about.
>From section 2.5 of 4627:

"All Unicode characters may be placed within the
=A0 =A0quotation marks except for the characters that must be escaped:
=A0 =A0quotation mark, reverse solidus, and the control characters (U+0000<= br> =A0 =A0through U+001F)."



On 2/19/13 4:42 PM, "Tim Bray" <tbray@textuality.com> wrote:

>I haven=B9t heard anyone saying U+0000 should be illegal in JSON. =A0It= =B9s too
>late to redesign JSON. -T
>
>
>
>On Tue, Feb 19, 2013 at 3:13 PM, Francis Galiegue
><fgaliegue@gmail.com> = wrote:
>
>On Wed, Feb 20, 2013 at 12:08 AM, Joe Hildebrand (jhildebr)
><jhildebr@cisco.com> wr= ote:
>[...]
>>>
>>>
>>>He means "\u0000 is an exception to Tim's proposed = 9;forbid escaping'
>>>rule".
>>
>> Exactly. =A0It's the only code point that I know of that MUST = be escaped
>> using \uxxxx notation when serialized (either canonically or other= wise).
>> All of the other codepoints that need to be escaped have \x versio= ns.
>>
>
>
>OK, but why should it be considered illegal at all? Any ASCII
>character is representable by such a sequence, it just happens that 0 >can where ASCII can't... I don't see this as a reason to outlaw= this
>particular sequence... Or there is something I don't understand in<= br> >your argument.
>
>--
>Francis Galiegue, fgaliegue@gmai= l.com
>Try out your JSON Schemas:
>http://json-schema-validator.herokuapp.com
><http://json-schema-validator.herokuapp.com>
>
>
>
>
>
>
>
>



--
Joe Hildebrand




--f46d043892e120ee7204d61cabec-- From jhildebr@cisco.com Tue Feb 19 16:08:40 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1756521F87A5 for ; Tue, 19 Feb 2013 16:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXA1LHlz+c0c for ; Tue, 19 Feb 2013 16:08:39 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 85FF321F87A4 for ; Tue, 19 Feb 2013 16:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=728; q=dns/txt; s=iport; t=1361318919; x=1362528519; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=V4o24NuYq9rehqdX9aMZKfQHAq7xCz2qUayX74vT4+c=; b=Cb/egQVywMAjOhtZFlewpcF2yJavR03uUB8MLL9HelcsoilBIZJh9dO9 sM4sca/qi9a7a8OUq7QrViQk7yvr/YJlr0v5IdmMRsGhBwevuVcIesnX4 vHhs+WFb70zH3DN/lDcD/orKhzSyzqI+5PjWlRTe1EvoozKx5Zu/9I4Ay Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAEsTJFGtJV2b/2dsb2JhbABFhgK6QoEOFnOCIQEEOjQLEgEIDhQUQiUCBA4FCIgKskiOE45dMQeCX2EDpwOCeg2CJw X-IronPort-AV: E=Sophos;i="4.84,698,1355097600"; d="scan'208";a="178936482" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 20 Feb 2013 00:08:39 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1K08das030802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Feb 2013 00:08:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 18:08:38 -0600 From: "Joe Hildebrand (jhildebr)" To: Tim Bray Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODu/VV0zn7u2LJ02Uk/kU6xbmZ5iBsyqAgAB3XoCAAAEJgP//kdsAgAB2rYCAAAg/AP//jWIAgAB4BID//4x1gA== Date: Wed, 20 Feb 2013 00:08:38 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.21.119.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" , Francis Galiegue , Nico Williams , "Matt Miller \(mamille2\)" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 00:08:40 -0000 On 2/19/13 5:02 PM, "Tim Bray" wrote: >Yes, I guess I did sort of strawman-suggest banning \uxxxx. Which >clearly doesn't fly. So, two suggestions: > > >- \uxxxx is only allowed for chars that must be escaped per the JSON spec > >- \uxxxx is freely allowed, but the \uxxxx is considered to represent a >single codepoint, and all comparison/hashing operations have to be >conducted codepoint-by-codepoint > >I think I probably support the first, because it does allow comparison >using strcmp() or equivalent. That's assuming that c14n is in fact worth >doing. -T +1 to the first approach, and also +1 about not knowing whether we need to do c14n or not yet. --=20 Joe Hildebrand From pbryan@anode.ca Tue Feb 19 16:18:03 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155A721F8840 for ; Tue, 19 Feb 2013 16:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqFSHT-qrhHV for ; Tue, 19 Feb 2013 16:18:01 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id D53A421F8830 for ; Tue, 19 Feb 2013 16:18:01 -0800 (PST) Received: from [10.126.22.27] (unknown [204.14.239.147]) by maple.anode.ca (Postfix) with ESMTPSA id 554E86BEB for ; Wed, 20 Feb 2013 00:18:01 +0000 (UTC) From: "Paul C. Bryan" To: json@ietf.org In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-tkSSO9UlJEKjEsaKqU7/" Date: Tue, 19 Feb 2013 16:17:59 -0800 Message-ID: <1361319479.9790.36.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 00:18:03 -0000 --=-tkSSO9UlJEKjEsaKqU7/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Should two representations of the same JSON (string) value be c14n'ed differently? I think not*. If not, then I think comparisons would need to occur by parsing JSON strings into Unicode codepoints. Paul * Why not? Mostly because I foresee many operations such as signature verification occurring on already-parsed JSON values, so how it was represented when it was serialized should (ideally) be moot. On Tue, 2013-02-19 at 16:02 -0800, Tim Bray wrote: > Yes, I guess I did sort of strawman-suggest banning \uxxxx. Which > clearly doesn't fly. So, two suggestions: > > > > - \uxxxx is only allowed for chars that must be escaped per the JSON > spec > > > - \uxxxx is freely allowed, but the \uxxxx is considered to represent > a single codepoint, and all comparison/hashing operations have to be > conducted codepoint-by-codepoint > > I think I probably support the first, because it does allow comparison > using strcmp() or equivalent. That's assuming that c14n is in fact > worth doing. -T > > > > > > > On Tue, Feb 19, 2013 at 3:52 PM, Joe Hildebrand (jhildebr) > wrote: > > Nor was I suggesting we do so. > > I was suggesting that if you want to get \u0000 - \u001f, > excluding > \u0008(\b), \u0009(\t), \u000a(\n), \u000c(\f), and \u000d(\r) > into the > canonicalized output, you have to use the \u notation, which > means we > can't outlaw \u notation entirely in the canonicalized form, > as some of us > thought Tim had suggested in the first place. > > Note, I was wrong about \u0000 being the only codepoint we > care about. > From section 2.5 of 4627: > > "All Unicode characters may be placed within the > quotation marks except for the characters that must be > escaped: > quotation mark, reverse solidus, and the control characters > (U+0000 > through U+001F)." > > > > > On 2/19/13 4:42 PM, "Tim Bray" wrote: > > >I haven¹t heard anyone saying U+0000 should be illegal in > JSON. It¹s too > >late to redesign JSON. -T > > > > > > > >On Tue, Feb 19, 2013 at 3:13 PM, Francis Galiegue > > wrote: > > > >On Wed, Feb 20, 2013 at 12:08 AM, Joe Hildebrand (jhildebr) > > wrote: > >[...] > >>> > >>> > >>>He means "\u0000 is an exception to Tim's proposed 'forbid > escaping' > >>>rule". > >> > >> Exactly. It's the only code point that I know of that MUST > be escaped > >> using \uxxxx notation when serialized (either canonically > or otherwise). > >> All of the other codepoints that need to be escaped have \x > versions. > >> > > > > > >OK, but why should it be considered illegal at all? Any ASCII > >character is representable by such a sequence, it just > happens that 0 > >can where ASCII can't... I don't see this as a reason to > outlaw this > >particular sequence... Or there is something I don't > understand in > >your argument. > > > >-- > >Francis Galiegue, fgaliegue@gmail.com > >Try out your JSON Schemas: > >http://json-schema-validator.herokuapp.com > > > > > > > > > > > > > > > > > > > > > > > > -- > Joe Hildebrand > > > > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --=-tkSSO9UlJEKjEsaKqU7/ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Should two representations of the same JSON (string) value be c14n'ed differently? I think not*.

If not, then I think comparisons would need to occur by parsing JSON strings into Unicode codepoints.

Paul

* Why not? Mostly because I foresee many operations such as signature verification occurring on already-parsed JSON values, so how it was represented when it was serialized should (ideally) be moot.

On Tue, 2013-02-19 at 16:02 -0800, Tim Bray wrote:
Yes, I guess I did sort of strawman-suggest banning \uxxxx.  Which clearly doesn't fly.  So, two suggestions:


- \uxxxx is only allowed for chars that must be escaped per the JSON spec

- \uxxxx is freely allowed, but the \uxxxx is considered to represent a single codepoint, and all comparison/hashing operations have to be conducted codepoint-by-codepoint

I think I probably support the first, because it does allow comparison using strcmp() or equivalent. That's assuming that c14n is in fact worth doing. -T




On Tue, Feb 19, 2013 at 3:52 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
Nor was I suggesting we do so.

I was suggesting that if you want to get \u0000 - \u001f, excluding
\u0008(\b), \u0009(\t), \u000a(\n), \u000c(\f), and \u000d(\r) into the
canonicalized output, you have to use the \u notation, which means we
can't outlaw \u notation entirely in the canonicalized form, as some of us
thought Tim had suggested in the first place.

Note, I was wrong about \u0000 being the only codepoint we care about.
From section 2.5 of 4627:

"All Unicode characters may be placed within the
   quotation marks except for the characters that must be escaped:
   quotation mark, reverse solidus, and the control characters (U+0000
   through U+001F)."



On 2/19/13 4:42 PM, "Tim Bray" <tbray@textuality.com> wrote:

>I haven¹t heard anyone saying U+0000 should be illegal in JSON.  It¹s too
>late to redesign JSON. -T
>
>
>
>On Tue, Feb 19, 2013 at 3:13 PM, Francis Galiegue
><fgaliegue@gmail.com> wrote:
>
>On Wed, Feb 20, 2013 at 12:08 AM, Joe Hildebrand (jhildebr)
><jhildebr@cisco.com> wrote:
>[...]
>>>
>>>
>>>He means "\u0000 is an exception to Tim's proposed 'forbid escaping'
>>>rule".
>>
>> Exactly.  It's the only code point that I know of that MUST be escaped
>> using \uxxxx notation when serialized (either canonically or otherwise).
>> All of the other codepoints that need to be escaped have \x versions.
>>
>
>
>OK, but why should it be considered illegal at all? Any ASCII
>character is representable by such a sequence, it just happens that 0
>can where ASCII can't... I don't see this as a reason to outlaw this
>particular sequence... Or there is something I don't understand in
>your argument.
>
>--
>Francis Galiegue, fgaliegue@gmail.com
>Try out your JSON Schemas:
>http://json-schema-validator.herokuapp.com

><http://json-schema-validator.herokuapp.com>
>
>
>
>
>
>
>
>



--
Joe Hildebrand





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

--=-tkSSO9UlJEKjEsaKqU7/-- From paul.hoffman@vpnc.org Tue Feb 19 16:23:35 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE3221F85F0 for ; Tue, 19 Feb 2013 16:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaFSvuJ1zVET for ; Tue, 19 Feb 2013 16:23:34 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5CACF21F85ED for ; Tue, 19 Feb 2013 16:23:33 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1K0NScg055671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2013 17:23:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Tue, 19 Feb 2013 16:23:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0A83DAEF-3C96-4659-8554-89247EB6A195@vpnc.org> References: To: Francis Galiegue X-Mailer: Apple Mail (2.1499) Cc: "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] About JSON equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 00:23:36 -0000 On Feb 19, 2013, at 3:19 PM, Francis Galiegue = wrote: > On Wed, Feb 20, 2013 at 12:10 AM, Joe Hildebrand (jhildebr) > wrote: >> Are you proposing that this be added to 4627bis, or that it be in a >> separate document? >>=20 >=20 > That is what I am asking. OK, then. I fully disagree. > I believe the more JSON is used, the more > people will want to "compare" JSON values, whatever they may be (and a > hint again: please make RFC 4627bis allow to transfer _any_ JSON > value, not just arrays and objects). JSON has been used for many, many years without any strong need for such = a comparison semantic in the base spec. It is fine for there to be a separate standard that is usable by = applications that want to compare JSON documents; the rest of the world = (and that seems like the large majority) can ignore the comparison = document and just use the base spec to understand how to create and = consume JSON objects and JSON files. --Paul Hoffman= From Michael.Jones@microsoft.com Tue Feb 19 16:24:16 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891AE21F86D3 for ; Tue, 19 Feb 2013 16:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJ4bE-3ksgtG for ; Tue, 19 Feb 2013 16:24:04 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.23]) by ietfa.amsl.com (Postfix) with ESMTP id 56D5521F85F5 for ; Tue, 19 Feb 2013 16:24:04 -0800 (PST) Received: from BY2FFO11FD028.protection.gbl (10.1.15.200) by BY2FFO11HUB022.protection.gbl (10.1.14.109) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 20 Feb 2013 00:24:01 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD028.mail.protection.outlook.com (10.1.15.217) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 20 Feb 2013 00:24:01 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Wed, 20 Feb 2013 00:23:45 +0000 From: Mike Jones To: "Paul C. Bryan" , "json@ietf.org" Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODu/bO++PfZyST0OQOvHOmW3/lZiBw+8AgAACBICAAAEJgIAABzYAgAABUoCAAAg/AIAAAr0AgAACqICAAARygIAAAKTQ Date: Wed, 20 Feb 2013 00:23:44 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367477E41@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <1361319479.9790.36.camel@pbryan-wsl.internal.salesforce.com> In-Reply-To: <1361319479.9790.36.camel@pbryan-wsl.internal.salesforce.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367477E41TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377424002)(377454001)(51704002)(479174001)(189002)(199002)(24454001)(65816001)(47976001)(56776001)(54356001)(55846006)(5343635001)(47736001)(49866001)(33656001)(50986001)(15202345001)(74502001)(63696002)(5343655001)(16297215001)(76482001)(54316002)(47446002)(44976002)(74662001)(20776003)(53806001)(46102001)(16236675001)(4396001)(16601075001)(31966008)(51856001)(59766001)(77982001)(80022001)(512874001)(66066001)(56816002)(16406001)(79102001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB022; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07630F72AD Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 00:24:16 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367477E41TK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgYmFja2dyb3VuZCwgdGhlIEpPU0Ugc3BlY3MgcmVxdWlyZSB0aGF0IGVxdWFsaXR5IGNvbXBh cmlzb25zIGZvciBtZW1iZXJzIGJlIGRvbmUgYXMgYSBjb21wYXJpc29uIG9mIFVuaWNvZGUgY29k ZSBwb2ludHMsIHdpdGggbm8gbm9ybWFsaXphdGlvbiBvciBjYXNlIGZvbGRpbmcgcGVyZm9ybWVk LiAgU2VlIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdl Yi1zaWduYXR1cmUtMDgjc2VjdGlvbi04LjMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IGpz b24tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpzb24tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFBhdWwgQy4gQnJ5YW4NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDE5LCAyMDEzIDQ6 MTggUE0NClRvOiBqc29uQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0pzb25dIFthcHBzLWRpc2N1 c3NdIEpTT04gbWFpbGluZyBsaXN0IGFuZCBCb0YNCg0KU2hvdWxkIHR3byByZXByZXNlbnRhdGlv bnMgb2YgdGhlIHNhbWUgSlNPTiAoc3RyaW5nKSB2YWx1ZSBiZSBjMTRuJ2VkIGRpZmZlcmVudGx5 PyBJIHRoaW5rIG5vdCouDQoNCklmIG5vdCwgdGhlbiBJIHRoaW5rIGNvbXBhcmlzb25zIHdvdWxk IG5lZWQgdG8gb2NjdXIgYnkgcGFyc2luZyBKU09OIHN0cmluZ3MgaW50byBVbmljb2RlIGNvZGVw b2ludHMuDQoNClBhdWwNCg0KKiBXaHkgbm90PyBNb3N0bHkgYmVjYXVzZSBJIGZvcmVzZWUgbWFu eSBvcGVyYXRpb25zIHN1Y2ggYXMgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbiBvY2N1cnJpbmcgb24g YWxyZWFkeS1wYXJzZWQgSlNPTiB2YWx1ZXMsIHNvIGhvdyBpdCB3YXMgcmVwcmVzZW50ZWQgd2hl biBpdCB3YXMgc2VyaWFsaXplZCBzaG91bGQgKGlkZWFsbHkpIGJlIG1vb3QuDQoNCk9uIFR1ZSwg MjAxMy0wMi0xOSBhdCAxNjowMiAtMDgwMCwgVGltIEJyYXkgd3JvdGU6DQpZZXMsIEkgZ3Vlc3Mg SSBkaWQgc29ydCBvZiBzdHJhd21hbi1zdWdnZXN0IGJhbm5pbmcgXHV4eHh4LiAgV2hpY2ggY2xl YXJseSBkb2Vzbid0IGZseS4gIFNvLCB0d28gc3VnZ2VzdGlvbnM6DQoNCi0gXHV4eHh4IGlzIG9u bHkgYWxsb3dlZCBmb3IgY2hhcnMgdGhhdCBtdXN0IGJlIGVzY2FwZWQgcGVyIHRoZSBKU09OIHNw ZWMNCi0gXHV4eHh4IGlzIGZyZWVseSBhbGxvd2VkLCBidXQgdGhlIFx1eHh4eCBpcyBjb25zaWRl cmVkIHRvIHJlcHJlc2VudCBhIHNpbmdsZSBjb2RlcG9pbnQsIGFuZCBhbGwgY29tcGFyaXNvbi9o YXNoaW5nIG9wZXJhdGlvbnMgaGF2ZSB0byBiZSBjb25kdWN0ZWQgY29kZXBvaW50LWJ5LWNvZGVw b2ludA0KDQpJIHRoaW5rIEkgcHJvYmFibHkgc3VwcG9ydCB0aGUgZmlyc3QsIGJlY2F1c2UgaXQg ZG9lcyBhbGxvdyBjb21wYXJpc29uIHVzaW5nIHN0cmNtcCgpIG9yIGVxdWl2YWxlbnQuIFRoYXQn cyBhc3N1bWluZyB0aGF0IGMxNG4gaXMgaW4gZmFjdCB3b3J0aCBkb2luZy4gLVQNCg0KDQpPbiBU dWUsIEZlYiAxOSwgMjAxMyBhdCAzOjUyIFBNLCBKb2UgSGlsZGVicmFuZCAoamhpbGRlYnIpIDxq aGlsZGVickBjaXNjby5jb208bWFpbHRvOmpoaWxkZWJyQGNpc2NvLmNvbT4+IHdyb3RlOg0KTm9y IHdhcyBJIHN1Z2dlc3Rpbmcgd2UgZG8gc28uDQoNCkkgd2FzIHN1Z2dlc3RpbmcgdGhhdCBpZiB5 b3Ugd2FudCB0byBnZXQgXHUwMDAwIC0gXHUwMDFmLCBleGNsdWRpbmcNClx1MDAwOChcYiksIFx1 MDAwOShcdCksIFx1MDAwYShcbiksIFx1MDAwYyhcZiksIGFuZCBcdTAwMGQoXHIpIGludG8gdGhl DQpjYW5vbmljYWxpemVkIG91dHB1dCwgeW91IGhhdmUgdG8gdXNlIHRoZSBcdSBub3RhdGlvbiwg d2hpY2ggbWVhbnMgd2UNCmNhbid0IG91dGxhdyBcdSBub3RhdGlvbiBlbnRpcmVseSBpbiB0aGUg Y2Fub25pY2FsaXplZCBmb3JtLCBhcyBzb21lIG9mIHVzDQp0aG91Z2h0IFRpbSBoYWQgc3VnZ2Vz dGVkIGluIHRoZSBmaXJzdCBwbGFjZS4NCg0KTm90ZSwgSSB3YXMgd3JvbmcgYWJvdXQgXHUwMDAw IGJlaW5nIHRoZSBvbmx5IGNvZGVwb2ludCB3ZSBjYXJlIGFib3V0Lg0KRnJvbSBzZWN0aW9uIDIu NSBvZiA0NjI3Og0KDQoiQWxsIFVuaWNvZGUgY2hhcmFjdGVycyBtYXkgYmUgcGxhY2VkIHdpdGhp biB0aGUNCiAgIHF1b3RhdGlvbiBtYXJrcyBleGNlcHQgZm9yIHRoZSBjaGFyYWN0ZXJzIHRoYXQg bXVzdCBiZSBlc2NhcGVkOg0KICAgcXVvdGF0aW9uIG1hcmssIHJldmVyc2Ugc29saWR1cywgYW5k IHRoZSBjb250cm9sIGNoYXJhY3RlcnMgKFUrMDAwMA0KICAgdGhyb3VnaCBVKzAwMUYpLiINCg0K DQoNCk9uIDIvMTkvMTMgNDo0MiBQTSwgIlRpbSBCcmF5IiA8dGJyYXlAdGV4dHVhbGl0eS5jb208 bWFpbHRvOnRicmF5QHRleHR1YWxpdHkuY29tPj4gd3JvdGU6DQoNCj5JIGhhdmVuwrl0IGhlYXJk IGFueW9uZSBzYXlpbmcgVSswMDAwIHNob3VsZCBiZSBpbGxlZ2FsIGluIEpTT04uICBJdMK5cyB0 b28NCj5sYXRlIHRvIHJlZGVzaWduIEpTT04uIC1UDQo+DQo+DQo+DQo+T24gVHVlLCBGZWIgMTks IDIwMTMgYXQgMzoxMyBQTSwgRnJhbmNpcyBHYWxpZWd1ZQ0KPjxmZ2FsaWVndWVAZ21haWwuY29t PG1haWx0bzpmZ2FsaWVndWVAZ21haWwuY29tPj4gd3JvdGU6DQo+DQo+T24gV2VkLCBGZWIgMjAs IDIwMTMgYXQgMTI6MDggQU0sIEpvZSBIaWxkZWJyYW5kIChqaGlsZGVicikNCj48amhpbGRlYnJA Y2lzY28uY29tPG1haWx0bzpqaGlsZGVickBjaXNjby5jb20+PiB3cm90ZToNCj5bLi4uXQ0KPj4+ DQo+Pj4NCj4+PkhlIG1lYW5zICJcdTAwMDAgaXMgYW4gZXhjZXB0aW9uIHRvIFRpbSdzIHByb3Bv c2VkICdmb3JiaWQgZXNjYXBpbmcnDQo+Pj5ydWxlIi4NCj4+DQo+PiBFeGFjdGx5LiAgSXQncyB0 aGUgb25seSBjb2RlIHBvaW50IHRoYXQgSSBrbm93IG9mIHRoYXQgTVVTVCBiZSBlc2NhcGVkDQo+ PiB1c2luZyBcdXh4eHggbm90YXRpb24gd2hlbiBzZXJpYWxpemVkIChlaXRoZXIgY2Fub25pY2Fs bHkgb3Igb3RoZXJ3aXNlKS4NCj4+IEFsbCBvZiB0aGUgb3RoZXIgY29kZXBvaW50cyB0aGF0IG5l ZWQgdG8gYmUgZXNjYXBlZCBoYXZlIFx4IHZlcnNpb25zLg0KPj4NCj4NCj4NCj5PSywgYnV0IHdo eSBzaG91bGQgaXQgYmUgY29uc2lkZXJlZCBpbGxlZ2FsIGF0IGFsbD8gQW55IEFTQ0lJDQo+Y2hh cmFjdGVyIGlzIHJlcHJlc2VudGFibGUgYnkgc3VjaCBhIHNlcXVlbmNlLCBpdCBqdXN0IGhhcHBl bnMgdGhhdCAwDQo+Y2FuIHdoZXJlIEFTQ0lJIGNhbid0Li4uIEkgZG9uJ3Qgc2VlIHRoaXMgYXMg YSByZWFzb24gdG8gb3V0bGF3IHRoaXMNCj5wYXJ0aWN1bGFyIHNlcXVlbmNlLi4uIE9yIHRoZXJl IGlzIHNvbWV0aGluZyBJIGRvbid0IHVuZGVyc3RhbmQgaW4NCj55b3VyIGFyZ3VtZW50Lg0KPg0K Pi0tDQo+RnJhbmNpcyBHYWxpZWd1ZSwgZmdhbGllZ3VlQGdtYWlsLmNvbTxtYWlsdG86ZmdhbGll Z3VlQGdtYWlsLmNvbT4NCj5Ucnkgb3V0IHlvdXIgSlNPTiBTY2hlbWFzOg0KPmh0dHA6Ly9qc29u LXNjaGVtYS12YWxpZGF0b3IuaGVyb2t1YXBwLmNvbQ0KPjxodHRwOi8vanNvbi1zY2hlbWEtdmFs aWRhdG9yLmhlcm9rdWFwcC5jb20+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQoNCg0KDQotLQ0K Sm9lIEhpbGRlYnJhbmQNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCmpzb24gbWFpbGluZyBsaXN0DQoNCmpzb25AaWV0Zi5vcmc8 bWFpbHRvOmpzb25AaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vanNvbg0KDQo= --_000_4E1F6AAD24975D4BA5B168042967394367477E41TK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+QXMgYmFja2dyb3VuZCwgdGhlIEpPU0Ugc3BlY3MgcmVxdWlyZSB0 aGF0IGVxdWFsaXR5IGNvbXBhcmlzb25zIGZvciBtZW1iZXJzIGJlIGRvbmUgYXMgYSBjb21wYXJp c29uIG9mIFVuaWNvZGUgY29kZSBwb2ludHMsIHdpdGggbm8gbm9ybWFsaXphdGlvbiBvciBjYXNl IGZvbGRpbmcNCiBwZXJmb3JtZWQuJm5ic3A7IFNlZSA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTA4I3NlY3Rpb24t OC4zIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdl Yi1zaWduYXR1cmUtMDgjc2VjdGlvbi04LjM8L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBqc29uLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqc29uLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPlBhdWwgQy4gQnJ5YW48YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVh cnkgMTksIDIwMTMgNDoxOCBQTTxicj4NCjxiPlRvOjwvYj4ganNvbkBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW0pzb25dIFthcHBzLWRpc2N1c3NdIEpTT04gbWFpbGluZyBsaXN0 IGFuZCBCb0Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T aG91bGQgdHdvIHJlcHJlc2VudGF0aW9ucyBvZiB0aGUgc2FtZSBKU09OIChzdHJpbmcpIHZhbHVl IGJlIGMxNG4nZWQgZGlmZmVyZW50bHk/IEkgdGhpbmsgbm90Ki48YnI+DQo8YnI+DQpJZiBub3Qs IHRoZW4gSSB0aGluayBjb21wYXJpc29ucyB3b3VsZCBuZWVkIHRvIG9jY3VyIGJ5IHBhcnNpbmcg SlNPTiBzdHJpbmdzIGludG8gVW5pY29kZSBjb2RlcG9pbnRzLjxicj4NCjxicj4NClBhdWw8YnI+ DQo8YnI+DQoqIFdoeSBub3Q/IE1vc3RseSBiZWNhdXNlIEkgZm9yZXNlZSBtYW55IG9wZXJhdGlv bnMgc3VjaCBhcyBzaWduYXR1cmUgdmVyaWZpY2F0aW9uIG9jY3VycmluZyBvbiBhbHJlYWR5LXBh cnNlZCBKU09OIHZhbHVlcywgc28gaG93IGl0IHdhcyByZXByZXNlbnRlZCB3aGVuIGl0IHdhcyBz ZXJpYWxpemVkIHNob3VsZCAoaWRlYWxseSkgYmUgbW9vdC48YnI+DQo8YnI+DQpPbiBUdWUsIDIw MTMtMDItMTkgYXQgMTY6MDIgLTA4MDAsIFRpbSBCcmF5IHdyb3RlOiA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+WWVzLCBJ IGd1ZXNzIEkgZGlkIHNvcnQgb2Ygc3RyYXdtYW4tc3VnZ2VzdCBiYW5uaW5nIFx1eHh4eC4mbmJz cDsgV2hpY2ggY2xlYXJseSBkb2Vzbid0IGZseS4mbmJzcDsgU28sIHR3byBzdWdnZXN0aW9uczo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4tIFx1eHh4eCBpcyBvbmx5IGFsbG93ZWQgZm9yIGNoYXJz IHRoYXQgbXVzdCBiZSBlc2NhcGVkIHBlciB0aGUgSlNPTiBzcGVjPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gXHV4eHh4IGlzIGZyZWVseSBh bGxvd2VkLCBidXQgdGhlIFx1eHh4eCBpcyBjb25zaWRlcmVkIHRvIHJlcHJlc2VudCBhIHNpbmds ZSBjb2RlcG9pbnQsIGFuZCBhbGwgY29tcGFyaXNvbi9oYXNoaW5nIG9wZXJhdGlvbnMgaGF2ZSB0 byBiZSBjb25kdWN0ZWQgY29kZXBvaW50LWJ5LWNvZGVwb2ludDxicj4NCjxicj4NCkkgdGhpbmsg SSBwcm9iYWJseSBzdXBwb3J0IHRoZSBmaXJzdCwgYmVjYXVzZSBpdCBkb2VzIGFsbG93IGNvbXBh cmlzb24gdXNpbmcgc3RyY21wKCkgb3IgZXF1aXZhbGVudC4gVGhhdCdzIGFzc3VtaW5nIHRoYXQg YzE0biBpcyBpbiBmYWN0IHdvcnRoIGRvaW5nLiAtVA0KPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmViIDE5LCAy MDEzIGF0IDM6NTIgUE0sIEpvZSBIaWxkZWJyYW5kIChqaGlsZGVicikgJmx0OzxhIGhyZWY9Im1h aWx0bzpqaGlsZGVickBjaXNjby5jb20iPmpoaWxkZWJyQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm9yIHdhcyBJIHN1Z2dlc3Rp bmcgd2UgZG8gc28uPGJyPg0KPGJyPg0KSSB3YXMgc3VnZ2VzdGluZyB0aGF0IGlmIHlvdSB3YW50 IHRvIGdldCBcdTAwMDAgLSBcdTAwMWYsIGV4Y2x1ZGluZzxicj4NClx1MDAwOChcYiksIFx1MDAw OShcdCksIFx1MDAwYShcbiksIFx1MDAwYyhcZiksIGFuZCBcdTAwMGQoXHIpIGludG8gdGhlPGJy Pg0KY2Fub25pY2FsaXplZCBvdXRwdXQsIHlvdSBoYXZlIHRvIHVzZSB0aGUgXHUgbm90YXRpb24s IHdoaWNoIG1lYW5zIHdlPGJyPg0KY2FuJ3Qgb3V0bGF3IFx1IG5vdGF0aW9uIGVudGlyZWx5IGlu IHRoZSBjYW5vbmljYWxpemVkIGZvcm0sIGFzIHNvbWUgb2YgdXM8YnI+DQp0aG91Z2h0IFRpbSBo YWQgc3VnZ2VzdGVkIGluIHRoZSBmaXJzdCBwbGFjZS48YnI+DQo8YnI+DQpOb3RlLCBJIHdhcyB3 cm9uZyBhYm91dCBcdTAwMDAgYmVpbmcgdGhlIG9ubHkgY29kZXBvaW50IHdlIGNhcmUgYWJvdXQu PGJyPg0KRnJvbSBzZWN0aW9uIDIuNSBvZiA0NjI3Ojxicj4NCjxicj4NCiZxdW90O0FsbCBVbmlj b2RlIGNoYXJhY3RlcnMgbWF5IGJlIHBsYWNlZCB3aXRoaW4gdGhlPGJyPg0KJm5ic3A7ICZuYnNw O3F1b3RhdGlvbiBtYXJrcyBleGNlcHQgZm9yIHRoZSBjaGFyYWN0ZXJzIHRoYXQgbXVzdCBiZSBl c2NhcGVkOjxicj4NCiZuYnNwOyAmbmJzcDtxdW90YXRpb24gbWFyaywgcmV2ZXJzZSBzb2xpZHVz LCBhbmQgdGhlIGNvbnRyb2wgY2hhcmFjdGVycyAoVSYjNDM7MDAwMDxicj4NCiZuYnNwOyAmbmJz cDt0aHJvdWdoIFUmIzQzOzAwMUYpLiZxdW90OyA8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCjxicj4NCjxicj4NCk9uIDIvMTkvMTMgNDo0MiBQTSwgJnF1b3Q7VGltIEJyYXkmcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0YnJheUB0ZXh0dWFsaXR5LmNvbSI+dGJyYXlAdGV4dHVh bGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7SSBoYXZlbsK5dCBoZWFyZCBh bnlvbmUgc2F5aW5nIFUmIzQzOzAwMDAgc2hvdWxkIGJlIGlsbGVnYWwgaW4gSlNPTi4gJm5ic3A7 SXTCuXMgdG9vPGJyPg0KJmd0O2xhdGUgdG8gcmVkZXNpZ24gSlNPTi4gLVQ8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7T24gVHVlLCBGZWIgMTksIDIwMTMgYXQgMzoxMyBQ TSwgRnJhbmNpcyBHYWxpZWd1ZTxicj4NCiZndDsmbHQ7PGEgaHJlZj0ibWFpbHRvOmZnYWxpZWd1 ZUBnbWFpbC5jb20iPmZnYWxpZWd1ZUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7 PGJyPg0KJmd0O09uIFdlZCwgRmViIDIwLCAyMDEzIGF0IDEyOjA4IEFNLCBKb2UgSGlsZGVicmFu ZCAoamhpbGRlYnIpPGJyPg0KJmd0OyZsdDs8YSBocmVmPSJtYWlsdG86amhpbGRlYnJAY2lzY28u Y29tIj5qaGlsZGVickBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Wy4uLl08YnI+ DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDtIZSBtZWFu cyAmcXVvdDtcdTAwMDAgaXMgYW4gZXhjZXB0aW9uIHRvIFRpbSdzIHByb3Bvc2VkICdmb3JiaWQg ZXNjYXBpbmcnPGJyPg0KJmd0OyZndDsmZ3Q7cnVsZSZxdW90Oy48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IEV4YWN0bHkuICZuYnNwO0l0J3MgdGhlIG9ubHkgY29kZSBwb2ludCB0aGF0IEkg a25vdyBvZiB0aGF0IE1VU1QgYmUgZXNjYXBlZDxicj4NCiZndDsmZ3Q7IHVzaW5nIFx1eHh4eCBu b3RhdGlvbiB3aGVuIHNlcmlhbGl6ZWQgKGVpdGhlciBjYW5vbmljYWxseSBvciBvdGhlcndpc2Up Ljxicj4NCiZndDsmZ3Q7IEFsbCBvZiB0aGUgb3RoZXIgY29kZXBvaW50cyB0aGF0IG5lZWQgdG8g YmUgZXNjYXBlZCBoYXZlIFx4IHZlcnNpb25zLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7T0ssIGJ1dCB3aHkgc2hvdWxkIGl0IGJlIGNvbnNpZGVyZWQgaWxsZWdh bCBhdCBhbGw/IEFueSBBU0NJSTxicj4NCiZndDtjaGFyYWN0ZXIgaXMgcmVwcmVzZW50YWJsZSBi eSBzdWNoIGEgc2VxdWVuY2UsIGl0IGp1c3QgaGFwcGVucyB0aGF0IDA8YnI+DQomZ3Q7Y2FuIHdo ZXJlIEFTQ0lJIGNhbid0Li4uIEkgZG9uJ3Qgc2VlIHRoaXMgYXMgYSByZWFzb24gdG8gb3V0bGF3 IHRoaXM8YnI+DQomZ3Q7cGFydGljdWxhciBzZXF1ZW5jZS4uLiBPciB0aGVyZSBpcyBzb21ldGhp bmcgSSBkb24ndCB1bmRlcnN0YW5kIGluPGJyPg0KJmd0O3lvdXIgYXJndW1lbnQuPGJyPg0KJmd0 Ozxicj4NCiZndDstLTxicj4NCiZndDtGcmFuY2lzIEdhbGllZ3VlLCA8YSBocmVmPSJtYWlsdG86 ZmdhbGllZ3VlQGdtYWlsLmNvbSI+ZmdhbGllZ3VlQGdtYWlsLmNvbTwvYT48YnI+DQomZ3Q7VHJ5 IG91dCB5b3VyIEpTT04gU2NoZW1hczo8YnI+DQomZ3Q7PGEgaHJlZj0iaHR0cDovL2pzb24tc2No ZW1hLXZhbGlkYXRvci5oZXJva3VhcHAuY29tIj5odHRwOi8vanNvbi1zY2hlbWEtdmFsaWRhdG9y Lmhlcm9rdWFwcC5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij4mZ3Q7Jmx0OzxhIGhyZWY9Imh0dHA6Ly9qc29uLXNjaGVtYS12YWxpZGF0b3IuaGVyb2t1 YXBwLmNvbSI+aHR0cDovL2pzb24tc2NoZW1hLXZhbGlkYXRvci5oZXJva3VhcHAuY29tPC9hPiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCjxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0 eWxlPSJjb2xvcjojODg4ODg4Ij4tLTwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4 ODg4OCI+Sm9lIEhpbGRlYnJhbmQ8L3NwYW4+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5qc29uIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1h aWx0bzpqc29uQGlldGYub3JnIj5qc29uQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vanNvbiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qc29uPC9hPjxvOnA+PC9vOnA+ PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B168042967394367477E41TK5EX14MBXC284r_-- From fgaliegue@gmail.com Tue Feb 19 16:30:05 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB30621F87FF for ; Tue, 19 Feb 2013 16:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJGjYX0CYg6z for ; Tue, 19 Feb 2013 16:30:05 -0800 (PST) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id D3E2021F86F4 for ; Tue, 19 Feb 2013 16:30:04 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id a13so3103199eaa.7 for ; Tue, 19 Feb 2013 16:30:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=waBUnq6Rf/W2QmcP/KAWsm6VILVlT9eKGMi4p9NThow=; b=WLMS/71Lv2lezKiysMQ6oAkWDJ+wJ3QEwy5oRJLVIeRkB04xUdgmesLue2zHOpxrr4 42wiFPWXRWcF2Gjyra1OTZ5mzxDBhsPi13tZtl0xXpd3u0+PAMd5TIOFbehqdjdN0ZDo Y+QG0F7Z7QElx32gYps73flh9MYEMY/ymgjMKUukdhN2YfkMTSxxDUD7b/q2CEWm9FKC K6xsKvmlf7NUCyepR6WzwdNpS6qDLU6dM0mWY6fzl8jqWtTfUQ9d75KgdUjq1XBSIj41 DMZcxXVigTaN2QSiWE9bc0tcAG80a8aQQOa5FiH2dSwwpGy3RQG8jMBD1Gsirj4YMm2S OzSA== MIME-Version: 1.0 X-Received: by 10.14.209.131 with SMTP id s3mr62289782eeo.26.1361320191835; Tue, 19 Feb 2013 16:29:51 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 16:29:51 -0800 (PST) In-Reply-To: <1361319479.9790.36.camel@pbryan-wsl.internal.salesforce.com> References: <1361319479.9790.36.camel@pbryan-wsl.internal.salesforce.com> Date: Wed, 20 Feb 2013 01:29:51 +0100 Message-ID: From: Francis Galiegue To: "Paul C. Bryan" Content-Type: text/plain; charset=UTF-8 Cc: json@ietf.org Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 00:30:05 -0000 On Wed, Feb 20, 2013 at 1:17 AM, Paul C. Bryan wrote: > Should two representations of the same JSON (string) value be c14n'ed > differently? I think not*. > > If not, then I think comparisons would need to occur by parsing JSON strings > into Unicode codepoints. > +1 on that. I see no reason why "a" and "\u0061" should be treated differently at all. Or I have completely misundertood the point... -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From nico@cryptonector.com Tue Feb 19 16:31:36 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF1921F8881 for ; Tue, 19 Feb 2013 16:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.713 X-Spam-Level: X-Spam-Status: No, score=-3.713 tagged_above=-999 required=5 tests=[AWL=-1.736, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsItKvCSoG7r for ; Tue, 19 Feb 2013 16:31:35 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id DB11921F8878 for ; Tue, 19 Feb 2013 16:31:35 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id A87571F0078 for ; Tue, 19 Feb 2013 16:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=g22c/tTFA4CLMwIsfPlb q+BeHr8=; b=VgT/ccgy4gfT5ctEwRAoTuSWmUapcWViSUfxycq32QcV9UP62hdB Mf0sD74Z2WV6D6lgKVnWmn9hSnFM3I2SVG5AQDfHyW6d+ntdE5XyHwkoj72yXYhE zUHExX/1SYflouvTHhJSOXTQXkN6h08mhRB34X5ADPQw8wJSnO3DSNg= Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 7B2541F0014 for ; Tue, 19 Feb 2013 16:31:35 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id 17so9342766iea.12 for ; Tue, 19 Feb 2013 16:31:34 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.152.132 with SMTP id uy4mr9408205igb.62.1361320294890; Tue, 19 Feb 2013 16:31:34 -0800 (PST) Received: by 10.64.102.201 with HTTP; Tue, 19 Feb 2013 16:31:34 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367477E41@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <1361319479.9790.36.camel@pbryan-wsl.internal.salesforce.com> <4E1F6AAD24975D4BA5B168042967394367477E41@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 18:31:34 -0600 Message-ID: From: Nico Williams To: Mike Jones Content-Type: text/plain; charset=UTF-8 Cc: "Paul C. Bryan" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 00:31:37 -0000 On Tue, Feb 19, 2013 at 6:23 PM, Mike Jones wrote: > As background, the JOSE specs require that equality comparisons for members > be done as a comparison of Unicode code points, with no normalization or > case folding performed. See > http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#section-8.3. Was that because normalization is hard, mostly useless (most input strings will already be NFC anyways), or for some other reason? Nico -- From fgaliegue@gmail.com Tue Feb 19 16:33:51 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A6621F874E for ; Tue, 19 Feb 2013 16:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND8MmBlw93Ob for ; Tue, 19 Feb 2013 16:33:51 -0800 (PST) Received: from mail-ea0-f171.google.com (mail-ea0-f171.google.com [209.85.215.171]) by ietfa.amsl.com (Postfix) with ESMTP id CE5A321F873C for ; Tue, 19 Feb 2013 16:33:50 -0800 (PST) Received: by mail-ea0-f171.google.com with SMTP id c13so3159701eaa.2 for ; Tue, 19 Feb 2013 16:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=a60f7iQdJ/dPP5TPWdy8hrTN/rH73ELpynTrxk8qgHw=; b=ee+NXJh3hv9fHCRVQU8yk/HAmt6hZcBQB0WDn4dOAmZ/t3VQJ12pBggToTn87B4wnD +1x/ogKHLI/BfvKKalMkso3Jh+gYFOKBYsSPpByvEXY7AOKtgXZ06L3K90vkWXKh0rBb MofbR1rH/dXtZFRXQAl5sNLRqGw1Fuf5gIL+ZoYmMZpu2xanhDnAjHdpf5hrKa9TmMkY 5IK9rIRdFz3wjW3IXBd0WojePGe2xzgfxIHYiWeJm7d22iTQ7lyOIQlJA1oVEOm9RK1u PlFrZXRhoz3B78DbETxNYNnZJ5MundU6dvMb08M+vEECf4Od6Rp40zICcvqlA/02VUV+ cdYg== MIME-Version: 1.0 X-Received: by 10.14.179.5 with SMTP id g5mr62660169eem.41.1361320429968; Tue, 19 Feb 2013 16:33:49 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 16:33:49 -0800 (PST) In-Reply-To: <0A83DAEF-3C96-4659-8554-89247EB6A195@vpnc.org> References: <0A83DAEF-3C96-4659-8554-89247EB6A195@vpnc.org> Date: Wed, 20 Feb 2013 01:33:49 +0100 Message-ID: From: Francis Galiegue To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] About JSON equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 00:33:51 -0000 On Wed, Feb 20, 2013 at 1:23 AM, Paul Hoffman wrote= : [...] >> >> That is what I am asking. > > OK, then. I fully disagree. > >> I believe the more JSON is used, the more >> people will want to "compare" JSON values, whatever they may be (and a >> hint again: please make RFC 4627bis allow to transfer _any_ JSON >> value, not just arrays and objects). > > JSON has been used for many, many years without any strong need for such = a comparison semantic in the base spec. > > It is fine for there to be a separate standard that is usable by applicat= ions that want to compare JSON documents; the rest of the world (and that s= eems like the large majority) can ignore the comparison document and just u= se the base spec to understand how to create and consume JSON objects and J= SON files. > > --Paul Hoffman Point taken. Equality defined in the JSON RFC itself is not the way to go, and if such an equality is defined, it could be defined in another document. Now, is there a need for such a document? --=20 Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From paul.hoffman@vpnc.org Tue Feb 19 16:47:24 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7FA21F87CD for ; Tue, 19 Feb 2013 16:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bkdeqQi2WJg for ; Tue, 19 Feb 2013 16:47:23 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CA03A21F87C3 for ; Tue, 19 Feb 2013 16:47:23 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1K0lMlk056314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 19 Feb 2013 17:47:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <711B5AAF-4CAB-414C-8553-C84493FB005E@vpnc.org> Date: Tue, 19 Feb 2013 16:47:22 -0800 To: "json@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [Json] Proposed document set from this WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 00:47:24 -0000 Straw-man, personal opinions. 1) JSON base, 4627bis Target: current JSON users Current: grammar, encoding, parser rules, generator rules, MIME type = registration) New: Internet transfer rules, list of changes from 4627 2) JSON value comparison Target: systems that want to compare two JSON values (usually = objects) for equivalence Character equivalence rules Unicode normalization (if any) Numeric normalization (if any) 3) JSON document description Target: systems that want to be sure an incoming document is what = they expect it to be Might be schema-like, might just be content rules Both #2 and #3 are useful, but to a much smaller audience than #1. #2 = and #3 are also much more exciting than #1, but that excitement in the = XML world has led to efforts that have been actively harmful. 4) JSON patching and testing Target: systems that use JSON as a data model and need to change data #4 is even more marginal than #2 and #3, but would need to be done in a = JSON-focused WG. 5+) JSON format for X Target: systems that use data of type X (personal information, = calendar items, DNS records, ...) The WG might *not* be chartered to do any of #5+, and each X needs its = own mailing list. Draft updates might be mentioned on the WG mailing = list. --Paul Hoffman= From James.H.Manger@team.telstra.com Tue Feb 19 16:57:58 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6587C21F85DA for ; Tue, 19 Feb 2013 16:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2yJDbwm7ZvL for ; Tue, 19 Feb 2013 16:57:58 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 879FA21F85D9 for ; Tue, 19 Feb 2013 16:57:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,698,1355058000"; d="scan'208";a="118875932" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 20 Feb 2013 11:57:56 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6991"; a="113025009" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcdvi.tcif.telstra.com.au with ESMTP; 20 Feb 2013 11:57:56 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Wed, 20 Feb 2013 11:57:55 +1100 From: "Manger, James H" To: "json@ietf.org" Date: Wed, 20 Feb 2013 11:57:54 +1100 Thread-Topic: Canonicalization Thread-Index: AQHODuJJD2QYqWyDNUmeQU+v/KxthpiB3nLA Message-ID: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 00:57:58 -0000 V2Ugc2hvdWxkIGF2b2lkIHRoZSBuZWVkIHRvIGNhbm9uaWNhbGl6ZSBKU09OIHdoZW5ldmVyIHBv c3NpYmxlLCBidXQgdGhlcmUgYXJlIGVub3VnaCBlZmZvcnRzIHRvIGRlZmluZSBhIGNhbm9uaWNh bCBmb3JtIHRoYXQgaXQgd291bGQgYmUgd29ydGggc3RhbmRhcmRpemluZyBvbmUuDQoNClN0cmlu Z3M6DQpFc2NhcGluZyBpcyBtYW5kYXRvcnkgZm9yIGNvbnRyb2xzIGNoYXJzLCBkb3VibGUgcXVv dGUsIGFuZCBiYWNrc2xhc2ggKCV4MDAtMUYgLyAleDIyIC8gJXg1QykuDQpUaGUgc2ltcGxlc3Qg c3RyaW5nIGNhbm9uaWNhbGl6YXRpb24gcnVsZSB3b3VsZCBiZSB0byBlc2NhcGUgdGhvc2UgMzQg Y2hhcnMgYW5kIG5vIG90aGVycy4gQSBydWxlIHRoYXQgbWlnaHQgYmUgc2xpZ2h0bHkgbmljZXIg Zm9yIHBlb3BsZSAoYW5kIGhlbmNlIHdvcnRoIHRoZSBmZXcgZXh0cmEgbGluZXMgb2YgY29kZSkg d291bGQgYmUgdG8gYWx3YXlzIHVzZSB0aGUgNyBceCBlc2NhcGVzIGZvciB0aG9zZSA3IGNoYXJz LCBhbHdheXMgdXNlIFx1eHh4eCBmb3IgdGhlIHJlc3Qgb2YgJXgwMC0xRiwgYW5kIG5ldmVyIHVz ZSBpdCBmb3IgYW55IG90aGVyIGNoYXJzLiBJIHdvdWxkIGJlIHRlbXB0ZWQgdG8gZHJvcCBcLyBm cm9tIHRoZSBsaXN0IG9mIHNldmVuIChvbmx5IGluIHRoZSBjYW5vbmljYWxpemF0aW9uIHJ1bGVz KSwgYmVjYXVzZSAvIGlzIHNvIGNvbW1vbiBpbiBVUklzIGV0Yy4NCg0KT2JqZWN0czoNClNvcnRp bmcgc3RyaW5nIG5hbWVzIHRvIGNhbm9uaWNhbGl6ZSBhbiBvYmplY3QgbmVlZHMgYSBmZXcgbW9y ZSB3b3Jkcy4NClByZXN1bWFibHkgc29ydGluZyBvY2N1cnMgb24gdGhlIGxvZ2ljYWwgc3RyaW5n cywgbm90IHRoZSAoY2Fub25pY2FsbHkpIGVuY29kZWQgdmVyc2lvbnMuIFNvIHsiYVwiYiI6MSwi YSNiIjoyfSBpcyBpbiBjYW5vbmljYWwgZm9ybSAoIihVKzIyKSA8ICMoVSsyMykgPCBcKFUrNUMp KS4NClByZXN1bWFibHkgc29ydGluZyB1c2VzIFVuaWNvZGUgY29kZSBwb2ludHMsIG5vdCBVVEYt MTYgd29yZHMsIG9yIFVURi04IGJ5dGVzLiBTbyB7Ilx1RkZFMFx1RkZFMSI6MywiXHVEODM0XHVE RDFFIjo0fSBpcyBpbiB0aGUgcmlnaHQgb3JkZXIgKDB4RkZFMCA8IDB4MDFEMTFFKSwgdGhvdWdo dCB0aGUgY2Fub25pY2FsIGZvcm0gd291bGQgdXNlIFVURi04IG5vdCBcdXh4eHggZm9yIHRoZSAz IGNoYXJhY3RlcnMuDQpbVGhlIDIxLWJ5dGUgY2Fub25pY2FsIGZvcm0gd291bGQgYmUgKGluIGhl eCk6DQo3QiAyMiBFRkJGQTAgRUZCRkExIDIyIDNBIDMzIDJDIDIyIEYwOUQ4NDlFIDIyIDNBIDM0 IDdEXQ0KDQpOdW1iZXJzOg0KMCwgMSwgMWUzLCAyLjMzNGUtNSwgMS41ZTYgYXJlIHRoZSBzb3J0 IG9mIGNhbm9uaWNhbCBmb3JtIG51bWJlcnMgc2hvdWxkIGhhdmUuIEkgZG9u4oCZdCBsaWtlIDAu MEUwIGZvciB6ZXJvIGFzIHBlciBkcmFmdC1zdGF5a292LWh1LWpzb24tY2Fub25pY2FsLWZvcm0t MDAgLS0gYSBwZXJzb24gd291bGQgbmV2ZXIgd3JpdGUgdGhhdC4gVGhhdCBkcmFmdCBhbHNvIGFs bG93cyBhbnkgbnVtYmVyIG9mIHRyYWlsaW5nIDDigJlzIChlZyAxLjIwMDAwMGUtMiksIHdoaWNo IGlzIGEgYnVnLiBBIGNhbm9uaWNhbCBmb3JtIHNob3VsZCBkcm9wIHRoZSBleHBvbmVudCB3aGVu IGl0IGlzIHplcm8sIGFuZCBkcm9wIHRoZSBkZWNpbWFsIHBvaW50IHdoZW4gdGhlcmUgaXMgbm90 aGluZyBhZnRlciBpdC4NCkEgcmVnZXggZm9yIG51bWJlcnMgaW4gY2Fub25pY2FsIGZvcm06DQoN CjB8LT9bMS05XShcLlswLTldKlsxLTldKT8oZS0/WzEtOV1bMC05XSopPw0KDQoNClNvIGRyYWZ0 LXN0YXlrb3YtaHUtanNvbi1jYW5vbmljYWwtZm9ybSBuZWVkcyBhIGZldyBjaGFuZ2VzIGluIG15 IG1pbmQsIGJ1dCBpcyBhcyBnb29kIGEgc3RhcnRpbmcgcG9pbnQgYXMgYW55Lg0KDQotLQ0KSmFt ZXMgTWFuZ2VyDQo= From paul.hoffman@vpnc.org Tue Feb 19 17:00:07 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140A521F86EA for ; Tue, 19 Feb 2013 17:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLHTFfHN6YbR for ; Tue, 19 Feb 2013 17:00:06 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF8321F86D5 for ; Tue, 19 Feb 2013 17:00:06 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1K105nq056737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 19 Feb 2013 18:00:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 19 Feb 2013 17:00:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> To: "json@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 01:00:07 -0000 One only needs to canonicalize at the time when one is comparing two = objects. We should say *nothing* that suggests that JSON sent on the = wire should be canonicalized at all. --Paul Hoffman= From fgaliegue@gmail.com Tue Feb 19 17:00:35 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652BC21F86FC for ; Tue, 19 Feb 2013 17:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tu82KS4e2YUb for ; Tue, 19 Feb 2013 17:00:34 -0800 (PST) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3082D21F86F0 for ; Tue, 19 Feb 2013 17:00:34 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so3861211eei.21 for ; Tue, 19 Feb 2013 17:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=icDl94A36aWZC2Qmk6NiB65BNEHMWCaCs7DNLnNZ7U8=; b=W5eJMicZXT9cy1FCGmV+elVvfzOaSO23NpYiSyzOxS80nXyrAeocZ8uPKd1cSbs4uL nKZ+hA49ZpJ7sMGer0VjWAz/p9PeAwLKW1flFSEpn1mBWri2abN3fKqa6nwC+lQdndot 0+qhRH4Vq0b2ZwMQA1upwmN07pA3BmCS7u1IYVQYGvpUowngGjI660pg8XudTOrbtYCV vMssi3SKMFcnx+g7lBA1Blb2YjhUmTOtwh5wTt7DOMhB1iuDFl+iG98LL4SPaph1m4oe J6JMwA7NgMMdJ3wEp70SEFaPNoG+5R6FyBpTWC3odCEZmfR+L5qzMPjzBbtCngk7qqEm FiRA== MIME-Version: 1.0 X-Received: by 10.14.194.198 with SMTP id m46mr62564991een.8.1361322033375; Tue, 19 Feb 2013 17:00:33 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 17:00:33 -0800 (PST) In-Reply-To: <711B5AAF-4CAB-414C-8553-C84493FB005E@vpnc.org> References: <711B5AAF-4CAB-414C-8553-C84493FB005E@vpnc.org> Date: Wed, 20 Feb 2013 02:00:33 +0100 Message-ID: From: Francis Galiegue To: Paul Hoffman , json@ietf.org Content-Type: text/plain; charset=UTF-8 Cc: geraintluff@gmail.com Subject: Re: [Json] Proposed document set from this WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 01:00:35 -0000 Hello, On Wed, Feb 20, 2013 at 1:47 AM, Paul Hoffman wrote: > Straw-man, personal opinions. > Even within this scope, I feel the need to comment as the author of proposals for #2 and #3 ;) [...] > > 2) JSON value comparison > Target: systems that want to compare two JSON values (usually objects) for equivalence > Character equivalence rules > Unicode normalization (if any) > Numeric normalization (if any) > > 3) JSON document description > Target: systems that want to be sure an incoming document is what they expect it to be > Might be schema-like, might just be content rules > > Both #2 and #3 are useful, but to a much smaller audience than #1. #2 and #3 are also much more exciting than #1, but that excitement in the XML world has led to efforts that have been actively harmful. > This is why I regard input to the current JSON Schema I-Ds as especially critical. I _think_ right now the core and validation specs can be steered "back into shape" before it is too late. The hyper schema specification (author CC:ed) covers a much larger ground, and I am not sure whether it enters the scope of this particular working group. And yes, the current core specification has an attempt at #2. And as has been coined on this list already, it can be improved upon. > 4) JSON patching and testing > Target: systems that use JSON as a data model and need to change data > > #4 is even more marginal than #2 and #3, but would need to be done in a JSON-focused WG. > I fail to see how "and testing" differs from #3 here? Are you referring to the "test" operation of the current JSON Patch I-D? Cheers, -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From nico@cryptonector.com Tue Feb 19 17:11:53 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185E121F8853 for ; Tue, 19 Feb 2013 17:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.683 X-Spam-Level: X-Spam-Status: No, score=-3.683 tagged_above=-999 required=5 tests=[AWL=-1.706, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0gjw8xJCImp for ; Tue, 19 Feb 2013 17:11:52 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2A821F8840 for ; Tue, 19 Feb 2013 17:11:52 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 5794531805C for ; Tue, 19 Feb 2013 17:11:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=AJo05mD7syGFl+v45J0N KlnOLmY=; b=jrVAMd86U2LhljQ/a1ZSondBr5EL036YbvZ/gluEMQHp/kpwfSe8 syPuT7w/Lwd2NJaVg8BCYDx1KJjNhL9toxS+TuIpsjCz9SGlBm6pkknPvTTK4C+G rfu04WXpZ9uAsQeO1jbLd7xS8eNCLfo+fGYbd71XwZoqmOEhSvih4Fg= Received: from mail-ia0-f175.google.com (mail-ia0-f175.google.com [209.85.210.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 3798E318059 for ; Tue, 19 Feb 2013 17:11:52 -0800 (PST) Received: by mail-ia0-f175.google.com with SMTP id r4so6618289iaj.6 for ; Tue, 19 Feb 2013 17:11:51 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.42.58.67 with SMTP id g3mr8453159ich.56.1361322711624; Tue, 19 Feb 2013 17:11:51 -0800 (PST) Received: by 10.64.102.201 with HTTP; Tue, 19 Feb 2013 17:11:51 -0800 (PST) In-Reply-To: <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> Date: Tue, 19 Feb 2013 19:11:51 -0600 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 01:11:53 -0000 On Tue, Feb 19, 2013 at 7:00 PM, Paul Hoffman wrote: > One only needs to canonicalize at the time when one is comparing two objects. We should say *nothing* that suggests that JSON sent on the wire should be canonicalized at all. When to canonicalize: - when you're signing something that a peer has to reconstruct independently - when you want to compare with memcmp() Note that that's not the only way to compare JSON data! One could parse into native objects in whatever programming language one is using and then proceed to compare bit by bit. Note too that equality comparison does require saying something about Unicode normalization. The simplest thing to say about that would be that there are two types of comparison: naive, which uses memcmp()/strcmp(), and normalization-insensitive (which internally might normalize then compare or work as a normalization-insensitive comparison; the latter performs better). Note that the first use of c14n given above also requires saying something about normalization... When to not canonicalize: any other time. Nico -- From paul.hoffman@vpnc.org Tue Feb 19 17:21:34 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0DB21F87BB for ; Tue, 19 Feb 2013 17:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfI0i3QLEfyo for ; Tue, 19 Feb 2013 17:21:33 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3846621F8439 for ; Tue, 19 Feb 2013 17:21:20 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1K1LJ51057350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 19 Feb 2013 18:21:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Tue, 19 Feb 2013 17:21:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> To: "json@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 01:21:34 -0000 On Feb 19, 2013, at 5:11 PM, Nico Williams = wrote: > On Tue, Feb 19, 2013 at 7:00 PM, Paul Hoffman = wrote: >> One only needs to canonicalize at the time when one is comparing two = objects. We should say *nothing* that suggests that JSON sent on the = wire should be canonicalized at all. >=20 > When to canonicalize: >=20 > - when you're signing something that a peer has to reconstruct = independently Canonicalizing is part of the signature process, not part of the JSON = creation process. The spec that specifies how to sign JSON will pick = what to do about canonicalization; the JOSE WG is dealing with this. > - when you want to compare with memcmp() Sure. That's what I said above. --Paul Hoffman= From fgaliegue@gmail.com Tue Feb 19 17:28:27 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189C121F8645 for ; Tue, 19 Feb 2013 17:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbu3SbDFG72W for ; Tue, 19 Feb 2013 17:28:26 -0800 (PST) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id B149621F85EB for ; Tue, 19 Feb 2013 17:28:15 -0800 (PST) Received: by mail-ee0-f46.google.com with SMTP id e49so3826507eek.5 for ; Tue, 19 Feb 2013 17:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=h0/jH/WlBU4keSZFVHfdIUUduZ3BJ7BbVgWCnVmdcXs=; b=UUKG1WGESfIOKNbZl0pXMVukDD8/FXhHq+p232H6Ssjb1adGnE/gH2hjmtWpRrQMlJ Ih6wMZfs1PoXPosvH0cUhS1esnq/fkCp4O9MXDYzBZixpvN4EUan37NGt8QIWgHXH6O4 pBbwnxcssUJEPhoNcS5oxi0f09FxAnrLxsW7mwFYH0ZjT4c9zoWtZuZfpuRioeUfBktp 9b5z1y7BploWcPS1HJPifKPSsD0YCPyXDGqXj/lcIm9iRhnWYpJwSOjl51RBvF4DY12w Uh+aRGmgZHYeYObilIFCEYSXKVapzvWaEv1PAZNlVRlEtlMKXZ3ZegJpgd/csXBL0nbN +iCg== MIME-Version: 1.0 X-Received: by 10.14.183.67 with SMTP id p43mr62802941eem.10.1361323694834; Tue, 19 Feb 2013 17:28:14 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 17:28:14 -0800 (PST) In-Reply-To: <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> Date: Wed, 20 Feb 2013 02:28:14 +0100 Message-ID: From: Francis Galiegue To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 01:28:27 -0000 On Wed, Feb 20, 2013 at 2:21 AM, Paul Hoffman wrote: [snip] > Canonicalizing is part of the signature process, not part of the JSON creation process. The spec that specifies how to sign JSON will pick what to do about canonicalization; the JOSE WG is dealing with this. > Just curious: how shoud signing require canonicalization in any way? As long as you have a media type and an encoding, the content is fully defined, right? How would JSON be any different than, say, text/plain here? AFAIK, text/plain has never required any "canonicalization" of any kind... -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From pbryan@anode.ca Tue Feb 19 17:32:57 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3617621F86CD for ; Tue, 19 Feb 2013 17:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7OXWf6VLJqc for ; Tue, 19 Feb 2013 17:32:56 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id A22C821F865B for ; Tue, 19 Feb 2013 17:32:56 -0800 (PST) Received: from [10.126.22.27] (unknown [204.14.239.147]) by maple.anode.ca (Postfix) with ESMTPSA id DCF076174; Wed, 20 Feb 2013 01:32:55 +0000 (UTC) From: "Paul C. Bryan" To: Francis Galiegue In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> Content-Type: multipart/alternative; boundary="=-D0GxIhupBuiCHuJnpGqN" Date: Tue, 19 Feb 2013 17:32:54 -0800 Message-ID: <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 01:32:57 -0000 --=-D0GxIhupBuiCHuJnpGqN Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Because in some cases, there's no guarantee that the JSON value being verified will be transmitted identically as an octet-string. Canonicalization, in theory, allows it to be represented during signature verification the same way it was when it was originally signed. I've seen some (ugly) ways of working around this by base64-encoding the entire JSON value and putting it in a JSON string. Paul On Wed, 2013-02-20 at 02:28 +0100, Francis Galiegue wrote: > On Wed, Feb 20, 2013 at 2:21 AM, Paul Hoffman wrote: > [snip] > > Canonicalizing is part of the signature process, not part of the JSON creation process. The spec that specifies how to sign JSON will pick what to do about canonicalization; the JOSE WG is dealing with this. > > > > Just curious: how shoud signing require canonicalization in any way? > As long as you have a media type and an encoding, the content is fully > defined, right? How would JSON be any different than, say, text/plain > here? AFAIK, text/plain has never required any "canonicalization" of > any kind... > --=-D0GxIhupBuiCHuJnpGqN Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Because in some cases, there's no guarantee that the JSON value being verified will be transmitted identically as an octet-string. Canonicalization, in theory, allows it to be represented during signature verification the same way it was when it was originally signed. I've seen some (ugly) ways of working around this by base64-encoding the entire JSON value and putting it in a JSON string.

Paul

On Wed, 2013-02-20 at 02:28 +0100, Francis Galiegue wrote: 
On Wed, Feb 20, 2013 at 2:21 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
[snip]
> Canonicalizing is part of the signature process, not part of the JSON creation process. The spec that specifies how to sign JSON will pick what to do about canonicalization; the JOSE WG is dealing with this.
>

Just curious: how shoud signing require canonicalization in any way?
As long as you have a media type and an encoding, the content is fully
defined, right? How would JSON be any different than, say, text/plain
here? AFAIK, text/plain has never required any "canonicalization" of
any kind...

--=-D0GxIhupBuiCHuJnpGqN-- From fgaliegue@gmail.com Tue Feb 19 17:39:44 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475F321F882A for ; Tue, 19 Feb 2013 17:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GPDMrQx3sG6 for ; Tue, 19 Feb 2013 17:39:43 -0800 (PST) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 62A2D21F8815 for ; Tue, 19 Feb 2013 17:39:43 -0800 (PST) Received: by mail-ee0-f45.google.com with SMTP id b57so3763659eek.18 for ; Tue, 19 Feb 2013 17:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TsjKDpruKzLjz25qiuyCcc1sTe/urTXOdqndZowQ7zw=; b=eQryFMQWKxjIVPxAVdM+6CHdaVV5/Lcjben+nBdch1c2EJiF5bsMtiFEsY9+gkKzCi /YDkWNUxdcuxTHYL05qDUMOq4xSLVHBiB6lk5GpR7a6jDpmHkBOeBseNB3+k3TCr2iL8 1vE180BLI6zKymzKvrNG7epvgnD/J6xBwdQVAkwDCgPWstqSExHVznJ4rnFratVwAqNB 4C5f+0dgmwcKy81wb0RAfU2sZGYFHRol5mONTh3VU9iPj7CuXofQw1Wl/4UUSxPPBC4S f3vPcXLWOVlzQqKiVIOFxMna6zP8BvCc9IkKgInd6v2jmEgURPsFrowd/k8RGtrbzbas ZvQg== MIME-Version: 1.0 X-Received: by 10.14.175.129 with SMTP id z1mr63606339eel.7.1361324382465; Tue, 19 Feb 2013 17:39:42 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 17:39:42 -0800 (PST) In-Reply-To: <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.com> References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.com> Date: Wed, 20 Feb 2013 02:39:42 +0100 Message-ID: From: Francis Galiegue To: "Paul C. Bryan" Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 01:39:44 -0000 On Wed, Feb 20, 2013 at 2:32 AM, Paul C. Bryan wrote: > Because in some cases, there's no guarantee that the JSON value being > verified will be transmitted identically as an octet-string. Given the amount of discussion generated by this topic alone, it seems that these "some cases" are more than "some". What would be such a case? > Canonicalization, in theory, allows it to be represented during signature > verification the same way it was when it was originally signed. I've seen > some (ugly) ways of working around this by base64-encoding the entire JSON > value and putting it in a JSON string. Ick. OK, well, the answer seems pretty simple: UTF-8. It is already recommended, I guess making is a MUST in RFC 4627bis will solve the issue without even the need for c14n... Nothing to lose, everything to gain. -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From mnot@mnot.net Tue Feb 19 17:54:10 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9190B21F87B2 for ; Tue, 19 Feb 2013 17:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.471 X-Spam-Level: X-Spam-Status: No, score=-105.471 tagged_above=-999 required=5 tests=[AWL=-2.872, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9LTNC6tBgZL for ; Tue, 19 Feb 2013 17:54:09 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id E450F21F87A3 for ; Tue, 19 Feb 2013 17:54:08 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.197.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6E990509B5 for ; Tue, 19 Feb 2013 20:54:03 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 20 Feb 2013 12:54:00 +1100 To: "json@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [Json] Comments on the proposed charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 01:54:11 -0000 I won't be at the JSON BoF. I may be able to participate remotely, but = in either case, I thought it'd be helpful to clearly state my position = on the current proposal for a charter = : > The JSON working group will have as its primary task the minor > revision of RFC 4627 to bring it onto the Standards Track. As noted > above, RFC 4627 is a mature and widely cited specification. The > initial goal of this work is essentially a reclassification in place, > with minimal changes. The working group will review errata and update > the document as needed to incorporate those, and will correct = significant > errors and inconsistencies, but will keep changes at this stage to a > minimum. This is necessary and good; just make sure to involve Crockford, because = he has banked up some issues, I believe, and can help illuminate some of = the subtleties around the current spec. > During that work, the working group may collect change requests, and > may choose to propose a more significant revision of the JSON = specification > if there is rough consensus to do so. Proceeding with such a revision > will require AD approval, for which the responsible AD may require a > recharter to get community and IESG review of the proposal. I am somewhat concerned about this. If "community" means a = self-selecting group of standards nerds / corporate interests / fringe = developers, I am violently against it.=20 Yes, anyone can come to the table at the IETF, but I question whether = the wider JSON community is even aware of this effort. Have we reached = out to JSON implementers, for example? Have they joined the list? Do we = have representation from the various Open Source frameworks that use = JSON? Let's not fork JSON, please. > The working group's next priority is to address various proposals for > JSON extensions and related standards. The working group will = consider > the proposals and will select those for which there is rough consensus > to proceed. >=20 > [More needed here. This is the list of what we're currently aware of. = Do > we want to leave it open? Do we want the WG to select which ones to > proceed with and get the approval of the AD? Do we want an initial = list, > and have the WG re-charter to add others?] >=20 > Internet Drafts of current JSON-related work: > - A Language for Rules Describing JSON Content: = draft-newton-json-content-rules > - A Convention for HTTP Access to JSON Resources: = draft-pbryan-http-json-resource > - Home Documents for HTTP APIs: draft-nottingham-json-home > - JSON Reference: draft-pbryan-zyp-json-ref > - JSON Predicate: draft-snell-json-test > - JSON Meta Object: draft-sakimura-json-meta > - JSON Merge-Patch: draft-snell-merge-patch > - JSON Activity Streams: draft-snell-activity-streams-type > - JSON Canonical Form: draft-staykov-hu-json-canonical-form > - JSON format for iCalendar: draft-kewisch-et-al-icalendar-in-json > - JSON format for vCard: draft-bhat-vcarddav-json This is a horrifically, monumentally bad idea.=20 Having a catch-all Working Group for anything that happens to use JSON = is like having one for anything that happens to use ASCII or UTF-8. It's = like shoving XML Schema, XLink, SOAP, Atom, DocBook and XHTML into the = same Working Group.=20 It's almost a guarantee that the only people who will persevere and = follow the work will be those least qualified to do so; the time and = attention of implementers and domain experts is valuable, and lumping = these together is hard to view as anything but an exclusionary tactic. = We already have one catch-all bucket with the APPSAWG, and I have = serious concerns about it; let's not repeat the experience. I know that = WGs have overhead, and it's hard to have one for each effort, but that's = a GOOD thing; it makes sure we don't start work unnecessarily. Many of the proposals discussed can (and should) go forward as = individual, Information drafts, rather than being prematurely given the = imprimatur of a standard. Only when there is broad interest and multiple = implementations should we invoke the overhead of a WG. A few things might make sense to do in such a WG, like JSON Schema = (provided we have confidence that doing so is a good thing, and we get = solid implementer involvement; e.g., I'd want to see a test suite and 3+ = implementations tracking the work). Anything domain-specific or = exploratory should be right out. Regardless of all of that - if this work does go ahead, we need a VERY = good chair. My suggestion would be someone with these sorts of skills: =20= https://www.youtube.com/watch?v=3DPWhnZI_GIgg Cheers, -- Mark Nottingham http://www.mnot.net/ From stpeter@stpeter.im Tue Feb 19 17:57:12 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725D221F883B for ; Tue, 19 Feb 2013 17:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id disS+CAsdjsq for ; Tue, 19 Feb 2013 17:57:11 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1845121F87B2 for ; Tue, 19 Feb 2013 17:57:10 -0800 (PST) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9E95A4060C for ; Tue, 19 Feb 2013 19:04:33 -0700 (MST) Message-ID: <51242D73.4010008@stpeter.im> Date: Tue, 19 Feb 2013 18:57:07 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: json@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Json] Comments on the proposed charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 01:57:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A big +1 to everything Mark said! On 2/19/13 6:54 PM, Mark Nottingham wrote: > > I won't be at the JSON BoF. I may be able to participate remotely, > but in either case, I thought it'd be helpful to clearly state my > position on the current proposal for a charter > : > >> The JSON working group will have as its primary task the minor >> revision of RFC 4627 to bring it onto the Standards Track. As >> noted above, RFC 4627 is a mature and widely cited >> specification. The initial goal of this work is essentially a >> reclassification in place, with minimal changes. The working >> group will review errata and update the document as needed to >> incorporate those, and will correct significant errors and >> inconsistencies, but will keep changes at this stage to a >> minimum. > > This is necessary and good; just make sure to involve Crockford, > because he has banked up some issues, I believe, and can help > illuminate some of the subtleties around the current spec. > > >> During that work, the working group may collect change requests, >> and may choose to propose a more significant revision of the >> JSON specification if there is rough consensus to do so. >> Proceeding with such a revision will require AD approval, for >> which the responsible AD may require a recharter to get community >> and IESG review of the proposal. > > I am somewhat concerned about this. If "community" means a > self-selecting group of standards nerds / corporate interests / > fringe developers, I am violently against it. > > Yes, anyone can come to the table at the IETF, but I question > whether the wider JSON community is even aware of this effort. Have > we reached out to JSON implementers, for example? Have they joined > the list? Do we have representation from the various Open Source > frameworks that use JSON? > > Let's not fork JSON, please. > > >> The working group's next priority is to address various >> proposals for JSON extensions and related standards. The working >> group will consider the proposals and will select those for which >> there is rough consensus to proceed. >> >> [More needed here. This is the list of what we're currently >> aware of. Do we want to leave it open? Do we want the WG to >> select which ones to proceed with and get the approval of the AD? >> Do we want an initial list, and have the WG re-charter to add >> others?] >> >> Internet Drafts of current JSON-related work: - A Language for >> Rules Describing JSON Content: draft-newton-json-content-rules - >> A Convention for HTTP Access to JSON Resources: >> draft-pbryan-http-json-resource - Home Documents for HTTP APIs: >> draft-nottingham-json-home - JSON Reference: >> draft-pbryan-zyp-json-ref - JSON Predicate: draft-snell-json-test >> - JSON Meta Object: draft-sakimura-json-meta - JSON Merge-Patch: >> draft-snell-merge-patch - JSON Activity Streams: >> draft-snell-activity-streams-type - JSON Canonical Form: >> draft-staykov-hu-json-canonical-form - JSON format for >> iCalendar: draft-kewisch-et-al-icalendar-in-json - JSON format >> for vCard: draft-bhat-vcarddav-json > > This is a horrifically, monumentally bad idea. > > Having a catch-all Working Group for anything that happens to use > JSON is like having one for anything that happens to use ASCII or > UTF-8. It's like shoving XML Schema, XLink, SOAP, Atom, DocBook > and XHTML into the same Working Group. > > It's almost a guarantee that the only people who will persevere > and follow the work will be those least qualified to do so; the > time and attention of implementers and domain experts is valuable, > and lumping these together is hard to view as anything but an > exclusionary tactic. We already have one catch-all bucket with the > APPSAWG, and I have serious concerns about it; let's not repeat the > experience. I know that WGs have overhead, and it's hard to have > one for each effort, but that's a GOOD thing; it makes sure we > don't start work unnecessarily. > > Many of the proposals discussed can (and should) go forward as > individual, Information drafts, rather than being prematurely > given the imprimatur of a standard. Only when there is broad > interest and multiple implementations should we invoke the overhead > of a WG. > > A few things might make sense to do in such a WG, like JSON Schema > (provided we have confidence that doing so is a good thing, and we > get solid implementer involvement; e.g., I'd want to see a test > suite and 3+ implementations tracking the work). Anything > domain-specific or exploratory should be right out. > > > Regardless of all of that - if this work does go ahead, we need a > VERY good chair. My suggestion would be someone with these sorts > of skills: https://www.youtube.com/watch?v=PWhnZI_GIgg > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJC1yAAoJEOoGpJErxa2piV8P/0nBhlnz/PiGL6+j7n3ccg64 ehgYCbxvMnA3IhINGsykRPy/eHoG7tEf6pjXN/YUnFGYouWFnDGwC9S0TW7EHgtL Wq3kVd8dyb6EkQj2/H7T+ZRI54QkCrnZoIYjpuJA8fdAeDETT8RzNDk14oVGsFpS unDqbqfwbX9Z9Q/GRJqzpQBtZVXjDUXe5wMoRRLlAI4OofZzXcCHgeVXrUUzo0U1 4t6Cf8ncbjcCMUouZPIQx+NlWu6B4AfQE3L3F0vzOYn1K/rNm+sfuNQXq1CZQQ2A e/bCNBCZQkI0bqrZvFeIuPHvhGY6PqnowsrM+59NfrDoXwhs6xwRuZelW1f52D+v cPWwSDUQ4UPCVdcFKzGxvnsonHH+jxcMBZ0cP/hxy28HPfaJnJT4XO+BEFBaw2Wj yWYHligrUzb+LQVnxWa0WSgqJcQ5fQLD94Wc75B6/K/lgmGUZrGvFwwGHju1m32q /b2QBVK++W9hMcnQsODHgewt/Eov+LroOgsSvYBTeAtTXrP3BN83v4mci74BoO/S 4iNuuauWBYlan7sSEDsHQjZejenb2UEsTYKM11qDihLQRE4FU7P+ucKhE+C2UhuS cxfvTGuBNAnfp1RlOC634a6kv3whuSj3mSDid+P7GDnml5VrHb+2Ce54ClgmVZkT IQxINdXDHCsBa8Fls9t+ =LbZ3 -----END PGP SIGNATURE----- From fgaliegue@gmail.com Tue Feb 19 18:04:56 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD3E21F8689 for ; Tue, 19 Feb 2013 18:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjgIbk38TkvG for ; Tue, 19 Feb 2013 18:04:55 -0800 (PST) Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9884621F8688 for ; Tue, 19 Feb 2013 18:04:55 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id i1so3070150eaa.4 for ; Tue, 19 Feb 2013 18:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=00APH2hKhuzhOQr2XSlYx14ja3aQUfgTZ7OAlWisCAI=; b=pq269Qf0pQx8fxA4/sRicTqDUu/zSWWY1B5Ibcx6DQuZgfiAzlrIUi9do2GHAIvvf1 L/rpfVxZjTOOiu8ct498b5BMeCDQ5vzt1Vb0t1mgebPR6LNWAfy70kd++QT6pSG06gDM 7Jv6M+M7S7y51DEQ39M2YuolsoKGHWm/STp2GxP8AOInKSaeP6BOAn3Tm40Sd2BBkG0V 5/OVEp5rq60XC/HiiJzdyhvKjpe2ILex+nKUg5B1FbUNK3taRuBTOyXYXesKHBdhxS7f Ws4dOpNvnhTYt5dUExGMQyWpSptB2ueRKvALB3St3maQVuUBmDZzGWhCT9fkDFgqxElH HzsQ== MIME-Version: 1.0 X-Received: by 10.14.209.131 with SMTP id s3mr63075108eeo.26.1361325894653; Tue, 19 Feb 2013 18:04:54 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 18:04:54 -0800 (PST) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.com> Date: Wed, 20 Feb 2013 03:04:54 +0100 Message-ID: From: Francis Galiegue To: "Paul C. Bryan" Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 02:04:56 -0000 On Wed, Feb 20, 2013 at 2:39 AM, Francis Galiegue wrote: [...] > > Ick. OK, well, the answer seems pretty simple: UTF-8. It is already > recommended, I guess making is a MUST in RFC 4627bis will solve the > issue without even the need for c14n... > > Nothing to lose, everything to gain. > Some more thoughts about this... Signing does not require c14n at all. Signing is totally unaware of the media type. It will sign whatever it is fed with, and does not care about what this content actually is. So, signing, say: ---- { "a": "b", "c": "d" } ---- will not yield the same result as signing: ---- { "a": "b", "c": "d" } ---- and that is pretty much normal. The scope of action as far as signing content is concerned is byte-to-byte representation. And yes, this means that UTF-16 in these two examples will yield a different signature than UTF-8. OK, but whatever encoding is used, it will be _known by the receiving end_. As such, signing in itself completely precludes the need for c14n, and as such, c14n is not needed at all since signing is not mandatory. What _is_ required is that interpretations on either point of a point-to-point transaction involving JSON data interpret this data in the same way. And as such, the more pressing matter is turning the SHOULD NOT have duplicate member names in JSON Objects into a MUST NOT. But c14n is, basically, unwarranted. At least, this is my view on the matter. -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From fgaliegue@gmail.com Tue Feb 19 18:12:01 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD1A21F874C for ; Tue, 19 Feb 2013 18:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2L56GTxHrk6e for ; Tue, 19 Feb 2013 18:12:01 -0800 (PST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8832921F86E6 for ; Tue, 19 Feb 2013 18:12:00 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e52so3680412eek.20 for ; Tue, 19 Feb 2013 18:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aEoenncdgxiCCcj8W9R0rjXq8tHXOxNSk87WvxAlzRQ=; b=Vcl10J1fqzQ7qaCACpl5eVSqDTJoWznaDA+E8gXeNVz/JpeI3eM4LVm7enHrNFBNoO QQ2pqkCcCRX608bYKj+89GtczLIq7uc16LYm/fwO+ZNb1FEGTyp0GfXTdu4hiXF040XA 1CeFt3GnjEWt4yjoE8UqO0NgPM12GxwvpLvEiyWzC8IwOZYRa9eg2Z8qMbUuO2kCvtSb Uy3rldj6QgpkKy77mM7xjygbHFnthnZ+OmXDN2jEblgkbmBe32HCBcTsG8B5iS0xipFf 4WAjl52cD9ZsFrA5IfDpiDizSfY95Qz+GfOT4hQ8F2Tm2O58bQ1xl7aukY4YeTWulO0i z/hg== MIME-Version: 1.0 X-Received: by 10.14.193.134 with SMTP id k6mr63483250een.37.1361326319585; Tue, 19 Feb 2013 18:11:59 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 18:11:59 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 03:11:59 +0100 Message-ID: From: Francis Galiegue To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] Comments on the proposed charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 02:12:01 -0000 On Wed, Feb 20, 2013 at 2:54 AM, Mark Nottingham wrote: [...] > > This is a horrifically, monumentally bad idea. > > Having a catch-all Working Group for anything that happens to use JSON is like having one for anything that happens to use ASCII or UTF-8. It's like shoving XML Schema, XLink, SOAP, Atom, DocBook and XHTML into the same Working Group. > On the other hand, a working group focussing on JSON alone and only JSON may fail to see the big picture of how JSON is actually _used_. As far as I see it, this working group does not aim at standardizing all of these, but it also needs to know how JSON is used in real life situations. And as such, it needs to be aware of whatever idea has been submitted as an I-D, or for that matter any other idea involving JSON and not the IETF (JSON-RPC comes to mind, but so does SMD, GeoJSON etc). So, I disagree: this is not a bad idea. Awareness is needed. The most clever people in the world, discussing a format, if clueless about what happens "out there", have no value in steering a format. -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From mnot@mnot.net Tue Feb 19 18:13:03 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5AA21F86E3 for ; Tue, 19 Feb 2013 18:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.433 X-Spam-Level: X-Spam-Status: No, score=-105.433 tagged_above=-999 required=5 tests=[AWL=-2.834, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Obi7sqQ8ifvd for ; Tue, 19 Feb 2013 18:13:02 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id AF74721F86E6 for ; Tue, 19 Feb 2013 18:13:02 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.197.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 88CCC509B5; Tue, 19 Feb 2013 21:13:01 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Wed, 20 Feb 2013 13:12:57 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <95501AA5-EA26-4D74-8C6B-187F0E52C524@mnot.net> References: To: Francis Galiegue X-Mailer: Apple Mail (2.1499) Cc: "json@ietf.org" Subject: Re: [Json] Comments on the proposed charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 02:13:03 -0000 There are ways to be aware of how JSON will be used without taking = responsibility for defining those uses. On 20/02/2013, at 1:11 PM, Francis Galiegue wrote: > On Wed, Feb 20, 2013 at 2:54 AM, Mark Nottingham = wrote: > [...] >>=20 >> This is a horrifically, monumentally bad idea. >>=20 >> Having a catch-all Working Group for anything that happens to use = JSON is like having one for anything that happens to use ASCII or UTF-8. = It's like shoving XML Schema, XLink, SOAP, Atom, DocBook and XHTML into = the same Working Group. >>=20 >=20 > On the other hand, a working group focussing on JSON alone and only > JSON may fail to see the big picture of how JSON is actually _used_. > As far as I see it, this working group does not aim at standardizing > all of these, but it also needs to know how JSON is used in real life > situations. And as such, it needs to be aware of whatever idea has > been submitted as an I-D, or for that matter any other idea involving > JSON and not the IETF (JSON-RPC comes to mind, but so does SMD, > GeoJSON etc). >=20 >=20 > So, I disagree: this is not a bad idea. Awareness is needed. The most > clever people in the world, discussing a format, if clueless about > what happens "out there", have no value in steering a format. >=20 > --=20 > Francis Galiegue, fgaliegue@gmail.com > Try out your JSON Schemas: http://json-schema-validator.herokuapp.com -- Mark Nottingham http://www.mnot.net/ From paul.hoffman@vpnc.org Tue Feb 19 18:19:24 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753A321F882F for ; Tue, 19 Feb 2013 18:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6fJ1Vr+tKh0 for ; Tue, 19 Feb 2013 18:19:24 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEA821F8815 for ; Tue, 19 Feb 2013 18:19:24 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1K2JMMc058793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 19 Feb 2013 19:19:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Tue, 19 Feb 2013 18:19:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.com> To: "json@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: [Json] Canonicalization vs. comparison X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 02:19:24 -0000 I was careful to call the document in my straw man "comparison" because = that is what is needed. Canonicalization is a step before comparison. It = is not needed at any other time. I propose that we let the people who care most about signature = comparison, the JOSE WG, deal with whether or not they need a = canonicalization method. If they do, they can ask us; if they don't, we = will have saved a huge amount of time. --Paul Hoffman= From paul.hoffman@vpnc.org Tue Feb 19 18:22:42 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E865221F8814 for ; Tue, 19 Feb 2013 18:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 369kuxO+wC3z for ; Tue, 19 Feb 2013 18:22:42 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 887B921F8802 for ; Tue, 19 Feb 2013 18:22:42 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1K2Me2C058890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2013 19:22:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <95501AA5-EA26-4D74-8C6B-187F0E52C524@mnot.net> Date: Tue, 19 Feb 2013 18:22:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <95501AA5-EA26-4D74-8C6B-187F0E52C524@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1499) Cc: Francis Galiegue , "json@ietf.org" Subject: Re: [Json] Comments on the proposed charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 02:22:43 -0000 > There are ways to be aware of how JSON will be used without taking = responsibility for defining those uses. --Paul Hoffman= From mamille2@cisco.com Tue Feb 19 18:28:59 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C2921F87BA for ; Tue, 19 Feb 2013 18:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pI8cb83xxF0f for ; Tue, 19 Feb 2013 18:28:59 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 05F5221F87B6 for ; Tue, 19 Feb 2013 18:28:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1862; q=dns/txt; s=iport; t=1361327339; x=1362536939; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ou3pwIAUdUU6sr8S+Vi5vvyoIS8v/V40+USJpafgUaU=; b=hbaJv+nPJklgd1N3xvlYZVf7sK+ojEFQeQ2GoW1GIqdXOEG/Ig+WbSP8 z5yoXPx8UNlaCXcno+tXfxN3AUfXjhQQ3ZDatFvX3FKK8XDrEZr9M0WLg ZibNiI9Jr2GygkJ6wy3hrML0kRZslH+r3mrCdvqCzxFJwrupvmBR9LWtR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPsyJFGtJV2Z/2dsb2JhbABFwE2BDRZzgh8BAQEDAQEBATc0CwULAgEIDgoKFBAhBgslAgQBDQUIEYdnAwkGDLJRhCMNiVqMN4IkAjEHgl9hA5RQjR6FFYJ6DYFrJBg X-IronPort-AV: E=Sophos;i="4.84,698,1355097600"; d="scan'208";a="175974485" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 20 Feb 2013 02:28:58 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1K2SwE6025327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Feb 2013 02:28:58 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 20:28:58 -0600 From: "Matt Miller (mamille2)" To: Mark Nottingham , "json@ietf.org" Thread-Topic: [Json] Comments on the proposed charter Thread-Index: AQHODw0516g5UKYB5UGMEEY3kJQ8bZiCZc6AgAAARYCAAAR5gA== Date: Wed, 20 Feb 2013 02:28:57 +0000 Message-ID: References: <95501AA5-EA26-4D74-8C6B-187F0E52C524@mnot.net> In-Reply-To: <95501AA5-EA26-4D74-8C6B-187F0E52C524@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.76.153] Content-Type: text/plain; charset="us-ascii" Content-ID: <77323ADD8BC79E4D9A58D840815F3211@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Francis Galiegue Subject: Re: [Json] Comments on the proposed charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 02:28:59 -0000 On Feb 19, 2013, at 7:12 PM, Mark Nottingham wrote: > There are ways to be aware of how JSON will be used without taking respon= sibility for defining those uses. >=20 THIS - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > On 20/02/2013, at 1:11 PM, Francis Galiegue wrote: >=20 >> On Wed, Feb 20, 2013 at 2:54 AM, Mark Nottingham wrote: >> [...] >>>=20 >>> This is a horrifically, monumentally bad idea. >>>=20 >>> Having a catch-all Working Group for anything that happens to use JSON = is like having one for anything that happens to use ASCII or UTF-8. It's li= ke shoving XML Schema, XLink, SOAP, Atom, DocBook and XHTML into the same W= orking Group. >>>=20 >>=20 >> On the other hand, a working group focussing on JSON alone and only >> JSON may fail to see the big picture of how JSON is actually _used_. >> As far as I see it, this working group does not aim at standardizing >> all of these, but it also needs to know how JSON is used in real life >> situations. And as such, it needs to be aware of whatever idea has >> been submitted as an I-D, or for that matter any other idea involving >> JSON and not the IETF (JSON-RPC comes to mind, but so does SMD, >> GeoJSON etc). >>=20 >>=20 >> So, I disagree: this is not a bad idea. Awareness is needed. The most >> clever people in the world, discussing a format, if clueless about >> what happens "out there", have no value in steering a format. >>=20 >> --=20 >> Francis Galiegue, fgaliegue@gmail.com >> Try out your JSON Schemas: http://json-schema-validator.herokuapp.com >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nico@cryptonector.com Tue Feb 19 18:36:18 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CE821F85FD for ; Tue, 19 Feb 2013 18:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=-1.539, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQVbwDLwRvIl for ; Tue, 19 Feb 2013 18:36:18 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 38F9721F859C for ; Tue, 19 Feb 2013 18:36:18 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id EFCB3286074 for ; Tue, 19 Feb 2013 18:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=dkVba0kB1tFiJnFvv+Pw gN7WbD4=; b=x/+oqsFeE2j22lahdCJkW3EBW4fQ3BvFfftRNtYVQFQ1hZ5CQCDj ChPIK9KfdZvqbEycQsQPXrkg85boZ6lZtkaWFPI1iVLYMr+J7go6ZnJGDASuq9lM loY1ggBGI189yM/6gYuy9OAzuuRzbrN7i79gnlfCV0IDc6fT2equYo8= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 9858A28605B for ; Tue, 19 Feb 2013 18:36:17 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id 12so4165666wgh.5 for ; Tue, 19 Feb 2013 18:36:16 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.97.166 with SMTP id eb6mr30921139wib.20.1361327776229; Tue, 19 Feb 2013 18:36:16 -0800 (PST) Received: by 10.216.254.217 with HTTP; Tue, 19 Feb 2013 18:36:15 -0800 (PST) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.com> Date: Tue, 19 Feb 2013 20:36:15 -0600 Message-ID: From: Nico Williams To: Francis Galiegue Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "Paul C. Bryan" , "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 02:36:18 -0000 On Tue, Feb 19, 2013 at 8:04 PM, Francis Galiegue wrote: > On Wed, Feb 20, 2013 at 2:39 AM, Francis Galiegue wrote: > Some more thoughts about this... > > Signing does not require c14n at all. Signing is totally unaware of > the media type. It will sign whatever it is fed with, and does not > care about what this content actually is. So, signing, say: Yes and no. If the verifier and the signer both have the same document then no c14n is needed. If the verifier must reconstruct the signed document -as opposed to receiving it from the signer- then the verifier must reconstruct exactly the signed document or the signature will not verify. Now, when does the latter come up? Rarely. You could say that application protocols must not work that way, but this seems imprudent to me. Instead the right thing to do is either define JSON c14n now or say that we don't need JSON c14n right now and won't define it until we do. Nico -- From fgaliegue@gmail.com Tue Feb 19 18:47:44 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5004921F8818 for ; Tue, 19 Feb 2013 18:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehFarN5Nah1e for ; Tue, 19 Feb 2013 18:47:43 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 78A6621F86BA for ; Tue, 19 Feb 2013 18:47:43 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id f13so3173086eaa.3 for ; Tue, 19 Feb 2013 18:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=N7aQNAWl6pZHpjZs7G0CgPdx4OJ70AA7UYe8nZVq3sk=; b=Xe5vy51L/m6u0SK4iVEtVNMznaGkV+vK0dl8M/550Y+fAHjylCWwBSEZMXkWIgMpjT OoFaHbD/O5qI5MZHa7KOmzxybfpzRJ6GUwypJJUCihsKygTVcRapUmNm5LB2wq/FoiLA h82uv/77qnzCNJQPdOfbWY8OcGmzS7SdIQ+W7s7v0NIoynA1ZKiMGfzdw1FMV/0nMxCD i+Dgt8rpQCivzwyqLhjBgEbA/S0HVlIozZkq1c6canJeAX9SkI/0+OaUpzfZzdxYHxvd XaePmH1DHxuo0jkAQDu92IP3jqlZtBZTNYVmZ7UuW/AG1/7+Tfvxh5lTySidH8gXrCWI Q1uA== MIME-Version: 1.0 X-Received: by 10.14.183.67 with SMTP id p43mr63474358eem.10.1361328462674; Tue, 19 Feb 2013 18:47:42 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 18:47:42 -0800 (PST) In-Reply-To: <95501AA5-EA26-4D74-8C6B-187F0E52C524@mnot.net> References: <95501AA5-EA26-4D74-8C6B-187F0E52C524@mnot.net> Date: Wed, 20 Feb 2013 03:47:42 +0100 Message-ID: From: Francis Galiegue To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] Comments on the proposed charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 02:47:44 -0000 On Wed, Feb 20, 2013 at 3:12 AM, Mark Nottingham wrote: > There are ways to be aware of how JSON will be used without taking responsibility for defining those uses. > And that is what I said exactly. Your initial wording let the impression that this working group SHOULD NOT care about the existing, concrete uses of JSON. And this is where I disagree. They SHOULD care. Not steer, but care. -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From stpeter@stpeter.im Tue Feb 19 18:58:21 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E45021F86AF for ; Tue, 19 Feb 2013 18:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8rJICVHK+Xw for ; Tue, 19 Feb 2013 18:58:20 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 23D7821F8630 for ; Tue, 19 Feb 2013 18:58:20 -0800 (PST) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2E76B4004E; Tue, 19 Feb 2013 20:05:42 -0700 (MST) Message-ID: <51243BC6.8080909@stpeter.im> Date: Tue, 19 Feb 2013 19:58:14 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Francis Galiegue References: <95501AA5-EA26-4D74-8C6B-187F0E52C524@mnot.net> In-Reply-To: X-Enigmail-Version: 1.5 X-Enigmail-Draft-Status: 513 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , "json@ietf.org" Subject: Re: [Json] Comments on the proposed charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 02:58:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/19/13 7:47 PM, Francis Galiegue wrote: > On Wed, Feb 20, 2013 at 3:12 AM, Mark Nottingham > wrote: >> There are ways to be aware of how JSON will be used without >> taking responsibility for defining those uses. >> > > And that is what I said exactly. Your initial wording let the > impression that this working group SHOULD NOT care about the > existing, concrete uses of JSON. > > And this is where I disagree. They SHOULD care. Not steer, but > care. It's not about caring, it's about the working group's contract with the IESG and the IETF community at large. It's true that the individuals working on base specs in the JSON WG (if formed) will probably care about various uses of JSON. It does not follow that it's best to work on applications of JSON in the same venue as the base specs. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJDvFAAoJEOoGpJErxa2pe2YP/2lQadq9Lotg4T+/9DZvqk/7 HrfHMaU7kmmu48x4hUx5j7+3qRYCAf6vLz1ASaMoD6uuk451SV1Zb/FVGT83aM/M rN8YVRv0BSwUwFUBT0iSRn50myPuEYOiCq1ptAqqZ3RLWa8CPgbouJkS5Rw3v/80 b/KHLHzifpmwVe8RNNaj1lQy7c63wmKUv4R0aPLVa3iG17FLeFk4Eia5KwiIdQux 1ucj5hA5O6kgTR9nlWDqmH10hiwJYMW+HnJES0SnIExuSz2a9KmJJ5hgpPPxRQiX UzPorPGI0yu1NFRSMFyN2UYhRHBD9Z3ADJKLAwiax4zJPFmDBD7U/p9tUw1sPwbq OFn0iq7oYw8wpoIRqLBAvgwZmphIYgNPgNDmi2MXIu44fXKtapfaKIxi/8j4NL0a Wb0vPBdrxeNN6KkQ1XE/8ZCH9GUOmFcxX0do8U1mi1Xj/6gyW+JzYBl8f6JQ1tZg BmnHIDk8SxlXTfTrMHW8j7KDqOErhVs/bcAF88daw4SO/lwkmxrsk5XxpbyAAoJi I68hP0ugTWEHjnE4y+Q1c7xwUUAD/a3BZfVJyedRJMXVdFfB5bxi8h412fBiniQw 5pVx4C1Ss0YR1qwzSTk2VUiWo/ob6+fIeywIFHXE86dHNTD8JTdQsMRmh1tvQu6M rOAYfssqRo5u5xEVnKrD =cNOL -----END PGP SIGNATURE----- From fgaliegue@gmail.com Tue Feb 19 19:01:05 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE9A21F8814 for ; Tue, 19 Feb 2013 19:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yADbsAAxcVvE for ; Tue, 19 Feb 2013 19:01:00 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80CB421F8855 for ; Tue, 19 Feb 2013 19:01:00 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id f13so3175619eaa.3 for ; Tue, 19 Feb 2013 19:00:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wSc+LufkpUxc2bU9ObTKUjelVcCH7dH185p0dsIwDCc=; b=D5M7DDXLG7tx6gJrOxUeiZuiEIlCxhxxsMj/ar2idr5y8xvuVUULUHsORulCrzfbOY 2acE2QCC67CqCt0SlwGBAv80RjfFS/sUAAsvkl39agpCrnyh6dE58nW7xGpUFCcumGkh fZajMCHu3DsmBif7z9rJ/V5x7JZzs9NReQbYgC+5dGhWZQ1Yde00kE7JTfKpCw/k/tzF l+zXkefNBRrNuEE3vHvw2ojJ7P9MHU2HQjincg/0HRW/972jLJmfsTYCgp+Hg7G9j99m 2pd2M+imM4PnYxVMV30nUwQdkemkkOTXGHbJYjTooiSs7kLFfStnMUP+tDhtxxMq8rkU ZyTQ== MIME-Version: 1.0 X-Received: by 10.14.193.134 with SMTP id k6mr63875434een.37.1361329259578; Tue, 19 Feb 2013 19:00:59 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 19:00:59 -0800 (PST) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.com> Date: Wed, 20 Feb 2013 04:00:59 +0100 Message-ID: From: Francis Galiegue To: Nico Williams Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "Paul C. Bryan" , "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:01:06 -0000 On Wed, Feb 20, 2013 at 3:36 AM, Nico Williams wrote: [...] > > Yes and no. If the verifier and the signer both have the same > document then no c14n is needed. If the verifier must reconstruct the > signed document -as opposed to receiving it from the signer- then the > verifier must reconstruct exactly the signed document or the signature > will not verify. > There is one thing I don't get: in any case, what is transmitted over the network is just a stream of bytes. One end writes that stream, the other reads it. In order for the receiving end to interpret that data, should signing be used, it needs to verify that the _byte stream_, not its interpretation, is correct. That byte stream MAY be JSON. It may not be. The problem is therefore, IIUC, that if the protocol exchange has determined that this byte stream is JSON, then there should exist a canonical form. OK, but then what about this: { "x": 0.00000000000000000000000000000000000000000000000000000000000000000000000000002 } This is valid JSON. However hard you wish to canonicalize it, the fact is, some languages won't read it correctly -- in fact, most languages won't. And c14n won't help here. -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From fgaliegue@gmail.com Tue Feb 19 19:04:23 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF57521F888B for ; Tue, 19 Feb 2013 19:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHcDk8SviQgl for ; Tue, 19 Feb 2013 19:04:23 -0800 (PST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4F021F886B for ; Tue, 19 Feb 2013 19:04:22 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e52so3691243eek.20 for ; Tue, 19 Feb 2013 19:04:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oxJ+nT5YmVhNnsU65fQNbBioAoOVfl6qWiME8QsmQOw=; b=oRLhD9DbjQL7bZUWeBSZF1x6zeS4BGMW16RcUC1lWkPV03Aa8ghgN7pUtfxh2oj07z 3GXt2fpFYmoYhXY2sFBWJTxa4zMrN3Je8N/cthdhEU6JF5rPRL90j1YQuCTstFZa+9KM Kj2sC0fEleOReIiuC5BMEKwVKGlWxFmXhIvaXkOoyrmGdBLuDXGnDle7bNzYZ3xnBbKn Zi9ptMhdZVBEbKDP/xQnxbN+Oe9qquOTctoXuK5jOmpIhngqkWq18HrrKS6CM2GZdnLA ziDcpNevii7lQUX6SezZYrfj4Tb0pL+A1hkCgVUfn1Pg42slq7SuU9IvZLR//wNIGZtl b6+A== MIME-Version: 1.0 X-Received: by 10.14.179.5 with SMTP id g5mr63905729eem.41.1361329461433; Tue, 19 Feb 2013 19:04:21 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 19:04:21 -0800 (PST) In-Reply-To: <51243BC6.8080909@stpeter.im> References: <95501AA5-EA26-4D74-8C6B-187F0E52C524@mnot.net> <51243BC6.8080909@stpeter.im> Date: Wed, 20 Feb 2013 04:04:21 +0100 Message-ID: From: Francis Galiegue To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: Mark Nottingham , "json@ietf.org" Subject: Re: [Json] Comments on the proposed charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:04:23 -0000 On Wed, Feb 20, 2013 at 3:58 AM, Peter Saint-Andre wrote: [...] >> >> And that is what I said exactly. Your initial wording let the >> impression that this working group SHOULD NOT care about the >> existing, concrete uses of JSON. >> >> And this is where I disagree. They SHOULD care. Not steer, but >> care. > > It's not about caring, it's about the working group's contract with > the IESG and the IETF community at large. It's true that the > individuals working on base specs in the JSON WG (if formed) will > probably care about various uses of JSON. It does not follow that it's > best to work on applications of JSON in the same venue as the base specs. > Yes, I agree with that too. My argument is that working on the base specifications without an awareness of how these existing base specifications are used is shortsighted. I may have misinterpreted what Mark said, but this is the impression I had when reading that part of his first answer. -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From nico@cryptonector.com Tue Feb 19 19:11:45 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C553D21F8815 for ; Tue, 19 Feb 2013 19:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=-1.510, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6H89a8PTrIFn for ; Tue, 19 Feb 2013 19:11:45 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 2302421F8810 for ; Tue, 19 Feb 2013 19:11:45 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id B5A0B76806C for ; Tue, 19 Feb 2013 19:11:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=yc1eRw0i5q1SYud6gLIE tztEFxA=; b=oy0+Ilyv/bZTy6zIw7WjWTT5QpgvxvcDEsUgc68CjAvTKLWbbUrl /XOjaKQREU3LeAFHeHIBwjgF5g4xwwwQN8ZHAsnFT/h4Do+LTopspEt26QFE6F+Y UcYjr/4eZBuTI+31qDUMeJSSYQko27Y3E3o3YvuqRvRJT/T+IVc2Si0= Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 5911176806B for ; Tue, 19 Feb 2013 19:11:44 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id x8so6262355wey.6 for ; Tue, 19 Feb 2013 19:11:42 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.84.165 with SMTP id a5mr31473846wiz.6.1361329902901; Tue, 19 Feb 2013 19:11:42 -0800 (PST) Received: by 10.216.254.217 with HTTP; Tue, 19 Feb 2013 19:11:42 -0800 (PST) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.com> Date: Tue, 19 Feb 2013 21:11:42 -0600 Message-ID: From: Nico Williams To: Francis Galiegue Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "Paul C. Bryan" , "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:11:45 -0000 On Tue, Feb 19, 2013 at 9:00 PM, Francis Galiegue wrote: > On Wed, Feb 20, 2013 at 3:36 AM, Nico Williams wrote: > [...] >> >> Yes and no. If the verifier and the signer both have the same >> document then no c14n is needed. If the verifier must reconstruct the >> signed document -as opposed to receiving it from the signer- then the >> verifier must reconstruct exactly the signed document or the signature >> will not verify. >> > > There is one thing I don't get: in any case, what is transmitted over > the network is just a stream of bytes. One end writes that stream, the > other reads it. No, in this one case the two ends construct some data. A good example would be channel bindings (RFCs 5056, 5929), except that mostly that has no structure, so it's not really a good example after all, but it illustrates the point. > In order for the receiving end to interpret that data, should signing > be used, it needs to verify that the _byte stream_, not its > interpretation, is correct. That byte stream MAY be JSON. It may not > be. That's just it: in this case the data isn't transmitted, only the signature. There's many protocols that transmit signatures (or hashes) but not necessarily contents. E.g., rsync. What if you had a JSON-based synchronization protocol and you're sending file metadata, only there's a lot of it (e.g., large ACLs), and you're trying to avoid sending it, so you send file names and metadata hashes, and if the receiver's don't match then you send the actual metadata? Nico -- From stpeter@stpeter.im Tue Feb 19 19:12:35 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A4521F8815 for ; Tue, 19 Feb 2013 19:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9vcveVDXWPk for ; Tue, 19 Feb 2013 19:12:34 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3B25A21F8600 for ; Tue, 19 Feb 2013 19:12:34 -0800 (PST) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AF28C4004E; Tue, 19 Feb 2013 20:19:56 -0700 (MST) Message-ID: <51243F1C.1030607@stpeter.im> Date: Tue, 19 Feb 2013 20:12:28 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Francis Galiegue References: <95501AA5-EA26-4D74-8C6B-187F0E52C524@mnot.net> <51243BC6.8080909@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , "json@ietf.org" Subject: Re: [Json] Comments on the proposed charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:12:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/19/13 8:04 PM, Francis Galiegue wrote: > On Wed, Feb 20, 2013 at 3:58 AM, Peter Saint-Andre > wrote: [...] >>> >>> And that is what I said exactly. Your initial wording let the >>> impression that this working group SHOULD NOT care about the >>> existing, concrete uses of JSON. >>> >>> And this is where I disagree. They SHOULD care. Not steer, but >>> care. >> >> It's not about caring, it's about the working group's contract >> with the IESG and the IETF community at large. It's true that >> the individuals working on base specs in the JSON WG (if formed) >> will probably care about various uses of JSON. It does not follow >> that it's best to work on applications of JSON in the same venue >> as the base specs. >> > > Yes, I agree with that too. My argument is that working on the > base specifications without an awareness of how these existing > base specifications are used is shortsighted. > > I may have misinterpreted what Mark said, but this is the > impression I had when reading that part of his first answer. Francis, in case you are new to the IETF, please be aware that IETF Working Groups are not formed lightly and tend to be quite tightly scoped so that they are able to sustain the energy and focus necessary to complete their work in a reasonable amount of time. I don't think anyone would disagree with the sentiment that it makes sense to define the base specs with the uses of JSON in mind. However, individuals who are active in the working group can maintain that awareness without adding a lot of additional deliverables to the working group's charter. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJD8cAAoJEOoGpJErxa2piLkQAJ8j9br2j86pq0TNYXDxHHHb v7zGNOB7SnXIzpO80Oy6UvygBW+b2a16B3jXCLWzTCoZgkFuHjRM9BLl6XIpWdgK OP7Nj3yNToGlCOJL26yEeMxRavfOp/rNvRJ/cdSIFuQEOlvSui1ozY9XZ6+7BLTR 9t5wR4oWFlbBacHS3zk3bKAs16bKsOj34AkitV9jYAC4wH2zSxPJEAFXqc/2DMeE OinUVLo86EAc/JswfvXb6QOn9HKlvQxwgXmS09RqttFa4UgAxWHe9eTLdFEgCTxL b+e7TC/6NNMfXnH67NG1tFrEbpMjr5eOMjXSpFQpjkjFLpHlR34g27dc9oLCWnp3 3nO3yoYaFj0OmfBL43yuc1F+NK+RqR8t1RmbOlt4ICOB8uZeri1JTIos3Be28jsg ROiSxxYS+o+GPi/TNfzwsDY9+fJFc7n863PI4MHrhtG7cs2kMDis12Q8MFOj6R0T o98wHakDWSPLIh+6opGuJXw2idGxRcJ69SFXNLdKahpl2ltZaQxIIura+KIo7VRP F0HL5XcLa5ikPW4tn5hqG8v6mxnqngJqjrvPZbr3oJzUadhuiWZ5y/39JSzUfMxf iOC0kZWq4PhnTZ4ryScnuHYFkoBqzf6twi4l7bE0VwyTdDeYpA/vimfdsp92pUcn P7AoZxU3WCNxm7Flf6FW =IVbe -----END PGP SIGNATURE----- From tbray@textuality.com Tue Feb 19 19:18:10 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656B221F8818 for ; Tue, 19 Feb 2013 19:18:10 -0800 (PST) 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=[AWL=-0.275, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVSbpc1nzbAu for ; Tue, 19 Feb 2013 19:18:09 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A68421F8810 for ; Tue, 19 Feb 2013 19:18:09 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id kp1so3758571pab.3 for ; Tue, 19 Feb 2013 19:18:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Cci8Bsh+p3yo+qu7Nk0SToFlYBGZZiW6/h6TECTg47M=; b=DJ0gB6OoZvGHUZ0gbY3pFWUCVTDuKDQjJjRbV15WcAMzCz/T8Dgyv8uZYo9CXjHi3U xyi633z3JoBaWvll45szlc3PMsS9d3hBEW23iHSJP07FjCgnTXNPkqx9o0bIDrDqF5BL izT+hmVhNJ/aR9wJsqpQ/7hA0oKhW1jIVnE5WY1Cr3hYpB0n43J74L9DMFMMoRR3Xk2E ctZ0Uz2FGvJX48swJYaJJICAS3tkmVMuS8etZB8sdzOn1XTLhtw1c2eVgTb+KhRjd2pC EaM88res9/orF/P6fk3BE3nAhlfQFUDOCP1KxZlOziblLyQO1JN67N5GhsXtczH345Dk ahow== MIME-Version: 1.0 X-Received: by 10.66.4.193 with SMTP id m1mr95003pam.214.1361330289371; Tue, 19 Feb 2013 19:18:09 -0800 (PST) Received: by 10.66.249.129 with HTTP; Tue, 19 Feb 2013 19:18:09 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.com> Date: Tue, 19 Feb 2013 19:18:09 -0800 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=bcaec520e7df51eba804d61f680d X-Gm-Message-State: ALoCoQlre2Levt9XTc7VmiXES5GjSXzJHxVNMARGH+amxlCCrwp1A1Q9IDR/XpYYPkdKoj05Zru/ Cc: Francis Galiegue , Paul Hoffman , "Paul C. Bryan" , "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:18:10 -0000 --bcaec520e7df51eba804d61f680d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OK, this discussion has convinced me that there=92s no real need for this group to proactively take up JSON c14n. If at some future point there=92s = a strong demonstrated real (not hypothetical) use case, it=92s a fairly tractable problem. But for now, it=92s unnecessary work. -T On Tue, Feb 19, 2013 at 7:11 PM, Nico Williams wrote= : > On Tue, Feb 19, 2013 at 9:00 PM, Francis Galiegue > wrote: > > On Wed, Feb 20, 2013 at 3:36 AM, Nico Williams > wrote: > > [...] > >> > >> Yes and no. If the verifier and the signer both have the same > >> document then no c14n is needed. If the verifier must reconstruct the > >> signed document -as opposed to receiving it from the signer- then the > >> verifier must reconstruct exactly the signed document or the signature > >> will not verify. > >> > > > > There is one thing I don't get: in any case, what is transmitted over > > the network is just a stream of bytes. One end writes that stream, the > > other reads it. > > No, in this one case the two ends construct some data. A good example > would be channel bindings (RFCs 5056, 5929), except that mostly that > has no structure, so it's not really a good example after all, but it > illustrates the point. > > > In order for the receiving end to interpret that data, should signing > > be used, it needs to verify that the _byte stream_, not its > > interpretation, is correct. That byte stream MAY be JSON. It may not > > be. > > That's just it: in this case the data isn't transmitted, only the > signature. There's many protocols that transmit signatures (or > hashes) but not necessarily contents. E.g., rsync. What if you had a > JSON-based synchronization protocol and you're sending file metadata, > only there's a lot of it (e.g., large ACLs), and you're trying to > avoid sending it, so you send file names and metadata hashes, and if > the receiver's don't match then you send the actual metadata? > > Nico > -- > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --bcaec520e7df51eba804d61f680d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
OK, this discussion has convinced me that there=92s n= o real need for this group to proactively take up JSON c14n.=A0 If at some = future point there=92s a strong demonstrated real (not hypothetical) use ca= se, it=92s a fairly tractable problem.=A0 But for now, it=92s unnecessary w= ork.

-T


On Tue, Feb 19, 2013 at 7:11 PM, Nico Williams &= lt;nico@cryptone= ctor.com> wrote:
On Tue, Feb 19, 2013 at 9:= 00 PM, Francis Galiegue <fgaliegu= e@gmail.com> wrote:
> On Wed, Feb 20, 2013 at 3:36 AM, Nico Williams <nico@cryptonector.com> wrote:
> [...]
>>
>> Yes and no. =A0If the verifier and the signer both have the same >> document then no c14n is needed. =A0If the verifier must reconstru= ct the
>> signed document -as opposed to receiving it from the signer- then = the
>> verifier must reconstruct exactly the signed document or the signa= ture
>> will not verify.
>>
>
> There is one thing I don't get: in any case, what is transmitted o= ver
> the network is just a stream of bytes. One end writes that stream, the=
> other reads it.

No, in this one case the two ends construct some data. =A0A good exam= ple
would be channel bindings (RFCs 5056, 5929), except that mostly that
has no structure, so it's not really a good example after all, but it illustrates the point.

> In order for the receiving end to interpret that data, should signing<= br> > be used, it needs to verify that the _byte stream_, not its
> interpretation, is correct. That byte stream MAY be JSON. It may not > be.

That's just it: in this case the data isn't transmitted, only= the
signature. =A0There's many protocols that transmit signatures (or
hashes) but not necessarily contents. =A0E.g., rsync. =A0What if you had a<= br> JSON-based synchronization protocol and you're sending file metadata, only there's a lot of it (e.g., large ACLs), and you're trying to avoid sending it, so you send file names and metadata hashes, and if
the receiver's don't match then you send the actual metadata?

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

--bcaec520e7df51eba804d61f680d-- From pbryan@anode.ca Tue Feb 19 19:21:42 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CFF21F8901 for ; Tue, 19 Feb 2013 19:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CryGHtqBUSHx for ; Tue, 19 Feb 2013 19:21:42 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 45ECC21F88B9 for ; Tue, 19 Feb 2013 19:21:42 -0800 (PST) Received: from [10.216.41.33] (unknown [199.119.234.213]) by maple.anode.ca (Postfix) with ESMTPSA id 300706174; Wed, 20 Feb 2013 03:21:40 +0000 (UTC) Date: Tue, 19 Feb 2013 19:21:34 -0800 Message-ID: From: "Paul C. Bryan" To: Tim Bray , Nico Williams MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: Francis Galiegue , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:21:42 -0000 KzEKClRpbSBCcmF5IDx0YnJheUB0ZXh0dWFsaXR5LmNvbT4gd3JvdGU6Cgo+T0ssIHRoaXMgZGlz Y3Vzc2lvbiBoYXMgY29udmluY2VkIG1lIHRoYXQgdGhlcmXigJlzIG5vIHJlYWwgbmVlZCBmb3Ig dGhpcwo+Z3JvdXAgdG8gcHJvYWN0aXZlbHkgdGFrZSB1cCBKU09OIGMxNG4uICBJZiBhdCBzb21l IGZ1dHVyZSBwb2ludCB0aGVyZeKAmXMgYQo+c3Ryb25nIGRlbW9uc3RyYXRlZCByZWFsIChub3Qg aHlwb3RoZXRpY2FsKSB1c2UgY2FzZSwgaXTigJlzIGEgZmFpcmx5Cj50cmFjdGFibGUgcHJvYmxl bS4gIEJ1dCBmb3Igbm93LCBpdOKAmXMgdW5uZWNlc3Nhcnkgd29yay4KPgo+LVQKPgo+Cj5PbiBU dWUsIEZlYiAxOSwgMjAxMyBhdCA3OjExIFBNLCBOaWNvIFdpbGxpYW1zIDxuaWNvQGNyeXB0b25l Y3Rvci5jb20+d3JvdGU6Cj4KPj4gT24gVHVlLCBGZWIgMTksIDIwMTMgYXQgOTowMCBQTSwgRnJh bmNpcyBHYWxpZWd1ZSA8ZmdhbGllZ3VlQGdtYWlsLmNvbT4KPj4gd3JvdGU6Cj4+ID4gT24gV2Vk LCBGZWIgMjAsIDIwMTMgYXQgMzozNiBBTSwgTmljbyBXaWxsaWFtcyA8bmljb0BjcnlwdG9uZWN0 b3IuY29tPgo+PiB3cm90ZToKPj4gPiBbLi4uXQo+PiA+Pgo+PiA+PiBZZXMgYW5kIG5vLiAgSWYg dGhlIHZlcmlmaWVyIGFuZCB0aGUgc2lnbmVyIGJvdGggaGF2ZSB0aGUgc2FtZQo+PiA+PiBkb2N1 bWVudCB0aGVuIG5vIGMxNG4gaXMgbmVlZGVkLiAgSWYgdGhlIHZlcmlmaWVyIG11c3QgcmVjb25z dHJ1Y3QgdGhlCj4+ID4+IHNpZ25lZCBkb2N1bWVudCAtYXMgb3Bwb3NlZCB0byByZWNlaXZpbmcg aXQgZnJvbSB0aGUgc2lnbmVyLSB0aGVuIHRoZQo+PiA+PiB2ZXJpZmllciBtdXN0IHJlY29uc3Ry dWN0IGV4YWN0bHkgdGhlIHNpZ25lZCBkb2N1bWVudCBvciB0aGUgc2lnbmF0dXJlCj4+ID4+IHdp bGwgbm90IHZlcmlmeS4KPj4gPj4KPj4gPgo+PiA+IFRoZXJlIGlzIG9uZSB0aGluZyBJIGRvbid0 IGdldDogaW4gYW55IGNhc2UsIHdoYXQgaXMgdHJhbnNtaXR0ZWQgb3Zlcgo+PiA+IHRoZSBuZXR3 b3JrIGlzIGp1c3QgYSBzdHJlYW0gb2YgYnl0ZXMuIE9uZSBlbmQgd3JpdGVzIHRoYXQgc3RyZWFt LCB0aGUKPj4gPiBvdGhlciByZWFkcyBpdC4KPj4KPj4gTm8sIGluIHRoaXMgb25lIGNhc2UgdGhl IHR3byBlbmRzIGNvbnN0cnVjdCBzb21lIGRhdGEuICBBIGdvb2QgZXhhbXBsZQo+PiB3b3VsZCBi ZSBjaGFubmVsIGJpbmRpbmdzIChSRkNzIDUwNTYsIDU5MjkpLCBleGNlcHQgdGhhdCBtb3N0bHkg dGhhdAo+PiBoYXMgbm8gc3RydWN0dXJlLCBzbyBpdCdzIG5vdCByZWFsbHkgYSBnb29kIGV4YW1w bGUgYWZ0ZXIgYWxsLCBidXQgaXQKPj4gaWxsdXN0cmF0ZXMgdGhlIHBvaW50Lgo+Pgo+PiA+IElu IG9yZGVyIGZvciB0aGUgcmVjZWl2aW5nIGVuZCB0byBpbnRlcnByZXQgdGhhdCBkYXRhLCBzaG91 bGQgc2lnbmluZwo+PiA+IGJlIHVzZWQsIGl0IG5lZWRzIHRvIHZlcmlmeSB0aGF0IHRoZSBfYnl0 ZSBzdHJlYW1fLCBub3QgaXRzCj4+ID4gaW50ZXJwcmV0YXRpb24sIGlzIGNvcnJlY3QuIFRoYXQg Ynl0ZSBzdHJlYW0gTUFZIGJlIEpTT04uIEl0IG1heSBub3QKPj4gPiBiZS4KPj4KPj4gVGhhdCdz IGp1c3QgaXQ6IGluIHRoaXMgY2FzZSB0aGUgZGF0YSBpc24ndCB0cmFuc21pdHRlZCwgb25seSB0 aGUKPj4gc2lnbmF0dXJlLiAgVGhlcmUncyBtYW55IHByb3RvY29scyB0aGF0IHRyYW5zbWl0IHNp Z25hdHVyZXMgKG9yCj4+IGhhc2hlcykgYnV0IG5vdCBuZWNlc3NhcmlseSBjb250ZW50cy4gIEUu Zy4sIHJzeW5jLiAgV2hhdCBpZiB5b3UgaGFkIGEKPj4gSlNPTi1iYXNlZCBzeW5jaHJvbml6YXRp b24gcHJvdG9jb2wgYW5kIHlvdSdyZSBzZW5kaW5nIGZpbGUgbWV0YWRhdGEsCj4+IG9ubHkgdGhl cmUncyBhIGxvdCBvZiBpdCAoZS5nLiwgbGFyZ2UgQUNMcyksIGFuZCB5b3UncmUgdHJ5aW5nIHRv Cj4+IGF2b2lkIHNlbmRpbmcgaXQsIHNvIHlvdSBzZW5kIGZpbGUgbmFtZXMgYW5kIG1ldGFkYXRh IGhhc2hlcywgYW5kIGlmCj4+IHRoZSByZWNlaXZlcidzIGRvbid0IG1hdGNoIHRoZW4geW91IHNl bmQgdGhlIGFjdHVhbCBtZXRhZGF0YT8KPj4KPj4gTmljbwo+PiAtLQo+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBqc29uIG1haWxpbmcgbGlzdAo+ PiBqc29uQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v anNvbgo+Pgo= From nico@cryptonector.com Tue Feb 19 19:22:03 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D8921F88C4 for ; Tue, 19 Feb 2013 19:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.626 X-Spam-Level: X-Spam-Status: No, score=-3.626 tagged_above=-999 required=5 tests=[AWL=-1.649, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjb59nXYqxQ2 for ; Tue, 19 Feb 2013 19:22:01 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 19F7E21F8818 for ; Tue, 19 Feb 2013 19:22:01 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id DAEEC27BC061 for ; Tue, 19 Feb 2013 19:21:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=wa11vAc7F2LPEm1c1/+2PKKviEI=; b=S6gyhUZfsDs 8mH58pzZvPF3+tfzJNmFrPQ51vMPCHi7IVeuDNI9yHRVK4O+MBhuqbYnY6z0dnWw ICXW9/ULgy6GmPmKFacPtj41jjk5lHqUmsGrKBCEPG8fM817h+ZdApZy0oYYGhuK cozcGf25+JsaBhVkiP6VPLGG4ve3XtQk= Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 82C2E27BC05D for ; Tue, 19 Feb 2013 19:21:58 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hn17so5645312wib.4 for ; Tue, 19 Feb 2013 19:21:57 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.121.38 with SMTP id lh6mr30171137wjb.27.1361330517316; Tue, 19 Feb 2013 19:21:57 -0800 (PST) Received: by 10.216.254.217 with HTTP; Tue, 19 Feb 2013 19:21:56 -0800 (PST) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.com> Date: Tue, 19 Feb 2013 21:21:56 -0600 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Francis Galiegue , Paul Hoffman , "Paul C. Bryan" , "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:22:03 -0000 On Tue, Feb 19, 2013 at 9:18 PM, Tim Bray wrote: > OK, this discussion has convinced me that there=E2=80=99s no real need fo= r this > group to proactively take up JSON c14n. If at some future point there=E2= =80=99s a > strong demonstrated real (not hypothetical) use case, it=E2=80=99s a fair= ly > tractable problem. But for now, it=E2=80=99s unnecessary work. Yup, I think that's the consensus. From fgaliegue@gmail.com Tue Feb 19 19:25:06 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C69A21F886A for ; Tue, 19 Feb 2013 19:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-wvXkNnoTSe for ; Tue, 19 Feb 2013 19:25:05 -0800 (PST) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id E46A721F887F for ; Tue, 19 Feb 2013 19:25:04 -0800 (PST) Received: by mail-ea0-f179.google.com with SMTP id d12so3138497eaa.10 for ; Tue, 19 Feb 2013 19:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=g48EpQjEiFgj59T8iKM4hx/tzC191ZEKps8oRD8gTrE=; b=KzV67ECENEad90x/hdBaQfPnhoiWgzizIypvFUz5oKA60bc5DHX/b9oqNEg7fjHnnb q9X36g0747v68+m9gGYrzIcO4TEPYWZ554U6rTw7/caj/8YJZKpocm2recCHvquyaJgC M75KwIhIgvogpL7N65cxYnun8Ciiaa94I+R/kKn0zXl2cc0laTg55JP4pZ90MDRNpRpy P5ikGIWXClPJFehwixzmoKHE5ExALQuwpwsAZqttP1YQ9hDKKgFvUR817BglA8NqW8kA LlP58MGrL18YMI/ri2OnD55K7imHHPYUnspGgR+uwzcb+BorKwW+0XPZ6mCYaUEEx6jB b9Dg== MIME-Version: 1.0 X-Received: by 10.14.205.68 with SMTP id i44mr63821591eeo.25.1361330704060; Tue, 19 Feb 2013 19:25:04 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 19:25:03 -0800 (PST) In-Reply-To: <51243F1C.1030607@stpeter.im> References: <95501AA5-EA26-4D74-8C6B-187F0E52C524@mnot.net> <51243BC6.8080909@stpeter.im> <51243F1C.1030607@stpeter.im> Date: Wed, 20 Feb 2013 04:25:03 +0100 Message-ID: From: Francis Galiegue To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: Mark Nottingham , "json@ietf.org" Subject: Re: [Json] Comments on the proposed charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:25:06 -0000 On Wed, Feb 20, 2013 at 4:12 AM, Peter Saint-Andre wrote: [...] > > Francis, in case you are new to the IETF, please be aware that IETF > Working Groups are not formed lightly and tend to be quite tightly > scoped so that they are able to sustain the energy and focus necessary > to complete their work in a reasonable amount of time. I don't think > anyone would disagree with the sentiment that it makes sense to define > the base specs with the uses of JSON in mind. However, individuals who > are active in the working group can maintain that awareness without > adding a lot of additional deliverables to the working group's charter. > I am indeed new, and as such may have overreacted. I am fully aware that a working group has to restrict itself to a tight scope, it is only natural that it must do so. As such, I may have overreacted and apologize for the noise. Please forgive me, -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From stpeter@stpeter.im Tue Feb 19 19:31:01 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9135A21F883A for ; Tue, 19 Feb 2013 19:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMCLP5BghI0M for ; Tue, 19 Feb 2013 19:31:00 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC8321F871E for ; Tue, 19 Feb 2013 19:31:00 -0800 (PST) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 674994004E; Tue, 19 Feb 2013 20:38:26 -0700 (MST) Message-ID: <51244372.6080906@stpeter.im> Date: Tue, 19 Feb 2013 20:30:58 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Francis Galiegue References: <95501AA5-EA26-4D74-8C6B-187F0E52C524@mnot.net> <51243BC6.8080909@stpeter.im> <51243F1C.1030607@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , "json@ietf.org" Subject: Re: [Json] Comments on the proposed charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:31:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/19/13 8:25 PM, Francis Galiegue wrote: > On Wed, Feb 20, 2013 at 4:12 AM, Peter Saint-Andre > wrote: [...] >> >> Francis, in case you are new to the IETF, please be aware that >> IETF Working Groups are not formed lightly and tend to be quite >> tightly scoped so that they are able to sustain the energy and >> focus necessary to complete their work in a reasonable amount of >> time. I don't think anyone would disagree with the sentiment that >> it makes sense to define the base specs with the uses of JSON in >> mind. However, individuals who are active in the working group >> can maintain that awareness without adding a lot of additional >> deliverables to the working group's charter. >> > > I am indeed new, and as such may have overreacted. I am fully > aware that a working group has to restrict itself to a tight scope, > it is only natural that it must do so. > > As such, I may have overreacted and apologize for the noise. > > Please forgive me, There is no need to apologize or ask for forgiveness. The IETF is a strange alternate universe and it takes a while to adjust to your new surroundings. You're doing fine! ;-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJENxAAoJEOoGpJErxa2pbUkQAJ6miMInF0XIEz4DP5QBJ66m ujrsSwi/OoEvHc3zyMpKKB5hF1qn2QwjPbfj5rdFMj6fTLIBd8dHdVQNMLVViVVa SYJ9ikf+KszsKneN3itEgav5MaKkLhHfc+wG1WuH0pvV5FXeTB3bkQFANTwP72Bv Kf9DtmLBWlVMhzOxtnDyrWTeSp0DVRkxIUw+USqch+punToZv1wSQRzjqexS7tsU Zy7QZtbFP0XED3a+0O++cnH/MikCf2mjVNJdPGHJ9hzncSX0dk8mcO7liOTZ28GW EJC7/Gm6phNnUC+byJn3MPNiXVju+1vPy3Hpwj5bVGcq7OUpIFUZaFCdRxM1e8RX OJxIloopfuxprRSquWwM7p7JsUse7bafHuLYhaHiG3w5pNOj0FC4RodjahX2GIll gpKAEOedO8muPNPxQF2ZgMHfONfqEZQo7e4K5mkro3HRk+FXxu3TSVapF7RGJn2e PGr4QfdB2SE4TAQkz0J0aMi8DANPb4RkFsnVoZLazwYm6NqaUkc2YEZFrwuTWhlZ x7NbcRGTZIsT5KjUXJ2iB+C6KGkP/xmtF0jfKb58akm+cGHS47Q/P1mbBfMMJZV/ ox0HSY6ipey4zLVUNCSihOsRuj1Jyw91eg5r0AEgF+Z2rqIATr8t22qY9jCZdmeF dML4mzeBmLK7tj1QcIO9 =0tIb -----END PGP SIGNATURE----- From James.H.Manger@team.telstra.com Tue Feb 19 19:49:46 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4A021F880B for ; Tue, 19 Feb 2013 19:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQ3fiZt6hMcJ for ; Tue, 19 Feb 2013 19:49:45 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id DE70C21F86C1 for ; Tue, 19 Feb 2013 19:49:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,699,1355058000"; d="scan'208,217";a="119085965" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 20 Feb 2013 14:49:44 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6991"; a="113056484" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcdvi.tcif.telstra.com.au with ESMTP; 20 Feb 2013 14:49:43 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Wed, 20 Feb 2013 14:49:43 +1100 From: "Manger, James H" To: "json@ietf.org" Date: Wed, 20 Feb 2013 14:49:42 +1100 Thread-Topic: [Json] Canonicalization Thread-Index: Ac4PGOx5tPNV0qKyTuSar4EaUQ612wAAOEBQ Message-ID: <255B9BB34FB7D647A506DC292726F6E115076344B3@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.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_255B9BB34FB7D647A506DC292726F6E115076344B3WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:49:46 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115076344B3WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBPSywgdGhpcyBkaXNjdXNzaW9uIGhhcyBjb252aW5jZWQgbWUgdGhhdCB0aGVyZeKAmXMgbm8g cmVhbCBuZWVkIGZvciB0aGlzIGdyb3VwIHRvIHByb2FjdGl2ZWx5IHRha2UgdXAgSlNPTiBjMTRu LiAgSWYgYXQgc29tZSBmdXR1cmUgcG9pbnQgdGhlcmXigJlzIGEgc3Ryb25nIGRlbW9uc3RyYXRl ZCByZWFsIChub3QgaHlwb3RoZXRpY2FsKSB1c2UgY2FzZSwgaXTigJlzIGEgZmFpcmx5IHRyYWN0 YWJsZSBwcm9ibGVtLiAgQnV0IGZvciBub3csIGl04oCZcyB1bm5lY2Vzc2FyeSB3b3JrLg0KDQpU aGVyZSBpcyBpbnRlcmVzdCBpbiBKU09OIGNhbm9uaWNhbGl6YXRpb24sIGRlc3BpdGUgdGhlIHRy ZXBpZGF0aW9uOiBkcmFmdC1zdGF5a292LWh1LWpzb24tY2Fub25pY2FsLWZvcm07IHRoaXMgZW1h aWwgZGlzY3Vzc2lvbjsgaHR0cDovL3dpa2kubGFwdG9wLm9yZy9nby9DYW5vbmljYWxfSlNPTjsg ZGlzY3Vzc2lvbnMgaW4gSk9TRSBXRzsgaHR0cDovL3N0YWNrb3ZlcmZsb3cuY29tL3F1ZXN0aW9u cy80NjcwNDk0L2hvdy10by1jcnlwdG9ncmFwaGljYWxseS1oYXNoLWEtanNvbi1vYmplY3Q7IGEg Y291cGxlIG9mIGdpdGh1YiBwcm9qZWN0czsgYmVuY29kZS4NCg0KQWRkIHRvIHRoYXQgdGhlIGZh Y3QgdGhhdCBpdCB3YXMgZmVsdCBuZWNlc3NhcnkgdG8gZGVmaW5lIGMxNG4gZm9yIFhNTCBhbmQg QVNOLjEgQkVSIChERVIgYW5kIENFUikuDQoNCkMxNG4gaGFzIGNhdXNlZCBsb3RzIG9mIHBhaW4g c28gYSBKU09OIGMxNG4gc3BlYyBzaG91bGQgaGF2ZSBhIGJpZyB3YXJuaW5nIHVwIGZyb250IHRv IHVzZSBjMTRuIHNwYXJpbmdseSwgb25seSB3aGVyZSBvdGhlciBwcm90b2NvbCBjaG9pY2VzIGFy ZSB3b3JzZS4NCg0KVmFyaW91cyBKU09OIGMxNG4gcHJvcG9zYWxzIHNvIGZhciBhZ3JlZSBvbiB0 aGUgYmFzaWNzIChzb3J0IG9iamVjdHMga2V5cywgbm8gZXh0cmEgd2hpdGUgc3BhY2UsIDEgZm9y bSBmb3IgbnVtYmVycyksIGJ1dCBza2ltcCBvbiBzb21lIGZpbmUgZGV0YWlscyAod2hpY2ggY2hh cnMgdG8gZXNjYXBlLCBlc2NhcGUgYXMgXHV4eHh4IG9yIFx4LCBmbG9hdGluZyBwb2ludCBudW1i ZXJzKS4gQSBzcGVjIHRvIGZpeCB0aG9zZSBkZXRhaWxzIGZvciBpbnRlcm9wZXJhYmlsaXR5IHNl ZW1zIGxpa2UgYSBnb29kIHRoaW5nIHRvIGRvIGF0IHRoZSBJRVRGOyBub3cuDQoNCmRyYWZ0LXN0 YXlrb3YtaHUtanNvbi1jYW5vbmljYWwtZm9ybSBpcyA0IHBhZ2VzIChpbmNsdWRpbmcgYm9pbGVy cGxhdGUsIGV4YW1wbGVzLCBldmVyeXRoaW5nKS4gSXQgbmVlZHMgYSBmZXcgbW9yZSB0byBuYWls IGRvd24gdGhlIGRldGFpbHMuDQoNCkkgcmVjb21tZW5kIGFkZGluZyBKU09OIGMxNG4gdG8gdGhl IGNoYXJ0ZXIuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KRnJvbToganNvbi1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86anNvbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGltIEJyYXkN ClNlbnQ6IFdlZG5lc2RheSwgMjAgRmVicnVhcnkgMjAxMyAyOjE4IFBNDQpUbzogTmljbyBXaWxs aWFtcw0KQ2M6IEZyYW5jaXMgR2FsaWVndWU7IFBhdWwgSG9mZm1hbjsgUGF1bCBDLiBCcnlhbjsg anNvbkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtKc29uXSBDYW5vbmljYWxpemF0aW9uDQoNCk9L LCB0aGlzIGRpc2N1c3Npb24gaGFzIGNvbnZpbmNlZCBtZSB0aGF0IHRoZXJl4oCZcyBubyByZWFs IG5lZWQgZm9yIHRoaXMgZ3JvdXAgdG8gcHJvYWN0aXZlbHkgdGFrZSB1cCBKU09OIGMxNG4uICBJ ZiBhdCBzb21lIGZ1dHVyZSBwb2ludCB0aGVyZeKAmXMgYSBzdHJvbmcgZGVtb25zdHJhdGVkIHJl YWwgKG5vdCBoeXBvdGhldGljYWwpIHVzZSBjYXNlLCBpdOKAmXMgYSBmYWlybHkgdHJhY3RhYmxl IHByb2JsZW0uICBCdXQgZm9yIG5vdywgaXTigJlzIHVubmVjZXNzYXJ5IHdvcmsuDQotVA0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E115076344B3WSMSG3153Vsrv_ 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 YXNzPU1zb05vcm1hbD4mZ3Q7IE9LLCB0aGlzIGRpc2N1c3Npb24gaGFzIGNvbnZpbmNlZCBtZSB0 aGF0IHRoZXJl4oCZcyBubyByZWFsIG5lZWQgZm9yIHRoaXMgZ3JvdXAgdG8gcHJvYWN0aXZlbHkg dGFrZSB1cCBKU09OIGMxNG4uJm5ic3A7IElmIGF0IHNvbWUgZnV0dXJlIHBvaW50IHRoZXJl4oCZ cyBhIHN0cm9uZyBkZW1vbnN0cmF0ZWQgcmVhbCAobm90IGh5cG90aGV0aWNhbCkgdXNlIGNhc2Us IGl04oCZcyBhIGZhaXJseSB0cmFjdGFibGUgcHJvYmxlbS4mbmJzcDsgQnV0IGZvciBub3csIGl0 4oCZcyB1bm5lY2Vzc2FyeSB3b3JrLjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5UaGVyZSBpcyBpbnRlcmVzdCBpbiBKU09OIGNhbm9uaWNhbGl6YXRpb24sIGRlc3Bp dGUgdGhlIHRyZXBpZGF0aW9uOiBkcmFmdC1zdGF5a292LWh1LWpzb24tY2Fub25pY2FsLWZvcm07 IHRoaXMgZW1haWwgZGlzY3Vzc2lvbjsgPGEgaHJlZj0iaHR0cDovL3dpa2kubGFwdG9wLm9yZy9n by9DYW5vbmljYWxfSlNPTiI+aHR0cDovL3dpa2kubGFwdG9wLm9yZy9nby9DYW5vbmljYWxfSlNP TjwvYT47IGRpc2N1c3Npb25zIGluIEpPU0UgV0c7IDxhIGhyZWY9Imh0dHA6Ly9zdGFja292ZXJm bG93LmNvbS9xdWVzdGlvbnMvNDY3MDQ5NC9ob3ctdG8tY3J5cHRvZ3JhcGhpY2FsbHktaGFzaC1h LWpzb24tb2JqZWN0Ij5odHRwOi8vc3RhY2tvdmVyZmxvdy5jb20vcXVlc3Rpb25zLzQ2NzA0OTQv aG93LXRvLWNyeXB0b2dyYXBoaWNhbGx5LWhhc2gtYS1qc29uLW9iamVjdDwvYT47IGEgY291cGxl IG9mIGdpdGh1YiBwcm9qZWN0czsgYmVuY29kZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFkZCB0byB0 aGF0IHRoZSBmYWN0IHRoYXQgaXQgd2FzIGZlbHQgbmVjZXNzYXJ5IHRvIGRlZmluZSBjMTRuIGZv ciBYTUwgYW5kIEFTTi4xIEJFUiAoREVSIGFuZCBDRVIpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QzE0 biBoYXMgY2F1c2VkIGxvdHMgb2YgcGFpbiBzbyBhIEpTT04gYzE0biBzcGVjIHNob3VsZCBoYXZl IGEgYmlnIHdhcm5pbmcgdXAgZnJvbnQgdG8gdXNlIGMxNG4gc3BhcmluZ2x5LCBvbmx5IHdoZXJl IG90aGVyIHByb3RvY29sIGNob2ljZXMgYXJlIHdvcnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VmFy aW91cyBKU09OIGMxNG4gcHJvcG9zYWxzIHNvIGZhciBhZ3JlZSBvbiB0aGUgYmFzaWNzIChzb3J0 IG9iamVjdHMga2V5cywgbm8gZXh0cmEgd2hpdGUgc3BhY2UsIDEgZm9ybSBmb3IgbnVtYmVycyks IGJ1dCBza2ltcCBvbiBzb21lIGZpbmUgZGV0YWlscyAod2hpY2ggY2hhcnMgdG8gZXNjYXBlLCBl c2NhcGUgYXMgXHV4eHh4IG9yIFx4LCBmbG9hdGluZyBwb2ludCBudW1iZXJzKS4gQSBzcGVjIHRv IGZpeCB0aG9zZSBkZXRhaWxzIGZvciBpbnRlcm9wZXJhYmlsaXR5IHNlZW1zIGxpa2UgYSBnb29k IHRoaW5nIHRvIGRvIGF0IHRoZSBJRVRGOyBub3cuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5kcmFmdC1z dGF5a292LWh1LWpzb24tY2Fub25pY2FsLWZvcm0gaXMgNCBwYWdlcyAoaW5jbHVkaW5nIGJvaWxl cnBsYXRlLCBleGFtcGxlcywgZXZlcnl0aGluZykuIEl0IG5lZWRzIGEgZmV3IG1vcmUgdG8gbmFp bCBkb3duIHRoZSBkZXRhaWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSByZWNvbW1lbmQgYWRkaW5n IEpTT04gYzE0biB0byB0aGUgY2hhcnRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0tPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkph bWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3Jt YWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Iic+IGpzb24tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpzb24tYm91bmNlc0BpZXRmLm9yZ10g PGI+T24gQmVoYWxmIE9mIDwvYj5UaW0gQnJheTxicj48Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCAy MCBGZWJydWFyeSAyMDEzIDI6MTggUE08YnI+PGI+VG86PC9iPiBOaWNvIFdpbGxpYW1zPGJyPjxi PkNjOjwvYj4gRnJhbmNpcyBHYWxpZWd1ZTsgUGF1bCBIb2ZmbWFuOyBQYXVsIEMuIEJyeWFuOyBq c29uQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW0pzb25dIENhbm9uaWNhbGl6YXRp b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1ib3R0b206MTIuMHB0Jz5PSywgdGhpcyBkaXNjdXNzaW9uIGhhcyBjb252aW5jZWQgbWUg dGhhdCB0aGVyZeKAmXMgbm8gcmVhbCBuZWVkIGZvciB0aGlzIGdyb3VwIHRvIHByb2FjdGl2ZWx5 IHRha2UgdXAgSlNPTiBjMTRuLiZuYnNwOyBJZiBhdCBzb21lIGZ1dHVyZSBwb2ludCB0aGVyZeKA mXMgYSBzdHJvbmcgZGVtb25zdHJhdGVkIHJlYWwgKG5vdCBoeXBvdGhldGljYWwpIHVzZSBjYXNl LCBpdOKAmXMgYSBmYWlybHkgdHJhY3RhYmxlIHByb2JsZW0uJm5ic3A7IEJ1dCBmb3Igbm93LCBp dOKAmXMgdW5uZWNlc3Nhcnkgd29yay48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+LVQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E115076344B3WSMSG3153Vsrv_-- From Michael.Jones@microsoft.com Tue Feb 19 19:56:25 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEB721F8855 for ; Tue, 19 Feb 2013 19:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iadc9Awc3kqU for ; Tue, 19 Feb 2013 19:56:24 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.30]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8FA21F8853 for ; Tue, 19 Feb 2013 19:56:24 -0800 (PST) Received: from BL2FFO11FD007.protection.gbl (10.173.161.204) by BL2FFO11HUB014.protection.gbl (10.173.160.106) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 20 Feb 2013 03:56:21 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD007.mail.protection.outlook.com (10.173.161.3) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 20 Feb 2013 03:56:21 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Wed, 20 Feb 2013 03:56:09 +0000 From: Mike Jones To: "Paul C. Bryan" , Tim Bray , "Nico Williams" Thread-Topic: [Json] Canonicalization Thread-Index: AQHODxli7EFk+IKM5U2ZmOMMlqjPFpiCHjrq Date: Wed, 20 Feb 2013 03:56:08 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367478431@TK5EX14MBXC284.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367478431TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(479174001)(377454001)(51704002)(199002)(189002)(24454001)(74662001)(74502001)(54356001)(79102001)(54316002)(51856001)(56776001)(80022001)(512944001)(55846006)(46102001)(50986001)(16236675001)(56816002)(49866001)(47976001)(47736001)(4396001)(33656001)(5343655001)(31966008)(16406001)(65816001)(53806001)(47446002)(5343635001)(76482001)(77982001)(44976002)(59766001)(20776003)(63696002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB014; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07630F72AD Cc: Francis Galiegue , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:56:25 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367478431TK5EX14MBXC284r_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 ________________________________ From: Paul C. Bryan Sent: 2/19/2013 7:21 PM To: Tim Bray; Nico Williams Cc: Francis Galiegue; Paul Hoffman; json@ietf.org Subject: Re: [Json] Canonicalization +1 Tim Bray wrote: >OK, this discussion has convinced me that there=92s no real need for this >group to proactively take up JSON c14n. If at some future point there=92s= a >strong demonstrated real (not hypothetical) use case, it=92s a fairly >tractable problem. But for now, it=92s unnecessary work. > >-T > > >On Tue, Feb 19, 2013 at 7:11 PM, Nico Williams wrot= e: > >> On Tue, Feb 19, 2013 at 9:00 PM, Francis Galiegue >> wrote: >> > On Wed, Feb 20, 2013 at 3:36 AM, Nico Williams >> wrote: >> > [...] >> >> >> >> Yes and no. If the verifier and the signer both have the same >> >> document then no c14n is needed. If the verifier must reconstruct th= e >> >> signed document -as opposed to receiving it from the signer- then the >> >> verifier must reconstruct exactly the signed document or the signatur= e >> >> will not verify. >> >> >> > >> > There is one thing I don't get: in any case, what is transmitted over >> > the network is just a stream of bytes. One end writes that stream, the >> > other reads it. >> >> No, in this one case the two ends construct some data. A good example >> would be channel bindings (RFCs 5056, 5929), except that mostly that >> has no structure, so it's not really a good example after all, but it >> illustrates the point. >> >> > In order for the receiving end to interpret that data, should signing >> > be used, it needs to verify that the _byte stream_, not its >> > interpretation, is correct. That byte stream MAY be JSON. It may not >> > be. >> >> That's just it: in this case the data isn't transmitted, only the >> signature. There's many protocols that transmit signatures (or >> hashes) but not necessarily contents. E.g., rsync. What if you had a >> JSON-based synchronization protocol and you're sending file metadata, >> only there's a lot of it (e.g., large ACLs), and you're trying to >> avoid sending it, so you send file names and metadata hashes, and if >> the receiver's don't match then you send the actual metadata? >> >> Nico >> -- >> _______________________________________________ >> 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 --_000_4E1F6AAD24975D4BA5B168042967394367478431TK5EX14MBXC284r_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1

From: Paul C= . Bryan
Sent: 2/19/2= 013 7:21 PM
To: Tim Br= ay; Nico Williams
Cc: Franci= s Galiegue; Paul Hoffman; json@ietf.org
Subject: Re: [J= son] Canonicalization

+1

Tim Bray <tbray@textuality.com> wrote:

>OK, this discussion has convinced me that there=92s no real need for th= is
>group to proactively take up JSON c14n.  If at some future point t= here=92s a
>strong demonstrated real (not hypothetical) use case, it=92s a fairly >tractable problem.  But for now, it=92s unnecessary work.
>
>-T
>
>
>On Tue, Feb 19, 2013 at 7:11 PM, Nico Williams <nico@cryptonector.co= m>wrote:
>
>> On Tue, Feb 19, 2013 at 9:00 PM, Francis Galiegue <fgaliegue@gm= ail.com>
>> wrote:
>> > On Wed, Feb 20, 2013 at 3:36 AM, Nico Williams <nico@crypt= onector.com>
>> wrote:
>> > [...]
>> >>
>> >> Yes and no.  If the verifier and the signer both hav= e the same
>> >> document then no c14n is needed.  If the verifier mu= st reconstruct the
>> >> signed document -as opposed to receiving it from the sign= er- then the
>> >> verifier must reconstruct exactly the signed document or = the signature
>> >> will not verify.
>> >>
>> >
>> > There is one thing I don't get: in any case, what is transmit= ted over
>> > the network is just a stream of bytes. One end writes that st= ream, the
>> > other reads it.
>>
>> No, in this one case the two ends construct some data.  A goo= d example
>> would be channel bindings (RFCs 5056, 5929), except that mostly th= at
>> has no structure, so it's not really a good example after all, but= it
>> illustrates the point.
>>
>> > In order for the receiving end to interpret that data, should= signing
>> > be used, it needs to verify that the _byte stream_, not its >> > interpretation, is correct. That byte stream MAY be JSON. It = may not
>> > be.
>>
>> That's just it: in this case the data isn't transmitted, only the<= br> >> signature.  There's many protocols that transmit signatures (= or
>> hashes) but not necessarily contents.  E.g., rsync.  Wha= t if you had a
>> JSON-based synchronization protocol and you're sending file metada= ta,
>> only there's a lot of it (e.g., large ACLs), and you're trying to<= br> >> avoid sending it, so you send file names and metadata hashes, and = if
>> the receiver's don't match then you send the actual metadata?
>>
>> Nico
>> --
>> _______________________________________________
>> 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
 --_000_4E1F6AAD24975D4BA5B168042967394367478431TK5EX14MBXC284r_-- From sayrer@gmail.com Tue Feb 19 22:47:15 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D65021F8956 for ; Tue, 19 Feb 2013 22:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 060Gtheu36ns for ; Tue, 19 Feb 2013 22:47:14 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8B86D21F8952 for ; Tue, 19 Feb 2013 22:47:14 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ez12so5780882wid.6 for ; Tue, 19 Feb 2013 22:47:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=/zOzG6g7NaltUh9tkzu0NBqL58czh1vuI2E5PfzhR4I=; b=xF7sJbuAX7sGbrc9H3goZP22OQSaafqs0eCF5Vp37/1FxqvKl/ypBGGr+tYvhkUHIG Hj1vDg+FPjSC3sZFt/aj0XSbRy46oz2Z/kmLEz9T0HIAKqiTn2xv/Jq3F/SkY3fC2IGZ 3bsBIfu4PKXt8dE7HfjUhHKulN3NLkQrkLkdiQUDhcuCTqniQ5cxykpD9UnJhmMwK+yJ tacg/boWArnGiK9zYW5twyx6BBHaUu/uVHLloIqSxgIF/ZmfsN25Sj7MhsXFe7cAGYcD myLNIwbJK3V7kwR0KspitnmgbpSCB5Wq0X5/bN4wNhenoyi1y7LI805NqU6xTQsKYnGQ aZNg== MIME-Version: 1.0 X-Received: by 10.180.24.229 with SMTP id x5mr30309819wif.17.1361342833719; Tue, 19 Feb 2013 22:47:13 -0800 (PST) Received: by 10.194.138.170 with HTTP; Tue, 19 Feb 2013 22:47:13 -0800 (PST) Date: Tue, 19 Feb 2013 22:47:13 -0800 Message-ID: From: R S To: json@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Json] Proposed document set from this WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 06:47:15 -0000 Paul Hoffman wrote: > 1) JSON base, 4627bis > Target: current JSON users > Current: grammar, encoding, parser rules, generator rules, MIME type re= gistration) > New: Internet transfer rules, list of changes from 4627 My suggestion is for the WG to target this use case only, and to treat the JSON processing rules in ECMAScript 5, Section 15.12 (The JSON Object) as the baseline for rules regarding encoding and decoding, rather than RFC4627. The motivation for this recommendation is that it's impractical to make breaking change to this algorithm on a reasonable time scale. But JSON RFC readers will expect to interoperate with web browsers and other JavaScript embeddings. The most significant delta concerns this line from RFC4627: > A JSON parser MAY accept non-JSON forms or extensions. ES5 parsers must raise an error when they encounter deviations from the grammar defined in ES5: "It is not permitted for a conforming implementation of JSON.parse to extend the JSON grammars." Tim Bray wrote: > \uxxxx is only allowed for chars that must be escaped per the JSON spec > \uxxxx is freely allowed, but the \uxxxx is considered to represent a sin= gle codepoint, and all comparison/hashing > operations have to be conducted codepoint-by-codepoint ES5 mandates \uxxxx for certain control characters and allows it for all (so does RFC4627 "Any character may be escaped."). JavaScript strings are composed of code units. Consider JSONKit's behavior when serializing escaped Unicode: "When JKSerializeOptionEscapeUnicode is enabled, JSONKit will encode Unicode code points that can be encoded as a single UTF16 code unit as \uXXXX, and will encode Unicode code points that require UTF16 surrogate pairs as \uhigh\ulow." json =E2=8A=84 js: > The problem comes down to two unicode characters that are considered line= terminators > in JavaScript: the line separator \u2028 and the paragraph separator \u20= 29. Recommend that encoders escape these characters. Paul Hoffman wrote: > If we are supposed to be keeping backwards compatibility, then yes, it's = too late. > The same is true for changing SHOULD not have duplicate names in objects. ES5 mandates behavior here: "In the case where there are duplicate name Strings within an object, lexically preceding values for the same key shall be overwritten." - Rob From framefritti@gmail.com Tue Feb 19 23:13:14 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A0721F8A6F for ; Tue, 19 Feb 2013 23:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZcrDzT7f77f for ; Tue, 19 Feb 2013 23:13:13 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id D2A0321F8A3F for ; Tue, 19 Feb 2013 23:13:12 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id ge1so5747126lbb.29 for ; Tue, 19 Feb 2013 23:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=Zkv51IH8PV5ySWgIWdWA/mFQfr0kWpzG5SAMUz0BFug=; b=jNvBJUT7m4yWqZYUs76cbxMuwwpwjT6eTgbjPqfXKSIpFnksFgrj2pZ6Z8ytstxvFk Yty9suN1NEZM3vmCZ0V07DjYhoXwi3A2+xmbL4Rz0MNx8KiUFvsucQJW5B/wCRTpEWOJ dkRr9V9MW6hjiBsWM1pIZPj7Nr8RmBW5F6ZdpG/Eyy7ngIaHhHMCXaop2q4xk+2FKI65 /n7mpiwtbxsd+J+TJKwlPOu00elGJAIf2TrqH+sNf7+wtiZV7TpsKAKrGUPYyr8y73Ap ZEjWG21ajVcUBcyBKHBYb61224K0E6IHFPHL9rO9suQX7Dzicz9663o/Kl3on6Ta9CzS CPLA== MIME-Version: 1.0 X-Received: by 10.112.36.38 with SMTP id n6mr3861261lbj.126.1361344381417; Tue, 19 Feb 2013 23:13:01 -0800 (PST) Received: by 10.112.126.74 with HTTP; Tue, 19 Feb 2013 23:13:01 -0800 (PST) In-Reply-To: <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.com> References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.com> Date: Wed, 20 Feb 2013 08:13:01 +0100 Message-ID: From: Riccardo Bernardini To: "json@ietf.org" Content-Type: multipart/alternative; boundary=485b390f7b204578c304d622b097 Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 07:13:14 -0000 --485b390f7b204578c304d622b097 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 20, 2013 at 2:32 AM, Paul C. Bryan wrote: > ** > Because in some cases, there's no guarantee that the JSON value being > verified will be transmitted identically as an octet-string. > Canonicalization, in theory, allows it to be represented during signature > verification the same way it was when it was originally signed. I've seen > some (ugly) ways of working around this by base64-encoding the entire JSON > value and putting it in a JSON string. > Moreover, without canonalization an attack (described, for example, in "Applied Cryptography," Bruce Schneier, Wiley) is possible. Briefly, suppose that Eve, who can ask Bob to sign a "good" JSON, wants to send to Alice a "bad" JSON signed by Bob. In order to do that, Eve takes a "good" JSON object that Bob is willing to sign and the "bad" JSON object that she wants to send to Alice and does some random semantically negligible changes (e.g., adding spaces, newlines or reordering entries) to both objects until she finds two versions that hash to the same value. By the birthday paradox this will take approximately 2^(b/2) trials, where b is the hash size. Now she can ask Bob to sign the good object and "stick" Bob's signature on the bad object. Of course, there are many ways to counteract such an attack. For example, one can use an hash with b=256 bits, so that 2^128 is still a very large number; Bob could do some semantically negligible changes himself before signing or add a random "nonce" somewhere. Nevertheless, this example suggests that the possibility of having several semantically equivalent descriptions of the same object could give rise to security issues. Riccardo > > > Paul > > > On Wed, 2013-02-20 at 02:28 +0100, Francis Galiegue wrote: > > On Wed, Feb 20, 2013 at 2:21 AM, Paul Hoffman wrote: > [snip] > > Canonicalizing is part of the signature process, not part of the JSON creation process. The spec that specifies how to sign JSON will pick what to do about canonicalization; the JOSE WG is dealing with this. > > > > Just curious: how shoud signing require canonicalization in any way? > As long as you have a media type and an encoding, the content is fully > defined, right? How would JSON be any different than, say, text/plain > here? AFAIK, text/plain has never required any "canonicalization" of > any kind... > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --485b390f7b204578c304d622b097 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 20, 2013 at 2:32 AM, Paul C.= Bryan <pbryan@anode.ca> wrote:
=20 =20
Because in some cases, there's no guarantee that the JSON value being v= erified will be transmitted identically as an octet-string. Canonicalizatio= n, in theory, allows it to be represented during signature verification the= same way it was when it was originally signed. I've seen some (ugly) w= ays of working around this by base64-encoding the entire JSON value and put= ting it in a JSON string.

Moreover, without canonalization an attack= (described, for example, in "Applied Cryptography," Bruce Schnei= er, Wiley) is possible. =A0

Briefly, suppose that = Eve, who can ask Bob to sign a "good" JSON, wants to send to Alic= e a "bad" JSON signed by Bob. =A0In order to do that, Eve takes a= "good" JSON object that Bob is willing to sign and the "bad= " JSON object that she wants to send to Alice and does some random sem= antically negligible changes (e.g., adding spaces, newlines or reordering e= ntries) to both objects until she finds two versions that hash to the same = value. =A0By the birthday paradox this will take approximately 2^(b/2) tria= ls, where b is the hash size. Now she can ask Bob to sign the good object a= nd "stick" Bob's signature on the bad object.=A0

Of course, there are many ways to counteract such an at= tack. =A0For example, one can use an hash with b=3D256 bits, so that 2^128 = is still a very large number; =A0Bob could do some semantically negligible = changes himself before signing or add a random "nonce" somewhere.= =A0Nevertheless, this example suggests that the possibility of having seve= ral semantically equivalent descriptions of the same object could give rise= to security issues.
=A0
Riccardo


Paul


On Wed, 2013-02-20 at 02:28 +0100, Francis Galiegue wrote: 
On Wed, Feb 20, 2013 at 2:21 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
[snip]
> Canonicalizing is part of the signature process, not part of the JSON =
creation process. The spec that specifies how to sign JSON will pick what t=
o do about canonicalization; the JOSE WG is dealing with this.
>

Just curious: how shoud signing require canonicalization in any way?
As long as you have a media type and an encoding, the content is fully
defined, right? How would JSON be any different than, say, text/plain
here? AFAIK, text/plain has never required any "canonicalization"=
 of
any kind...


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


--485b390f7b204578c304d622b097-- From jhildebr@cisco.com Wed Feb 20 01:29:26 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D84421F86EA for ; Wed, 20 Feb 2013 01:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5hrNret1Wc1 for ; Wed, 20 Feb 2013 01:29:25 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 76B6321F86F4 for ; Wed, 20 Feb 2013 01:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=875; q=dns/txt; s=iport; t=1361352558; x=1362562158; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GiJ4Xo7BkGKbxjFHCjlGBencWRp/PtHXyvP+AOQJcmk=; b=NFLhpprzCji7d4khxgFdNAPf3tao6iLgfCGQBxIVewygGTav2pc3bsYJ +2g+6HeueRzRYsnFVdnX0Sd9e8DgqjJ+qJ36I2m8vP/3zxLa7CkFqsf+V gDxw8nE9tgOJywKzIwPm5F2O5En/YxW7ftq8PgTyx0QwFLoW5eiSIFh2v Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAAiWJFGtJXG//2dsb2JhbABFhgK6Un4Wc4IfAQEBBDo0CxIBCA4KChQxESUCBAENBQiHeAMPtXINiVqMN4ImMQeCX2EDlFCNHoUVgweCJw X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; d="scan'208";a="179135102" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 20 Feb 2013 09:29:18 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1K9TI8X012826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Feb 2013 09:29:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 03:29:17 -0600 From: "Joe Hildebrand (jhildebr)" To: Francis Galiegue , "Paul C. Bryan" Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODv+8V0zn7u2LJ02Uk/kU6xbmZ5iCSWCAgAAhXQA= Date: Wed, 20 Feb 2013 09:29:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.21.122.132] Content-Type: text/plain; charset="us-ascii" Content-ID: <8DB7E7EFF580C3418AC95AE42A661235@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 09:29:26 -0000 On 2/19/13 5:29 PM, "Francis Galiegue" wrote: >On Wed, Feb 20, 2013 at 1:17 AM, Paul C. Bryan wrote: >> Should two representations of the same JSON (string) value be c14n'ed >> differently? I think not*. >> >> If not, then I think comparisons would need to occur by parsing JSON >>strings >> into Unicode codepoints. >> > >+1 on that. I see no reason why "a" and "\u0061" should be treated >differently at all. > >Or I have completely misundertood the point... It depends why you are canonicalizing. If it's for crypto reasons (for which I think c14n is usually bad fit), then you're trying to ensure that different implementations achieved the same octet sequence from the same starting point. Therefore, you want to ensure that you only ever generate exactly one of "a" or "\u0061". --=20 Joe Hildebrand From cabo@tzi.org Wed Feb 20 05:05:13 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C7421F87D1 for ; Wed, 20 Feb 2013 05:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.11 X-Spam-Level: X-Spam-Status: No, score=-106.11 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwmXc3Nf7i9t for ; Wed, 20 Feb 2013 05:05:13 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C083C21F87C6 for ; Wed, 20 Feb 2013 05:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r1KD53RB004649; Wed, 20 Feb 2013 14:05:03 +0100 (CET) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CF60D3E8A; Wed, 20 Feb 2013 14:05:03 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> Date: Wed, 20 Feb 2013 14:05:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0E9B4E15-8D15-4301-9808-BB1995A06149@tzi.org> References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1499) Cc: "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 13:05:13 -0000 On Feb 20, 2013, at 02:21, Paul Hoffman wrote: > Canonicalizing is part of the signature process I hope not. I want to use JSON in constrained systems. Anything that is saddled with a process as complex as canonicalization = will turn out to be a non-starter for this area of application. If there is a value in (1) taking apart (parsing) a JSON text, (2) = keeping the parse tree (or some other form, which by the way is not = standardized in any way), then (3) reconstructing a JSON text from that = non-standard form, and then (4) checking a digest/authentication value = from the reconstructed text, I'd like to know about that benefit. Not = in theoretical terms, but in terms of building actual systems. By the way, I do find it theoretically interesting to be able to compare = two JSON texts at a semantic level. (Having that equality relation defined amounts to having defined that = semantics. That might help.*) But please don't do any useful spec that requires implementing c14n. (Or, at least do another equivalent spec without c14n that makes the = previous one unnecessary to implement.) And, if you actually do need to do c14n for something, do it by turning = the JSON text into a byte string that is optimized for being the result = of c14n, not into JSON text again. (You can start from msgpack if you need help in visualizing such a byte = string. Probably much simpler than msgpack, though.) Gr=FC=DFe, Carsten *) {"foo": 1, "bar": 2} =3D?=3D {"bar": 2, "foo": 1} [1234123412341234.1] =3D?=3D [1234123412341234.2] [12341234123412341234.1] =3D?=3D [12341234123412341234.2] [1234123412341234] =3D?=3D [1234123412341234.0] etc. Just to make these interesting, I posit that all of these pairs are not = equal. This is obviously wrong for anyone but me, but which of the other 15 = alternatives is righter? Why? From paul.hoffman@vpnc.org Wed Feb 20 08:20:14 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8F221F88CF for ; Wed, 20 Feb 2013 08:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+RZDYsNYSZR for ; Wed, 20 Feb 2013 08:20:13 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3F421F88B9 for ; Wed, 20 Feb 2013 08:20:11 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1KGK8iL086894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2013 09:20:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Wed, 20 Feb 2013 08:20:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <734F6B55-2AA7-44A6-A636-7221C8518479@vpnc.org> References: To: R S X-Mailer: Apple Mail (2.1499) Cc: json@ietf.org Subject: Re: [Json] Proposed document set from this WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 16:20:14 -0000 On Feb 19, 2013, at 10:47 PM, R S wrote: > My suggestion is for the WG to target this use case only, and to treat > the JSON processing rules in ECMAScript 5, Section 15.12 (The JSON > Object) as the baseline for rules regarding encoding and decoding, > rather than RFC4627. It feels weird to be agreeing with Rob so early in the discusson, but I = agree on both parts. - Charter 4627bis *and nothing else*, so that the 4627bis work is done = without distraction. It is really clear that canonicalization and = schema/description have the *high* potential for distraction. - Say that the base for that one charter item is RFC 4627 *and* = ECMAScript 5, which seems to be widely-deployed. - Say that the WG is likely to recharter while 4627bis is under review = by the IESG to discuss schema/description. - Given the recent consensus, don't mention canonicalization in the = charter at all unless another WG or SDO has specifically asked us to = work on it. --Paul Hoffman= From Michael.Jones@microsoft.com Wed Feb 20 08:30:10 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFA121F88F1 for ; Wed, 20 Feb 2013 08:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfqB6emNcTIo for ; Wed, 20 Feb 2013 08:30:09 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.29]) by ietfa.amsl.com (Postfix) with ESMTP id 8670621F86BA for ; Wed, 20 Feb 2013 08:30:09 -0800 (PST) Received: from BL2FFO11FD006.protection.gbl (10.173.161.200) by BL2FFO11HUB039.protection.gbl (10.173.160.245) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 20 Feb 2013 16:30:00 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD006.mail.protection.outlook.com (10.173.161.2) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 20 Feb 2013 16:30:00 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Wed, 20 Feb 2013 16:29:30 +0000 From: Mike Jones To: Paul Hoffman , R S Thread-Topic: [Json] Proposed document set from this WG Thread-Index: AQHODzYddsZobCY4qEWkoFxnlmNwu5iC7eAAgAACizA= Date: Wed, 20 Feb 2013 16:29:29 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436747A9DC@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <734F6B55-2AA7-44A6-A636-7221C8518479@vpnc.org> In-Reply-To: <734F6B55-2AA7-44A6-A636-7221C8518479@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(24454001)(13464002)(377454001)(16406001)(66066001)(50986001)(59766001)(77982001)(49866001)(79102001)(65816001)(56776001)(47976001)(80022001)(5343635001)(47736001)(20776003)(4396001)(23726001)(74662001)(44976002)(54356001)(51856001)(46406002)(5343655001)(31966008)(63696002)(56816002)(47776003)(76482001)(50466001)(33656001)(54316002)(74502001)(46102001)(53806001)(55846006)(47446002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB039; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07630F72AD Cc: "json@ietf.org" Subject: Re: [Json] Proposed document set from this WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 16:30:10 -0000 +1 -----Original Message----- From: json-bounces@ietf.org [mailto:json-bounces@ietf.org] On Behalf Of Pau= l Hoffman Sent: Wednesday, February 20, 2013 8:20 AM To: R S Cc: json@ietf.org Subject: Re: [Json] Proposed document set from this WG On Feb 19, 2013, at 10:47 PM, R S wrote: > My suggestion is for the WG to target this use case only, and to treat=20 > the JSON processing rules in ECMAScript 5, Section 15.12 (The JSON > Object) as the baseline for rules regarding encoding and decoding,=20 > rather than RFC4627. It feels weird to be agreeing with Rob so early in the discusson, but I agr= ee on both parts. - Charter 4627bis *and nothing else*, so that the 4627bis work is done with= out distraction. It is really clear that canonicalization and schema/descri= ption have the *high* potential for distraction. - Say that the base for that one charter item is RFC 4627 *and* ECMAScript = 5, which seems to be widely-deployed. - Say that the WG is likely to recharter while 4627bis is under review by t= he IESG to discuss schema/description. - Given the recent consensus, don't mention canonicalization in the charter= at all unless another WG or SDO has specifically asked us to work on it. --Paul Hoffman _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json From tony@att.com Wed Feb 20 08:36:37 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0E721F8816 for ; Wed, 20 Feb 2013 08:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.071 X-Spam-Level: X-Spam-Status: No, score=-107.071 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrVSGhN7gDke for ; Wed, 20 Feb 2013 08:36:36 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDB421F8962 for ; Wed, 20 Feb 2013 08:36:36 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 39bf4215.0.3667002.00-477.10173202.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 20 Feb 2013 16:36:36 +0000 (UTC) X-MXL-Hash: 5124fb947f250035-c25e335fa2a2c10c039082ec2acf2510367316aa Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1KGaZu5021879 for ; Wed, 20 Feb 2013 11:36:35 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1KGaTjf021817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Feb 2013 11:36:30 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Wed, 20 Feb 2013 11:36:10 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id r1KGaAxc017588 for ; Wed, 20 Feb 2013 11:36:10 -0500 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id r1KGa6QO017405 for ; Wed, 20 Feb 2013 11:36:08 -0500 Received: from [135.70.29.22] (vpn-135-70-29-22.vpn.west.att.com[135.70.29.22]) by maillennium.att.com (mailgw1) with ESMTP id <20130220163458gw100632mne> (Authid: tony); Wed, 20 Feb 2013 16:34:58 +0000 X-Originating-IP: [135.70.29.22] Message-ID: <5124FB74.9050207@att.com> Date: Wed, 20 Feb 2013 11:36:04 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: json@ietf.org References: <734F6B55-2AA7-44A6-A636-7221C8518479@vpnc.org> In-Reply-To: <734F6B55-2AA7-44A6-A636-7221C8518479@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=Z9Rb6gtA c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=5AE5csG8RS0A:10 a=djqtFF5C5r8A:10 a=jufuc0U89qMA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=V4ehOIsOMmYA:10 a=pGLkceISAAAA:8 a=jnmcSc3tiodUW] X-AnalysisOut: [5I9Or0A:9 a=wPNLvfGTeEIA:10 a=MSl-tDqOz04A:10] Subject: Re: [Json] Proposed document set from this WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 16:36:37 -0000 On 2/20/2013 11:20 AM, Paul Hoffman wrote: > On Feb 19, 2013, at 10:47 PM, R S wrote: >> My suggestion is for the WG to target this use case only, and to treat >> the JSON processing rules in ECMAScript 5, Section 15.12 (The JSON >> Object) as the baseline for rules regarding encoding and decoding, >> rather than RFC4627. > It feels weird to be agreeing with Rob so early in the discusson, but I agree on both parts. > > - Charter 4627bis *and nothing else*, so that the 4627bis work is done without distraction. It is really clear that canonicalization and schema/description have the *high* potential for distraction. > - Say that the base for that one charter item is RFC 4627 *and* ECMAScript 5, which seems to be widely-deployed. > - Say that the WG is likely to recharter while 4627bis is under review by the IESG to discuss schema/description. > - Given the recent consensus, don't mention canonicalization in the charter at all unless another WG or SDO has specifically asked us to work on it. +1 From jhildebr@cisco.com Wed Feb 20 08:51:07 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCD821F88A9 for ; Wed, 20 Feb 2013 08:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIQ3kJwhX8mc for ; Wed, 20 Feb 2013 08:51:06 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4D521F87CC for ; Wed, 20 Feb 2013 08:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2130; q=dns/txt; s=iport; t=1361379066; x=1362588666; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=JzKC1hTYcqdLmCDQL09ca/MRRGIA6v3iOTHx7vIYnd8=; b=M8dIlG8tOKlewRwt3Il4Qku7qsOdnaM6ekwT5IO37skfVUSHtpuO8wt9 xPsuykZ5hZ7d6JLFiEBUekpi54CFtNBNpXJy00jVxW3+LtkBoVKY2Qs5D 2+uSjMjtbz9VNR8jPwVbJ3wdjULzM1674ZReNGgjYFKdesUApdeMcYhCw I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAL39JFGtJV2a/2dsb2JhbABFwFmBARZzgh8BAQEEAQEBNzQLEgEIGAoUMQYLJQIEAQ0FCId4Aw8MtlgNiUsEjDeCJjEHgl9hA5RRjSGFFYMHgic X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; d="scan'208";a="179238529" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 20 Feb 2013 16:51:06 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1KGp6KR010730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Feb 2013 16:51:06 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 10:51:05 -0600 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman , R S Thread-Topic: [Json] Proposed document set from this WG Thread-Index: AQHODzYd4GSxDud/oEmpRv3zklbNKpiDUnUA//+TRwA= Date: Wed, 20 Feb 2013 16:51:05 +0000 Message-ID: In-Reply-To: <734F6B55-2AA7-44A6-A636-7221C8518479@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <7BDEBE6F9B041740A2B85A531BA0DCFB@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Proposed document set from this WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 16:51:07 -0000 +1, with one caveat. What if we find ECMAScript 5 and 4627 to be in conflict in some way? In particular, I find: 15.12: "Conforming implementations of JSON.parse and JSON.stringify must support the exact interchange format described in this specification without any deletions or extensions to the format. This differs from RFC 4627 which permits a JSON parser to accept non-JSON forms and extensions." 15.12.1.1: The ABNF is constructed differently. Hopefully in a completely compatible way (looks that way with a couple of minutes analysis), but we all know how finicky even small changes to ABNF can be. 15.12.1.2: JSONText can be any value, not just object or array. I think this would be a positive change for 4627bis, perhaps with a note that older processors are likely to reject any top level that is not an object or array. On 2/20/13 9:20 AM, "Paul Hoffman" wrote: >On Feb 19, 2013, at 10:47 PM, R S wrote: > >> My suggestion is for the WG to target this use case only, and to treat >> the JSON processing rules in ECMAScript 5, Section 15.12 (The JSON >> Object) as the baseline for rules regarding encoding and decoding, >> rather than RFC4627. > >It feels weird to be agreeing with Rob so early in the discusson, but I >agree on both parts. > >- Charter 4627bis *and nothing else*, so that the 4627bis work is done >without distraction. It is really clear that canonicalization and >schema/description have the *high* potential for distraction. > >- Say that the base for that one charter item is RFC 4627 *and* >ECMAScript 5, which seems to be widely-deployed. > >- Say that the WG is likely to recharter while 4627bis is under review by >the IESG to discuss schema/description. > >- Given the recent consensus, don't mention canonicalization in the >charter at all unless another WG or SDO has specifically asked us to work >on it. > >--Paul Hoffman >_______________________________________________ >json mailing list >json@ietf.org >https://www.ietf.org/mailman/listinfo/json > --=20 Joe Hildebrand From tbray@textuality.com Wed Feb 20 08:57:48 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1860821F875F for ; Wed, 20 Feb 2013 08:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDsIspHjVm6C for ; Wed, 20 Feb 2013 08:57:47 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4988921F8722 for ; Wed, 20 Feb 2013 08:57:47 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa10so4201001pad.41 for ; Wed, 20 Feb 2013 08:57:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Hr+mhGS1woh6ckkArgy6e7VqH/iLuNgsGpF+COizQ5o=; b=HP9rgjKahPTyajcunncM27dwXiPSm8h+oOAAExM7zxx6xBIdy/YZP6j+Fk74Wq0k0F xgCJLuHyy9HCNCLAx0F2h4xOKD493qFTJmkPuthM6Tr0gDeSgvaZbyIitSpLlvnA91sX 3oqBURB0AeVtfR903i6h3+79j+kYBlrhSGITG5BsEJ99ilk27xdq7h3M3QgU/ChA1i72 XuJrbVvPMXdUQLxwxnTgZUfHR4XDL3a6gcgH+BSYGQg/gISaVwEZ1TZP+sQOH2QjE9kb XbqeiTQjDdONXFXIfIMWXzcW/Qch8L/mOywd7OpJh7a/6vZ1vvnCp6emWufOpIqWu8gv KazQ== MIME-Version: 1.0 X-Received: by 10.68.137.42 with SMTP id qf10mr17904463pbb.80.1361379467058; Wed, 20 Feb 2013 08:57:47 -0800 (PST) Received: by 10.66.249.129 with HTTP; Wed, 20 Feb 2013 08:57:46 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <734F6B55-2AA7-44A6-A636-7221C8518479@vpnc.org> Date: Wed, 20 Feb 2013 08:57:46 -0800 Message-ID: From: Tim Bray To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=047d7b2e461489de7004d62adb5c X-Gm-Message-State: ALoCoQmAh5OB1EmQ8JmnD4P/MgmGZMqzFeR9wmvJHoz6qtMP0y6e6hthhN3wBEMF30nk5EoMcS/7 Cc: "json@ietf.org" , Paul Hoffman , R S Subject: Re: [Json] Proposed document set from this WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 16:57:48 -0000 --047d7b2e461489de7004d62adb5c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 to Rob/Paul=92s proposal, and Joe=92s right to be worried, but this is a problem we have to deal with. On Wed, Feb 20, 2013 at 8:51 AM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > > > 15.12.1.2: JSONText can be any value, not just object or array. I think > this would be a positive change for 4627bis, perhaps with a note that > older processors are likely to reject any top level that is not an object > or array. > Eeek, that scares me. That is a huge liberalization; there=92s a lot of co= de out there that assumes that when you parse JSON you get a hash. Thinking off the top of my head: I=92ve seen protocols defined where the payload looks like { "values" : [ ... the array that I actually wanted ...] } But you know, I really like the top-level-is-a-hash assumption; it buys a lot of extensibility. Write your protocol with a MUST-IGNORE policy and people can later enrich it by adding new goodies... but only if the top level is a hash. -T --047d7b2e461489de7004d62adb5c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
+1 to Rob/Paul=92s proposal, and Joe=92s right to be worri= ed, but this is a problem we have to deal with.

On Wed, Feb 20, 2013= at 8:51 AM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com>= wrote:


15.12.1.2: JSONText can = be any value, not just object or array. =A0I think
this would be a positive change for 4627bis, perhaps with a note that
older processors are likely to reject any top level that is not an object or array.

Eeek, that scares me.=A0 That= is a huge liberalization; there=92s a lot of code out there that assumes t= hat when you parse JSON you get a hash.

Thinking off the top of my h= ead: I=92ve seen protocols defined where the payload looks like

{
=A0 "values" : [ ... the array that I actuall= y wanted ...]
}

But you know, I really like the top-le= vel-is-a-hash assumption; it buys a lot of extensibility.=A0 Write your pro= tocol with a MUST-IGNORE policy and people can later enrich it by adding ne= w goodies... but only if the top level is a hash.

=A0-T

--047d7b2e461489de7004d62adb5c-- From paul.hoffman@vpnc.org Wed Feb 20 08:59:02 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799F421F8816 for ; Wed, 20 Feb 2013 08:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edu9LTDfjovZ for ; Wed, 20 Feb 2013 08:59:02 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0990D21F880B for ; Wed, 20 Feb 2013 08:59:02 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1KGx1i7088247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 20 Feb 2013 09:59:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Wed, 20 Feb 2013 08:59:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <17425F97-2FA0-4AED-8F84-4664E5FAC6BC@vpnc.org> References: To: "json@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [Json] Proposed document set from this WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 16:59:02 -0000 On Feb 20, 2013, at 8:51 AM, "Joe Hildebrand (jhildebr)" = wrote: > +1, with one caveat. What if we find ECMAScript 5 and 4627 to be in > conflict in some way? >=20 > In particular, I find: >=20 > 15.12: "Conforming implementations of JSON.parse and JSON.stringify = must > support the exact interchange format described in this specification > without any deletions or extensions to the format. This differs from = RFC > 4627 which permits a JSON parser to accept non-JSON forms and = extensions." >=20 > 15.12.1.1: The ABNF is constructed differently. Hopefully in a = completely > compatible way (looks that way with a couple of minutes analysis), but = we > all know how finicky even small changes to ABNF can be. >=20 > 15.12.1.2: JSONText can be any value, not just object or array. I = think > this would be a positive change for 4627bis, perhaps with a note that > older processors are likely to reject any top level that is not an = object > or array. Proposal: - The WG picks one of the two ways - 4627bis says MUST for that way - In the Introduction (not an appendix), there is a subsection that = lists every change from either 4627 or ECMAScript 5 --Paul Hoffman From fgaliegue@gmail.com Wed Feb 20 09:00:32 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D194E21F8991 for ; Wed, 20 Feb 2013 09:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRiS9WxBsjAv for ; Wed, 20 Feb 2013 09:00:31 -0800 (PST) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id DDA2221F88CC for ; Wed, 20 Feb 2013 09:00:29 -0800 (PST) Received: by mail-ee0-f43.google.com with SMTP id c50so4244613eek.2 for ; Wed, 20 Feb 2013 09:00:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Gt4IF3ZtvRf0QTwiJHWCzhEWZDByHTYIebvPW82B4Gs=; b=emXMOsl6LrSGlqapmcFKwRDf+sd6KYRssTG7EA9idLJGqle82F1YKuSm/pMYwXUVjv HrW+Ibl+YMqkfRmbdXlRzagGmIQ4MQwlDwIzZ7PG2HhTN4bW3qfIrBp6foRWK5yTgnS6 WCgV2JTdBtC55YOjb3QTl7EFNwN0vF42jeKxCFDRpp9Oi//2mY5FOSyZwYHNj5jFckPt M7WocNjRa3F3tkqAXP/RTNH1/5I3YPWHD7HqSlsS3CnV3O7vHcc5qX4Ce4HwSvt+LSMg QRCmt+yMdR5KNF7mqMdBS2c11XSMGWcZh8ezj4v31+Yim95FzSjhDf1EBYy4kRA2icr4 1zlw== MIME-Version: 1.0 X-Received: by 10.14.183.67 with SMTP id p43mr70600726eem.10.1361379629016; Wed, 20 Feb 2013 09:00:29 -0800 (PST) Received: by 10.14.1.7 with HTTP; Wed, 20 Feb 2013 09:00:28 -0800 (PST) In-Reply-To: References: <734F6B55-2AA7-44A6-A636-7221C8518479@vpnc.org> Date: Wed, 20 Feb 2013 18:00:28 +0100 Message-ID: From: Francis Galiegue To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: R S , Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Proposed document set from this WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:00:33 -0000 On Wed, Feb 20, 2013 at 5:57 PM, Tim Bray wrote: [...] >> >> 15.12.1.2: JSONText can be any value, not just object or array. I think >> this would be a positive change for 4627bis, perhaps with a note that >> older processors are likely to reject any top level that is not an objec= t >> or array. > > > Eeek, that scares me. That is a huge liberalization; there=E2=80=99s a l= ot of code > out there that assumes that when you parse JSON you get a hash. > Well, RFC 4627 also "allows" arrays as JSON texts... I agree about any JSON value being possible. In practice, there are a lot of parsers which don't obey RFC 4627 in that they do parse any JSON value whereas they shouldn't... -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From derhoermi@gmx.net Wed Feb 20 09:09:46 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E56E21F8797 for ; Wed, 20 Feb 2013 09:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.966 X-Spam-Level: X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtOSoLOzRexO for ; Wed, 20 Feb 2013 09:09:45 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id F0EE521F8771 for ; Wed, 20 Feb 2013 09:09:44 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LiFq9-1UdTGF08u3-00nMPP for ; Wed, 20 Feb 2013 18:09:44 +0100 Received: (qmail invoked by alias); 20 Feb 2013 17:09:43 -0000 Received: from p5B231E9D.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [91.35.30.157] by mail.gmx.net (mp029) with SMTP; 20 Feb 2013 18:09:43 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18eahwBYmgeVrb0hYb0GQmOjPMlFbmUCrP1R+fKCn 1XahWc95nYF26k From: Bjoern Hoehrmann To: R S Date: Wed, 20 Feb 2013 18:09:45 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: json@ietf.org Subject: Re: [Json] Proposed document set from this WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:09:46 -0000 * R S wrote: >My suggestion is for the WG to target this use case only, and to treat >the JSON processing rules in ECMAScript 5, Section 15.12 (The JSON >Object) as the baseline for rules regarding encoding and decoding, >rather than RFC4627. The ecmascript specification defines a grammar for JSON to explain the behavior of JSON.stringify and JSON.parse and notes that the on-the-wire JSON format is defined in RFC 4627. The only difference between the two grammars is that ecmascript allows values like `null` at the top level, while RFC 4627 is more restrictive. The Working Group might decide to remove this restriction in RFC4627bis, but I see no reason to take the ecmascript specification as a baseline. Also note that since the ecmascript specification does not define an on- the-wire format, it does not address encoding and decoding issues like handling character encodings at all, only RFC 4627 addresses those. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From tbray@textuality.com Wed Feb 20 09:27:13 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B8421F8686 for ; Wed, 20 Feb 2013 09:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.196 X-Spam-Level: X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vaz7yyCtegik for ; Wed, 20 Feb 2013 09:27:13 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0266D21F85D7 for ; Wed, 20 Feb 2013 09:27:12 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa10so4215345pad.41 for ; Wed, 20 Feb 2013 09:27:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=pMvv/9TN/PO7fRQrzugsVTy2s0BLhvG/BYT2LCWNItY=; b=Y0/5wzURPAW4X0VoQbq+LzPZPSKv5LgDdzPklv476Rm7265HN2l/uUOhLBtMZCeZdw jsKQLv7aDbr9f55DeAKk4MIaQ4W9YUE5MmQ7EyLMUphndtV9ohnT3AiuKrSmQ1f3E3Kq WgMWC1hkjt6CkIPrrpRxS8CV3hFKaZnO9MAX3tsl1GvblDXZvGEIonh53k5H+nRnLaq1 L7fyMXm0g3Ha04cusarMWP+OrTamxDR9J7XkfKUVdinXcNBqr3qAxWyvfGPVvS04zhPB ANXpz+lGvLpFncwltqq0O+vcwjF4rhNjGDLQFD0051yYx5iFto+z3OjSS52BqoodmSHv CFTw== MIME-Version: 1.0 X-Received: by 10.66.86.201 with SMTP id r9mr55011866paz.14.1361381232695; Wed, 20 Feb 2013 09:27:12 -0800 (PST) Received: by 10.66.249.129 with HTTP; Wed, 20 Feb 2013 09:27:12 -0800 (PST) X-Originating-IP: [24.84.235.32] Date: Wed, 20 Feb 2013 09:27:12 -0800 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=f46d042fd918c758ab04d62b44b9 X-Gm-Message-State: ALoCoQlyKeWty2uoU4SHwWoBlT92qZjNS+kWKcXkzODE1Pv16GCTq246envxuyHsDi4LIZgozb+e Subject: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:27:13 -0000 --f46d042fd918c758ab04d62b44b9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My proposal is: do nothing. I use JSON for protocol design and work all the time, and have not observed any interop problems in the wild which originate at the JSON parson or construction level. I give the incoming text to the library and it Just Works or reliably reports a syntax botch. I give my data structures to the JSON serializer and cheerfully send off whatever comes out. I read specs and build clients and servers and, when things break, it=92s because I=92m stupidly using a bogus name or value in some field, not because of the serialization. I suggest that there is not a problem here that needs the investment of precious IETF time. -T --f46d042fd918c758ab04d62b44b9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
My proposal is: do nothing.

I use JSON for pro= tocol design and work all the time, and have not observed any interop probl= ems in the wild which originate at the JSON parson or construction level.= =A0 I give the incoming text to the library and it Just Works or reliably r= eports a syntax botch.=A0 I give my data structures to the JSON serializer = and cheerfully send off whatever comes out. I read specs and build clients = and servers and, when things break, it=92s because I=92m stupidly using a b= ogus name or value in some field, not because of the serialization.

I suggest that there is not a problem here that needs the investment of= precious IETF time.

=A0-T
--f46d042fd918c758ab04d62b44b9-- From paul.hoffman@vpnc.org Wed Feb 20 09:38:22 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693D321F8780 for ; Wed, 20 Feb 2013 09:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1fN0nK97twy for ; Wed, 20 Feb 2013 09:38:21 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 134EE21F87BA for ; Wed, 20 Feb 2013 09:38:21 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1KHcKH7089998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 20 Feb 2013 10:38:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Wed, 20 Feb 2013 09:38:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> References: To: "json@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:38:22 -0000 On Feb 20, 2013, at 9:27 AM, Tim Bray wrote: > My proposal is: do nothing. >=20 > I use JSON for protocol design and work all the time, and have not = observed any interop problems in the wild which originate at the JSON = parson or construction level. I give the incoming text to the library = and it Just Works or reliably reports a syntax botch. I give my data = structures to the JSON serializer and cheerfully send off whatever comes = out. I read specs and build clients and servers and, when things break, = it=92s because I=92m stupidly using a bogus name or value in some field, = not because of the serialization. >=20 > I suggest that there is not a problem here that needs the investment = of precious IETF time. -1. There are places where RFC 4627 has SHOULDs where some processors do one = thing and others do something different. That should be cleaned up in a = standards-track RFC, and it should be done with lots of JSON developers = and users having a discussion that comes to rough consensus. The other stuff mentioned so far will probably happen as experimental = RFCs even if there is no WG; a WG might help prevent those from being = silly, but doing so might take a lot of effort (more than the value). --Paul Hoffman= From gsalguei@cisco.com Wed Feb 20 09:41:10 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E0121F8886 for ; Wed, 20 Feb 2013 09:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.511 X-Spam-Level: X-Spam-Status: No, score=-10.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTJDfb3s7G4W for ; Wed, 20 Feb 2013 09:41:09 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 265E621F8887 for ; Wed, 20 Feb 2013 09:41:09 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1KHf7UJ028824 for ; Wed, 20 Feb 2013 12:41:07 -0500 (EST) Received: from rtp-gsalguei-8917.cisco.com (rtp-gsalguei-8917.cisco.com [10.116.132.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1KHf6JS023013 for ; Wed, 20 Feb 2013 12:41:07 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Gonzalo Salgueiro In-Reply-To: <5124FB74.9050207@att.com> Date: Wed, 20 Feb 2013 12:41:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <91DB94DC-1D3F-406E-B644-233CEB0B09A1@cisco.com> References: <734F6B55-2AA7-44A6-A636-7221C8518479@vpnc.org> <5124FB74.9050207@att.com> To: "json@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [Json] Proposed document set from this WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:41:10 -0000 +1 I can get behind this. --G On Feb 20, 2013, at 11:36 AM, Tony Hansen wrote: > On 2/20/2013 11:20 AM, Paul Hoffman wrote: >> On Feb 19, 2013, at 10:47 PM, R S wrote: >>> My suggestion is for the WG to target this use case only, and to = treat >>> the JSON processing rules in ECMAScript 5, Section 15.12 (The JSON >>> Object) as the baseline for rules regarding encoding and decoding, >>> rather than RFC4627. >> It feels weird to be agreeing with Rob so early in the discusson, but = I agree on both parts. >>=20 >> - Charter 4627bis *and nothing else*, so that the 4627bis work is = done without distraction. It is really clear that canonicalization and = schema/description have the *high* potential for distraction. >> - Say that the base for that one charter item is RFC 4627 *and* = ECMAScript 5, which seems to be widely-deployed. >> - Say that the WG is likely to recharter while 4627bis is under = review by the IESG to discuss schema/description. >> - Given the recent consensus, don't mention canonicalization in the = charter at all unless another WG or SDO has specifically asked us to = work on it. >=20 > +1 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 From mamille2@cisco.com Wed Feb 20 09:43:23 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502E821F869E for ; Wed, 20 Feb 2013 09:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJWy0ycqaYue for ; Wed, 20 Feb 2013 09:43:21 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 989FB21F8686 for ; Wed, 20 Feb 2013 09:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1568; q=dns/txt; s=iport; t=1361382200; x=1362591800; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6iTDYIUx+FW7zTeqzT4DESjjFpgju4Hi8ZteRpv1utc=; b=M6dmmfPWBS13T2QymSdGbIqqFCEapJja3x+Spl6AJP9hC4aAjUxy8G3H FGgEB46XRdVOSpVR1sDpK574XREaiv1Ywv5zIbBA+msps5SPHMRl8sCPq Zyn6xOP+MTWwzw1cNXnq2Vmf88K83GPdAP9ysiLGs4Agl9eeeZn8+3EKP w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPEJJVGtJXG+/2dsb2JhbABFwFyBAhZzgh8BAQEDAX4LAgEIGAokMiUCBBMIiAQGwFyOWwI4gl9hA6cHgweCJw X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; d="scan'208";a="179261350" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 20 Feb 2013 17:43:20 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1KHhK23017067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 20 Feb 2013 17:43:20 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 11:43:19 -0600 From: "Matt Miller (mamille2)" To: "json@ietf.org" Thread-Topic: [Json] Counterproposal on work items Thread-Index: AQHOD4+Hfs91qE+RakqjfTLbwh+3+ZiDZ5qAgAABZoA= Date: Wed, 20 Feb 2013 17:43:19 +0000 Message-ID: References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> In-Reply-To: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.55] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0FC6A4EF070470439131145B2BFD8DBD@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:43:23 -0000 On Feb 20, 2013, at 10:38 AM, Paul Hoffman wrote: > On Feb 20, 2013, at 9:27 AM, Tim Bray wrote: >=20 >> My proposal is: do nothing. >>=20 >> I use JSON for protocol design and work all the time, and have not obser= ved any interop problems in the wild which originate at the JSON parson or = construction level. I give the incoming text to the library and it Just Wo= rks or reliably reports a syntax botch. I give my data structures to the J= SON serializer and cheerfully send off whatever comes out. I read specs and= build clients and servers and, when things break, it=92s because I=92m stu= pidly using a bogus name or value in some field, not because of the seriali= zation. >>=20 >> I suggest that there is not a problem here that needs the investment of = precious IETF time. >=20 > -1. >=20 > There are places where RFC 4627 has SHOULDs where some processors do one = thing and others do something different. That should be cleaned up in a sta= ndards-track RFC, and it should be done with lots of JSON developers and us= ers having a discussion that comes to rough consensus. Just to reinforce Paul's point; while things seem to more-or-less work out,= there are serious questions occasionally asked about the appropriateness o= f JSON for use in security protocols given those differences. It might see= m like re-arranging the deck chairs, but that arrangement can be important = for acceptance. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. From gsalguei@cisco.com Wed Feb 20 09:43:24 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4651821F8686 for ; Wed, 20 Feb 2013 09:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.515 X-Spam-Level: X-Spam-Status: No, score=-10.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkqsG5+FtC2g for ; Wed, 20 Feb 2013 09:43:23 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 7390E21F863F for ; Wed, 20 Feb 2013 09:43:22 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1KHhLxR029095 for ; Wed, 20 Feb 2013 12:43:21 -0500 (EST) Received: from rtp-gsalguei-8917.cisco.com (rtp-gsalguei-8917.cisco.com [10.116.132.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1KHhLXw026860; Wed, 20 Feb 2013 12:43:21 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Gonzalo Salgueiro In-Reply-To: Date: Wed, 20 Feb 2013 12:43:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4C9AB1F8-647E-4352-9827-FB9DA4F828FC@cisco.com> References: To: Tim Bray X-Mailer: Apple Mail (2.1499) Cc: json@ietf.org Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:43:24 -0000 I don't hink doing anything is the proper course. At *minimum* clean up = of 4627 and moving it to Standards-Track is needed IMO. --G On Feb 20, 2013, at 12:27 PM, Tim Bray wrote: > My proposal is: do nothing. >=20 > I use JSON for protocol design and work all the time, and have not = observed any interop problems in the wild which originate at the JSON = parson or construction level. I give the incoming text to the library = and it Just Works or reliably reports a syntax botch. I give my data = structures to the JSON serializer and cheerfully send off whatever comes = out. I read specs and build clients and servers and, when things break, = it=92s because I=92m stupidly using a bogus name or value in some field, = not because of the serialization. >=20 > I suggest that there is not a problem here that needs the investment = of precious IETF time. >=20 > -T > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From tbray@textuality.com Wed Feb 20 10:01:49 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331CB21F871C for ; Wed, 20 Feb 2013 10:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.616 X-Spam-Level: X-Spam-Status: No, score=-3.616 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8cHK9dOJ7z2 for ; Wed, 20 Feb 2013 10:01:48 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2875721F8473 for ; Wed, 20 Feb 2013 10:01:42 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id hz1so4176896pad.24 for ; Wed, 20 Feb 2013 10:01:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=rPYhWeLcmSmffmTp9BPdWyQIc+9wSrnOgYfSQLicoLk=; b=S98liNxRP5DMaOZIDHVEPgTWO4a0VqtU7RGVXAW13ucZvp0Tpc7sWCS9tPscP07NwB ZlRDGvRYac1X03R2T4wKueznkjV7Y9JnILo6uIwVdI9ewJfMi+aUVmqNq5ndLTyqjuVM /WO7QFGcVEkUPC7iBwbE64y/BinAZ93p3r3sU4R4TMDgH6xGiZ/K37jrFKzaJu3gCxYg vQKOHnQFq2YddbL6EiCFOBTFjPBPAOrEhjG0TL/vDMZfcsUP9SQxWMvop/WctudS9+3T 1Obv6YBW3RG32jSr+YtgEkjHBesfF9sO3RKcdAcyWgMyi5e2vf4jOnq6HSvpnQoTsUNj wOVw== MIME-Version: 1.0 X-Received: by 10.66.86.201 with SMTP id r9mr55172392paz.14.1361383301810; Wed, 20 Feb 2013 10:01:41 -0800 (PST) Received: by 10.66.249.129 with HTTP; Wed, 20 Feb 2013 10:01:41 -0800 (PST) X-Originating-IP: [96.49.81.176] Date: Wed, 20 Feb 2013 10:01:41 -0800 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=f46d042fd9181b89d204d62bc095 X-Gm-Message-State: ALoCoQlIq+29yaOfxYz/MgVz4/h8wNTS5NuDcCLN5fvFDg5sWDOebmUStuIISEdb0GZdLwtT9hh/ Subject: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:01:49 -0000 --f46d042fd9181b89d204d62bc095 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable JSON is finished and well-defined, and we have an immense amount of running code in place as testimony. Perhaps, though it would be worthwhile to do an analogue of RFC3470 aka BCP70, =93Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols=94, for JSON. Rather than niggle about things that aren=92t really actually problems, sin= ce JSON is observed to pretty well Just Work, actually add some value by giving good advice on how to get good mileage in the IETF-protocol context. For example: - always use UTF-8 - always include a charset parameter on the Media type anyhow - always make the top-level construct an object - never have duplicate keys in an object - bear in mind that if you include U+0000 in a string value, you are making life difficult for implementors in certain popular languages ... I=92m sure the fertile minds here could add to the list. -T --f46d042fd9181b89d204d62bc095 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
JSON is finished and well-de= fined, and we have an immense amount of running code in place as testimony.= =A0 Perhaps, though it would be worthwhile to do an analogue of RFC3470 aka= BCP70, =93Guidelines for the Use of Extensible Markup Language (XML) withi= n IETF Protocols=94, for JSON.

Rather than niggle about things that aren=92t really actually pro= blems, since JSON is observed to pretty well Just Work, actually add some v= alue by giving good advice on how to get good mileage in the IETF-protocol = context. For example:

- always use UTF-8
- always include a charset parameter = on the Media type anyhow
- always make the top-level construct an = object
- never have duplicate keys in an object
- bear in mind that if you include U+0000 in a string value, you are making= life difficult for implementors in certain popular languages

... I=92m sure the fertile minds here could add to the list.

=A0-T
--f46d042fd9181b89d204d62bc095-- From Michael.Jones@microsoft.com Wed Feb 20 10:04:35 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF9021F88CF for ; Wed, 20 Feb 2013 10:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+fwPS-MfxDH for ; Wed, 20 Feb 2013 10:04:35 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4E821F88A0 for ; Wed, 20 Feb 2013 10:04:34 -0800 (PST) Received: from BY2FFO11FD007.protection.gbl (10.1.15.202) by BY2FFO11HUB028.protection.gbl (10.1.14.139) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 20 Feb 2013 18:04:31 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD007.mail.protection.outlook.com (10.1.14.128) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 20 Feb 2013 18:04:31 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Wed, 20 Feb 2013 18:03:58 +0000 From: Mike Jones To: "Matt Miller (mamille2)" , "json@ietf.org" Thread-Topic: [Json] Counterproposal on work items Thread-Index: AQHOD4+SPseM1SMZE0mkChl5mvoWOpiDAwWAgAABZYCAAASqUA== Date: Wed, 20 Feb 2013 18:03:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436747B21A@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(24454001)(13464002)(377454001)(51704002)(31966008)(5343655001)(54356001)(51856001)(23726001)(16406001)(79102001)(77982001)(56816002)(66066001)(59766001)(80022001)(5343635001)(33656001)(47976001)(561944001)(50986001)(49866001)(47736001)(65816001)(55846006)(50466001)(46406002)(20776003)(74662001)(53806001)(4396001)(46102001)(44976002)(54316002)(74502001)(47776003)(76482001)(56776001)(47446002)(63696002)(15202345001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB028; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07630F72AD Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:04:35 -0000 The "SHOULD" versus "MUST" caused the JOSE specs to have to include this la= nguage in http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#= section-4: The Header Parameter Names within this object MUST be unique; JWSs with duplicate Header Parameter Names MUST be rejected. Whereas, if we were referencing a RFC4627bis with the MUST, this language c= ould be softened to be a caution about older JSON parsers, and probably mov= ed to the Security Considerations section. -- Mike -----Original Message----- From: json-bounces@ietf.org [mailto:json-bounces@ietf.org] On Behalf Of Mat= t Miller (mamille2) Sent: Wednesday, February 20, 2013 9:43 AM To: json@ietf.org Subject: Re: [Json] Counterproposal on work items On Feb 20, 2013, at 10:38 AM, Paul Hoffman wrote: > On Feb 20, 2013, at 9:27 AM, Tim Bray wrote: >=20 >> My proposal is: do nothing. >>=20 >> I use JSON for protocol design and work all the time, and have not obser= ved any interop problems in the wild which originate at the JSON parson or = construction level. I give the incoming text to the library and it Just Wo= rks or reliably reports a syntax botch. I give my data structures to the J= SON serializer and cheerfully send off whatever comes out. I read specs and= build clients and servers and, when things break, it's because I'm stupidl= y using a bogus name or value in some field, not because of the serializati= on. >>=20 >> I suggest that there is not a problem here that needs the investment of = precious IETF time. >=20 > -1. >=20 > There are places where RFC 4627 has SHOULDs where some processors do one = thing and others do something different. That should be cleaned up in a sta= ndards-track RFC, and it should be done with lots of JSON developers and us= ers having a discussion that comes to rough consensus. Just to reinforce Paul's point; while things seem to more-or-less work out,= there are serious questions occasionally asked about the appropriateness o= f JSON for use in security protocols given those differences. It might see= m like re-arranging the deck chairs, but that arrangement can be important = for acceptance. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json From tsaloranta@gmail.com Wed Feb 20 10:22:38 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C985821F8881 for ; Wed, 20 Feb 2013 10:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1VUZdr+rkjU for ; Wed, 20 Feb 2013 10:22:34 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4666421F87E1 for ; Wed, 20 Feb 2013 10:22:31 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id r6so6888045wey.19 for ; Wed, 20 Feb 2013 10:22:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=sE5pLa5l8UNLd13o1ZAksCBsnW4GMjhHG/RG5yK8Bww=; b=E4ZZld68iy9q31cToaHWbfqBZJLC7VUBl6Yz+UdbVwl880iJQbOR0uWDQYcDedX1QG vA/sAWFmqzM6SJxk3ve2cHmZn+rvS7dFc+TxRbKFy51rbsH6/4eiDPXffNmz+wzVO72n i5JLoAbFmxEn4Yeg/s3NyBhlyffI/Gl/wqqO3dmxwgJ1DXGwx7MBXHq7bn8okr/rx+WR YaBB8UrKZjRN3u5kS4OIkc3Kef+ebBx8AOwq6WW5GA4L6A+wjWIKdxP4cpsjWdAd43Ys sONLZ97Zx3jeggEQLJofKgcSg+zu77o1zwZf5mLjbmUxinEp7trk3czMaWr60mWtHy6L 0qsA== MIME-Version: 1.0 X-Received: by 10.180.89.101 with SMTP id bn5mr36195104wib.14.1361384550226; Wed, 20 Feb 2013 10:22:30 -0800 (PST) Received: by 10.227.63.132 with HTTP; Wed, 20 Feb 2013 10:22:30 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 10:22:30 -0800 Message-ID: From: Tatu Saloranta To: Tim Bray Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "json@ietf.org" Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:22:38 -0000 +1 -+ Tatu +- On Wed, Feb 20, 2013 at 9:27 AM, Tim Bray wrote: > My proposal is: do nothing. > > I use JSON for protocol design and work all the time, and have not observ= ed > any interop problems in the wild which originate at the JSON parson or > construction level. I give the incoming text to the library and it Just > Works or reliably reports a syntax botch. I give my data structures to t= he > JSON serializer and cheerfully send off whatever comes out. I read specs = and > build clients and servers and, when things break, it=92s because I=92m st= upidly > using a bogus name or value in some field, not because of the serializati= on. > > I suggest that there is not a problem here that needs the investment of > precious IETF time. > > -T > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From sayrer@gmail.com Wed Feb 20 10:27:51 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9E021F8904 for ; Wed, 20 Feb 2013 10:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzYqdNQcAbiC for ; Wed, 20 Feb 2013 10:27:50 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1462221F88F1 for ; Wed, 20 Feb 2013 10:27:49 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr12so6546266wgb.23 for ; Wed, 20 Feb 2013 10:27:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qB/0TMVIKQxwrTt4iI2CRhW235jyByRh7pV4hQRkO6k=; b=e3CfPgXWjBwGDoC2VEwZSg2fehhR38nfhDfxXlRYBvOmwE04d8fcFg5vkQ3BpF/vMx sfFt6ICUi87Q8LE4hJ2L/st/7rHHSPMx7Wb0EJZBtSijiM/MRwBffevFcZEQUlqH2Gl2 aIKBuoVuWiW7RYW6ufANtVYJr2fyx1oAW+7h29tibOVWU75GCqZ8Z0xkco2yA9cwwj6z KF1EG88Z+gTHY/JBww4RwNhyS5bIjE4CgmgXZXu6GMSQahkobQIsUfCTk3xVDoNi5xlZ B1cK9BS3CtniJuVt1V0mBjP3ppKWl9nqMav09vIRv5NwY7fHoM6wcvuR9O/jOLa0EOG9 5HDQ== MIME-Version: 1.0 X-Received: by 10.180.91.106 with SMTP id cd10mr17610581wib.6.1361384862454; Wed, 20 Feb 2013 10:27:42 -0800 (PST) Received: by 10.194.138.170 with HTTP; Wed, 20 Feb 2013 10:27:42 -0800 (PST) In-Reply-To: References: <734F6B55-2AA7-44A6-A636-7221C8518479@vpnc.org> Date: Wed, 20 Feb 2013 10:27:42 -0800 Message-ID: From: Robert Sayre To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=ISO-8859-1 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed document set from this WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:27:51 -0000 On Wed, Feb 20, 2013 at 8:51 AM, Joe Hildebrand (jhildebr) wrote: > > 15.12.1.2: JSONText can be any value, not just object or array. I think > this would be a positive change for 4627bis, perhaps with a note that > older processors are likely to reject any top level that is not an object > or array. Ah, yes. I had forgotten about that large change. I think most JSON implementations support it at this point. - Rob From nico@cryptonector.com Wed Feb 20 10:44:25 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCBF21F8722 for ; Wed, 20 Feb 2013 10:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=-1.457, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 544z-bSrgtP3 for ; Wed, 20 Feb 2013 10:44:25 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1268721F8716 for ; Wed, 20 Feb 2013 10:44:25 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id ABE2F6B008B for ; Wed, 20 Feb 2013 10:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=yT2OhBhPqtfKMY2zBiyvfGVsYws=; b=RUCBGa5Ue0n o7SlUAscrWHJUpnTdbPtDPO1/KCClV7dokY11lwi8C3oqh4IpIc55AfuJzPZt2tV vfOMpHBuAk3n1QSIxVGnNYAGK81CgwIFiKQ/e3ZiiR2mXXp69IYBwu2KJ/kGIeeS bTX7b9/d8YBe0ll92LGBJbw55EoR4oqs= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 7FF346B00A1 for ; Wed, 20 Feb 2013 10:43:27 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x10so7050761wey.3 for ; Wed, 20 Feb 2013 10:43:26 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.87.98 with SMTP id w2mr34778397wiz.30.1361385806311; Wed, 20 Feb 2013 10:43:26 -0800 (PST) Received: by 10.216.148.193 with HTTP; Wed, 20 Feb 2013 10:43:25 -0800 (PST) In-Reply-To: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> Date: Wed, 20 Feb 2013 12:43:25 -0600 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "json@ietf.org" Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:44:26 -0000 On Wed, Feb 20, 2013 at 11:38 AM, Paul Hoffman wrot= e: > On Feb 20, 2013, at 9:27 AM, Tim Bray wrote: >> My proposal is: do nothing. > > -1. > > There are places where RFC 4627 has SHOULDs where some processors do one = thing and others do something different. That should be cleaned up in a sta= ndards-track RFC, and it should be done with lots of JSON developers and us= ers having a discussion that comes to rough consensus. One I-D as simple as this hardly justifies a WG. From tony@att.com Wed Feb 20 10:56:16 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E41C21F8984 for ; Wed, 20 Feb 2013 10:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.976 X-Spam-Level: X-Spam-Status: No, score=-106.976 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZszgh2P6VyV for ; Wed, 20 Feb 2013 10:56:15 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id D5D5D21F88EF for ; Wed, 20 Feb 2013 10:56:14 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id e4c15215.0.271508.00-280.765767.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 20 Feb 2013 18:56:14 +0000 (UTC) X-MXL-Hash: 51251c4e29fb3591-a04795860cacfdf5539b7d004e6ee333e52dcf0b Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1KIuD0L003519 for ; Wed, 20 Feb 2013 10:56:14 -0800 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1KIu8YR003395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Feb 2013 10:56:10 -0800 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint03.pst.cso.att.com (RSA Interceptor) for ; Wed, 20 Feb 2013 10:55:50 -0800 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id r1KItndS001993 for ; Wed, 20 Feb 2013 13:55:49 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id r1KIteQb000801 for ; Wed, 20 Feb 2013 13:55:41 -0500 Received: from [135.70.29.22] (vpn-135-70-29-22.vpn.west.att.com[135.70.29.22]) by maillennium.att.com (mailgw1) with ESMTP id <20130220185432gw100632n1e> (Authid: tony); Wed, 20 Feb 2013 18:54:32 +0000 X-Originating-IP: [135.70.29.22] Message-ID: <51251C2A.4030501@att.com> Date: Wed, 20 Feb 2013 13:55:38 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "json@ietf.org" References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=IcMwrxWa c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=5AE5csG8RS0A:10 a=djqtFF5C5r8A:10 a=lVdhOp8B8YAA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=Vq4NU9Hifv4A:10 a=m9rGlshOAAAA:8 a=lhK04cLjTUmVy] X-AnalysisOut: [T7BXCAA:9 a=wPNLvfGTeEIA:10 a=3tVY_Mm33XkA:10] Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:56:16 -0000 On 2/20/2013 1:43 PM, Nico Williams wrote: > On Wed, Feb 20, 2013 at 11:38 AM, Paul Hoffman wrote: >> There are places where RFC 4627 has SHOULDs where some processors do one thing and others do something different. That should be cleaned up in a standards-track RFC, and it should be done with lots of JSON developers and users having a discussion that comes to rough consensus. > One I-D as simple as this hardly justifies a WG. Countercase in point: the imapmove working group. It had one document, was chartered in 7/2012, and lived for a total of 6 months until it successfully shut down in 1/2013. Tony Hansen From paul.hoffman@vpnc.org Wed Feb 20 11:02:16 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9661F0D0A for ; Wed, 20 Feb 2013 11:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoVOy5G6lE5S for ; Wed, 20 Feb 2013 11:02:15 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D48721F0C4E for ; Wed, 20 Feb 2013 11:02:15 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1KJ2E7r093225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 20 Feb 2013 12:02:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Wed, 20 Feb 2013 11:02:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> To: "json@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:02:16 -0000 On Feb 20, 2013, at 10:43 AM, Nico Williams = wrote: > On Wed, Feb 20, 2013 at 11:38 AM, Paul Hoffman = wrote: >> On Feb 20, 2013, at 9:27 AM, Tim Bray wrote: >>> My proposal is: do nothing. >>=20 >> -1. >>=20 >> There are places where RFC 4627 has SHOULDs where some processors do = one thing and others do something different. That should be cleaned up = in a standards-track RFC, and it should be done with lots of JSON = developers and users having a discussion that comes to rough consensus. >=20 > One I-D as simple as this hardly justifies a WG. Getting broad consensus on changing a standard that is implemented = widely outside the IETF justifies the effort to have the time and space = for consensus. This is *not* just IETF work. --Paul Hoffman From fgaliegue@gmail.com Wed Feb 20 11:41:40 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEE821F875A for ; Wed, 20 Feb 2013 11:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t86iaOSoCMn7 for ; Wed, 20 Feb 2013 11:41:39 -0800 (PST) Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by ietfa.amsl.com (Postfix) with ESMTP id 5129521F8716 for ; Wed, 20 Feb 2013 11:41:39 -0800 (PST) Received: by mail-ea0-f169.google.com with SMTP id d13so3704382eaa.28 for ; Wed, 20 Feb 2013 11:41:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nVZ6DVERuJnufedJvEt11kP+kMUBhXDUDKKnvGBsWh0=; b=EmlnaBYq9YqdaEgz+gwMLePnOuiVraQEkGx+lz1d9YIuOz3vswbIJimpiLkFnTSimm vLDyikJsnVWH78/9OpGlDPJRjNUCDNsfh61dmqm24Wuk9UQZAEwDgDg5AUddM/ZQoZ8t iaxqt+7Cv1j1ayfloNYR4mi2GF3P4K2jkT0LYsUrH7uWLrOQz6vZvXeGelxVM/pr+La8 FDiFIvZ/5dU137zOvjmDYArv3Mivwe/xuH2UY+sNiooMkbNpeRxlY2vYegJUDAewfOlp Bg1dqeGR19BN1ep0v+gHdAUdPFClPHhwKkSeifzovS/7/t1dLBPlg7Y2rlCniM3zCLYo OEgQ== MIME-Version: 1.0 X-Received: by 10.14.183.67 with SMTP id p43mr71953287eem.10.1361389298380; Wed, 20 Feb 2013 11:41:38 -0800 (PST) Received: by 10.14.1.7 with HTTP; Wed, 20 Feb 2013 11:41:38 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 20:41:38 +0100 Message-ID: From: Francis Galiegue To: Tim Bray Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:41:40 -0000 On Wed, Feb 20, 2013 at 7:01 PM, Tim Bray wrote: [...] > - always make the top-level construct an object Why? I have the totally opposite view -- right now only arrays and objects are dubbed as legal JSON texts. And I have never seen a parser raise an error if it were fed with anything else -- nor fail to produce anything else, for that matter. Restricting the top level construct to objects and arrays is "bad" enough, but restricting it even more? I think the _opposite_ should be done. JSON is flexible, restricting its flexibility would be a mistake imho. -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From tbray@textuality.com Wed Feb 20 12:14:39 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C52E21F88CC for ; Wed, 20 Feb 2013 12:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBvShvw1F3jI for ; Wed, 20 Feb 2013 12:14:38 -0800 (PST) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4267D21F88C7 for ; Wed, 20 Feb 2013 12:14:38 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id fb11so4289097pad.28 for ; Wed, 20 Feb 2013 12:14:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=PUasyfjWy27eQDM3Mei9MgILKQZ7T/fq8fhReB0Z7/M=; b=mEt2BFJoVIU0arWflcPYYvLkU63QDP4MUwOnWTVufJyZ7/D0VTFJTJxOpBZ0gcnrsB lufXtlIqzGEk+PUYHh0/K+UwFphBNBmJmUW+/VAsuzQdtoJbiscNpQHvAE4Lm2wIuDL4 SwNzQI5/ybSm7YUFpOX8aB/ExTVFAfmeBrerw75UieeJCOtZnh3ozX2YS3SgtaMCRDak Cb2mN7IdT+Zmxz/tnTqRcjPs3eYlzbW1ovUY/srjp1TV9ChZJZqcT8gXBQ7Hov2Vme0s 5EkRy0TR00KI199CE9tpYBM2W1eyYtsnCHQofwphgiA5kUsINEL5q2DZCC//pY3slooY b0rw== MIME-Version: 1.0 X-Received: by 10.66.4.193 with SMTP id m1mr4264222pam.214.1361391278031; Wed, 20 Feb 2013 12:14:38 -0800 (PST) Received: by 10.66.249.129 with HTTP; Wed, 20 Feb 2013 12:14:37 -0800 (PST) X-Originating-IP: [96.49.81.176] In-Reply-To: References: Date: Wed, 20 Feb 2013 12:14:37 -0800 Message-ID: From: Tim Bray To: Francis Galiegue Content-Type: multipart/alternative; boundary=bcaec520e7df87060a04d62d9b50 X-Gm-Message-State: ALoCoQnGv1SeyvQEpQ8UU/wH2QB2/9WgnZ+xWep665tNQ9pFU+iJsW/DJj8zwXUQe56DXW3AOn6h Cc: "json@ietf.org" Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:14:39 -0000 --bcaec520e7df87060a04d62d9b50 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I=92m actually pretty sure about that one, for use in protocols. If in som= e protocol I'm going to send you 3 data items called =93size=94, =93date=94, = and =93uid=94, if I put them in a hash, then when for a later version we need t= o add =93ttl=94, assuming a MUST-IGNORE policy, you can just do it. If you= =92ve put them in a tuple or some such, you have much less flexibility. -T On Wed, Feb 20, 2013 at 11:41 AM, Francis Galiegue wro= te: > On Wed, Feb 20, 2013 at 7:01 PM, Tim Bray wrote: > [...] > > - always make the top-level construct an object > > Why? > > I have the totally opposite view -- right now only arrays and objects > are dubbed as legal JSON texts. And I have never seen a parser raise > an error if it were fed with anything else -- nor fail to produce > anything else, for that matter. > > Restricting the top level construct to objects and arrays is "bad" > enough, but restricting it even more? I think the _opposite_ should be > done. JSON is flexible, restricting its flexibility would be a mistake > imho. > > -- > Francis Galiegue, fgaliegue@gmail.com > Try out your JSON Schemas: http://json-schema-validator.herokuapp.com > --bcaec520e7df87060a04d62d9b50 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I=92m actually pretty sure about that one, for use in prot= ocols.=A0 If in some protocol I'm going to send you 3 data items called= =93size=94, =93date=94, and =93uid=94, if I put them in a hash, then when = for a later version we need to add =93ttl=94, assuming a MUST-IGNORE policy= , you can just do it.=A0 If you=92ve put them in a tuple or some such, you = have much less flexibility.=A0 -T


On Wed,= Feb 20, 2013 at 11:41 AM, Francis Galiegue <fgaliegue@gmail.com&g= t; wrote:
On Wed, Feb 20, 2013 at 7:01 PM, Tim Bray &l= t;tbray@textuality.com> wrot= e:
[...]
> - always make the top-level construct an object

Why?

I have the totally opposite view -- right now only arrays and objects
are dubbed as legal JSON texts. And I have never seen a parser raise
an error if it were fed with anything else -- nor fail to produce
anything else, for that matter.

Restricting the top level construct to objects and arrays is "bad"= ;
enough, but restricting it even more? I think the _opposite_ should be
done. JSON is flexible, restricting its flexibility would be a mistake
imho.

--
Francis Galiegue, fgaliegue@gmail.co= m
Try out your JSON Schemas: http://json-schema-validator.herokuapp.com

--bcaec520e7df87060a04d62d9b50-- From jhildebr@cisco.com Wed Feb 20 12:17:35 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177F021E8044 for ; Wed, 20 Feb 2013 12:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fa45WPG-XlkB for ; Wed, 20 Feb 2013 12:17:34 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6571021E8042 for ; Wed, 20 Feb 2013 12:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1598; q=dns/txt; s=iport; t=1361391454; x=1362601054; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Rf+lb4ZAPJT2G/i2WbqDPjimlSoF7xLFiGy2nwgJ2wE=; b=kdx5oCG8xqkACoI/OWWv6QujnSEcSmW8O3QNbFSDZGHacBFb06azIHrv 2tOWJz4hwigLlb2nXK2YCzPBihisjGx0nUU7fNBbsiOSvucKJouzWySNK k110dBTN+Zjhx2tVMVvQER4WjuvzZvVaDcrHf66WGbBovasz97af+Wut2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFQuJVGtJXG//2dsb2JhbABFwF+BAhZzgh8BAQEEeRIBCA4KCkURJQIEAQ0FCId4Aw8MtmwNiVqMN4IkAjEHgl9hA4gwjCGNIYUVgweBayQY X-IronPort-AV: E=Sophos;i="4.84,703,1355097600"; d="scan'208";a="179349390" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 20 Feb 2013 20:17:33 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1KKHXL0013247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Feb 2013 20:17:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 14:17:33 -0600 From: "Joe Hildebrand (jhildebr)" To: Tim Bray , Francis Galiegue Thread-Topic: [Json] Counterproposal #2 on work items Thread-Index: AQHOD5RjTUz37iGayUSEf11jvGkoDJiDigUAgAAJN4D//4t2gA== Date: Wed, 20 Feb 2013 20:17:33 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:17:35 -0000 +1. Keep in mind this BCP wouldn't be defining what the legal syntax is, but would be helping protocol designers who use JSON make sane choices based on what we have seen work in practice. On 2/20/13 1:14 PM, "Tim Bray" wrote: >I=B9m actually pretty sure about that one, for use in protocols. If in >some protocol I'm going to send you 3 data items called =B3size=B2, =B3dat= e=B2, >and =B3uid=B2, if I put them in a hash, then when for a later version we n= eed >to add =B3ttl=B2, assuming a MUST-IGNORE > policy, you can just do it. If you=B9ve put them in a tuple or some such= , >you have much less flexibility. -T > > > >On Wed, Feb 20, 2013 at 11:41 AM, Francis Galiegue > wrote: > >On Wed, Feb 20, 2013 at 7:01 PM, Tim Bray wrote: >[...] >> - always make the top-level construct an object > > >Why? > >I have the totally opposite view -- right now only arrays and objects >are dubbed as legal JSON texts. And I have never seen a parser raise >an error if it were fed with anything else -- nor fail to produce >anything else, for that matter. > >Restricting the top level construct to objects and arrays is "bad" >enough, but restricting it even more? I think the _opposite_ should be >done. JSON is flexible, restricting its flexibility would be a mistake >imho. > >-- >Francis Galiegue, fgaliegue@gmail.com >Try out your JSON Schemas: >http://json-schema-validator.herokuapp.com > > > > > > > --=20 Joe Hildebrand From fgaliegue@gmail.com Wed Feb 20 12:19:06 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A51821F88CC for ; Wed, 20 Feb 2013 12:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5GOHgCzjwQz for ; Wed, 20 Feb 2013 12:19:03 -0800 (PST) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8085321F889C for ; Wed, 20 Feb 2013 12:19:03 -0800 (PST) Received: by mail-ee0-f51.google.com with SMTP id d17so4126905eek.24 for ; Wed, 20 Feb 2013 12:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=uIzDk48/7PqGF8yJ16h1uLxCFYZ68q5130jsvwBIaDA=; b=pGuEW52IvQDuXGjGVD/J3WPNH1JkFWFSUkMxftNaC0a2MDTqzz9cBT0o/be5yNC2vL KaNffdvMncWZw8d6tJPrIU3jnIIZfvEVqjJqheNyaHOqYQCvgMVWkrV2lHabMmjbnECA JrShmSgvNRtmJ11uR+ViZifSdCb6y5Kol7yOJnGsLTfZXyIBbbxQ69Pvqz/JpXJusq3X ZoxTblEwPSVvF3cVMHGbXxtDy8p+/uL/pXRFhiVDUmgGuydJHE9R9fmMN3C50FkN+Hcn WZgGLNiS/LldjOtpx5Wbsix3mNpxCUEgRZKXuBVzJT3aTtoBKqq+V6TFX9SKkvWZiw9B xp9g== MIME-Version: 1.0 X-Received: by 10.14.175.129 with SMTP id z1mr73092474eel.7.1361391542616; Wed, 20 Feb 2013 12:19:02 -0800 (PST) Received: by 10.14.1.7 with HTTP; Wed, 20 Feb 2013 12:19:02 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 21:19:02 +0100 Message-ID: From: Francis Galiegue To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "json@ietf.org" Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:19:06 -0000 On Wed, Feb 20, 2013 at 9:14 PM, Tim Bray wrote: > I=E2=80=99m actually pretty sure about that one, for use in protocols. I= f in some > protocol I'm going to send you 3 data items called =E2=80=9Csize=E2=80=9D= , =E2=80=9Cdate=E2=80=9D, and > =E2=80=9Cuid=E2=80=9D, if I put them in a hash, then when for a later ver= sion we need to add > =E2=80=9Cttl=E2=80=9D, assuming a MUST-IGNORE policy, you can just do it.= If you=E2=80=99ve put > them in a tuple or some such, you have much less flexibility. -T > And what about JSON-RPC which uses an _array_ of requests/responses for batch requests? While an object may be suitable for 95+% of protocols, this is not a reason for outlawing protocols which _do not_ use objects. And it costs nothing to enlarge what is possible. --=20 Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From jhildebr@cisco.com Wed Feb 20 12:24:15 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB1921F8816 for ; Wed, 20 Feb 2013 12:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qr+iADF6waSM for ; Wed, 20 Feb 2013 12:24:14 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BD49221F8806 for ; Wed, 20 Feb 2013 12:24:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=987; q=dns/txt; s=iport; t=1361391854; x=1362601454; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=tvmRfAWqePq6YRSZvwtBstIuoF/WC5LUnWslEzilanc=; b=gt2+p/obR32nY0732isiUM1a10AjjvVeHgPmCyHt508ffD6/fW08JoL9 ZpoOhl6ZAPLVfVsiTbO/wk5a0inqHL7gkzL1qvSu8qoUviG5U5QCg6yJp UBZbYylp2nFqGGHL/AdcNP1RGnKxiHt/0piBIKwJ8ktvkRDx3FfCENnpM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFACQwJVGtJV2Z/2dsb2JhbABFhgK6XYECFnOCHwEBAQQ6UQEIGAoUQiUCBAESCIgKwGKOXTiCX2EDpweDB4In X-IronPort-AV: E=Sophos;i="4.84,703,1355097600"; d="scan'208";a="179324979" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 20 Feb 2013 20:24:14 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1KKOE6R031287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Feb 2013 20:24:14 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 14:24:14 -0600 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman , "json@ietf.org" Thread-Topic: [Json] Counterproposal on work items Thread-Index: AQHOD4+Hzm3bIvMaPk2Qb7T7cknXbZiDZ5qAgAASMICAAAVCAP//oY4A Date: Wed, 20 Feb 2013 20:24:13 +0000 Message-ID: In-Reply-To: <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <99658955C522994284280832EB04919D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:24:15 -0000 On 2/20/13 12:02 PM, "Paul Hoffman" wrote: >On Feb 20, 2013, at 10:43 AM, Nico Williams wrote: > >>=20 >> One I-D as simple as this hardly justifies a WG. > >Getting broad consensus on changing a standard that is implemented widely >outside the IETF justifies the effort to have the time and space for >consensus. This is *not* just IETF work. (individual) That seems like a solid argument. (BoF chair) We should definitely spend some time on this question at the BoF. I think it's going to be the crux for whether we charter a working group or not. As such, the apparea wg chairs and AD's opinions are likely to be interesting from a management perspective. Do they want the overhead of a working group for something relatively small or not? In my talks with Pete and Barry, I've been given to believe that they would like to be able to charter and kill small working groups rapidly. --=20 Joe Hildebrand From jhildebr@cisco.com Wed Feb 20 12:28:41 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A35E21F863F for ; Wed, 20 Feb 2013 12:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUhR4ZNiyTQc for ; Wed, 20 Feb 2013 12:28:40 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A45AB21F8619 for ; Wed, 20 Feb 2013 12:28:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=724; q=dns/txt; s=iport; t=1361392120; x=1362601720; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=biLN6xCLJIK6ZvHjR9W8ScyIS5IhLZdY/tLarS5kdpM=; b=My62dcx6ZTdvZOVaROPOmj9CHQ6bkBNanY3f/mWtSgLx5eX6l5OdDFu0 upBSCOhRZuy/uPH9cvwEF3pyyeVh+d95qWeCjurKwzoLLls8zvnWqeUha /F9Lurk6CaHqP5FuNzWwCNJQu9ZVZofn5kiHAPbaDbGykkk6dK+jYoOlY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFAFAxJVGtJXHB/2dsb2JhbABFhgK6XYECFnOCIQEEOj8SAQgOFBQxESUCBAENBQiHeAMPtn4NiVqMN4ImMQeCX2EDlFGNIYUVgweCJw X-IronPort-AV: E=Sophos;i="4.84,703,1355097600"; d="scan'208";a="179299301" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 20 Feb 2013 20:28:40 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1KKSeOQ023592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Feb 2013 20:28:40 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 14:28:40 -0600 From: "Joe Hildebrand (jhildebr)" To: Francis Galiegue , Tim Bray Thread-Topic: [Json] Counterproposal #2 on work items Thread-Index: AQHOD5RjTUz37iGayUSEf11jvGkoDJiDigUAgAAJN4CAAAE8AP//jVSA Date: Wed, 20 Feb 2013 20:28:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <717A652A3DC816438C7D5B1DC5B90326@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:28:41 -0000 On 2/20/13 1:19 PM, "Francis Galiegue" wrote: >And what about JSON-RPC which uses an _array_ of requests/responses >for batch requests? > >While an object may be suitable for 95+% of protocols, this is not a >reason for outlawing protocols which _do not_ use objects. And it >costs nothing to enlarge what is possible. I would urge not focusing on specific issues for a potential BCP just yet. Let's focus first on the question: "Does it seem useful for us to work on this sort of problem?" Traditionally, we would want the charter to be pretty well-understood at the time of the BoF, and this sort of scope definition is our most important task this week. --=20 Joe Hildebrand From fgaliegue@gmail.com Wed Feb 20 12:39:38 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A563121F877B for ; Wed, 20 Feb 2013 12:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsCbbhiRzHvp for ; Wed, 20 Feb 2013 12:39:38 -0800 (PST) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id B021521F8754 for ; Wed, 20 Feb 2013 12:39:37 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id c41so4427692eek.41 for ; Wed, 20 Feb 2013 12:39:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ErlULa7EQEwcZz47yGrX9Pt/7jobYhv+/cvVYkYEPrk=; b=mkp5n8Timn/XPmm/8dbbJQlM85f/hV6TJso8QwkDI5pYW3AHE9hDnq6h2SPDGxh16V WgfhCjJFvJpxwxVsfrVF3sPkP0rrdPmVvQE2D0TIX1/2UNm60IKY00fLqISAxBVoVj5M ZCfBkRkfGhIGhq4A38CFN+A8wz0TKE7OjF71YlwDv3fhyMzRW8WFlKkAjG5mO1+T5AIX TXEX7p/pStnzL+JThfcvdAnvGKAN/ysQJT9f69kurd5lSe0dNGKT1TU6Pt+GsZd0UHFO 1EOOy1x9g9OjS3Ltj2UIk7W3dXJ4PXYWqYBaSZNJBdL2ktxphdTz9Uvwqi91VqjdTSQX Tl8w== MIME-Version: 1.0 X-Received: by 10.14.179.5 with SMTP id g5mr72848250eem.41.1361392776761; Wed, 20 Feb 2013 12:39:36 -0800 (PST) Received: by 10.14.1.7 with HTTP; Wed, 20 Feb 2013 12:39:36 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 21:39:36 +0100 Message-ID: From: Francis Galiegue To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:39:38 -0000 On Wed, Feb 20, 2013 at 9:28 PM, Joe Hildebrand (jhildebr) wrote: [...] > > I would urge not focusing on specific issues for a potential BCP just yet. > Let's focus first on the question: "Does it seem useful for us to work on > this sort of problem?" > > Traditionally, we would want the charter to be pretty well-understood at > the time of the BoF, and this sort of scope definition is our most > important task this week. > That makes sense and it does not seem that important of a question indeed. It is just that, at least to my eyes, allowing any JSON value over the wire looks like a no-brainer, but it seems that not everyone agrees ;) On the whole, I don't believe it is that important of an issue either. Duplicate keys in an object, on the other hand, are indeed an important subject -- again, at least to my eyes. -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From kewisch@gmail.com Wed Feb 20 13:20:28 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B2C21F86F8 for ; Wed, 20 Feb 2013 13:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUAjJbZU74tx for ; Wed, 20 Feb 2013 13:20:27 -0800 (PST) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id 202FA21F86F0 for ; Wed, 20 Feb 2013 13:20:26 -0800 (PST) Received: by mail-bk0-f42.google.com with SMTP id jk7so3792371bkc.15 for ; Wed, 20 Feb 2013 13:20:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=vzRF/FRoOqh3GjJ3trpOzl0uXdJ4Djsf/nPGbMzBd9Q=; b=IM4P2MJn0LVSqYDs5d39KIzwTTYWzrrRjazMIL/Q3Wl9qxCzhyQFf3qzFzawwyrAID P7OiR7uQlatwKCuRPS235haqqokGAouCKGqL3r3uFn3G00JzEr68y/eJFlBFRo8SJOTX Z59TH0hnpb41bR9CfZ7kXHPjceQ439xN9PchedPxSQ9IufLxsHs6rQTjO6k5DBjyABxQ d6u8jksNVUBYfgRe2G2y/l+Ga6ccRu2MNPFRDWk0dOZ/TVb1Bul3IOTW/YpByjsQUEPJ +/e2L7kw4/XzQ4r/npBnbQcZIiAqUOF2DOKDtWzHGcR6IV7YATrp2UBHOZjeqBtnjJN/ HNjw== X-Received: by 10.204.13.25 with SMTP id z25mr9161670bkz.114.1361395226023; Wed, 20 Feb 2013 13:20:26 -0800 (PST) Received: from oskar.fritz.box (e179192205.adsl.alicedsl.de. [85.179.192.205]) by mx.google.com with ESMTPS id fy17sm15112479bkc.6.2013.02.20.13.20.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 13:20:25 -0800 (PST) Message-ID: <51253E18.7090508@gmail.com> Date: Wed, 20 Feb 2013 22:20:24 +0100 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: json@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020309060206030000080108" Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 21:20:28 -0000 This is a multi-part message in MIME format. --------------020309060206030000080108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I second Francis' opinion. While it might be more common to have an object as a root, this is by no means a best common practice without explaination. I'd be ok with hilighting that there is greater flexibility in adding new key-value type data when using an object as the root, but there is more than one protocol type where an array as root makes more sense. Specifically, any protocol that uses sequential data or where potential keys can have duplicate names should probably have an array as a root. We went through just this question when designing draft-kewisch-et-al-icalendar-in-json. While iCalendar may seem like key-value type data, these keys can show up more than once so using an object as the root is the wrong thing to do. I know the question is first if its useful to work on a such problem, but since I might not be around to mention this when a BCP is being created I still wanted to mention it. Philipp --------------020309060206030000080108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I second Francis' opinion. While it might be more common to have an object as a root, this is by no means a best common practice without explaination. I'd be ok with hilighting that there is greater flexibility in adding new key-value type data when using an object as the root, but there is more than one protocol type where an array as root makes more sense. Specifically, any protocol that uses sequential data or where potential keys can have duplicate names should probably have an array as a root. We went through just this question when designing draft-kewisch-et-al-icalendar-in-json. While iCalendar may seem like key-value type data, these keys can show up more than once so using an object as the root is the wrong thing to do.

I know the question is first if its useful to work on a such problem, but since I might not be around to mention this when a BCP is being created I still wanted to mention it.

Philipp

--------------020309060206030000080108-- From mnot@mnot.net Wed Feb 20 14:31:04 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C1521E803A for ; Wed, 20 Feb 2013 14:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.396 X-Spam-Level: X-Spam-Status: No, score=-105.396 tagged_above=-999 required=5 tests=[AWL=-2.797, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCkEKhyxkq6E for ; Wed, 20 Feb 2013 14:31:04 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFCC21E8037 for ; Wed, 20 Feb 2013 14:31:04 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.197.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C94E8509B6; Wed, 20 Feb 2013 17:31:02 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> Date: Thu, 21 Feb 2013 09:30:58 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1499) Cc: "json@ietf.org" Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:31:04 -0000 On 21/02/2013, at 6:02 AM, Paul Hoffman wrote: > On Feb 20, 2013, at 10:43 AM, Nico Williams = wrote: >=20 >> On Wed, Feb 20, 2013 at 11:38 AM, Paul Hoffman = wrote: >>> On Feb 20, 2013, at 9:27 AM, Tim Bray wrote: >>>> My proposal is: do nothing. >>>=20 >>> -1. >>>=20 >>> There are places where RFC 4627 has SHOULDs where some processors do = one thing and others do something different. That should be cleaned up = in a standards-track RFC, and it should be done with lots of JSON = developers and users having a discussion that comes to rough consensus. >>=20 >> One I-D as simple as this hardly justifies a WG. >=20 > Getting broad consensus on changing a standard that is implemented = widely outside the IETF justifies the effort to have the time and space = for consensus. This is *not* just IETF work. I don't know. I think I'd be fine if we just asked Crockford (perhaps = helped by a willing editor) to do 4627bis and then have the AD sponsor = it on Standards Track. Cheers, -- Mark Nottingham http://www.mnot.net/ From tbray@textuality.com Wed Feb 20 14:34:30 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B147821F87DC for ; Wed, 20 Feb 2013 14:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyoXLy08AHTk for ; Wed, 20 Feb 2013 14:34:29 -0800 (PST) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 83E1521F87D4 for ; Wed, 20 Feb 2013 14:34:29 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id um15so3140882pbc.0 for ; Wed, 20 Feb 2013 14:34:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=2b6zEaPA/dHuAFvRe4fEKZqXTJp8dsUaSZSvvac98sc=; b=VKxN+xcPhvBxOyay3HSGbcQCXahpmdtRpYKNMKN9VN96abtD55t9TzdnHPECT91HZy tjifqpLnPgSlwPxHsou1MoaFTGab7EuKCwtwBLfnVoeflHf30+NxPtqUTqHnPKumEkj1 MgrM9GVPgtWf2W92VRGnm9zT+opYP7K+5k+fbPDjsrRPTPQvucYz3nk65iqHVbEikzOg wTw1dPiSVUlJiVV+IVcMyJgZuWt+fSVwZKpETmEB7gFcFkOcYTwjsDxk7WCSBvRpcafz NofnAfRajPs9GpQvxQsDdb+8S/1Z9Yz8cWKGRP6DcTznBh/MOutcsBl4jMBdvbdewh9U VFSw== MIME-Version: 1.0 X-Received: by 10.68.130.35 with SMTP id ob3mr5232476pbb.92.1361399665014; Wed, 20 Feb 2013 14:34:25 -0800 (PST) Received: by 10.66.249.129 with HTTP; Wed, 20 Feb 2013 14:34:24 -0800 (PST) X-Originating-IP: [96.49.81.176] In-Reply-To: <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> Date: Wed, 20 Feb 2013 14:34:24 -0800 Message-ID: From: Tim Bray To: Mark Nottingham Content-Type: multipart/alternative; boundary=047d7b10ceb36e35ff04d62f8f22 X-Gm-Message-State: ALoCoQm6E4TUFqFzoCFRjXBCz0MB6WczlYQF/u05GhdttkTCzP3qaO6tvdpowSwzBsjm9gs9Vi0G Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:34:30 -0000 --047d7b10ceb36e35ff04d62f8f22 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 (Not that I have any idea if he=92s interested) -T On Wed, Feb 20, 2013 at 2:30 PM, Mark Nottingham wrote: > On 21/02/2013, at 6:02 AM, Paul Hoffman wrote: > > > On Feb 20, 2013, at 10:43 AM, Nico Williams > wrote: > > > >> On Wed, Feb 20, 2013 at 11:38 AM, Paul Hoffman > wrote: > >>> On Feb 20, 2013, at 9:27 AM, Tim Bray wrote: > >>>> My proposal is: do nothing. > >>> > >>> -1. > >>> > >>> There are places where RFC 4627 has SHOULDs where some processors do > one thing and others do something different. That should be cleaned up in= a > standards-track RFC, and it should be done with lots of JSON developers a= nd > users having a discussion that comes to rough consensus. > >> > >> One I-D as simple as this hardly justifies a WG. > > > > Getting broad consensus on changing a standard that is implemented > widely outside the IETF justifies the effort to have the time and space f= or > consensus. This is *not* just IETF work. > > > I don't know. I think I'd be fine if we just asked Crockford (perhaps > helped by a willing editor) to do 4627bis and then have the AD sponsor it > on Standards Track. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b10ceb36e35ff04d62f8f22 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
+1 (Not that I have any idea if he=92s interested) -T
<= /div>


On Wed, = Feb 20, 2013 at 2:30 PM, Mark Nottingham <mnot@mnot.net> wrote:<= br>
On 21/02/2013, at 6:02 AM,= Paul Hoffman <paul.hoffman@vpn= c.org> wrote:

> On Feb 20, 2013, at 10:43 AM, Nico Williams <nico@cryptonector.com> wrote:
>
>> On Wed, Feb 20, 2013 at 11:38 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>>> On Feb 20, 2013, at 9:27 AM, Tim Bray <tbray@textuality.com> wrote:
>>>> My proposal is: do nothing.
>>>
>>> -1.
>>>
>>> There are places where RFC 4627 has SHOULDs where some process= ors do one thing and others do something different. That should be cleaned = up in a standards-track RFC, and it should be done with lots of JSON develo= pers and users having a discussion that comes to rough consensus.
>>
>> One I-D as simple as this hardly justifies a WG.
>
> Getting broad consensus on changing a standard that is implemented wid= ely outside the IETF justifies the effort to have the time and space for co= nsensus. This is *not* just IETF work.


I don't know. I think I'd be fine if we just asked Crockford = (perhaps helped by a willing editor) to do 4627bis and then have the AD spo= nsor it on Standards Track.

Cheers,

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



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

--047d7b10ceb36e35ff04d62f8f22-- From James.H.Manger@team.telstra.com Wed Feb 20 14:58:23 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A6E21E8037 for ; Wed, 20 Feb 2013 14:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQX10H3Yr0Fd for ; Wed, 20 Feb 2013 14:58:19 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id AA27C21F841C for ; Wed, 20 Feb 2013 14:58:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,705,1355058000"; d="scan'208";a="119257606" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 21 Feb 2013 09:58:11 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6992"; a="113310703" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbvi.tcif.telstra.com.au with ESMTP; 21 Feb 2013 09:58:11 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Thu, 21 Feb 2013 09:58:11 +1100 From: "Manger, James H" To: "json@ietf.org" Date: Thu, 21 Feb 2013 09:58:09 +1100 Thread-Topic: Canonicalization Thread-Index: AQHODuJJD2QYqWyDNUmeQU+v/KxthpiB3nLAgAF4HLA= Message-ID: <255B9BB34FB7D647A506DC292726F6E11507634C37@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "draft-staykov-hu-json-canonical-form@tools.ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:58:23 -0000 Q2Fub25pY2FsaXphdGlvbiAoYzE0bikgbWF5IGJlIGEgZGlydHkgd29yZCwgYW5kIGJhcnJlZCBm cm9tIHRoZSBjaGFydGVyLCBidXQgSSBob3BlIGl0IGlzbid0IHRvbyBpbmFwcHJvcHJpYXRlIHRv IHN0aWxsIGRpc2N1c3MgaXQgb24gdGhpcyBlbWFpbCBsaXN0Lg0KDQpUaGVyZSBpcyBhIGJldHRl ciBjMTRuIGZvcm1hdCBmb3IgbnVtYmVycyB0aGFuIEkgb3IgZHJhZnQtc3RheWtvdi1odS1qc29u LWNhbm9uaWNhbC1mb3JtIGhhdmUgc3VnZ2VzdGVkOiBpdCBpcyB0aGUgZm9ybWF0IHByb2R1Y2Vk IGJ5IEpTT04uc3RyaW5naWZ5LCBhcyBkZWZpbmVkIGluIEVDTUFTY3JpcHQgdjUuMSBbaHR0cDov L3d3dy5lY21hLWludGVybmF0aW9uYWwub3JnL2VjbWEtMjYyLzUuMS8jc2VjLTE1LjEyLjNdLiBF eGFtcGxlczogMCwgMSwgLTEwMDAsIDAuMDAwMDIzMzQsIDE1MDAwMDAsIDYuMDIyZSsyMywgOS4x ZS0yOC4NCg0KSW4gZmFjdCwgYzE0biBmb3IgSlNPTiBjYW4gKGFuZCBzaG91bGQpIGJlIHNpbXBs eSBkZWZpbmVkIGFzIHBlciBKU09OLnN0cmluZ2lmeSwgd2l0aCB0d28gZXh0cmEgY29uc3RyYWlu dHM6IG9iamVjdCBuYW1lL3ZhbHVlIHBhaXJzIGFyZSBzb3J0ZWQ7IGFuZCBcdXh4eHggZXNjYXBl cyB1c2UgbG93ZXJjYXNlIGhleCBkaWdpdHMgKGEtZikuIERvbmUuIERldmVsb3BlcnMgZXZlbiBo YXZlIGEgcmVhZGlseSBhdmFpbGFibGUgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9ucyBzaW1wbHkg YnkgdHlwaW5nIEpTT04uc3RyaW5naWZ5KC4uLikgaW50byB0aGUgSmF2YVNjcmlwdCBjb25zb2xl IG9mIHRoZWlyIGJyb3dzZXIuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBqc29uLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqc29u LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBNYW5nZXIsIEphbWVzIEgNCj4gU2Vu dDogV2VkbmVzZGF5LCAyMCBGZWJydWFyeSAyMDEzIDExOjU4IEFNDQo+IFRvOiBqc29uQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbSnNvbl0gQ2Fub25pY2FsaXphdGlvbg0KPiANCj4gV2Ugc2hv dWxkIGF2b2lkIHRoZSBuZWVkIHRvIGNhbm9uaWNhbGl6ZSBKU09OIHdoZW5ldmVyIHBvc3NpYmxl LCBidXQNCj4gdGhlcmUgYXJlIGVub3VnaCBlZmZvcnRzIHRvIGRlZmluZSBhIGNhbm9uaWNhbCBm b3JtIHRoYXQgaXQgd291bGQgYmUNCj4gd29ydGggc3RhbmRhcmRpemluZyBvbmUuDQo+IA0KPiBT dHJpbmdzOg0KPiBFc2NhcGluZyBpcyBtYW5kYXRvcnkgZm9yIGNvbnRyb2xzIGNoYXJzLCBkb3Vi bGUgcXVvdGUsIGFuZCBiYWNrc2xhc2gNCj4gKCV4MDAtMUYgLyAleDIyIC8gJXg1QykuDQo+IFRo ZSBzaW1wbGVzdCBzdHJpbmcgY2Fub25pY2FsaXphdGlvbiBydWxlIHdvdWxkIGJlIHRvIGVzY2Fw ZSB0aG9zZSAzNA0KPiBjaGFycyBhbmQgbm8gb3RoZXJzLiBBIHJ1bGUgdGhhdCBtaWdodCBiZSBz bGlnaHRseSBuaWNlciBmb3IgcGVvcGxlDQo+IChhbmQgaGVuY2Ugd29ydGggdGhlIGZldyBleHRy YSBsaW5lcyBvZiBjb2RlKSB3b3VsZCBiZSB0byBhbHdheXMgdXNlDQo+IHRoZSA3IFx4IGVzY2Fw ZXMgZm9yIHRob3NlIDcgY2hhcnMsIGFsd2F5cyB1c2UgXHV4eHh4IGZvciB0aGUgcmVzdCBvZg0K PiAleDAwLTFGLCBhbmQgbmV2ZXIgdXNlIGl0IGZvciBhbnkgb3RoZXIgY2hhcnMuIEkgd291bGQg YmUgdGVtcHRlZCB0bw0KPiBkcm9wIFwvIGZyb20gdGhlIGxpc3Qgb2Ygc2V2ZW4gKG9ubHkgaW4g dGhlIGNhbm9uaWNhbGl6YXRpb24gcnVsZXMpLA0KPiBiZWNhdXNlIC8gaXMgc28gY29tbW9uIGlu IFVSSXMgZXRjLg0KPiANCj4gT2JqZWN0czoNCj4gU29ydGluZyBzdHJpbmcgbmFtZXMgdG8gY2Fu b25pY2FsaXplIGFuIG9iamVjdCBuZWVkcyBhIGZldyBtb3JlIHdvcmRzLg0KPiBQcmVzdW1hYmx5 IHNvcnRpbmcgb2NjdXJzIG9uIHRoZSBsb2dpY2FsIHN0cmluZ3MsIG5vdCB0aGUgKGNhbm9uaWNh bGx5KQ0KPiBlbmNvZGVkIHZlcnNpb25zLiBTbyB7ImFcImIiOjEsImEjYiI6Mn0gaXMgaW4gY2Fu b25pY2FsIGZvcm0gKCIoVSsyMikgPA0KPiAjKFUrMjMpIDwgXChVKzVDKSkuDQo+IFByZXN1bWFi bHkgc29ydGluZyB1c2VzIFVuaWNvZGUgY29kZSBwb2ludHMsIG5vdCBVVEYtMTYgd29yZHMsIG9y IFVURi04DQo+IGJ5dGVzLiBTbyB7Ilx1RkZFMFx1RkZFMSI6MywiXHVEODM0XHVERDFFIjo0fSBp cyBpbiB0aGUgcmlnaHQgb3JkZXINCj4gKDB4RkZFMCA8IDB4MDFEMTFFKSwgdGhvdWdodCB0aGUg Y2Fub25pY2FsIGZvcm0gd291bGQgdXNlIFVURi04IG5vdA0KPiBcdXh4eHggZm9yIHRoZSAzIGNo YXJhY3RlcnMuDQo+IFtUaGUgMjEtYnl0ZSBjYW5vbmljYWwgZm9ybSB3b3VsZCBiZSAoaW4gaGV4 KToNCj4gN0IgMjIgRUZCRkEwIEVGQkZBMSAyMiAzQSAzMyAyQyAyMiBGMDlEODQ5RSAyMiAzQSAz NCA3RF0NCj4gDQo+IE51bWJlcnM6DQo+IDAsIDEsIDFlMywgMi4zMzRlLTUsIDEuNWU2IGFyZSB0 aGUgc29ydCBvZiBjYW5vbmljYWwgZm9ybSBudW1iZXJzDQo+IHNob3VsZCBoYXZlLiBJIGRvbuKA mXQgbGlrZSAwLjBFMCBmb3IgemVybyBhcyBwZXIgZHJhZnQtc3RheWtvdi1odS1qc29uLQ0KPiBj YW5vbmljYWwtZm9ybS0wMCAtLSBhIHBlcnNvbiB3b3VsZCBuZXZlciB3cml0ZSB0aGF0LiBUaGF0 IGRyYWZ0IGFsc28NCj4gYWxsb3dzIGFueSBudW1iZXIgb2YgdHJhaWxpbmcgMOKAmXMgKGVnIDEu MjAwMDAwZS0yKSwgd2hpY2ggaXMgYSBidWcuIEENCj4gY2Fub25pY2FsIGZvcm0gc2hvdWxkIGRy b3AgdGhlIGV4cG9uZW50IHdoZW4gaXQgaXMgemVybywgYW5kIGRyb3AgdGhlDQo+IGRlY2ltYWwg cG9pbnQgd2hlbiB0aGVyZSBpcyBub3RoaW5nIGFmdGVyIGl0Lg0KPiBBIHJlZ2V4IGZvciBudW1i ZXJzIGluIGNhbm9uaWNhbCBmb3JtOg0KPiANCj4gMHwtP1sxLTldKFwuWzAtOV0qWzEtOV0pPyhl LT9bMS05XVswLTldKik/DQo+IA0KPiANCj4gU28gZHJhZnQtc3RheWtvdi1odS1qc29uLWNhbm9u aWNhbC1mb3JtIG5lZWRzIGEgZmV3IGNoYW5nZXMgaW4gbXkgbWluZCwNCj4gYnV0IGlzIGFzIGdv b2QgYSBzdGFydGluZyBwb2ludCBhcyBhbnkuDQo+IA0KPiAtLQ0KPiBKYW1lcyBNYW5nZXINCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4ganNvbiBt YWlsaW5nIGxpc3QNCj4ganNvbkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2pzb24NCg== From fgaliegue@gmail.com Wed Feb 20 15:05:58 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91C921F86E7 for ; Wed, 20 Feb 2013 15:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy07Ma9bb1Ex for ; Wed, 20 Feb 2013 15:05:57 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7701B21E8030 for ; Wed, 20 Feb 2013 15:05:57 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id f13so3694024eaa.31 for ; Wed, 20 Feb 2013 15:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=hfKYQ1M7VkEjrWu75cIxjgJn1nJEAQ9Pk/wMu7r47vY=; b=I5BANjfW7+D9rmIhIBlnf5f1KnWOHyl/7wVHASbJZv7bBsIkEJ2ibVxJSWbSNsuJv7 QyaXiWmEd00f2ba7jkqWao4qM0hiqb/I81GM09h184BSPmpe/F1XKOIufKLkAb+jgzOr IDaXXFxcjh0tfeTxrirEFcG7Gk3nCaiZqC6VjvzEjwH6zrgYy0nEG08Zt7PqW3VWHki+ +WORAAYNmNfbDgWYuBHm4nJnC2gtPnU32LFRRW8bjFkKyg6Lf/Ld6jm49qAYIShIA5nm P66PSIHHp5dc82DqPofaPlFhMvD0fCf/eN8x/2RlHOp2SatRyu0POiObyt+SVbZIjZpz iqTw== MIME-Version: 1.0 X-Received: by 10.14.175.129 with SMTP id z1mr74450848eel.7.1361401551332; Wed, 20 Feb 2013 15:05:51 -0800 (PST) Received: by 10.14.1.7 with HTTP; Wed, 20 Feb 2013 15:05:50 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11507634C37@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11507634C37@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 21 Feb 2013 00:05:50 +0100 Message-ID: From: Francis Galiegue To: "Manger, James H" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-staykov-hu-json-canonical-form@tools.ietf.org" , "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 23:05:59 -0000 On Wed, Feb 20, 2013 at 11:58 PM, Manger, James H wrote: > Canonicalization (c14n) may be a dirty word, and barred from the charter,= but I hope it isn't too inappropriate to still discuss it on this email li= st. > > There is a better c14n format for numbers than I or draft-staykov-hu-json= -canonical-form have suggested: it is the format produced by JSON.stringify= , as defined in ECMAScript v5.1 [http://www.ecma-international.org/ecma-262= /5.1/#sec-15.12.3]. Examples: 0, 1, -1000, 0.00002334, 1500000, 6.022e+23, = 9.1e-28. > > In fact, c14n for JSON can (and should) be simply defined as per JSON.str= ingify, with two extra constraints: object name/value pairs are sorted; and= \uxxxx escapes use lowercase hex digits (a-f). Done. Developers even have = a readily available reference implementations simply by typing JSON.stringi= fy(...) into the JavaScript console of their browser. > Not done. By saying that it should be done as per JSON.stringify(), you basically preclude the use of JSON for languages which _do_ have the ability to represent numbers outside of IEEE 754, and that includes numbers as simple as 0.1. It is not because ECMA 262 has made the braindead decision of limiting numbers to IEEE 754 that JSON should follow way. RFC 4627 didn't make that mistake and I certainly hope any IETF-related work concerning JSON will not make such a mistake either. --=20 Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From James.H.Manger@team.telstra.com Wed Feb 20 15:20:06 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B81321E8030 for ; Wed, 20 Feb 2013 15:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YD8OBJ4tKF1 for ; Wed, 20 Feb 2013 15:20:05 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id D1FDD21F88A1 for ; Wed, 20 Feb 2013 15:20:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,705,1355058000"; d="scan'208";a="120620699" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 21 Feb 2013 10:20:03 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6992"; a="113916120" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipccvi.tcif.telstra.com.au with ESMTP; 21 Feb 2013 10:20:03 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Thu, 21 Feb 2013 10:20:02 +1100 From: "Manger, James H" To: Francis Galiegue Date: Thu, 21 Feb 2013 10:20:02 +1100 Thread-Topic: [Json] Canonicalization Thread-Index: Ac4PvtXolAwYhFyASYa8/C83b3BN1QAACG0Q Message-ID: <255B9BB34FB7D647A506DC292726F6E11507634CD2@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11507634C37@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "draft-staykov-hu-json-canonical-form@tools.ietf.org" , "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 23:20:06 -0000 PiBPbiBXZWQsIEZlYiAyMCwgMjAxMyBhdCAxMTo1OCBQTSwgTWFuZ2VyLCBKYW1lcyBIDQo+IDxK YW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPiB3cm90ZToNCj4gPiBDYW5vbmljYWxpemF0 aW9uIChjMTRuKSBtYXkgYmUgYSBkaXJ0eSB3b3JkLCBhbmQgYmFycmVkIGZyb20gdGhlDQo+IGNo YXJ0ZXIsIGJ1dCBJIGhvcGUgaXQgaXNuJ3QgdG9vIGluYXBwcm9wcmlhdGUgdG8gc3RpbGwgZGlz Y3VzcyBpdCBvbg0KPiB0aGlzIGVtYWlsIGxpc3QuDQo+ID4NCj4gPiBUaGVyZSBpcyBhIGJldHRl ciBjMTRuIGZvcm1hdCBmb3IgbnVtYmVycyB0aGFuIEkgb3IgZHJhZnQtc3RheWtvdi1odS0NCj4g anNvbi1jYW5vbmljYWwtZm9ybSBoYXZlIHN1Z2dlc3RlZDogaXQgaXMgdGhlIGZvcm1hdCBwcm9k dWNlZCBieQ0KPiBKU09OLnN0cmluZ2lmeSwgYXMgZGVmaW5lZCBpbiBFQ01BU2NyaXB0IHY1LjEg W2h0dHA6Ly93d3cuZWNtYS0NCj4gaW50ZXJuYXRpb25hbC5vcmcvZWNtYS0yNjIvNS4xLyNzZWMt MTUuMTIuM10uIEV4YW1wbGVzOiAwLCAxLCAtMTAwMCwNCj4gMC4wMDAwMjMzNCwgMTUwMDAwMCwg Ni4wMjJlKzIzLCA5LjFlLTI4Lg0KPiA+DQo+ID4gSW4gZmFjdCwgYzE0biBmb3IgSlNPTiBjYW4g KGFuZCBzaG91bGQpIGJlIHNpbXBseSBkZWZpbmVkIGFzIHBlcg0KPiBKU09OLnN0cmluZ2lmeSwg d2l0aCB0d28gZXh0cmEgY29uc3RyYWludHM6IG9iamVjdCBuYW1lL3ZhbHVlIHBhaXJzIGFyZQ0K PiBzb3J0ZWQ7IGFuZCBcdXh4eHggZXNjYXBlcyB1c2UgbG93ZXJjYXNlIGhleCBkaWdpdHMgKGEt ZikuIERvbmUuDQo+IERldmVsb3BlcnMgZXZlbiBoYXZlIGEgcmVhZGlseSBhdmFpbGFibGUgcmVm ZXJlbmNlIGltcGxlbWVudGF0aW9ucw0KPiBzaW1wbHkgYnkgdHlwaW5nIEpTT04uc3RyaW5naWZ5 KC4uLikgaW50byB0aGUgSmF2YVNjcmlwdCBjb25zb2xlIG9mDQo+IHRoZWlyIGJyb3dzZXIuDQoN Cj4gTm90IGRvbmUuIEJ5IHNheWluZyB0aGF0IGl0IHNob3VsZCBiZSBkb25lIGFzIHBlciBKU09O LnN0cmluZ2lmeSgpLCB5b3UNCj4gYmFzaWNhbGx5IHByZWNsdWRlIHRoZSB1c2Ugb2YgSlNPTiBm b3IgbGFuZ3VhZ2VzIHdoaWNoIF9kb18gaGF2ZSB0aGUNCj4gYWJpbGl0eSB0byByZXByZXNlbnQg bnVtYmVycyBvdXRzaWRlIG9mIElFRUUgNzU0LCBhbmQgdGhhdCBpbmNsdWRlcw0KPiBudW1iZXJz IGFzIHNpbXBsZSBhcyAwLjEuDQo+IA0KPiBJdCBpcyBub3QgYmVjYXVzZSBFQ01BIDI2MiBoYXMg bWFkZSB0aGUgYnJhaW5kZWFkIGRlY2lzaW9uIG9mIGxpbWl0aW5nDQo+IG51bWJlcnMgdG8gSUVF RSA3NTQgdGhhdCBKU09OIHNob3VsZCBmb2xsb3cgd2F5LiBSRkMgNDYyNyBkaWRuJ3QgbWFrZQ0K PiB0aGF0IG1pc3Rha2UgYW5kIEkgY2VydGFpbmx5IGhvcGUgYW55IElFVEYtcmVsYXRlZCB3b3Jr IGNvbmNlcm5pbmcgSlNPTg0KPiB3aWxsIG5vdCBtYWtlIHN1Y2ggYSBtaXN0YWtlIGVpdGhlci4N Cg0KRG9uZSAoYWxtb3N0KS4NCg0KVGhlIEpTT04uc3RyaW5naWZ5IGZvcm1hdCBmb3IgbnVtYmVy cyBpcyBOT1QgbGltaXRlZCB0byA2NC1iaXQgZmxvYXRzLiBJdCBlZmZlY3RpdmVseSBzYXlzIGZv cm1hdCB0aGUgbnVtYmVyIHdpdGhvdXQgYW4gZXhwb25lbnQgaWYgaXQgaXMgaW4gdGhlIHJhbmdl IFsxZS02LCAxZTIxKTsgb3RoZXJ3aXNlIGZvcm1hdCBpdCB3aXRoIDEgZGlnaXQgYmVmb3JlIHRo ZSBkZWNpbWFsIHBvaW50LiBUaGVyZSBpcyBubyBsaW1pdCB0byB0aGUgbnVtYmVyIG9mIGRpZ2l0 cywgaWUgdGhlIHByZWNpc2lvbi4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From fgaliegue@gmail.com Wed Feb 20 15:31:53 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CCC21E803A for ; Wed, 20 Feb 2013 15:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUqkMf6ZeJbh for ; Wed, 20 Feb 2013 15:31:53 -0800 (PST) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id AC68021E8037 for ; Wed, 20 Feb 2013 15:31:52 -0800 (PST) Received: by mail-ee0-f49.google.com with SMTP id d4so4317134eek.22 for ; Wed, 20 Feb 2013 15:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=e/HGvWPlYKUXIQYU6xEqUzNIhdn7PpUhV1aqKMQL8KA=; b=JowtVKDjGVwcFrWN4GYzX8z+zTEOV07jmgU0tGYyscMAcq7YIjqMzHMgmhqnF5wwJ6 /AXlrCaZbSF05LCkUbeIPSrCj8qNZ1Alhhq+b1DwNCO7T2OZeYZPoplH1OwhYmRE8QFC sWCRFXxyNZ7oBbbMLCWQJakZdbkWzFxq9FGWVD6plo1AszvFjZHr4NU2MSAABTWT+Uqk lGH0Dm2G7SjKvfFZY/xdZJw3fbs10YPRWhpV81GoYXLzBAPFcDh/JCFSOUSU4Pw7PkMI mo5umXzH7QGrgQGRehr/bjUumORlkZqvYQ/NT6L/VbYWWCZ8KJcvHjlLn864sn9JvEoR Uakg== MIME-Version: 1.0 X-Received: by 10.14.209.131 with SMTP id s3mr73772902eeo.26.1361403111736; Wed, 20 Feb 2013 15:31:51 -0800 (PST) Received: by 10.14.1.7 with HTTP; Wed, 20 Feb 2013 15:31:51 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11507634CD2@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11507634C37@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11507634CD2@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 21 Feb 2013 00:31:51 +0100 Message-ID: From: Francis Galiegue To: "Manger, James H" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-staykov-hu-json-canonical-form@tools.ietf.org" , "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 23:31:53 -0000 On Thu, Feb 21, 2013 at 12:20 AM, Manger, James H wrote: [...] > > Done (almost). > > The JSON.stringify format for numbers is NOT limited to 64-bit floats. It= effectively says format the number without an exponent if it is in the ran= ge [1e-6, 1e21); otherwise format it with 1 digit before the decimal point.= There is no limit to the number of digits, ie the precision. > Well, I can tell you that it _is_ limited... Go to the site in my signature, try this: { "maximum": 209098901232398109823091823.29839080918230980980192830198230= 98, "exclusiveMaximum": true } as a schema, and as data, input: 209098901232398109823091823.29839080918230980980192830198230981 As I use a language which has the capability to deal with such numbers, this answers false -- but I use JSON.stringify() to format the results of validation: look at how the numbers are formatted. -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From frsyuki@gmail.com Wed Feb 20 12:35:35 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACF521E803C for ; Wed, 20 Feb 2013 12:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgM9DoDBloCJ for ; Wed, 20 Feb 2013 12:35:34 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id 74C0B21E8039 for ; Wed, 20 Feb 2013 12:35:34 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id kp14so4210654pab.19 for ; Wed, 20 Feb 2013 12:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=IPeauHZHXWveTsJifyBy8IgDXkFHXekl5QVQ+GQu5bU=; b=suxayxNGLoHzQdWeA4ZMmvudSOo2Pjt3nUXTPmaHgHIPm0mEI/2Wwh868L4MyW9fWa r+UbrbRU2irwYn7Vrirqzo4SFYR4YhoT/WoGalt4myaNUryElsmW0q9f991DNsrz/SCD dYKLyjEmbVFx8qaB/n3WeNAJb4pVZlChH0+tl+q0n5DE7Ivg213XAQ3+j6S1N4EG/I0m wW2sj0uTc6uR41Z/a0oyxmgeBmFJ/1qgO2yD2KgDm6faXu+1B+NmF3gvWHf799hniUkK bPSktYFp3T1o/dEiMZ4Axdz768IEiA2kn9WtsYplb4YA9EmnfPrq2VvERa/5b5d2+Y+g R1tA== X-Received: by 10.68.191.73 with SMTP id gw9mr4501139pbc.200.1361392534224; Wed, 20 Feb 2013 12:35:34 -0800 (PST) Received: from [192.168.0.103] (204.11.229.35.static.etheric.net. [204.11.229.35]) by mx.google.com with ESMTPS id qp13sm22686689pbb.3.2013.02.20.12.35.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 12:35:32 -0800 (PST) From: Sadayuki Furuhashi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <54A62940-C313-47FE-A595-FAAD60EB7DAA@gmail.com> Date: Wed, 20 Feb 2013 12:35:29 -0800 To: "json@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 00:20:56 -0000 I'm frsyuki (Sadyuki Furuhashi), the initial designer of the = MessagePack. I found a mail about msgpack. draft-bormann-apparea-bpack-00.txt is slightly modified version of = msgpack and it's not compatible with existent msgpack implementations for over = 20+ languages. Even if msgpack had a UTF-8 type, it will be different from the one = proposed by bpack-00.txt because specs without implementations don't make sense. Thus today's msgpack is a stable format and future msgpack will be = compatible with it. We're supposed to add user-defined custom type support as the part of = its spec. And the string type will be one of the custom types. Here is a msgpack issue thread to discuss about the string type: https://github.com/msgpack/msgpack/issues/121 > On Feb 19, 2013, at 00:47, "Joe Hildebrand (jhildebr)" wrote: >=20 >> As an individual, I'm +1 on that. I love msgpack, and don't mind the >> addition of UTF8 as a separate type. Was frsyuki involved in the = draft, >> or at least know that it happened? >=20 > I tried to involve him. > Frsyuki doesn't like what I did with the binary strings vs. UTF-8, = though. >=20 > I didn't quite catch whether he is just focusing on maintaining = compatibility with what's out there (today's msgpack) or whether he = really doesn't see why that is a good idea. > (For me, maintaining 100 % compatibility won't work anyway, because in = the end that won't be the only change we'll want to make. =20 > If we look a bit outside the space that msgpack is being applied to = today, we might want to support, say, 16-bit floating point.) >=20 > Gr=C3=BC=C3=9Fe, Carsten -- Sadayuki Furuhashi http://fluentd.org http://msgpack.org twitter:@frsyuki From James.H.Manger@team.telstra.com Wed Feb 20 16:33:57 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44D021E8049 for ; Wed, 20 Feb 2013 16:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58o0lgRrOk4l for ; Wed, 20 Feb 2013 16:33:57 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id DA44321E803C for ; Wed, 20 Feb 2013 16:33:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,705,1355058000"; d="scan'208";a="120641622" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 21 Feb 2013 11:33:54 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6992"; a="113932353" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipccvi.tcif.telstra.com.au with ESMTP; 21 Feb 2013 11:33:54 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 21 Feb 2013 11:33:53 +1100 From: "Manger, James H" To: Francis Galiegue Date: Thu, 21 Feb 2013 11:33:52 +1100 Thread-Topic: [Json] Canonicalization Thread-Index: Ac4Pwng4eU3Qn8VSTGCiahP302TwsAAACLwA Message-ID: <255B9BB34FB7D647A506DC292726F6E11507634EE0@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11507634C37@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11507634CD2@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "draft-staykov-hu-json-canonical-form@tools.ietf.org" , "json@ietf.org" Subject: Re: [Json] Canonicalization X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 00:33:58 -0000 RnJhbmNpcywNCllvdXIgbnVtYmVyIGlzIGdyZWF0ZXIgdGhhbiAxZTIxIHNvIHRoZSBjMTRuIGZv cm1hdCB3b3VsZCBiZToNCjIuMDkwOTg5MDEyMzIzOTgxMDk4MjMwOTE4MjMyOTgzOTA4MDkxODIz MDk4MDk4MDE5MjgzMDE5ODIzMDk4ZSsyNg0KDQpJZiB5b3UgYXJlIGV4Y2hhbmdpbmcgZGF0YSB3 aXRoIGFuIGltcGxlbWVudGF0aW9uIHRoYXQgcm91bmRzIG51bWJlcnMgdG8gZml0IGluIDY0LWJp dCBmbG9hdHMgdGhlbiB5b3Ugb2J2aW91c2x5IHdpbGwgbm90IGFncmVlIG9uIHRoZSBleGFjdCB2 YWx1ZS4gSSBkb24ndCB0aGluayB0aGF0IGlzIHJlYWxseSBhIGMxNG4gaXNzdWUsIGhvd2V2ZXIu DQoNClBlcmhhcHMgYW4gSUVURiBKU09OIGMxNG4gc3BlYyB3b3VsZCBuZWVkIHRvIHJlcGVhdCB0 aGUgSlNPTi5zdHJpbmdpZnkgcnVsZXMgYXMgb3Bwb3NlZCB0byBqdXN0IHJlZmVyZW5jaW5nIHRo ZW0uIE15IHBvaW50IGlzIHRoYXQgSlNPTi5zdHJpbmdpZnkgcGlja3MgYSByZWFsbHkgdXNlZnVs IGZvcm0gZm9yIG51bWJlcnMgKGFuZCBzdHJpbmdzKSwgaXQgaXMgYSBjYW5vbmljYWwgZm9ybSAo ZXhhY3RseSAxIGZvcm0gZm9yIGFueSBudW1iZXIgb3Igc3RyaW5nKSwgaXQgaXMgYWxyZWFkeSBw cmVjaXNlbHkgc3BlY2lmaWVkLCB0aGVyZSBhcmUgbXVsdGlwbGUgcHJvZHVjdGlvbiBpbXBsZW1l bnRhdGlvbnMuIFRoYXQgaXMgYSBncmVhdCBiYXNpcyBmb3IgYSBoaWdobHktaW50ZXJvcGVyYWJs ZSBJRVRGIEpTT04gYzE0biBzcGVjLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBGcmFuY2lzIEdhbGllZ3VlIFttYWlsdG86Zmdh bGllZ3VlQGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIDIxIEZlYnJ1YXJ5IDIwMTMgMTA6 MzIgQU0NCj4gVG86IE1hbmdlciwgSmFtZXMgSA0KPiBDYzoganNvbkBpZXRmLm9yZzsgZHJhZnQt c3RheWtvdi1odS1qc29uLWNhbm9uaWNhbC1mb3JtQHRvb2xzLmlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbSnNvbl0gQ2Fub25pY2FsaXphdGlvbg0KPiANCj4gT24gVGh1LCBGZWIgMjEsIDIwMTMg YXQgMTI6MjAgQU0sIE1hbmdlciwgSmFtZXMgSA0KPiA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxz dHJhLmNvbT4gd3JvdGU6DQo+IFsuLi5dDQo+ID4NCj4gPiBEb25lIChhbG1vc3QpLg0KPiA+DQo+ ID4gVGhlIEpTT04uc3RyaW5naWZ5IGZvcm1hdCBmb3IgbnVtYmVycyBpcyBOT1QgbGltaXRlZCB0 byA2NC1iaXQNCj4gZmxvYXRzLiBJdCBlZmZlY3RpdmVseSBzYXlzIGZvcm1hdCB0aGUgbnVtYmVy IHdpdGhvdXQgYW4gZXhwb25lbnQgaWYgaXQNCj4gaXMgaW4gdGhlIHJhbmdlIFsxZS02LCAxZTIx KTsgb3RoZXJ3aXNlIGZvcm1hdCBpdCB3aXRoIDEgZGlnaXQgYmVmb3JlDQo+IHRoZSBkZWNpbWFs IHBvaW50LiBUaGVyZSBpcyBubyBsaW1pdCB0byB0aGUgbnVtYmVyIG9mIGRpZ2l0cywgaWUgdGhl DQo+IHByZWNpc2lvbi4NCj4gPg0KPiANCj4gV2VsbCwgSSBjYW4gdGVsbCB5b3UgdGhhdCBpdCBf aXNfIGxpbWl0ZWQuLi4NCj4gDQo+IEdvIHRvIHRoZSBzaXRlIGluIG15IHNpZ25hdHVyZSwgdHJ5 IHRoaXM6DQo+IA0KPiB7DQo+ICAgICAibWF4aW11bSI6DQo+IDIwOTA5ODkwMTIzMjM5ODEwOTgy MzA5MTgyMy4yOTgzOTA4MDkxODIzMDk4MDk4MDE5MjgzMDE5ODIzMDk4LA0KPiAgICAgImV4Y2x1 c2l2ZU1heGltdW0iOiB0cnVlDQo+IH0NCj4gDQo+IGFzIGEgc2NoZW1hLCBhbmQgYXMgZGF0YSwg aW5wdXQ6DQo+IA0KPiAyMDkwOTg5MDEyMzIzOTgxMDk4MjMwOTE4MjMuMjk4MzkwODA5MTgyMzA5 ODA5ODAxOTI4MzAxOTgyMzA5ODENCj4gDQo+IEFzIEkgdXNlIGEgbGFuZ3VhZ2Ugd2hpY2ggaGFz IHRoZSBjYXBhYmlsaXR5IHRvIGRlYWwgd2l0aCBzdWNoIG51bWJlcnMsDQo+IHRoaXMgYW5zd2Vy cyBmYWxzZSAtLSBidXQgSSB1c2UgSlNPTi5zdHJpbmdpZnkoKSB0byBmb3JtYXQgdGhlIHJlc3Vs dHMNCj4gb2YgdmFsaWRhdGlvbjogbG9vayBhdCBob3cgdGhlIG51bWJlcnMgYXJlIGZvcm1hdHRl ZC4NCj4gDQo+IC0tDQo+IEZyYW5jaXMgR2FsaWVndWUsIGZnYWxpZWd1ZUBnbWFpbC5jb20NCj4g VHJ5IG91dCB5b3VyIEpTT04gU2NoZW1hczogaHR0cDovL2pzb24tc2NoZW1hLXZhbGlkYXRvci5o ZXJva3VhcHAuY29tDQo= From jsontest@yahoo.com Wed Feb 20 17:12:06 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74B921E804B for ; Wed, 20 Feb 2013 17:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C32dtW5pshti for ; Wed, 20 Feb 2013 17:12:05 -0800 (PST) Received: from nm37-vm8.bullet.mail.gq1.yahoo.com (nm37-vm8.bullet.mail.gq1.yahoo.com [98.136.217.44]) by ietfa.amsl.com (Postfix) with ESMTP id 192B921E8049 for ; Wed, 20 Feb 2013 17:12:04 -0800 (PST) Received: from [98.137.12.61] by nm37.bullet.mail.gq1.yahoo.com with NNFMP; 21 Feb 2013 01:12:04 -0000 Received: from [98.136.185.199] by tm6.bullet.mail.gq1.yahoo.com with NNFMP; 21 Feb 2013 01:12:04 -0000 Received: from [127.0.0.1] by smtp108-mob.biz.mail.gq1.yahoo.com with NNFMP; 21 Feb 2013 01:12:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361409124; bh=Btisi2AKx9SXl3BIARb3muzbtEJWBOr3LRnHrkkugWk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=y/sLqMKSNzafprWhF6Gjjg99u6ddjqDhxNVyClSiqmYNvJePDHDdCB4hopWtGCgKeb7wkniU24qn2KPB02UPe+OANG3Jn6ISL18aZH24llfQ8fTCu6A6N9SEWQquXHu+XP+77AlZlsNpZYz9MMywCqLCOT7avKZC/xQSkl9gAl0= X-Yahoo-Newman-Id: 615545.45428.bm@smtp108-mob.biz.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: .HGXQNIVM1kLvmONHqxWdFrJsVw86Wg09lT0_TMz.ma9XD5 au_XCYZO1ZPRKOQiqJue7vziafRkBFtymViFBn.HQTWxT9Lx3y.JCyLxwv0a 5QvcUFGjp6bTxuF0tZSX3slHBMdsKjK33SkYVF9lV4I2C5DOxyqDEWZq6Nxl 7kSNnd6JEcSXLCWTUOywO1mdzAZRnJ8qW60mP4RQMf9VfiyI6O3FHCGN6gAx TCeNmjpw77a4BS65YfgOU2jB2650HEL_UMqwBmz7gN03XHPQEO21PtG6uADp XBp4wEEBA9pA4D8C_F6SitA2zacFGGvPNhg66aSx.Dps8O1jLqoo5PhqVrnd E_KLAOCPllee4.g3Jfqo2HI_kGGyD.o0P5wECh.aAglkNn8X0t8EdNYlS1FB lx9FAh10P1tAy2LG8409Hl2LbhuAdPbwupA-- X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T Received: from [192.168.0.102] (jsontest@76.29.100.42 with xymcookie) by smtp108-mob.biz.mail.gq1.yahoo.com with SMTP; 20 Feb 2013 17:12:04 -0800 PST References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <12CE5BFB-49C5-48D0-96DF-F78F0D60578A@yahoo.com> X-Mailer: iPod Mail (9B206) From: Vinny A Date: Wed, 20 Feb 2013 19:12:01 -0600 To: Francis Galiegue Cc: Tim Bray , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 01:12:07 -0000 On Feb 20, 2013, at 2:39 PM, Francis Galiegue wrote: > Duplicate keys in an object, on the other hand, are indeed an > important subject There's a lot of interesting discussion in this thread, but I'd like to see m= ore on duplicate keys. Various parsers either throw errors or record the las= t key:value pair when encountering duplicate keys, and I'd like to see a rec= ommendation consensus. One parser I've seen took a fascinating approach: it copied all values of a s= hared key and added them to an array, keyed to the duplicate key. From fgaliegue@gmail.com Wed Feb 20 17:20:36 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B2521F8CD2 for ; Wed, 20 Feb 2013 17:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m57WkE2RSNNZ for ; Wed, 20 Feb 2013 17:20:35 -0800 (PST) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5715821F8CD1 for ; Wed, 20 Feb 2013 17:20:35 -0800 (PST) Received: by mail-ea0-f178.google.com with SMTP id a14so3657045eaa.23 for ; Wed, 20 Feb 2013 17:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bfnvlwDL/CxD0EjYf7QwMwYW5r0Z0iTL27ix8c4PUvE=; b=TiWFMCogjSq6YTCz1/s9Ius4PuMYJFQzGElex7OIpTDFJsZzpUi9kdqhsPdNPTVHVg XYw4I6zzvNFDgDJFIftlzbJevx43zWEs6GVyap4mV0N7dJYY9YdcefwdRTZIsA1P/ki5 geQIU2gjLyvoOEpTDOfDhz5GDPCU9sqwKL7rPdOHfzjTgzH0N23oOmUenqAUiB9r23k8 XwkFexwBWacKOvaQfqurqOLuOtwBYbIXNX6QFCWU/2vceG4TFH7ChkDJtOVHVanDaAjk IGN/l+ZatvZKxnShslmrelIfHFjraN9ZscYSxtYH3Q+uB0qLXmnGJ9ViJnW32flBnNpO ESTA== MIME-Version: 1.0 X-Received: by 10.14.183.198 with SMTP id q46mr75516943eem.1.1361409634334; Wed, 20 Feb 2013 17:20:34 -0800 (PST) Received: by 10.14.1.7 with HTTP; Wed, 20 Feb 2013 17:20:34 -0800 (PST) In-Reply-To: <12CE5BFB-49C5-48D0-96DF-F78F0D60578A@yahoo.com> References: <12CE5BFB-49C5-48D0-96DF-F78F0D60578A@yahoo.com> Date: Thu, 21 Feb 2013 02:20:34 +0100 Message-ID: From: Francis Galiegue To: Vinny A Content-Type: text/plain; charset=UTF-8 Cc: Tim Bray , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 01:20:36 -0000 On Thu, Feb 21, 2013 at 2:12 AM, Vinny A wrote: > On Feb 20, 2013, at 2:39 PM, Francis Galiegue wrote: >> Duplicate keys in an object, on the other hand, are indeed an >> important subject > > > There's a lot of interesting discussion in this thread, but I'd like to see more on duplicate keys. Various parsers either throw errors or record the last key:value pair when encountering duplicate keys, and I'd like to see a recommendation consensus. > > One parser I've seen took a fascinating approach: it copied all values of a shared key and added them to an array, keyed to the duplicate key. > Isn't that org.json? I recall having seen that as well... I know for sure that Jackson picks the last key/value pair. But the problem is indeed that the "append to an array" parser does nothing illegal per se -- basically, as RFC 4627 stands today, the behaviour of parsers with regards to duplicate object member names is undefined. And some existing I-Ds, such as JSON Patch, as a result, have felt compelled to say that a JSON Patch operation, for instance, must have one and only one member named "op". Which imposes constraints on _parsing_ that RFC 4627 does not... -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From sayrer@gmail.com Wed Feb 20 17:29:53 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D02C21E8055 for ; Wed, 20 Feb 2013 17:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+nhYa0Xnh15 for ; Wed, 20 Feb 2013 17:29:52 -0800 (PST) Received: from mail-we0-x22f.google.com (we-in-x022f.1e100.net [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1A021E8053 for ; Wed, 20 Feb 2013 17:29:52 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id x8so7201676wey.6 for ; Wed, 20 Feb 2013 17:29:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DHT5aRXUgD8aYs2CP0Aj74RxM6BqcW1ymrD+7NLFKnw=; b=pCV+H9cF3D6OuvsYHdj80/j6YFHZ+GgWwhDvopV/XdT+zvJ6J36uuT2ZqcZedBa9Of JhO0s6Bgcmt1aR/M9G2Ot/YB7n9OXEPSgvC65FknPkB8ECCFwQQxcn9yAsfhuiOwTH25 YXHDpiw/+jWNSrxXE21EUvYLzgrlKzZYbDUOUhxAD+i7nppw7CQHRsbfBC3hNE+v0NIH 56iZVdemxuHrXSya0JfuGlZ4XYDApz1+ja/qOAxGfOUdBclOi55d+svw6eGoC/V/xciH Eq5hRE9jctdvbNov4bEnOxuC6veu8Y42USstWi3mNFspWEk5VaNYhf1CjO9/aojJnw7C 1heQ== MIME-Version: 1.0 X-Received: by 10.180.105.232 with SMTP id gp8mr37802866wib.33.1361410191202; Wed, 20 Feb 2013 17:29:51 -0800 (PST) Received: by 10.194.138.170 with HTTP; Wed, 20 Feb 2013 17:29:51 -0800 (PST) In-Reply-To: References: <12CE5BFB-49C5-48D0-96DF-F78F0D60578A@yahoo.com> Date: Wed, 20 Feb 2013 17:29:51 -0800 Message-ID: From: Robert Sayre To: Francis Galiegue Content-Type: text/plain; charset=ISO-8859-1 Cc: Vinny A , Tim Bray , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 01:29:53 -0000 On Wed, Feb 20, 2013 at 5:20 PM, Francis Galiegue wrote: > > And some existing I-Ds, such as JSON Patch, as a result, have felt > compelled to say that a JSON Patch operation, for instance, must have > one and only one member named "op". Which imposes constraints on > _parsing_ that RFC 4627 does not... I can't think of a reason not to specify what ES5 does here (always use the last one). This is a perfectly reliable way to write into a hash table during decoding. And while you can't depend on a single hash table's iteration order during encoding, you can count on unique keys, so the appearance of duplicate keys in a JSON dictionary implies a sequence of sets. - Rob From stpeter@stpeter.im Wed Feb 20 17:44:25 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA4521F8558 for ; Wed, 20 Feb 2013 17:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+xcQtOy+wng for ; Wed, 20 Feb 2013 17:44:24 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B740221F854D for ; Wed, 20 Feb 2013 17:44:24 -0800 (PST) Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 201AC403CD; Wed, 20 Feb 2013 18:51:53 -0700 (MST) Message-ID: <51257BF6.2060408@stpeter.im> Date: Wed, 20 Feb 2013 18:44:22 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mark Nottingham References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> In-Reply-To: <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 01:44:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/20/13 3:30 PM, Mark Nottingham wrote: > On 21/02/2013, at 6:02 AM, Paul Hoffman > wrote: > >> On Feb 20, 2013, at 10:43 AM, Nico Williams >> wrote: >> >>> On Wed, Feb 20, 2013 at 11:38 AM, Paul Hoffman >>> wrote: >>>> On Feb 20, 2013, at 9:27 AM, Tim Bray >>>> wrote: >>>>> My proposal is: do nothing. >>>> >>>> -1. >>>> >>>> There are places where RFC 4627 has SHOULDs where some >>>> processors do one thing and others do something different. >>>> That should be cleaned up in a standards-track RFC, and it >>>> should be done with lots of JSON developers and users having >>>> a discussion that comes to rough consensus. >>> >>> One I-D as simple as this hardly justifies a WG. >> >> Getting broad consensus on changing a standard that is >> implemented widely outside the IETF justifies the effort to have >> the time and space for consensus. This is *not* just IETF work. > > > I don't know. I think I'd be fine if we just asked Crockford > (perhaps helped by a willing editor) to do 4627bis and then have > the AD sponsor it on Standards Track. That does seem reasonable, and it carefully sidesteps the all-too-common desire to "improve" a spec... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJXv1AAoJEOoGpJErxa2pnSQP/jUuvKCmuXzmPvCWDUlV9wYu 1eyyxjvTxxaXrbL3GCIA8QBTt+LOYn3PMHRg1+hERgMsLC8IQ1Nhb365Zxjhu/xL opCbsRigY9v2JOo/sahI6M4fFs+MFEFAy1lj+cNCIWZN/NpI5PJt3wYmojSeJ2S0 GJG+/afWSxyWPTkCScgr52HEmiNikpTMGRws0fdE0KVWo99pGReI+sAe7BDiVGo5 upVrX8fK4rFclJE6SvZxBYTFKvJzlX6gj5fqEoBfH8DoQhMUQKi7NpjuokITkO2P G+wr3qEGHveMPmAF6wmEI0N+oDw7L+zobzHR62iOUwtRRdJGJtRYOwCkuuObufTI T339IZyPmXAIR2uOiaPBEDG+KvMD8DG778B4pf+E74+tfIZU7lw+GHTQ1fgDX18n vHt7SN3/ggK6NjjrPx3BDoR5cgnJfpGSKyU2jWgloaUsmZqkft1Tq/iQPHdsMiNC 2EHyt+9Q97GIuFgnN67tQfkaSUCbVHTGCjsLJeVwX8h+zbbptOjF6DrIAIx5HVDL jnjG7rgzZhJIc7A7CFD/Rxcn67hx4YZ3TjsrcIFZabcoLPLVAXMVIP5HncVjdroC xu1AjitNv+7gvM9O5JLwZE91gCGro3fkp6W+YMk48Zne8cTtQ3YGC9gPrMqhq5yT 3qFbXKKCJIYQ4pmk0RE5 =0aub -----END PGP SIGNATURE----- From sayrer@gmail.com Wed Feb 20 18:03:21 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01EB21F8480 for ; Wed, 20 Feb 2013 18:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGul8IttO0mx for ; Wed, 20 Feb 2013 18:03:21 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id EB2B921F847C for ; Wed, 20 Feb 2013 18:03:20 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id l13so199634wie.4 for ; Wed, 20 Feb 2013 18:03:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vMHO+DKm0cm/kTW605aZ+xs6j1gVbh3gVepFxrdZUNI=; b=efEEu/73leJrtJKamF+QUXq1MHuSmHTFFBTpIimxPrSGzo4a2RL7npTJ+2y5sdEFCK Wk4nZDdraCTegpXq2Op1YzRzO1QVQ50bCk+ELcDvWTPvDV/qzDqJHAOti5pFi3y+GAWq DTjJ6zH/xsyLA2Pk+Q28MIY5aeOjCxhdvz7Wb1TVq3R9ugGYAQaV6l2MkzJxQSZ77S+V sNG3G7BlIVWLp0f/7jJtrE9rkzoEM+EOcrYeQLYSbdueVLHRKFVdqReS+KJqcGr8My49 8Rx2L/WzMGVHeYdwXuMklbvxbgOt8WAZVXMh4Sa0/Nf0w9R2J+FGTBhNnp318FG4Kjdm Ae9g== MIME-Version: 1.0 X-Received: by 10.194.108.229 with SMTP id hn5mr38046553wjb.8.1361412200104; Wed, 20 Feb 2013 18:03:20 -0800 (PST) Received: by 10.194.138.170 with HTTP; Wed, 20 Feb 2013 18:03:19 -0800 (PST) In-Reply-To: <51257BF6.2060408@stpeter.im> References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <51257BF6.2060408@stpeter.im> Date: Wed, 20 Feb 2013 18:03:19 -0800 Message-ID: From: Robert Sayre To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: Mark Nottingham , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 02:03:21 -0000 On Wed, Feb 20, 2013 at 5:44 PM, Peter Saint-Andre wrote: > > That does seem reasonable, and it carefully sidesteps the > all-too-common desire to "improve" a spec... Yes. The RFC is out of date now, in the sense that you can expect to have interoperability problems if you follow it to the letter. But, as Bjoern points out, there are aspects of JSON defined only in the RFC. In other words, I think a new RFC is needed, but Crockford has already documented almost all of the changes needed in ES5. - Rob From jsontest@yahoo.com Wed Feb 20 20:02:15 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB87621F8D94 for ; Wed, 20 Feb 2013 20:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAWxESoKsdOj for ; Wed, 20 Feb 2013 20:02:15 -0800 (PST) Received: from nm9-vm0.bullet.mail.ne1.yahoo.com (nm9-vm0.bullet.mail.ne1.yahoo.com [98.138.91.67]) by ietfa.amsl.com (Postfix) with ESMTP id DA9E021F8D0D for ; Wed, 20 Feb 2013 20:02:14 -0800 (PST) Received: from [98.138.226.178] by nm9.bullet.mail.ne1.yahoo.com with NNFMP; 21 Feb 2013 04:02:14 -0000 Received: from [98.138.87.6] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 21 Feb 2013 04:02:14 -0000 Received: from [127.0.0.1] by omp1006.mail.ne1.yahoo.com with NNFMP; 21 Feb 2013 04:02:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 127388.53648.bm@omp1006.mail.ne1.yahoo.com Received: (qmail 62560 invoked by uid 60001); 21 Feb 2013 04:02:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361419333; bh=xYtELIKjjoCF1tZ8R8ECNtyE9j+Aglw6ehSd8jvrxM4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jNKsn66c4FARY2g2qh7f0N23XS+SD0wgZfZ41gIBplhd5ogr+sa0kWM/D3imCI6PQJ3CmyEyq2q4zCNitxrh254cskbeWLaQethyuIa5e0Q49HPDz7aOHGMkektSaku9H2k+nmL18ofZMlqkx57gQX3EbpBSSyT90aIvl5vqfq0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=m1mur2sn/a7hs3ivf+/mJsMpBVKjFo8izDhBbv6uNGwx7eNyRnLgy2/z6hWohYzrSyQD7wqt5bWxUbqs1uJ1R5ly6V68WjLxHIvwmiIsePuZL71vmbG6+IW/ldV+DIHx3CH/L2hKoaWZszSyKMM64CtdIYEcV7L0ygI9Kdn/4lM=; X-YMail-OSG: JyBf_FoVM1mQB49E75g04qc6zhBDQxb5hBTfJq.Ulkr.Xan uAEzK4KgaCvTlBZrCyS7MSrwB_OFDhw3QxGJDbA3AFQ7kzY6wTZSUm78hLCy 6rjOkCKUHlCsDan8Thgb2krJql0qjEuEbEUib3o6_65_pFnZFg6y9QaO0LW5 jngHr96oOXHg5Udk2RwGzQzAV2J_XyJ26j5HLgo5E7_2ridcJRbFHcon7dbt HolkAE.xz0fkyNe8FbGlrdwvCj7.d2OS61BYCKlJ4R5wVmzvQaU.0Sfo37H3 t8_VTie8TeLgbnRjitN486Yi_F8RbuAzxXaWmNq_pADwFF_FmBTSc7rDnMGU 9NMMYA09uA_YQmSMeF1uiyj9sYIxN7BpWDIXJmWbR172hWU3J.WqPFiD15PG 6ZoML46U7o9KB.sM3aP.gf6XH42dGoD7cYkllGGYU5dWcaY7wlXs5gOi4RYp uVYwC.fEHvfuVbRY3dmoVRBmy2qajFmXkKsX0p5JN.eZe2.YKDnIS2ibOVp6 LoMxs5yXE50jm6LRz2iAivwl9DYFlrUmxzt0QulL_cEQc0.uj Received: from [76.29.100.42] by web125604.mail.ne1.yahoo.com via HTTP; Wed, 20 Feb 2013 20:02:13 PST X-Rocket-MIMEInfo: 001.001, PiBPbiBGZWIgMjAsIDIwMTMsIGF0IDI6MzkgUE0sIEZyYW5jaXMgR2FsaWVndWUgPGZnYWxpZWd1ZUBnbWFpbC5jb20.IHdyb3RlOgo.SXNuJ3QgdGhhdCBvcmcuanNvbj8gSSByZWNhbGwgaGF2aW5nIHNlZW4gdGhhdCBhcyB3ZWxsLi4uIEkga25vdyBmb3Igc3VyZSB0aGF0IEphY2tzb24gcGlja3MgdGhlIGxhc3Qga2V5L3ZhbHVlIHBhaXIuIEJ1dCB0aGUgcHJvYmxlbSBpcyBpbmRlZWQgdGhhdCB0aGUgImFwcGVuZCB0byBhbiBhcnJheSIgcGFyc2VyIGRvZXMgbm90aGluZyBpbGxlZ2FsIHBlciBzZSAtLSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.134.513 References: <12CE5BFB-49C5-48D0-96DF-F78F0D60578A@yahoo.com> Message-ID: <1361419333.51990.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Wed, 20 Feb 2013 20:02:13 -0800 (PST) From: Vinny A To: Francis Galiegue In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-367120970-1361419333=:51990" Cc: Tim Bray , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Vinny A List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 04:02:16 -0000 ---685807438-367120970-1361419333=:51990 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > On Feb 20, 2013, at 2:39 PM, Francis Galiegue wrote= :=0A>Isn't that org.json? I recall having seen that as well... I know for s= ure that Jackson picks the last key/value pair. But the problem is indeed t= hat the "append to an array" parser does nothing illegal per se -- basicall= y, as RFC 4627 stands today, the behaviour of parsers with regards to dupli= cate object member names is undefined.=0A=A0=0AI believe org.json throws a = exception if it hits a duplicated key; at least the documentation [ http://= json.org/javadoc/org/json/JSONObject.html#JSONObject(java.lang.String) ] su= ggests that to be the case. I don't remember where I saw the append to arra= y parser - but it's such a good idea it's worth bringing up in this convers= ation.=0A=A0=0A>And some existing I-Ds, such as JSON Patch, as a result, ha= ve felt compelled to say that a JSON Patch operation, for instance, must ha= ve one and only one member named "op". Which imposes constraints on _parsin= g_ that RFC 4627 does not...=0A=A0=0AWhich is precisely why I'd like to see= a recommendation regarding duplicated keys. To be honest, I like the idea = of array conversion, but I can understand if others dislike it. I work with= JSON quite a bit, and it would be nice to be able to point to a documented= , recommended spec.=0A=A0=0A-----------=0A-Vinny A ---685807438-367120970-1361419333=:51990 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
> On Feb 20, = 2013, at 2:39 PM, Francis Galiegue <fgaliegue@gmail.com> wrote= :
>Isn't that org.json? I recall having seen that as well... I know f= or sure that Jackson picks the last key/value pair. But the problem is inde= ed that the "append to an array" parser does nothing illegal per se -- basi= cally, as RFC 4627 stands today, the behaviour of parsers with regards to d= uplicate object member names is undefined.
 
I bel= ieve org.json throws a exception if it hits a duplicated key; at least the = documentation [ http://json.org/javadoc/org/json/JSONObject.h= tml#JSONObject(java.lang.String) ] suggests that to be the case. I don'= t remember where I saw the append to array parser - but it's such a good ide= a it's worth bringing up in this conversation.
 
&= gt;And some existing I-Ds, such as JSON Patch, as a result, have felt compe= lled to say that a JSON Patch operation, for instance, must have one and on= ly one member named "op". Which imposes constraints on _parsing_ that RFC 4= 627 does not...
 
Which is precisely why I'd like = to see a recommendation regarding duplicated keys. To be honest, I like the= idea of array conversion, but I can understand if others dislike it. I wor= k with JSON quite a bit, and it would be nice to be able to point to a docu= mented, recommended spec.
 
-----------
= -Vinny A
 
---685807438-367120970-1361419333=:51990-- From cyrus@daboo.name Wed Feb 20 20:14:33 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB4C21E808D for ; Wed, 20 Feb 2013 20:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.474 X-Spam-Level: X-Spam-Status: No, score=-104.474 tagged_above=-999 required=5 tests=[AWL=-2.475, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4yXtpSlgiNq for ; Wed, 20 Feb 2013 20:14:33 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4311321E8055 for ; Wed, 20 Feb 2013 20:14:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id D47783DC3AF9; Wed, 20 Feb 2013 23:14:32 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyBB_r82H7XX; Wed, 20 Feb 2013 23:14:32 -0500 (EST) Received: from [17.45.162.188] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 600E63DC3AE9; Wed, 20 Feb 2013 23:14:31 -0500 (EST) Date: Wed, 20 Feb 2013 23:14:44 -0500 From: Cyrus Daboo To: Vinny A , Francis Galiegue Message-ID: <4E2B71678D46B212D1553AD2@cyrus.local> In-Reply-To: <1361419333.51990.YahooMailNeo@web125604.mail.ne1.yahoo.com> References: <12CE5BFB-49C5-48D0-96DF-F78F0D60578A@yahoo.com> <1361419333.51990.YahooMailNeo@web125604.mail.ne1.yahoo.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=812 Cc: Tim Bray , "Joe Hildebrand \(jhildebr\)" , json@ietf.org Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 04:14:34 -0000 Hi Vinny, --On February 20, 2013 8:02:13 PM -0800 Vinny A wrote: > I believe org.json throws a exception if it hits a duplicated key; at > least the documentation [ > http://json.org/javadoc/org/json/JSONObject.html#JSONObject(java.lang.Str > ing) ] suggests that to be the case. I don't remember where I saw the > append to array parser - but it's such a good idea it's worth bringing up > in this conversation. Another data point: Python 2.7.2 - >>> import json >>> print json.loads('{"a":"a", "a":"b"}') {u'a': u'b'} So Python will accept duplicate keys, but one value is lost. This makes sense since keys in Python dicts are unique. At this point I favor changing the SHOULD to a MUST in RFC 4627bis to make it clear that there is lack of interoperability here. -- Cyrus Daboo From sayrer@gmail.com Wed Feb 20 21:15:40 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCD121E80A0 for ; Wed, 20 Feb 2013 21:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0j3GuQiaxuL for ; Wed, 20 Feb 2013 21:15:39 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id A43CD21F841D for ; Wed, 20 Feb 2013 21:15:38 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hn17so7051378wib.16 for ; Wed, 20 Feb 2013 21:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GaNTw069SdTQdBtne7lBI3MTx3r09WowCd6WPXb/DUk=; b=f9noZfIv84IG1+mlPFBtRGgxGPTkd6E7PE04pm4uy0XaPiRc9867YCETqu/fOy1dqZ ygC+1OPgWxFGCPEF3lMuV+QHvh/A8yXD4EIBbULOY5moqK9FE/jScOWYctpQtVO+9FV9 JPEM95cOQx6wtnmQZXYIylSpqE0+lgwaSq9KrTCtTyKazmzDOFZLRO+oLCueuYtDEI+8 PyE5/jYTPDkLpexBHqDvr+i4Nvqyzxo4l8s0LJCyrLCB5e8bR7hKZztGrKBFtdb2zNfQ yP+gH+59I9VKE33UviUwVQrVMHOoUpOuVAwIIFHlPWUGtnj78/4B5WZxdwFy3wlV8+Nm sZzw== MIME-Version: 1.0 X-Received: by 10.180.91.106 with SMTP id cd10mr20036488wib.6.1361423737852; Wed, 20 Feb 2013 21:15:37 -0800 (PST) Received: by 10.194.138.170 with HTTP; Wed, 20 Feb 2013 21:15:37 -0800 (PST) In-Reply-To: <4E2B71678D46B212D1553AD2@cyrus.local> References: <12CE5BFB-49C5-48D0-96DF-F78F0D60578A@yahoo.com> <1361419333.51990.YahooMailNeo@web125604.mail.ne1.yahoo.com> <4E2B71678D46B212D1553AD2@cyrus.local> Date: Wed, 20 Feb 2013 21:15:37 -0800 Message-ID: From: Robert Sayre To: Cyrus Daboo Content-Type: multipart/alternative; boundary=f46d043be11a48920604d6352a72 Cc: Vinny A , "json@ietf.org" , Tim Bray , "Joe Hildebrand \(jhildebr\)" , Francis Galiegue Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 05:15:40 -0000 --f46d043be11a48920604d6352a72 Content-Type: text/plain; charset=ISO-8859-1 On Wednesday, February 20, 2013, Cyrus Daboo wrote: > Hi Vinny, > > --On February 20, 2013 8:02:13 PM -0800 Vinny A > wrote: > > I believe org.json throws a exception if it hits a duplicated key; at >> least the documentation [ >> http://json.org/javadoc/org/**json/JSONObject.html#** >> JSONObject(java.lang.Str >> ing) ] suggests that to be the case. I don't remember where I saw the >> append to array parser - but it's such a good idea it's worth bringing up >> in this conversation. >> > > Another data point: Python 2.7.2 - > > import json >>>> print json.loads('{"a":"a", "a":"b"}') >>>> >>> {u'a': u'b'} > > So Python will accept duplicate keys, but one value is lost. This makes > sense since keys in Python dicts are unique. At this point I favor changing > the SHOULD to a MUST in RFC 4627bis to make it clear that there is lack of > interoperability here. > There is a lack of interoperability, and this issue is one of the smaller points. The larger point is that the JS implementations (and many smaller ones) have no incentive to change their behavior, and what they do is reasonable. Let's just do that. - Rob --f46d043be11a48920604d6352a72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wednesday, February 20, 2013, Cyrus Daboo wrote:
Hi Vinny,

--On February 20, 2013 8:02:13 PM -0800 Vinny A <jsontest@yahoo.com> wrote:

I believe org.json throws a exception if it hits a duplicated key; at
least the documentation [
http://json.org/javadoc/org/json/JSONOb= ject.html#JSONObject(java.lang.Str
ing) ] suggests that to be the case. I don't remember where I saw the append to array parser - but it's such a good idea it's worth bring= ing up
in this conversation.

Another data point: Python 2.7.2 -

import json
print json.loads('{"a":"a", "a":"b&q= uot;}')
{u'a': u'b'}

So Python will accept duplicate keys, but one value is lost. This makes sen= se since keys in Python dicts are unique. At this point I favor changing th= e SHOULD to a MUST in RFC 4627bis to make it clear that there is lack of in= teroperability here.

There is a lack of interoperability, and t= his issue is one of the smaller points. The larger point is that the JS imp= lementations (and many smaller ones)=A0have no incentive to=A0= change their behavior, and what they do is reasonable. Let's just do th= at.

- Rob
--f46d043be11a48920604d6352a72-- From tbray@textuality.com Wed Feb 20 22:33:47 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1439B21F8DC7 for ; Wed, 20 Feb 2013 22:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1h-9-g889ns for ; Wed, 20 Feb 2013 22:33:46 -0800 (PST) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2653221F8DB7 for ; Wed, 20 Feb 2013 22:33:45 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id xb4so3356005pbc.15 for ; Wed, 20 Feb 2013 22:33:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=6BAkKELdyEr+X50CXO1O4Or9E/SvZmLzI/jDBTDVKr8=; b=PpPsTzqc8e6ovli5EbYgh7663YBUDmEaRfxLEpcYtGb4IkgjfdlNj7m7YkI3IAwobE 6hYqaKhybard08GGF/EOMDYPUdm6aT0YW6mE9+ILY2yOaHPZQCxMe9AaE7IYuFbYkkkn AM+aX5QmIPfGLdoNcDw3cTUhLmsHfUqNmgAcATItDAUrKm6kbhqrAJNF9uV+V+b2u/iD 8QaE1BNk3BHIA5ldoTh6WiyI+COqFE+s4qE1UOvSHsQJZsGNy//eg+hyizcok2pmE1Ic VjUlAydOrDBH020ESgfC1Ib/fKTRlyOcej/LeGUnbVb5Bnax3AaKtl64+WxM3WSkUcRl f/FQ== MIME-Version: 1.0 X-Received: by 10.66.155.104 with SMTP id vv8mr6508307pab.165.1361428425516; Wed, 20 Feb 2013 22:33:45 -0800 (PST) Received: by 10.66.249.129 with HTTP; Wed, 20 Feb 2013 22:33:45 -0800 (PST) X-Originating-IP: [24.84.235.32] Received: by 10.66.249.129 with HTTP; Wed, 20 Feb 2013 22:33:45 -0800 (PST) In-Reply-To: References: <12CE5BFB-49C5-48D0-96DF-F78F0D60578A@yahoo.com> <1361419333.51990.YahooMailNeo@web125604.mail.ne1.yahoo.com> <4E2B71678D46B212D1553AD2@cyrus.local> Date: Wed, 20 Feb 2013 22:33:45 -0800 Message-ID: From: Tim Bray To: Robert Sayre Content-Type: multipart/alternative; boundary=047d7b86c72cb0a59f04d636416f X-Gm-Message-State: ALoCoQlslX8fA/61zEcHuo7mV+d0X1bCej7EsvJ1mpUL7ejo0XuXrxjeqtB1e8H2bHqNK9S/gK2j Cc: Cyrus Daboo , Francis Galiegue , Vinny A , "Joe Hildebrand \(jhildebr\)" , json@ietf.org Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 06:33:47 -0000 --047d7b86c72cb0a59f04d636416f Content-Type: text/plain; charset=ISO-8859-1 Which was why I was interested in a best-practices spec. Because it's basically crazy, in a network protocol, to issue duplicate keys, whether or not it's legal JSON. Somewhere this should be stated. On Feb 20, 2013 9:15 PM, "Robert Sayre" wrote: > > > > On Wednesday, February 20, 2013, Cyrus Daboo wrote: >> >> Hi Vinny, >> >> --On February 20, 2013 8:02:13 PM -0800 Vinny A wrote: >> >>> I believe org.json throws a exception if it hits a duplicated key; at >>> least the documentation [ >>> http://json.org/javadoc/org/json/JSONObject.html#JSONObject(java.lang.Str >>> ing) ] suggests that to be the case. I don't remember where I saw the >>> append to array parser - but it's such a good idea it's worth bringing up >>> in this conversation. >> >> >> Another data point: Python 2.7.2 - >> >>>>> import json >>>>> print json.loads('{"a":"a", "a":"b"}') >> >> {u'a': u'b'} >> >> So Python will accept duplicate keys, but one value is lost. This makes sense since keys in Python dicts are unique. At this point I favor changing the SHOULD to a MUST in RFC 4627bis to make it clear that there is lack of interoperability here. > > > There is a lack of interoperability, and this issue is one of the smaller points. The larger point is that the JS implementations (and many smaller ones) have no incentive to change their behavior, and what they do is reasonable. Let's just do that. > > - Rob --047d7b86c72cb0a59f04d636416f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Which was why I was interested in a best-practices spec.=A0 = Because it's basically crazy, in a network protocol, to issue duplicate= keys, whether or not it's legal JSON.=A0 Somewhere this should be stat= ed.

On Feb 20, 2013 9:15 PM, "Robert Sayre" <sayrer@gmail.com> wrote:
>
>
>
> On Wednesday, February 20, 2013, Cyrus Daboo wrote:
>>
>> Hi Vinny,
>>
>> --On February 20, 2013 8:02:13 PM -0800 Vinny A <jsontest@yahoo.com> wrote:
>>
>>> I believe org.json throws a exception if it hits a duplicated = key; at
>>> least the documentation [
>>> http://json.org/javadoc/org/json/JSONObject.html#JS= ONObject(java.lang.Str
>>> ing) ] suggests that to be the case. I don't remember wher= e I saw the
>>> append to array parser - but it's such a good idea it'= s worth bringing up
>>> in this conversation.
>>
>>
>> Another data point: Python 2.7.2 -
>>
>>>>> import json
>>>>> print json.loads('{"a":"a", &q= uot;a":"b"}')
>>
>> {u'a': u'b'}
>>
>> So Python will accept duplicate keys, but one value is lost. This = makes sense since keys in Python dicts are unique. At this point I favor ch= anging the SHOULD to a MUST in RFC 4627bis to make it clear that there is l= ack of interoperability here.
>
>
> There is a lack of interoperability, and this issue is one of the smal= ler points. The larger point is that the JS implementations (and many small= er ones)=A0have no incentive to=A0change their behavior, and what they do i= s reasonable. Let's just do that.
>
> - Rob

--047d7b86c72cb0a59f04d636416f-- From sayrer@gmail.com Wed Feb 20 22:46:19 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0116421F8DEE for ; Wed, 20 Feb 2013 22:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crJZS2Q9-mB4 for ; Wed, 20 Feb 2013 22:46:18 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4232021F8DED for ; Wed, 20 Feb 2013 22:46:18 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id 16so7147512wgi.27 for ; Wed, 20 Feb 2013 22:46:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UVR9TBFPfJBO7MG+KsKi4qoTOrVfErQp5FCT0bp3SzI=; b=FD9z7IfJlM4vmzu8Zodjd+T+hdd+mQcEBqdnxWBL2m62m817/BzOVf3jsfMKAOPUIC mHHuzuyOyhPNN84sNeUvLjqLxlBXd6sExnwxAB5Ep1Ql0fHgZQxLOFUZYbupGrOzenFJ DRi/bg7NgPBR0Ne5HXwFaXvGRv6q0rx72PsRIgAty5qYOXRYH+DRQc/1KlfyQ51gVlZt RqjKdCHQ/MuEABfdxms/Jtt10dKe+pTnN3UMNbVdrJMyAsCwhbaKsXqpdb+HR2GWqh6j EFMa/oohqQ72Z0MPlFPiyBPSMVhdVqTdX9jf/Kx1+os+DErNf67qN76Nlac1qMM6oVDh R1Hw== MIME-Version: 1.0 X-Received: by 10.194.5.196 with SMTP id u4mr33803416wju.47.1361429177387; Wed, 20 Feb 2013 22:46:17 -0800 (PST) Received: by 10.194.138.170 with HTTP; Wed, 20 Feb 2013 22:46:17 -0800 (PST) In-Reply-To: References: <12CE5BFB-49C5-48D0-96DF-F78F0D60578A@yahoo.com> <1361419333.51990.YahooMailNeo@web125604.mail.ne1.yahoo.com> <4E2B71678D46B212D1553AD2@cyrus.local> Date: Wed, 20 Feb 2013 22:46:17 -0800 Message-ID: From: Robert Sayre To: Tim Bray Content-Type: text/plain; charset=ISO-8859-1 Cc: Cyrus Daboo , Francis Galiegue , Vinny A , "Joe Hildebrand \(jhildebr\)" , json@ietf.org Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 06:46:19 -0000 On Wed, Feb 20, 2013 at 10:33 PM, Tim Bray wrote: > Which was why I was interested in a best-practices spec. I agree that such a document would be the right place to address the duplicate-key issue. - Rob From paul.hoffman@vpnc.org Thu Feb 21 06:48:08 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960C721F8DE9 for ; Thu, 21 Feb 2013 06:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK1+1TDUTX6L for ; Thu, 21 Feb 2013 06:48:08 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 17D2F21F8CAC for ; Thu, 21 Feb 2013 06:48:08 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1LEm6ZY097187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 21 Feb 2013 07:48:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Thu, 21 Feb 2013 06:48:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <56D1C59D-D6BE-453D-9E0D-A300E9A1AC8A@vpnc.org> References: <12CE5BFB-49C5-48D0-96DF-F78F0D60578A@yahoo.com> <1361419333.51990.YahooMailNeo@web125604.mail.ne1.yahoo.com> <4E2B71678D46B212D1553AD2@cyrus.local> To: "json@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:48:08 -0000 On Feb 20, 2013, at 10:46 PM, Robert Sayre wrote: > On Wed, Feb 20, 2013 at 10:33 PM, Tim Bray = wrote: >> Which was why I was interested in a best-practices spec. >=20 > I agree that such a document would be the right place to address the > duplicate-key issue. If we felt that best-practices RFCs were ever read, I would agree. = They're not, and even when they are, people see "SHOULD" and say "great, = I don't *have* to do that". The standard should be clear and not allow bendy-ness. --Paul Hoffman= From jhildebr@cisco.com Thu Feb 21 11:05:05 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A5D21F8EED for ; Thu, 21 Feb 2013 11:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4PqjDShwhFy for ; Thu, 21 Feb 2013 11:05:04 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D4F3621F8EA1 for ; Thu, 21 Feb 2013 11:05:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=816; q=dns/txt; s=iport; t=1361473505; x=1362683105; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=i0IpV2kDyCRPUw6Xjg8afn1jf91oahIMm/fWq3Qb+A0=; b=NkWYdhLYatiKBNk0fIz4e06C4T+bVUkssZsLGa2uonGQflNLn0rIp/mX 4JHfG1Cd77ycrw1Dr8htWe3naKR1f808JdhdIJ8h7RReCxa3YVTRq/hEy kYwTkWYQ8SKpn3vCppRpgdmexdO6798zztZfFibKkfXZhnnywDHO6difl 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0FANNuJlGtJXG+/2dsb2JhbABFhge7A4EFFnOCIQEEOj8SAQgiFDERJQIEAQ0FCId4Aw+1fQ2JO4w3giYxB4JfYQOUWo0lhRWDB4In X-IronPort-AV: E=Sophos;i="4.84,711,1355097600"; d="scan'208";a="179537814" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 21 Feb 2013 19:05:04 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1LJ54OU017960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Feb 2013 19:05:04 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 13:05:04 -0600 From: "Joe Hildebrand (jhildebr)" To: Robert Sayre , Cyrus Daboo Thread-Topic: [Json] Counterproposal #2 on work items Thread-Index: AQHOD5RjTUz37iGayUSEf11jvGkoDJiDigUAgAAJN4CAAAE8AP//jVSAgAB4awCAAEwcgIAAAmQAgAAtKoCAAAN/AIAAEQOAgAByZAA= Date: Thu, 21 Feb 2013 19:05:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <83BBC4C968BF38408361571F5761CD99@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Vinny A , Tim Bray , Francis Galiegue , "json@ietf.org" Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 19:05:05 -0000 On 2/20/13 10:15 PM, "Robert Sayre" wrote: >There is a lack of interoperability, and this issue is one of the smaller >points. The larger point is that the JS implementations (and many smaller >ones) have no incentive to change their behavior, and what they do is >reasonable. Let's just > do that. How about text like this for section 2.2: "The names within an object SHOULD be unique. Applications and protocols built on top of JSON SHOULD require names within an object to be unique, specifying an error condition when this constraint is broken. However, if multiple instances of a name are allowed by a particular usage of JSON, the value for the last member in the input serialization with the same name MUST be used as the value for that name." --=20 Joe Hildebrand From paul.hoffman@vpnc.org Thu Feb 21 11:14:53 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F79F21F8EF9 for ; Thu, 21 Feb 2013 11:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGr9vAfg6dZH for ; Thu, 21 Feb 2013 11:14:52 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A715D21F8F42 for ; Thu, 21 Feb 2013 11:14:52 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1LJEnfr017514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 21 Feb 2013 12:14:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Thu, 21 Feb 2013 11:14:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "json@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 19:14:53 -0000 On Feb 21, 2013, at 11:05 AM, Joe Hildebrand (jhildebr) = wrote: > On 2/20/13 10:15 PM, "Robert Sayre" wrote: >=20 >> There is a lack of interoperability, and this issue is one of the = smaller >> points. The larger point is that the JS implementations (and many = smaller >> ones) have no incentive to change their behavior, and what they do is >> reasonable. Let's just >> do that. >=20 > How about text like this for section 2.2: Wrong thread. This thread is for "only product a best practices guide". I bring this up because there is a huge difference between: - Changing the requirements in the format specification - Adding new processing rules, but allowing bad-idea data, in the format = document - Not touching the format specification and creating a best practices = guide Further, as we have discovered in many other areas of the IETF, there is = a huge difference between: - A format specification that is unclear on how to process illegal input - A format specification that says processors must reject illegal input - A format specification that says how processors handle = legal-but-bad-idea input --Paul Hoffman= From jhildebr@cisco.com Thu Feb 21 12:40:27 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038C421F8F10 for ; Thu, 21 Feb 2013 12:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.578 X-Spam-Level: X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKarCs+EhKSH for ; Thu, 21 Feb 2013 12:40:26 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1564E21F8688 for ; Thu, 21 Feb 2013 12:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1557; q=dns/txt; s=iport; t=1361479226; x=1362688826; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=tx26CsPzCMgZET34AOf2R+7Cp4fSx2RT0paO+va7JcE=; b=gRRqGCvVA3tkSCjaMVySwUDBf2Jb9jjFqSz7EGglnAOankmSImrZE9HB 80ePoalq5n/mm4xLtQ2aCbES7p1+WmMUoRZeJ0vR+2p42btLIo+AFXl5d pxRMIg9H2AmDhlxuJVOpo1SVXoLDB/vNbbeTA8pXS+105GUvXky1jeMwz M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADKFJlGtJXG+/2dsb2JhbABFwQyBBRZzgh8BAQEEAQEBNzQdAQgYChQxBgslAgQBEgiHeAMPDLVSDYk3BIw3giY4gl9hA5RajSWFFYMHgic X-IronPort-AV: E=Sophos;i="4.84,711,1355097600"; d="scan'208";a="179782648" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 21 Feb 2013 20:40:25 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1LKePdR009013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Feb 2013 20:40:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 14:40:25 -0600 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman , "json@ietf.org" Thread-Topic: [Json] Counterproposal #2 on work items Thread-Index: AQHOD5RjTUz37iGayUSEf11jvGkoDJiDigUAgAAJN4CAAAE8AP//jVSAgAB4awCAAEwcgIAAAmQAgAAtKoCAAAN/AIAAEQOAgAByZACAAHgUgP//oo8A Date: Thu, 21 Feb 2013 20:40:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <9340218280D72F4E9FC930B5FD9EB362@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Counterproposal #2 on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 20:40:27 -0000 Fine, but I'm more interested in an existence proof at this point than the actual language. On 2/21/13 12:14 PM, "Paul Hoffman" wrote: >On Feb 21, 2013, at 11:05 AM, Joe Hildebrand (jhildebr) > wrote: > >> On 2/20/13 10:15 PM, "Robert Sayre" wrote: >>=20 >>> There is a lack of interoperability, and this issue is one of the >>>smaller >>> points. The larger point is that the JS implementations (and many >>>smaller >>> ones) have no incentive to change their behavior, and what they do is >>> reasonable. Let's just >>> do that. >>=20 >> How about text like this for section 2.2: > >Wrong thread. This thread is for "only product a best practices guide". > >I bring this up because there is a huge difference between: >- Changing the requirements in the format specification >- Adding new processing rules, but allowing bad-idea data, in the format >document >- Not touching the format specification and creating a best practices >guide > >Further, as we have discovered in many other areas of the IETF, there is >a huge difference between: >- A format specification that is unclear on how to process illegal input >- A format specification that says processors must reject illegal input >- A format specification that says how processors handle >legal-but-bad-idea input > >--Paul Hoffman >_______________________________________________ >json mailing list >json@ietf.org >https://www.ietf.org/mailman/listinfo/json > --=20 Joe Hildebrand From nico@cryptonector.com Tue Feb 19 12:59:18 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7147E21F8A4F; Tue, 19 Feb 2013 12:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.844 X-Spam-Level: X-Spam-Status: No, score=-3.844 tagged_above=-999 required=5 tests=[AWL=-1.867, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAjWqP2uaCKh; Tue, 19 Feb 2013 12:59:17 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6E65521F8A3F; Tue, 19 Feb 2013 12:59:17 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 4A439678058; Tue, 19 Feb 2013 12:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=MCPVJH1MmHDSGvrkCgbq Nklxv+s=; b=iNnOq4CKkUkrpdg3YWkaxlByFfbeTV3S7dOkCbOAWNeaElXdmAeO JPXSsWpUFN4CB57Daf2a1bCdMf1BoT7DUCo1pnc1BgGsc2DmNSTu7c4rQtWNKE3c TfAQb0eQFId+w0FNm6s9FarMeU8r6sCTRWsMSo8jqFxodFPEKNvwq6Y= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id B858267803E; Tue, 19 Feb 2013 12:59:16 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id o1so5388346wic.17 for ; Tue, 19 Feb 2013 12:59:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.91.106 with SMTP id cd10mr11273471wib.6.1361307554320; Tue, 19 Feb 2013 12:59:14 -0800 (PST) Received: by 10.216.254.217 with HTTP; Tue, 19 Feb 2013 12:59:14 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 14:59:14 -0600 Message-ID: From: Nico Williams To: Mike Jones Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 22 Feb 2013 08:24:43 -0800 Cc: "json@ietf.org" , "apps-discuss@ietf.org" , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 20:59:18 -0000 On Tue, Feb 19, 2013 at 2:47 PM, Mike Jones wrote: > I'm strongly against canonicalization. The XML canonicalization experience was horrible and resulted in more interop bugs than any other aspect of XML DSIG, XML ENC, etc. Let's not repeat the mistakes of our elders. ;-) > > I also haven't seen a clear use case that canonicalization solves that can't be more easily solved another way. But what were the mistakes? Is canonicalization in and of itself a mistake? Or were the mistakes about how to do it? I personally think that standards should avoid having to canonicalize JSON (and XML) wherever possible. The simplest way to do this is never re-encode in the process of validating signatures, for example. However, I'm not sure that we can always avoid canonicalization, or that even if we can it has no value; I could be convinced. Nico -- From sayrer@gmail.com Tue Feb 19 22:41:29 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5EC21F8949 for ; Tue, 19 Feb 2013 22:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcjYWo02CqH6 for ; Tue, 19 Feb 2013 22:41:28 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id CCBF121F8947 for ; Tue, 19 Feb 2013 22:41:27 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id o1so5767341wic.17 for ; Tue, 19 Feb 2013 22:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=nrm74NBYA3j38Qr9QaVUfIrZoQcKZQtCthm36l6Bf8g=; b=Y7KeOToJNZoVyKqpporPBuuJAWlC7qJfC8SQuK3+iwKW0ehASEOpQu9j8NndwvEstW HsEn7coaR4gSbNvCNFtvbhsZ/HGrNQxgha3Ovq/arIu1IcEJXcosKxR4ely7eeZchFLt wARFxgT/Kz3mL1bMdR+Wpmf5KLGBGVVyr1DDHK5eYHIgYgg8o346msPJWRPA9QPiMKhI Ub1LwmaXVsHFL8u+r6hx3tun5wkDgo8VEqJkNJOQSnimOS1wgwTX8S7skK+3Qp/cVK4X HjAfhgpBtH/jB0DJ/xoesqfFaLWf/rlR/aX95n8F0EtN/rP2sk+5T61pByuK7l8Xmlrb X4jA== MIME-Version: 1.0 X-Received: by 10.194.108.229 with SMTP id hn5mr31405659wjb.8.1361342487037; Tue, 19 Feb 2013 22:41:27 -0800 (PST) Received: by 10.194.138.170 with HTTP; Tue, 19 Feb 2013 22:41:26 -0800 (PST) Date: Tue, 19 Feb 2013 22:41:26 -0800 Message-ID: From: R S To: json@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 22 Feb 2013 08:24:43 -0800 Subject: Re: [Json] Proposed document set from this WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 06:41:29 -0000 Paul Hoffman wrote: > 1) JSON base, 4627bis > Target: current JSON users > Current: grammar, encoding, parser rules, generator rules, MIME type re= gistration) > New: Internet transfer rules, list of changes from 4627 My suggestion is for the WG to target this use case only, and to treat the JSON processing rules in ECMAScript 5, Section 15.12 (The JSON Object) as the baseline for rules regarding encoding and decoding, rather than RFC4627. The motivation for this recommendation is that it's impractical to change this algorithm on a reasonable time scale, and JSON RFC readers will expect to interoperate with web browsers and other JavaScript embeddings. The most significant delta concerns this line from RFC4627: > A JSON parser MAY accept non-JSON forms or extensions. ES5 parsers must raise an error when they encounter deviations from the grammar defined in ES5: "It is not permitted for a conforming implementation of JSON.parse to extend the JSON grammars." Tim Bray wrote: > \uxxxx is only allowed for chars that must be escaped per the JSON spec > \uxxxx is freely allowed, but the \uxxxx is considered to represent a sin= gle codepoint, and all comparison/hashing > operations have to be conducted codepoint-by-codepoint ES5 mandates \uxxxx for certain control characters and allows it for all (so does RFC4627 "Any character may be escaped."). JavaScript strings are composed of code units. Consider JSONKit's behavior when serializing escaped Unicode: "When JKSerializeOptionEscapeUnicode is enabled, JSONKit will encode Unicode code points that can be encoded as a single UTF16 code unit as \uXXXX, and will encode Unicode code points that require UTF16 surrogate pairs as \uhigh\ulow." json =E2=8A=84 js: > The problem comes down to two unicode characters that are considered line= terminators > in JavaScript: the line separator \u2028 and the paragraph separator \u20= 29. Recommend that encoders escape these characters. Paul Hoffman wrote: > If we are supposed to be keeping backwards compatibility, then yes, it's = too late. > The same is true for changing SHOULD not have duplicate names in objects. ES5 mandates behavior here: "In the case where there are duplicate name Strings within an object, lexically preceding values for the same key shall be overwritten." - Rob From cabo@tzi.org Sun Feb 24 05:11:29 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B20A21F8FFA; Sun, 24 Feb 2013 05:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.237 X-Spam-Level: X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbWoEu1jJfeN; Sun, 24 Feb 2013 05:11:22 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF5721F8FF7; Sun, 24 Feb 2013 05:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r1ODB9Z9020863; Sun, 24 Feb 2013 14:11:09 +0100 (CET) Received: from [192.168.217.135] (p54893FCD.dip.t-dialin.net [84.137.63.205]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8D9AE3156; Sun, 24 Feb 2013 14:11:08 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <7EB82E7A-F664-46F8-8137-83DF0C3F5536@tzi.org> Date: Sun, 24 Feb 2013 14:11:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85CB7BA1-2C92-4C52-A1C3-7FD430396725@tzi.org> References: <7EB82E7A-F664-46F8-8137-83DF0C3F5536@tzi.org> To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: [Json] msgpack/binarypack (Re: [apps-discuss] JSON mailing list and BoF) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 13:11:29 -0000 On Feb 19, 2013, at 17:39, Carsten Bormann wrote: > On Feb 19, 2013, at 00:47, "Joe Hildebrand (jhildebr)" = wrote: >=20 >> As an individual, I'm +1 on that. I love msgpack, and don't mind the >> addition of UTF8 as a separate type. Was frsyuki involved in the = draft, >> or at least know that it happened? >=20 > I tried to involve him. Well, I did engage the msgpack community some more. You can find a transcript of some 275 messages about separating byte and = UTF-8 strings at: https://github.com/msgpack/msgpack/issues/121 Summary: Some members of the msgpack community are very enraged that this change = hasn't happened earlier. Of course, some have gone off and done their own incompatible forks. Others are very enraged that any change is happening at all, and that = new people are intruding on their turf. (And some probably feel guilty that it took a ****storm from outside to = finally make this change.) frsyuki is now working on a proposal that solves the problem: https://gist.github.com/frsyuki/5022569 The proposal is technically complete (and has already been implemented). It already is pretty good at the details, too, but this whole thing is = being done in a process that is closer to Japanese consensus processes = than to IETF culture. My -01 will be fully aligned with whatever the state of frsyuki's = proposal will be on Monday's I-D deadline (find today's snapshot at = http://www.tzi.de/~cabo/draft-bormann-apparea-bpack-01pre2.txt). (frsyuki's proposal may change some more, but those will in all = likelihood be minor details.) I think his overall thinking is fine, but it is much more dominated by a = requirement for backwards compatibility than an IETF process would be. So, the larger question on whether the msgpack community is ready to = take part (or just endure) in an IETF-style consensus process (including = handing over change control) still looms. That doesn't diminish from the requirement for a msgpack-like format, = and I think we should use Hallway Time in Orlando to discuss potential = ways forward. I any case, I definitely don't want to disturb the constructive = discussion about chartering a very narrow JSON fixup WG with this work. (I do want to find a home for it, soon, though: I want to build other = specs on top of it.) Gr=FC=DFe, Carsten From paulej@packetizer.com Wed Feb 27 08:44:57 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B24821F8667 for ; Wed, 27 Feb 2013 08:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgvlFo+8xxHW for ; Wed, 27 Feb 2013 08:44:56 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7628C21F862B for ; Wed, 27 Feb 2013 08:44:47 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r1RGikkC010091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Feb 2013 11:44:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1361983486; bh=bFe3O+Chk6qMWejUNvENuNqJjTq6k+iLi4ZMRmXLDnU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=HSn6ddAXpX8J5odBIJZBfh3HbbPIWeXdLeAtFtGiMLhhOtQFcykdYBGcIy1hxM7XN ewrAj01oY3rfrdPiZFXDUbUFceDnKHi09oYLBP2O7wjqb6nZnH+qcdMneCyIr+I0Lj p7Xs3yrDBxdZ8fsN0IhQyu3kNIZwnQFSlE71iWwg= From: "Paul E. Jones" To: "'Mark Nottingham'" , "'Paul Hoffman'" References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> In-Reply-To: <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> Date: Wed, 27 Feb 2013 11:44:53 -0500 Message-ID: <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJmlHHeuQsFbaCuWES9MqWLBpmfyQGang29AdmZMiIDQRCvmgOfBT/QlwpHjDA= Content-Language: en-us Cc: json@ietf.org Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:44:57 -0000 Mark, > I don't know. I think I'd be fine if we just asked Crockford (perhaps > helped by a willing editor) to do 4627bis and then have the AD sponsor > it on Standards Track. I did ask him. I actually asked him about updating it even before I had heard about the JSON BoF. He indicated that he is willing to work on it "as long as it does not break compatibility with existing implementations." As editor, I think he would be in a good position to ensure that his requirement is met. Paul From barryleiba.mailing.lists@gmail.com Wed Feb 27 10:15:24 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E6121F886B for ; Wed, 27 Feb 2013 10:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjqWhGFhwpoO for ; Wed, 27 Feb 2013 10:15:24 -0800 (PST) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0128621F881A for ; Wed, 27 Feb 2013 10:15:23 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id d10so892897vea.40 for ; Wed, 27 Feb 2013 10:15:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Fiyq6ql6gJNPCt7ZAmjnW/zY55rWIL5f2oL7nbykoOI=; b=KpzhXjf23FKnUnS4/1iPJR32Yj1ndr9XZRU2RFFWUDGniMI9HZLuy5ulyeZVaPB6wc X1jNtm8oD2w8KlSmgxRpkuU1Pvs6+7VylCNpRbChpNtZT5fS7lw7YKFzdwGIS0yx6iwu jwnhEDwojt6JwpZI18Ps3PMjSmBuLeG+U4/PMbVxow+mODLivSlcfjyLZA6yUs943KjL AlFDDb7xbUoKTrJsrqfS1ux1pvaRhwNmIjGdG7gNHOqN48VcM6XCzoq+tD5J2/RHAuL6 NyhIaF9YeOlVxBytfUzr93NYtjgv1524n13zdoTuK6czeX6Pzj40kK+EQ5ELNuFT9q5m Mbvg== MIME-Version: 1.0 X-Received: by 10.58.117.229 with SMTP id kh5mr1308731veb.27.1361988920596; Wed, 27 Feb 2013 10:15:20 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Wed, 27 Feb 2013 10:15:20 -0800 (PST) In-Reply-To: <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> Date: Wed, 27 Feb 2013 13:15:20 -0500 X-Google-Sender-Auth: c8wghMk6W9nt2iq6ZE9ubDjVRkE Message-ID: From: Barry Leiba To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Cc: Mark Nottingham , Paul Hoffman , json@ietf.org Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:15:24 -0000 >> I don't know. I think I'd be fine if we just asked Crockford (perhaps >> helped by a willing editor) to do 4627bis and then have the AD sponsor >> it on Standards Track. > > I did ask him. I actually asked him about updating it even before I had > heard about the JSON BoF. He indicated that he is willing to work on it "as > long as it does not break compatibility with existing implementations." > > As editor, I think he would be in a good position to ensure that his > requirement is met. Indeed; I had talked with him back in August, as well, with the same response. And as the likely responsible AD for any WG that forms, I can say that I strongly agree with the "doesn't break compatibility" point. My view is that the charter has to make it clear that the "4627 to Standards Track" work is essentially a re-classification in place, rolling in errata and clarifications, but *not* changing the language. Any proposals that actually make changes would have to come later, and be considered as separate work proposals. Barry, Applications AD From fgaliegue@gmail.com Wed Feb 27 10:21:21 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D3621F8947 for ; Wed, 27 Feb 2013 10:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pj7htWaElywG for ; Wed, 27 Feb 2013 10:21:20 -0800 (PST) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id BC39521F8942 for ; Wed, 27 Feb 2013 10:21:19 -0800 (PST) Received: by mail-ee0-f45.google.com with SMTP id b57so793883eek.32 for ; Wed, 27 Feb 2013 10:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lveRsT/LrQpCKwEHbWFTyt+SkKeJpz3HBGKwtG+oKo4=; b=CU2DJv6QPysB4bRAOqjj0Gn6jGenCvgLS+5ZcFWRbV2M3ulIExqUMq+eoqJLWIZPRq /MUAdDpTb+BS4u0zAelew8ve5QxcIseuWdtR5XdNyekH+B1Q0mEtbraor0zxriEvK+sA vk2FAVdpqijbYp2cniy3rfjwHhpE0IKIkEnxFRB8xeW473RE0nQHKT/mrSQfI3axerSb m7wIVL3hLd2CHdqI5BXHJ5uO1PwU15ZZkgJD4rs9HqRNfQ+6qUX4L7Gtxvtjn5bmoSld ntVxAt+iikQR8d0LNA0t7r4yMMJFi6U1P03uWaDzMN5gsNkBehS6u6jSSPPN9TYLhINp R1uA== MIME-Version: 1.0 X-Received: by 10.14.194.198 with SMTP id m46mr8507764een.8.1361989278471; Wed, 27 Feb 2013 10:21:18 -0800 (PST) Received: by 10.14.1.7 with HTTP; Wed, 27 Feb 2013 10:21:18 -0800 (PST) In-Reply-To: References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> Date: Wed, 27 Feb 2013 19:21:18 +0100 Message-ID: From: Francis Galiegue To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Cc: "Paul E. Jones" , Mark Nottingham , Paul Hoffman , json@ietf.org Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:21:21 -0000 On Wed, Feb 27, 2013 at 7:15 PM, Barry Leiba wrote: [...] > > Indeed; I had talked with him back in August, as well, with the same > response. And as the likely responsible AD for any WG that forms, I > can say that I strongly agree with the "doesn't break compatibility" > point. > Which means there will always be the sour point of specs like JSON Patch having to specify that an operation must have one and only one member named "op". Because "doesn't break compatibility" means the "no duplicate member names" will remain a SHOULD, right? I personally hate this wording in JSON Patch because it doesn't really impose constraints on the format of JSON Patch itself, it also imposes constraints on _parsers_. And this is a problem. Many parsers will just _not_ yell on duplicate member names, and RFC 4627 currently allows them to do so. Just my 2e-42 cents, -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From stpeter@stpeter.im Wed Feb 27 10:29:43 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3125F21F890E for ; Wed, 27 Feb 2013 10:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+Xv0MKdZRVh for ; Wed, 27 Feb 2013 10:29:42 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E83C521F88EE for ; Wed, 27 Feb 2013 10:29:41 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0F52E4060C; Wed, 27 Feb 2013 11:37:31 -0700 (MST) Message-ID: <512E5090.4000103@stpeter.im> Date: Wed, 27 Feb 2013 11:29:36 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Barry Leiba References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , Mark Nottingham , Paul Hoffman , json@ietf.org Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:29:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/27/13 11:15 AM, Barry Leiba wrote: >>> I don't know. I think I'd be fine if we just asked Crockford >>> (perhaps helped by a willing editor) to do 4627bis and then >>> have the AD sponsor it on Standards Track. >> >> I did ask him. I actually asked him about updating it even >> before I had heard about the JSON BoF. He indicated that he is >> willing to work on it "as long as it does not break compatibility >> with existing implementations." >> >> As editor, I think he would be in a good position to ensure that >> his requirement is met. > > Indeed; I had talked with him back in August, as well, with the > same response. And as the likely responsible AD for any WG that > forms, I can say that I strongly agree with the "doesn't break > compatibility" point. My view is that the charter has to make it > clear that the "4627 to Standards Track" work is essentially a > re-classification in place, rolling in errata and clarifications, > but *not* changing the language. Any proposals that actually make > changes would have to come later, and be considered as separate > work proposals. +1 for sure. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRLlCQAAoJEOoGpJErxa2p5yoP/Ryh7xXS6Cl9rdKyRYvZjBKR HSb6Aalaqa6njHWMrx2ESfwVMdFiQtf1RnftWEh88OkpIAx4hTTjQgAN4HQwuvLx mOjWrFanxjkJEfDLl4MgHFe/+EfdLQ9TG9MEEqtWv6vnKI6xpv4mij/FsrNkEOQK EYOe0bMZzyjdzZr7VUDdyna295EfqwdfWlK3l0h4tFJqjN83d2JRp/Nsrrn3HHc+ ZiKVErozznZtdag7MWkpLi7pdqjnRJAaWxBogdetjQ/c9kivuaNvLWG5TMDNmfse Pi7lTNAg7v7ip3c21vtOW0PWd/BMSD1lyNIW9TS/GnFh/CBvB8h4bDpwQf68rGY+ 8jCBX0U9wUJiAYYfOussGrzu7nOdIi1p0SyhmgonxnzWqrTp6ihrkN7Y+/Q+dt58 Ha6R54H2YAnw9WyQvLQb/QI2vo1iZ64ll05f6e3A7+Ii7g8FAgv8CWdFFDWjibLZ GhcwnhlLwrexrwoNVjdQUGBo8kPGJVZHc9K69oNb1i4FGUWknDU/zzppnr57rYlr 0k7JD64FNdJvqW+k1y2pcU5AUlH4qoE081Yt6lruBbI1A6G4B9qZVkSxyUq9UE/d yqMOQAx/t+6a6PNny1LWu9Z0po+3rHALfxORX/tj79B1wemvmBe8WaSumpf5Yvkt nyRLFbjKJp1woGLsTJKQ =ToYm -----END PGP SIGNATURE----- From paulej@packetizer.com Wed Feb 27 10:40:38 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16FF21F88E1 for ; Wed, 27 Feb 2013 10:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBSN7NYoZf6p for ; Wed, 27 Feb 2013 10:40:38 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC5E21F88BE for ; Wed, 27 Feb 2013 10:40:38 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r1RIeWvP016545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Feb 2013 13:40:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1361990433; bh=EuV4G+douZwFshWyRx68+iqZQ7l0U75U0aCsNlUMB24=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=YyZlUOm8sMpYzK0/+WPy2DGI+g3EDWDT5Dirg6EFCUhxW24AsfqLst5VzkAx2yHLR LgwRMCCZHfl+1uCiBfoDxqk+dCxPcT3pnXp+ApOoqKg38zgV7VIaygQG+KwmiW0n8+ xB+Aa7ltJvk3YKH3dqa504GLYXLyHnEppwxSxFXY= From: "Paul E. Jones" To: "'Francis Galiegue'" , "'Barry Leiba'" References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> In-Reply-To: Date: Wed, 27 Feb 2013 13:40:40 -0500 Message-ID: <012801ce1519$f146fc90$d3d4f5b0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJmlHHeuQsFbaCuWES9MqWLBpmfyQGang29AdmZMiIDQRCvmgOfBT/QAkARRrECJlceGAJMhm1fltTQ8XA= Content-Language: en-us Cc: 'Mark Nottingham' , 'Paul Hoffman' , json@ietf.org Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:40:38 -0000 > Which means there will always be the sour point of specs like JSON Patch > having to specify that an operation must have one and only one member > named "op". Because "doesn't break compatibility" means the "no > duplicate member names" will remain a SHOULD, right? If you want more than one member named "op", why not just use an array? Paul From fgaliegue@gmail.com Wed Feb 27 10:45:30 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F01521F89C3 for ; Wed, 27 Feb 2013 10:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XiTGXmkHZOG for ; Wed, 27 Feb 2013 10:45:28 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DAC1D21F89A6 for ; Wed, 27 Feb 2013 10:45:27 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id l10so813257eei.3 for ; Wed, 27 Feb 2013 10:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=j9BuRUkz2lCTGnDa33mA7yrn5m7XzYOLBEaPG9Pf9cY=; b=nrIJdNl5FVwlnzJ3wLMl2S5NeAcGdXd0RZw8p1Y98gjf+LtQyEM4BwHO4Nvh589jU8 5fC+c3aSJbSRir0z8wapA7hNVAbtDPPj3Pzv8FPBPK2Jf+EHiqY/HowJMdZ/qhquvkzp zMrw6zs3Ibz9c+cUu+REr3qUcsDFqWPePg+q2WO0MZb0rG3CD2jD/WAtUyck/9ZvtTla TWXsIdcYmm2LXrekaFMlP6esTQOIxdpYcTqj2CYxBcAyPOJ52tKRmx+K1loOMZum/pyF H2uAvMTNWX0P0GCaiUaRlLYENcv3TNDc7bNhDBQ5jipund17lNp9jbcA/nT2zpiRAPGS F3Qw== MIME-Version: 1.0 X-Received: by 10.14.205.68 with SMTP id i44mr8590098eeo.25.1361990727119; Wed, 27 Feb 2013 10:45:27 -0800 (PST) Received: by 10.14.1.7 with HTTP; Wed, 27 Feb 2013 10:45:27 -0800 (PST) In-Reply-To: <012801ce1519$f146fc90$d3d4f5b0$@packetizer.com> References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> <012801ce1519$f146fc90$d3d4f5b0$@packetizer.com> Date: Wed, 27 Feb 2013 19:45:27 +0100 Message-ID: From: Francis Galiegue To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Cc: Mark Nottingham , Barry Leiba , Paul Hoffman , json@ietf.org Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:45:30 -0000 On Wed, Feb 27, 2013 at 7:40 PM, Paul E. Jones wrote: >> Which means there will always be the sour point of specs like JSON Patch >> having to specify that an operation must have one and only one member >> named "op". Because "doesn't break compatibility" means the "no >> duplicate member names" will remain a SHOULD, right? > > If you want more than one member named "op", why not just use an array? > That is not the problem here. The problem is that one JSON Patch operation is an object, and this object must have a member named "op", so far so good. BUT due to RFC 4627 being lax here, the draft says that there should be "one and only one member" by that name. It should not have to say that. RFC 4627 should make duplicate member names outright illegal. Well, not 4627, but whatever will supersede/complement it. -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From cabo@tzi.org Wed Feb 27 10:45:44 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9FE21F8A0C for ; Wed, 27 Feb 2013 10:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.157 X-Spam-Level: X-Spam-Status: No, score=-106.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIXlemxBjAsU for ; Wed, 27 Feb 2013 10:45:43 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4A64E21F89CE for ; Wed, 27 Feb 2013 10:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r1RIjTcF022814; Wed, 27 Feb 2013 19:45:29 +0100 (CET) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AD9CC3787; Wed, 27 Feb 2013 19:45:29 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 27 Feb 2013 19:45:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8D4A1C4F-F3A6-4DB6-8F96-039A3E665755@tzi.org> References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> To: Barry Leiba X-Mailer: Apple Mail (2.1499) Cc: json@ietf.org Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:45:44 -0000 On Feb 27, 2013, at 19:15, Barry Leiba wrote: > doesn't break compatibility Being embroiled in a similar discussion right now in a different place, = I'd sure like to know what that means: -- we can't change anything substantive at all; -- we're not going to extend it (I sure hope that is consensus); -- we can't take out things that shouldn't be in there (UTF-32, = anyone?); -- we can't clarify ambiguities because there are implementations that = solve them either way (duplicate keys?); -- we can't do often-asked-for things like allow numbers on top (well, = that is not quite consensus, maybe). Gr=FC=DFe, Carsten From fgaliegue@gmail.com Wed Feb 27 10:49:08 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7025F21F88B0 for ; Wed, 27 Feb 2013 10:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPgoFFQtVsxF for ; Wed, 27 Feb 2013 10:49:07 -0800 (PST) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1B75421F8887 for ; Wed, 27 Feb 2013 10:49:06 -0800 (PST) Received: by mail-ee0-f52.google.com with SMTP id b15so780166eek.11 for ; Wed, 27 Feb 2013 10:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qVj/oH9OtQWQv3Yv+o9VNDoQgm5cpbgRSzOqOOSPSFI=; b=ZfWM+NAA1r7BGvn2rccibIqwYJDv8Xbo0aTGuBDINSIhiMXp8ZxZp4JFG8z4yqWcxO rCJl1f1qw8dKCdZET/Ckm5aSlx7E7lZwY9kpmKQGQFHiY3v1aWRbOx3segWTwUalj8CE 8l2LsSzSX54vVunUOLzbufk4TTpQ1yxGLiSzmyS1VuhSRfl9gM8m8jAGQ8I+xx88QBSv 5/zhMhEFAUvbvsy+oTE0g+G3Sr9F38DkX9vMXC9Wb2nvgEn46IgWXiRpXjSBHzxHZTpk Z6PZN6N7YjV7I+hJ/JBgPcGCkEZABE8yjJNuzKhDify3cDiLigZBK3KCxxIO501utrdY 0C8g== MIME-Version: 1.0 X-Received: by 10.14.183.198 with SMTP id q46mr8830521eem.1.1361990946267; Wed, 27 Feb 2013 10:49:06 -0800 (PST) Received: by 10.14.1.7 with HTTP; Wed, 27 Feb 2013 10:49:06 -0800 (PST) In-Reply-To: References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> <012801ce1519$f146fc90$d3d4f5b0$@packetizer.com> Date: Wed, 27 Feb 2013 19:49:06 +0100 Message-ID: From: Francis Galiegue To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Cc: Mark Nottingham , Barry Leiba , Paul Hoffman , json@ietf.org Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:49:08 -0000 On Wed, Feb 27, 2013 at 7:45 PM, Francis Galiegue wrote: [...] > > BUT due to RFC 4627 being lax here, the draft says that there should > be "one and only one member" by that name. It should not have to say > that. > And, I'll repeat myself, it especially should not (have to) say that since it imposes constraints on the parser. Which means it tramples on RFC 4627 territory. And that is not a good thing. -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From markus.lanthaler@gmx.net Wed Feb 27 12:24:27 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCCD21F8530 for ; Wed, 27 Feb 2013 12:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1lYLwQwI4WS for ; Wed, 27 Feb 2013 12:24:25 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD7821F87BA for ; Wed, 27 Feb 2013 12:24:22 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.32]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MXTY0-1UMGNa2m3C-00WZRB for ; Wed, 27 Feb 2013 21:24:16 +0100 Received: (qmail invoked by alias); 27 Feb 2013 20:24:16 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp032) with SMTP; 27 Feb 2013 21:24:16 +0100 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX19snQViD15smSw8REEXE9TljT5BPKqjry8DSqinQ3 B0ZphUklYOgSmP From: "Markus Lanthaler" To: References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> <512E5090.4000103@stpeter.im> In-Reply-To: <512E5090.4000103@stpeter.im> Date: Wed, 27 Feb 2013 21:24:11 +0100 Message-ID: <014601ce1528$68061fb0$38125f10$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4VGGsRGQcCEdv6Tg6TUVLmhZP/IgAD97Tg Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Counterproposal on work items X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:24:27 -0000 On Wednesday, February 27, 2013 7:30 PM, Peter Saint-Andre wrote: > On 2/27/13 11:15 AM, Barry Leiba wrote: > >>> I don't know. I think I'd be fine if we just asked Crockford > >>> (perhaps helped by a willing editor) to do 4627bis and then > >>> have the AD sponsor it on Standards Track. > >> > >> I did ask him. I actually asked him about updating it even > >> before I had heard about the JSON BoF. He indicated that he is > >> willing to work on it "as long as it does not break compatibility > >> with existing implementations." > >> > >> As editor, I think he would be in a good position to ensure that > >> his requirement is met. > > > > Indeed; I had talked with him back in August, as well, with the > > same response. And as the likely responsible AD for any WG that > > forms, I can say that I strongly agree with the "doesn't break > > compatibility" point. My view is that the charter has to make it > > clear that the "4627 to Standards Track" work is essentially a > > re-classification in place, rolling in errata and clarifications, > > but *not* changing the language. Any proposals that actually make > > changes would have to come later, and be considered as separate > > work proposals. > > +1 for sure. Huge +1 -- Markus Lanthaler @markuslanthaler From paul.hoffman@vpnc.org Thu Feb 28 11:46:07 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F36621F8749 for ; Thu, 28 Feb 2013 11:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.69 X-Spam-Level: X-Spam-Status: No, score=-102.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5rg1C3TmNUb for ; Thu, 28 Feb 2013 11:46:07 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F16B221F8765 for ; Thu, 28 Feb 2013 11:46:06 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1SJk2SU028777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Feb 2013 12:46:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Thu, 28 Feb 2013 11:46:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <63519CDF-144F-4DA4-A9F3-A1AB824861D2@vpnc.org> References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> To: Barry Leiba X-Mailer: Apple Mail (2.1499) Cc: json@ietf.org Subject: [Json] What does "break compatibility" mean? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 19:46:07 -0000 On Feb 27, 2013, at 10:15 AM, Barry Leiba = wrote: >>> I don't know. I think I'd be fine if we just asked Crockford = (perhaps >>> helped by a willing editor) to do 4627bis and then have the AD = sponsor >>> it on Standards Track. >>=20 >> I did ask him. I actually asked him about updating it even before I = had >> heard about the JSON BoF. He indicated that he is willing to work on = it "as >> long as it does not break compatibility with existing = implementations." >>=20 >> As editor, I think he would be in a good position to ensure that his >> requirement is met. >=20 > Indeed; I had talked with him back in August, as well, with the same > response. And as the likely responsible AD for any WG that forms, I > can say that I strongly agree with the "doesn't break compatibility" > point. =20 As we discussed, RFC 4627 says "The names within an object SHOULD be = unique." So, what does "break compatibility" mean for this specific = issue? If we make the SHOULD a MUST, there are emitters that will become = incompatible. If change the sentence to follow the ECMAScript spec ("In = the case where there are duplicate name Strings within an object, = lexically preceding values for the same key shall be overwritten."), = there are parsers that will become incompatible.=20 > My view is that the charter has to make it clear that the > "4627 to Standards Track" work is essentially a re-classification in > place, rolling in errata and clarifications, but *not* changing the > language. =20 Is the ECMAScript text a clarification or a change? > Any proposals that actually make changes would have to come > later, and be considered as separate work proposals. That certainly sounds reasonable. The question is whether you will allow = clarifications that might make something incompatible. --Paul Hoffman= From tbray@textuality.com Thu Feb 28 12:06:08 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C6121F87B9 for ; Thu, 28 Feb 2013 12:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJj0Y-WQXn1v for ; Thu, 28 Feb 2013 12:06:07 -0800 (PST) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 046DD21F87A4 for ; Thu, 28 Feb 2013 12:06:06 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id b10so2261508vea.30 for ; Thu, 28 Feb 2013 12:06:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=EoaMKxEYR06B7NGdf+3r3k6iWDdzeBslgf8lZ4sAU3s=; b=AekqAxykLDnh7FpZF/nmDq6Bgy8Nhes/7SyqoYQj0HR60w23QFzjl8WhE8vtHcYAiT h7hbcb0iXkOBbpfm41m70svSSzB4+7AOiPRAk2vNQHyiZu5A7M8Sl8+JMKZyqWgOpzMw 0w2vHsEaLbrv+dal0n1MT0550myOoR06kqNfsgfGynfoc5o2+frX4jBqMCCLPjOO0+aK lmqiKbS9TadXzB8YTnjNJHkFyaDWaQp7l09sILojRQbsfM6lZwiH4IpeKr2TIiRVfgou CDldpMW/rECc4tXWMFbdokVn8r9my1+IO36pO/EZi6FNIEOGJZkSnj3DZKNn9vgO7SC/ /EGw== MIME-Version: 1.0 X-Received: by 10.58.155.99 with SMTP id vv3mr3049533veb.50.1362081966372; Thu, 28 Feb 2013 12:06:06 -0800 (PST) Received: by 10.220.167.10 with HTTP; Thu, 28 Feb 2013 12:06:06 -0800 (PST) X-Originating-IP: [209.121.225.209] Received: by 10.220.167.10 with HTTP; Thu, 28 Feb 2013 12:06:06 -0800 (PST) In-Reply-To: <63519CDF-144F-4DA4-A9F3-A1AB824861D2@vpnc.org> References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> <63519CDF-144F-4DA4-A9F3-A1AB824861D2@vpnc.org> Date: Thu, 28 Feb 2013 12:06:06 -0800 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b67002dc307dc04d6ce6ba1 X-Gm-Message-State: ALoCoQmKW3iIdy+4TGczNiCG+2mA2FShD8mvol+fuvAMmRgBA9grg5PYyLHDFmX+Sj4h8rPtdmZw Cc: Barry Leiba , json@ietf.org Subject: Re: [Json] What does "break compatibility" mean? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 20:06:08 -0000 --047d7b67002dc307dc04d6ce6ba1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It=92s clear to me that, *for the purposes of the IETF*, someone needs to s= ay =93People sending JSON MUST NOT use duplicate keys.=94 The fact that certa= in libraries allow less-clueful developers to do this, and that parsing software is observed to behave unpredictably when they do, should only encourage us. -T On Feb 27, 2013, at 10:15 AM, Barry Leiba wrote: >>> I don't know. I think I'd be fine if we just asked Crockford (perhaps >>> helped by a willing editor) to do 4627bis and then have the AD sponsor >>> it on Standards Track. >> >> I did ask him. I actually asked him about updating it even before I had >> heard about the JSON BoF. He indicated that he is willing to work on it "as >> long as it does not break compatibility with existing implementations." >> >> As editor, I think he would be in a good position to ensure that his >> requirement is met. > > Indeed; I had talked with him back in August, as well, with the same > response. And as the likely responsible AD for any WG that forms, I > can say that I strongly agree with the "doesn't break compatibility" > point. As we discussed, RFC 4627 says "The names within an object SHOULD be unique." So, what does "break compatibility" mean for this specific issue? If we make the SHOULD a MUST, there are emitters that will become incompatible. If change the sentence to follow the ECMAScript spec ("In the case where there are duplicate name Strings within an object, lexically preceding values for the same key shall be overwritten."), there are parsers that will become incompatible. > My view is that the charter has to make it clear that the > "4627 to Standards Track" work is essentially a re-classification in > place, rolling in errata and clarifications, but *not* changing the > language. Is the ECMAScript text a clarification or a change? > Any proposals that actually make changes would have to come > later, and be considered as separate work proposals. That certainly sounds reasonable. The question is whether you will allow clarifications that might make something incompatible. --Paul Hoffman _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json --047d7b67002dc307dc04d6ce6ba1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

It=92s clear to me that, *for the purposes of the IETF*, som= eone needs to say =93People sending JSON MUST NOT use duplicate keys.=94=A0= The fact that certain libraries allow less-clueful developers to do this, = and that parsing software is observed to behave unpredictably when they do,= should only encourage us.
-T

On Feb 27, 2013, at 10:15 AM,= Barry Leiba <barryleiba@comp= uter.org> wrote:

>>> I don't know. I think I'd be fine if we just asked Cro= ckford (perhaps
>>> helped by a willing editor) to do 4627bis and then have the AD= sponsor
>>> it on Standards Track.
>>
>> I did ask him. =A0I actually asked him about updating it even befo= re I had
>> heard about the JSON BoF. =A0He indicated that he is willing to wo= rk on it "as
>> long as it does not break compatibility with existing implementati= ons."
>>
>> As editor, I think he would be in a good position to ensure that h= is
>> requirement is met.
>
> Indeed; I had talked with him back in August, as well, with the same > response. =A0And as the likely responsible AD for any WG that forms, I=
> can say that I strongly agree with the "doesn't break compati= bility"
> point.

As we discussed, RFC 4627 says "The names within an object SHOULD be u= nique." So, what does "break compatibility" mean for this sp= ecific issue? If we make the SHOULD a MUST, there are emitters that will be= come incompatible. If change the sentence to follow the ECMAScript spec (&q= uot;In the case where there are duplicate name Strings within an object, le= xically preceding values for the same key shall be overwritten."), the= re are parsers that will become incompatible.

> My view is that the charter has to make it clear that the
> "4627 to Standards Track" work is essentially a re-classific= ation in
> place, rolling in errata and clarifications, but *not* changing the > language.

Is the ECMAScript text a clarification or a change?

> Any proposals that actually make changes would have to come
> later, and be considered as separate work proposals.

That certainly sounds reasonable. The question is whether you will allow cl= arifications that might make something incompatible.

--Paul Hoffman
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json
--047d7b67002dc307dc04d6ce6ba1-- From paul.hoffman@vpnc.org Thu Feb 28 12:43:20 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7010B21F8976 for ; Thu, 28 Feb 2013 12:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.688 X-Spam-Level: X-Spam-Status: No, score=-102.688 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6I6kE13rsv8A for ; Thu, 28 Feb 2013 12:43:20 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 06EA021F8922 for ; Thu, 28 Feb 2013 12:43:19 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1SKhFlt032295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Feb 2013 13:43:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Thu, 28 Feb 2013 12:43:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> <63519CDF-144F-4DA4-A9F3-A1AB824861D2@vpnc.org> To: Tim Bray X-Mailer: Apple Mail (2.1499) Cc: Barry Leiba , json@ietf.org Subject: Re: [Json] What does "break compatibility" mean? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 20:43:20 -0000 On Feb 28, 2013, at 12:06 PM, Tim Bray wrote: > It=92s clear to me that, *for the purposes of the IETF*, someone needs = to say =93People sending JSON MUST NOT use duplicate keys.=94 The fact = that certain libraries allow less-clueful developers to do this, and = that parsing software is observed to behave unpredictably when they do, = should only encourage us.=20 That doesn't answer the question in the heading, and the question was = aimed at our esteemed Area Director. :-) --Paul Hoffman From nico@cryptonector.com Thu Feb 28 12:47:23 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C5D21F8A55 for ; Thu, 28 Feb 2013 12:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=-1.353, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQrolkSKSpuV for ; Thu, 28 Feb 2013 12:47:23 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id A116C21F858A for ; Thu, 28 Feb 2013 12:46:56 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 2C52D350079 for ; Thu, 28 Feb 2013 12:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=xtHnSHeYrcf5zhhf6DdMlxSOOrQ=; b=MLcAB1FtQrG PD0a7dznsw2nhn2aDytDJ9V8mdTtmFe8vuta7dxZ4DsLQ0wAjxOaL3H8Fg0b09NV VuVL2iC7Rzt0jiMAcZUjiSP0EkwouYM6qB3wr9/NYKC167pwE+8OyjMa4AfkLs1t ZPypjhAbqtKwZUpcERNTOnuuvA43k3C4= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id BAB8A350072 for ; Thu, 28 Feb 2013 12:46:55 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hq4so2662536wib.11 for ; Thu, 28 Feb 2013 12:46:54 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr13468310wjr.33.1362084414321; Thu, 28 Feb 2013 12:46:54 -0800 (PST) Received: by 10.216.148.193 with HTTP; Thu, 28 Feb 2013 12:46:54 -0800 (PST) In-Reply-To: References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> <63519CDF-144F-4DA4-A9F3-A1AB824861D2@vpnc.org> Date: Thu, 28 Feb 2013 14:46:54 -0600 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Barry Leiba , Paul Hoffman , json@ietf.org Subject: Re: [Json] What does "break compatibility" mean? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 20:47:23 -0000 On Thu, Feb 28, 2013 at 2:06 PM, Tim Bray wrote: > It=E2=80=99s clear to me that, *for the purposes of the IETF*, someone ne= eds to say > =E2=80=9CPeople sending JSON MUST NOT use duplicate keys.=E2=80=9D The f= act that certain > libraries allow less-clueful developers to do this, and that parsing > software is observed to behave unpredictably when they do, should only > encourage us. The obvious compromise is to say senders MUST NOT send dup object keys and receivers MUST take the last key value pair of any dup keys, per-ECMAScript. The latter preserves compatibility. Nico -- From barryleiba@gmail.com Thu Feb 28 13:46:43 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBEB21F892C for ; Thu, 28 Feb 2013 13:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.039 X-Spam-Level: X-Spam-Status: No, score=-102.039 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4VandY0DVBG for ; Thu, 28 Feb 2013 13:46:43 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 52D1F21F88ED for ; Thu, 28 Feb 2013 13:46:41 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id fs13so2251045lab.22 for ; Thu, 28 Feb 2013 13:46:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=u9CDUk2jiuNAyGXMpLAHFEe1Q5lZ5Wp5fdjtypn8VZ8=; b=dt4CTIqn9FA1Y3FzIMwNTM0h6/g0hsd+L0x/G6kvUgs3NiRvsoWhXOVOvAiL+Wvlaw emKcRVPVylD6UWEf9Frw2S/q1unA0B3uJQk1HwR519MviMwyq8NTiDFAfWsN9RIE/P9K iAlNqf1KDA2hOw8pPX69MzeZhu7DwhQ2bdHdsC0yC6rzzlpdNzI6I3a3vl8Uf7An/aUC Oe5LSsnRzFQHdxzYsLZuU5s14wRLG2lMFYznpb47O3UZKSfOV224EXESgIcG2CU2BllL G/Uq9F9P/a9SPKIjKcOvvXt8AQ95Kl74SvU8M0+jcH4gZve3ZdVK9UiNsf7hBpr5s0Qr J0/Q== MIME-Version: 1.0 X-Received: by 10.112.28.101 with SMTP id a5mr4295141lbh.0.1362088000018; Thu, 28 Feb 2013 13:46:40 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.112.76.98 with HTTP; Thu, 28 Feb 2013 13:46:39 -0800 (PST) In-Reply-To: <63519CDF-144F-4DA4-A9F3-A1AB824861D2@vpnc.org> References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> <63519CDF-144F-4DA4-A9F3-A1AB824861D2@vpnc.org> Date: Thu, 28 Feb 2013 16:46:39 -0500 X-Google-Sender-Auth: J1LoB9iqgQU9EmNP7xMf3QugoYg Message-ID: From: Barry Leiba To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 28 Feb 2013 13:51:25 -0800 Cc: json@ietf.org Subject: Re: [Json] What does "break compatibility" mean? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 21:46:44 -0000 > As we discussed, RFC 4627 says "The names within an object SHOULD be > unique." So, what does "break compatibility" mean for this specific issue? ... > That certainly sounds reasonable. The question is whether you will allow > clarifications that might make something incompatible. Yes, I guess I did speak too soon: that specific change is one we've talked about, and that's likely to be on the charter. But we do need to scope this very tightly. Barry From paul.hoffman@vpnc.org Thu Feb 28 13:51:26 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFC321F8A8E for ; Thu, 28 Feb 2013 13:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.686 X-Spam-Level: X-Spam-Status: No, score=-102.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TbJVM1NJ39Q for ; Thu, 28 Feb 2013 13:51:26 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C20B521F89AF for ; Thu, 28 Feb 2013 13:51:24 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1SLpHcN036189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Feb 2013 14:51:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Thu, 28 Feb 2013 13:51:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> <63519CDF-144F-4DA4-A9F3-A1AB824861D2@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1499) Cc: Barry Leiba , json@ietf.org Subject: Re: [Json] What does "break compatibility" mean? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 21:51:27 -0000 On Feb 28, 2013, at 12:46 PM, Nico Williams = wrote: > On Thu, Feb 28, 2013 at 2:06 PM, Tim Bray = wrote: >> It=92s clear to me that, *for the purposes of the IETF*, someone = needs to say >> =93People sending JSON MUST NOT use duplicate keys.=94 The fact that = certain >> libraries allow less-clueful developers to do this, and that parsing >> software is observed to behave unpredictably when they do, should = only >> encourage us. >=20 > The obvious compromise is to say senders MUST NOT send dup object keys > and receivers MUST take the last key value pair of any dup keys, > per-ECMAScript. The latter preserves compatibility. ...but the former ("say senders MUST NOT send dup object keys") breaks = it, given that the RFC had a SHOULD not a MUST. Thus the question in = this thread. --Paul Hoffman= From tbray@textuality.com Thu Feb 28 13:59:40 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0104121F8B49 for ; Thu, 28 Feb 2013 13:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCw+fdcT19Ks for ; Thu, 28 Feb 2013 13:59:38 -0800 (PST) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB7221F8B1D for ; Thu, 28 Feb 2013 13:59:38 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id fy27so1554165vcb.18 for ; Thu, 28 Feb 2013 13:59:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Fa3ZXMjKL1ToLy8J0m0pgwMxH5ZRnQBgQYLyUtG8p8I=; b=C4/gp3kXbg71EsNeIirXqOCawpSCPVmkoJzmnF6jxCwfYrp6+O/dcrpbts6i5EpUXQ lLZ/ewwgMRkHa/l76u3n9RzHH1ihvg1tpPLakmT/xF3UPkCjDMlYuWiS3cex53OY05Pd OAu+riaw099V34DPYSvvYDS8Xjak4NeRGvygWLY0EIm8HDTp+jX0u8pJD1/Afn9cGRZm qIgjcxrfiFn7+zjWfFzcigEEGh+rYRVBPeO7YoPXbojieq0VuhsH1oHDH6adaAYm/H04 1ofAkF5AAUjMs8s1+xwOOOMhDgGUmkNogXe/4N4ll0eK6nvQbAaeT1MmJeSdRAcNNgmw xz6A== MIME-Version: 1.0 X-Received: by 10.52.89.52 with SMTP id bl20mr2731531vdb.85.1362088777801; Thu, 28 Feb 2013 13:59:37 -0800 (PST) Received: by 10.220.167.10 with HTTP; Thu, 28 Feb 2013 13:59:37 -0800 (PST) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> <63519CDF-144F-4DA4-A9F3-A1AB824861D2@vpnc.org> Date: Thu, 28 Feb 2013 13:59:37 -0800 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=20cf307f37f4c1297604d6d001c4 X-Gm-Message-State: ALoCoQkgJEOgoyQfahKPzSVEdambq/z2rlQCPRbaV775Ii0B38EN4iLe7wDaEwArr1oYc67SC7jB Cc: Nico Williams , Barry Leiba , "json@ietf.org" Subject: Re: [Json] What does "break compatibility" mean? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 21:59:40 -0000 --20cf307f37f4c1297604d6d001c4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If there were a significant number of protocols, or deployed software components, that relied on the use of multiple keys, then changing the SHOULD to a MUST would be a breaking change. I do not believe that there are any, and thus this is not, *de facto*, a breaking change. That hypothesis is easily falsified, if in the course of the IETF work someone sticks their hand up and says =93this is going to break me=94. But I=92m n= ot holding my breath. -T On Thu, Feb 28, 2013 at 1:51 PM, Paul Hoffman wrote= : > On Feb 28, 2013, at 12:46 PM, Nico Williams wrote= : > > > On Thu, Feb 28, 2013 at 2:06 PM, Tim Bray wrote: > >> It=92s clear to me that, *for the purposes of the IETF*, someone needs= to > say > >> =93People sending JSON MUST NOT use duplicate keys.=94 The fact that > certain > >> libraries allow less-clueful developers to do this, and that parsing > >> software is observed to behave unpredictably when they do, should only > >> encourage us. > > > > The obvious compromise is to say senders MUST NOT send dup object keys > > and receivers MUST take the last key value pair of any dup keys, > > per-ECMAScript. The latter preserves compatibility. > > ...but the former ("say senders MUST NOT send dup object keys") breaks it= , > given that the RFC had a SHOULD not a MUST. Thus the question in this > thread. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --20cf307f37f4c1297604d6d001c4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
If there were a significant number of protocols, or d= eployed software components, that relied on the use of multiple keys, then = changing the SHOULD to a MUST would be a breaking change. I do not believe = that there are any, and thus this is not, *de facto*, a breaking change.=A0= That hypothesis is easily falsified, if in the course of the IETF work som= eone sticks their hand up and says =93this is going to break me=94.=A0 But = I=92m not holding my breath.

=A0-T


On Thu, Feb 28, 2013 at 1:51 PM, Paul Hoffman <paul.hoffma= n@vpnc.org> wrote:
On F= eb 28, 2013, at 12:46 PM, Nico Williams <nico@cryptonector.com> wrote:

> On Thu, Feb 28, 2013 at 2:06 PM, Tim Bray <tbray@textuality.com> wrote:
>> It=92s clear to me that, *for the purposes of the IETF*, someone n= eeds to say
>> =93People sending JSON MUST NOT use duplicate keys.=94 =A0The fact= that certain
>> libraries allow less-clueful developers to do this, and that parsi= ng
>> software is observed to behave unpredictably when they do, should = only
>> encourage us.
>
> The obvious compromise is to say senders MUST NOT send dup object keys=
> and receivers MUST take the last key value pair of any dup keys,
> per-ECMAScript. =A0The latter preserves compatibility.

...but the former ("say senders MUST NOT send dup object k= eys") breaks it, given that the RFC had a SHOULD not a MUST. Thus the = question in this thread.

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

--20cf307f37f4c1297604d6d001c4-- From nico@cryptonector.com Thu Feb 28 14:07:39 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FABF21F8B49 for ; Thu, 28 Feb 2013 14:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.092 X-Spam-Level: X-Spam-Status: No, score=-3.092 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qo815gOwaaxp for ; Thu, 28 Feb 2013 14:07:38 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 89B3521F89B5 for ; Thu, 28 Feb 2013 14:07:38 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 19DB6678063 for ; Thu, 28 Feb 2013 14:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=zuQPjEq8VlcNjgzJvflnYI6CYmc=; b=sn/W2qK5eoA I1ScxuV92n4TX11P3MP7Y67gUTJe9AvRKeOO9obVXsiDdrxeOa5lfPuD4pG8Ysov yroSJ/V+uO46jTM0cCY4v+INWZODb8fwUy2zZWcYURD7ly+OqWh//IWAziiESb6j xFbOOBiOXrKavvtqT4kwH+sTqQzuhHYg= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 99E3E6780BF for ; Thu, 28 Feb 2013 14:06:07 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id p43so2003674wea.10 for ; Thu, 28 Feb 2013 14:06:05 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr13796312wjr.33.1362089165769; Thu, 28 Feb 2013 14:06:05 -0800 (PST) Received: by 10.216.148.193 with HTTP; Thu, 28 Feb 2013 14:06:05 -0800 (PST) In-Reply-To: References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> <63519CDF-144F-4DA4-A9F3-A1AB824861D2@vpnc.org> Date: Thu, 28 Feb 2013 16:06:05 -0600 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Barry Leiba , json@ietf.org Subject: Re: [Json] What does "break compatibility" mean? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:07:39 -0000 On Thu, Feb 28, 2013 at 3:51 PM, Paul Hoffman wrote= : > On Feb 28, 2013, at 12:46 PM, Nico Williams wrote= : > >> On Thu, Feb 28, 2013 at 2:06 PM, Tim Bray wrote: >>> It=E2=80=99s clear to me that, *for the purposes of the IETF*, someone = needs to say >>> =E2=80=9CPeople sending JSON MUST NOT use duplicate keys.=E2=80=9D The= fact that certain >>> libraries allow less-clueful developers to do this, and that parsing >>> software is observed to behave unpredictably when they do, should only >>> encourage us. >> >> The obvious compromise is to say senders MUST NOT send dup object keys >> and receivers MUST take the last key value pair of any dup keys, >> per-ECMAScript. The latter preserves compatibility. > > ...but the former ("say senders MUST NOT send dup object keys") breaks it= , given that the RFC had a SHOULD not a MUST. Thus the question in this thr= ead. Depends on your definition of "break". If you mean that some senders are now "non-compliant", you're right, but there's no compliance police here so what matters is whether *receivers* change behavior in ways that a) are different from the old spec *and* b) break actual interop. It's the interop that matters. Nico -- From tsaloranta@gmail.com Thu Feb 28 14:14:30 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD69E21F8B06 for ; Thu, 28 Feb 2013 14:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO-RcePjGrb4 for ; Thu, 28 Feb 2013 14:14:28 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id B434921F8B83 for ; Thu, 28 Feb 2013 14:14:27 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so8356239wib.15 for ; Thu, 28 Feb 2013 14:14:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=S2WvO0E2m2LeXTR2td/9GEAB1jcZzGAKj3TVI5e9lYo=; b=YuQ3iDpLPm1bWTsUMndwVRCJdm0V13QmGPRCO630BaRbgtGkRSLFKYWGXAawc44wCw uL/GQlMxWNtbOD2XwzG8JJgS+3mT4SJpRCCau7mJUoikzPwU0xr61gySYeGDsU+AqUY2 U8sVwcBDTsrid4LGWnAmsYos96L0Qglmia9dAi1zU9MjyzGG6l6B1kXVp2XLdnSeGB3D PIhddvqQ/ifvFuiQT1SXkeUyU6gOP/zPeHdcBsiD+kTZ/6LGo0tgJHpHOd/HABYR91tb ny4rsqffH6Q9TulcFDy7qsJ6dok5C8v4VF8FMJAhaCTwxOzgilaNnRLWlkUK4HTB9q/u TwRg== MIME-Version: 1.0 X-Received: by 10.180.14.233 with SMTP id s9mr353403wic.25.1362089666896; Thu, 28 Feb 2013 14:14:26 -0800 (PST) Received: by 10.227.63.132 with HTTP; Thu, 28 Feb 2013 14:14:26 -0800 (PST) In-Reply-To: References: <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> <63519CDF-144F-4DA4-A9F3-A1AB824861D2@vpnc.org> Date: Thu, 28 Feb 2013 14:14:26 -0800 Message-ID: From: Tatu Saloranta To: Tim Bray Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Nico Williams , Barry Leiba , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] What does "break compatibility" mean? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:14:30 -0000 On Thu, Feb 28, 2013 at 1:59 PM, Tim Bray wrote: > If there were a significant number of protocols, or deployed software > components, that relied on the use of multiple keys, then changing the > SHOULD to a MUST would be a breaking change. I do not believe that there = are > any, and thus this is not, *de facto*, a breaking change. That hypothesi= s > is easily falsified, if in the course of the IETF work someone sticks the= ir > hand up and says =93this is going to break me=94. But I=92m not holding = my > breath. +1 on this. One minor comment on latter part -- in cases where parsers do not retain more state than absolutely required for matching open scopes (aka "streaming parsers"), this would presumably mean no change, as all key/value pairs would still be exposed as is. It would then be up to higher layers, such as tree builder or data-binder, to ensure that of possible duplicates the last one sticks. This is how many tools already work. I just want to mention this as it is one case where wording could still be debated ("but parser SHOULD remove other values, only expose last one"), depending on wording. -+ Tatu +- > > -T > > > On Thu, Feb 28, 2013 at 1:51 PM, Paul Hoffman wro= te: >> >> On Feb 28, 2013, at 12:46 PM, Nico Williams wrot= e: >> >> > On Thu, Feb 28, 2013 at 2:06 PM, Tim Bray wrote= : >> >> It=92s clear to me that, *for the purposes of the IETF*, someone need= s to >> >> say >> >> =93People sending JSON MUST NOT use duplicate keys.=94 The fact that >> >> certain >> >> libraries allow less-clueful developers to do this, and that parsing >> >> software is observed to behave unpredictably when they do, should onl= y >> >> encourage us. >> > >> > The obvious compromise is to say senders MUST NOT send dup object keys >> > and receivers MUST take the last key value pair of any dup keys, >> > per-ECMAScript. The latter preserves compatibility. >> >> ...but the former ("say senders MUST NOT send dup object keys") breaks i= t, >> given that the RFC had a SHOULD not a MUST. Thus the question in this >> thread. >> >> --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 sm@resistor.net Thu Feb 28 17:06:58 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A1B21F891C for ; Thu, 28 Feb 2013 17:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCndZ2cxJhYl for ; Thu, 28 Feb 2013 17:06:57 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE2D21F886E for ; Thu, 28 Feb 2013 17:06:57 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2116okW003079; Thu, 28 Feb 2013 17:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362100015; bh=XM+h9wLRNmehmnawEbDsT+7yIoh4SG8EEvEDdFcpimI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TLcF5XDbBQY0i9ytHPw1t2fZzsCa6thM0Y8P1SC1WhkgtvD7Zk+wYRLPqbGtGW1tM OwgVkdkOZE6VxxoCyZG6KAj9BC+Y0rlABehNaJBA2OUkh9HJJTMEQPwnn3sm5V0+No c+zVESkFeubT23gM/7X6zaEBPSm6Xp+CC+LYM/i0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1362100015; i=@resistor.net; bh=XM+h9wLRNmehmnawEbDsT+7yIoh4SG8EEvEDdFcpimI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xx+zaYPYzsvGbityqRRrSNzWFpjcrC21ybmahzi5bjr4CWHBxfDO2iZPQyFYDXk4B hCe4ddqgqEefuP6FWbRWYx5Q/fLxs3LrXekB6EqlwTt1WdL0oWweXhfhOsdr/3uRMl 1+L7dYWZpsQklNmQ5nOLyEnO2+FQyAcdcwk1LCyY= Message-Id: <6.2.5.6.2.20130228165355.0a76fcb0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 28 Feb 2013 17:00:13 -0800 To: json@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Mark Nottingham Subject: Re: [Json] Comments on the proposed charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 01:06:58 -0000 At 17:54 19-02-2013, Mark Nottingham wrote: >I am somewhat concerned about this. If "community" means a >self-selecting group of standards nerds / corporate interests / >fringe developers, I am violently against it. > >Yes, anyone can come to the table at the IETF, but I question >whether the wider JSON community is even aware of this effort. Have >we reached out to JSON implementers, for example? Have they joined >the list? Do we have representation from the various Open Source >frameworks that use JSON? I agree with what Mark wrote. This ends up creating social issues which affect other work. Regards, -sm From sm@resistor.net Thu Feb 28 17:39:50 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E586321F8771 for ; Thu, 28 Feb 2013 17:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqZdVNc-g3Dw for ; Thu, 28 Feb 2013 17:39:50 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADE021F86FB for ; Thu, 28 Feb 2013 17:39:50 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r211djFs006648 for ; Thu, 28 Feb 2013 17:39:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362101989; bh=waMWoIVtVeqjltByXm1l77CwXUWJcdAuWlsIUActH5c=; h=Date:To:From:Subject; b=LzDtEcLQt4AqM/lq0s0IZhrvPjwsNYG3kOQ7UyKfIllOziAhRsH+VUoT6wS91mhRg Fr9J3W6W4df27YdYnclSg8TzRsURQndKIA49ApdgM4EaC8mQigw3Y969Yy5ziNpc3n v33o1ry9IZ/6r3TQMMHt1xHSddFA7pYPSn/WAjqE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1362101989; i=@resistor.net; bh=waMWoIVtVeqjltByXm1l77CwXUWJcdAuWlsIUActH5c=; h=Date:To:From:Subject; b=mszvkTOxh4L7twhX+xMFXkd6CoG7b+fMuwW0YhkEfahCLEumO2OUbILX1TMYb1OB6 ffC5NiXzAoapVhiaOXP2aoJEkf8bUO4eJNaleph5qMO5w+jfXIO4FS43ae0k9SSVO+ 8B+WDvIpdt5urDXn+Ku+qqPcpnqM2kNOeJTUqAlA= Message-Id: <6.2.5.6.2.20130228170825.09fcfa20@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 28 Feb 2013 17:25:08 -0800 To: json@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Json] Comments on proposed charter for JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 01:39:51 -0000 Hello, Here's a few comments about the proposed JSON charter: "There are also a number of other JSON-related proposals for Standards Track that would benefit from the community and review created by a working group focused on JSON." What is "community" in the above? "During that work, the working group may collect change requests, and may choose to propose a more significant revision of the JSON specification if there is rough consensus to do so. Proceeding with such a revision will require AD approval, for which the responsible AD may require a recharter to get community and IESG review of the proposal." I suggest removing the above paragraph. It's easier to stick to errata and "correct significant errors and inconsistencies". I suggest against having an initial list. It's difficult to predict whether people will have the energy to review once the charter has been approved. Regards, -sm