From nobody Wed Oct 15 12:54:55 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0190A1A90AE for ; Wed, 15 Oct 2014 12:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EBvYoK8nxnv for ; Wed, 15 Oct 2014 12:54:50 -0700 (PDT) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B39251A90DD for ; Wed, 15 Oct 2014 12:54:50 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id ey11so1937749pad.13 for ; Wed, 15 Oct 2014 12:54:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=/R5PDKXHV7RH68KJIe4uVeh/++TP6JT8tEqnNzZqfm8=; b=e652cKAM9t9/EBwrXQGvWDS6VmqcG4Y6BXrr9zKJDME//a72qwj3z4rTxz5Sft8wYN vcEXxUMcWIb7ywFFrhJGuQmRhCk5fvrGyP0AsFIvE0qZPBUckREMdWbYg0A13rO7NZuC dxARo3WZiOy+03fwZ4MvyXu1gIqdgw8w7mI0MhyIg15B2o6MLgTG479A1RwsFTrKI3PG XOS0oP24nYwm1oWHgMZtGL1ky+0t87SUkVbMvp+VYUE5ux2Pg3Zp4tjk+NpwTZE9FNFE gmmaxZLWOZNPtqoEKl4L8TbZnqucJZw8k/Vp2b0r7YSXBJASd7xwDa24DKZnTWcJRGOY HSOw== X-Gm-Message-State: ALoCoQnchnY76mC7YBVdBDwVqjbG6kHn6rZ/GKYGALk3R++ZydJ+lbBBABRroBtxu4/A/pgT6jFz MIME-Version: 1.0 X-Received: by 10.68.219.70 with SMTP id pm6mr5234350pbc.146.1413402890364; Wed, 15 Oct 2014 12:54:50 -0700 (PDT) Received: by 10.66.194.13 with HTTP; Wed, 15 Oct 2014 12:54:50 -0700 (PDT) X-Originating-IP: [192.149.252.11] Date: Wed, 15 Oct 2014 15:54:50 -0400 Message-ID: From: Andrew Newton To: JSON WG Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/byStN-j2Rt8e1PnnKewm-K3c2Hg Subject: [Json] more on schemas, JCR -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 19:54:52 -0000 All, Continuing the "discussion we are not having", I've updated JSON Content Rules (JCR) based on feedback I have received from people who are using it and others. The draft is here: URL: http://www.ietf.org/internet-drafts/draft-newton-json-content-rules-03.txt Status: https://datatracker.ietf.org/doc/draft-newton-json-content-rules/ Htmlized: http://tools.ietf.org/html/draft-newton-json-content-rules-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-newton-json-content-rules-03 While JCR is not JSON, its sole intent is to model JSON. There is no abstraction: it is composed of 5 basic rules, the first four being tied to JSON syntax and the fifth being a grouping rule. Specifically regarding JCR, one of the comments is that it is "cryptic". The new draft introduces an alternative syntax that will probably be less cryptic to readers unfamiliar with JCR. Personally I find this to be a matter of taste where TL;DR can also be an issue, but I am sympathetic to the argument that some readers will prefer words over symbols. While a prose based approach does have its place, sometimes conciseness and compactness is a virtue. For example, if you take a look at draft-ietf-weirds-json-response (http://tools.ietf.org/html/draft-ietf-weirds-json-response-10) you will see that there are a lot of JSON structures that are re-used inside of other structures. In my opinion, description of this type of JSON benefits from a more compact and concise schema language, and had draft-ietf-weirds-json-response had the benefit of JCR it might not need to rely so heavily on copious examples. This is illustrated in Appendix B of the JCR draft. Another valuable trait of JCR in describing IETF documents specifically is the ability to describe values as IP addresses, domain names, and other types used by protocol documents. While a small benefit, anything that reduces the tedium of specification writing will hopefully reduce mistakes. To a larger point, the same hope applies to a syntax that is concise and compact. With regards to schema languages in general, Tim has repeatedly said that we should concentrate on protocol test suites. I agree, but I do not see schema languages as being mutually exclusive of test suites. In fact, they aid in the construction of test suites. With JCR, it is possible to have JCR validators call custom code based on rule names for evaluation of JSON in the context of the protocol and specific to the needs of the test suite. I've already written a JCR parser in hopes of getting a validator written, and that is one of my intended features. I welcome feedback on this draft, and encourage those who have not looked at it to do so. -andy From nobody Wed Oct 15 13:28:10 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252C61ACC83 for ; Wed, 15 Oct 2014 13:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pn2KsmYRiTSG for ; Wed, 15 Oct 2014 13:28:08 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1BA1A8935 for ; Wed, 15 Oct 2014 13:28:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 5EFE2C3C467; Wed, 15 Oct 2014 16:27:28 -0400 (EDT) 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 wUjNzvK0KPGT; Wed, 15 Oct 2014 16:27:27 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 275F2C3C45C; Wed, 15 Oct 2014 16:27:25 -0400 (EDT) Date: Wed, 15 Oct 2014 16:27:59 -0400 From: Cyrus Daboo To: Andrew Newton , JSON WG Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=700 Archived-At: http://mailarchive.ietf.org/arch/msg/json/JBd8VjvmZL4xn5GkO1Ca-_r-Io0 Subject: Re: [Json] more on schemas, JCR -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 20:28:09 -0000 Hi Andrew, --On October 15, 2014 at 3:54:50 PM -0400 Andrew Newton wrote: > I welcome feedback on this draft, and encourage those who have not > looked at it to do so. Looks good. The draft I have in the tzdist WG (draft-ietf-tzdist-service) uses JCR to describe the JSON responses that the protocol uses. I have found the JCR syntax pretty simple to use and understand and it looks to me like a good way to describe JSON. There is an open issue in the tzdist WG about how best to describe the JSON responses - my preference is to stick with JCR and thus I would like to see JCR get published as an RFC suitable for normative reference in a preposed standard. -- Cyrus Daboo From nobody Wed Oct 15 13:49:25 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49D81ACD4C for ; Wed, 15 Oct 2014 13:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSp4okLXKUnB for ; Wed, 15 Oct 2014 13:49:20 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917F51ACD3F for ; Wed, 15 Oct 2014 13:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3559; q=dns/txt; s=iport; t=1413406161; x=1414615761; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Swh6aUyWUCA3Fk/NUzH5j0uO1b9z/TaFAYwqV6sUNDM=; b=i5C7/5xEb9r92lakBbq+Az/416QYuoKfO75WSO1xhqYoxYTuBTY4q2xQ owwMUJkqILCSLX8Q9AElQrHzku1k6bRkJDQNv0yxt8jn8EQTAYD+5w2yV YkfYRJqWpeFoqXIiDv6a97QH+TJdgqzmVEaslxkhP71soTKIRpLkbKP0G M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAKDcPlStJA2J/2dsb2JhbABbgw5TUwUEy3kMh0sCgRcWAX2EAwEBBAEBATc0GwIBCA4oECcLJQIEARIJiDUIBch3AQEBAQEBAQMBAQEBAQEBARqQVYRLBZF/hESHEYFslC6Dd2wBgQckHIECAQEB X-IronPort-AV: E=Sophos;i="5.04,727,1406592000"; d="scan'208";a="87290329" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP; 15 Oct 2014 20:49:20 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9FKnJwj000880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 20:49:19 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 15:49:19 -0500 From: "Andrew Biggs (adb)" To: Andrew Newton , JSON WG Thread-Topic: [Json] more on schemas, JCR -03 Thread-Index: AQHP6LHqG+IJSEytvE6otokMCdXQYJwxkNGA Date: Wed, 15 Oct 2014 20:49:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [64.101.72.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <301A07D86ED1054F8442D0DD89B7442E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Qx_WLbdhD-vqQF5Y_wA76egK6i8 Subject: Re: [Json] more on schemas, JCR -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 20:49:22 -0000 Hi Andrew, I've only had a chance to briefly scan the new draft, but it looks good so far. Will pass on more detailed comments after I've had a chance to dig in more. I've been working with the previous revisions of the JCR for over a year now, to document JSON based APIs and API design guidelines, and have really appreciated the conciseness and simplicity of the syntax. The symbolic approach actually becomes pretty natural after a short time as evidenced by the feedback I've received from readers of my docs. Andrew =20 On 10/15/14, 1:54 PM, "Andrew Newton" wrote: >All, > >Continuing the "discussion we are not having", I've updated JSON >Content Rules (JCR) based on feedback I have received from people who >are using it and others. The draft is here: > >URL: >http://www.ietf.org/internet-drafts/draft-newton-json-content-rules-03.txt >Status: >https://datatracker.ietf.org/doc/draft-newton-json-content-rules/ >Htmlized: =20 >http://tools.ietf.org/html/draft-newton-json-content-rules-03 >Diff: >http://www.ietf.org/rfcdiff?url2=3Ddraft-newton-json-content-rules-03 > >While JCR is not JSON, its sole intent is to model JSON. There is no >abstraction: it is composed of 5 basic rules, the first four being >tied to JSON syntax and the fifth being a grouping rule. > >Specifically regarding JCR, one of the comments is that it is >"cryptic". The new draft introduces an alternative syntax that will >probably be less cryptic to readers unfamiliar with JCR. Personally I >find this to be a matter of taste where TL;DR can also be an issue, >but I am sympathetic to the argument that some readers will prefer >words over symbols. > >While a prose based approach does have its place, sometimes >conciseness and compactness is a virtue. For example, if you take a >look at draft-ietf-weirds-json-response >(http://tools.ietf.org/html/draft-ietf-weirds-json-response-10) you >will see that there are a lot of JSON structures that are re-used >inside of other structures. In my opinion, description of this type of >JSON benefits from a more compact and concise schema language, and had >draft-ietf-weirds-json-response had the benefit of JCR it might not >need to rely so heavily on copious examples. This is illustrated in >Appendix B of the JCR draft. > >Another valuable trait of JCR in describing IETF documents >specifically is the ability to describe values as IP addresses, domain >names, and other types used by protocol documents. While a small >benefit, anything that reduces the tedium of specification writing >will hopefully reduce mistakes. To a larger point, the same hope >applies to a syntax that is concise and compact. > >With regards to schema languages in general, Tim has repeatedly said >that we should concentrate on protocol test suites. I agree, but I do >not see schema languages as being mutually exclusive of test suites. >In fact, they aid in the construction of test suites. With JCR, it is >possible to have JCR validators call custom code based on rule names >for evaluation of JSON in the context of the protocol and specific to >the needs of the test suite. I've already written a JCR parser in >hopes of getting a validator written, and that is one of my intended >features. > >I welcome feedback on this draft, and encourage those who have not >looked at it to do so. > >-andy > >_______________________________________________ >json mailing list >json@ietf.org >https://www.ietf.org/mailman/listinfo/json From nobody Wed Oct 15 14:11:19 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6561ACD21 for ; Wed, 15 Oct 2014 14:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BzY-xjjiwnp for ; Wed, 15 Oct 2014 14:11:16 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D898C1ACD8F for ; Wed, 15 Oct 2014 14:11:15 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id w7so1797848lbi.9 for ; Wed, 15 Oct 2014 14:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=d72rjk8ftiden0/0R8ezcB+aQUpMnc4hl3cQm6/Jq4o=; b=ULL721ChhI8pWr+UOZlteUauM0R/JWGMNdwusDQyXjSkTqEEJUQcnuktmb8KYTX7CI sJysd2RUEOAcjVm3DlAGWdY+QCWzGjZ5O01MzMSzWG0O/V6jw/Gq1vPzigXMyL39FxOb kkftgGahVxDJ62TqmqqzKdDsOdnCdx60VQZ0O03gNaxFj6Ypo2u8wNL8Xze9/QSM+3uf Zyu8ADpa3KS1zjBIIeaaOlee3rMztcvm/YQ3zi1oVmBsD6cuk3m/Oi9Ra6Bs0+3NkYWr KrifCfcjq46JeGE1KUMVZKSCub+XIUJjeH4A5nvly2+87Z89fOvilyvXTYGYk1n9Me1A trjQ== MIME-Version: 1.0 X-Received: by 10.152.87.171 with SMTP id az11mr5486752lab.97.1413407474181; Wed, 15 Oct 2014 14:11:14 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Wed, 15 Oct 2014 14:11:13 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Oct 2014 17:11:13 -0400 X-Google-Sender-Auth: mSg0KOh8mnQa_J3cFTcpq12Qcdk Message-ID: From: Phillip Hallam-Baker To: Andrew Newton Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/v9J1l4z-HdzCCd2qxjueN2w6gPQ Cc: JSON WG Subject: Re: [Json] more on schemas, JCR -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 21:11:18 -0000 I think a tool for producing specs and JSON parsing code is a good idea. And I have been using one for quite a while. The main difference between Andy's scheme and mine is that I have a description element that allows each entry to be documented and I have elements that allow messages to be grouped together as transactions and transactions into services. There are some differences in the syntax but the main features I didn't add were to specify maximum/minimum integer values. I can see the point in specifying 1,2,4 or 8 bit integers and signed or unsigned. But going deeper seems unnecessary. If we specify any limits it should be on overall message sizes. The part that I think the group could usefully look at is the composition problem. Lets say we have Spec A/1.0 and we want to use that inside Spec B/1.0, how should we guide people to do that in a way that maximizes code reuse and all that goodness and also means that we are clear when we do A/1.1 and B/1.1 and they both introduce new code points. This is what XML purported to solve but turned out not to. From nobody Wed Oct 15 14:47:34 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EEA1ACDC3 for ; Wed, 15 Oct 2014 14:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_MT7_1rKCpr for ; Wed, 15 Oct 2014 14:47:29 -0700 (PDT) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BD91ACDB4 for ; Wed, 15 Oct 2014 14:47:29 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id ey11so2047886pad.41 for ; Wed, 15 Oct 2014 14:47:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9JIZbQvuER3+9weaqqZ54qGpoT7D2wQIRMDOzT9hQak=; b=O+DHvzMakgG2yqHLGgxAiPdlVQX0N+fxa/HOkk5ScehzYtT/5R5idK+IzF5z/Qb4S3 xYKjOuNdhd2CLJztqo5iyUdSGGDltJweuA7lLkrc/hw2r2lLpeqFoj04Mgr2RZjE0oWU Dj/xhHHSAoZD+uD59dTsEWPZtXg8tiYWUWpk2VpAK3aprxZX6NbG31YOEFqMRioOGPyz 866aQWMT1VdCemMXKeZsQXHBDqWfX91Ef5ocJW2heefpsspv26Zgq1JjfXAHEYTiWF7P s2B0DMy/BnfCtXG6mBsJGZCPi01eRMF+9QlycT/o858pou77vQ3bkIwN1OUbX2H/t3NH ZNeA== X-Gm-Message-State: ALoCoQlQ6izGIIfNwzXMwWbjKfsY6wMn9glTweZzOvt5YPyFlAI4qnZRLKPi1jwDNBzDcYu1XOIS MIME-Version: 1.0 X-Received: by 10.70.129.206 with SMTP id ny14mr5088912pdb.166.1413409649022; Wed, 15 Oct 2014 14:47:29 -0700 (PDT) Received: by 10.66.194.13 with HTTP; Wed, 15 Oct 2014 14:47:28 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: References: Date: Wed, 15 Oct 2014 17:47:28 -0400 Message-ID: From: Andrew Newton To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/L3ClgFXC8vBgnN8cMkw5BpEPTsY Cc: JSON WG Subject: Re: [Json] more on schemas, JCR -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 21:47:31 -0000 On Wed, Oct 15, 2014 at 5:11 PM, Phillip Hallam-Baker wrote: > The main difference between Andy's scheme and mine is that I have a > description element that allows each entry to be documented and I have > elements that allow messages to be grouped together as transactions > and transactions into services. > By messages, transactions, services do you mean each message is a JSON "document", and the transactions and services are protocol concepts beyond the JSON serialization? Otherwise I do not understand. Is this in an I-D? > There are some differences in the syntax but the main features I > didn't add were to specify maximum/minimum integer values. I can see > the point in specifying 1,2,4 or 8 bit integers and signed or > unsigned. But going deeper seems unnecessary. To each his own, I guess. I can certainly think of use cases where min/max are useful. > > If we specify any limits it should be on overall message sizes. > > > The part that I think the group could usefully look at is the > composition problem. Lets say we have Spec A/1.0 and we want to use > that inside Spec B/1.0, how should we guide people to do that in a way > that maximizes code reuse and all that goodness and also means that we > are clear when we do A/1.1 and B/1.1 and they both introduce new code > points. There is an include directive in JCR that does this, if I correctly understand your point. > > This is what XML purported to solve but turned out not to. I think XML, and more specifically XML Schema, is what gives a lot people pause when discussing JSON schemas. -andy From nobody Thu Oct 16 02:08:35 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AB51A19E3 for ; Thu, 16 Oct 2014 02:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyNrh_GYig1M for ; Thu, 16 Oct 2014 02:08:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B131A014F for ; Thu, 16 Oct 2014 02:08:32 -0700 (PDT) Received: from ladislavs-air-2.labs.office.nic.cz (unknown [172.20.6.120]) by mail.nic.cz (Postfix) with ESMTPSA id F211313F738 for ; Thu, 16 Oct 2014 11:08:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1413450511; bh=eMOS7mHDL60JY5bFbcqCQfAWdkd2SvG01yUBbsY0GH4=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=TYlxRMK0ZNcsMY1obibTb4ORCHkK7QPHTU8J9mZD2DQhxpTG58uD34/o1iVFpFrt2 c2hbM49RVu3gKaCKjAaomUeqdUp+uu1yLKSr7bWlKAQCR7SDpyEqItKyPagHT6/ke1 3qqwhj5WsO3MUJ+bMDVHqlAfwqUvDeFPdT4oEEYg= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 16 Oct 2014 11:08:30 +0200 To: JSON WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/json/5ss5gESePzc02EiXfzRpQ96dKwA Subject: [Json] draft-ietf-netmod-yang-json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 09:08:34 -0000 Hi, the last revision of $subj now explicitly refers (normatively) to = I-JSON, and some changes to the previous revision were motivated by = I-JSON compliance. The only two remaining deviations from I-JSON are: - noncharacters (those that are permitted by XML), - use of base64 for encoding binary data instead of base64url. The former is likely to be resolved in the new version of YANG = (noncharacters will be banned). Here is the I-D: http://tools.ietf.org/html/draft-ietf-netmod-yang-json-01 Comments and suggestions will be appreciated. Thanks, Lada =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Oct 16 14:55:19 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286931A8ABB for ; Thu, 16 Oct 2014 14:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_Raridv5qss for ; Thu, 16 Oct 2014 14:55:14 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F2F1A874B for ; Thu, 16 Oct 2014 14:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413496514; x=1445032514; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=/R6FLXsl8T7mcGnG1MG8y+ZOwIt8UMGBm+10lGHbgl0=; b=FqYKf9WhSzCzTI3ykqzJhLISrTVLavsOTQumW7oB8pTvQcyXvBpKPXr7 hWAlhKxlLW7UegII/PFIgXIiQ5qWZ24MNo+lP9j2P2S2PWbWjzykjRxJ5 iSLZqdFXQZ+w+QxpjwKsKItJs8FUJqyCMRHmUiHip/ammp/crhulygmzJ 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7593"; a="167189730" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Oct 2014 14:55:13 -0700 X-IronPort-AV: E=Sophos;i="5.04,734,1406617200"; d="scan'208";a="825964408" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Oct 2014 14:55:12 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 16 Oct 2014 14:55:12 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 16 Oct 2014 14:55:11 -0700 Message-ID: <54403EBD.9060203@qti.qualcomm.com> Date: Thu, 16 Oct 2014 16:55:09 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "json@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/json/TulAIQt0UuJ4vOtw8jaiIbYju4E Subject: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 21:55:17 -0000 It's been a lousy month. I'm finally getting to my AD Evaluations for this group. Here's the i-json eval; you should see text-sequences in a few hours. Generally this document is looking good, but some things need tightening up or clarification. I think only my comment about section 3 is likely to cause any consternation. By section number: 2.2 - The "MUST NOT assume" and "MUST NOT expect" language is too mushy. You should put the requirement on the generators clearly: OLD Software which implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used. Implementations which generate I-JSON messages MUST NOT assume that receiving implementations can process numeric values with greater magnitude or precision than provided by those numbers. NEW Software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, and receiving implementations might not be able to process numeric values that can't be represented as such. Therefore, implementations which generate I-JSON messages MUST NOT generate numeric values with magnitude or precision greater than provided by those numbers. On the second bit, I think switching to a SHOULD NOT actually makes it stronger: OLD In particular, an I-JSON sender MUST NOT expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. NEW In particular, an I-JSON sender SHOULD NOT generate a numeric integer value greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]), since a receiving implementation is likely not to treat it as an exact value. That way you're using a proper 2119 SHOULD NOT: there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing... You could make it a simple "MUST NOT generate", but the way it was written didn't seem like the WG was on board with that. I'm OK with it either way. 2.3 - Again, the "MUST NOT assume" makes this mushy: OLD Implementations which generate I-JSON messages MUST NOT assume that the order of object members in those messages is available to software which receives them. Here, I think using a MAY for the *receiving* side actually makes it stronger: The order of object members in an I-JSON message does not change the meaning of an I-JSON message. A receiving implementation MAY treat two I-JSON messages as equivalent if they differ only in the order of the object members. 3 - In the rest of this document, we're putting tight constraint on the generators of I-JSON messages. That's exactly what this document ought to do. But the first paragraph of this section is putting constraints on all interpreters. This seems bogus to me. If I write a client that receives I-JSON, I've got my choice of what to do with broken I-JSON. I can generate an error; I can use it but warn the user; I can rewrite it to make it proper I-JSON; I can post copies of it (and the name of the generator software) on my website called, "Idiots who can't implement I-JSON". Saying that there are circumstances (which depend on the protocol in question) where you MUST discard the message (say, using it in a security circumstance) is fine. What I object to is this protocol document saying that I MUST NOT act on it in any way. Let me suggest a replacement: A major advantage of using I-JSON is that receivers can avoid ambiguous semantics in the JSON messages it receives. This allows receivers to reject or otherwise disregard messages which do not conform to the requirements in this document for I-JSON messages. Protocols that use I-JSON message can be written so that receiving implementation are required to reject (or, as in the case of security protocols, not trust) messages that do not satisfy the constraints of I-JSON. The second paragraph I'm OK with. 4.1 - s/avoid the use of/do not use (or you can reverse the order of the sentence and say "SHOULD NOT use") 4.2 - OLD Such a policy is often referred to as "Must-Ignore" and is expressed with language such as "When receiving software encounters a protocol element which it does not recognize, it MUST NOT change its behavior as a consequence, and in particular must not fail." The converse policy, often referred to as "Must-Understand", does not tolerate the introduction of new protocol elements, and while this has proven necessary in certain protocol designs, in general it has been found to be overly restrictive and brittle. First of all, this is the first time I can remember seeing the terms "Must-Ignore" and "Must-Understand" as some sort of catch phrases, so I think "often referred to" is probably overstated. I also find the use of the terms "software" and "behavior" here kind of icky. Let me suggest an alternative: NEW This can be referred to as a "Must-Ignore" policy, meaning that when an implementation encounters a protocol element which it does not recognize, it should treat the rest of the protocol transaction as if the new element simply did not appear, and in particular MUST NOT treat this as an error condition. The converse "Must-Understand" policy does not tolerate the introduction of new protocol elements, and while this has proven necessary in certain protocol designs, in general it has been found to be overly restrictive and brittle. And then a small editorial change to the last paragraph: s/MUST NOT produce behavior changes/MUST be ignored. Everything else seems good to go. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Oct 16 15:52:26 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B301A01E1 for ; Thu, 16 Oct 2014 15:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZcrI11Zww65 for ; Thu, 16 Oct 2014 15:52:18 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ABBB1A0111 for ; Thu, 16 Oct 2014 15:52:18 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hy10so3500598vcb.29 for ; Thu, 16 Oct 2014 15:52:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=AOB3OB3lRdChELHSap1F/vmD9ZRIJwlXIp0eOAiI8Ho=; b=AqtccdqyWcJpi7Z7Hmw2rdjaTjMJfMUEWsB8lrvdM1V9WRlCnVY4XJJx11bjRd6iCJ e954OtbGkm91VsR0aBBEIbdSQTNVo+nRVKY5s/qTWDxa9V21i97bSYeqO64MByA8KWCh 8gREnjCwu5B1vOakt0PASQDV838fmZcptCp3ZAzwjmRigqo2WjQvOtZtZeOX8jKM4ZnV UVh8T3Lg7pOpgBOW7bT8E0aC6WvGHgCrpHk9PKo+TiRpGqpqBeUUBw3FtPG+Pi6fbxvi R7qYr4puOh9LocZWTXv4uzUZyXqOdVNZfgQPEyRhWZvyFHElA5XeSuOi24IiLIOMaU3K Z8oA== X-Gm-Message-State: ALoCoQkzR1XSz49fFSBmwj2GorAgU4YIdGKsHHUPmghWX4LGUW4hsc6YGahuTfT5Lo9/ZBLalrsA X-Received: by 10.52.189.196 with SMTP id gk4mr3590687vdc.10.1413499937541; Thu, 16 Oct 2014 15:52:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.160.135 with HTTP; Thu, 16 Oct 2014 15:51:57 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <54403EBD.9060203@qti.qualcomm.com> References: <54403EBD.9060203@qti.qualcomm.com> From: Tim Bray Date: Thu, 16 Oct 2014 15:51:57 -0700 Message-ID: To: Pete Resnick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/06mT-2XeMBfWIlbaYiYZ3ZQXVgA Cc: "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 22:52:25 -0000 These almost all look like improvements to me and, absent screaming, I'll fold them in. Except for: On Thu, Oct 16, 2014 at 2:55 PM, Pete Resnick w= rote: > OLD > Software which implements IEEE 754-2008 binary64 (double precision) > numbers [IEEE754] is generally available and widely used. > Implementations which generate I-JSON messages MUST NOT assume that > receiving implementations can process numeric values with greater > magnitude or precision than provided by those numbers. > NEW > Software that implements IEEE 754-2008 binary64 (double precision) > numbers [IEEE754] is generally available and widely used, and > receiving implementations might not be able to process numeric values > that can't be represented as such. Therefore, implementations which > generate I-JSON messages MUST NOT generate numeric values with > magnitude or precision greater than provided by those numbers. I suggest rolling in the improvement with the sentence that followed the OLD, to read Software which implements IEEE 754-2008 binary64 (double precision) numbers is generally available and widely used, and receiving implementations might not be able to process numeric values that can=E2=80=99t be represented as such. Therefore, implementations which generate I-JSON messages MUST NOT generate numeric values with greater magnitude or precision than an IEEE 754 double precision number provides, for example 1E400 or 3.141592653589793238462643383279. > OLD > In particular, an I-JSON sender MUST NOT expect a receiver to treat > an integer whose absolute value is greater than 9007199254740991 > (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact > value. > NEW > In particular, an I-JSON sender SHOULD NOT generate a numeric integer > value greater than 9007199254740991 (i.e., that is outside the range > [-(2**53)+1, (2**53)-1]), since a receiving implementation is likely > not to treat it as an exact value. I assume your omission of =E2=80=9Cabsolute=E2=80=9D is an oversight not an intentional change? Thus: In particular, an I-JSON sender SHOULD NOT generate a numeric integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]), since a receiving implementation is unlikely to treat it as an exact value. > 3 - What > I object to is this protocol document saying that I MUST NOT act on it in > any way. Let me suggest a replacement: > > A major advantage of using I-JSON is that receivers can avoid > ambiguous semantics in the JSON messages it receives. This allows > receivers to reject or otherwise disregard messages which do not > conform to the requirements in this document for I-JSON messages. > Protocols that use I-JSON message can be written so that receiving > implementation are required to reject (or, as in the case of security > protocols, not trust) messages that do not satisfy the constraints of > I-JSON. This feels like a substantial change from where the WG had consensus. I could live with it. Others? From nobody Thu Oct 16 16:16:28 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE131A8F3B for ; Thu, 16 Oct 2014 16:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Nv2_pCr1ei3 for ; Thu, 16 Oct 2014 16:16:24 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98371A8F34 for ; Thu, 16 Oct 2014 16:16:23 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s9GNGLM7008335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 19:16:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1413501382; bh=+xXOPp1C3nZfRJ2LH7W1kNGsJTjgK/pEJmEN1slKq0E=; h=From:To:Subject:Date:Message-Id:In-Reply-To:Reply-To:Mime-Version: Content-Type:Content-Transfer-Encoding; b=r7T9JWrJtGYPk8NUIFALTNA3qgXRz44+Ze0KciruOsPDwTZFq2fQGvZPlJ26jBOYY bq57VuUcBGOvrbs78Qfmt3IF4Ndpo8FFZ+ahhLRo9G5GLcQyJfhlC5nKMCgwJm1q2P htd22R3vOHxO03rt0Jd12PB/yigdumo7yj7PtTCM= From: "Paul E. Jones" To: "Andrew Newton" , "JSON WG" Date: Thu, 16 Oct 2014 23:16:24 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.21034.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/uKyhPFT4aNT-gWRgzHeVAsqvG7k Subject: Re: [Json] more on schemas, JCR -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 23:16:27 -0000 Andy, This spec is being used to help craft the syntax in some work ITU-T SG16= =20 is currently undertaking, so I'm glad to see some forward motion on it. = =20 I do have a few comments. I really appreciate seeing an enumeration in there. That will be very=20 helpful. You introduce the idea of "object mixins", but wasn't that syntax=20 already possible? Did you just introduce the word "mixins" or is this=20 really new syntax? I can appreciate the motivation for "# include", but we cannot automate=20 processing of "Section 3 of RFC XXXX". I guess this wasn't necessarily=20 intended, anyway, but I still think it would be more appropriate to do=20 it this way: # include "http://uri/to/some/file.jcr" ; Section 3 of RFC XXXX I do prefer the original syntax over the proposed alternative. I=20 appreciate the argument that syntax is a matter of taste. However, the=20 purpose of this draft is to define content rules for JSON. So, those=20 making use of it will know JSON. I don't think the alternative is going= =20 to make that any easier or useful. (Of course since I said that, it=20 will now become widely used throughout the industry.) Also, I noted the ABNF was removed from this version. I think having=20 the ABNF there is immensely helpful, as there are many syntax constructs= =20 that are not immediately obvious by just looking at the limited number=20 of examples. I do hope to see the ABNF return in a subsequent version. Paul ------ Original Message ------ From: "Andrew Newton" To: "JSON WG" Sent: 10/15/2014 3:54:50 PM Subject: [Json] more on schemas, JCR -03 >All, > >Continuing the "discussion we are not having", I've updated JSON >Content Rules (JCR) based on feedback I have received from people who >are using it and others. The draft is here: > >URL: >http://www.ietf.org/internet-drafts/draft-newton-json-content-rules-03.txt >Status: >https://datatracker.ietf.org/doc/draft-newton-json-content-rules/ >Htmlized: http://tools.ietf.org/html/draft-newton-json-content-rules-03 >Diff: >http://www.ietf.org/rfcdiff?url2=3Ddraft-newton-json-content-rules-03 From nobody Thu Oct 16 16:30:06 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7093D1A9009 for ; Thu, 16 Oct 2014 16:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFbv228hq7LE for ; Thu, 16 Oct 2014 16:30:04 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC03C1A9007 for ; Thu, 16 Oct 2014 16:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9GNU004022950; Fri, 17 Oct 2014 01:30:00 +0200 (CEST) Received: from [192.168.217.145] (p5489167A.dip0.t-ipconnect.de [84.137.22.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4D61B48B; Fri, 17 Oct 2014 01:29:58 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Fri, 17 Oct 2014 01:29:54 +0200 X-Mao-Original-Outgoing-Id: 435194994.269773-c9685f075f19bd12394e31f240659b46 Content-Transfer-Encoding: quoted-printable Message-Id: <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> References: <54403EBD.9060203@qti.qualcomm.com> To: Tim Bray X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/KvCH_iZO7xkTWLXfBaaGYxPnm10 Cc: Pete Resnick , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 23:30:05 -0000 On 17 Oct 2014, at 00:51, Tim Bray wrote: > greater magnitude or precision > than an IEEE 754 double precision number provides =97 is 1e-400 in or out? =97 this appears to need a definition that allows me to derive the exact = set of JSON numbers (which are decimal) that do not provide more = precision than a binary64 provides (it took about 25 years to get = libraries that get the binary-to-decimal conversion for this mostly = right, CVE-2010-4645 and CVE-2010-4476 being good cases in point; I hope = we are not actually requiring this of every I-JSON transmitter, or, = worse, requiring the detection of superfluous precision by every I-JSON = receiver). Gr=FC=DFe, Carsten From nobody Thu Oct 16 16:38:28 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C9F1A8AA6 for ; Thu, 16 Oct 2014 16:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14JpirrWChaW for ; Thu, 16 Oct 2014 16:38:24 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0410D1A88C7 for ; Thu, 16 Oct 2014 16:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9GNcLbI012356; Fri, 17 Oct 2014 01:38:21 +0200 (CEST) Received: from [192.168.217.145] (p5489167A.dip0.t-ipconnect.de [84.137.22.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5FAB848E; Fri, 17 Oct 2014 01:38:20 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Fri, 17 Oct 2014 01:38:16 +0200 X-Mao-Original-Outgoing-Id: 435195495.904875-477cfe34ac694369f8018346fb31b6cc Content-Transfer-Encoding: quoted-printable Message-Id: References: <54403EBD.9060203@qti.qualcomm.com> To: Tim Bray X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/V__sFkPbqSoVnqqC-CiNeJT7WNc Cc: Pete Resnick , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 23:38:25 -0000 Oh, and I missed this one: On 17 Oct 2014, at 00:51, Tim Bray wrote: > In particular, an I-JSON sender SHOULD NOT generate a numeric > integer whose absolute value is greater than 9007199254740991 (i.e., > that is outside the range [-(2**53)+1, (2**53)-1]), > since a receiving implementation is unlikely to treat it > as an exact value. Is 9007199254740992 a =93numeric integer=94? Is 900719925474099.2e1? Do I have to make sure all my values that are larger than 2**53 have = fractional components? (That conflicts with the precision thing above.) Gr=FC=DFe, Carsten From nobody Thu Oct 16 17:04:58 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0491A87DB for ; Thu, 16 Oct 2014 17:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZvMoyz1comL for ; Thu, 16 Oct 2014 17:04:46 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12D8E1A87A6 for ; Thu, 16 Oct 2014 17:04:45 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id im17so3598579vcb.10 for ; Thu, 16 Oct 2014 17:04:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=4q1foh92UcI0+ao4+txy4Ba9Ei5eYwGUCS1fFf9lhJA=; b=J+mHrt4WtolsyB2K0UhCAc8TZ/n/ektBMLRCGN1aVf0ybYJwRGgrdqv4nOBd+B8MaO kQxvyecsA6FC2e75oBvlnqGh8N8ccweNVTWWhuNzw9ZOLlgejsRupy0kot4/TGYWMi4t Njw2CLP8E9HXBCfaZMb7UkBt7NmUNM++uhw0vWLoHkYKMPDOMcNZnONV0JMpvXO4rl+F u8SJgERbdOgpfS4ssrK5IuCEG9FLKCEJ9PMEz4ESRxRyLHfWQ93hwkXYxrdoDYyR8oGz mQfKfklNMqpcsEjNuoG/+QDBtZbAMUPG15n6+6i15UTV0sEGdRYURUzW91xXuwb3n6eu F34Q== X-Gm-Message-State: ALoCoQnEcOMSd7EMCpyNeLkBhbKRlJXvAr+0QDm1hNyyt/CJu/QSdPDWDn7irDpisj4Qb9zs1qmG X-Received: by 10.220.143.16 with SMTP id s16mr3986510vcu.53.1413504284326; Thu, 16 Oct 2014 17:04:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.160.135 with HTTP; Thu, 16 Oct 2014 17:04:24 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> From: Tim Bray Date: Thu, 16 Oct 2014 17:04:24 -0700 Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/GaFQz-V4-e74Kf6Huw_lirW932o Cc: Pete Resnick , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 00:04:51 -0000 Carsten, I don=E2=80=99t think it=E2=80=99s that bad. For floating-point qu= antities, if inside your program they=E2=80=99re actually 754-compliant you can just = use %g or %ld or whatever on them and you should be safe. If you=E2=80=99re dealing with bignums inside your program then yeah, your JSON generator is going to have to have a normalize_to_ieee function and that=E2=80=99s a good thing, because otherwise you could accidentally e= nd up sending monster values that would actually break real-world receivers. What are some scenarios where this would be hard to comply with? On Thu, Oct 16, 2014 at 4:29 PM, Carsten Bormann wrote: > On 17 Oct 2014, at 00:51, Tim Bray wrote: > >> greater magnitude or precision >> than an IEEE 754 double precision number provides > > =E2=80=94 is 1e-400 in or out? > =E2=80=94 this appears to need a definition that allows me to derive the = exact set of JSON numbers (which are decimal) that do not provide more prec= ision than a binary64 provides (it took about 25 years to get libraries tha= t get the binary-to-decimal conversion for this mostly right, CVE-2010-4645= and CVE-2010-4476 being good cases in point; I hope we are not actually re= quiring this of every I-JSON transmitter, or, worse, requiring the detectio= n of superfluous precision by every I-JSON receiver). > > Gr=C3=BC=C3=9Fe, Carsten > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) From nobody Thu Oct 16 19:14:45 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8701A884E for ; Thu, 16 Oct 2014 19:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-dPsJNg9SmV for ; Thu, 16 Oct 2014 19:14:43 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id AAD511A1BA4 for ; Thu, 16 Oct 2014 19:14:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,735,1406556000"; d="scan'208";a="245586852" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 17 Oct 2014 13:02:56 +1100 X-IronPort-AV: E=McAfee;i="5600,1067,7593"; a="257550677" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcbvi.tcif.telstra.com.au with ESMTP; 17 Oct 2014 13:13:51 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Fri, 17 Oct 2014 13:13:51 +1100 From: "Manger, James" To: Carsten Bormann , Tim Bray , Pete Resnick , "json@ietf.org" Date: Fri, 17 Oct 2014 13:13:49 +1100 Thread-Topic: [Json] AD Evaluation of draft-ietf-json-i-json-03 Thread-Index: Ac/pmSE8CyUkT2dlTRSpbaVr8NNOqAAABIsw Message-ID: <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> In-Reply-To: <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/wQqgn9Rih4a4J3K7yCH3dJg2vfU Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 02:14:44 -0000 +1 to Carsten's comment. Pete Resnick's suggestion is not an improvement. ECMAScript 5.1 =A79.8.1 "ToString Applied to the Number Type" specifies tha= t integers with up to 20 digits are written as plain integers (no exponent)= , eg 9555444333222111000. I-JSON better not make this normal output from JSON.stringify() invalid. The I-JSON rules on numbers are aimed primarily at people *designing* JSON = types. If you have an integer field (eg a serial number) that will always b= e < 2^53 then a JSON number is a good choice. If you have a 64-bit integer = field then a JSON number is a bad choice -- your spec for this type cannot = call itself I-JSON. "MUST NOT expect" and "MUST NOT assume" apply to *designers*. -- James Manger -----Original Message----- From: json [mailto:json-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Friday, 17 October 2014 10:30 AM To: Tim Bray Cc: Pete Resnick; json@ietf.org Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 On 17 Oct 2014, at 00:51, Tim Bray wrote: > greater magnitude or precision > than an IEEE 754 double precision number provides - is 1e-400 in or out? - this appears to need a definition that allows me to derive the exact set = of JSON numbers (which are decimal) that do not provide more precision than= a binary64 provides (it took about 25 years to get libraries that get the = binary-to-decimal conversion for this mostly right, CVE-2010-4645 and CVE-2= 010-4476 being good cases in point; I hope we are not actually requiring th= is of every I-JSON transmitter, or, worse, requiring the detection of super= fluous precision by every I-JSON receiver). Gr=FC=DFe, Carsten _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json From nobody Fri Oct 17 07:44:40 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62DC1A010C for ; Fri, 17 Oct 2014 07:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvbiIo44RAvN for ; Fri, 17 Oct 2014 07:44:37 -0700 (PDT) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2251A001B for ; Fri, 17 Oct 2014 07:44:37 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id hz1so940481pad.22 for ; Fri, 17 Oct 2014 07:44:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RCVZEzvoKBtodbOF/RApX0z2Jk2/cK1sQlZ2RCMFR0s=; b=WqSUNCD03BtpuLRzSuEthfwIKsPNTpRym2zBpl0wgfvdp4k/tN6Bf5w1s1iibhi++Q ECIhKPVGRtoe8eB9gXRWRXAUOi2tsUDoQAWIlWRVWVPbnc8EyUeDno8FJvCHndf9FxUz YZnfeYWeF//bM7RRNk2PKU4Bz78zioCC2QrdRHOYqQ4fR8TsSMw54OHwkzhNO6t4kmJ7 TJegYLg/sU71pbgpUqkS/x1oXQxWUEThJCVaeCqsWpzQ5C2GZKueARAPxhUh84rS6reo JM43jwR973UEwViIguE8046Qjht0DIeHcbKWdfetx69FR4XEUQ0rKplq44KSKbV9Lw6y qJ8g== X-Gm-Message-State: ALoCoQmuu/xEJGYFqd0NHI5VtwbGfiJ0aGGQ/uMWfFSLPAf9GCSN77z8q0XbZU2SEXyJkjTbY8vy MIME-Version: 1.0 X-Received: by 10.68.235.103 with SMTP id ul7mr8958460pbc.63.1413557071783; Fri, 17 Oct 2014 07:44:31 -0700 (PDT) Received: by 10.66.194.13 with HTTP; Fri, 17 Oct 2014 07:44:31 -0700 (PDT) X-Originating-IP: [2001:500:4:15:b06f:87b2:a62d:2e2] In-Reply-To: References: Date: Fri, 17 Oct 2014 10:44:31 -0400 Message-ID: From: Andrew Newton To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/2NcLNM3fzDOjW7VpPT5mpz5wFD8 Cc: JSON WG Subject: Re: [Json] more on schemas, JCR -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:44:38 -0000 Paul, Thanks for your comments and review. On Thu, Oct 16, 2014 at 7:16 PM, Paul E. Jones wrote: > You introduce the idea of "object mixins", but wasn't that syntax already > possible? Did you just introduce the word "mixins" or is this really new > syntax? That syntax was already present with the group rule, it just wasn't obvious that mixins were possible with it. I hope you find the concept useful. > I can appreciate the motivation for "# include", but we cannot automate > processing of "Section 3 of RFC XXXX". I guess this wasn't necessarily > intended, anyway, but I still think it would be more appropriate to do it > this way: > > # include "http://uri/to/some/file.jcr" ; Section 3 of RFC XXXX I agree. Your approach is better. > I do prefer the original syntax over the proposed alternative. I appreciate > the argument that syntax is a matter of taste. However, the purpose of this > draft is to define content rules for JSON. So, those making use of it will > know JSON. I don't think the alternative is going to make that any easier > or useful. (Of course since I said that, it will now become widely used > throughout the industry.) I prefer the original syntax as well. If nobody finds the alternative syntax useful, it should be removed. > Also, I noted the ABNF was removed from this version. I think having the > ABNF there is immensely helpful, as there are many syntax constructs that > are not immediately obvious by just looking at the limited number of > examples. I do hope to see the ABNF return in a subsequent version. I plan to put it back once syntax issues are settled. Thanks. -andy From nobody Fri Oct 17 10:49:35 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B911A0052 for ; Fri, 17 Oct 2014 10:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObNQ8cZ7WUdT for ; Fri, 17 Oct 2014 10:49:33 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3CD1A00E8 for ; Fri, 17 Oct 2014 10:49:32 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id n15so1094573lbi.11 for ; Fri, 17 Oct 2014 10:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xS/F+pr1CkgnUiIHE73dgpzXGZgL5Qw91hXEqSYaOSE=; b=ssXiCVRiiQr5SXNrxX/Of57pD7U2B7Yy3bKiHpMZpPX0Qtm41pXTtp/DnIERjq8HO9 P34BYjTfPtDgoI8Y39pa41oii2nC2yFAAheEOVd32DqBU64NpJEne0WqMSDwfUzCxnKC xR8smKWePma9wwEvx0PHvfy5+7InywXuAA+wEhwvY/5jKwcV8NTFfAPvILeIEbxJQoqt pMHPudtOaC9yeMJv4ExE5t9HMFGo0kS/w98iN2i6nc4e8cU+7F8S2Oymxii8oSRKkLRH fIaaN3vBX8Yxb/8y3rmRBLseSZNmeCmbrVxcv/0Ut5SoM8S0RJPyahCAo2TqzFOpeg+6 C1bg== MIME-Version: 1.0 X-Received: by 10.152.243.8 with SMTP id wu8mr10360337lac.21.1413568170223; Fri, 17 Oct 2014 10:49:30 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Fri, 17 Oct 2014 10:49:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Oct 2014 13:49:29 -0400 X-Google-Sender-Auth: 8NWCMLD23LFbKUjT0mem8-PH-Zg Message-ID: From: Phillip Hallam-Baker To: Andrew Newton Content-Type: multipart/alternative; boundary=001a1133f704a6fa700505a1fcd8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/nja-2gHaHuRHZJu1DFI_8Gd7YUA Cc: "Paul E. Jones" , JSON WG Subject: Re: [Json] more on schemas, JCR -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 17:49:34 -0000 --001a1133f704a6fa700505a1fcd8 Content-Type: text/plain; charset=UTF-8 Since Andy asked, here is a rough draft describing my alternative approach: https://tools.ietf.org/id/draft-hallambaker-protogen-00 To see specifications generated using the tool take a look at: http://prismproof.org/resources.html#specifications All the JSON specifications are generated from schemas described with protogen. All the examples are produced by code generated from the same code. This ensures that the code and data are always locked. On the topic of syntax, I really don't care very much. I am going to use my occam style syntax which was adopted by python. The existing parser does accept braces as an alternative to indentation for control. So this is my preferred style: Structure Site Description |A site location String Country Description |ISO ALPHA-2 Country Code. String precision Decimal Latitude Decimal Longitude String Address String City String State String Zip But the following is accepted: Structure Site { String Country { ... } .... } If people really like I can make the lexer ignore semicolons but the parser does not need them. Unlike my comp sci undergrad lecturer I knew that Chomsky's LR(1) model is designed to describe human languages. I have from time to time considered writing a parser that would accept either RFC 4627 JSON syntax or a python style syntax. all it would require is a modification to the lexer. Which is fairly straightforward as that is generated using a tool. Whether the syntax specifies or is something I keep changing my mind on. It is certainly more consistent to use the latter but C switches between the first and the second. --001a1133f704a6fa700505a1fcd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since Andy asked, here is a rough draft describing my alte= rnative approach:

https://tools.ietf.org/id/draft-hallambaker-protogen-00

All the JSON specifications are generated from schemas described with prot= ogen. All the examples are produced by code generated from the same code. T= his ensures that the code and data are always locked.

<= div>
On the topic of syntax, I really don't care very muc= h. I am going to use my occam style syntax which was adopted by python. The= existing parser does accept braces as an alternative to indentation for co= ntrol.

So this is my preferred style:
=C2=A0 =C2=A0 = Structure Site
=C2=A0 =C2=A0 Description
=C2=A0 =C2=A0 |A site location
=C2=A0 =C2=A0= String Country
=C2=A0 =C2=A0 Description
=C2=A0 = =C2=A0 |ISO ALPHA-2 Co= untry Code.
=C2=A0 =C2=A0 String preci= sion
=C2=A0 =C2=A0 Decimal Latitude
=C2=A0 =C2=A0 De= cimal Longitude
=C2=A0 =C2=A0 String Address
=C2=A0 = =C2=A0 String City
=C2=A0 =C2=A0 String State
=C2=A0 =C2=A0 String Zip

But the following is = accepted:

Structure Site {
=C2=A0 = =C2=A0 String Country {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ....
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

<= /div>
If people really like I can make the lexer ignore semicolons but = the parser does not need them. Unlike my comp sci undergrad lecturer I knew= that Chomsky's LR(1) model is designed to describe human languages.

I have from time to time considered writing a parser= that would accept either RFC 4627 JSON syntax or a python style syntax. al= l it would require is a modification to the lexer. Which is fairly straight= forward as that is generated using a tool.

Whether= the syntax specifies <type> <identifier> or <identifier>= <type> is something I keep changing my mind on. It is certainly more= consistent to use the latter but C switches between the first and the seco= nd.=C2=A0
--001a1133f704a6fa700505a1fcd8-- From nobody Fri Oct 17 11:19:50 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615431A00F0 for ; Fri, 17 Oct 2014 11:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe3tyfiK7wag for ; Fri, 17 Oct 2014 11:19:45 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176D51A0007 for ; Fri, 17 Oct 2014 11:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413569985; x=1445105985; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=XdtSLrZMRa7SIgI1QkCBPfhl84XwnY2JtF016TDw82s=; b=sxRmsleLiT8m3/I7SAxVUa9peABnoAp2+/FTEgvvN1m2iKL4Z8/qNoa2 P5CSem/vZ95wj4L+ydIoQm5vVior67zZBkMO8HpG8nNaII2S1mz2lqsaF OR6Xt7KtSzj63uEQU8sfDh5oQPB+yMGI/HEGO99cHIFAgs8+bsox3vSyu U=; X-IronPort-AV: E=McAfee;i="5600,1067,7594"; a="75718183" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine01.qualcomm.com with ESMTP; 17 Oct 2014 11:19:44 -0700 X-IronPort-AV: E=Sophos; i="5.04,740,1406617200"; d="scan'208,217"; a="30809513" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Oct 2014 11:19:43 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 17 Oct 2014 11:19:42 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 17 Oct 2014 11:19:42 -0700 Message-ID: <54415DBB.3090701@qti.qualcomm.com> Date: Fri, 17 Oct 2014 13:19:39 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Manger, James" References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="------------040702020104080305040208" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.46.201.191) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/json/8SeDMgseMTX5V-IJsgIAS3JNGoM Cc: Carsten Bormann , Tim Bray , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:19:47 -0000 --------------040702020104080305040208 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit On 10/16/14 9:13 PM, Manger, James wrote: > ECMAScript 5.1 §9.8.1 "ToString Applied to the Number Type" specifies that integers with up to 20 digits are written as plain integers (no exponent), eg 9555444333222111000. > I-JSON better not make this normal output from JSON.stringify() invalid. > Why not? I thought this was *exactly* what the purpose of I-JSON: To limit otherwise valid JSON productions within some particular constraints. If your implementation passes numbers to JSON.stringify() that are too large to be interpreted by an I-JSON interpreter, that output from JSON.stringify is *invalid* I-JSON and you've implemented the I-JSON spec incorrectly. > The I-JSON rules on numbers are aimed primarily at people*designing* JSON types. If you have an integer field (eg a serial number) that will always be< 253 then a JSON number is a good choice. If you have a 64-bit integer field then a JSON number is a bad choice -- your spec for this type cannot call itself I-JSON. > MUST and SHOULD and the like to describe issues of interoperability and potential harm. If I am handed a block of text that purports to be I-JSON, whatever produced it best have followed I-JSON requirements in order to interoperate with me. That means that if the implementation is going to use a generic JSON.stringify() function, it's going to need to (i.e., MUST) do a range check beforehand. This is about implementation, not design. > "MUST NOT expect" and "MUST NOT assume" apply to*designers*. > Except that they are misuses of the term "MUST NOT". I don't know how to implement a "MUST NOT expect" or "MUST NOT assume". pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------040702020104080305040208 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 10/16/14 9:13 PM, Manger, James wrote: 
ECMAScript 5.1 §9.8.1 "ToString Applied to the Number Type" specifies that integers with up to 20 digits are written as plain integers (no exponent), eg 9555444333222111000.
I-JSON better not make this normal output from JSON.stringify() invalid.

Why not? I thought this was *exactly* what the purpose of I-JSON: To limit otherwise valid JSON productions within some particular constraints. If your implementation passes numbers to JSON.stringify() that are too large to be interpreted by an I-JSON interpreter, that output from JSON.stringify is *invalid* I-JSON and you've implemented the I-JSON spec incorrectly.

The I-JSON rules on numbers are aimed primarily at people *designing* JSON types. If you have an integer field (eg a serial number) that will always be < 253 then a JSON number is a good choice. If you have a 64-bit integer field then a JSON number is a bad choice -- your spec for this type cannot call itself I-JSON.

MUST and SHOULD and the like to describe issues of interoperability and potential harm. If I am handed a block of text that purports to be I-JSON, whatever produced it best have followed I-JSON requirements in order to interoperate with me. That means that if the implementation is going to use a generic JSON.stringify() function, it's going to need to (i.e., MUST) do a range check beforehand. This is about implementation, not design.

"MUST NOT expect" and "MUST NOT assume" apply to *designers*.

Except that they are misuses of the term "MUST NOT". I don't know how to implement a "MUST NOT expect" or "MUST NOT assume".

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------040702020104080305040208-- From nobody Fri Oct 17 11:27:32 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D6E1A19F8 for ; Fri, 17 Oct 2014 11:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zkkuk-MmhsD9 for ; Fri, 17 Oct 2014 11:27:25 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084C41A1A0D for ; Fri, 17 Oct 2014 11:27:14 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hy10so1032158vcb.1 for ; Fri, 17 Oct 2014 11:27:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=bIykEYs3AG0l3QjFCFBsq9/S0pqkF/GQKM1JHqRG0Jw=; b=RmlKXdFV3gVyff9InkLOMF9htBPZ8w7zi7f2NGu9yBMoKoYNP/gFfBcHLRomw0PAtD zz5aIr/Mrrg+9QdC5tm55s6AUkYUdWz2WlOVA0+L8MssS9Co5Mysz1NHjvmKBw6zq+sB 0oK3TmwvMvC82eeqJRiHbenUFGYeleWb7/EDc8iFZyHHrzYf8LzxmVcE0ETL4yNawKHp +MaPIIBK7/fDpgrGV3Qqzl7RVLdDb6LbeJZK+U91pHE5+9870czkyhG5PRl2WPG4Fd8x gZTdEydL0WJ4giEsCfT2ffnSoSmK8BlEHbvT9vX9tHFrt8L7Xm5yHygkpBCAnRKKhkga 9tHw== X-Gm-Message-State: ALoCoQkaCHqUpMXKfW//iKxoIfOEhQ+Pq0qIwjoEgFeWSEYDBAxCBq/h9kGLSXn2tKZ9roDy/HPD X-Received: by 10.220.162.196 with SMTP id w4mr8934051vcx.30.1413570434230; Fri, 17 Oct 2014 11:27:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.160.135 with HTTP; Fri, 17 Oct 2014 11:26:53 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <54415DBB.3090701@qti.qualcomm.com> References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> From: Tim Bray Date: Fri, 17 Oct 2014 11:26:53 -0700 Message-ID: To: Pete Resnick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/MQpRaN-dV3Ktr88RjRUdkmMbiOM Cc: Carsten Bormann , "Manger, James" , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:27:27 -0000 Yeah, what Pete said. If your ECMAScript program wants to interoperate with the rest of the Internet, it really needs to be a little bit careful about the size of numbers it emits. On Fri, Oct 17, 2014 at 11:19 AM, Pete Resnick wrote: > On 10/16/14 9:13 PM, Manger, James wrote: > > ECMAScript 5.1 =C2=A79.8.1 "ToString Applied to the Number Type" specifie= s that > integers with up to 20 digits are written as plain integers (no exponent)= , > eg 9555444333222111000. > I-JSON better not make this normal output from JSON.stringify() invalid. > > > > Why not? I thought this was *exactly* what the purpose of I-JSON: To limi= t > otherwise valid JSON productions within some particular constraints. If y= our > implementation passes numbers to JSON.stringify() that are too large to b= e > interpreted by an I-JSON interpreter, that output from JSON.stringify is > *invalid* I-JSON and you've implemented the I-JSON spec incorrectly. > > The I-JSON rules on numbers are aimed primarily at people *designing* JSO= N > types. If you have an integer field (eg a serial number) that will always= be > < 253 then a JSON number is a good choice. If you have a 64-bit integer > field then a JSON number is a bad choice -- your spec for this type canno= t > call itself I-JSON. > > > > MUST and SHOULD and the like to describe issues of interoperability and > potential harm. If I am handed a block of text that purports to be I-JSON= , > whatever produced it best have followed I-JSON requirements in order to > interoperate with me. That means that if the implementation is going to u= se > a generic JSON.stringify() function, it's going to need to (i.e., MUST) d= o a > range check beforehand. This is about implementation, not design. > > "MUST NOT expect" and "MUST NOT assume" apply to *designers*. > > > > Except that they are misuses of the term "MUST NOT". I don't know how to > implement a "MUST NOT expect" or "MUST NOT assume". > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) From nobody Fri Oct 17 11:29:19 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7DE1A03AA for ; Fri, 17 Oct 2014 11:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGM2OxtmUEtR for ; Fri, 17 Oct 2014 11:29:10 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC8C1A0154 for ; Fri, 17 Oct 2014 11:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9HIT7mC015098; Fri, 17 Oct 2014 20:29:07 +0200 (CEST) Received: from [192.168.217.113] (p54890598.dip0.t-ipconnect.de [84.137.5.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F1402BC6; Fri, 17 Oct 2014 20:29:03 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: <54415DBB.3090701@qti.qualcomm.com> Date: Fri, 17 Oct 2014 20:28:53 +0200 X-Mao-Original-Outgoing-Id: 435263333.636765-64bd8a944b226be74694888a0ba01796 Content-Transfer-Encoding: quoted-printable Message-Id: <3EC1FA83-69B2-4903-AB88-82156C7F6A51@tzi.org> References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/json/OFB10ix4AKCK2s6ZGMANggw5oTI Cc: Tim Bray , "Manger, James" , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:29:12 -0000 On 17 Oct 2014, at 20:19, Pete Resnick = wrote: >=20 >> ECMAScript 5.1 =A79.8.1 "ToString Applied to the Number Type" = specifies that integers with up to 20 digits are written as plain = integers (no exponent), eg 9555444333222111000. >> I-JSON better not make this normal output from JSON.stringify() = invalid. >> =20 >>=20 >=20 > Why not? I thought this was *exactly* what the purpose of I-JSON: To = limit otherwise valid JSON productions within some particular = constraints. If your implementation passes numbers to JSON.stringify() = that are too large to be interpreted by an I-JSON interpreter, that = output from JSON.stringify is *invalid* I-JSON and you've implemented = the I-JSON spec incorrectly. I think James=92 point was that there is no known interoperability = problem with exchanging, say, 2**55. So the text, as changed, rules out = interchange that is unproblematic. Gr=FC=DFe, Carsten > JSON.stringify(Math.pow(2, 55)) '36028797018963970' > JSON.stringify(Math.pow(2, 55)+10) '36028797018963976' > JSON.stringify(Math.pow(2, 55)-10) '36028797018963960' > JSON.stringify(Math.pow(2, 55)+20) '36028797018963980' > JSON.stringify(Math.pow(2, 55)-20) =9136028797018963948' From nobody Fri Oct 17 11:35:39 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B821A1A14 for ; Fri, 17 Oct 2014 11:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.888 X-Spam-Level: X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93l-2NBteLDU for ; Fri, 17 Oct 2014 11:35:35 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE9C1A1A21 for ; Fri, 17 Oct 2014 11:35:35 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id pn19so1184521lab.28 for ; Fri, 17 Oct 2014 11:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TrydfhwFRkfERBl5TLE9suTJnBG8SL7iS5GOCklS8vs=; b=zf1f9rihUEopGhUXGGrwzt2Usst/tEx5GYYiackmBnU1GXxj57egur3qXwsUhywOHa FK/LBPSqOd67CwPQp3iYwCbn3dkPDigtZgx/8PlpfxgF9gSgX+u3tb0ADt3xuUAAVExc IFndjhvBpjkgKMBgbhH02UVCGqZTK5xlyW0sryWMPmxo+XwOt8nXXC9q3SpAXRKngWPB rohX6TEIvFzk78/dgVLW+rqzdTnoGt7sC+/+vlfAXcGLbrhiVeFly1llrjsf1T/JkJTF 97PclbaUI/25dnPt5FqLpQODA+Jq+nhWFyEg0AI6hKwifDpm/GkSIg51pTvxwnNvslPO 8ANg== MIME-Version: 1.0 X-Received: by 10.152.243.8 with SMTP id wu8mr10615821lac.21.1413570933411; Fri, 17 Oct 2014 11:35:33 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Fri, 17 Oct 2014 11:35:33 -0700 (PDT) In-Reply-To: References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> Date: Fri, 17 Oct 2014 14:35:33 -0400 X-Google-Sender-Auth: 7Kf1BKVe4BOZIB4VrRgGTF8MjkE Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/bSSLryuTNISR_JI-5renhT-wdfo Cc: Pete Resnick , "Manger, James" , Carsten Bormann , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:35:37 -0000 On Fri, Oct 17, 2014 at 2:26 PM, Tim Bray wrote: > Yeah, what Pete said. If your ECMAScript program wants to interoperate > with the rest of the Internet, it really needs to be a little bit > careful about the size of numbers it emits. I would take a totally different tack and eliminate floats entirely from I-JSON. I have never seen a protocol use of a float as opposed to a decimal fraction. Lattitude and Longitude are decimal fractions, not floats. If we are doing floats then either we don't care about exact precision or we should declare an enhanced version of the spec that can encode floats as hex fractions rather than decimal. Yes, I know you don't want to extend JSON but the inescapable consequence of deciding not to modify your base technology is that you are not going to have a result that is fit for every purpose. If people want to encode science data in a format that can round trip then JSON-I is not going to be that format. Regardless of what curlicues or constraints you attempt there is no possibility that implementations will be sufficiently robust to rely on. From nobody Fri Oct 17 11:46:36 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4AD1A1A9D for ; Fri, 17 Oct 2014 11:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zINl8TKAZQbp for ; Fri, 17 Oct 2014 11:46:30 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA171A1A79 for ; Fri, 17 Oct 2014 11:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413571589; x=1445107589; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=V+IVptcxMComRAKfP3lHH0tB8ZSDVnLM/x4ktC0AHaE=; b=BkHJYALWCFbpQxQN/WyHwqDB5DUwWD+p6eNk1l0iswSP/4erXlh+MZvO QRUOXM03bIQ4dCd7NPpMYT7T4nJDlLzBUmSp0ZwPR/FKxaGZmQ0AcJonV rj8eRm4cFgYNkV8UrZn5BIVBBbjIDlWcLXH0iiztnZsCRj27GcnePHova A=; X-IronPort-AV: E=McAfee;i="5600,1067,7594"; a="75723736" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Oct 2014 11:46:28 -0700 X-IronPort-AV: E=Sophos;i="5.04,740,1406617200"; d="scan'208";a="771987757" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Oct 2014 11:46:28 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 17 Oct 2014 11:46:27 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 17 Oct 2014 11:46:09 -0700 Message-ID: <544163EB.70103@qti.qualcomm.com> Date: Fri, 17 Oct 2014 13:46:03 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Carsten Bormann References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> <3EC1FA83-69B2-4903-AB88-82156C7F6A51@tzi.org> In-Reply-To: <3EC1FA83-69B2-4903-AB88-82156C7F6A51@tzi.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.46.201.191) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/json/c23FHOLPjGpvZC0sfFUT2rGi0dY Cc: "Manger, James" , Tim Bray , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:46:31 -0000 On 10/17/14 1:28 PM, Carsten Bormann wrote: > I think James’ point was that there is no known interoperability problem with exchanging, say, 2**55. So the text, as changed, rules out interchange that is unproblematic. > Ah, that's a different kettle of fish, but makes the original text no less problematic. If there's an interoperability problem, use a MUST NOT and tell me what that interoperability problem is. If there isn't an interoperability problem, don't use MUST NOT. I'm not committed to my text if I've gotten the requirement wrong; the text just needs to state a proper requirement (if there is one). pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Fri Oct 17 17:57:56 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351011A000E for ; Fri, 17 Oct 2014 17:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3jjB6ntWcZS for ; Fri, 17 Oct 2014 17:57:53 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575831A0006 for ; Fri, 17 Oct 2014 17:57:53 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1XfIKx-00062I-K9; Fri, 17 Oct 2014 20:57:39 -0400 Date: Fri, 17 Oct 2014 20:57:39 -0400 From: John Cowan To: Pete Resnick Message-ID: <20141018005739.GE12268@mercury.ccil.org> References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54415DBB.3090701@qti.qualcomm.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/3nSi_ASEqpAJViu18ugsOX8Ez3o Cc: Tim Bray , Carsten Bormann , "Manger, James" , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 00:57:55 -0000 Pete Resnick scripsit: > Why not? I thought this was *exactly* what the purpose of I-JSON: To > limit otherwise valid JSON productions within some particular > constraints. If your implementation passes numbers to > JSON.stringify() that are too large to be interpreted by an I-JSON > interpreter, that output from JSON.stringify is *invalid* I-JSON and > you've implemented the I-JSON spec incorrectly. Doubtless: if you don't comply, you are non-compliant. But "is" does not imply "ought". Whatever rules I-JSON imposes ought not to disallow the behavior of ECMAScript JSON encoders and decoders. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org A: "Spiro conjectures Ex-Lax." Q: "What does Pat Nixon frost her cakes with?" --"Jeopardy" for generative semanticists From nobody Sat Oct 18 14:14:08 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC38C1A1A79 for ; Sat, 18 Oct 2014 14:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.112 X-Spam-Level: X-Spam-Status: No, score=-5.112 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5_b_AIE94HZ for ; Sat, 18 Oct 2014 14:14:03 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACCA91A005B for ; Sat, 18 Oct 2014 14:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413666843; x=1445202843; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TYrkB/zDbJjKKLL+YdzyQGuacJN1hjz4ze36O90AVVk=; b=KWQ5hglWautfpmoF/DYNKE8mUga7rUe+fO4ebWIM5E0Zuoflxk/krhF/ QuW+VywQGaOJl1rezlJS0s83gJt5e+xx9y2QzF996hO/8RtuaRsxW/gPH 2Qp4z2hX9kW6Ro9z66EIwu1m+cUYwUhpRNPIouxvDvLtmlCPhA8MkpIje I=; X-IronPort-AV: E=McAfee;i="5600,1067,7595"; a="75947863" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Oct 2014 14:14:02 -0700 X-IronPort-AV: E=Sophos;i="5.04,745,1406617200"; d="scan'208";a="772549103" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Oct 2014 14:14:02 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 18 Oct 2014 14:14:01 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sat, 18 Oct 2014 14:14:01 -0700 Message-ID: <5442D816.9090107@qti.qualcomm.com> Date: Sat, 18 Oct 2014 16:13:58 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: John Cowan References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> <20141018005739.GE12268@mercury.ccil.org> In-Reply-To: <20141018005739.GE12268@mercury.ccil.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.46.201.191) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/json/qKuEI4XkHzkRmJGy7y95tNs6Es0 Cc: "Manger, James" , Carsten Bormann , Tim Bray , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 21:14:06 -0000 On 10/17/14 7:57 PM, John Cowan wrote: > Pete Resnick scripsit: > > >> Why not? I thought this was *exactly* what the purpose of I-JSON: To >> limit otherwise valid JSON productions within some particular >> constraints. If your implementation passes numbers to >> JSON.stringify() that are too large to be interpreted by an I-JSON >> interpreter, that output from JSON.stringify is *invalid* I-JSON and >> you've implemented the I-JSON spec incorrectly. >> > Doubtless: if you don't comply, you are non-compliant. But "is" does not > imply "ought". Whatever rules I-JSON imposes ought not to disallow the > behavior of ECMAScript JSON encoders and decoders. > "Is" implies "ought" *in the context of implementing the standard*. As a general rule, we don't write compliance standards in the IETF; we write interoperability standards. "MUST" means "do it this way or you're not going to interoperate with someone who is also implementing this standard". If you are implementing an I-JSON encoder, you *ought* not blindly pass things to an ECMAScript JSON encoder, because an I-JSON decoder might fail to interpret what you send correctly. In the context of I-JSON, the behavior of an ECMAScript encoder *is* disallowed by the standard, in the sense that if you use one, you're going to produce some JSON which does not interoperate with other I-JSON implementations. (In James terminology, the normal output from JSON.stringify() *can* be invalid I-JSON.) If you want to use your ECMAScript JSON encoder to implement regular old JSON, have at it; that's not disallowed. Heck, if you want to use it to produce scrambled eggs, more power to you if you can pull it off. But it's not appropriate (by itself, without adding on extra code or external modules) to use it to produce I-JSON. I hope we're saying the same thing in two different ways, just looking at opposite ends of the elephant. Otherwise, I'm pretty mystified. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sat Oct 18 15:54:34 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454031A19FF for ; Sat, 18 Oct 2014 15:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lj6jJCghnJW5 for ; Sat, 18 Oct 2014 15:54:31 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13BDD1A0011 for ; Sat, 18 Oct 2014 15:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9IMsRmI016412; Sun, 19 Oct 2014 00:54:27 +0200 (CEST) Received: from [192.168.217.113] (p54892213.dip0.t-ipconnect.de [84.137.34.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AD1B4FBF; Sun, 19 Oct 2014 00:54:26 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: <5442D816.9090107@qti.qualcomm.com> Date: Sun, 19 Oct 2014 00:54:25 +0200 X-Mao-Original-Outgoing-Id: 435365665.429734-dd2b98a5417712462bae8cd2c148be0d Content-Transfer-Encoding: quoted-printable Message-Id: References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> <20141018005739.GE12268@mercury.ccil.org> <5442D816.9090107@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/json/sYQKh9SFzynTgBIazMV-WtBVuyM Cc: Tim Bray , "Manger, James" , John Cowan , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 22:54:33 -0000 On 18 Oct 2014, at 23:13, Pete Resnick = wrote: >=20 > If you are implementing an I-JSON encoder, you *ought* not blindly = pass things to an ECMAScript JSON encoder, because an I-JSON decoder = might fail to interpret what you send correctly. I don=E2=80=99t think this is what the WG intended to do. Since the ECMAscript JSON encoder is the 800 pound gorilla here (and = everybody else will make sure they can read at least that), and the = ECMAscript number system is the most restricted one that we want to = cater for, there is no point disallowing anything that comes up = naturally out of the ECNAscript JSON encoder. In other words: If we define I-JSON in such a way that it requires extra = work from a JavaScript programmer, it will not see much use. All the = extra work goes to everyone else. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Oct 18 16:12:22 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95371A1A30 for ; Sat, 18 Oct 2014 16:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-BYt5uHvxXu for ; Sat, 18 Oct 2014 16:12:18 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2E81A19F8 for ; Sat, 18 Oct 2014 16:12:18 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id lf12so2115853vcb.3 for ; Sat, 18 Oct 2014 16:12:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=HnNgsb22xDr3x7Hx6ca1i1r19dc3XgADPas3QMX035E=; b=dIyDQ+ex5z9duvqY9uDTycxi8K11VSwRj2CB/jnX3iCXl4l6NSg6zapIp9ffXkfI7L YTlIsFpxJVXTdU6LQ7TGYwmyjPPB/Qm/hCMZN5WVUXwvNvlwbS5mVoZjftfB+Z3e0DP/ nCCVsk+8M4+jpwYDlDtddZxj7x0eskMc98QqE//FDOF3JTzH0JRCZ82frLS8Tz62/qnU Sdqc55RxOVcQmiAu4x8omPwoAHwGcccAEepD06ztazdhhcsRCGZgqjGGizLtPUpHToUK e10xHPVZAR5PDHOMtDK1FSd2I2/ssyXvGgubdl80wvmzrrPS1Fd+erz2dezG7irNXONY jcKw== X-Gm-Message-State: ALoCoQmADLi82RwUxLlrm56JwvIjMHROK9JBNEaRyaHsUmPZPrBHDqNOk14I1XR5Mjom7t+hZVEv X-Received: by 10.52.29.131 with SMTP id k3mr7992628vdh.2.1413673937401; Sat, 18 Oct 2014 16:12:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.160.135 with HTTP; Sat, 18 Oct 2014 16:11:57 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> <20141018005739.GE12268@mercury.ccil.org> <5442D816.9090107@qti.qualcomm.com> From: Tim Bray Date: Sat, 18 Oct 2014 16:11:57 -0700 Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/pMarbqIKCXyqD3ziWtrUJAQfECU Cc: John Cowan , Pete Resnick , "Manger, James" , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 23:12:20 -0000 Right, but I think we=E2=80=99re actually in harmony. ECMAScript specifies that numbers are IEEE 754 doubles, so there should be no impedance mismatch with I-JSON. What our draft said was =E2=80=9Cdon=E2=80=99t count on any more precision/= range than 754 doubles, and in particular don=E2=80=99t try to interchange integers wi= th more than53 bits=E2=80=9D and I think it did an OK job of saying that. Pet= e points out accurately that it would be more within the spirit of 2119 language to say =E2=80=9CI-JSON producers MUST NOT produce anything that fa= lls outside those bounds=E2=80=9D and what I think we=E2=80=99re learning is th= at specifying the forbidden behavior turns out to be hard. Note that languages which have built-in bignums that silently Do The Right Thing, e.g. Ruby and most Lisps, are more apt to produce busted I-JSON than any modern ECMAScript implementation. I have no objection to what Pete=E2=80=99s trying to accomplish here but I have to confess that I so far haven=E2=80=99t been able to think of good language for specifying it. Anyone have suggestion? On Sat, Oct 18, 2014 at 3:54 PM, Carsten Bormann wrote: > On 18 Oct 2014, at 23:13, Pete Resnick wrote: >> >> If you are implementing an I-JSON encoder, you *ought* not blindly pass = things to an ECMAScript JSON encoder, because an I-JSON decoder might fail = to interpret what you send correctly. > > I don=E2=80=99t think this is what the WG intended to do. > > Since the ECMAscript JSON encoder is the 800 pound gorilla here (and ever= ybody else will make sure they can read at least that), and the ECMAscript = number system is the most restricted one that we want to cater for, there i= s no point disallowing anything that comes up naturally out of the ECNAscri= pt JSON encoder. > > In other words: If we define I-JSON in such a way that it requires extra = work from a JavaScript programmer, it will not see much use. All the extra= work goes to everyone else. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) From nobody Sat Oct 18 16:32:09 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92F41A1A29 for ; Sat, 18 Oct 2014 16:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWUoEkmJKg5U for ; Sat, 18 Oct 2014 16:32:05 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875EA1A1A1B for ; Sat, 18 Oct 2014 16:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9INW2G0015567; Sun, 19 Oct 2014 01:32:02 +0200 (CEST) Received: from [192.168.217.113] (p54892213.dip0.t-ipconnect.de [84.137.34.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BDBF1FDF; Sun, 19 Oct 2014 01:32:01 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: Date: Sun, 19 Oct 2014 01:32:00 +0200 X-Mao-Original-Outgoing-Id: 435367920.698739-dbb3309450b34691b9cd0f5cda0b520a Content-Transfer-Encoding: quoted-printable Message-Id: References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> <20141018005739.GE12268@mercury.ccil.org> <5442D816.9090107@qti.qualcomm.com> To: Tim Bray X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/json/XnBva-SHa10eIamNfWaie1jWz44 Cc: "Manger, James" , Pete Resnick , John Cowan , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 23:32:07 -0000 > Note that languages which have built-in bignums that silently Do The > Right Thing, e.g. Ruby and most Lisps, are more apt to produce busted > I-JSON than any modern ECMAScript implementation. (Or any language that has 64-bit numbers, which is pretty much =E2=80=9Can= y modern language but JavaScript=E2=80=9D at this point.) > I have no objection to what Pete=E2=80=99s trying to accomplish here = but I > have to confess that I so far haven=E2=80=99t been able to think of = good > language for specifying it. Anyone have suggestion? We spent quite some time in the WG coming up with text that is capturing = the results of the discussion. Unfortunately, there is no way to look at a JSON file and say whether = the conversion from the source=E2=80=99s internal number representation = to the JSON file represents the intent of the programmer, under the = restrictions of I-JSON. If you see 36028797018963970, there is no way = to find out if the programmer intended that to be a different number = from 36028797018963968 or not (it isn=E2=80=99t in I-JSON). So trying to phrase this in MUST/MUST NOT predicates on the JSON file = will not work. Gr=C3=BC=C3=9Fe, Carsten PS.: 36028797018963968 is the exact decimal representation of the number = 2**55 (which ECMAscript can represent exactly), but: > JSON.stringify(36028797018963968) '36028797018963970=E2=80=99 There are actually good reasons for this behavior, but there is little = point in turning I-JSON into a dissertation about binary to decimal = conversion. There is also absolutely no point in ruling out 36028797018963968. From nobody Sat Oct 18 18:42:49 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE391A000B for ; Sat, 18 Oct 2014 18:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS0XWhDgzhU9 for ; Sat, 18 Oct 2014 18:42:45 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4542E1A0019 for ; Sat, 18 Oct 2014 18:42:45 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1XffVp-0005Eq-Mu; Sat, 18 Oct 2014 21:42:25 -0400 Date: Sat, 18 Oct 2014 21:42:25 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20141019014225.GH12991@mercury.ccil.org> References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> <20141018005739.GE12268@mercury.ccil.org> <5442D816.9090107@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/_HYp68nt0fGe_yAx3BjRpMYxVZE Cc: Tim Bray , Pete Resnick , "Manger, James" , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 01:42:47 -0000 Carsten Bormann scripsit: > Since the ECMAscript JSON encoder is the 800 pound gorilla here > (and everybody else will make sure they can read at least that), > and the ECMAscript number system is the most restricted one that we > want to cater for, there is no point disallowing anything that comes > up naturally out of the ECNAscript JSON encoder. That is exactly what I meant. I-JSON *could* set any limitations it wants to (and then I-JSON users would have to conform). But we don't want to set limitations that disallow what ECMAscript allows. > In other words: If we define I-JSON in such a way that it requires > extra work from a JavaScript programmer, it will not see much use. > All the extra work goes to everyone else. +1 -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org I could dance with you till the cows come home. On second thought, I'd rather dance with the cows when you come home. --Rufus T. Firefly From nobody Sun Oct 19 10:29:59 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638CC1A19F3 for ; Sun, 19 Oct 2014 10:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAWb5lNdmMvn for ; Sun, 19 Oct 2014 10:29:55 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1204A1A19E4 for ; Sun, 19 Oct 2014 10:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413739796; x=1445275796; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/B+XrsOyceTk3UJc56KBbKhGB6ucn31eoB+28i0L9dA=; b=DqBHQoAfIoCcaZpvBFUlZ+Zg9nl4ylD28e46tykjLWkeTYKsWvFq5MQw LiM6mrEwat9iaGrj5cDbuTHMDsbGiCHAYXQNen2oO2G9fOhv/WXIQRCCN 849KNTPwg7llWkhmWTZ605JiZPOMZ930R3zEX+FxE0vky5haD5UkvgT/D w=; X-IronPort-AV: E=McAfee;i="5600,1067,7595"; a="76399973" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 19 Oct 2014 10:29:54 -0700 X-IronPort-AV: E=Sophos;i="5.04,749,1406617200"; d="scan'208";a="30814950" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Oct 2014 10:29:52 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 19 Oct 2014 10:29:51 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sun, 19 Oct 2014 10:29:32 -0700 Message-ID: <5443F4FA.4080001@qti.qualcomm.com> Date: Sun, 19 Oct 2014 12:29:30 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Carsten Bormann References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> <20141018005739.GE12268@mercury.ccil.org> <5442D816.9090107@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.46.200.111) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/json/uKZ58Hgf_UpAPs5PODwmRTcfR1Y Cc: John Cowan , "Manger, James" , Tim Bray , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 17:29:57 -0000 On 10/18/14 6:32 PM, Carsten Bormann wrote: > Unfortunately, there is no way to look at a JSON file and say whether the conversion from the source’s internal number representation to the JSON file represents the intent of the programmer, under the restrictions of I-JSON. If you see 36028797018963970, there is no way to find out if the programmer intended that to be a different number from 36028797018963968 or not (it isn’t in I-JSON). > > So trying to phrase this in MUST/MUST NOT predicates on the JSON file will not work. > I have read the above a dozen times, and I'm still a bit baffled. If I look at some data, and I can't tell what the intent of the generator of that data was regarding the semantics of the data, that is by definition an interoperability problem. We agree that if someone sends me 36028797018963970 as a numeric value in a JSON text (leave aside I-JSON), I can't tell whether they meant it to be identical to 36028797018963968 or not. I hope we also agree that this means if I act on such a value, I might end up doing the wrong thing. Both sides should be told, "Using such a value is non-interoperable; you'd need out of band information to know what to do with it." That's all that "MUST NOT" means in the context of IETF documents. Are we simply disagreeing about the *efficacy* of saying "MUST NOT"? That even if we make it a requirement of the spec, it will be ignored because people won't actually implement the range check? IETF specs are voluntary standards; they're not laws. I thought the whole point of I-JSON was, "If you generate this, the other side will always interpret it correctly." If the spec doesn't say, "In I-JSON, don't use >53 bit integers", what's the point of saying *anything* about number ranges? I am mystified. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sun Oct 19 10:35:52 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48A21A19E7 for ; Sun, 19 Oct 2014 10:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj-5w8t_bamQ for ; Sun, 19 Oct 2014 10:35:49 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59B11A19E4 for ; Sun, 19 Oct 2014 10:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413740150; x=1445276150; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=E3480Jcub7CbJQymyBlm3Y/9P8l8NJyP9PS2bDOKCds=; b=F6YdHc3FhHDmEE3KRqqJafOf2K8tzIuxIKc0OOy7fRbcN2gtE2tCeHHV mfH/org2tkDdWP0N2Qy1D7vWNUjlJbMxLBf7AAa3qRKkilPykNVrP10lT /mcw7IHrkaLVaZqzHkXPdw7xv7NV8LSam+UrcbulfgkJszvuPidNutA0l M=; X-IronPort-AV: E=McAfee;i="5600,1067,7595"; a="77041545" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Oct 2014 10:35:49 -0700 X-IronPort-AV: E=Sophos;i="5.04,749,1406617200"; d="scan'208";a="772867861" Received: from nasanexhc03.na.qualcomm.com ([10.46.200.142]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Oct 2014 10:35:49 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by NASANEXHC03.na.qualcomm.com (10.46.200.142) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 19 Oct 2014 10:35:48 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sun, 19 Oct 2014 10:35:30 -0700 Message-ID: <5443F661.5090404@qti.qualcomm.com> Date: Sun, 19 Oct 2014 12:35:29 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "json@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.46.200.111) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/json/wm9ihEW8hO4YsYo63ihyPP-fKnk Subject: [Json] AD Evaluation of draft-ietf-json-text-sequence-07 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 17:35:51 -0000 I hope these comments are helpful: 2 - Editorial: An "ABNF rule" (as the term is used in 5234) is a single line. I think what you want is: NEW Two different sets of ABNF rules are provided for the definition of JSON text sequences: one for parsers, and one for encoders. Having two different sets of rules permits recovery by parsers from sequences where some the elements are truncated for whatever reason. The syntax for parsers is specified in terms of octet strings which are then interpreted as JSON-texts if possible. The syntax for encoders, on the other hand, assumes that sequence elements are not truncated. 2.1/2.2 - Why use the reference to 646? I would have thought either referencing ASCII or even Unicode (which are more readily available than 646) would be a much better choice; I've never seen a reference to 646 before, and both ASCII and Unicode define RS. Unless there's a good reason, I'd prefer to switch it. 2.1 - The last paragraph has me a bit baffled. Starting with the first bit: If parsing of such an octet string as a JSON-text fails, the parser should nonetheless continue parsing the remainder of the sequence; Just a nit here: it seems to me "can" is better than "should" here. the parser SHOULD report such failures so that applications may terminate processing if desired. That's not an appropriate use of SHOULD. Reporting errors up the application stack isn't part of interoperability. Instead, how about: "however, applications might wish to terminate processing in this case, so it is useful for parsers to report JSON-text parsing failures to the application." Multiple consecutive RS octets do not denote empty sequence elements between them. Parsers MAY report about empty sequence elements. I cannot parse that above (pun intended). First of all, aside from the inappropriate use of MAY, the second sentence makes no sense in light of the first: If multiple RSs don't denote empty sequence elements, how can the parser report about empty sequence elements? But I'm not even getting what the first sentence really means. Did you mean, "Multiple consecutive RS octets can be ignored" or "Multiple consecutive RS octets are semantically equivalent to a single RS octets"? Please explain. 2.2 - The syntax says: JSON-sequence = *(RS JSON-text LF) but the prose says: In prose: any number of JSON texts, each preceded and followed by one or more ASCII RS characters and each followed by a line feed (LF). One of those is incorrect. The syntax only allows for a single RS preceding the JSON text. 2.3/2.4 - Reversing the order of these sections would be helpful. 2.3 occurs because of truncation, which is described in 2.4. 2.3 - "("ws" ABNF rule from [RFC7159])" has the potential for confusion, since "ws" from 7159 is optional. I would simply say, "(SP, HTAB, LF, or CR)". They're all defined in 5234, which you already have a normative reference to. "(see previous sentence)" seems completely unnecessary. I suggest striking it. s/MAY/can in the last sentence. See comment on 2.1. 2.4 - Strike the word "be" from the title of the section. In the first sentence, s/SHOULD NOT/need not. 2.5 - Change "MAY" in the second sentence to "can" or "can attempt to". 3 - I think you should strike the second paragraph in its entirety. This is not a security consideration for the data format defined here. It's a security consideration for any transport that might move these things (or any other data format, for that matter) around, not for the data format itself. Now, if you put this in here simply because you thought it would satisfy some Security AD, please do take it out and I'll deal with the IESG. If you really think it belongs in there, do explain; perhaps I'm missing something (or perhaps I'll be in the rough). pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sun Oct 19 13:20:19 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013031A6F82 for ; Sun, 19 Oct 2014 13:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BFDWBblAc6t for ; Sun, 19 Oct 2014 13:20:00 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037FA1A6F7F for ; Sun, 19 Oct 2014 13:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9JKJtvW010416; Sun, 19 Oct 2014 22:19:55 +0200 (CEST) Received: from [192.168.217.113] (p548938FA.dip0.t-ipconnect.de [84.137.56.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 250D6367; Sun, 19 Oct 2014 22:19:55 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: <5443F4FA.4080001@qti.qualcomm.com> Date: Sun, 19 Oct 2014 22:19:54 +0200 X-Mao-Original-Outgoing-Id: 435442794.79185-fee1509b32a252bef705fd7d8e559742 Content-Transfer-Encoding: quoted-printable Message-Id: <210F8BC4-13D9-43FE-A6BF-F625F0A0C3D8@tzi.org> References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> <20141018005739.GE12268@mercury.ccil.org> <5442D816.9090107@qti.qualcomm.com> <5443F4FA.4080001@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/json/zBgXcLWE_ONaFHLm8iU1ohKS4WU Cc: John Cowan , "Manger, James" , Tim Bray , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 20:20:02 -0000 On 19 Oct 2014, at 19:29, Pete Resnick = wrote: >=20 > On 10/18/14 6:32 PM, Carsten Bormann wrote: >=20 >> Unfortunately, there is no way to look at a JSON file and say whether = the conversion from the source=92s internal number representation to the = JSON file represents the intent of the programmer, under the = restrictions of I-JSON. If you see 36028797018963970, there is no way to = find out if the programmer intended that to be a different number from = 36028797018963968 or not (it isn=92t in I-JSON). >>=20 >> So trying to phrase this in MUST/MUST NOT predicates on the JSON file = will not work. >> =20 >=20 > I have read the above a dozen times, and I'm still a bit baffled. >=20 > If I look at some data, and I can't tell what the intent of the = generator of that data was regarding the semantics of the data, that is = by definition an interoperability problem. We agree that if someone = sends me 36028797018963970 as a numeric value in a JSON text (leave = aside I-JSON), I can't tell whether they meant it to be identical to = 36028797018963968 or not. The benefit of agreeing on something like I-JSON is to take out that = ambiguity. With JSON, I really don=92t know, because clearly these are different = numbers, and JSON is not bound to JavaScript and the limitations of = JavaScript=92s number space in any way. With I-JSON, I know that the intention of sending 36028797018963970 = cannot have been different from the intention of sending = 36028797018963968. (In all likelihood, this is a floating point value, = measuring and computing which has had a larger internal uncertainty than = that difference.) > I hope we also agree that this means if I act on such a value, I might = end up doing the wrong thing. Both sides should be told, "Using such a = value is non-interoperable; you'd need out of band information to know = what to do with it." That's all that "MUST NOT" means in the context of = IETF documents. >=20 > Are we simply disagreeing about the *efficacy* of saying "MUST NOT"? = That even if we make it a requirement of the spec, it will be ignored = because people won't actually implement the range check? If we agreed on outlawing 36028797018963970 (because it is not exact), = or 36028797018963968 (because it is not the = minimum-number-of-required-digits representation that a modern = floating-point binary to decimal conversion routing will generate), we = would indeed lose users: Doing such a check is not inexpensive, and = libraries are not prepared today to do this check. Worse, a constrained = implementation may not want to include expensive = minimum-number-of-required-digits floating point code (we are talking = about more code here than one would need for decent crypto). So, independent of whether users of such a specification want to = conform, it seems unwise to impose the cost on them. > IETF specs are voluntary standards; they're not laws. I thought the = whole point of I-JSON was, "If you generate this, the other side will = always interpret it correctly." If the spec doesn't say, "In I-JSON, = don't use >53 bit integers", what's the point of saying *anything* about = number ranges? JSON doesn=92t have integers or floating point values, it only has = numbers. So the spec says: If the objective is exactness, use an integer number = within [-(2**53)+1, (2**53)-1], because for most implementations = exactness is cheap to check in this range. If an inexact number is = fine, do not expect more resolution than binary64 provides, because we = don=92t expect receivers to have more than that. Unfortunately, JSON = does not distinguish exact and inexact numbers*), so there is no way to = check for compatibility with the objective. Retroactively classifying = the floating point representations into exact and inexact ones (e.g., = NR1 is always exact, NR2/NR3 are always inexact) ten years after JSON = took hold doesn=92t make sense. oOo (Unless specifically asked, I am going to shut up on this issue now, as = the utility of I-JSON is palpable but limited, and it is already having = a detrimental effect on specifications such as YANG-JSON that I didn=92t = see coming, but also don=92t know how to curb.) Gr=FC=DFe, Carsten *) JSON was extracted from a programming language, and very few = programming languages have number systems that are sophisticated enough = to make that distinction.= From nobody Sun Oct 19 13:43:19 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFE21A0273 for ; Sun, 19 Oct 2014 13:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FVEsrNZZrYX for ; Sun, 19 Oct 2014 13:43:14 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3175F1A0258 for ; Sun, 19 Oct 2014 13:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413751395; x=1445287395; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jwBabJzyvOjbpLXdO6vIBXEmucxGcGpMvwHRnjyYBEQ=; b=XSJf2zo/dxXH5a+MkTgI+ElwoZjEqji+44YPkE9N8pWnfyG3ZZfkTpF8 BXYLKGCd/HgXnvx6ollDKUVvFgV8d7vCgPnpGVsPDcRf/RLukCVOPZrVl rjS2JFHbChAzdBxLoyb7hPoB0JkjOoE7M0LGp8VlKsQaY9YkhAwREyJOu Q=; X-IronPort-AV: E=McAfee;i="5600,1067,7595"; a="167842976" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Oct 2014 13:43:14 -0700 X-IronPort-AV: E=Sophos;i="5.04,749,1406617200"; d="scan'208";a="772936257" Received: from nasanexhc03.na.qualcomm.com ([10.46.200.142]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Oct 2014 13:43:12 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by NASANEXHC03.na.qualcomm.com (10.46.200.142) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 19 Oct 2014 13:43:11 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sun, 19 Oct 2014 13:43:11 -0700 Message-ID: <5444225D.9000707@qti.qualcomm.com> Date: Sun, 19 Oct 2014 15:43:09 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Carsten Bormann References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> <20141018005739.GE12268@mercury.ccil.org> <5442D816.9090107@qti.qualcomm.com> <5443F4FA.4080001@qti.qualcomm.com> <210F8BC4-13D9-43FE-A6BF-F625F0A0C3D8@tzi.org> In-Reply-To: <210F8BC4-13D9-43FE-A6BF-F625F0A0C3D8@tzi.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.46.201.191) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/json/h0WzyOxu8mSuXaRTuOwU-8i29Jw Cc: Tim Bray , "Manger, James" , John Cowan , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 20:43:16 -0000 Aha. I think this is the bit that made it clear: On 10/19/14 3:19 PM, Carsten Bormann wrote: > JSON doesn’t have integers or floating point values, it only has numbers. > So the spec says: If the objective is exactness, use an integer number within [-(2**53)+1, (2**53)-1], because for most implementations exactness is cheap to check in this range. If an inexact number is fine, do not expect more resolution than binary64 provides, because we don’t expect receivers to have more than that. Unfortunately, JSON does not distinguish exact and inexact numbers*), so there is no way to check for compatibility with the objective. Retroactively classifying the floating point representations into exact and inexact ones (e.g., NR1 is always exact, NR2/NR3 are always inexact) ten years after JSON took hold doesn’t make sense. > So basically what we're saying is, "Any numeric value that can be exactly represented by IEEE 754-2008 binary64 (double precision) numbers (e.g., any integer in the range [-(2**53)+1, (2**53)-1]), is perfectly safe to use in I-JSON. The semantics of any I-JSON numeric value that cannot be exactly represented by an IEEE 754-2008 binary64 (double precision) number are undefined, SHOULD NOT be used, and if you need numbers outside of that range with exact values, use a string instead." I'm perfectly cool with that. It's all of the "MUST NOT assume/expect" stuff that bugged me, but saying that the semantics are undefined seems just fine. So, here's a replacement for the first two paragraphs of the section, rewritten that way. Does this work for folks? Software which implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used. In an I-JSON implementation, numeric values that can be exactly represented using the magnitude or precision of such numbers (e.g., any integer in the range [-(2**53)+1, (2**53)-1]) are perfectly safe to use. The semantics of any numeric value that cannot be exactly represented by an IEEE 754-2008 binary64 (double precision) number (e.g., 1E400 or 3.141592653589793238462643383279) are undefined and I-JSON messages SHOULD NOT include such numbers, since a receiver may be unable to treat such numbers as an exact value. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sun Oct 19 14:04:16 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DE61A0270 for ; Sun, 19 Oct 2014 14:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cm0IrEEc2Vl for ; Sun, 19 Oct 2014 14:04:13 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305E11A0258 for ; Sun, 19 Oct 2014 14:04:13 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id hq11so2627250vcb.7 for ; Sun, 19 Oct 2014 14:04:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=0K9nXD2LgvntOgH6qvc2pLa/Q9+N8ZqXv9xTnUjaZqM=; b=E5RRxpJ9EnxektNg1qaYY6PU2ssG9f1MBc1jDitqAuNXoTZI1ywnxqo2cfjTyHi1Ox MTkz0lnwTDDooLW7HHXxJ4XK00c+3t9A+Mki7eEMkjpimKb2QwNa01ZRrewjtk3GCBWv KksOOvwNdkrfkj85x5AuTFi9hq9K5OwwkGqFgdsLQgIWvQF46cmdDoygUFFB1tJrtmWi f1gN3APi8JcHKWdb9Zmqswq4r4ZWxyqOwU2ZCdSsVX7lqweHqMKY6jqJuOyfblmMDfgg Qpu76XJc0opu2w+VYfF/ovu18FgTSRBSKDalMApirl8agkeST3d/S64dK9G5Lml2RVX5 W2Yg== X-Gm-Message-State: ALoCoQmB30bSZV52S1QueCgZ1RbSDlpw0IMSMyQ0f/2aCkC4y5PaaCK1I4NkGEjk2jFbbh/iL9Ra X-Received: by 10.221.20.198 with SMTP id qp6mr19611793vcb.18.1413752652224; Sun, 19 Oct 2014 14:04:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.160.135 with HTTP; Sun, 19 Oct 2014 14:03:52 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <5444225D.9000707@qti.qualcomm.com> References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> <20141018005739.GE12268@mercury.ccil.org> <5442D816.9090107@qti.qualcomm.com> <5443F4FA.4080001@qti.qualcomm.com> <210F8BC4-13D9-43FE-A6BF-F625F0A0C3D8@tzi.org> <5444225D.9000707@qti.qualcomm.com> From: Tim Bray Date: Sun, 19 Oct 2014 14:03:52 -0700 Message-ID: To: Pete Resnick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/BXGkJEkMFOm4TthZ_peHyXU9Pfo Cc: "Manger, James" , Carsten Bormann , John Cowan , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 21:04:15 -0000 We=E2=80=99re on the right trail, but I don=E2=80=99t think =E2=80=9Cthe se= mantics are undefined=E2=80=9D is the right wording. The semantics are clear, it=E2=80= =99s just that interchange may fail to produce the expected results if those results rely on numeric accuracy better than IEEE754 can provide. Also the =E2=80=9Cperfectly safe=E2=80=9D language feels a little chatty to= me. Slight re-spin: Software which implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used. In an I-JSON implementation, numeric values that can be exactly represented using the magnitude and precision of such numbers (e.g., any integer in the range [-(2**53)+1, (2**53)-1]) are fully interoperable. Numeric values that cannot be exactly represented by such numbers (e.g., 1E400 or 3.141592653589793238462643383279) can lead to interoperability problems and I-JSON messages SHOULD NOT include such numbers. On Sun, Oct 19, 2014 at 1:43 PM, Pete Resnick w= rote: > Aha. I think this is the bit that made it clear: > > On 10/19/14 3:19 PM, Carsten Bormann wrote: >> >> JSON doesn=E2=80=99t have integers or floating point values, it only has= numbers. >> So the spec says: If the objective is exactness, use an integer number >> within [-(2**53)+1, (2**53)-1], because for most implementations exactne= ss >> is cheap to check in this range. If an inexact number is fine, do not >> expect more resolution than binary64 provides, because we don=E2=80=99t = expect >> receivers to have more than that. Unfortunately, JSON does not distingu= ish >> exact and inexact numbers*), so there is no way to check for compatibili= ty >> with the objective. Retroactively classifying the floating point >> representations into exact and inexact ones (e.g., NR1 is always exact, >> NR2/NR3 are always inexact) ten years after JSON took hold doesn=E2=80= =99t make >> sense. >> > > > So basically what we're saying is, "Any numeric value that can be exactly > represented by IEEE 754-2008 binary64 (double precision) numbers (e.g., a= ny > integer in the range [-(2**53)+1, (2**53)-1]), is perfectly safe to use i= n > I-JSON. The semantics of any I-JSON numeric value that cannot be exactly > represented by an IEEE 754-2008 binary64 (double precision) number are > undefined, SHOULD NOT be used, and if you need numbers outside of that ra= nge > with exact values, use a string instead." I'm perfectly cool with that. I= t's > all of the "MUST NOT assume/expect" stuff that bugged me, but saying that > the semantics are undefined seems just fine. > > So, here's a replacement for the first two paragraphs of the section, > rewritten that way. Does this work for folks? > > Software which implements IEEE 754-2008 binary64 (double precision) > numbers [IEEE754] is generally available and widely used. In an > I-JSON implementation, numeric values that can be exactly represented > using the magnitude or precision of such numbers (e.g., any integer > in the range [-(2**53)+1, (2**53)-1]) are perfectly safe to use. The > semantics of any numeric value that cannot be exactly represented by > an IEEE 754-2008 binary64 (double precision) number (e.g., 1E400 or > 3.141592653589793238462643383279) are undefined and I-JSON messages > SHOULD NOT include such numbers, since a receiver may be unable to > treat such numbers as an exact value. > > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) From nobody Sun Oct 19 16:47:02 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72891A1A4C for ; Sun, 19 Oct 2014 16:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usEQl68X7Pxu for ; Sun, 19 Oct 2014 16:46:58 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 487F01A1A36 for ; Sun, 19 Oct 2014 16:46:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,749,1406556000"; d="scan'208";a="46078131" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 20 Oct 2014 10:29:32 +1100 X-IronPort-AV: E=McAfee;i="5600,1067,7595"; a="268326192" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdvi.tcif.telstra.com.au with ESMTP; 20 Oct 2014 10:46:55 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Mon, 20 Oct 2014 10:46:55 +1100 From: "Manger, James" To: Tim Bray , Pete Resnick Date: Mon, 20 Oct 2014 10:46:51 +1100 Thread-Topic: [Json] AD Evaluation of draft-ietf-json-i-json-03 Thread-Index: Ac/r4D6GRInH+UD/SdaGLuTWXgQfzAAC8N5Q Message-ID: <255B9BB34FB7D647A506DC292726F6E127CF5DC07B@WSMSG3153V.srv.dir.telstra.com> References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> <20141018005739.GE12268@mercury.ccil.org> <5442D816.9090107@qti.qualcomm.com> <5443F4FA.4080001@qti.qualcomm.com> <210F8BC4-13D9-43FE-A6BF-F625F0A0C3D8@tzi.org> <5444225D.9000707@qti.qualcomm.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/CPjn9-B6mQhfIjRmR_vIniIRnyg Cc: Carsten Bormann , John Cowan , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 23:47:01 -0000 V2UgY2FuJ3Qgc2F5ICJudW1lcmljIHZhbHVlcyB0aGF0IGNhbm5vdCBiZSBleGFjdGx5IHJlcHJl c2VudGVkIFtieSBhIGJpbmFyeTY0IG51bWJlcl0gU0hPVUxEIE5PVCBiZSBpbmNsdWRlZCIuIElm IHlvdSBhcmUgaGFuZGxpbmcgYSBmbG9hdGluZyBwb2ludCBxdWFudGl0eSB5b3UgZ2VuZXJhbGx5 IGRvbid0IGV4cGVjdGVkIHRvIGJlIGV4YWN0LiBQcm9ncmFtcyBoYXZlIGdlbmVyYWxseSBhbHJl YWR5IG1hZGUgYW4gYXBwcm94aW1hdGlvbiB0byBwdXQgdGhlIHF1YW50aXR5IGluIGEgNjQtYml0 IGZsb2F0LCBhbmQgZ2VuZXJhbGx5IG5lZWQgdG8gbWFrZSBhbm90aGVyIGFwcHJveGltYXRpb24g dG8gcmVwcmVzZW50ZWQgdGhlIHF1YW50aXR5IHdpdGggZGVjaW1hbCBkaWdpdHMuDQoNCkkgYmVs aWV2ZSB0aGUgY2xvc2VzdCBiaW5hcnk2NCB2YWx1ZSB0byBQSSBpczoNCiAgIDB4MS45MjFmYjU0 NDQyZDE4cDEgKGphdmEgbm90YXRpb24pDQpUaGlzIDY0LWJpdCBudW1iZXIgaXMgKmV4YWN0bHkq IGVxdWFsIHRvIHRoZSBmb2xsb3dpbmcgNDktZGlnaXQgbnVtYmVyOg0KICAgMy4xNDE1OTI2NTM1 ODk3OTMxMTU5OTc5NjM0Njg1NDQxODUxNjE1OTA1NzYxNzE4NzUgIA0KQnV0IFBJIHRvIDQ5LWRp Z2l0cyBpcyAoZGlmZiB1bmRlcmxpbmVkKToNCiAgIDMuMTQxNTkyNjUzNTg5NzkzMjM4NDYyNjQz MzgzMjc5NTAyODg0MTk3MTY5Mzk5Mzc1DQogICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpTbyB3aGF0IHNob3VsZCBiZSBzZW50IGluIGFuIEkt SlNPTiBtZXNzYWdlPw0KSXQgZGVwZW5kcy4NCklmIHlvdSBkb24ndCBuZWVkIG11Y2ggcHJlY2lz aW9uIHlvdSBjb3VsZCBzZW5kOg0KICAgMy4xNDE1OQ0KDQpJZiB5b3Ugd2FudCA2NC1iaXQgZmxv YXQgcHJlY2lzaW9uIHlvdSBvdWdodCB0byBzZW5kOg0KICAgMy4xNDE1OTI2NTM1ODk3OTMNCm9y IDMuMTQxNTkyNjUzNTg5NzkzMQ0Kb3IgMy4xNDE1OTI2NTM1ODk3OTMyDQpvciAwLjMxNDE1OTI2 NTM1ODk3OTNlMQ0Kb3Igc29tZXRoaW5nIHNpbWlsYXIgd2l0aCwgc2F5LCAxNS0xNyBzaWduaWZp Y2FudCBkaWdpdHMuDQpZb3Ugc2hvdWxkIE5PVCBzZW5kIHRoZSBleGFjdCA0OS1kaWdpdCBkZWNp bWFsIHZlcnNpb24gb2YgYSBiaW5hcnk2NCB2YWx1ZS4NCg0KSWYgeW91IHdhbnQgbW9yZSBwcmVj aXNpb24geW91IG91Z2h0IHRvIHBpY2sgYW5vdGhlciBzeW50YXggKGVnIGEgc3RyaW5nKQ0KICAg IjMuMTQxNTkyNjUzNTg5NzkzMjM4NDYyNjQzMzgzMjc5NTAyODg0MTk3MTY5Mzk5Mzc1Ig0KDQoN ClRoZSB0ZXh0IGluIGRyYWZ0LWlldGYtanNvbi1pLWpzb24tMDMgY2FwdHVyZXMgdGhpcyBiZXR0 ZXIgdGhhbiB0aGUgYWx0ZXJuYXRpdmVzIHN1Z2dlc3RlZCBpbiB0aGlzIHRocmVhZCB0byBkYXRl Lg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBUaW0gQnJheSBbbWFpbHRvOnRicmF5QHRleHR1YWxpdHkuY29tXSANClNlbnQ6IE1vbmRheSwg MjAgT2N0b2JlciAyMDE0IDg6MDQgQU0NClRvOiBQZXRlIFJlc25pY2sNCkNjOiBDYXJzdGVuIEJv cm1hbm47IEpvaG4gQ293YW47IE1hbmdlciwgSmFtZXM7IGpzb25AaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbSnNvbl0gQUQgRXZhbHVhdGlvbiBvZiBkcmFmdC1pZXRmLWpzb24taS1qc29uLTAzDQoN Cldl4oCZcmUgb24gdGhlIHJpZ2h0IHRyYWlsLCBidXQgSSBkb27igJl0IHRoaW5rIOKAnHRoZSBz ZW1hbnRpY3MgYXJlIHVuZGVmaW5lZOKAnSBpcyB0aGUgcmlnaHQgd29yZGluZy4gVGhlIHNlbWFu dGljcyBhcmUgY2xlYXIsIGl04oCZcyBqdXN0IHRoYXQgaW50ZXJjaGFuZ2UgbWF5IGZhaWwgdG8g cHJvZHVjZSB0aGUgZXhwZWN0ZWQgcmVzdWx0cyBpZiB0aG9zZSByZXN1bHRzIHJlbHkgb24gbnVt ZXJpYyBhY2N1cmFjeSBiZXR0ZXIgdGhhbiBJRUVFNzU0IGNhbiBwcm92aWRlLg0KQWxzbyB0aGUg 4oCccGVyZmVjdGx5IHNhZmXigJ0gbGFuZ3VhZ2UgZmVlbHMgYSBsaXR0bGUgY2hhdHR5IHRvIG1l Lg0KU2xpZ2h0IHJlLXNwaW46DQoNClNvZnR3YXJlIHdoaWNoIGltcGxlbWVudHMgSUVFRSA3NTQt MjAwOCBiaW5hcnk2NCAoZG91YmxlIHByZWNpc2lvbikgbnVtYmVycyBbSUVFRTc1NF0gaXMgZ2Vu ZXJhbGx5IGF2YWlsYWJsZSBhbmQgd2lkZWx5IHVzZWQuIEluIGFuIEktSlNPTiBpbXBsZW1lbnRh dGlvbiwgbnVtZXJpYyB2YWx1ZXMgdGhhdCBjYW4gYmUgZXhhY3RseSByZXByZXNlbnRlZCB1c2lu ZyB0aGUgbWFnbml0dWRlIGFuZCBwcmVjaXNpb24gb2Ygc3VjaCBudW1iZXJzIChlLmcuLCBhbnkg aW50ZWdlciBpbiB0aGUgcmFuZ2UgWy0oMioqNTMpKzEsICgyKio1MyktMV0pIGFyZSBmdWxseSBp bnRlcm9wZXJhYmxlLg0KTnVtZXJpYyB2YWx1ZXMgdGhhdCBjYW5ub3QgYmUgZXhhY3RseSByZXBy ZXNlbnRlZCBieSBzdWNoIG51bWJlcnMgKGUuZy4sIDFFNDAwIG9yIDMuMTQxNTkyNjUzNTg5Nzkz MjM4NDYyNjQzMzgzMjc5KSAgY2FuIGxlYWQgdG8gaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcyBh bmQgSS1KU09OIG1lc3NhZ2VzIFNIT1VMRCBOT1QgaW5jbHVkZSBzdWNoIG51bWJlcnMuDQoNCg0K T24gU3VuLCBPY3QgMTksIDIwMTQgYXQgMTo0MyBQTSwgUGV0ZSBSZXNuaWNrIDxwcmVzbmlja0Bx dGkucXVhbGNvbW0uY29tPiB3cm90ZToNCj4gQWhhLiBJIHRoaW5rIHRoaXMgaXMgdGhlIGJpdCB0 aGF0IG1hZGUgaXQgY2xlYXI6DQo+DQo+IE9uIDEwLzE5LzE0IDM6MTkgUE0sIENhcnN0ZW4gQm9y bWFubiB3cm90ZToNCj4+DQo+PiBKU09OIGRvZXNu4oCZdCBoYXZlIGludGVnZXJzIG9yIGZsb2F0 aW5nIHBvaW50IHZhbHVlcywgaXQgb25seSBoYXMgbnVtYmVycy4NCj4+IFNvIHRoZSBzcGVjIHNh eXM6ICBJZiB0aGUgb2JqZWN0aXZlIGlzIGV4YWN0bmVzcywgdXNlIGFuIGludGVnZXIgDQo+PiBu dW1iZXIgd2l0aGluIFstKDIqKjUzKSsxLCAoMioqNTMpLTFdLCBiZWNhdXNlIGZvciBtb3N0IA0K Pj4gaW1wbGVtZW50YXRpb25zIGV4YWN0bmVzcyBpcyBjaGVhcCB0byBjaGVjayBpbiB0aGlzIHJh bmdlLiAgSWYgYW4gDQo+PiBpbmV4YWN0IG51bWJlciBpcyBmaW5lLCBkbyBub3QgZXhwZWN0IG1v cmUgcmVzb2x1dGlvbiB0aGFuIGJpbmFyeTY0IA0KPj4gcHJvdmlkZXMsIGJlY2F1c2Ugd2UgZG9u 4oCZdCBleHBlY3QgcmVjZWl2ZXJzIHRvIGhhdmUgbW9yZSB0aGFuIHRoYXQuICANCj4+IFVuZm9y dHVuYXRlbHksIEpTT04gZG9lcyBub3QgZGlzdGluZ3Vpc2ggZXhhY3QgYW5kIGluZXhhY3QgbnVt YmVycyopLCANCj4+IHNvIHRoZXJlIGlzIG5vIHdheSB0byBjaGVjayBmb3IgY29tcGF0aWJpbGl0 eSB3aXRoIHRoZSBvYmplY3RpdmUuICANCj4+IFJldHJvYWN0aXZlbHkgY2xhc3NpZnlpbmcgdGhl IGZsb2F0aW5nIHBvaW50IHJlcHJlc2VudGF0aW9ucyBpbnRvIA0KPj4gZXhhY3QgYW5kIGluZXhh Y3Qgb25lcyAoZS5nLiwgTlIxIGlzIGFsd2F5cyBleGFjdCwNCj4+IE5SMi9OUjMgYXJlIGFsd2F5 cyBpbmV4YWN0KSB0ZW4geWVhcnMgYWZ0ZXIgSlNPTiB0b29rIGhvbGQgZG9lc27igJl0IA0KPj4g bWFrZSBzZW5zZS4NCj4+DQo+DQo+DQo+IFNvIGJhc2ljYWxseSB3aGF0IHdlJ3JlIHNheWluZyBp cywgIkFueSBudW1lcmljIHZhbHVlIHRoYXQgY2FuIGJlIA0KPiBleGFjdGx5IHJlcHJlc2VudGVk IGJ5IElFRUUgNzU0LTIwMDggYmluYXJ5NjQgKGRvdWJsZSBwcmVjaXNpb24pIA0KPiBudW1iZXJz IChlLmcuLCBhbnkgaW50ZWdlciBpbiB0aGUgcmFuZ2UgWy0oMioqNTMpKzEsICgyKio1MyktMV0p LCBpcyANCj4gcGVyZmVjdGx5IHNhZmUgdG8gdXNlIGluIEktSlNPTi4gVGhlIHNlbWFudGljcyBv ZiBhbnkgSS1KU09OIG51bWVyaWMgDQo+IHZhbHVlIHRoYXQgY2Fubm90IGJlIGV4YWN0bHkgcmVw cmVzZW50ZWQgYnkgYW4gSUVFRSA3NTQtMjAwOCBiaW5hcnk2NCANCj4gKGRvdWJsZSBwcmVjaXNp b24pIG51bWJlciBhcmUgdW5kZWZpbmVkLCBTSE9VTEQgTk9UIGJlIHVzZWQsIGFuZCBpZiANCj4g eW91IG5lZWQgbnVtYmVycyBvdXRzaWRlIG9mIHRoYXQgcmFuZ2Ugd2l0aCBleGFjdCB2YWx1ZXMs IHVzZSBhIHN0cmluZyANCj4gaW5zdGVhZC4iIEknbSBwZXJmZWN0bHkgY29vbCB3aXRoIHRoYXQu IEl0J3MgYWxsIG9mIHRoZSAiTVVTVCBOT1QgDQo+IGFzc3VtZS9leHBlY3QiIHN0dWZmIHRoYXQg YnVnZ2VkIG1lLCBidXQgc2F5aW5nIHRoYXQgdGhlIHNlbWFudGljcyBhcmUgdW5kZWZpbmVkIHNl ZW1zIGp1c3QgZmluZS4NCj4NCj4gU28sIGhlcmUncyBhIHJlcGxhY2VtZW50IGZvciB0aGUgZmly c3QgdHdvIHBhcmFncmFwaHMgb2YgdGhlIHNlY3Rpb24sIA0KPiByZXdyaXR0ZW4gdGhhdCB3YXku IERvZXMgdGhpcyB3b3JrIGZvciBmb2xrcz8NCj4NCj4gU29mdHdhcmUgd2hpY2ggaW1wbGVtZW50 cyBJRUVFIDc1NC0yMDA4IGJpbmFyeTY0IChkb3VibGUgcHJlY2lzaW9uKSANCj4gbnVtYmVycyBb SUVFRTc1NF0gaXMgZ2VuZXJhbGx5IGF2YWlsYWJsZSBhbmQgd2lkZWx5IHVzZWQuIEluIGFuIEkt SlNPTiANCj4gaW1wbGVtZW50YXRpb24sIG51bWVyaWMgdmFsdWVzIHRoYXQgY2FuIGJlIGV4YWN0 bHkgcmVwcmVzZW50ZWQgdXNpbmcgDQo+IHRoZSBtYWduaXR1ZGUgb3IgcHJlY2lzaW9uIG9mIHN1 Y2ggbnVtYmVycyAoZS5nLiwgYW55IGludGVnZXIgaW4gdGhlIA0KPiByYW5nZSBbLSgyKio1Mykr MSwgKDIqKjUzKS0xXSkgYXJlIHBlcmZlY3RseSBzYWZlIHRvIHVzZS4gVGhlIA0KPiBzZW1hbnRp Y3Mgb2YgYW55IG51bWVyaWMgdmFsdWUgdGhhdCBjYW5ub3QgYmUgZXhhY3RseSByZXByZXNlbnRl ZCBieSANCj4gYW4gSUVFRSA3NTQtMjAwOCBiaW5hcnk2NCAoZG91YmxlIHByZWNpc2lvbikgbnVt YmVyIChlLmcuLCAxRTQwMCBvcg0KPiAzLjE0MTU5MjY1MzU4OTc5MzIzODQ2MjY0MzM4MzI3OSkg YXJlIHVuZGVmaW5lZCBhbmQgSS1KU09OIG1lc3NhZ2VzIA0KPiBTSE9VTEQgTk9UIGluY2x1ZGUg c3VjaCBudW1iZXJzLCBzaW5jZSBhIHJlY2VpdmVyIG1heSBiZSB1bmFibGUgdG8gDQo+IHRyZWF0 IHN1Y2ggbnVtYmVycyBhcyBhbiBleGFjdCB2YWx1ZS4NCj4NCj4NCj4gcHINCj4NCj4gLS0NCj4g UGV0ZSBSZXNuaWNrPGh0dHA6Ly93d3cucXVhbGNvbW0uY29tL35wcmVzbmljay8+DQo+IFF1YWxj b21tIFRlY2hub2xvZ2llcywgSW5jLiAtICsxICg4NTgpNjUxLTQ0NzgNCj4NCg0KDQoNCi0tDQot IFRpbSBCcmF5IChJZiB5b3XigJlkIGxpa2UgdG8gc2VuZCBtZSBhIHByaXZhdGUgbWVzc2FnZSwg c2VlDQpodHRwczovL2tleWJhc2UuaW8vdGltYnJheSkNCg== From nobody Sun Oct 19 19:31:18 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFD01A1ABF for ; Sun, 19 Oct 2014 19:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6BezQv6F6rX for ; Sun, 19 Oct 2014 19:31:15 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F781A0019 for ; Sun, 19 Oct 2014 19:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413772275; x=1445308275; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=THbiFZLGpB8kZ/0tKSWiTeGym34cIgRHxkX8gne0amU=; b=zmPE493RH0hzqvUEJeiOAD6uFJdZ23wP2CmMV5qo1qY7InCfRiQh14dB UnUDUPYui98LQL/n+5Fm9FDTmd1Y7xgGz5NQiepBq3+ZCaenN0avLrYRk jJ2x37PggxFCQ4AbUK60W5leZ4bRQ38+kLq4ZWi0BmGtV5arLFmajplES k=; X-IronPort-AV: E=McAfee;i="5600,1067,7595"; a="167905751" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Oct 2014 19:31:14 -0700 X-IronPort-AV: E=Sophos;i="5.04,749,1406617200"; d="scan'208";a="758706371" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Oct 2014 19:31:15 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc07.na.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 19 Oct 2014 19:31:13 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sun, 19 Oct 2014 19:31:13 -0700 Message-ID: <544473DD.8030206@qti.qualcomm.com> Date: Sun, 19 Oct 2014 21:30:53 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Manger, James" References: <54403EBD.9060203@qti.qualcomm.com> <5F89F4FA-7EDB-4A03-B42F-CD19873F03F4@tzi.org> <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> <20141018005739.GE12268@mercury.ccil.org> <5442D816.9090107@qti.qualcomm.com> <5443F4FA.4080001@qti.qualcomm.com> <210F8BC4-13D9-43FE-A6BF-F625F0A0C3D8@tzi.org> <5444225D.9000707@qti.qualcomm.com> <255B9BB34FB7D647A506DC292726F6E127CF5DC07B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E127CF5DC07B@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (129.46.53.226) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/json/Es1qV_Wwrw2_9BCy3X4GJi-Mma0 Cc: John Cowan , Carsten Bormann , Tim Bray , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 02:31:17 -0000 On 10/19/14 6:46 PM, Manger, James wrote: > On 10/19/14 4:03 PM, Tim Bray wrote: > >> We’re on the right trail, but I don’t think “the semantics are >> undefined” is the right wording. The semantics are clear, it’s just >> that interchange may fail to produce the expected results if those >> results rely on numeric accuracy better than IEEE754 can provide. >> Also the “perfectly safe” language feels a little chatty to me. >> Slight re-spin: >> >> Software which implements IEEE 754-2008 binary64 (double precision) >> numbers [IEEE754] is generally available and widely used. In an >> I-JSON implementation, numeric values that can be exactly represented >> using the magnitude and precision of such numbers (e.g., any integer >> in the range [-(2**53)+1, (2**53)-1]) are fully interoperable. >> Numeric values that cannot be exactly represented by such numbers >> (e.g., 1E400 or 3.141592653589793238462643383279) can lead to >> interoperability problems and I-JSON messages >> SHOULD NOT include such numbers. >> FWIW, I am fine with the above; I'm happy to leave the precise language to you. > We can't say "numeric values that cannot be exactly represented [by a binary64 number] SHOULD NOT be included". If you are handling a floating point quantity you generally don't expected to be exact. Programs have generally already made an approximation to put the quantity in a 64-bit float, and generally need to make another approximation to represented the quantity with decimal digits. > I see what you mean. Just for information: The language currently in the document is: I-JSON messages SHOULD NOT include numbers which express greater magnitude or precision than an IEEE 754 double precision number provides, for example 1E400 or 3.141592653589793238462643383279. Maybe going along those same lines (talking in terms of SHOULD NOT include numeric values that *express* greater magnitude or precision than binary64) is what needs to be said. > The text in draft-ietf-json-i-json-03 captures this better than the alternatives suggested in this thread to date. > Again, the rest of the text I'm happy to see. It's only the "MUST NOT assume/expect" language that I am objecting to. My other suggestions were just by way of trying to get at what Carsten was pointing out. If you can clarify the rest, I'm sure that will work for me. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Oct 20 06:51:29 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8688F1A8778 for ; Mon, 20 Oct 2014 06:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RslBUX2CybZi for ; Mon, 20 Oct 2014 06:51:19 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011A61A870B for ; Mon, 20 Oct 2014 06:51:08 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1XgDMX-0001LX-Gm; Mon, 20 Oct 2014 09:51:05 -0400 Date: Mon, 20 Oct 2014 09:51:05 -0400 From: John Cowan To: Pete Resnick Message-ID: <20141020135105.GA14499@mercury.ccil.org> References: <5443F661.5090404@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5443F661.5090404@qti.qualcomm.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/tg2KdCmqPmLk62sSuxMhjMvbr9I Cc: "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-text-sequence-07 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 13:51:25 -0000 Pete Resnick scripsit: > 2.1/2.2 - Why use the reference to 646? I would have thought either > referencing ASCII or even Unicode (which are more readily available > than 646) would be a much better choice; I've never seen a reference > to 646 before, and both ASCII and Unicode define RS. Unless there's > a good reason, I'd prefer to switch it. Unicode does not define RS, or any C0 control characters except TAB, CR, and LF. ISO 646 is ASCII. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Babies are born as a result of the mating between men and women, and most men and women enjoy mating. --Isaac Asimov in Earth: Our Crowded Spaceship From nobody Mon Oct 20 07:26:12 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5B41A891B for ; Mon, 20 Oct 2014 07:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlIOeZUyPmP7 for ; Mon, 20 Oct 2014 07:14:08 -0700 (PDT) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA351A8725 for ; Mon, 20 Oct 2014 07:02:04 -0700 (PDT) Received: from [192.168.1.26] (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 694A415A03DC; Mon, 20 Oct 2014 16:02:00 +0200 (CEST) Message-ID: <544515D3.509@greenbytes.de> Date: Mon, 20 Oct 2014 16:01:55 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Cowan , Pete Resnick References: <5443F661.5090404@qti.qualcomm.com> <20141020135105.GA14499@mercury.ccil.org> In-Reply-To: <20141020135105.GA14499@mercury.ccil.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/VE0RfFI8qKtave9lR7FrcnnaTq8 X-Mailman-Approved-At: Mon, 20 Oct 2014 07:26:09 -0700 Cc: "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-text-sequence-07 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 14:14:12 -0000 On 2014-10-20 15:51, John Cowan wrote: > Pete Resnick scripsit: > >> 2.1/2.2 - Why use the reference to 646? I would have thought either >> referencing ASCII or even Unicode (which are more readily available >> than 646) would be a much better choice; I've never seen a reference >> to 646 before, and both ASCII and Unicode define RS. Unless there's >> a good reason, I'd prefer to switch it. > > Unicode does not define RS, or any C0 control characters except TAB, CR, and > LF. ISO 646 is ASCII. But then why does list them? Best regards, Julian From nobody Mon Oct 20 07:49:09 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8E81A8887 for ; Mon, 20 Oct 2014 07:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAKa6jBeg38I for ; Mon, 20 Oct 2014 07:49:00 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C131ABD39 for ; Mon, 20 Oct 2014 07:23:58 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1XgDsI-0004aP-Gc; Mon, 20 Oct 2014 10:23:54 -0400 Date: Mon, 20 Oct 2014 10:23:54 -0400 From: John Cowan To: Julian Reschke Message-ID: <20141020142354.GE14499@mercury.ccil.org> References: <5443F661.5090404@qti.qualcomm.com> <20141020135105.GA14499@mercury.ccil.org> <544515D3.509@greenbytes.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544515D3.509@greenbytes.de> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/scmhC_k16GHutuxDZu_iY_u4JAk Cc: Pete Resnick , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-text-sequence-07 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 14:49:06 -0000 Julian Reschke scripsit: > But then why does list them? Code charts are informative, not normative. See the Unicode FAQ page at , which has this question: Q: The character name alias for the control character U+0082 is BREAK PERMITTED HERE. Does that mean I have to interpret that control character in that way? A: The Unicode Standard does not define U+0082 to mean "BREAK PERMITTED HERE". Formally this character is simply one of 65 control codes, one which in ISO 6429 has the name and meaning of "BREAK PERMITTED HERE". Implementers of the Unicode Standard are not required to interpret the character U+0082 in accordance with ISO 6429 (or to interpret it at all). The standard does assign particular properties and semantics for certain controls commonly used in text files including tab, carriage return, line feed, form feed, and next line. However, it does not give the majority of control codes any semantics at all; that is left to a higher-level protocol. The character names for control characters are actually undefined, however, name aliases, such as "BREAK PERMITTED HERE" have been defined. These aliases are based on ISO 6429, and can be used to identify specific controls, for example in regular expressions. For other control characters see http://www.unicode.org/charts/PDF/U0080.pdf. [End of FAQ] So we could formally cite ISO 6429 or its equivalent ECMA-48 (online at ) rather than ISO 646, I suppose. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org But the next day there came no dawn, and the Grey Company passed on into the darkness of the Storm of Mordor and were lost to mortal sight; but the Dead followed them. --"The Passing of the Grey Company" From nobody Mon Oct 20 08:13:16 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E550D1A03E3 for ; Mon, 20 Oct 2014 08:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOb85tOd_7S1 for ; Mon, 20 Oct 2014 08:13:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5301A8AA8 for ; Mon, 20 Oct 2014 07:52:10 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MhiTL-1XTOQN2ED5-00MwFb; Mon, 20 Oct 2014 16:52:08 +0200 Message-ID: <54452193.8080109@gmx.de> Date: Mon, 20 Oct 2014 16:52:03 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Cowan References: <5443F661.5090404@qti.qualcomm.com> <20141020135105.GA14499@mercury.ccil.org> <544515D3.509@greenbytes.de> <20141020142354.GE14499@mercury.ccil.org> In-Reply-To: <20141020142354.GE14499@mercury.ccil.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:KLzlehZZ9CtNFhD71eGUvMf4GmQdxYApcdjjqURvMbKjcLRYQdJ mzL80Mmx5Lkw7+J45wnoJdhhDYdBjfUH5G8oK6EpKjZK9d4MIEOn8jciaJ3tbOXkapayeKs 352RagOHKqLowQbX+zVlAy/rI9IVlvOYWU9gUDdEu9TA+KSy3XcDyR9ECI4uXonMfiVhByr NSf7niMF4IuJHXBukXwTw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/json/H_bDHu7FIkr_HTi56T3BcXwpy0k Cc: Pete Resnick , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-text-sequence-07 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:13:07 -0000 On 2014-10-20 16:23, John Cowan wrote: > Julian Reschke scripsit: > >> But then why does list them? > > Code charts are informative, not normative. See the Unicode FAQ page at > , which has this > question: > ... OK, thanks for the explanation. Best regards, Julian From nobody Mon Oct 20 08:16:05 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEFF1A8A7B for ; Mon, 20 Oct 2014 08:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS9nIQOGUt2v for ; Mon, 20 Oct 2014 08:16:02 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807C61A8F3B for ; Mon, 20 Oct 2014 07:58:10 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1XgEPF-0007fr-2x; Mon, 20 Oct 2014 10:57:57 -0400 Date: Mon, 20 Oct 2014 10:57:57 -0400 From: John Cowan To: Pete Resnick Message-ID: <20141020145756.GF14499@mercury.ccil.org> References: <255B9BB34FB7D647A506DC292726F6E127CF459623@WSMSG3153V.srv.dir.telstra.com> <54415DBB.3090701@qti.qualcomm.com> <20141018005739.GE12268@mercury.ccil.org> <5442D816.9090107@qti.qualcomm.com> <5443F4FA.4080001@qti.qualcomm.com> <210F8BC4-13D9-43FE-A6BF-F625F0A0C3D8@tzi.org> <5444225D.9000707@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5444225D.9000707@qti.qualcomm.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/NowenVFD0BCgeEa9rGUhhPgTVRM Cc: "Manger, James" , Carsten Bormann , Tim Bray , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:16:04 -0000 Pete Resnick scripsit: > So basically what we're saying is, "Any numeric value that can be > exactly represented by IEEE 754-2008 binary64 (double precision) > numbers (e.g., any integer in the range [-(2**53)+1, (2**53)-1]), is > perfectly safe to use in I-JSON. +1 > The semantics of any I-JSON numeric value that cannot be exactly > represented by an IEEE 754-2008 binary64 (double precision) number are > undefined, SHOULD NOT be used, No, that is much too strong. 36028797018963968 and 36028797018963970 are both well-defined (by the 800-lb gorilla and other systems) as the binary64 number whose canonical representation is 3.6028797018964e+16. > and if you need numbers outside of that range with exact values, use a > string instead." +1, the key being "with exact values". > It's all of the "MUST NOT assume/expect" stuff that bugged me, I suggested that language, I believe (others may have done so too) based on how the Unicode Standard talks about composed vs. decomposed equivalents, like A-with-acute (composed) and A followed by combining acute (decomposed). These are equivalent, but NOT in the sense that no process is permitted to distinguish between them. Trivially, a process that decomposes or composes running text distinguishes, in the sense that one representation is left alone and the other is changed. Instead, what Unicode requires is that no process assume that any other process makes a distinction between equivalent forms. In other words, the distinction can't conformantly be used to encode out-of-band information. Similarly, I think the distinction between 36028797018963968, 36028797018963970, and 3.6028797018964e+16 can't be used in I-JSON to encode a meaningful distinction. That is not the same as banning two of them or saying their semantics is undefined. If you say this is not an appropriate use of MUST NOT, then I'd say change it to "cannot assume" and move on. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org In politics, obedience and support are the same thing. --Hannah Arendt From nobody Mon Oct 20 08:17:49 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9ABE1A0381 for ; Mon, 20 Oct 2014 08:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bJ7k6r23a46 for ; Mon, 20 Oct 2014 08:17:47 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946321A87BD for ; Mon, 20 Oct 2014 08:01:06 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1XgES7-00081y-Gf; Mon, 20 Oct 2014 11:00:55 -0400 Date: Mon, 20 Oct 2014 11:00:55 -0400 From: John Cowan To: Tim Bray Message-ID: <20141020150055.GG14499@mercury.ccil.org> References: <54415DBB.3090701@qti.qualcomm.com> <20141018005739.GE12268@mercury.ccil.org> <5442D816.9090107@qti.qualcomm.com> <5443F4FA.4080001@qti.qualcomm.com> <210F8BC4-13D9-43FE-A6BF-F625F0A0C3D8@tzi.org> <5444225D.9000707@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/bXfndcC_pxBHmF81AMssFv-dLUU Cc: Pete Resnick , "Manger, James" , Carsten Bormann , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-i-json-03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:17:48 -0000 Tim Bray scripsit: > Software which implements IEEE 754-2008 binary64 (double precision) > numbers [IEEE754] is generally available and widely used. In an > I-JSON implementation, numeric values that can be exactly represented > using the magnitude and precision of such numbers (e.g., any integer > in the range [-(2**53)+1, (2**53)-1]) are fully interoperable. > Numeric values that cannot be exactly represented by such numbers > (e.g., 1E400 or 3.141592653589793238462643383279) can lead to > interoperability problems and I-JSON messages > SHOULD NOT include such numbers. This is all right as far as it goes, but I don't think it goes far enough. See my immediately previous post. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org I don't know half of you half as well as I should like, and I like less than half of you half as well as you deserve. --Bilbo From nobody Mon Oct 20 12:55:33 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700011ACD60 for ; Mon, 20 Oct 2014 12:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E4rRM3ou_TM for ; Mon, 20 Oct 2014 12:55:28 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0621.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:621]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36EF31ACD59 for ; Mon, 20 Oct 2014 12:55:27 -0700 (PDT) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0958.namprd02.prod.outlook.com (25.160.216.26) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Mon, 20 Oct 2014 19:55:03 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.00.1054.004; Mon, 20 Oct 2014 19:55:03 +0000 From: Larry Masinter To: "julian.reschke@gmx.de" , John Cowan Thread-Topic: explain reference to ISO 646 Thread-Index: Ac/snoCFi2CE71q7QTm9iZGN5+Y/DA== Date: Mon, 20 Oct 2014 19:55:03 +0000 Message-ID: <4709c427d9674e72b90e34e92f238d73@DM2PR0201MB0960.namprd02.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2601:9:8380:992:b067:113c:3b1e:3117] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0958; x-forefront-prvs: 03706074BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(243025005)(189002)(199003)(51704005)(51914003)(377424004)(24454002)(13464003)(377454003)(2501002)(76482002)(15975445006)(76576001)(4396001)(120916001)(74316001)(80022003)(85306004)(33646002)(101416001)(16601075003)(2656002)(20776003)(15202345003)(64706001)(46102003)(97736003)(87936001)(85852003)(19580395003)(21056001)(108616004)(19580405001)(229853001)(107046002)(106356001)(587094004)(105586002)(122556002)(31966008)(40100003)(95666004)(77096002)(50986999)(99396003)(86362001)(92566001)(99286002)(54356999)(3826002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0958; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/bFUA83gn3G758WGPg4grhWLSpwk Cc: Pete Resnick , "json@ietf.org" Subject: [Json] explain reference to ISO 646 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 19:55:32 -0000 U2luY2Ugc2V2ZXJhbCByZXZpZXdlcnMgaGF2ZSBoYWQgdGhlIHNhbWUgcXVlc3Rpb24sIGlzbid0 IGl0IHdvcnRoIGEgZmV3ICB3b3Jkcw0KaW4gdGhlIHNwZWM/IEknbSBub3Qgc3VyZSBob3cgdG8g d29yZCBpdC4NCg0KRm9yIG15IHRhc3RlLCBoZSBmYWN0IHRoYXQgUlMgaXMgYWN0dWFsbHkgZGVm aW5lZCBhcyBhbnl0aGluZyBpcw0Ka2luZCBvZiBpcnJlbGV2YW50IHRvIGFueW9uZSBpbXBsZW1l bnRpbmcgdGhpcyBzcGVjLg0KDQpUaGlzIHNwZWMgdXNlcyBhIGNvZGUgcG9pbnQuIFRoZSBpbmZv cm1hdGlvbmFsIHJlZmVyZW5jZSB0byB0aGUNClVuaWNvZGUgY29kZSBjaGFydCBhbmQgSVNPIDY0 NiBiZWxvbmcgaW4gYSBoaXN0b3JpY2FsIG5vdGUgZm9yDQp3aHkgUlMgd2FzIGNob3NlbiwgYnV0 IHRoZSBkZWNpc2lvbiB3YXMgcHJldHR5IGFyYml0cmFyeS4NCg0KTGFycnkNCi0tDQpodHRwOi8v bGFycnkubWFzaW50ZXIubmV0DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bToganNvbiBbbWFpbHRvOmpzb24tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1bGlh biBSZXNjaGtlDQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMCwgMjAxNCA3OjUyIEFNDQo+IFRv OiBKb2huIENvd2FuDQo+IENjOiBQZXRlIFJlc25pY2s7IGpzb25AaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFtKc29uXSBBRCBFdmFsdWF0aW9uIG9mIGRyYWZ0LWlldGYtanNvbi10ZXh0LXNlcXVl bmNlLTA3DQo+IA0KPiBPbiAyMDE0LTEwLTIwIDE2OjIzLCBKb2huIENvd2FuIHdyb3RlOg0KPiA+ IEp1bGlhbiBSZXNjaGtlIHNjcmlwc2l0Og0KPiA+DQo+ID4+IEJ1dCB0aGVuIHdoeSBkb2VzIDxo dHRwOi8vd3d3LnVuaWNvZGUub3JnL2NoYXJ0cy9QREYvVTAwMDAucGRmPg0KPiBsaXN0IHRoZW0/ DQo+ID4NCj4gPiBDb2RlIGNoYXJ0cyBhcmUgaW5mb3JtYXRpdmUsIG5vdCBub3JtYXRpdmUuICBT ZWUgdGhlIFVuaWNvZGUgRkFRDQo+IHBhZ2UgYXQNCj4gPiA8aHR0cDovL3d3dy51bmljb2RlLm9y Zy9mYXEvY2FzZW1hcF9jaGFycHJvcC5odG1sPiwgd2hpY2ggaGFzDQo+IHRoaXMNCj4gPiBxdWVz dGlvbjoNCj4gPiAuLi4NCj4gDQo+IE9LLCB0aGFua3MgZm9yIHRoZSBleHBsYW5hdGlvbi4NCj4g DQo+IEJlc3QgcmVnYXJkcywgSnVsaWFuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBqc29uIG1haWxpbmcgbGlzdA0KPiBqc29uQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vanNvbg0K From nobody Mon Oct 20 13:22:53 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80611ACDE8 for ; Mon, 20 Oct 2014 13:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.907 X-Spam-Level: X-Spam-Status: No, score=0.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhOkTWP7hDrI for ; Mon, 20 Oct 2014 13:22:48 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB0C1ACDE0 for ; Mon, 20 Oct 2014 13:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9KKLpbO025659; Mon, 20 Oct 2014 22:21:51 +0200 (CEST) Received: from [10.11.147.157] (ip-109-47-3-233.web.vodafone.de [109.47.3.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D92ECD43; Mon, 20 Oct 2014 22:21:49 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-0F942952-B8C3-4A1D-9F3E-160E69A778AC Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (12A405) In-Reply-To: <4709c427d9674e72b90e34e92f238d73@DM2PR0201MB0960.namprd02.prod.outlook.com> Date: Mon, 20 Oct 2014 22:21:46 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4709c427d9674e72b90e34e92f238d73@DM2PR0201MB0960.namprd02.prod.outlook.com> To: Larry Masinter Archived-At: http://mailarchive.ietf.org/arch/msg/json/1k81xhy1UdCDo9e4qwWtptdCP3Y Cc: "julian.reschke@gmx.de" , Pete Resnick , John Cowan , "json@ietf.org" Subject: Re: [Json] explain reference to ISO 646 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 20:22:51 -0000 --Apple-Mail-0F942952-B8C3-4A1D-9F3E-160E69A778AC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The Correct reference is rfc 20. Sent from mobile > On 20 Oct 2014, at 21:55, Larry Masinter wrote: >=20 > Since several reviewers have had the same question, isn't it worth a few w= ords > in the spec? I'm not sure how to word it. >=20 > For my taste, he fact that RS is actually defined as anything is > kind of irrelevant to anyone implementing this spec. >=20 > This spec uses a code point. The informational reference to the > Unicode code chart and ISO 646 belong in a historical note for > why RS was chosen, but the decision was pretty arbitrary. >=20 > Larry > -- > http://larry.masinter.net >=20 >> -----Original Message----- >> From: json [mailto:json-bounces@ietf.org] On Behalf Of Julian Reschke >> Sent: Monday, October 20, 2014 7:52 AM >> To: John Cowan >> Cc: Pete Resnick; json@ietf.org >> Subject: Re: [Json] AD Evaluation of draft-ietf-json-text-sequence-07 >>=20 >>> On 2014-10-20 16:23, John Cowan wrote: >>> Julian Reschke scripsit: >>>=20 >>>> But then why does >> list them? >>>=20 >>> Code charts are informative, not normative. See the Unicode FAQ >> page at >>> , which has >> this >>> question: >>> ... >>=20 >> OK, thanks for the explanation. >>=20 >> Best regards, Julian >>=20 >> _______________________________________________ >> 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 >=20 --Apple-Mail-0F942952-B8C3-4A1D-9F3E-160E69A778AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The Correct reference is rfc 20.
=

Sent from mobile
=

On 20 Oct 2014, at 21:55, Larry Masinter <masinter@adobe.com> wrote:

Since several reviewers have had the same question, i= sn't it worth a few  words
in the spec? I'm not sure ho= w to word it.

For my taste, he fact that RS= is actually defined as anything is
kind of irrelevant to an= yone implementing this spec.

This spec uses= a code point. The informational reference to the
Unicode co= de chart and ISO 646 belong in a historical note for
why RS w= as chosen, but the decision was pretty arbitrary.
Larry
--
http://larry.masinter.net

-----Original Message-----
From: json [mailto:json-bounces@ietf.org] On Behalf Of Julian Reschke
Sent: Monday, October 20, 201= 4 7:52 AM
To: John Co= wan
Cc: Pete Resnick;= json@ietf.org
<= blockquote type=3D"cite">Subject: Re: [Json] AD Evaluation of draft-ie= tf-json-text-sequence-07

On 2014-10-20 16= :23, John Cowan wrote:
Julian Reschke scripsit:
=

But then why does <http://www.unicode.org/charts/PDF/U= 0000.pdf>
list them?

<= blockquote type=3D"cite">
Code charts are inf= ormative, not normative.  See the Unicode FAQ
page at
<http://www.unicode.org/faq/case= map_charprop.html>, which has
this
question:
...

OK, thanks for the explanation.

Best regards, Julian

_______________________________________________
json mailing list
json@i= etf.org
https://www.ietf.org/mailman/li= stinfo/json
_______________________________= ________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/js= on

= --Apple-Mail-0F942952-B8C3-4A1D-9F3E-160E69A778AC-- From nobody Mon Oct 20 17:45:10 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F451ACF73 for ; Mon, 20 Oct 2014 17:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAN45vzbYS6P for ; Mon, 20 Oct 2014 17:45:06 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E8D1ACE0D for ; Mon, 20 Oct 2014 17:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413852307; x=1445388307; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lB1oeEJ+K49D4hiKTEErmuH463cmWnCein6bo7LjMsw=; b=ROVlE3ShCUrl9OOsnWVHNEqjHhFX7eMbCVsc39q2HKX/fJc8RSrKGNLa ma1lUUoEaY1UuQAFTQpSN/e4sqxNlX0tPetd0ySLKeT12nvLsGrQzOVzE +oR55ET8Z2PIXVMU/y54yLHeCzm7CZTo+KUlnmPx9nHe4mbXWn/DQL1zM w=; X-IronPort-AV: E=McAfee;i="5600,1067,7597"; a="168199764" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2014 17:45:06 -0700 X-IronPort-AV: E=Sophos;i="5.04,759,1406617200"; d="scan'208";a="733735218" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Oct 2014 17:45:03 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 20 Oct 2014 17:45:03 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 20 Oct 2014 17:45:03 -0700 Message-ID: <5445AC88.2020108@qti.qualcomm.com> Date: Mon, 20 Oct 2014 19:44:56 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Carsten Bormann References: <4709c427d9674e72b90e34e92f238d73@DM2PR0201MB0960.namprd02.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (129.46.53.236) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/json/C9bhlXWXWmqDfK9RcUoUGVr6Xh0 Cc: "julian.reschke@gmx.de" , "json@ietf.org" , John Cowan , Larry Masinter Subject: Re: [Json] explain reference to ISO 646 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 00:45:08 -0000 On 10/20/14 3:21 PM, Carsten Bormann wrote: > The Correct reference is rfc 20. Thank you. Good choice. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Oct 20 20:06:44 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D711A1ACC for ; Mon, 20 Oct 2014 20:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3rWQr2ojm3C for ; Mon, 20 Oct 2014 20:06:39 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EFA431A1AC5 for ; Mon, 20 Oct 2014 20:06:38 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 10AC631805D for ; Mon, 20 Oct 2014 20:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=lvv2HYcm0TJ6kQTT97/b o/3SGX4=; b=cTlrhOAFJxCcMmjyFnW4hZIPxdRdIKueeSeqPnQHXJY68EmUUq/L oiUfmkHn8IY3dBQ7aZWrw5j5ipuO0OlH+W1C75lw6noXE7ilrgvw95FtwWfMjXBv WYZTPFV4UASKnTbaM+7QP0AUB4b4SSVmEXjVItnHgdo//fD1J7Y3gnU= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id AF5ED31805C for ; Mon, 20 Oct 2014 20:06:37 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hi2so8757053wib.3 for ; Mon, 20 Oct 2014 20:06:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.78.238 with SMTP id e14mr16066104wjx.106.1413860796426; Mon, 20 Oct 2014 20:06:36 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Mon, 20 Oct 2014 20:06:36 -0700 (PDT) In-Reply-To: <5445AC88.2020108@qti.qualcomm.com> References: <4709c427d9674e72b90e34e92f238d73@DM2PR0201MB0960.namprd02.prod.outlook.com> <5445AC88.2020108@qti.qualcomm.com> Date: Mon, 20 Oct 2014 22:06:36 -0500 Message-ID: From: Nico Williams To: Pete Resnick Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/pvPZq5zcLKbnNhEJho5LpfuQ19Q Cc: "julian.reschke@gmx.de" , Carsten Bormann , Larry Masinter , John Cowan , "json@ietf.org" Subject: Re: [Json] explain reference to ISO 646 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 03:06:40 -0000 Yes, the reference will be to RFC 20. (What happened is I knew about RFC 20 but I couldn't find the reference for it. It's RFC 0020 as far as bibxml is concerned... ISTR knowing this once, and then it fell off the important knowledge cache.) From nobody Tue Oct 21 09:43:34 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220381A890A for ; Tue, 21 Oct 2014 09:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.855 X-Spam-Level: X-Spam-Status: No, score=0.855 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9bccmSkosKz for ; Tue, 21 Oct 2014 09:43:31 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 155EA1A87D6 for ; Tue, 21 Oct 2014 09:43:31 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id DCD4620047B83 for ; Tue, 21 Oct 2014 09:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= resent-from:resent-date:resent-message-id:resent-to:mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; s=cryptonector.com; bh=lvv2HYcm0TJ6kQTT97/bo/3SGX 4=; b=SSB/6dRXF7JcbCT/H5mnJwq+zmgv5BqsCVuEYuWLPFIpjk5tVc4GjH5ccU loxxJvJugJuX/jF3AQJDIBdTvCmJTnL9iMs6qGkpKXt5DlJgdfDVK/XISqq65PLW A729Uh+/oEZNJFPc9rkXYSMD2dI1YNG4uXNpfMLHk9kpztRp0= Received: from localhost (unknown [70.42.94.222]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id 812CB20047B82 for ; Tue, 21 Oct 2014 09:43:30 -0700 (PDT) Resent-From: Nico Williams Resent-Date: Tue, 21 Oct 2014 11:43:29 -0500 Resent-Message-ID: <20141021164329.GA2282@localhost> Resent-To: json@ietf.org MIME-Version: 1.0 Received: by 10.216.32.135 with HTTP; Mon, 20 Oct 2014 20:06:36 -0700 (PDT) In-Reply-To: <5445AC88.2020108@qti.qualcomm.com> References: <4709c427d9674e72b90e34e92f238d73@DM2PR0201MB0960.namprd02.prod.outlook.com> <5445AC88.2020108@qti.qualcomm.com> Date: Mon, 20 Oct 2014 22:06:36 -0500 Message-ID: From: Nico Williams To: Pete Resnick Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/pvPZq5zcLKbnNhEJho5LpfuQ19Q Cc: "julian.reschke@gmx.de" , Carsten Bormann , Larry Masinter , John Cowan , "json@ietf.org" Subject: Re: [Json] explain reference to ISO 646 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 16:43:32 -0000 Yes, the reference will be to RFC 20. (What happened is I knew about RFC 20 but I couldn't find the reference for it. It's RFC 0020 as far as bibxml is concerned... ISTR knowing this once, and then it fell off the important knowledge cache.) From nobody Tue Oct 21 17:10:13 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F65C1A884D for ; Tue, 21 Oct 2014 17:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.443 X-Spam-Level: X-Spam-Status: No, score=0.443 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKrrfbVVy3Id for ; Tue, 21 Oct 2014 17:09:58 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 63C2E1A884A for ; Tue, 21 Oct 2014 17:09:58 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 1E828598058; Tue, 21 Oct 2014 17:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= resent-from:resent-date:resent-message-id:resent-to:date:from:to :cc:subject:message-id:references:mime-version:content-type: in-reply-to; s=cryptonector.com; bh=Oz5kIxxhCfp55GwCVkvN0ojh1L0= ; b=JpAO64SF9m29MrC9/NNQrkD0RTrIfSqpXjpQJWao5cFwZYjyAM5KhbL1o/Zo l93kYGdRfRQPbWdlNxBeXUTyx42TtslsNIStxzl/Xf/8N7RHtQf3iUcmRM2yu+32 pfV/bw5H6LeJC4o4bBHIojcbObT4A6MclcUuR/4lV+aY1c0= Received: from localhost (ip-64-134-196-209.public.wayport.net [64.134.196.209]) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id E1440598057; Tue, 21 Oct 2014 17:09:56 -0700 (PDT) Resent-From: Nico Williams Resent-Date: Tue, 21 Oct 2014 19:09:55 -0500 Resent-Message-ID: <20141022000955.GA5230@localhost> Resent-To: presnick@qti.qualcomm.com, json@ietf.org, nico@cryptonector.com, paul.hoffman@vpnc.org Date: Tue, 21 Oct 2014 11:31:15 -0500 From: Nico Williams To: Pete Resnick Message-ID: <20141021163115.GA1945@localhost> References: <5443F661.5090404@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5443F661.5090404@qti.qualcomm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/MZK-D9k7gPvxRNQxuZ_U49gIqG4 Cc: "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-text-sequence-07 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 00:10:00 -0000 On Sun, Oct 19, 2014 at 12:35:29PM -0500, Pete Resnick wrote: > 2 - Editorial: An "ABNF rule" (as the term is used in 5234) is a > single line. I think what you want is: > > NEW > Two different sets of ABNF rules are provided for the definition of > JSON text sequences: one for parsers, and one for encoders. Having > two different sets of rules permits recovery by parsers from > sequences where some the elements are truncated for whatever reason. > The syntax for parsers is specified in terms of octet strings which > are then interpreted as JSON-texts if possible. The syntax for > encoders, on the other hand, assumes that sequence elements are not > truncated. OK. > 2.1/2.2 - Why use the reference to 646? I would have thought either > referencing ASCII or even Unicode (which are more readily available > than 646) would be a much better choice; I've never seen a reference > to 646 before, and both ASCII and Unicode define RS. Unless there's > a good reason, I'd prefer to switch it. Only because I didn't know how to reference RFC 20. I hadn't noticed (or rather, I'd forgotten) that it's 0020 as far as bibxml is concerned. Perhaps I should have submitted a -08 with this (and some other editorial nits I'd accepted). > 2.1 - The last paragraph has me a bit baffled. Starting with the first bit: > > If parsing of such an octet string as a JSON-text fails, the parser > should nonetheless continue parsing the remainder of the sequence; > > Just a nit here: it seems to me "can" is better than "should" here. Sure. > the parser SHOULD report such failures so that applications may > terminate processing if desired. > > That's not an appropriate use of SHOULD. Reporting errors up the > application stack isn't part of interoperability. Instead, how > about: "however, applications might wish to terminate processing in > this case, so it is useful for parsers to report JSON-text parsing > failures to the application." There's a lot of places where we use RFC2119 language where it has no interoperability effect (e.g., security). Are you sure you want this to not be a recommendation? > Multiple consecutive RS octets do > not denote empty sequence elements between them. Parsers MAY report > about empty sequence elements. > > I cannot parse that above (pun intended). First of all, aside from > the inappropriate use of MAY, the second sentence makes no sense in > light of the first: If multiple RSs don't denote empty sequence > elements, how can the parser report about empty sequence elements? They might still imply truncated elements in some circumstances. > But I'm not even getting what the first sentence really means. Did > you mean, "Multiple consecutive RS octets can be ignored" or > "Multiple consecutive RS octets are semantically equivalent to a > single RS octets"? Please explain. Sequence elements are separated by RS bytes. Does this mean that two consecutive RS bytes denote an empty/missing/truncated element? The desired answer is "no". I don't think "multiple conseuctive RS octets are semantically equivalent to a single RS octet" is what we want: the RS octets as such have no "semantics" as such -- they are a detail of the encoding. > 2.2 - The syntax says: > > JSON-sequence = *(RS JSON-text LF) > > but the prose says: > > In prose: any number of JSON texts, each preceded and followed by one > or more ASCII RS characters and each followed by a line feed (LF). > > One of those is incorrect. The syntax only allows for a single RS > preceding the JSON text. Agreed. That's one of the nits mentioned above that is to be corrected. It was an editing error. > 2.3/2.4 - Reversing the order of these sections would be helpful. > 2.3 occurs because of truncation, which is described in 2.4. Agreed. > 2.3 - "("ws" ABNF rule from [RFC7159])" has the potential for > confusion, since "ws" from 7159 is optional. I would simply say, > "(SP, HTAB, LF, or CR)". They're all defined in 5234, which you > already have a normative reference to. I don't follow. For the purpose of this section all that matters is that the reader understand what is meant by 'ws', which surely the refernce to RFC7159 is sufficient to ensure. > "(see previous sentence)" seems completely unnecessary. I suggest > striking it. Yeah, it does. > s/MAY/can in the last sentence. See comment on 2.1. See above. > 2.4 - Strike the word "be" from the title of the section. In the > first sentence, s/SHOULD NOT/need not. Thanks. > 2.5 - Change "MAY" in the second sentence to "can" or "can attempt to". A number of people preferred removing this section. I think that's a better approach now. > 3 - I think you should strike the second paragraph in its entirety. I'd like to, yes. > This is not a security consideration for the data format defined > here. It's a security consideration for any transport that might > move these things (or any other data format, for that matter) > around, not for the data format itself. Now, if you put this in here > simply because you thought it would satisfy some Security AD, please > do take it out and I'll deal with the IESG. If you really think it > belongs in there, do explain; perhaps I'm missing something (or > perhaps I'll be in the rough). Nah, let's remove it. Nico -- From nobody Tue Oct 21 17:30:30 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4F21A886D for ; Tue, 21 Oct 2014 17:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFQaHhfJfrz9 for ; Tue, 21 Oct 2014 17:30:26 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889CA1A886C for ; Tue, 21 Oct 2014 17:30:26 -0700 (PDT) Received: from [10.20.30.90] (50-1-50-141.dsl.dynamic.fusionbroadband.com [50.1.50.141]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s9M0UNOo008064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 17:30:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-50-141.dsl.dynamic.fusionbroadband.com [50.1.50.141] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Paul Hoffman In-Reply-To: <20141021163115.GA1945@localhost> Date: Tue, 21 Oct 2014 17:30:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6BCD11CE-30E3-4367-81F3-CE35E4804330@vpnc.org> References: <5443F661.5090404@qti.qualcomm.com> <20141021163115.GA1945@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/json/daMaw4lKBL8FPSNonxKk4ihkXw0 Cc: Pete Resnick , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-text-sequence-07 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 00:30:28 -0000 Nico: this mostly seems uncontroversial; see below. Go ahead and issue a = new draft, and Pete can decide to poke the correct buttons or ask for = another round. Turning in your draft sooner rather than later will help = avoid the draft deadline crush next Monday. >> the parser SHOULD report such failures so that applications may >> terminate processing if desired. >>=20 >> That's not an appropriate use of SHOULD. Reporting errors up the >> application stack isn't part of interoperability. Instead, how >> about: "however, applications might wish to terminate processing in >> this case, so it is useful for parsers to report JSON-text parsing >> failures to the application." >=20 > There's a lot of places where we use RFC2119 language where it has no > interoperability effect (e.g., security). Are you sure you want this = to > not be a recommendation? This can go either way. RFC 2119 is only for interop and security, and = this is an example of neither *except* if you want to make the case that = there is a security issue if they don't report failures. That is, I can = see Pete's point of view in general, and I can see your point of view in = specific here. In this case, I think I would lean towards Pete's view, = but not strongly. >> Multiple consecutive RS octets do >> not denote empty sequence elements between them. Parsers MAY = report >> about empty sequence elements. >>=20 >> I cannot parse that above (pun intended). First of all, aside from >> the inappropriate use of MAY, the second sentence makes no sense in >> light of the first: If multiple RSs don't denote empty sequence >> elements, how can the parser report about empty sequence elements? >=20 > They might still imply truncated elements in some circumstances. >=20 >> But I'm not even getting what the first sentence really means. Did >> you mean, "Multiple consecutive RS octets can be ignored" or >> "Multiple consecutive RS octets are semantically equivalent to a >> single RS octets"? Please explain. >=20 > Sequence elements are separated by RS bytes. Does this mean that two > consecutive RS bytes denote an empty/missing/truncated element? The > desired answer is "no". I don't think "multiple conseuctive RS octets > are semantically equivalent to a single RS octet" is what we want: the > RS octets as such have no "semantics" as such -- they are a detail of > the encoding. Then I propose we stay away from the nebulous "truncated elements in = some circumstances" and say "Multiple consecutive RS octets do not = denote empty sequence elements between them, and can be ignored." Remove = the second sentence, since it does not help anyone. >> 2.3 - "("ws" ABNF rule from [RFC7159])" has the potential for >> confusion, since "ws" from 7159 is optional. I would simply say, >> "(SP, HTAB, LF, or CR)". They're all defined in 5234, which you >> already have a normative reference to. >=20 > I don't follow. For the purpose of this section all that matters is > that the reader understand what is meant by 'ws', which surely the > refernce to RFC7159 is sufficient to ensure. I agree with Nico here. "ws" in 7159 is optional, but understanding it = when reading 7159 is not. --Paul Hoffman= From nobody Tue Oct 21 17:48:41 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC81B1A88B5 for ; Tue, 21 Oct 2014 17:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXpucx8XNpJL for ; Tue, 21 Oct 2014 17:48:40 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2A27B1A88B2 for ; Tue, 21 Oct 2014 17:48:40 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id DBC3B3B805C; Tue, 21 Oct 2014 17:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=kVv6X/ynz1c1NI XebQm3Ea1yxFI=; b=OyQDMDRbgThOz28ZLVoWsUgoBGk7s5to3WXRqmdkO9FzuO fjbc58WsR4oKhjFVfc2Pxq1Gz2HamRki26Ui0F0R9Fz97t9l8bsCxg4vyG0rkrbA E+1021hwnInQIn73U3kKW9DgjWGm9HuzfIZQ50bWirOHfLxNFE7uNktIk8e8g= Received: from localhost (ip-64-134-196-209.public.wayport.net [64.134.196.209]) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPA id 682E63B805B; Tue, 21 Oct 2014 17:48:39 -0700 (PDT) Date: Tue, 21 Oct 2014 19:48:39 -0500 From: Nico Williams To: Paul Hoffman Message-ID: <20141022004837.GD5230@localhost> References: <5443F661.5090404@qti.qualcomm.com> <20141021163115.GA1945@localhost> <6BCD11CE-30E3-4367-81F3-CE35E4804330@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6BCD11CE-30E3-4367-81F3-CE35E4804330@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/sxNA0pSOfL2KaU1CYh-c2qifZ-k Cc: Pete Resnick , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-text-sequence-07 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 00:48:41 -0000 On Tue, Oct 21, 2014 at 05:30:23PM -0700, Paul Hoffman wrote: > Nico: this mostly seems uncontroversial; see below. Go ahead and issue > a new draft, and Pete can decide to poke the correct buttons or ask > for another round. Turning in your draft sooner rather than later will > help avoid the draft deadline crush next Monday. OK. I'm traveling, but I can submit one tomorrow. > > There's a lot of places where we use RFC2119 language where it has no > > interoperability effect (e.g., security). Are you sure you want this to > > not be a recommendation? > > This can go either way. RFC 2119 is only for interop and security, and > this is an example of neither *except* if you want to make the case > that there is a security issue if they don't report failures. That is, > I can see Pete's point of view in general, and I can see your point of > view in specific here. In this case, I think I would lean towards > Pete's view, but not strongly. We also do some APIs... This effectively is a recommendation for an API. I don't feel too strongly about it, but I do think that if you have an API you're feeding octets to, and you're not doing any interpretation of them, and if you did care to know about truncated records, then you'd want the API to tell you. One could always choose an API that does do that over one that doesn't, so there's not much harm in removing the recommendation. > >> Multiple consecutive RS octets do > >> not denote empty sequence elements between them. Parsers MAY report > >> about empty sequence elements. > > [...] > > Then I propose we stay away from the nebulous "truncated elements in > some circumstances" and say "Multiple consecutive RS octets do not > denote empty sequence elements between them, and can be ignored." > Remove the second sentence, since it does not help anyone. OK. (This MAY effectively modifies the SHOULD discussed further up. Removing it might increase one's desire to also remove the SHOULD above. I'd rather keep the SHOULD but I don't care enough to argue any further :) Nico -- From nobody Wed Oct 22 14:19:55 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4DD1A1B6F for ; Wed, 22 Oct 2014 14:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caFNrvPGx-Kk for ; Wed, 22 Oct 2014 14:19:52 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A1F1A1B4D for ; Wed, 22 Oct 2014 14:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3614; q=dns/txt; s=iport; t=1414012792; x=1415222392; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SpUWPdXXc4pkkyq27SM/4UQhIsP3ERQVi/Hyfv9CPlk=; b=S9FhQChS8T1WYUsGbkbqWKZ58A23tLA0hLDcWeg928pRlS484LYswpIa sNH9JRBM+iwCZyxKIROhpLSFRjt6wh1JlXVJGxZr7vs1zrfING0HsoGl9 LFHmSLCbQGFHxrEhR64Ldt5dcem4vEIch/bmHIXtI1fX0/9OEf6vd20G2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFABEfSFStJV2Y/2dsb2JhbABcgw6BLATUKQKBDxYBfYQDAQEEgQkCAQgOODIlAgQBEohAxXkBAQEBAQEBAwEBAQEBHZAkOoRLBZIEi1mBMYZ2jgODeGyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.04,771,1406592000"; d="scan'208";a="365565530" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 22 Oct 2014 21:19:31 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9MLJVMl024269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 21:19:31 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.122]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 16:19:30 -0500 From: "Andrew Biggs (adb)" To: Andrew Newton , JSON WG Thread-Topic: [Json] more on schemas, JCR -03 Thread-Index: AQHP6LHqG+IJSEytvE6otokMCdXQYJw8mZOA Date: Wed, 22 Oct 2014 21:19:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.21.113.28] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/PA1lj0JigpPELevR1meW3hfx_gQ Subject: Re: [Json] more on schemas, JCR -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 21:19:54 -0000 On 10/15/14, 1:54 PM, "Andrew Newton" wrote: >I welcome feedback on this draft, and encourage those who have not >looked at it to do so. Comments below on draft -03. In general, I really appreciated the additional explanatory text introduced in this draft, particularly in the introduction. =20 1. Introduction * s/more concise/more concise and unambiguous/ * s/the rules name/the rule's name/ * The bullet list names 5 types of rules, but the subsequent text of this section only mentions the first 4. * Figure 4 shows capitalized attributes, though some of the corresponding member rules of figure 5 are not (e.g. "width"). * I find figure 6 takes much less effort to grok than figure 7. I=B9m not = a big fan of the alternate syntax. 3. Rules * I had to read the first paragraph a few times before I really understood it. Wondering if it might help to coin the terms "named rule" vs "anonymous rule" to differentiate between the case where a rule name is used as part of another rule's definition, versus a definition embedded directly within a definition. Seems like this could make it easier to explain. * s/rule names of other appropriate types of rules/rule names of other rules of appropriate type/ * I=B9m guessing rule names are case sensitive, it may be worth mentioning one way or the other. 3.2 Member Rules * First sentence, I would think value rules are the simplest. * s/may be substituted for/may be (substituted with | replaced by)/ 3.3 Member Rules=20 * Regarding the '&' token, if I have something like this: response { location_uri & referrer_uri } Does this mean that the location_uri must be present (since there's no '?' before location_uri)? If so, then would rewriting it this way: response { ?location_uri & referrer_uri } mean "location_uri is optional, and referrer_uri may be present iff location_uri is present" or does it mean "location_uri is optional, and referrer_uri must be present iff location_uri is present"? Seems like we could actually represent either of these conditions, almost as concisely, using just the existing syntax for groups: response { ?( location_uri, ?referrer_uri ) } response { ?( location_uri, referrer_uri ) } So I'm wondering, do we actually need '&'? 3.4 Array Rules=20 * I'm not exactly advocating this, but if '&' is supported for member rules, should it have an analogous place within array rules? 3.6 Any Value and Any Member * Regarding the exception that allows repetition of member rules with ^"" as the member name, would these represent valid syntax: any_member_any_value ^"" : any object_of_three_to_six_members_that_are_anything { 3*6 any_member_any_value } any_member_string_value ^"" : string object_of_three_or_more_members_that_are_strings { 3* any_member_string_value } 3.5 Group Rules * Can the =8C?=B9 token be used in group rules? I have actually been using= it this way in practice, it seems useful. 4.1 ignore-unknown-members The ignore-unknown-members directive seems to be more consistent with common practice in JSON than the alternative. Would it make sense for this to be regarded as the default, and instead define a directive such as "pedantic" or "no-unknown-members" for the case where the presence of unknown members invalidates a JSON object? 4.3 all-members-optional With the all-members-optional directive, would it be an error to use this directive with rules that explicitly mark some members as optional? Cheers, Andrew From nobody Thu Oct 23 10:44:38 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F97B1A8AD2 for ; Thu, 23 Oct 2014 10:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiDy-0ECen9b for ; Thu, 23 Oct 2014 10:44:32 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5305C1ABD3F for ; Thu, 23 Oct 2014 10:44:26 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 1DA3910060 for ; Thu, 23 Oct 2014 10:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=gXHB/pEsa2jymq7NJpyR ol3LVyE=; b=Ut/iItMnytYUYJB/nXdtkzGMHyIPLYCxtXNUNzKMfcX1koe7FoUU BX3ydZeFaEgDWNeYEiHNJjIKvdxbNaDZ5s9xyjT/0MJ2N6uFxIlKJOckUYHqKxe/ 5SOPE8hcSz5La/2WMquz+SIASVI4arNi18yxhcUrR/1diLS9pHyipAM= Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 2E3B31005D for ; Thu, 23 Oct 2014 10:44:24 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id d1so2686862wiv.6 for ; Thu, 23 Oct 2014 10:44:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.20.43 with SMTP id k11mr14889231wie.28.1414086262769; Thu, 23 Oct 2014 10:44:22 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Thu, 23 Oct 2014 10:44:22 -0700 (PDT) In-Reply-To: <20141021163310.GB1945@localhost> References: <5443F661.5090404@qti.qualcomm.com> <20141021163310.GB1945@localhost> Date: Thu, 23 Oct 2014 12:44:22 -0500 Message-ID: From: Nico Williams To: Pete Resnick Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Fcbz0vs7OAVX-lbVFQ1gf-BLDJU Cc: "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-text-sequence-07 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 17:44:36 -0000 On Tue, Oct 21, 2014 at 11:33 AM, Nico Williams wrote: > On Sun, Oct 19, 2014 at 12:35:29PM -0500, Pete Resnick wrote: >> 2.1 - The last paragraph has me a bit baffled. Starting with the first bit: >> >> If parsing of such an octet string as a JSON-text fails, the parser >> should nonetheless continue parsing the remainder of the sequence; >> >> Just a nit here: it seems to me "can" is better than "should" here. > > Sure. Er, in -07 section 2.4 says "parsers SHOULD NOT abort when..." so I think this should be a SHOULD, not "can". (Clearly this is the desired behavior.) Nico -- From nobody Thu Oct 23 10:56:48 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475A11A911D; Thu, 23 Oct 2014 10:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiN7A8urPsV7; Thu, 23 Oct 2014 10:56:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE6A1ACE44; Thu, 23 Oct 2014 10:56:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141023175604.13880.52348.idtracker@ietfa.amsl.com> Date: Thu, 23 Oct 2014 10:56:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/json/02MAPmpfMsc4Q-izFxI6ADT1Fd8 Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-text-sequence-08.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 17:56:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JavaScript Object Notation Working Group of the IETF. Title : JavaScript Object Notation (JSON) Text Sequences Author : Nicolas Williams Filename : draft-ietf-json-text-sequence-08.txt Pages : 10 Date : 2014-10-23 Abstract: This document describes the JSON text sequence format and associated media type, "application/json-seq". A JSON text sequence consists of any number of JSON tests, each prefix by an Record Separator (U+001E), and each ending with a newline character (U+000A). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-json-text-sequence-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-text-sequence-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 23 11:07:34 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3031ACE41 for ; Thu, 23 Oct 2014 11:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7lHZvh6LNRa for ; Thu, 23 Oct 2014 11:07:31 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9017F1ACD86 for ; Thu, 23 Oct 2014 11:07:30 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 6BA5920068D33 for ; Thu, 23 Oct 2014 11:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=g8lzSc6PyFPXGpRSqbAj wFOMSDw=; b=mBm657gWfMnqjhmQ7nbM6CCNx/t7c/cSE7B+Kjk08VcQnO1wqgX3 1fBpj0ZXLTOYoFfCe+cFqkuZwLfw61If5FqHz12yoB0fSPo0GAlb653FwYzsPBiz kJl9XJrdXCUm2hvaXMVSNmJvGsFtDzfqLHz/tXArUXMJ3aZHs6+xYvQ= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id 2038920052935 for ; Thu, 23 Oct 2014 11:07:28 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so1718413wgh.22 for ; Thu, 23 Oct 2014 11:07:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.73.19 with SMTP id h19mr45605631wiv.3.1414087648018; Thu, 23 Oct 2014 11:07:28 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Thu, 23 Oct 2014 11:07:27 -0700 (PDT) In-Reply-To: <6BCD11CE-30E3-4367-81F3-CE35E4804330@vpnc.org> References: <5443F661.5090404@qti.qualcomm.com> <20141021163115.GA1945@localhost> <6BCD11CE-30E3-4367-81F3-CE35E4804330@vpnc.org> Date: Thu, 23 Oct 2014 13:07:27 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/SY1b3rU41E46DWfHfXGdyDjsAnE Cc: Pete Resnick , "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-text-sequence-07 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 18:07:32 -0000 https://tools.ietf.org/html/draft-ietf-json-text-sequence-08 https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-json-text-sequence-08.txt https://tools.ietf.org/rfcdiff?url2=draft-ietf-json-text-sequence-08.txt There's a bit of noise there due to s/JSON-text/JSON text/g and minor edits I'd agreed to in the last WGLC. Changes: - s/JSON-text/JSON text/g (except in the ABNF) - downgraded[*] RFC2119 language about reporting malformed texts - removed the second paragraph of section 3 - removed section 2.5 - swapped sections 2.3 and 2.4 - adopted new text proposed by Pete R. - section 2.4 (top-level numeric values) got a bit of a re-write proposed (and accepted) on the list during WGLC, but it keeps the same meaning - removed informative references - replaced the ISO 646 reference with RFC20 - fixed nits - added a sentence to the abstrace that was proposed and accepted during WGLC - added a note about how to input RS in some systems [*] Oops, I left a "MAY" in the new section 2.4 that should be "can". Let me know if that merits a -09 or a note to the RFC-Editor. Nico -- From nobody Thu Oct 23 19:51:38 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953381A6F2F for ; Thu, 23 Oct 2014 19:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.997 X-Spam-Level: X-Spam-Status: No, score=0.997 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1xCY7_ijayb for ; Thu, 23 Oct 2014 19:51:36 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id DDE311A1BBB for ; Thu, 23 Oct 2014 19:51:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,778,1406556000"; d="scan'208";a="234371371" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 24 Oct 2014 13:39:21 +1100 X-IronPort-AV: E=McAfee;i="5600,1067,7600"; a="269612395" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcdvi.tcif.telstra.com.au with ESMTP; 24 Oct 2014 13:51:13 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Fri, 24 Oct 2014 13:51:13 +1100 From: "Manger, James" To: Nico Williams , "json@ietf.org" Date: Fri, 24 Oct 2014 13:51:12 +1100 Thread-Topic: [Json] AD Evaluation of draft-ietf-json-text-sequence-07 Thread-Index: Ac/u7FtVUgggtkMOTpG92ojwm0m5LwAQ1/vw Message-ID: <255B9BB34FB7D647A506DC292726F6E127CFADA376@WSMSG3153V.srv.dir.telstra.com> References: <5443F661.5090404@qti.qualcomm.com> <20141021163115.GA1945@localhost> <6BCD11CE-30E3-4367-81F3-CE35E4804330@vpnc.org> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/BHzZpfsTc1E6WUPs6luajLyUi3A Subject: Re: [Json] AD Evaluation of draft-ietf-json-text-sequence-07 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 02:51:37 -0000 The abstract says a sequence consists of "any number of JSON tests". I suspect this tests/texts typo in the abstract warrants another version. 2.2 says "preceded and *followed* by one ASCII RS character", but the JSON-= sequence ABNF has no RS following. Drop the "and followed" phrase. I would put encoding before parsing (move section 2.2 before 2.1). Encoding= explains the format more cleanly, without the added complexity of error re= covery in the parsing side. The encoding ABNF is presumably in terms of Unicode code points (%x0 to %x1= 0FFFF), given that is what JSON-text from RFC7159 uses. This should be expl= icitly stated. Since encoding is in terms of Unicode, drop "ASCII" from the phrase: "prece= ded .. by one ASCII RS character". To the note in section 2.2: Note that on some systems it's possible to input RS by typing 'ctrl-^'. This is helpful when constructing a sequence manually with a text editor. Add the following ;-): But on most systems it is very awkward to input RS so manipulating a sequence manually will be frustrating and error-prone. -- James Manger From nobody Fri Oct 24 06:42:01 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA671A008D for ; Fri, 24 Oct 2014 06:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbOeU2sy-MHa for ; Fri, 24 Oct 2014 06:41:57 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A34D1A0072 for ; Fri, 24 Oct 2014 06:41:50 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id eu11so1174652pac.2 for ; Fri, 24 Oct 2014 06:41:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mMXK/qnv0ANbKdKsap4HwfaFhJdR0yKqDSeNAMtfMOU=; b=bF9sJrQ7hSOJF9WfOpbEnwcyUqnFYisMZEYyzj/R+lso1M6OB/fskNLK2PF8BTEMFt WSKYINO81hHr//FK2wN4o5aAjQdJAZjMkmYsc2+6dcNu+nobYybvz3o3Wf8h43QdyFFO /vOmRt1TBGmbtEa3XhTeNUppoeN3NbniJhmZF4w1P/3mM/zb/j9ImDkgmLo8B80Z9FjO ekUjLsuQy35ibp1ke/JOCEzDbdSgQTwH7ZJCI3QB1M/0G3MZFfakcLkNDDpuNGJOwy/i t79HF+DX2vr1eUbI7cezQtMF0q60tqT8HXwOq8CtUxMEfcbqCk31mQuhmhz4wWKBpH/V 6tpw== X-Gm-Message-State: ALoCoQkfsoAXJke8ox8tk/0OEufZpi30wHFUfMTybrccOrTAKHXH2hxDsEw+d0eITMy2JiV/Jpaa MIME-Version: 1.0 X-Received: by 10.68.231.232 with SMTP id tj8mr625882pbc.166.1414158109755; Fri, 24 Oct 2014 06:41:49 -0700 (PDT) Received: by 10.66.194.13 with HTTP; Fri, 24 Oct 2014 06:41:49 -0700 (PDT) X-Originating-IP: [71.191.38.92] In-Reply-To: References: Date: Fri, 24 Oct 2014 09:41:49 -0400 Message-ID: From: Andrew Newton To: "Andrew Biggs (adb)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/sxuuW9krWMmLMgEKjgYOHVko17s Cc: JSON WG Subject: Re: [Json] more on schemas, JCR -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 13:41:59 -0000 On Wed, Oct 22, 2014 at 5:19 PM, Andrew Biggs (adb) wrote: > > * I find figure 6 takes much less effort to grok than figure 7. I=C2=B9m= not a > big fan of the alternate syntax. I'm beginning to think the alternative syntax is not a good idea. Nobody seems to like it. > 3. Rules > > * I had to read the first paragraph a few times before I really understoo= d > it. Wondering if it might help to coin the terms "named rule" vs > "anonymous rule" to differentiate between the case where a rule name is > used as part of another rule's definition, versus a definition embedded > directly within a definition. Seems like this could make it easier to > explain. Good point. > 3.3 Member Rules > > * Regarding the '&' token, if I have something like this: > > response { location_uri & referrer_uri } > > Does this mean that the location_uri must be present (since there's no '?= ' > before location_uri)? If so, then would rewriting it this way: > > response { ?location_uri & referrer_uri } > > mean "location_uri is optional, and referrer_uri may be present iff > location_uri is present" or does it mean "location_uri is optional, and > referrer_uri must be present iff location_uri is present"? Seems like we > could actually represent either of these conditions, almost as concisely, > using just the existing syntax for groups: It means location_uri is optional, and referrer_uri can only be present if location_uri is present. > response { ?( location_uri, ?referrer_uri ) } Or it could be written that way. > response { ?( location_uri, referrer_uri ) } > > So I'm wondering, do we actually need '&'? Good point. We can probably remove it. > 3.4 Array Rules > > * I'm not exactly advocating this, but if '&' is supported for member > rules, should it have an analogous place within array rules? Given your point above, we shouldn't do this. > 3.6 Any Value and Any Member > > * Regarding the exception that allows repetition of member rules with ^"" > as the member name, would these represent valid syntax: > > any_member_any_value ^"" : any > object_of_three_to_six_members_that_are_anything { 3*6 > any_member_any_value } > > > any_member_string_value ^"" : string > object_of_three_or_more_members_that_are_strings { 3* > any_member_string_value } Yes. > 3.5 Group Rules > > * Can the =C5=92?=C2=B9 token be used in group rules? I have actually be= en using it > this way in practice, it seems useful. Given your point above, I think it is a useful addition. > 4.1 ignore-unknown-members > > The ignore-unknown-members directive seems to be more consistent with > common practice in JSON than the alternative. Would it make sense for > this to be regarded as the default, and instead define a directive such a= s > "pedantic" or "no-unknown-members" for the case where the presence of > unknown members invalidates a JSON object? That's a good idea. > 4.3 all-members-optional > > With the all-members-optional directive, would it be an error to use this > directive with rules that explicitly mark some members as optional? I don't think it should be an error, but I do see how it could cause confusion. Perhaps this directive should be removed. What do you think? -andy From nobody Fri Oct 24 06:57:51 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D481A00F2 for ; Fri, 24 Oct 2014 06:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsB9oetvTdTt for ; Fri, 24 Oct 2014 06:57:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2041A008D for ; Fri, 24 Oct 2014 06:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=488; q=dns/txt; s=iport; t=1414159066; x=1415368666; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TOKvgNWpOa1kHAu0xNrEKhzv3r9zW2F5ESM1T0w0VPg=; b=LdxpJAqkyx68DgKt5J61XKeszqz+goo55Q3W/pXnIdTt4Rj9GYPkiWPs ywkhatYArcwEuhPd5lEf3Y3W9JLsBxGRdjeaz8MBKPy+6g/JAdyOOJI3A baMYiX7Ksuyu5m5mG+VaUPUZpJT8E4Zw/wLuoEsqTqxo2z3GDbWhAUYM0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAJRZSlStJA2L/2dsb2JhbABcgw6BLATUdgKBCBYBfYQDAQEEeRACAQgOODIlAgQOBYhByUoBAQEBAQEBAQEBAQEBAQEBAQEBGZBYB4RLAQSLJYZgi1iWLIN4bIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,780,1406592000"; d="scan'208";a="363006597" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP; 24 Oct 2014 13:57:45 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9ODvjgF017343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 13:57:45 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.122]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 08:57:45 -0500 From: "Andrew Biggs (adb)" To: Andrew Newton Thread-Topic: [Json] more on schemas, JCR -03 Thread-Index: AQHP6LHqG+IJSEytvE6otokMCdXQYJw8mZOAgAMJYID//5/cgA== Date: Fri, 24 Oct 2014 13:57:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.21.91.13] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Kk_m2HvSIr2q_-54u6qk2IymN8c Cc: JSON WG Subject: Re: [Json] more on schemas, JCR -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 13:57:48 -0000 On 10/24/14, 7:41 AM, "Andrew Newton" wrote: >>4.3 all-members-optional >> >>With the all-members-optional directive, would it be an error to use this >>directive with rules that explicitly mark some members as optional? > >I don't think it should be an error, but I do see how it could cause >confusion. Perhaps this directive should be removed. What do you >think? +1, I could see how this directive might create more confusion than it=B9s worth. Andrew From nobody Fri Oct 24 12:25:27 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A31D1A19F1 for ; Fri, 24 Oct 2014 12:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nI6bj9AngNE for ; Fri, 24 Oct 2014 12:25:18 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9FD1A86F2 for ; Fri, 24 Oct 2014 12:25:15 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id 10so3332750lbg.0 for ; Fri, 24 Oct 2014 12:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oBiEo2VSnnAtL16i5tAN1hUUbUmAC35foWuuLRLjJYs=; b=068KODa196htbc27AHPkdO4baEzZeWKjFBlR9k6If7oRVqrPSWiWBTkXDdFY93mslO Rlqyk5bXdmtzAsS7ePn4AzkcOXNCHzvHVMuDHJA+7IACWO2Hn65eMzhTslaWrGP8nx8O wP6oiw86PrpZ+KSdam034tqblpZ6PinEUyu/lALbs9ma12eJaU9sOBWx6mvL4J08J7PG 25vWADiAmcb4hGPe1eGXIsddDJxgbJAjgFUNm/39vFaOkMp2J0MLNOd5DuL7mSMohNqf /zYG1KI95ojjqrxWWdFZ7Sc8KkJXxW4dFDu4lhiFuPpmgAgd+X/em5RDgdmxoWsKu14s yUbg== MIME-Version: 1.0 X-Received: by 10.112.51.40 with SMTP id h8mr5164829lbo.91.1414178704622; Fri, 24 Oct 2014 12:25:04 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Fri, 24 Oct 2014 12:25:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Oct 2014 15:25:04 -0400 X-Google-Sender-Auth: qPh51ZQBEHs9tFfUpebvmqzg1j8 Message-ID: From: Phillip Hallam-Baker To: Andrew Newton Content-Type: multipart/alternative; boundary=001a113365ec568d3b050630234f Archived-At: http://mailarchive.ietf.org/arch/msg/json/XyCKrYZ4Ol32H4CurOJQ55RU7As Cc: "Andrew Biggs \(adb\)" , JSON WG Subject: Re: [Json] more on schemas, JCR -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 19:25:21 -0000 --001a113365ec568d3b050630234f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 24, 2014 at 9:41 AM, Andrew Newton wrote: > On Wed, Oct 22, 2014 at 5:19 PM, Andrew Biggs (adb) wrote= : > > > > * I find figure 6 takes much less effort to grok than figure 7. I=C2= =B9m not > a > > big fan of the alternate syntax. > > I'm beginning to think the alternative syntax is not a good idea. > Nobody seems to like it. > I think an alternative syntax for the schema language is not the best idea. But back on the JSON list a while back there was a proposal for a less verbose version of the JSON syntax to make it easier to use it for writing admin config files. So if you have something like { "name": "Fred", "type": "Integer", "constrants": { "max": 10, "min", 5} } A small change to the lexer allows us to write that as follows: name=3DFred, type=3DInteger, constraints { max=3D10, min=3D5} Which is a lot less noisy. But what you would really want is something more like Fred Integer {max=3D10, min=3D5} Since name and type are required parameters we can elide the tags for them if the parser is schema aware. The ability to do that sort of thing is one of the main reasons to have a schema. It makes it very easy to convert data from human readable format to wireline. --001a113365ec568d3b050630234f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 24, 2014 at 9:41 AM, Andrew Newton <andy@hxr.us> w= rote:
On Wed, Oct 22, 20= 14 at 5:19 PM, Andrew Biggs (adb) <adb@= cisco.com> wrote:
>
> * I find figure 6 takes much less effort to grok than figure 7.=C2=A0 = I=C2=B9m not a
> big fan of the alternate syntax.

I'm beginning to think the alternative syntax is not a good idea= .
Nobody seems to like it.

I think an alt= ernative syntax for the schema language is not the best idea.=C2=A0

But back on the JSON list a while back there was a propos= al for a less verbose version of the JSON syntax to make it easier to use i= t for writing admin config files.

So if you have s= omething like

{ "name": "Fred"= ,
=C2=A0 "type": "Integer",
=C2=A0 = "constrants": { "max": 10, "min", 5}
=C2=A0 }

A small change to the lexer allows us t= o write that as follows:

name=3DFred, type=3DInteg= er, constraints {
=C2=A0max=3D10, min=3D5}

Which is a lot less noisy. But what you would really want is something m= ore like

Fred Integer {max=3D10, min=3D5}

Since name and type are required parameters we can elide t= he tags for them if the parser is schema aware.

The ability to do that sort of thing is one of the main reason= s to have a schema. It makes it very easy to convert data from human readab= le format to wireline.

=C2=A0
--001a113365ec568d3b050630234f-- From nobody Fri Oct 24 13:31:23 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EDF1A1A33 for ; Fri, 24 Oct 2014 13:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLCQXIgRLcCL for ; Fri, 24 Oct 2014 13:31:20 -0700 (PDT) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61A21A064C for ; Fri, 24 Oct 2014 13:31:20 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id rd3so1775785pab.13 for ; Fri, 24 Oct 2014 13:31:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Om0UI/py/qDHskzPClUFE7c8Gn0xKqiTmSl9KienOnU=; b=BrVxzPR7AH7K6vTaCa0fERT8uNiKDLuR7cuS8e9gPdzKtRyL3VPNblyzDCrwO7dV/q 7T9yqwjE5k5zRuRjXEm0ZR0jGi7UW9oCp+EwO4G+DKC/m08EGLEx4ce7Anpeb55SUDHC dQdHzEqIf55p3GqAACTZvYlctWrVPqKFL0nhfhC0huP8Yq4Ho7lBf0SBFDuwHhTeTBxK teDTf889YvhQL8iy0dRoKKmwLGIqqLoEWKsMJdoC5Qaojp2o4jeLIc5tSVbo7XpcJb+s HygNQh4WjwYIgCODCOUGhTl6pvWcac/mfkrfThV7vwj76Ml66sEgdQd77I6XwATFspRr CryA== X-Gm-Message-State: ALoCoQnpw+WAVDft8mLHHjVrgGhcvGC1Do2DLVkIIX2F7+GB3JrlXowt/SDlHMeLiD7GdMSgHYvB MIME-Version: 1.0 X-Received: by 10.70.140.34 with SMTP id rd2mr4822413pdb.146.1414182680377; Fri, 24 Oct 2014 13:31:20 -0700 (PDT) Received: by 10.66.194.13 with HTTP; Fri, 24 Oct 2014 13:31:20 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: References: Date: Fri, 24 Oct 2014 16:31:20 -0400 Message-ID: From: Andrew Newton To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/ieN2R5SaURLHEUCKqcEnXOc_V7g Cc: "Andrew Biggs \(adb\)" , JSON WG Subject: Re: [Json] more on schemas, JCR -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 20:31:22 -0000 On Fri, Oct 24, 2014 at 3:25 PM, Phillip Hallam-Baker wrote: > > But back on the JSON list a while back there was a proposal for a less > verbose version of the JSON syntax to make it easier to use it for writing > admin config files. > > So if you have something like > > { "name": "Fred", > "type": "Integer", > "constrants": { "max": 10, "min", 5} > } > > A small change to the lexer allows us to write that as follows: > > name=Fred, type=Integer, constraints { > max=10, min=5} > > Which is a lot less noisy. But what you would really want is something more > like > > Fred Integer {max=10, min=5} > > Since name and type are required parameters we can elide the tags for them > if the parser is schema aware. Interesting. I'll note that in JCR this is "Fred" : integer 5..10 -andy From nobody Sat Oct 25 00:56:02 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502681A86E6 for ; Sat, 25 Oct 2014 00:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0u8Yg_ml6ca for ; Sat, 25 Oct 2014 00:56:00 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72F51A86E5 for ; Sat, 25 Oct 2014 00:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9P7tnjo008274; Sat, 25 Oct 2014 09:55:49 +0200 (CEST) Received: from [192.168.217.145] (p5489011D.dip0.t-ipconnect.de [84.137.1.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CC4132DB; Sat, 25 Oct 2014 09:55:48 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: Date: Sat, 25 Oct 2014 09:55:46 +0200 X-Mao-Original-Outgoing-Id: 435915226.376648-2b2478947b590d7be27932ee68adab6a Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andrew Newton X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/json/oOE62q_VdyOFH_2ZTu75b-1U9d8 Cc: bert greevenbosch , Christoph Vigano , JSON WG Subject: Re: [Json] more on schemas, JCR -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 07:56:01 -0000 On 24 Oct 2014, at 15:41, Andrew Newton wrote: >=20 > I'm beginning to think the alternative syntax is not a good idea. > Nobody seems to like it. +1 Instead, it might be more useful to invest in a critical review of the = main syntax. E.g., JCR repeats JSON=E2=80=99s mistake of using =E2=80=9C,=E2=80=9D as = a separator, not as terminator. (Before I say more about this, I need an ABNF to look at; I=E2=80=99m = not sure the one in -02 is still current, clearly needing some review.) I also would like to see someone spend time on comparing JCR to CDDL and = possibly learning how and why they are different... Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Oct 26 21:54:16 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6081A6FBB for ; Sun, 26 Oct 2014 21:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOC-FW-aPglb for ; Sun, 26 Oct 2014 21:54:13 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D73F81A6FB4 for ; Sun, 26 Oct 2014 21:54:13 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 6BAC11005D; Sun, 26 Oct 2014 21:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=CgNBse7YbSBW36 YpC63OC53BkRY=; b=JNlKF0XTJ2zdRxiS9L3SO/Cad2T3GOkLO0PlCO8fT3AUVU xKYR/hpDhQz7GKZHeBrvSdo/IN0NrbeLKWQ7fLQVoWxvaFYYBx15rI3YDSkJiyAv 0B1iSz3Wwaz+/6ZUxEqwKFoPunqg0bhohWr8KEzjq5vGATQBFpEcNQ6TQFJJo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 290AD10059; Sun, 26 Oct 2014 21:54:13 -0700 (PDT) Date: Sun, 26 Oct 2014 23:54:12 -0500 From: Nico Williams To: "Manger, James" Message-ID: <20141027045411.GA14215@localhost> References: <5443F661.5090404@qti.qualcomm.com> <20141021163115.GA1945@localhost> <6BCD11CE-30E3-4367-81F3-CE35E4804330@vpnc.org> <255B9BB34FB7D647A506DC292726F6E127CFADA376@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <255B9BB34FB7D647A506DC292726F6E127CFADA376@WSMSG3153V.srv.dir.telstra.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/5Y7KkfSJqlxaUPMO6LyqosgBSPs Cc: "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-text-sequence-07 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 04:54:14 -0000 On Fri, Oct 24, 2014 at 01:51:12PM +1100, Manger, James wrote: > The abstract says a sequence consists of "any number of JSON tests". > I suspect this tests/texts typo in the abstract warrants another version. Meh :) It's a typo, but sure. > 2.2 says "preceded and *followed* by one ASCII RS character", but the > JSON-sequence ABNF has no RS following. Drop the "and followed" > phrase. Editing error. Will fix. > I would put encoding before parsing (move section 2.2 before 2.1). > Encoding explains the format more cleanly, without the added > complexity of error recovery in the parsing side. I'll let Pete ask for this. > The encoding ABNF is presumably in terms of Unicode code points (%x0 > to %x10FFFF), given that is what JSON-text from RFC7159 uses. This > should be explicitly stated. ABNF deals in bytes, and RFC7159 doesn't say otherwise. Including the RFC7159 ABNF by reference is sufficient. However, there was a comment that I dropped about this format being just UTF-8 specific -- it has to be, since for the log-type applications there is a hard requirement for a one-byte record separator. > Since encoding is in terms of Unicode, drop "ASCII" from the phrase: > "preceded .. by one ASCII RS character". No need. We're referencing RFC 20 for RS. > To the note in section 2.2: > Note that on some systems it's possible to input RS by typing > 'ctrl-^'. This is helpful when constructing a sequence manually with > a text editor. > Add the following ;-): > But on most systems it is very awkward to input RS so manipulating > a sequence manually will be frustrating and error-prone. Heh :) I'll leave it as is though. Nico -- From nobody Mon Oct 27 00:12:37 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0E91A89AD; Mon, 27 Oct 2014 00:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8mx0H0N6Cp3; Mon, 27 Oct 2014 00:12:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 201EB1A89D3; Mon, 27 Oct 2014 00:12:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027071225.1240.9252.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 00:12:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Bd7SCjjY0pcnBA5oMnV3pxrNi-A Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-text-sequence-09.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 07:12:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JavaScript Object Notation Working Group of the IETF. Title : JavaScript Object Notation (JSON) Text Sequences Author : Nicolas Williams Filename : draft-ietf-json-text-sequence-09.txt Pages : 10 Date : 2014-10-27 Abstract: This document describes the JSON text sequence format and associated media type, "application/json-seq". A JSON text sequence consists of any number of JSON texts, each prefix by an Record Separator (U+001E), and each ending with a newline character (U+000A). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-json-text-sequence-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-text-sequence-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 30 04:29:37 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3841AD043 for ; Thu, 30 Oct 2014 04:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlFQuY3f2qDA for ; Thu, 30 Oct 2014 04:29:32 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44931AD0BE for ; Thu, 30 Oct 2014 04:29:32 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id ey11so5266408pad.35 for ; Thu, 30 Oct 2014 04:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8plOKDsag/VFzFktCY/zcARr7knkrXj6kgXFraQgv9g=; b=ksXFuX4p6uY6Q2EU6/aO9kGpeZuKhVci9TMkV7CijxzL5/IaqWuEOs0eLEVe0BKKdK yGjxILptkdtgHvDOXrsR8bfpZFUZQsv0jzfjLOf3raANfnH25xQtjzvlzmYgbIVn/Unl BV9we1IsXTjg/Lfrq80+TowjcEaJJEAVTbCrZ93zoxYpKI1+tu7ObfrPt2+woKJv/xQ4 QB5YYYA8ztz+DqKfu7UBoOnMKn+3KEL3k0QgQs00/oG3j0inM6Qt1vG4/UtdBTNJ1Lf9 u5qNLrehRBvUvzRGYs5Ci856jkwSrE3cyRwc5eWsX6EGTiaA68idWmMoUo3VmH8EvA72 fMMw== MIME-Version: 1.0 X-Received: by 10.66.220.3 with SMTP id ps3mr17056176pac.8.1414668572299; Thu, 30 Oct 2014 04:29:32 -0700 (PDT) Received: by 10.70.32.165 with HTTP; Thu, 30 Oct 2014 04:29:32 -0700 (PDT) Date: Thu, 30 Oct 2014 12:29:32 +0100 Message-ID: From: Francis Galiegue To: json@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/_MAq7CV9H57xx_A3ZwHQ0FnbSh0 Subject: [Json] RFC 7386: correct indentation of the MergePatch function... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 11:29:35 -0000 Hello, [note: plain text message, please read with a fixed width font!] In the RFC as well as in the errata, the MergePatch function suffers indentation problems. Am I correct to surmise that this is the correct indentation? define MergePatch(Target, Patch): if Patch is an Object: if Target is not an Object: Target = {} # Ignore the contents and set it to an empty Object for each Name/Value pair in Patch: if Value is null: if Name exists in Target: remove the Name/Value pair from Target else: Target[Name] = MergePatch(Target[Name], Value) return Target else: return Patch -- Francis Galiegue, fgaliegue@gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From nobody Thu Oct 30 04:37:22 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301831AD0C0 for ; Thu, 30 Oct 2014 04:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU5yHVOvYnW9 for ; Thu, 30 Oct 2014 04:37:19 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0450E1AD0CD for ; Thu, 30 Oct 2014 04:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9UBbEfg007200; Thu, 30 Oct 2014 12:37:14 +0100 (CET) Received: from eduroam-pool7-0325.wlan.uni-bremen.de (eduroam-pool7-0325.wlan.uni-bremen.de [134.102.113.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5B23A9DC; Thu, 30 Oct 2014 12:37:14 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: Date: Thu, 30 Oct 2014 12:37:13 +0100 X-Mao-Original-Outgoing-Id: 436361833.186377-485c81975418bf267514844c1be574d5 Content-Transfer-Encoding: quoted-printable Message-Id: <723AD00E-4935-4B59-B692-370F2D887E27@tzi.org> References: To: Francis Galiegue X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/json/YydUxKeYyV1a0qpxG5bO0kFmn9g Cc: json@ietf.org Subject: Re: [Json] RFC 7386: correct indentation of the MergePatch function... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 11:37:21 -0000 On 30 Oct 2014, at 12:29, Francis Galiegue wrote: >=20 > if Value is null: > if Name exists in Target: > remove the Name/Value pair from Target > else: > Target[Name] =3D MergePatch(Target[Name], Value) Unfortunately, not quite. http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-07 says: define MergePatch(Target, Patch): if Patch is an Object: if Target is not an Object: Target =3D {} # Ignore the contents and set it to an empty = Object for each Name/Value pair in Patch: if Value is null: if Name exists in Target: remove the Name/Value pair from Target else: Target[Name] =3D MergePatch(Target[Name], Value) return Target else: return Patch You can also look at https://gist.github.com/cabo/7888768#file-merge-patch-rb which is the same thing in a language that is not indentation-sensitive. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 30 05:18:59 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0067A1A002A for ; Thu, 30 Oct 2014 05:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS16VZnPV33l for ; Thu, 30 Oct 2014 05:18:55 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185F11A0040 for ; Thu, 30 Oct 2014 05:18:55 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id ey11so5340752pad.35 for ; Thu, 30 Oct 2014 05:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EtGh22257oZag293qDu4D+pVK5pEHTk0CUAHS/vSmY0=; b=lh01IREHJTafqdnZahat/l5bv7aslV2Go8poEesFTCJOe1JWxqz255KDcTg1QGUIzQ 6MST1S+TLwuWqQECkECyyNkaeBQBiSEYmjcQdvkjtodE4DxS5ruT5AAS98UnNWDvjGZ7 fEG3tNdZPzLxku6K816IdRWaMOe907QgOTJ2Hm5A35NuZI6OnEWF6MxAi17QjZZp9j8L NxnLtccw2ZOONU+FxHk+r8W45JXGtZdYtPEmPBpYlau2tfgbrTV8ftZM1bC0SNKObPCd icK15Wd+yi/eAGlaeD/nJ2R2hnsLNFLazRj/KVYAdX/MpOlY1nVtn8N08mluqBenND/L tvfg== MIME-Version: 1.0 X-Received: by 10.68.57.200 with SMTP id k8mr802510pbq.96.1414671534707; Thu, 30 Oct 2014 05:18:54 -0700 (PDT) Received: by 10.70.32.165 with HTTP; Thu, 30 Oct 2014 05:18:54 -0700 (PDT) In-Reply-To: <723AD00E-4935-4B59-B692-370F2D887E27@tzi.org> References: <723AD00E-4935-4B59-B692-370F2D887E27@tzi.org> Date: Thu, 30 Oct 2014 13:18:54 +0100 Message-ID: From: Francis Galiegue To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/_wIoUgUcmyyG_E2CsdWd31wuxNY Cc: json@ietf.org Subject: Re: [Json] RFC 7386: correct indentation of the MergePatch function... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 12:18:57 -0000 On Thu, Oct 30, 2014 at 12:37 PM, Carsten Bormann wrote: > On 30 Oct 2014, at 12:29, Francis Galiegue wrote: >> >> if Value is null: >> if Name exists in Target: >> remove the Name/Value pair from Target >> else: >> Target[Name] = MergePatch(Target[Name], Value) > > Unfortunately, not quite. > > http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-07 > > says: > > define MergePatch(Target, Patch): > if Patch is an Object: > if Target is not an Object: > Target = {} # Ignore the contents and set it to an empty Object > for each Name/Value pair in Patch: > if Value is null: > if Name exists in Target: > remove the Name/Value pair from Target > else: > Target[Name] = MergePatch(Target[Name], Value) > return Target > else: > return Patch > Wee! Glad I asked, then... I'd have made a fundamental implementation mistake. > You can also look at > > https://gist.github.com/cabo/7888768#file-merge-patch-rb > > which is the same thing in a language that is not indentation-sensitive. > Thanks for the pointer! Regards, -- Francis Galiegue, fgaliegue@gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From nobody Thu Oct 30 05:40:02 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB071A003A for ; Thu, 30 Oct 2014 05:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtq_LsT1lT69 for ; Thu, 30 Oct 2014 05:39:56 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A16A1A0037 for ; Thu, 30 Oct 2014 05:39:56 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id g10so5101996pdj.10 for ; Thu, 30 Oct 2014 05:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wWzpInLVmZjUTg5LN20B8SAHpm8Mwed61sqWSDqoufc=; b=YbYPKnsgICqHAMz996pIV2J5TS8OAZt/tZ88FRd6hWQNBqbRcanEPczeJiApRKUcvY 9IMQw9D1bbJGrSSaRyD0W2V4xAOdRq+CL9YjHeaUMAWMGj6xcCwQBA52khuKA90Ureu8 /leBhvNOvCAtc+b7uQ8eZYT+Gc14NwWD8cttEJsto4rjXuKi/rnyU5iwXpft5w/npoXL D55FvzTr5DHD3mwVsf5bGgHoF8XCoVnzK/poF5B2oGduWSavRPPNrsTNcOfotiZlknnc eecXwXOiLPpcxCujcaLpIr+Em4mFcc8+tY9GHWf708S1YMou4s5Yr5AYrbJrbAd9NhTT cMYQ== MIME-Version: 1.0 X-Received: by 10.70.5.227 with SMTP id v3mr1969545pdv.165.1414672796245; Thu, 30 Oct 2014 05:39:56 -0700 (PDT) Received: by 10.70.32.165 with HTTP; Thu, 30 Oct 2014 05:39:56 -0700 (PDT) In-Reply-To: <723AD00E-4935-4B59-B692-370F2D887E27@tzi.org> References: <723AD00E-4935-4B59-B692-370F2D887E27@tzi.org> Date: Thu, 30 Oct 2014 13:39:56 +0100 Message-ID: From: Francis Galiegue To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Y_q3np4mdWkdqRL8l6m9IrUhVLg Cc: json@ietf.org Subject: Re: [Json] RFC 7386: correct indentation of the MergePatch function... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 12:39:58 -0000 On Thu, Oct 30, 2014 at 12:37 PM, Carsten Bormann wrote: [...] > > Unfortunately, not quite. > > http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-07 > > says: > > define MergePatch(Target, Patch): > if Patch is an Object: > if Target is not an Object: > Target = {} # Ignore the contents and set it to an empty Object > for each Name/Value pair in Patch: > if Value is null: > if Name exists in Target: > remove the Name/Value pair from Target > else: > Target[Name] = MergePatch(Target[Name], Value) > return Target > else: > return Patch > OK then, might I suggest that the pseudo-language used be independent of the indentation? This could be another erratum, I guess, only I don't even know how to "post" an erratum to begin with. Regards, -- Francis Galiegue, fgaliegue@gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From nobody Thu Oct 30 05:51:54 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366571A003B for ; Thu, 30 Oct 2014 05:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBoZh-_HyQzd for ; Thu, 30 Oct 2014 05:51:51 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62641A0059 for ; Thu, 30 Oct 2014 05:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9UCpkmR004684; Thu, 30 Oct 2014 13:51:46 +0100 (CET) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D504CA9B; Thu, 30 Oct 2014 13:51:46 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: Date: Thu, 30 Oct 2014 13:51:46 +0100 X-Mao-Original-Outgoing-Id: 436366305.793323-08a295c4931fe7f5190369715452e40f Content-Transfer-Encoding: quoted-printable Message-Id: References: <723AD00E-4935-4B59-B692-370F2D887E27@tzi.org> To: Francis Galiegue X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/json/SM3N7RgR_TGojovHIxXdw45HsJA Cc: json@ietf.org Subject: Re: [Json] RFC 7386: correct indentation of the MergePatch function... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 12:51:52 -0000 On 30 Oct 2014, at 13:39, Francis Galiegue wrote: >=20 > I > don't even know how to "post" an erratum to begin with. You don=E2=80=99t have to =E2=80=94 it=E2=80=99s already there: http://www.rfc-editor.org/errata_search.php?rfc=3D7386 If you have a look at https://tools.ietf.org/html/rfc7386, you can see = the red =E2=80=9CErrata exist=E2=80=9D, and the link =E2=80=9C[Errata]=E2=80= =9D on top of that. That leads to the errata known so far. (We need to campaign for the tools.ietf.org interface to the RFCs some = more; this is the only interface that alerts the reader to errata and/or = new versions of RFCs.) There isn=E2=80=99t necessarily a fundamental problem with = indentation-dependence here; there just was an accident with a = space-to-tab-to-space conversion on the way to the RFC, and because most = of the tools we tend to use, ignore whitespace, nobody noticed until it = was too late. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 30 08:23:59 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1902E1AD489 for ; Thu, 30 Oct 2014 08:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3L71OcdBzWRC for ; Thu, 30 Oct 2014 08:23:45 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0E61AD4FE for ; Thu, 30 Oct 2014 08:23:08 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id DFDFB3B9F7; Thu, 30 Oct 2014 16:23:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id C31F119065F; Thu, 30 Oct 2014 16:22:42 +0100 (CET) Date: Thu, 30 Oct 2014 16:22:42 +0100 From: Stephane Bortzmeyer To: Francis Galiegue Message-ID: <20141030152242.GA13287@sources.org> References: <723AD00E-4935-4B59-B692-370F2D887E27@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 7.7 User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/_u1UKei-i1ywizaq3-MmCk5kpe8 Cc: Carsten Bormann , json@ietf.org Subject: Re: [Json] RFC 7386: correct indentation of the MergePatch function... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:23:50 -0000 On Thu, Oct 30, 2014 at 01:39:56PM +0100, Francis Galiegue wrote a message of 39 lines which said: > OK then, might I suggest that the pseudo-language used be independent > of the indentation? This could be another erratum, I guess, No. The RFC editor insisted several times that the errata should be for _errors_, not for disagreements. The working group decided to use an indentation-dependant language, you may disagree but it is not an error. Instead, you should engage with the working group to convince it to switch. An Internet-Draft "Indentation-dependant languages for pseudocode considered harmful" could be a start. > only I don't even know how to "post" an erratum to begin with. http://www.rfc-editor.org/errata.php From nobody Thu Oct 30 08:29:05 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DA61AD50A for ; Thu, 30 Oct 2014 08:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pvs4Aa0Uhyp for ; Thu, 30 Oct 2014 08:29:01 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702921AD4E4 for ; Thu, 30 Oct 2014 08:28:08 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 1F2ED3BA1A; Thu, 30 Oct 2014 16:28:07 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id A4A2919065F; Thu, 30 Oct 2014 16:24:39 +0100 (CET) Date: Thu, 30 Oct 2014 16:24:39 +0100 From: Stephane Bortzmeyer To: Carsten Bormann Message-ID: <20141030152439.GB13287@sources.org> References: <723AD00E-4935-4B59-B692-370F2D887E27@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 7.7 User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/kwffmZGwbngB8ad7Fnrw6mivOTQ Cc: Francis Galiegue , json@ietf.org Subject: Re: [Json] RFC 7386: correct indentation of the MergePatch function... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:29:03 -0000 On Thu, Oct 30, 2014 at 01:51:46PM +0100, Carsten Bormann wrote a message of 18 lines which said: > You don’t have to — it’s already there: > > http://www.rfc-editor.org/errata_search.php?rfc=7386 The current one (#4132) is about a specific error caused by indentation. Francis wanted to report about the use of indentation itself (see my previous message for why it would be a bad idea to use the RFC errata system for that). From nobody Thu Oct 30 08:33:13 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAE91AD45B for ; Thu, 30 Oct 2014 08:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUbBI4H4Rx7z for ; Thu, 30 Oct 2014 08:33:08 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24451AD4F8 for ; Thu, 30 Oct 2014 08:33:07 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 93A4D3BA19; Thu, 30 Oct 2014 16:33:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id B3791190659; Thu, 30 Oct 2014 16:30:11 +0100 (CET) Date: Thu, 30 Oct 2014 16:30:11 +0100 From: Stephane Bortzmeyer To: Francis Galiegue Message-ID: <20141030153011.GA13798@sources.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 7.7 User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/vD1RZuqQRtruX-md-tADeHZoQ2w Cc: json@ietf.org Subject: Re: [Json] RFC 7386: correct indentation of the MergePatch function... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:33:11 -0000 On Thu, Oct 30, 2014 at 12:29:32PM +0100, Francis Galiegue wrote a message of 32 lines which said: > In the RFC as well as in the errata, the MergePatch function suffers > indentation problems. The errata is in state Verified which means it has been checked and found OK. If you spotted an error in it, you should report it with more details. From nobody Thu Oct 30 08:35:03 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA7C1AD487 for ; Thu, 30 Oct 2014 08:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERC_K2c2HgBj for ; Thu, 30 Oct 2014 08:34:56 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62491AD4E2 for ; Thu, 30 Oct 2014 08:34:56 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-34.dsl.dynamic.fusionbroadband.com [50.0.66.34]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s9UFYtSA013541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 08:34:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-0-66-34.dsl.dynamic.fusionbroadband.com [50.0.66.34] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Paul Hoffman In-Reply-To: <20141030152242.GA13287@sources.org> Date: Thu, 30 Oct 2014 08:34:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6F1A05D7-D6BA-452B-A7A3-C34DE6048B87@vpnc.org> References: <723AD00E-4935-4B59-B692-370F2D887E27@tzi.org> <20141030152242.GA13287@sources.org> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/json/jIRLaXFmsf8eUjNd4_3UwnWJmtw Cc: IETF JSON WG Subject: Re: [Json] RFC 7386: correct indentation of the MergePatch function... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:34:59 -0000 A few things here: - The corrected RFC is on its way. You can see the temporary version at = http://www.rfc-editor.org/authors/rfc7396.txt - Carsten Bormann suggested using pseudocode instead of the original = prose, and it got support. - When I introduced the specific pseudocode to the draft, I think there = were no objections, nor did I hear any suggestions for formats that = could be clearer. - I'm quite open to reissuing the RFC (again) with a different form of = pseudocode. We now have a working example of where it can be = misunderstood; what can we do better? --Paul Hoffman > On Oct 30, 2014, at 8:22 AM, Stephane Bortzmeyer = wrote: >=20 > On Thu, Oct 30, 2014 at 01:39:56PM +0100, > Francis Galiegue wrote=20 > a message of 39 lines which said: >=20 >> OK then, might I suggest that the pseudo-language used be independent >> of the indentation? This could be another erratum, I guess, >=20 > No. The RFC editor insisted several times that the errata should be > for _errors_, not for disagreements. The working group decided to use > an indentation-dependant language, you may disagree but it is not an > error. Instead, you should engage with the working group to convince > it to switch. An Internet-Draft "Indentation-dependant languages for > pseudocode considered harmful" could be a start. >=20 >> only I don't even know how to "post" an erratum to begin with. >=20 > http://www.rfc-editor.org/errata.php >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Thu Oct 30 09:50:30 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711A61A028A for ; Thu, 30 Oct 2014 09:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cGZOt1IUkRe for ; Thu, 30 Oct 2014 09:50:24 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467311A0196 for ; Thu, 30 Oct 2014 09:50:24 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id ft15so5435671pdb.25 for ; Thu, 30 Oct 2014 09:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0llWrU9PsF60YZc63zLcbkrXxPSHYzvB6T76I327Dok=; b=srx6XZ0UVoVrjNQTGCLcopV9Teq/+AuDoF1aTaDbw2wbIHa7ZvJ435j4wXvmxUJu63 7kyC8fOMYyfpUIii8pav9JRvnjD8FZ74ORc+w8SPj4+2m/269DtPCZtWv3+UbA9m5+Em nNdz4FkB4xVZ64ZBxrTx7ogdJegPVWr+6UuVQdemi/Y66Yn5AvPSf95S1VkYBGeQ2BYb /0K8lO32I8bdYqcgEz3FPVGvL0szHImdhTUzf39wSv59plbhVcRctltdz90PByJMktlL i5qAyXMux/zLFWzTIBfd/mzPzLZph5/rbDRKSZMbanAPoSjwUrBx6YZJGDputJt0khtO K52g== MIME-Version: 1.0 X-Received: by 10.68.57.200 with SMTP id k8mr2508403pbq.96.1414687823851; Thu, 30 Oct 2014 09:50:23 -0700 (PDT) Received: by 10.70.32.165 with HTTP; Thu, 30 Oct 2014 09:50:23 -0700 (PDT) In-Reply-To: <6F1A05D7-D6BA-452B-A7A3-C34DE6048B87@vpnc.org> References: <723AD00E-4935-4B59-B692-370F2D887E27@tzi.org> <20141030152242.GA13287@sources.org> <6F1A05D7-D6BA-452B-A7A3-C34DE6048B87@vpnc.org> Date: Thu, 30 Oct 2014 17:50:23 +0100 Message-ID: From: Francis Galiegue To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Q5HxrgK7IcbJ76A1ZzsefsYa-ZI Cc: Stephane Bortzmeyer , IETF JSON WG Subject: Re: [Json] RFC 7386: correct indentation of the MergePatch function... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 16:50:26 -0000 On Thu, Oct 30, 2014 at 4:34 PM, Paul Hoffman wrote: > A few things here: > > - The corrected RFC is on its way. You can see the temporary version at http://www.rfc-editor.org/authors/rfc7396.txt > OK, I may have had my priorities messed up in the original mail, but just one thing: "if" should be paired with "endif" in such pseudocode at the very least. In the current RFC, it isn't; and I am a seasoned programmer in languages where indentation _does not_ matter (C, C++, Java, take your pick) whereas the current wording in the RFC assumes seasoning in languages were indetation _does_ (Python and Cobol for instance). What does not help either is that indentation is done with only two spaces, which is difficult to read. See Linux' Documentation/CodingStyle (well, OK, I use 4, not 8, but I wouldn't even dare use 2). So, those are two problems. While I have no ready-made solution right now, I merely suggest that the pseudo code be made truly unambiguous, either by changing the language or indenting it in a more "readable" way. So yes, there are problems remaining. -- Francis Galiegue, fgaliegue@gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From nobody Fri Oct 31 16:51:11 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E151A874F for ; Fri, 31 Oct 2014 16:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0LyWUaGPo3v for ; Fri, 31 Oct 2014 16:51:05 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793B61A874E for ; Fri, 31 Oct 2014 16:51:05 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-34.dsl.dynamic.fusionbroadband.com [50.0.66.34]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s9VNp4Jo012851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 31 Oct 2014 16:51:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-0-66-34.dsl.dynamic.fusionbroadband.com [50.0.66.34] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Oct 2014 16:51:03 -0700 References: <20141031233049.C8558181C73@rfc-editor.org> To: IETF JSON WG Message-Id: <8B5BADA6-C5A6-4B96-A630-888B65F96E1A@vpnc.org> Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/json/YwbGOkLX3707pk5-e62A-BLBaz8 Subject: [Json] Fwd: [apps-discuss] RFC 7396 on JSON Merge Patch X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 23:51:09 -0000 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7396 >=20 > Title: JSON Merge Patch=20 > Author: P. Hoffman, J. Snell > Status: Standards Track > Stream: IETF > Date: October 2014 > Mailbox: paul.hoffman@vpnc.org,=20 > jasnell@gmail.com > Pages: 9 > Characters: 12791 > Obsoletes: RFC 7386 >=20 > URL: https://www.rfc-editor.org/rfc/rfc7396.txt >=20 > This specification defines the JSON merge patch format and processing > rules. The merge patch format is primarily intended for use with the > HTTP PATCH method as a means of describing a set of modifications to > a target resource's content. >=20 > This document is a product of the Applications Area Working Group = Working Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for = the=20 > standardization state and status of this protocol. Distribution of = this=20 > memo is unlimited. >=20