From nobody Sun Nov 1 18:32:19 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4A21AD0C5; Sun, 1 Nov 2015 18:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qx0FDGmtKc_I; Sun, 1 Nov 2015 18:32:14 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1211AD0BC; Sun, 1 Nov 2015 18:32:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.20,232,1444654800"; d="scan'208";a="41128429" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipoani.tcif.telstra.com.au with ESMTP; 02 Nov 2015 13:32:10 +1100 X-IronPort-AV: E=McAfee;i="5700,7163,7972"; a="289111045" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcdni.tcif.telstra.com.au with ESMTP; 02 Nov 2015 13:32:10 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Mon, 2 Nov 2015 13:32:09 +1100 From: "Manger, James" To: Anders Rundgren , "json@ietf.org" , "jose@ietf.org" Date: Mon, 2 Nov 2015 13:32:08 +1100 Thread-Topic: [jose] EcmaScript V6 - numbers Thread-Index: AdEVFKhfIy5zplRrQ6+/nA+BPRIwSQ== Message-ID: <255B9BB34FB7D647A506DC292726F6E13BB16C9857@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Json] [jose] EcmaScript V6 - numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 02:32:17 -0000 Hi Anders, For floating point numbers in JSON, I am not certain that removing digits b= eyond 15 guarantees a canonical form. Most (64-bit) doubles might have 15.9= 5 digits of precision, but what about the range of "denormal" doubles that = have less precision? My concern wasn't so much that the last digit might vary, but whether only = some implementations would round to shorter forms. For example, consider th= ree successive 64-bit doubles near 0.3. In hex with a base 2 exponent the v= alues are (java.lang.Double#toHexString(double)): 0x1.3333333333332p-2 0x1.3333333333333p-2 0x1.3333333333334p-2 The exact decimal values for these are: 0.29999999999999993338661852249060757458209991455078125 0.299999999999999988897769753748434595763683319091796875 0.3000000000000000444089209850062616169452667236328125 Canonical JSON forms need to be: 0.29999999999999993 0.3 0.30000000000000004 which have 17, 1, and 17 significant digits; but might some implementations= use 17 digits for the middle one as well? 0.29999999999999999 I now think that specifying a canonical form as the "shortest correct repre= sentation" can work; it does give a unique string for each 64-bit double (i= t gives 0.3 above). ECMAScript "ToString Applied to the Number Type" is not= quite phrased in this way, but it might be equivalent (with the recommende= d "accurate conversion" version). I am confident that V8 (ECMAScript in Chrome) produces this "shortest corre= ct representation". See DTOA_SHORTEST in https://chromium.googlesource.com/= v8/v8.git/+/master/src/dtoa.h. If a few other implement this form as well, = then it looks like the best way to define a canonical form for 64-bit doubl= es. Hopefully, interoperability with non-ECMAScript languages can be simpler th= an your es6JsonNumberSerialization(double) function. Ideally the following = should work: use ECMAScript's choice of when to include or omit an exponent= , and omit trailing zeros (and use lower-case). [may need to add a precisio= n and locale] static String toJsonString(double d) { double ad =3D Math.abs(d); if (1e-6d <=3D ad && ad < 1e21d) return String.format("%f", d).replaceFir= st("\\.?0++$", ""); else if (ad =3D=3D 0) return "0"; else return String.format("%g", d).replaceFirst("\\.?0++e", "e"); } Anders, Do you still think "the textual representation of numbers MUST be preserved= during parsing"? I would prefer to drop that and require serialization to use the "shortest = correct representation" + specify when to omit an exponent. -- James Manger -----Original Message----- From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren Sent: Monday, 26 October 2015 4:15 PM To: Manger, James ; json@ietf.org; jose@ie= tf.org Subject: Re: [jose] EcmaScript V6 - Defined Property Order On 2015-10-26 00:10, Manger, James wrote: > Hi Anders, > > I agree that the EcmaScript string format for numbers is a better basis f= or a canonical JSON format than, say, normalized scientific notation - part= icularly for the dominant case of integers less than 2^64. However, EcmaScr= ipt's ToString(number) doesn't quite give a canonical form. 7.1.12.1 step 5= says "the least significant digit of s is not necessarily uniquely determi= ned by these criteria". EcmaScript guarantees that ToNumber(ToString(x)) gi= ves the same number x, but that is not quite what we need for signing. We n= eed ToString(ToNumber(s)) to give the same string. I guess you could sign t= he 8 bytes of a 64-bit float, instead of the JSON decimal digits. Hi James, Thanx for pointing out this, it is apparently always a very good idea testi= ng concepts with other knowledgeable people before you actually start build= ing something :-) I guess the ES committee wasn't entirely happy about having to adjust their= spec. due to improper reliance on JavaScript property order by parts of th= e development community. But they probably did the right thing. I'm thinking in a similar way. Why let an edge-case spoil all the fun? Ma= ybe the ES6 vendors implement the same broken ToString algorithm or the imp= roved version mentioned as a note after the section you referred to? I won= 't research this issue now because I consider Ecma the sole "owner" of this= problem :-) So this is my (latest) suggestion for an upgraded in-object JSON clear-text= signature specification: "Due to limitations in the EcmaScript V6 [ECMA-262] specification rega= rding the ToString(number) method, it is for interoperability reasons RECOM= MENDED to utilize a maximum of 18 digits of precision for non-integer Number= s." It sure isn't pretty but since "business messaging" can't even use JSON/ES = numbers for expressing monetary amounts, it is hardly a show-stopper. Anders Rundgren > > James Manger > > -----Original Message----- > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren > Sent: Monday, 26 October 2015 2:33 AM > To: jose@ietf.org; json@ietf.org > Subject: Re: [jose] EcmaScript V6 - Defined Property Order > > Since the ES6 Number type is 64-bit IEEE, there's no need to worry about = number canonicalization either if you base the signature system on ES6 whic= h seems like a pretty safe bet. > > http://www.ecma-international.org/ecma-262/6.0/index.html#sec-tostring-ap= plied-to-the-number-type > > That is, AFAICT, clear-text in-object JSON signatures are already compati= ble with ES6 (and I must drop my "number preservation" stuff...). > > Folks working with constrained devices will probably settle for CBOR. > > On 2015-10-25 10:08, Anders Rundgren wrote: >> http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ordinary-o= bject-internal-methods-and-internal-slots-ownpropertykeys >> >> I can't say I'm able "deciphering" the ES6 specification but it seems th= at the largest base of JSON parsers (the browsers), now are compliant with = in-object JSON clear-text signature schemes of the kind I have proposed (pu= shing maybe...), albeit with some (IMO for practical purposes insignificant= ) limitations: >> >> - Integer property names doesn't work. >> - Numeric values would have to be normalized. >> >> Java, Python, and C# already manages this as well. >> >> Yay! >> >> Anders >> > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From nobody Sun Nov 1 19:30:23 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E961B32DD; Sun, 1 Nov 2015 19:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yu0QOw6K09pO; Sun, 1 Nov 2015 19:30:20 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2552E1B32DC; Sun, 1 Nov 2015 19:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id tA23UEPe012254; Mon, 2 Nov 2015 04:30:14 +0100 (CET) Received: from dhcp-38-127.meeting.ietf94.jp (t20010c4000003032cc8f9d73cbb98481.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3032:cc8f:9d73:cbb9:8481]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nq09x1R34z2Fj7; Mon, 2 Nov 2015 04:30:12 +0100 (CET) Message-ID: <5636D8BC.1020107@tzi.org> Date: Mon, 02 Nov 2015 12:30:04 +0900 From: Carsten Bormann User-Agent: Postbox 4.0.7 (Macintosh/20151021) MIME-Version: 1.0 To: "Manger, James" References: <255B9BB34FB7D647A506DC292726F6E13BB16C9857@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BB16C9857@WSMSG3153V.srv.dir.telstra.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "json@ietf.org" , "jose@ietf.org" , Anders Rundgren Subject: Re: [Json] [jose] EcmaScript V6 - numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 03:30:22 -0000 Here's mine (converting from C library %g format to JS toString format): class Float def cbor_diagnostic # do a little bit of JSON.stringify gaming (ECMA-262-2015, 7.1.12.1) a = abs if a < 1 && a >= 1e-6 inspect.sub(/(\d)[.](\d+)e-(\d+)/) {"0.#{"0" * ($3.to_i - 1)}#{$1}#{$2}"} else inspect.sub(/(e[+-])0+/) {$1} end end end Apart from selecting the shortest representation, you need to select details of the exponent format etc. But the biggest problem with number c14n in JSON is that the last digit may not be uniquely determined (i.e., there are a number of shortest-form decimal numbers that map to the same binary64). Grüße, Carsten From nobody Sun Nov 1 23:12:01 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB031B3201; Sun, 1 Nov 2015 23:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maA1o7SMvmge; Sun, 1 Nov 2015 23:11:51 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBAA1A00B1; Sun, 1 Nov 2015 23:11:49 -0800 (PST) Received: by wmeg8 with SMTP id g8so52325639wme.1; Sun, 01 Nov 2015 23:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=F6a+RQqrZH8TMjw92krO8P0DYmGCqA5ob0PG580tl3M=; b=nuAa45odfYHTqRfjcO/78D3mDrWgZ6Tp6R+vhW8CydLiuN1TDyYMvQ/uXMQtt4eOW9 QEG75IaKQHutAlgXBaYKMepIOyBfYe9XiyFFdDdUc8uNlKcgs0f4mVaO4jUZPKDFbWS1 YWn0ykYGBljftFBi2ZDMP+8IZOQFZ5470PP6lDe0mpPG2v57ArtX6XSZYDJ9urVe7HTw QzVl5HSL/v5joHojAjhovKte0BG2YFsIr1Nwxmk+LNEFD3kxUdyk5kWGGGaViXTlRXdX 3UtoYBD6QHStxJVoi/1JIikrCPUoOJyE7XwGuPFC9NCfDil0+AdghuiBNnuI5iqFpm0u A2Zw== X-Received: by 10.28.138.194 with SMTP id m185mr10775256wmd.92.1446448308302; Sun, 01 Nov 2015 23:11:48 -0800 (PST) Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id u126sm16458556wmd.3.2015.11.01.23.11.46 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Nov 2015 23:11:47 -0800 (PST) To: "Manger, James" , "json@ietf.org" , "jose@ietf.org" References: <255B9BB34FB7D647A506DC292726F6E13BB16C9857@WSMSG3153V.srv.dir.telstra.com> From: Anders Rundgren Message-ID: <56370CA8.7080304@gmail.com> Date: Mon, 2 Nov 2015 08:11:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BB16C9857@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] [jose] EcmaScript V6 - numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 07:11:55 -0000 On 2015-11-02 03:32, Manger, James wrote: > Hi Anders, Hi James, Disclaimer: I'm not a mathematician, I design and build systems. Comments in line: > > For floating point numbers in JSON, I am not certain that removing digits beyond 15 guarantees a canonical form. Most (64-bit) doubles might have 15.95 digits of precision, but what about the range of "denormal" doubles that have less precision? The original idea was defining a robust number canonicalization scheme that would be a true subset of ES6 at some expense of precision. My (maybe somewhat naive) belief is that 15 digits of precision should suffice for some 99.9999999999999% of all use-cases :-) This is addressed by the parseFloat(value.toPrecision(15)) "workaround". Anyway, whatever solution we come up with, it must IMO be possible to use today with ES6 as implemented in browsers (modulo apparent bugs...) otherwise absolutely nothing will happen. I don't see that a few restrictions or constraints would be show-stoppers. > > My concern wasn't so much that the last digit might vary, but whether only some implementations would round to shorter forms. Of course, what we need/want/require is a deterministic scheme. > For example, consider three successive 64-bit doubles near 0.3. In hex with a base 2 exponent the values are (java.lang.Double#toHexString(double)): > 0x1.3333333333332p-2 > 0x1.3333333333333p-2 > 0x1.3333333333334p-2 > The exact decimal values for these are: > 0.29999999999999993338661852249060757458209991455078125 > 0.299999999999999988897769753748434595763683319091796875 > 0.3000000000000000444089209850062616169452667236328125 > Canonical JSON forms need to be: > 0.29999999999999993 > 0.3 > 0.30000000000000004 > which have 17, 1, and 17 significant digits; but might some implementations use 17 digits for the middle one as well? > 0.29999999999999999 This is the same using Java BigDecimal: original: 0.29999999999999993338661852249060757458209991455078125 rounded: 0.300000000000000 to 15 digits of precision rounded: 0.2999999999999999 to 16 digits of precision rounded: 0.29999999999999993 to 17 digits of precision rounded: 0.299999999999999933 to 18 digits of precision original: 0.299999999999999988897769753748434595763683319091796875 rounded: 0.300000000000000 to 15 digits of precision rounded: 0.3000000000000000 to 16 digits of precision rounded: 0.29999999999999999 to 17 digits of precision rounded: 0.299999999999999989 to 18 digits of precision original: 0.3000000000000000444089209850062616169452667236328125 rounded: 0.300000000000000 to 15 digits of precision rounded: 0.3000000000000000 to 16 digits of precision rounded: 0.30000000000000004 to 17 digits of precision rounded: 0.300000000000000044 to 18 digits of precision So what you are saying is that since some IEEE numbers can be expressed with higher precision than 15.95 digits. this is what should also be done in signed data? I feel a bit leery about that since I don't have full insight in this topic and status of implementations. > > I now think that specifying a canonical form as the "shortest correct representation" can work; it does give a unique string for each 64-bit double (it gives 0.3 above). ECMAScript "ToString Applied to the Number Type" is not quite phrased in this way, but it might be equivalent (with the recommended "accurate conversion" version). > > I am confident that V8 (ECMAScript in Chrome) produces this "shortest correct representation". See DTOA_SHORTEST in https://chromium.googlesource.com/v8/v8.git/+/master/src/dtoa.h. If a few other implement this form as well, then it looks like the best way to define a canonical form for 64-bit doubles. I'm sure about that but this appears to be a task for TC 39 rather than the IETF. This won't happen though unless there is genuine support for a use-case that motivates such a work-item. Is there? > > Hopefully, interoperability with non-ECMAScript languages can be simpler than your es6JsonNumberSerialization(double) function. Ideally the following should work: use ECMAScript's choice of when to include or omit an exponent, and omit trailing zeros (and use lower-case). [may need to add a precision and locale] > > static String toJsonString(double d) > { > double ad = Math.abs(d); > if (1e-6d <= ad && ad < 1e21d) return String.format("%f", d).replaceFirst("\\.?0++$", ""); > else if (ad == 0) return "0"; > else return String.format("%g", d).replaceFirst("\\.?0++e", "e"); > } Thanx! Will test ASAP. > > Anders, > Do you still think "the textual representation of numbers MUST be preserved during parsing"? > I would prefer to drop that and require serialization to use the "shortest correct representation" + specify when to omit an exponent. Well, this is my "pre-ES6" scheme which indeed isn't strictly be necessary for what we are discussing now. I guess it at least nicely fits the IETF interoperability mantra "be conservative in what you do, be liberal in what you accept from others", right? Cheers, Anders R > > -- > James Manger > > > > -----Original Message----- > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren > Sent: Monday, 26 October 2015 4:15 PM > To: Manger, James ; json@ietf.org; jose@ietf.org > Subject: Re: [jose] EcmaScript V6 - Defined Property Order > > On 2015-10-26 00:10, Manger, James wrote: >> Hi Anders, >> >> I agree that the EcmaScript string format for numbers is a better basis for a canonical JSON format than, say, normalized scientific notation - particularly for the dominant case of integers less than 2^64. However, EcmaScript's ToString(number) doesn't quite give a canonical form. 7.1.12.1 step 5 says "the least significant digit of s is not necessarily uniquely determined by these criteria". EcmaScript guarantees that ToNumber(ToString(x)) gives the same number x, but that is not quite what we need for signing. We need ToString(ToNumber(s)) to give the same string. I guess you could sign the 8 bytes of a 64-bit float, instead of the JSON decimal digits. > Hi James, > Thanx for pointing out this, it is apparently always a very good idea testing concepts with other knowledgeable people before you actually start building something :-) > > I guess the ES committee wasn't entirely happy about having to adjust their spec. due to improper reliance on JavaScript property order by parts of the development community. But they probably did the right thing. > > I'm thinking in a similar way. Why let an edge-case spoil all the fun? Maybe the ES6 vendors implement the same broken ToString algorithm or the improved version mentioned as a note after the section you referred to? I won't research this issue now because I consider Ecma the sole "owner" of this problem :-) > > So this is my (latest) suggestion for an upgraded in-object JSON clear-text signature specification: > > "Due to limitations in the EcmaScript V6 [ECMA-262] specification regarding > the ToString(number) method, it is for interoperability reasons RECOMMENDED > to utilize a maximum of 18 digits of precision for non-integer Numbers." > > It sure isn't pretty but since "business messaging" can't even use JSON/ES numbers for expressing monetary amounts, it is hardly a show-stopper. > > Anders Rundgren > > >> James Manger >> >> -----Original Message----- >> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren >> Sent: Monday, 26 October 2015 2:33 AM >> To: jose@ietf.org; json@ietf.org >> Subject: Re: [jose] EcmaScript V6 - Defined Property Order >> >> Since the ES6 Number type is 64-bit IEEE, there's no need to worry about number canonicalization either if you base the signature system on ES6 which seems like a pretty safe bet. >> >> http://www.ecma-international.org/ecma-262/6.0/index.html#sec-tostring-applied-to-the-number-type >> >> That is, AFAICT, clear-text in-object JSON signatures are already compatible with ES6 (and I must drop my "number preservation" stuff...). >> >> Folks working with constrained devices will probably settle for CBOR. >> >> On 2015-10-25 10:08, Anders Rundgren wrote: >>> http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ordinary-object-internal-methods-and-internal-slots-ownpropertykeys >>> >>> I can't say I'm able "deciphering" the ES6 specification but it seems that the largest base of JSON parsers (the browsers), now are compliant with in-object JSON clear-text signature schemes of the kind I have proposed (pushing maybe...), albeit with some (IMO for practical purposes insignificant) limitations: >>> >>> - Integer property names doesn't work. >>> - Numeric values would have to be normalized. >>> >>> Java, Python, and C# already manages this as well. >>> >>> Yay! >>> >>> Anders >>> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From nobody Mon Nov 2 02:04:58 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2F51A1A10; Mon, 2 Nov 2015 02:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0VzfY1jcTmp; Mon, 2 Nov 2015 02:04:54 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4FFC1A1A24; Mon, 2 Nov 2015 02:04:53 -0800 (PST) Received: by wmec75 with SMTP id c75so55483287wme.1; Mon, 02 Nov 2015 02:04:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=+f6nR09Uj2svZrUiaShpQ5bCngJBcU0MtA74DuWpYQk=; b=i0HRLe0nWy5th1AGa6XsKhqwLb+G9LR8/PskKTyLfS5XxHERodnJHoEnoiD0NXy9mU hqzrAO5bmfzWdc1tSPZ7UkzjvMMTnUvR+wxqXSJx4Yx5/dx3jeg8pgdgbunHwqcoyLLR h5z2OjJOxSMGjwKbidANG3yvGCf41G/ALwk+3lsHhv18uy3XWe7rqaenEeFWu9NgyY95 rF7OJEoIFKqogEv4RvANlMevi4mfjPXsiA0LHu+n8S4zHnLHx8rrtc0Q+ntrnr2MKdlu pMkTaYzm2zDN9NRORTUjzNQ1zv8wmOAhZyCGEuNytitQzg5vrw4NhL6TJuqCzdNroUME 8khQ== X-Received: by 10.28.10.142 with SMTP id 136mr13115923wmk.84.1446458692336; Mon, 02 Nov 2015 02:04:52 -0800 (PST) Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id jh4sm21384747wjb.33.2015.11.02.02.04.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 02:04:51 -0800 (PST) To: "Manger, James" , "jose@ietf.org" , "json@ietf.org" References: <255B9BB34FB7D647A506DC292726F6E13BB16C9857@WSMSG3153V.srv.dir.telstra.com> From: Anders Rundgren Message-ID: <56373538.1000105@gmail.com> Date: Mon, 2 Nov 2015 11:04:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BB16C9857@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Json] Upgraded Test. Re: [jose] EcmaScript V6 - numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 10:04:57 -0000 Hi James, It seems that Java doesn't bother about the exact representation for edge-cases. http://webpki.org/ietf/es6numbertest.html From an interoperability point-of-view a system that provides between 15 and 17 correct digits wouldn't be technically (too) broken by only using 15 digits externally. I'm worried that this concern will rather kill an otherwise pretty good idea. However, it might suffice to use RECOMMENDED although it feels like a cheap trick to fool reviewers. I wouldn't hesitate using REQUIRED. When/if TC 39 comes out with a fully deterministic representation of numbers, the spec can be updated, I incorporated your formatter in the test. It needs some fixes, right? Anders On 2015-11-02 03:32, Manger, James wrote: > Hi Anders, > > For floating point numbers in JSON, I am not certain that removing digits beyond 15 guarantees a canonical form. Most (64-bit) doubles might have 15.95 digits of precision, but what about the range of "denormal" doubles that have less precision? > > My concern wasn't so much that the last digit might vary, but whether only some implementations would round to shorter forms. For example, consider three successive 64-bit doubles near 0.3. In hex with a base 2 exponent the values are (java.lang.Double#toHexString(double)): > 0x1.3333333333332p-2 > 0x1.3333333333333p-2 > 0x1.3333333333334p-2 > The exact decimal values for these are: > 0.29999999999999993338661852249060757458209991455078125 > 0.299999999999999988897769753748434595763683319091796875 > 0.3000000000000000444089209850062616169452667236328125 > Canonical JSON forms need to be: > 0.29999999999999993 > 0.3 > 0.30000000000000004 > which have 17, 1, and 17 significant digits; but might some implementations use 17 digits for the middle one as well? > 0.29999999999999999 > > I now think that specifying a canonical form as the "shortest correct representation" can work; it does give a unique string for each 64-bit double (it gives 0.3 above). ECMAScript "ToString Applied to the Number Type" is not quite phrased in this way, but it might be equivalent (with the recommended "accurate conversion" version). > > I am confident that V8 (ECMAScript in Chrome) produces this "shortest correct representation". See DTOA_SHORTEST in https://chromium.googlesource.com/v8/v8.git/+/master/src/dtoa.h. If a few other implement this form as well, then it looks like the best way to define a canonical form for 64-bit doubles. > > Hopefully, interoperability with non-ECMAScript languages can be simpler than your es6JsonNumberSerialization(double) function. Ideally the following should work: use ECMAScript's choice of when to include or omit an exponent, and omit trailing zeros (and use lower-case). [may need to add a precision and locale] > > static String toJsonString(double d) > { > double ad = Math.abs(d); > if (1e-6d <= ad && ad < 1e21d) return String.format("%f", d).replaceFirst("\\.?0++$", ""); > else if (ad == 0) return "0"; > else return String.format("%g", d).replaceFirst("\\.?0++e", "e"); > } > > Anders, > Do you still think "the textual representation of numbers MUST be preserved during parsing"? > I would prefer to drop that and require serialization to use the "shortest correct representation" + specify when to omit an exponent. > > -- > James Manger > > > > -----Original Message----- > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren > Sent: Monday, 26 October 2015 4:15 PM > To: Manger, James ; json@ietf.org; jose@ietf.org > Subject: Re: [jose] EcmaScript V6 - Defined Property Order > > On 2015-10-26 00:10, Manger, James wrote: >> Hi Anders, >> >> I agree that the EcmaScript string format for numbers is a better basis for a canonical JSON format than, say, normalized scientific notation - particularly for the dominant case of integers less than 2^64. However, EcmaScript's ToString(number) doesn't quite give a canonical form. 7.1.12.1 step 5 says "the least significant digit of s is not necessarily uniquely determined by these criteria". EcmaScript guarantees that ToNumber(ToString(x)) gives the same number x, but that is not quite what we need for signing. We need ToString(ToNumber(s)) to give the same string. I guess you could sign the 8 bytes of a 64-bit float, instead of the JSON decimal digits. > > Hi James, > Thanx for pointing out this, it is apparently always a very good idea testing concepts with other knowledgeable people before you actually start building something :-) > > I guess the ES committee wasn't entirely happy about having to adjust their spec. due to improper reliance on JavaScript property order by parts of the development community. But they probably did the right thing. > > I'm thinking in a similar way. Why let an edge-case spoil all the fun? Maybe the ES6 vendors implement the same broken ToString algorithm or the improved version mentioned as a note after the section you referred to? I won't research this issue now because I consider Ecma the sole "owner" of this problem :-) > > So this is my (latest) suggestion for an upgraded in-object JSON clear-text signature specification: > > "Due to limitations in the EcmaScript V6 [ECMA-262] specification regarding > the ToString(number) method, it is for interoperability reasons RECOMMENDED > to utilize a maximum of 18 digits of precision for non-integer Numbers." > > It sure isn't pretty but since "business messaging" can't even use JSON/ES numbers for expressing monetary amounts, it is hardly a show-stopper. > > Anders Rundgren > > >> >> James Manger >> >> -----Original Message----- >> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren >> Sent: Monday, 26 October 2015 2:33 AM >> To: jose@ietf.org; json@ietf.org >> Subject: Re: [jose] EcmaScript V6 - Defined Property Order >> >> Since the ES6 Number type is 64-bit IEEE, there's no need to worry about number canonicalization either if you base the signature system on ES6 which seems like a pretty safe bet. >> >> http://www.ecma-international.org/ecma-262/6.0/index.html#sec-tostring-applied-to-the-number-type >> >> That is, AFAICT, clear-text in-object JSON signatures are already compatible with ES6 (and I must drop my "number preservation" stuff...). >> >> Folks working with constrained devices will probably settle for CBOR. >> >> On 2015-10-25 10:08, Anders Rundgren wrote: >>> http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ordinary-object-internal-methods-and-internal-slots-ownpropertykeys >>> >>> I can't say I'm able "deciphering" the ES6 specification but it seems that the largest base of JSON parsers (the browsers), now are compliant with in-object JSON clear-text signature schemes of the kind I have proposed (pushing maybe...), albeit with some (IMO for practical purposes insignificant) limitations: >>> >>> - Integer property names doesn't work. >>> - Numeric values would have to be normalized. >>> >>> Java, Python, and C# already manages this as well. >>> >>> Yay! >>> >>> Anders >>> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From nobody Thu Nov 5 00:39:29 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9BF1A8A63 for ; Thu, 5 Nov 2015 00:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 Wr4nNBa5gZtd for ; Thu, 5 Nov 2015 00:39:24 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0124.outbound.protection.outlook.com [104.47.126.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E6081A014D for ; Thu, 5 Nov 2015 00:39:23 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [IPv6:2001:c40:0:3032:1885:674:583f:4d96] (2001:c40:0:3032:1885:674:583f:4d96) by TY1PR01MB0142.jpnprd01.prod.outlook.com (10.161.134.14) with Microsoft SMTP Server (TLS) id 15.1.312.18; Thu, 5 Nov 2015 08:39:18 +0000 To: Carsten Bormann , "Joe Hildebrand (jhildebr)" References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> <56342E23.6000509@tzi.org> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <563B15AD.3070309@it.aoyama.ac.jp> Date: Thu, 5 Nov 2015 17:39:09 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56342E23.6000509@tzi.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [2001:c40:0:3032:1885:674:583f:4d96] X-ClientProxiedBy: TY1PR01CA0017.jpnprd01.prod.outlook.com (25.161.131.155) To TY1PR01MB0142.jpnprd01.prod.outlook.com (25.161.134.14) X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0142; 2:X20sMSNdxpYHL5xEChA8AmXs7RLXMLtx76unMudUcgA7EgWvq9R0zqoqD0//krYg5m6EQhFLATi9bFj3SKh8YRuNAZ3TVboCTdppVJFByIJuAvGRBa18OrCJV9/8sOpHk0qA1dS1IbQ3YENu3OCRbwkWYfXEhZfSURAaLA+nrQk=; 3:SxQNZ10TYG9RVpBaRRRXqqurhSTA0h7jebCmZhznXlD3a5BAQxMO9hWfp/C2XwIIIt+1Xmq+K8wSb0Kjn8fsfwNuNuorMUXWom57RKQPW0xWe4/YUE8UHpnvUQ6agtkQbvGVkMq13Jp3Xf20WSX9Ng==; 25:cHm2OM3GkB7e2ReEAUDEn/Iff+Df2s/+JJ7o+0upXr4EohecVe7P8Rq9qLb1X3PFTdAdmU0GSgsC7gMQdrYarqJg/oLXg04CEPMMxkIiP7/kavcE2HB5lUQ4Tb/atZJXbJZPM6xGS8HXb7UaYpmttHU+7y94lPiouAFQKqrvmBzzsnPDJYSp6xEJHosECw8FD/gPkMWwiucM9wVYCjPFhgEFLofrxO39DoMcd7tgF8Yl8/HXLfcAGXtVypT41FYbLfTKgMsqL5ywRRqY3dOBzg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0142; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:TY1PR01MB0142; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0142; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0142; 4:Y9hbP2zrAVginddlz5zr7zvFka+QKIqEaQCm8Wrysbc0UlNr/5gzKmZL0jB6Ax6FRpIouYI3VZlgd8GxNeqzSCzb9xu9whv1zfK9PzV5LsK2t2sYD1ciAHID3MuO5qbaHV2+EKDvWpv0HNSue6RCE+2FEc2+Zl2Xqj5BPIECFhzFD+CMU3G495eQ02KwL2dihH93FZX0YKEQsjs8HAMdEoEZvPvg72x4bM+Hjsoo8z7tYvvhHMoH6HKK/dLIL8DX1m4+IhetBNOG/azjfOHbuKORauDikB2qpE+tkyn3AjZpLxB3rATQ8iP/Y4UaB4Q1fxFgHX3/7y9htLHLbefqX+6DXw4jg4CnujstPqSgxmhe4AxVudxG/r8Ni7PGEg0D X-Forefront-PRVS: 0751474A44 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(24454002)(189002)(199003)(4001350100001)(23676002)(15975445007)(86362001)(47776003)(106356001)(19580405001)(5007970100001)(74482002)(81156007)(5004730100002)(77096005)(40100003)(5001770100001)(189998001)(93886004)(97736004)(50466002)(42186005)(101416001)(2950100001)(87976001)(65956001)(33656002)(5008740100001)(54356999)(65816999)(5001960100002)(19580395003)(83506001)(64126003)(92566002)(105586002)(122386002)(87266999)(80316001)(50986999)(76176999)(59896002)(65806001)(3826002)(5001840100002); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0142; H:[IPv6:2001:c40:0:3032:1885:674:583f:4d96]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwMTQyOzIzOjdvVlo0dnFWU2JwczZ1bHhBUEY1YmgySURC?= =?utf-8?B?R0d0RVh5bFg0WTJYOE0zWG1BSGE0d1RITGZFMVh0RFllbVRRK2RpTGxsdlVk?= =?utf-8?B?WDFPd29wZzlKbmNMWDlGMGhoZm1WUjZiMWZ4aDR3dU9nREh5OThYMUxHY05C?= =?utf-8?B?eVBDR2NtbzN0T1Y2YlAwejl6dHRXUEN6ZWhOZXZmWjFRL2Z4ZDdTMXRtRytr?= =?utf-8?B?YTc1WDRVcmw2dTJKV1k2VnpuOGZyR0VGRFQycU52MkR4bytiSCtlSzdsVDRU?= =?utf-8?B?UzRGbGVjOFBVZzNGSjlFOVBFQjFIdXZEdGhIQloyOGF0Wm1yUW9pc3BILzVn?= =?utf-8?B?OHBiem5jQ0NDTVBDRkhCL0tDczFpWC9KdHprdEQwZlF3TlRYdUtlcXVEZkdY?= =?utf-8?B?Q21qVnVmSGpabHRDalA2NTBVZGgrTWptQ1FxMnZUUFVTWW5DQUwreHdzT3lE?= =?utf-8?B?YXlBR0dGck5tSUtSZkVUQ2VieFRJQVQzVkxtUEVoUGtEZEdJbDVBSmhBMXNY?= =?utf-8?B?bHhzWE1Dcm00djY2ZzFLMWpxSHRacU9DNDZnaE04SHF3QUhOYy9RVmNvSnVn?= =?utf-8?B?T3NwdFdhOGI5ZWxvME1tK0J1ekNMWmM5bkpXVTBGeldFK04xazhHektpdjdk?= =?utf-8?B?Y0dSc01HMEJrclgwUE01eCs0QkVjU0UyTHVEc0d3QmliVDdSUnFIMjJQYjhR?= =?utf-8?B?M0JXZ3RRbTl1TTdKNTVHUTFUZndxcU9xZGJ4dURvcHpNM1l6U0ZVdjNNZWJJ?= =?utf-8?B?OVV6MW5qV2I5VGdSaDQrSWdsalpIa0wzNjdlUWVxeTl2SldWeUNaQldUV09T?= =?utf-8?B?MzY5YktxZW9uMVFDMkV2eDJaZkNWZStSV1paeVdMZGd3aE1qeU93ZktZSHpp?= =?utf-8?B?QUFxb1ZwV24wWDFoODRtNTRRQk9ZMnZzNndBUUFJVmNRM2FETC9leHE4dUxr?= =?utf-8?B?SnNaQnU0SzZqVEZnWWZaQWwzbHU4Wi9RdVV0QTBxOWRyZFRsU28xNkRlendq?= =?utf-8?B?TFk3a29udXRYaC82N25TbUVySzIxUlkzUGdoRnQ1ZjRHVmRQd1c3ek9PZGtz?= =?utf-8?B?QURSaFZKaUJ2MjQ4TGJJR3huTkhYS1hwb3E3bDdCaUVDaGV5cTR0eVpqclAz?= =?utf-8?B?VUFJS1QrTkZXaXZDS3JPbHcwL0xjRWpPM3dlaWV5QnJTL1FOaGcvSlMzR1hD?= =?utf-8?B?U0psaDVaYTRFUXJuUDRZQWRibjJ5c1Zrd3VBMDlldDdKZ096M2VoeTdsYUM1?= =?utf-8?B?QStGUkR5dS81bXJHbzBGUVUrOUh0WDFteUE5VWE3NldJTitpenFjcXVRVFZZ?= =?utf-8?B?Wm54cURmdkJlVjIrZDllbWVQTk1HR0s4QmN4ci9SaDdBbGZsSUgwMFQxTXI3?= =?utf-8?B?UGdzVVJNL3lnamFCaFdzUXZNZVFhZnIyMkc0U1UyNmE1bzEwdjFzSmRYR29h?= =?utf-8?B?d1pSNzJqOCtCNldXWGRLY3FXV3VwcmF4ZUFleUtHZ0U1dUgxcTczNVA3OHZ4?= =?utf-8?B?VWh6bFJ6clFkZHBNT1AxRE9LVVFvbDBsalhFb3BiVlUzZzBaREdQbVN2VmEr?= =?utf-8?B?SVlGdXBIbDlzN0dLU1cyZ0hHbG1QUmpLUTNkNE1KS21xRFo5aUlFR01UbmtD?= =?utf-8?B?M2RhbXl4d3FYcCtPaDNvb2QxQ3B5SmRJVkVGMTRBQlRhd2tlYVJkRGh3NGwz?= =?utf-8?Q?6TAuRaI0fOOmrhi3Vf0o3Pv1plCii2eDOCX1PP8?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0142; 5:aTFetsBlE/k/L36bLOP401LD3FyUPSLb14oi4NYtaemtjTAKu6WU9lrh1dn2ijckiHxDWIh3I36nmKNXcbQoDCeVDR3gRaIVKKAMqQT/Q2SavWeWMTX/vTHdrIItoH7XgQx9sWP7aVt0NQuLSsKtwg==; 24:FqACuszIV7TJyOEEEBufjQHRZ6sltJ4C7uBE9HOM1f68iRUge3Q/pwzwWIXl3UH8gQaZdKNeCrauUNdCEGYTPvlbs3uWfO5VGBFa0qMR8Vo=; 20:U17CWSn45r0yTBBvw5rddvcj2rklHA61W+VVrAOGgBK2h7t/hUfS5Qt1gFc4qOyo86ZIgop95vPdcN91jY1CWg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Nov 2015 08:39:18.3816 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0142 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 08:39:28 -0000 I like this very much too. The approach is right, and the wording looks great. Regards, Martin. On 2015/10/31 11:57, Carsten Bormann wrote: > I like that approach. > > Grüße, Carsten > > > Joe Hildebrand (jhildebr) wrote: >> "This document intends to document the exact same data model as described in ECMA-404, which is the main document used by ECMAscript implementors. Implementors that want to interoperate with ECMAscript implementations (such as web browsers) are advised to also read ECMA-404 to understand any potential interoperability challenges. Any differences in the model described in this document with that described in ECMA-404 are not intentional, and will require the IETF and ECMA to work together to resolve the difference." >> >> >> That makes the normative reference understandable, and makes clear that the IETF and ECMA are partners in maintaining JSON going forward. >> > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Thu Nov 5 00:49:10 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8381A8A9D for ; Thu, 5 Nov 2015 00:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, 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 WmWQfzsiywA1 for ; Thu, 5 Nov 2015 00:49:07 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA16A1A8A9C for ; Thu, 5 Nov 2015 00:49:06 -0800 (PST) Received: by wmww144 with SMTP id w144so1638999wmw.1 for ; Thu, 05 Nov 2015 00:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=wTB58MZe0bOhk/ywft0HPDPINvq9Pj545uA3eVDWFok=; b=xd0BvTdKZL0yDBu/Mbgbd/LDGLx5pi+itu2fuQfLhNaXcvBGYqbtAoH6cuEwoEwen9 ovw/bwjvlVPq85bL2my/ERjXCGqEydyaHmuA/XIo9J9yqyPhhcj/FnVNOUeSAxyFiQBY bUDdH21z/R7n+CZ7QkBmo5iOUg7C/1DApfEzLxhD2RnwiQNON7MolkAIGI35Yk9kuVb3 GrUzqGDrfIMYysB7TTA1PQmXY9UcSB1bv9GNIb1MMaUvVTPz4Xa9FXVQJAtYj93LGyU1 6ytGITT++mvhyj2tDoSRPTh63LvdXN2bL5AUpRsFgLR9U+/09cbuBupLRFWhkq0f5jL1 dM8Q== X-Received: by 10.28.7.67 with SMTP id 64mr1956701wmh.70.1446713345317; Thu, 05 Nov 2015 00:49:05 -0800 (PST) Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id c1sm5767661wjf.19.2015.11.05.00.49.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Nov 2015 00:49:04 -0800 (PST) To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Carsten Bormann , "Joe Hildebrand (jhildebr)" References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> <56342E23.6000509@tzi.org> <563B15AD.3070309@it.aoyama.ac.jp> From: Anders Rundgren Message-ID: <563B17FF.5050002@gmail.com> Date: Thu, 5 Nov 2015 09:49:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563B15AD.3070309@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 08:49:09 -0000 On 2015-11-05 09:39, Martin J. Dürst wrote: > I like this very much too. The approach is right, and the wording looks > great. > > Regards, Martin. > > On 2015/10/31 11:57, Carsten Bormann wrote: >> I like that approach. >> >> Grüße, Carsten >> >> >> Joe Hildebrand (jhildebr) wrote: >>> "This document intends to document the exact same data model as described in ECMA-404, >>> which is the main document used by ECMAscript implementors. Implementors that want to >>> interoperate with ECMAscript implementations (such as web browsers) are advised to also >>> read ECMA-404 to understand any potential interoperability challenges. Since EMCAScript introduces predictable property order, the reference to EMCA-404 doesn't really tell the whole interoperability story. Anders Any differences in the model described in this document with that described in ECMA-404 are not intentional, and will require the IETF and ECMA to work together to resolve the difference." >>> >>> >>> That makes the normative reference understandable, and makes clear that the IETF and ECMA are partners in maintaining JSON going forward. >>> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Sun Nov 8 07:59:46 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E8E1B31D7; Sun, 8 Nov 2015 07:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8aRlxemzjfx; Sun, 8 Nov 2015 07:59:42 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA311B31D4; Sun, 8 Nov 2015 07:59:41 -0800 (PST) Received: by wmww144 with SMTP id w144so13653233wmw.0; Sun, 08 Nov 2015 07:59:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=wxHC70KBtHz2GNlL1XuCZy3xyNVE1nHfqwnmXmf9XIk=; b=k/ZfeWoAjPg74j4yWNVFkmNmLRQa8XHqFCm7WPrNCGS2ZZWbUSsycJM3SAH2Bgm9pn bjZc7KJM6IPs3+SI1LaPHSQYzSly5F611wDkKvrWdTUNoUmBYRDyeBfn60dp9Wu6W34c uTWSGnbBqQokw5rPKZUjM7W+YS5mWiKmU9/8zXv76S5TpAaFvvEj1l7SLwYvp+4eWFX0 J9k9nqn3HFNASY5g3aNZxUcfIdO6dz+a9KesvCYxzmK2zEtcEr8++YKhofGgHSJoAv3d hi9TT/O2Qe5sHgPSW8tVDMsK0oB1pIyEdFH39jBsdwaoX+y2dlzNLXrYWh2fdJLGZYNc q5MA== X-Received: by 10.28.138.148 with SMTP id m142mr22057611wmd.2.1446998380185; Sun, 08 Nov 2015 07:59:40 -0800 (PST) Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id n17sm9444455wmg.17.2015.11.08.07.59.36 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Nov 2015 07:59:39 -0800 (PST) To: "jose@ietf.org" , "json@ietf.org" From: Anders Rundgren Message-ID: <563F7160.30603@gmail.com> Date: Sun, 8 Nov 2015 16:59:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Json] Canonicalized 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: Sun, 08 Nov 2015 15:59:43 -0000 Canonical JSON would [probably] be cool but it isn't a reality. Anyway, I have continued the quest into ES6 and the canonicalization of Numbers and AFAICT [1] a bunch of ES6-vendors [2] have selected algorithms [3] that produce deterministic and interoperable values for serializing and deserializing Numbers. That is, no workarounds of any kind are necessary for using in-object JS or JSON signatures like the JS-example below which was created by my just updated reference implementation: var reading = { device: "Pump2", value: 13000, signature: { algorithm: "ES256", publicKey: { type: "EC", curve: "P-256", x: "ajlL4ksVEi-T589G7X9H4VOLoqbMkzPQw_GQFvUIXMA", y: "BdNg_sfSs6cZsYiMoRSmvnFOHXHJhYf9adQTkP1yweA" }, value: "VMbKgogiOeoWQd7tT9_vqNVxUm0fg7phsITvfj6Ggd_ghYj0BzW30QOS69tiYL0tTIEMVI4Kf9ZnQUocrr7XYQ" } }; 1] Test-file with specific values as well as random numbers. 10 million total: http://webpki.org/ietf/es6testfile.txt 2] Google (Chrome), Mozilla (Firefox), and Apple (Safari). 3] https://github.com/cyberphone/openkeystore/blob/master/library/src/org/webpki/json/DToA.java - anders From nobody Mon Nov 9 13:20:33 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142AA1B836F for ; Mon, 9 Nov 2015 13:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1OlJzkCL8Vc for ; Mon, 9 Nov 2015 13:20:27 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13AE11B847B for ; Mon, 9 Nov 2015 13:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1380; q=dns/txt; s=iport; t=1447104026; x=1448313626; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SwevyYca2NnmtozSTyg7IttTAwqrKbmVE/RXRC+mva4=; b=C3U1YbvvlP1FcKoJwiNJMoeKEtNjO5JIFGPfnKrMAiaHk6s24X6mqGG5 l2Nl0PsdC/eGz7gxN9bfAf9dUInaCHut0nWHPvtHxwJziry691qZQGlv8 qbcakt7WfToUPwWt83bdnUi5z88tJ1NFmUkCcwGcqgUBRU/w5gQ9IqjLP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQDXDUFW/4oNJK1eDoMtgUIGvjgBD?= =?us-ascii?q?YFjhhACHIEpOBQBAQEBAQEBgQqENgEBBCMRRRACAQgaAiYCAgIfERUQAgQBDQW?= =?us-ascii?q?IGQMSsRWMCw2ESQEBAQEBAQEBAQEBAQEBAQEBAQEBARiBAYVTghCCboJTggaDH?= =?us-ascii?q?C+BFQEEh0aPAgGIDYMkgXWBW4RAjleHUgEfAQFCg0Y+cgGEXoEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,267,1444694400"; d="scan'208";a="45366856" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP; 09 Nov 2015 21:20:05 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tA9LK5uR004856 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2015 21:20:05 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 9 Nov 2015 16:20:05 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.000; Mon, 9 Nov 2015 16:20:05 -0500 From: "Joe Hildebrand (jhildebr)" To: Anders Rundgren , =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= , "Carsten Bormann" Thread-Topic: [Json] Kicking Off JSONbis Thread-Index: AQHRF6V8wbG58cqRTk2NlHPfs03MdJ6NciuAgAalzoA= Date: Mon, 9 Nov 2015 21:20:04 +0000 Message-ID: References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> <56342E23.6000509@tzi.org> <563B15AD.3070309@it.aoyama.ac.jp> <563B17FF.5050002@gmail.com> In-Reply-To: <563B17FF.5050002@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.203.19] Content-Type: text/plain; charset="utf-8" Content-ID: <849B17323D2B8046883E3BEBE108F023@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 09 Nov 2015 21:20:30 -0000 T24gMTEvNS8xNSwgMTo0OSBBTSwgImpzb24gb24gYmVoYWxmIG9mIEFuZGVycyBSdW5kZ3JlbiIg PGpzb24tYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYW5kZXJzLnJ1bmRncmVuLm5ldEBn bWFpbC5jb20+IHdyb3RlOg0KDQoNCg0KPlNpbmNlIEVNQ0FTY3JpcHQgaW50cm9kdWNlcyBwcmVk aWN0YWJsZSBwcm9wZXJ0eSBvcmRlciwgdGhlIHJlZmVyZW5jZSB0byBFTUNBLTQwNCBkb2Vzbid0 DQo+cmVhbGx5IHRlbGwgdGhlIHdob2xlIGludGVyb3BlcmFiaWxpdHkgc3RvcnkuDQoNClRoYXQg cHJlZGljdGFiaWxpdHkgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgd2lyZSBmb3JtYXQsIHRo b3VnaC4gIEl0J3Mgc3BlY2lmaWMgdG8gdGhlIEVDTUFzY3JpcHQgc2VyaWFsaXplciBhbmQgZG9l cyBub3QgYWZmZWN0IHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGdlbmVyYXRlZCBkb2N1bWVudC4gIEl0 J3Mgbm90IGV2ZW4gdGVycmlibHkgdXNlZnVsIGZvciBjYW5vbmljYWxpemF0aW9uLCB3aXRob3V0 IGdvaW5nIHRvIHRoZSB0cm91YmxlIG9mIGNyZWF0aW5nIGEgbmV3IEVTIG9iamVjdCBidWlsdCBp biB0aGUgY29ycmVjdCBvcmRlciwgd2hpY2ggc2VlbXMgZXJyb3ItcHJvbmUuICBPbiB0aGUgcGFy c2Ugc2lkZSwgSSAqZ3Vlc3MqIHlvdSBtaWdodCB3YW50IHRvIGtub3cgdGhhdCB0aGVyZSBpcyBh biBpbmZvcm1hdGlvbiBzaWduYWwgcmV0YWluZWQgYnkgdGhlIG9yZGVyIG9mIHByb3BlcnRpZXMu ICBUaGF0IGNvdWxkIGJlIHVzZWQgYXMgYSBzdGVnYW5vZ3JhcGhpYyBjaGFubmVsLCBmb3IgaW5z dGFuY2UuICBJdCBkb2Vzbid0IHNlZW0gc3BlY2lmaWMgdG8gRVMsIHRob3VnaC4NCg0KSSB0aGlu ayB0aGVyZSBtYXliZSBzb21lIG90aGVyIHJlYXNvbiB3aHkgRVMncyBwcm9wZXJ0eSBvcmRlciBs b2dpYyBtaWdodCBiZSBpbnRlcmVzdGluZyB0byB5b3UgdGhvdWdoIC0gY2FuIHlvdSBzYXkgbW9y ZSwgcGxlYXNlPw0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQoNCg== From nobody Tue Nov 10 08:20:20 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80431B2EC4 for ; Tue, 10 Nov 2015 08:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, 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 QA5nE5LXb0dI for ; Tue, 10 Nov 2015 08:20:17 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B2D1B3A28 for ; Tue, 10 Nov 2015 08:19:22 -0800 (PST) Received: by wmec201 with SMTP id c201so141770455wme.0 for ; Tue, 10 Nov 2015 08:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=tNWqNE2WMsyTZwHkyH2av1Lj/9uQQ7QVTOWdorwTCzU=; b=qygMoRoYgcH1D1A5amQ2FagQREC7gLqRsxhyld/8Kv73xjFNM9zfR1Ljegzxky3t9j DbOR6asPGGdl377m7P0F5FfeRTnZfaTE5NnNUhT7cuVTato2+QH6dnHLsVIwxkiZ/1eq XPfm01fPxx5GSaIpPg5f2Mv85wTsWSh6odD0YqGtW90EHx7XRK8EXiI8CK1mTiP5d0Xd SiQzcXiZl80P5d2vioM/xvLJjC8wnT1pLIa67QSbxR3m0dyhnSphC/oUURRt4G0Y1TO/ K4+CreS7sGJ1GirJm9HX5S3csQKtetktd9l58AauMHZw2iTfMGn+LVPUldEhOjm1M1fj C2Xg== X-Received: by 10.194.243.102 with SMTP id wx6mr4993807wjc.68.1447172361345; Tue, 10 Nov 2015 08:19:21 -0800 (PST) Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id h4sm4257715wjx.41.2015.11.10.08.19.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Nov 2015 08:19:20 -0800 (PST) To: "Joe Hildebrand (jhildebr)" , =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Carsten Bormann References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> <56342E23.6000509@tzi.org> <563B15AD.3070309@it.aoyama.ac.jp> <563B17FF.5050002@gmail.com> From: Anders Rundgren Message-ID: <56421902.8040001@gmail.com> Date: Tue, 10 Nov 2015 17:19:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 10 Nov 2015 16:20:18 -0000 On 2015-11-09 22:20, Joe Hildebrand (jhildebr) wrote: > On 11/5/15, 1:49 AM, "json on behalf of Anders Rundgren" wrote: > > > >> Since EMCAScript introduces predictable property order, the reference to EMCA-404 doesn't >> really tell the whole interoperability story. > That predictability has nothing to do with the wire format, though. It's specific to the ECMAscript serializer and does not affect the semantics of the generated document. It's not even terribly useful for canonicalization, without going to the trouble of creating a new ES object built in the correct order, which seems error-prone. On the creation side there is nothing special to do in an ES6 environment. In a non-ES6 JSON toolbox, you only need to use an ordered dictionary like LinkedHashMap in Java to get things right. Well, numeric properties would need something else but that appears to be an edge-case, not worth bothering with. For those who disagree with that, strict creation order does in no way rule out numeric property order, it only requires a bit more care by the programmer :-) > On the parse side, I *guess* you might want to know that there is an information signal retained by the order of properties. That could be used as a steganographic channel, for instance. It doesn't seem specific to ES, though. > > I think there maybe some other reason why ES's property order logic might be interesting to you though - can you say more, please? > My target application has since mid-2013 been a JSONesque counterpart to XML's enveloped signatures but without getting bogged down by complex, stand-alone canonicalizers. The latest developments seem to verify that the most difficult part of JSON (Numbers), also are properly canonicalized by the majority (but not all) ES6 implementations. This enables very simple and efficient "in-object" JavaScript and JSON signatures which only rely on standard JavaScript for creating and manipulating objects and the built-in JSON parse/stringify methods for parsing and serialization respectively: https://mailarchive.ietf.org/arch/msg/jose/s5TdEtfOdQ0z3Qmtij2yXemZW-A Anders From nobody Wed Nov 11 13:31:13 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48DD1B3A7C for ; Wed, 11 Nov 2015 13:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np81bRp6du42 for ; Wed, 11 Nov 2015 13:31:11 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56DF91B3A72 for ; Wed, 11 Nov 2015 13:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3900; q=dns/txt; s=iport; t=1447277471; x=1448487071; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RtayIeEOS4BpWmL+7PaC1WX5TrzeWCvOyMz21weTHGU=; b=iR1AzSHe/H/XEo+b2IXFJ7aajVL/uC/bH3ZTK34HNL9jtWD4jMCF5vCJ Biw/MNBuoBb5PolhOPV612m05t+CFk7IIt38wcVoc4nTHzER7iLEx+Iin mnPy0Qr3Q9X4a3SB7LZelKw0Xg4th14PAASxnDSoHFYQ5vS4qAbavOk74 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHBQDvskNW/5NdJa1eDoMtU28GviaBZ?= =?us-ascii?q?SWFawIcgS46EgEBAQEBAQGBCoQ1AQEDASMRRRACAQgaAiYCAgIfERUQAgQBDQW?= =?us-ascii?q?IGQMKCA2zeowDDYRjAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEBhVOCEIJuglOCB?= =?us-ascii?q?oMcL4EVBZZIAYUcgnCDJIF1gVuEQI5Xh1IBKAU2ghEdgRg+cgGEToEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,277,1444694400"; d="scan'208";a="49688055" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Nov 2015 21:31:10 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id tABLVA0s000436 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2015 21:31:10 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 Nov 2015 16:31:09 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.000; Wed, 11 Nov 2015 16:31:09 -0500 From: "Joe Hildebrand (jhildebr)" To: Anders Rundgren , =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= , "Carsten Bormann" Thread-Topic: [Json] Kicking Off JSONbis Thread-Index: AQHRF6V8wbG58cqRTk2NlHPfs03MdJ6NciuAgAalzoCAAbOhAIABdCOA Date: Wed, 11 Nov 2015 21:31:09 +0000 Message-ID: <313EF0F9-0DC4-432B-9904-1E8B4C483EA9@cisco.com> References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> <56342E23.6000509@tzi.org> <563B15AD.3070309@it.aoyama.ac.jp> <563B17FF.5050002@gmail.com> <56421902.8040001@gmail.com> In-Reply-To: <56421902.8040001@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.203.19] Content-Type: text/plain; charset="utf-8" Content-ID: <14A5C9CA2383CB4690E40230F744DB62@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 11 Nov 2015 21:31:13 -0000 T24gMTEvMTAvMTUsIDk6MTkgQU0sICJBbmRlcnMgUnVuZGdyZW4iIDxhbmRlcnMucnVuZGdyZW4u bmV0QGdtYWlsLmNvbT4gd3JvdGU6DQoNCg0KDQo+T24gdGhlIGNyZWF0aW9uIHNpZGUgdGhlcmUg aXMgbm90aGluZyBzcGVjaWFsIHRvIGRvIGluIGFuIEVTNiBlbnZpcm9ubWVudC4gIEluIGEgbm9u LUVTNiBKU09OIHRvb2xib3gsIHlvdSBvbmx5IG5lZWQgdG8gdXNlIGFuIG9yZGVyZWQgZGljdGlv bmFyeSBsaWtlIExpbmtlZEhhc2hNYXAgaW4gSmF2YSB0byBnZXQgdGhpbmdzIHJpZ2h0LiANCg0K SSB1bmRlcnN0YW5kIHRoYXQgSSAqY291bGQqIHdyaXRlIGNvZGUgdG8gZ2VuZXJhdGUga2V5cyBp biB0aGUgc2FtZSBvcmRlciwgYnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgSSB3b3VsZCBib3Ro ZXIsIHdoZW4gdGhlIHNwZWNpZmllZCBvcmRlciBpczoNCg0KKGZyb206IGh0dHA6Ly93d3cuZWNt YS1pbnRlcm5hdGlvbmFsLm9yZy9lY21hLTI2Mi82LjAvI3NlYy1vcmRpbmFyeS1vYmplY3QtaW50 ZXJuYWwtbWV0aG9kcy1hbmQtaW50ZXJuYWwtc2xvdHMtb3ducHJvcGVydHlrZXlzKQ0KDQoNCi0g SW50ZWdlciBrZXlzIGluIG51bWVyaWMgb3JkZXIgKG9rLCBtYWtlcyBzZW5zZSBmb3IgYXJyYXkt bGlrZSB0aGluZ3MsIGJ1dCBzZWVtcyBtb3N0bHkgbW9vdCBmb3IgSlNPTikNCi0gU3RyaW5nIGtl eXMgaW4gKmNyZWF0aW9uKiBvcmRlcg0KDQpJIGRvbid0IHlldCBzZWUgaG93IGNyZWF0aW9uIG9y ZGVyIGlzIHVzZWZ1bCB0byBwcmVzZXJ2ZS4NCg0KPldlbGwsIG51bWVyaWMgcHJvcGVydGllcyB3 b3VsZCBuZWVkIHNvbWV0aGluZyBlbHNlIGJ1dCB0aGF0IGFwcGVhcnMgdG8gYmUgYW4gZWRnZS1j YXNlLCBub3Qgd29ydGggYm90aGVyaW5nIHdpdGguICAgRm9yIHRob3NlIHdobyBkaXNhZ3JlZSB3 aXRoIHRoYXQsIHN0cmljdCBjcmVhdGlvbiBvcmRlciBkb2VzIGluIG5vIHdheSBydWxlIG91dCBu dW1lcmljIHByb3BlcnR5IG9yZGVyLCBpdCBvbmx5IHJlcXVpcmVzIGEgYml0IG1vcmUgY2FyZSBi eSB0aGUgcHJvZ3JhbW1lciA6LSkNCg0KUGxlYXNlIGZvY3VzIG9uIHRoZSBpbnRlcm9wZXJhYmls aXR5IGJlbmVmaXRzLg0KDQo+PiAgIE9uIHRoZSBwYXJzZSBzaWRlLCBJICpndWVzcyogeW91IG1p Z2h0IHdhbnQgdG8ga25vdyB0aGF0IHRoZXJlIGlzIGFuIGluZm9ybWF0aW9uIHNpZ25hbCByZXRh aW5lZCBieSB0aGUgb3JkZXIgb2YgcHJvcGVydGllcy4gIFRoYXQgY291bGQgYmUgdXNlZCBhcyBh IHN0ZWdhbm9ncmFwaGljIGNoYW5uZWwsIGZvciBpbnN0YW5jZS4gIEl0IGRvZXNuJ3Qgc2VlbSBz cGVjaWZpYyB0byBFUywgdGhvdWdoLg0KPj4NCj4+IEkgdGhpbmsgdGhlcmUgbWF5YmUgc29tZSBv dGhlciByZWFzb24gd2h5IEVTJ3MgcHJvcGVydHkgb3JkZXIgbG9naWMgbWlnaHQgYmUgaW50ZXJl c3RpbmcgdG8geW91IHRob3VnaCAtIGNhbiB5b3Ugc2F5IG1vcmUsIHBsZWFzZT8NCj4+DQo+DQo+ TXkgdGFyZ2V0IGFwcGxpY2F0aW9uIGhhcyBzaW5jZSBtaWQtMjAxMyBiZWVuIGEgSlNPTmVzcXVl IGNvdW50ZXJwYXJ0IHRvIFhNTCdzIGVudmVsb3BlZCBzaWduYXR1cmVzIGJ1dCB3aXRob3V0IGdl dHRpbmcgYm9nZ2VkIGRvd24gYnkgY29tcGxleCwgc3RhbmQtYWxvbmUgY2Fub25pY2FsaXplcnMu ICBUaGUgbGF0ZXN0IGRldmVsb3BtZW50cyBzZWVtIHRvIHZlcmlmeSB0aGF0IHRoZSBtb3N0IGRp ZmZpY3VsdCBwYXJ0IG9mIEpTT04gKE51bWJlcnMpLCBhbHNvIGFyZSBwcm9wZXJseSBjYW5vbmlj YWxpemVkIGJ5IHRoZSBtYWpvcml0eSAoYnV0IG5vdCBhbGwpIEVTNiBpbXBsZW1lbnRhdGlvbnMu ICBUaGlzIGVuYWJsZXMgdmVyeSBzaW1wbGUgYW5kIGVmZmljaWVudCAiaW4tb2JqZWN0IiBKYXZh U2NyaXB0IGFuZCBKU09OIHNpZ25hdHVyZXMgd2hpY2ggb25seSByZWx5IG9uIHN0YW5kYXJkIEph dmFTY3JpcHQgZm9yIGNyZWF0aW5nIGFuZCBtYW5pcHVsYXRpbmcgb2JqZWN0cyBhbmQgdGhlIGJ1 aWx0LWluIEpTT04gcGFyc2Uvc3RyaW5naWZ5IG1ldGhvZHMgZm9yIHBhcnNpbmcgYW5kIHNlcmlh bGl6YXRpb24gcmVzcGVjdGl2ZWx5Og0KPg0KPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvam9zZS9zNVRkRXRmT2RRMHozUW10aWoyeVhlbVpXLUENCg0KT2ghICBZb3UncmUg cmVseWluZyBvbiB0aGUgcGFyc2luZyBhbmQgc2VyaWFsaXppbmcgY29kZSB0byBiZSBwYXJhbGxl bCwgc3VjaCB0aGF0IHRoZSBwYXJzZXIgbWFpbnRhaW5zIG9yZGVyLCBhbmQgdGhlIHNlcmlhbGl6 ZXIgcmVwZWF0cyB0aGF0IG9yZGVyIG9uIG91dHB1dC4NCg0KSW50ZXJlc3RpbmcuICBIb3dldmVy LCB0aGF0IHdvdWxkIGJlIGEgbWFqb3IgY2hhbmdlIHRvIHRoZSBKU09OIHNwZWMgKHRoYXQgd291 bGQgbmVjZXNzaXRhdGUgY2hhbmdlcyB0byBMT1RTIG9mIGV4aXN0aW5nIGNvZGUsIGF0IGEgcGVy Zm9ybWFuY2Ugb3IgbWVtb3J5IHBlbmFsdHkpLiBJdCBhbHNvIHRvb2sgbWUgYSBnb29kIGFtb3Vu dCBvZiB0aW1lIHRvIHRyYWNrIGRvd24gZXZlbiBpbiB0aGUgRUNNQXNjcmlwdCBkb2MgLSBzbyBJ IGRvbid0IHRoaW5rIHlvdSBjYW4gZXhwZWN0IG1vc3QgZm9sa3MgcmVhZGluZyBFQ01BLTQwNCB0 byBmaWd1cmUgdGhpcyBvdXQgZWl0aGVyLiAgSWYgeW91IHJlYWxseSB3YW50IGludGVyb3BlcmFi aWxpdHksIHRoZXJlJ3Mgbm90aGluZyBzdG9wcGluZyB5b3UgZnJvbSBkb2luZyBzb21ldGhpbmcg bGlrZSBJLUpTT04gdGhhdCBzYXlzIGFuIG9yZGVyZWQtanNvbiBpcyBKU09OLCBleGNlcHQgZm9y IHNvbWUgb3RoZXIgY29uc3RyYWludHMuDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Wed Nov 11 13:58:15 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3EB1A90A1 for ; Wed, 11 Nov 2015 13:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn26rGWPWpY3 for ; Wed, 11 Nov 2015 13:58:12 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0BD1A8AFA for ; Wed, 11 Nov 2015 13:58:12 -0800 (PST) Received: by ykdr82 with SMTP id r82so73516806ykd.3 for ; Wed, 11 Nov 2015 13:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=G8U6Ai+5F0sKf+QnqQfSlA2bS9oIRTYnnsX1a0SnwJs=; b=MuKkM6h60eesh3jxqZSB7ayrLiMQNAm4c7LkWyGaeYW627PldaIG660wEO4Yq8cPy1 yMqfMdNYmQZzpP+LknBwU5QWaYG+xb0kak7uRu/88DKqgsuA/GbpO9ppAXfUAzM3icgb 0VxyxyG/EApLq5ODFhZxgm+tccAuBL525F3J5Zb8T5ebh1UpU2q+5LE7VNFGoAErQ54m +JLdSOWKriHW1DJm20A2vMWDjbka6MgcRyupZWYV7l4Rc9m8hPiSIWAIa23Y+xcvvwaM 6zPDEfTqA0r8GGkt74fNSp9XOlCxzoz2/eHsocmFIyKxwoKsZO7cQ5qiwr2XM+QFxqo8 SqMA== X-Received: by 10.129.114.213 with SMTP id n204mr6773778ywc.72.1447279091576; Wed, 11 Nov 2015 13:58:11 -0800 (PST) Received: from idefix.nuance.com (pool-108-53-90-228.nwrknj.fios.verizon.net. [108.53.90.228]) by smtp.gmail.com with ESMTPSA id u63sm13059939ywf.4.2015.11.11.13.58.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Nov 2015 13:58:10 -0800 (PST) To: "Joe Hildebrand (jhildebr)" , "json@ietf.org" References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> From: "Peter F. Patel-Schneider" X-Enigmail-Draft-Status: N1110 Message-ID: <5643B9F1.5030901@gmail.com> Date: Wed, 11 Nov 2015 13:58:09 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 11 Nov 2015 21:58:15 -0000 Also apologies for the delayed response. On 10/30/2015 07:42 PM, Joe Hildebrand (jhildebr) wrote: > (Sorry I didn't get to this until now) > > On 10/18/15, 4:23 PM, "json on behalf of Carsten Bormann" wrote: [...] > > "This document intends to document the exact same data model as described in ECMA-404, which is the main document used by ECMAscript implementors. Implementors that want to interoperate with ECMAscript implementations (such as web browsers) are advised to also read ECMA-404 to understand any potential interoperability challenges. Any differences in the model described in this document with that described in ECMA-404 are not intentional, and will require the IETF and ECMA to work together to resolve the difference." [...] I don't think that ECMA-404 describes a data model at all, unless you mean unbounded-precision floating point numbers, collections of name/value pairs with possible repeating names, and strings as sequences of Unicode code points. I don't think that many JSON libraries implement this data model. peter From nobody Wed Nov 11 21:22:41 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF231AC43A for ; Wed, 11 Nov 2015 21:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, 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 JEaB5H8J5_sT for ; Wed, 11 Nov 2015 21:22:39 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D81FB1AC438 for ; Wed, 11 Nov 2015 21:22:38 -0800 (PST) Received: by wmww144 with SMTP id w144so72527946wmw.0 for ; Wed, 11 Nov 2015 21:22:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=cpgfuGTTQdwiTqjg9/ls2MrqwbIcnUm3aOS5bGDgdW0=; b=ITYC6fHO6scefeyEPDsV6r5IhshBch1WnE2wkqoZAhtxtUvNjOlLfoqps63f8kd3mR R4790I0CrS6qYvJP1ZpNK3MPz9uu/3FF4rE//8nTUyJHa/xG5lFJe10fRc5gOIBLG+jE DjPzx97ld/Y0Wk76Ae9nppxWU1hZZB59pZyAFlKCgra3EZqTilfnod1xzAD/BZYUCgvz AMjM2+OZCAwAVismYWTfgO9bCFx8IB091kj3sr+FKX8+dpGwOMI1q2eZLzNA0+rlhK2z QuNAKetVwH7ExXzHro5nPZeQosmJegiKSEccMuchfvCdSj1T6GtKMqlbvooIVrHYuB7M CnOg== X-Received: by 10.194.192.106 with SMTP id hf10mr13978267wjc.131.1447305757344; Wed, 11 Nov 2015 21:22:37 -0800 (PST) Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id t126sm12977227wmd.23.2015.11.11.21.22.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Nov 2015 21:22:36 -0800 (PST) To: "Joe Hildebrand (jhildebr)" , =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Carsten Bormann References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> <56342E23.6000509@tzi.org> <563B15AD.3070309@it.aoyama.ac.jp> <563B17FF.5050002@gmail.com> <56421902.8040001@gmail.com> <313EF0F9-0DC4-432B-9904-1E8B4C483EA9@cisco.com> From: Anders Rundgren Message-ID: <56442216.6080802@gmail.com> Date: Thu, 12 Nov 2015 06:22:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <313EF0F9-0DC4-432B-9904-1E8B4C483EA9@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 12 Nov 2015 05:22:40 -0000 On 2015-11-11 22:31, Joe Hildebrand (jhildebr) wrote: > On 11/10/15, 9:19 AM, "Anders Rundgren" wrote: >> >> My target application has since mid-2013 been a JSONesque counterpart > to XML's enveloped signatures but without getting bogged down by complex, > stand-alone canonicalizers. The latest developments seem to verify that > the most difficult part of JSON (Numbers), also are properly canonicalized > by the majority (but not all) ES6 implementations. This enables very simple > and efficient "in-object" JavaScript and JSON signatures which only rely on > standard JavaScript for creating and manipulating objects and the built-in > JSON parse/stringify methods for parsing and serialization respectively: >> >> https://mailarchive.ietf.org/arch/msg/jose/s5TdEtfOdQ0z3Qmtij2yXemZW-A > > Oh! You're relying on the parsing and serializing code to be parallel, > such that the parser maintains order, and the serializer repeats that order on output. > > Interesting. However, that would be a major change to the JSON spec (that would > necessitate changes to LOTS of existing code, at a performance or memory penalty). > It also took me a good amount of time to track down even in the ECMAscript > doc - so I don't think you can expect most folks reading ECMA-404 to figure this > out either. If you really want interoperability, there's nothing stopping you > from doing something like I-JSON that says an ordered-json is JSON, except for > some other constraints. The depicted signature runs without hiccups in Chrome, Firefox, Safari, and of course in the Java reference implementation which generated it. The current alternative is using JWS which encapsulates (=hides) data in Base64 which is perfectly OK for some applications but (IMO) slightly less appetizing for things like Web Payments. The genie is out of the bottle and now it is time to wish something :-) Anders From nobody Sat Nov 14 10:55:57 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728911ACEF6 for ; Sat, 14 Nov 2015 10:55:56 -0800 (PST) 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, HTML_MESSAGE=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 ut0XXZmgi1uT for ; Sat, 14 Nov 2015 10:55:54 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C161ACECB for ; Sat, 14 Nov 2015 10:55:53 -0800 (PST) Received: by ioir85 with SMTP id r85so85802796ioi.1 for ; Sat, 14 Nov 2015 10:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hvJS0FdNHFaYDRL++Q2sZi6hcJpjpRzq8S9pSOD1jpI=; b=Vs9RD7eMG99HqPoiiLDjvCVfINSY0/RB63WLdahL+1iJbvfBpWORNv8PzKoWE2MZEx URZTDOcJovKIfuqTBB//VabKau/+5MdgPcyxcUQ8HiVd6I+Ossd90E1Kz8fn/FPmgUB8 BS40QkZm8it8OaZXlDqhgxMHPFbTLv7T5kb/oPtaq6hyxY1OUIYLJrjPtzg2q2+ZC85n KDCmzjQm8Sf0oXvH0zx4R0rToTz2iPNkq5oIIjdNnofRKfWt8bMHyi0fPgFKl8mvJT/7 J0ACb5Ihid6Rt6slWdW15lB0tpu+lRUt4TXXbKHWb24qgemGKrVfVhvcWrrxEoZXkjzW 655g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hvJS0FdNHFaYDRL++Q2sZi6hcJpjpRzq8S9pSOD1jpI=; b=Hsnb5/OTjWWD4NOecjHNX5AIQ4zUsdxKyZqM2uqV553N5CMZvHZQoPFMNaT3pNxyFj ZIvseB2ZWNGDeoKOQUjd4MZUFsw/uFjltnnYxByA4E8TNLIRpfuq55XT4WbMBlPl781i uJnC/J8nQShsPS8IQpiQD+jVzrxoOjnALbSlSHGLscUR5CYfguFLLds/Kn5r5ZQ1L1xL hs2a7vV2DCb1DbDUjJaywS/HauPgtjJEFnHFoBz+A6YNz/c8Y0HqsQZqon38zO0IjzKx MNigmdgAs+E/rXUU/ars/AaI/EHmkal84hyPEsBbrEkxutZSyJm6eqbSJCZpUNLvq5aW 0mtg== X-Gm-Message-State: ALoCoQkPNeYagEYZWbfHJn97HLgh/eup83dik0RRZwUl6jLtDKVgmZ0qjKY2bwu+Hsi77Y0NV+mj X-Received: by 10.107.170.105 with SMTP id t102mr11163685ioe.65.1447527353205; Sat, 14 Nov 2015 10:55:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.78.214 with HTTP; Sat, 14 Nov 2015 10:55:33 -0800 (PST) X-Originating-IP: [24.84.248.61] In-Reply-To: <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> From: Tim Bray Date: Sat, 14 Nov 2015 10:55:33 -0800 Message-ID: To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a1142e806b0e051052484b93f Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Nov 2015 18:55:56 -0000 --001a1142e806b0e051052484b93f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 30, 2015 at 7:42 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > There's an argument to be made that if you want to interoperate with JSON > implementations in browsers, you should probably read ECMA-404. Several = of > the places where 7159 says "interoperable in > =E2=80=8B=E2=80=8B > the sense" have specific choices in ECMA-404. > =E2=80=8BI just re-read ECMA-404 (I recommend this, it doesn=E2=80=99t take= long) and I couldn't find examples of such specific choices, could you be more specific= ? =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > Conversely, serious implementors of ECMA-404 really ought to read 7159bis > in order to understand some of the edge cases of interoperability a littl= e > better. > =E2=80=8BAgreed.=E2=80=8B =E2=80=8B > The argument that we shouldn't bother with 7159 at all was discussed the > last time through. ECMA-404 only specifies what to do in an ECMAscript > environment, and someone needed to specify interoperability for other > environments, such as those that don't use UTF-16 code units or 64bit > floats as their implementation substrate. > =E2=80=8BActually ECMA-404 says exactly nothing about what any software sho= uld do.=E2=80=8B (Maybe I missed it?) Whether one should bother with ECMA-404 is out of our control, and overcome > by events. Both documents exist, and we need to ensure that they stay in > sync going forward. We could add a statement to section 1.2 such as: > =E2=80=8BI'm not sure about the premise. It's not obvious to me that any c= hanges are required in either 404 or 7159 for the foreseeable future. 404 explicitly says =E2=80=9CBecause it is so simple, it is not expected that t= he JSON grammar will ever change.=E2=80=9D=E2=80=8B "This document intends to document the exact same data model as described > in ECMA-404, which is the main document used by ECMAscript implementors. > Implementors that want to interoperate with ECMAscript implementations > (such as web browsers) are advised to also read ECMA-404 to understand an= y > potential interoperability challenges. Any differences in the model > described in this document with that described in ECMA-404 are not > intentional, and will require the IETF and ECMA to work together to resol= ve > the difference." > 1. =E2=80=8BFirst, ECMA-404 absolutely does not describe any data model. 2. I don't like this sort of nudge-nudge, wink-wink language. If we want to provide this language, don't tell them to go search 404 for =E2=80=9Cinteroperability challenges=E2=80=9D. Rather, a simple statement a= long these lines would be appropriate. =E2=80=9CThis document contains several recommendati= ons for best practices to avoid interoperability problems. ECMA-404 enforces none of these, thus implementations based on it might potentially emit JON texts which exhibit these problems.=E2=80=9C 3. Having re-read 404 closely, I am pretty sure that there are not in fact any differences in the set of data objects which qualify as =E2=80=9CJSON t= exts=E2=80=9D aside from 404's greater permissiveness already noted. So I'm dubious of the need for any future work. =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > That makes the normative reference understandable, and makes > =E2=80=8B=E2=80=8B > clear that the IETF and ECMA are partners in maintaining JSON going > forward. > =E2=80=8BNo, it still falls massively short of the very explicit and clear definition of the term =E2=80=9Cnormative reference=E2=80=9D. I=E2=80=99m sticking with my suggestion that if it is absolutely necessary = to insert a normative reference, we need language acknowledging that, while this reference does not meet the usual criteria for that sort of reference, we are inserting one anyhow because [X]. I think Joe was starting to suggest a value for [X], but I'm pretty sure we can do better. I'll write a note with some suggestions. =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8B > > -- > Joe Hildebrand > _______________________________________________ > 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) --001a1142e806b0e051052484b93f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Fri, Oct 30, 2015 at 7:42 PM, Joe Hildebrand (jhildebr) &= lt;jhildebr@cisco.c= om> wrote:
=E2=80=8B=E2=80=8B
=C2=A0
=E2=80=8B=E2=80=8B
There's an argument to be made that if you wa= nt to interoperate with JSON implementations in browsers, you should probab= ly read ECMA-404.=C2=A0 Several of the places where 7159 says "interop= erable in
=E2=80=8B=E2=80=8B
the sense" have specific choices in ECMA-= 404.

=E2=80=8BI just re-read ECMA-404 (I recommend this, it= doesn=E2=80=99t take long) and I couldn't find examples of such specif= ic choices, could you be more specific?
=E2=80=8B=E2=80=8B
=E2= =80=8B=E2=80=8B
Conversely, serious implementors of ECMA-404 really ou= ght to read 7159bis in order to understand some of the edge cases of intero= perability a little better.

=E2=80=8BAgreed.=E2=80=8B
=E2=80=8B
The argument that we shouldn't bother with 7159 at all was discussed th= e last time through.=C2=A0 ECMA-404 only specifies what to do in an ECMAscr= ipt environment, and someone needed to specify interoperability for other e= nvironments, such as those that don't use UTF-16 code units or 64bit fl= oats as their implementation substrate.

=E2=80=8BActually E= CMA-404 says exactly nothing about what any software should do.=E2=80=8B (M= aybe I missed it?)

Whether one should bother with ECMA-404 is out of our control, and overcome= by events.=C2=A0 Both documents exist, and we need to ensure that they sta= y in sync going forward.=C2=A0 We could add a statement to section 1.2 such= as:

=E2=80=8BI'm not sure about the premise.=C2=A0 It&= #39;s not obvious to me that any changes are required in either 404 or 7159= for the foreseeable future. =C2=A0404 explicitly says =E2=80=9CBecause it = is so simple, it is not expected that the JSON grammar will ever change.=E2= =80=9D=E2=80=8B

"This document intends to document the exact same data model as descri= bed in ECMA-404, which is the main document used by ECMAscript implementors= .=C2=A0 Implementors that want to interoperate with ECMAscript implementati= ons (such as web browsers) are advised to also read ECMA-404 to understand = any potential interoperability challenges. Any differences in the model des= cribed in this document with that described in ECMA-404 are not intentional= , and will require the IETF and ECMA to work together to resolve the differ= ence."

1. =E2=80=8BFirst, ECMA-404 absolutely does not= describe any data model. =C2=A0
2. I don't like this sort of nudge-nudge, wink-wink l= anguage. If we want to provide this language, don't tell them to go sea= rch 404 for =E2=80=9Cinteroperability challenges=E2=80=9D. Rather, a simple= statement along these lines would be appropriate. =C2=A0=E2=80=9CThis docu= ment contains several recommendations for best practices to avoid interoper= ability problems. =C2=A0 ECMA-404 enforces none of these, thus implementati= ons based on it might potentially emit JON texts which exhibit these proble= ms.=E2=80=9C
3.= Having re-read 404 closely, I am pretty sure that there are not in fact an= y differences in the set of data objects which qualify as =E2=80=9CJSON tex= ts=E2=80=9D aside from 404's greater permissiveness already noted. So I= 'm dubious of the need for any future work.
=E2=80=8B=E2=80=8B
= =E2=80=8B=E2=80=8B
That makes the normative reference understandable, = and makes
=E2=80=8B=E2=80=8B
clear that the IETF and ECMA are partners in m= aintaining JSON going forward.

=E2=80=8BNo, it still falls = massively short of the very explicit and clear definition of the term =E2= =80=9Cnormative reference=E2=80=9D. =C2=A0

I=E2=80=99m sticking with my suggestion that if it is abs= olutely necessary to insert a normative reference, we need language acknowl= edging that, while this reference does not meet the usual criteria for that= sort of reference, we are inserting one anyhow because [X]. =C2=A0 I think= Joe was starting to suggest a value for [X], but I'm pretty sure we ca= n do better.=C2=A0 I'll write a note with some suggestions.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=C2=A0

--
Joe Hildebrand
___________________________= ____________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json



--
=
- Tim Bray (If you=E2= =80=99d like to send me a private message, see https://keybase.io/timbray)
--001a1142e806b0e051052484b93f-- From nobody Sat Nov 14 11:11:11 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FA21AD0AB for ; Sat, 14 Nov 2015 11:11:10 -0800 (PST) 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, HTML_MESSAGE=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 dWeJcU7tirez for ; Sat, 14 Nov 2015 11:11:08 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E3F1AD0AA for ; Sat, 14 Nov 2015 11:11:08 -0800 (PST) Received: by igl9 with SMTP id 9so35470646igl.0 for ; Sat, 14 Nov 2015 11:11:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality_com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=481BV0xGCYAwWKULn0Eup92ddToGeedLG12+FWCRrYg=; b=T4p4KrpoMY3QUVojOyFPtuBCZDUhwqLPs7fyYWHb4ZIlSedFiiITvCNbwKFJmkx6Fb GpfjxTpBFmuJ5+U3bhDm2qvVtZGJZRVqgSJ4mdqX0kYnPgD0HFKGeogrI2hNRWIGRNUs HPjG8yn3LTaAPTIul/Nreg+wUh83w4eJnOa7G4j3FzrCWS5hXtngxTKd7JAmY9zhNfFz spoRIzsY4CQwOWxQaq5+k0/LDfoyCTPmwVEdQ8ULxEkunslDtllQ84+F2W2Nab3QARhb P2wEIePqw/KDH6Z2z+pgA08rmuxGedxkQFsWf7fgXn8gPoi+Eaw9gAPxh/qanQs1fyKI ZyVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=481BV0xGCYAwWKULn0Eup92ddToGeedLG12+FWCRrYg=; b=cHrv6p8xvrD4crazMxAuiAMI62x2tn5Az7HzhuXnS132lKgh9SI/iQ3Qvr+2LXuyXv 91w7JhDqbrvxIHZuhXT31YwVbdCq5NcG1RjA2aGkpbzP8FVSqv54lfrjDe7xwlBhpfBz sS+P2K6PeGfe8pdenuA4y9yL3GNvysnL76QCBcFwvCL8bPNLURmzzl80w2EXYl+ZpFY5 /IIbgPc8+QDcMTwAVwUp0bEvD2Dums4Sb2n14Tfw4iY+zjZsMDt/gicqsGAIoOszxB3w 2YNyFSkPqwcGvj3IhFQftJRBJTiAQneZlh1yvLfNxNSVpSkBTsn7kwCmAYKS+fBNwFOe U/5Q== X-Gm-Message-State: ALoCoQlcCCoJPoEi1lAku2bCjUbx75VHFtJOJMwll6w4E3QFTvRaiajtQgaggKtN+5WHS67PTDI2 X-Received: by 10.50.67.18 with SMTP id j18mr9516804igt.43.1447528266570; Sat, 14 Nov 2015 11:11:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.78.214 with HTTP; Sat, 14 Nov 2015 11:10:47 -0800 (PST) X-Originating-IP: [24.84.248.61] From: Tim Bray Date: Sat, 14 Nov 2015 11:10:47 -0800 Message-ID: To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc053221bcd8052484f0e5 Archived-At: Subject: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Nov 2015 19:11:10 -0000 --047d7bdc053221bcd8052484f0e5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Our charter says we are to consider inserting a normative reference to ECMA-404 into an RFC7159bis. There is a problem in that the definition of =E2=80=9Cnormative reference=E2=80=9D is clear (I won't read it off yet aga= in) and there's no way ECMA-404 qualifies. You could make a case that the reference is useful because 404 allows all the things 7159 warns against, but implementors would be better served by a simple assertion that =E2=80=9C404 allows all the things 7159 warns against= =E2=80=9D. In fact, I'm deeply unconvinced that consulting -404 is useful for anyone in any circumstance, because it doesn't change the definition of what a =E2=80=9CJSON text=E2=80=9D is from that found in 7159 and all its predeces= sors. So, is there a *real* reason why a normative reference might be useful? I think there might be, and it's purely rhetorical (in the formal sense, designed to support an argument): To make it clear to the world that all JSON is the same JSON no matter where it's specified. So I think it would be plausible to add the following to the second paragraph of section 1.2 of 7159 (for convenience: http://rfc7159.net/rfc7159#rfc.section.1.2 ): =E2=80=9CThe reference to ECMA-404 in the previous sentence is normative, n= ot with the usual meaning that implementors need to consult it in order to understand this document, but to emphasize that there are no inconsistencies in the definition of the term =E2=80=9CJSON text=E2=80=9D i= n any of its specifications. Note, however, that ECMA-404 allows several practices which this specification recommends avoiding in the interests of maximal interoperability.=E2=80=9D But I have a practical question. What exact effect to we expect this to have? Will ECMA-404 be updated in place with a reference to 7159bis (ECMA specs can be updated in place, because -404 already has been, to remove a silly typo). Will there be an ECMA-404bis, and if so, should we work carefully with ECMA to make sure that the two -bis specs mutually reference each other? --047d7bdc053221bcd8052484f0e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Our= charter says we are to consider inserting a normative reference to ECMA-40= 4 into an RFC7159bis.=C2=A0 There is a problem in that the definition of = =E2=80=9Cnormative reference=E2=80=9D is clear (I won't read it off yet= again) and there's no way ECMA-404 qualifies.

You could make a case that the reference is usefu= l because 404 allows all the things 7159 warns against, but implementors wo= uld be better served by a simple assertion that =E2=80=9C404 allows all the= things 7159 warns against=E2=80=9D.

In fact, I'm deeply unconvinced that consulting -404 is use= ful for anyone in any circumstance, because it doesn't change the defin= ition of what a =E2=80=9CJSON text=E2=80=9D is from that found in 7159 and = all its predecessors.

So,= is there a *real* reason why a normative reference might be useful? I thin= k there might be, and it's purely rhetorical (in the formal sense, desi= gned to support an argument): To make it clear to the world that all JSON i= s the same JSON no matter where it's specified.=C2=A0 So I think it wou= ld be plausible to add the following to the second paragraph of section 1.2= of 7159 (for convenience: http://rfc7159.net/rfc7159#rfc.section.1.2 ):

=E2=80=9CThe reference to ECMA-404 in the p= revious sentence is normative, not with the usual meaning that implementors= need to consult it in order to understand this document, but to emphasize = that there are no inconsistencies in the definition of the term =E2=80=9CJS= ON text=E2=80=9D in any of its specifications. Note, however, that ECMA-404= allows several practices which this specification recommends avoiding in t= he interests of maximal interoperability.=E2=80=9D

But I have a practical question. What exact effec= t to we expect this to have?=C2=A0 Will ECMA-404 be updated in place with a= reference to 7159bis (ECMA specs can be updated in place, because -404 alr= eady has been, to remove a silly typo).=C2=A0 Will there be an ECMA-404bis,= and if so, should we work carefully with ECMA to make sure that the two -b= is specs mutually reference each other?
--047d7bdc053221bcd8052484f0e5-- From nobody Sat Nov 14 11:35:41 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139F01B29BF for ; Sat, 14 Nov 2015 11:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9breohizeC3C for ; Sat, 14 Nov 2015 11:35:36 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D9D1A9132 for ; Sat, 14 Nov 2015 11:35:36 -0800 (PST) Received: by ykdr82 with SMTP id r82so190661946ykd.3 for ; Sat, 14 Nov 2015 11:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=rpPFyuu8s4mviHyKd366g3HfA9G16ooNKfrUrNnwC38=; b=J6MBnGs9mzJ6NV3SnCJEqcAZjP2GzyvQzZiKztZ13m9KTicFhCuZDqOBQLpmZMpq7/ jUuvUjekFllb6exyMbL3qUYKMZUsckxOohSwc2fQHjZV7MpQBOOKK0npEEfPne6RBdPm d1hbvVRt8+ZQCtnyKRzOPSHX6QS90QTNQhwfGqbUnMiHj1Hjpni806ZcIq+eAUirsn1e 9EL4oXJg2/vZTZEf2bS6zx7o8DukqlAwQpa+kSVqUMfTv5GQQvOGzgb2YuIolR1ki0Nc R/sKA1+yEuVMlcueKdOCBw7UQTIheApZl+Ku0xoBr3koKxWKD/uQ/pui1O6QFTkw1VN7 lrzQ== X-Received: by 10.129.31.70 with SMTP id f67mr28482404ywf.114.1447529735634; Sat, 14 Nov 2015 11:35:35 -0800 (PST) Received: from idefix.nuance.com (pool-108-53-90-228.nwrknj.fios.verizon.net. [108.53.90.228]) by smtp.gmail.com with ESMTPSA id z130sm20639023ywb.18.2015.11.14.11.35.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Nov 2015 11:35:34 -0800 (PST) To: Tim Bray , "json@ietf.org" References: From: "Peter F. Patel-Schneider" X-Enigmail-Draft-Status: N1110 Message-ID: <56478D05.7080104@gmail.com> Date: Sat, 14 Nov 2015 11:35:33 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Nov 2015 19:35:38 -0000 On 11/14/2015 11:10 AM, Tim Bray wrote: [...] > So, is there a *real* reason why a normative reference might be useful? I > think there might be, and it's purely rhetorical (in the formal sense, > designed to support an argument): To make it clear to the world that all JSON > is the same JSON no matter where it's specified. So I think it would be > plausible to add the following to the second paragraph of section 1.2 of 7159 > (for convenience: http://rfc7159.net/rfc7159#rfc.section.1.2 ): > > “The reference to ECMA-404 in the previous sentence is normative, not with the > usual meaning that implementors need to consult it in order to understand this > document, but to emphasize that there are no inconsistencies in the definition > of the term “JSON text” in any of its specifications. Note, however, that > ECMA-404 allows several practices which this specification recommends avoiding > in the interests of maximal interoperability.” I don't see any utility in making the reference normative, particularly if wording along the lines of "There are no differences in the definition of the term ``JSON text'' between this specification and ECMA-404 [informative reference]. There is no intent to allow the two specifications to diverge in the future on what is allowable for JSON text." is in 7159bis. This wording seems to be adequate support for what I think everyone hopes is the case. peter PS: Is there any formal definition for the railroad tracks in ECMA-404? From nobody Tue Nov 17 01:06:55 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9433F1B2D01 for ; Tue, 17 Nov 2015 01:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.187 X-Spam-Level: X-Spam-Status: No, score=-13.187 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aculV2zkubjN for ; Tue, 17 Nov 2015 01:06:52 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0311B2D09 for ; Tue, 17 Nov 2015 01:06:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3794; q=dns/txt; s=iport; t=1447751212; x=1448960812; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ln1PvzY7FgghC4PeU04s7zRcORSuS2m21p3UmJG2Mak=; b=NXO85MKpJ7kTr3cneEDAkuzZvPSffacHgrH63w31BR9qjlLtyiSHfXwX Af8x8V6JFCYq642ySYghxyCxGRcRWneybGdGBi6uMCXzJPXgbLd4VgWbq 7/LdjWIYqjeM95kcBnBqHMNP43tOChe0uSwSxp9gLBCKv/OVJmT2YWkAP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsDQDM7UpW/5tdJa1dgzt/AUIGwEqCX?= =?us-ascii?q?4MxAhyBLjsRAQEBAQEBAYEKhDUBAQQjEUUQAgEGAg4MAiYCAgIwFRACBA4FiC6?= =?us-ascii?q?NUJ01kEQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYgQGFU4IQgWiBBoRZgxwvgRUBB?= =?us-ascii?q?JZJAY0pgVuHZZMEATcshARyhAOBBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,307,1444694400"; d="scan'208";a="208998039" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2015 09:06:33 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tAH96XJd003118 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Nov 2015 09:06:33 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 Nov 2015 04:06:32 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.000; Tue, 17 Nov 2015 04:06:32 -0500 From: "Joe Hildebrand (jhildebr)" To: Tim Bray Thread-Topic: [Json] Kicking Off JSONbis Thread-Index: AQHRHw4KwbG58cqRTk2NlHPfs03MdJ6gVPiA Date: Tue, 17 Nov 2015 09:06:32 +0000 Message-ID: <73F1E21E-3E3D-4EFB-A1B2-AF713EA30461@cisco.com> References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.162.65] Content-Type: text/plain; charset="utf-8" Content-ID: <109C6B593085FC4FA9489161B9D56858@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 09:06:54 -0000 DQpPbiAxMS8xNC8xNSwgNzo1NSBQTSwgIlRpbSBCcmF5IiA8dGJyYXlAdGV4dHVhbGl0eS5jb20+ IHdyb3RlOg0KDQo+4oCLSSBqdXN0IHJlLXJlYWQgRUNNQS00MDQgKEkgcmVjb21tZW5kIHRoaXMs IGl0IGRvZXNu4oCZdCB0YWtlIGxvbmcpIGFuZCBJIGNvdWxkbid0IGZpbmQgZXhhbXBsZXMgb2Yg c3VjaCBzcGVjaWZpYyBjaG9pY2VzLCBjb3VsZCB5b3UgYmUgbW9yZSBzcGVjaWZpYz8NCg0KVGhl eSdyZSBub3QgYXMgbXVjaCBpbiA0MDQgYXMgdGhleSBhcmUgaW4gMjYyLCB3aGljaCBpcyByZWZl cmVuY2VkIGZyb20gNDA0LiAgRm9yIGV4YW1wbGUsIHRoZSBkb3VibGUgaW1wbGVtZW50YXRpb24g Zm9yIGFsbCBudW1iZXJzLCBsZWFkaW5nIHRvIHRoZSAyXjUzLTEgaXNzdWUuICBBbHNvLCBzb21l IG9mIHRoZSBVbmljb2RlIGlzc3VlcyBjcmVlcCBpbiB0aHJvdWdoIHRoZSBzYW1lIGRvb3IuDQoN Cj7igItBY3R1YWxseSBFQ01BLTQwNCBzYXlzIGV4YWN0bHkgbm90aGluZyBhYm91dCB3aGF0IGFu eSBzb2Z0d2FyZSBzaG91bGQgZG8u4oCLIChNYXliZSBJIG1pc3NlZCBpdD8pDQoNCkkgdGhpbmsg aXQncyBpbXBsaWNpdCBpbiA0MDQncyB0aWVzIHRvIDI2Mi4NCg0KPuKAi0knbSBub3Qgc3VyZSBh Ym91dCB0aGUgcHJlbWlzZS4gIEl0J3Mgbm90IG9idmlvdXMgdG8gbWUgdGhhdCBhbnkgY2hhbmdl cyBhcmUgcmVxdWlyZWQgaW4gZWl0aGVyIDQwNCBvciA3MTU5IGZvciB0aGUgZm9yZXNlZWFibGUg ZnV0dXJlLiAgNDA0IGV4cGxpY2l0bHkgc2F5cyDigJxCZWNhdXNlIGl0IGlzIHNvIHNpbXBsZSwg aXQgaXMgbm90IGV4cGVjdGVkIHRoYXQNCj4gdGhlIEpTT04gZ3JhbW1hciB3aWxsIGV2ZXIgY2hh bmdlLuKAneKAiw0KDQpOb2QuICBUaGlzIGlzIGEgc3RhdGVtZW50IG9mIHBvbGl0aWNhbCBkw6l0 ZW50ZSwgdGhhdCB3ZSBob3BlIGlzIG5ldmVyIGFjdHVhbGx5IHVzZWQgaW4gcHJhY3RpY2UuDQoN Cj4xLiDigItGaXJzdCwgRUNNQS00MDQgYWJzb2x1dGVseSBkb2VzIG5vdCBkZXNjcmliZSBhbnkg ZGF0YSBtb2RlbC4gIA0KDQpQaWNrIGFueSBvdGhlciB3b3JkcyB0aGFuICJkYXRhIG1vZGVsIi4g IFN5bnRheD8NCg0KPjIuIEkgZG9uJ3QgbGlrZSB0aGlzIHNvcnQgb2YgbnVkZ2UtbnVkZ2UsIHdp bmstd2luayBsYW5ndWFnZS4gSWYgd2Ugd2FudCB0byBwcm92aWRlIHRoaXMgbGFuZ3VhZ2UsIGRv bid0IHRlbGwgdGhlbSB0byBnbyBzZWFyY2ggNDA0IGZvciDigJxpbnRlcm9wZXJhYmlsaXR5IGNo YWxsZW5nZXPigJ0uIFJhdGhlciwgYSBzaW1wbGUgc3RhdGVtZW50IGFsb25nIHRoZXNlDQo+IGxp bmVzIHdvdWxkIGJlIGFwcHJvcHJpYXRlLiAg4oCcVGhpcyBkb2N1bWVudCBjb250YWlucyBzZXZl cmFsIHJlY29tbWVuZGF0aW9ucyBmb3IgYmVzdCBwcmFjdGljZXMgdG8gYXZvaWQgaW50ZXJvcGVy YWJpbGl0eSBwcm9ibGVtcy4gICBFQ01BLTQwNCBlbmZvcmNlcyBub25lIG9mIHRoZXNlLCB0aHVz IGltcGxlbWVudGF0aW9ucyBiYXNlZCBvbiBpdCBtaWdodCBwb3RlbnRpYWxseSBlbWl0IEpPTiB0 ZXh0cyB3aGljaCBleGhpYml0IHRoZXNlIHByb2JsZW1zLuKAnA0KDQpQZXJoYXBzIHdlIG5lZWQg dG8gcmVmZXJlbmNlIDI2MiBleHBsaWNpdGx5IGFzIHdlbGwsIHRoZW4uDQoNCj4zLiBIYXZpbmcg cmUtcmVhZCA0MDQgY2xvc2VseSwgSSBhbSBwcmV0dHkgc3VyZSB0aGF0IHRoZXJlIGFyZSBub3Qg aW4gZmFjdCBhbnkgZGlmZmVyZW5jZXMgaW4gdGhlIHNldCBvZiBkYXRhIG9iamVjdHMgd2hpY2gg cXVhbGlmeSBhcyDigJxKU09OIHRleHRz4oCdIGFzaWRlIGZyb20gNDA0J3MgZ3JlYXRlciBwZXJt aXNzaXZlbmVzcyBhbHJlYWR5IG5vdGVkLiBTbw0KPiBJJ20gZHViaW91cyBvZiB0aGUgbmVlZCBm b3IgYW55IGZ1dHVyZSB3b3JrLg0KDQpJIGhvcGUgd2UgbmV2ZXIgbmVlZCB0byBkbyBhbnkgZnV0 dXJlIHdvcmsuDQoNCj7igItObywgaXQgc3RpbGwgZmFsbHMgbWFzc2l2ZWx5IHNob3J0IG9mIHRo ZSB2ZXJ5IGV4cGxpY2l0IGFuZCBjbGVhciBkZWZpbml0aW9uIG9mIHRoZSB0ZXJtIOKAnG5vcm1h dGl2ZSByZWZlcmVuY2XigJ0uICANCj4NCj4NCj5J4oCZbSBzdGlja2luZyB3aXRoIG15IHN1Z2dl c3Rpb24gdGhhdCBpZiBpdCBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeSB0byBpbnNlcnQgYSBub3Jt YXRpdmUgcmVmZXJlbmNlLCB3ZSBuZWVkIGxhbmd1YWdlIGFja25vd2xlZGdpbmcgdGhhdCwgd2hp bGUgdGhpcyByZWZlcmVuY2UgZG9lcyBub3QgbWVldCB0aGUgdXN1YWwgY3JpdGVyaWEgZm9yIHRo YXQgc29ydCBvZg0KPiByZWZlcmVuY2UsIHdlIGFyZSBpbnNlcnRpbmcgb25lIGFueWhvdyBiZWNh dXNlIFtYXS4gICBJIHRoaW5rIEpvZSB3YXMgc3RhcnRpbmcgdG8gc3VnZ2VzdCBhIHZhbHVlIGZv ciBbWF0sIGJ1dCBJJ20gcHJldHR5IHN1cmUgd2UgY2FuIGRvIGJldHRlci4gIEknbGwgd3JpdGUg YSBub3RlIHdpdGggc29tZSBzdWdnZXN0aW9ucy4NCg0KSSdtIGNvbXBsZXRlbHkgb2sgd2l0aCBs YW5ndWFnZSB0byB0aGlzIGVmZmVjdC4gIEFuZCB5ZXMsIHRoZSB0ZXh0IEkgcHJvdmlkZWQgd2Fz IG1lYW50IGVudGlyZWx5IGFzIGEgc3RhcnRpbmcgcG9pbnQsIHRvIGJlIHBpY2tlZCBhcGFydCBh bmQgcmVwbGFjZWQgd2l0aCBzb21ldGhpbmcgZ29vZC4gIFNvbWV0aW1lcyBhIHN0cmF3bWFuIGlz IG5pY2UgdG8gaGF2ZSBzbyB0aGF0ICpzb21ldGhpbmcqIGNhbiBiZSBzZXQgb24gZmlyZS4NCg0K LS0gDQpKb2UgSGlsZGVicmFuZA0KDQoNCg0KDQoNCg0KDQo= From nobody Tue Nov 17 01:10:50 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B361B2D24 for ; Tue, 17 Nov 2015 01:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.086 X-Spam-Level: X-Spam-Status: No, score=-15.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4AEa808DnGE for ; Tue, 17 Nov 2015 01:10:47 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52BFC1B2D22 for ; Tue, 17 Nov 2015 01:10:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1212; q=dns/txt; s=iport; t=1447751447; x=1448961047; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bNsl7GI+zT7s5Jy0fxmunow7kZ0ovYegCjFbRXNzVZQ=; b=mmkeYux3L1x2cBAbVbEdVRtZKhroht4mxe3bf35cNA5//UUT9UXF6T+e BuJH/6h6DTYEQu4hYTqOboSUpqR6sayXgbjYN9XRsrcIXThJNWO0DH7/4 UE6WvANjeiqrWbBGQO5NVqME8f3xG8xRyHzTGDkta8NDKbBZ5GZuk3v3+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAgCF7kpW/4UNJK1dgzuBQga+VwENg?= =?us-ascii?q?WWGEAIcgS44FAEBAQEBAQGBCoQ1AQEEIxFVAgEIDgwCJgICAjAVEAIEARKILqs?= =?us-ascii?q?HkEQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYgQGFU4IQgm6EWYMcL4EVAQSWSQGNK?= =?us-ascii?q?YFblniDcQEfAQFChARyhAOBBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,307,1444694400"; d="scan'208";a="47548480" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Nov 2015 09:10:46 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id tAH9Akfo009178 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Nov 2015 09:10:46 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 Nov 2015 04:10:45 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.000; Tue, 17 Nov 2015 04:10:45 -0500 From: "Joe Hildebrand (jhildebr)" To: Tim Bray , "json@ietf.org" Thread-Topic: [Json] Normative reference reasoning and logistics Thread-Index: AQHRHxA7TAPtcsxNR0yDl0V93+X9ZZ6gViIA Date: Tue, 17 Nov 2015 09:10:45 +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/0.0.0.151105 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.162.65] Content-Type: text/plain; charset="utf-8" Content-ID: <8B3D004F2B924B4D9001147AAAA71765@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 09:10:48 -0000 T24gMTEvMTQvMTUsIDg6MTAgUE0sICJqc29uIG9uIGJlaGFsZiBvZiBUaW0gQnJheSIgPGpzb24t Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgdGJyYXlAdGV4dHVhbGl0eS5jb20+IHdyb3Rl Og0KDQoNCg0KPkJ1dCBJIGhhdmUgYSBwcmFjdGljYWwgcXVlc3Rpb24uIFdoYXQgZXhhY3QgZWZm ZWN0IHRvIHdlIGV4cGVjdCB0aGlzIHRvIGhhdmU/ICBXaWxsIEVDTUEtNDA0IGJlIHVwZGF0ZWQg aW4gcGxhY2Ugd2l0aCBhIHJlZmVyZW5jZSB0byA3MTU5YmlzIChFQ01BIHNwZWNzIGNhbiBiZSB1 cGRhdGVkIGluIHBsYWNlLCBiZWNhdXNlIC00MDQgYWxyZWFkeSBoYXMgYmVlbiwNCj4gdG8gcmVt b3ZlIGEgc2lsbHkgdHlwbykuICBXaWxsIHRoZXJlIGJlIGFuIEVDTUEtNDA0YmlzLCBhbmQgaWYg c28sIHNob3VsZCB3ZSB3b3JrIGNhcmVmdWxseSB3aXRoIEVDTUEgdG8gbWFrZSBzdXJlIHRoYXQg dGhlIHR3byAtYmlzIHNwZWNzIG11dHVhbGx5IHJlZmVyZW5jZSBlYWNoIG90aGVyPw0KDQpNeSB1 bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhpcyBpcyB0aGUgaW50ZW50LiAgQSBub3JtYXRpdmUgcmVm ZXJlbmNlIG1ha2VzIHJvdWdobHkgdGhlIHNhbWUgYW1vdW50IG9mIHNlbnNlIGluIHRoZSBvdGhl ciBkaXJlY3Rpb24gKGkuZS4gUGVyaGFwcyBub25lLCBkZXBlbmRpbmcgb24geW91ciBwb2ludCBv ZiB2aWV3KSwgYnV0IHRoYXQgd2UgaGF2ZSBwcmUtZGlzY3Vzc2VkIHdpdGggdGhlIC00MDQgdGVh bSB0aGlzIHBvdGVudGlhbCBhcHByb2FjaCBmb3IgbW92aW5nIGZvcndhcmQuDQoNCk91ciBFQ01B IGxpYWlzb24gbWlnaHQgd2FudCB0byBzcGVhayBtb3JlIGZvcm1hbGx5IHRvIHRoaXMgcG9pbnQu DQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQo= From nobody Tue Nov 17 01:16:46 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6851B2D48 for ; Tue, 17 Nov 2015 01:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 UsFdYx8F76VO for ; Tue, 17 Nov 2015 01:16:43 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 EE0541B2D46 for ; Tue, 17 Nov 2015 01:16:42 -0800 (PST) Received: from [192.168.178.20] ([84.187.38.196]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MOOdZ-1a4NfM1XEr-005o83; Tue, 17 Nov 2015 10:16:37 +0100 To: "Joe Hildebrand (jhildebr)" , Tim Bray References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> <73F1E21E-3E3D-4EFB-A1B2-AF713EA30461@cisco.com> From: Julian Reschke Message-ID: <564AF072.6010901@gmx.de> Date: Tue, 17 Nov 2015 10:16:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <73F1E21E-3E3D-4EFB-A1B2-AF713EA30461@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:hWO57OPkrMZPP6ABfNAgshm308hQg4nWSlgDAonpu5pEe48KK6x DbnKA3d+6/j00ieJPBLOP9lzw49fNhiLA8D4L9S/0kzhMsQ9xkZnRUAdZ+sPkWg7siSugS5 W9wBf2HUQDokUfXg0EcQviSi21Vqh0leMQxivYQrm1mQf0PYaKkRkCxY5skkOsJCdeLfKJN pe8TBDxqFXyF7B2Wy0CaQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:wFFlnw2DCkc=:HttNND/Z4qkY6qCBfMU+q6 X6A3SlPXTHMw8SVshbLXb5Z1UeajuKSyQWgTDbxKpCfpQvRIBjq1bvkF7oZrhQ4od/6lBqWxx ZAIVlLVxvPUfxfOXGC23aSz/0NTVY79OJgTqQ8wUIQ8cDULg0UqYkmBc05Z0k/o2rOKfcGvuy VhhkNwcg7ZYz60wRksj+TFKzG/fjUUPbSZwfSx27/PorlcotPxupS38rzyqZ2pr7KWWmxeigK dC/siumo9Lz6YuvOWSRLfb3SFWMb6quGX8ZWJMB788L3WAf8lctH+GvB24NT4zouj+iY5Z9OR wOyCkmklOEIYtsN/EXH5AiqHBTbsz4GISmx2jZaHvcjnmGRzVeVQwCRGpMBrz/dpG5CySDNBg dtd/2Euvnsj+u3nDP76Fr9QqwkR/b36Jd1i0mBzgI+V1juNbLYqcOLPhUCM5jLBNaLzi30SgZ rauu/cAc8oLu1l9VJaOtZHPczssCT2ysMnH3tnl/KoXfYdl3Tc70Olvc4wVio03U7wbNmlN6z kLJUjWY1yBoJqPT5GoTjc+XxK6XFQte5nZrPvyspIQDJM0hPJenjBgVwC5fr9bqDCSggYt5xN rKaPhUMuu9qeyVVe3OUitinuzf5Sy8rqoN/Y6yscaj/VdXXt+/8hxv8KdGZ7g/blQHPwkp92I /eOpyEGxO3h1AL8PLhFBBf3bhAwJmwbRk62nYEgUDk5LsgnEAk623XYDM2ODJIfFsQKvIQdgm aEua5aMY+QWWrtGV8SmA3k0JAxRQ0Nq/zi3aBitUoIhIFjML4mzSuWLgbIu6y5D0sIzePDWV8 FqPmFro Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 09:16:44 -0000 On 2015-11-17 10:06, Joe Hildebrand (jhildebr) wrote: > ... >> 2. I don't like this sort of nudge-nudge, wink-wink language. If we want to provide this language, don't tell them to go search 404 for “interoperability challenges”. Rather, a simple statement along these >> lines would be appropriate. “This document contains several recommendations for best practices to avoid interoperability problems. ECMA-404 enforces none of these, thus implementations based on it might potentially emit JON texts which exhibit these problems.“ > > Perhaps we need to reference 262 explicitly as well, then. > ... So one needs ECMA 262 (Javascript) to implement JSON? Best regards, Julian From nobody Tue Nov 17 07:17:24 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD891A9077 for ; Tue, 17 Nov 2015 07:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.086 X-Spam-Level: X-Spam-Status: No, score=-15.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kseJNIZ0MVB for ; Tue, 17 Nov 2015 07:17:13 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1071A90B2 for ; Tue, 17 Nov 2015 07:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2279; q=dns/txt; s=iport; t=1447773385; x=1448982985; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uNF2fe1+NWGpMHgF6KCyhELREVmUz/YE72R69VGl4DM=; b=aNK2cEQgPKpqGaQeCxklvkA1vEm8/XUOKmG9V1nJTsXpLvJFljo1ZBt8 yJlywTyMBF0R9Xaf5MnMm3GMz9i9033/d0UPzMhDa1W6+CK0UFmhGUhi4 CNDnbsXLc5MGvDUZO65wauNNpf8HMGtTBWvcQXKpxvGSfzPFynYwG2sRI s=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C9AgAfREtW/4sNJK1egzuBMw8GvlsOg?= =?us-ascii?q?WWGEAKBTjgUAQEBAQEBAYEKhDQBAQEDAXkFCwIBCBguMiUCBA4FDogYCLwbAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBDwmIZIJuiCSBFQEElkkBglaBYIh0gVuSFoRig?= =?us-ascii?q?3EBHwFDhARyhAOBBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,308,1444694400"; d="asc'?scan'208";a="208476128" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Nov 2015 15:16:24 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id tAHFGLwb000831 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Nov 2015 15:16:21 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 Nov 2015 09:16:21 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.000; Tue, 17 Nov 2015 09:16:21 -0600 From: "Matt Miller (mamille2)" To: "Joe Hildebrand (jhildebr)" Thread-Topic: [Json] Normative reference reasoning and logistics Thread-Index: AQHRHxA7S5ZBW+xd50G1ZxMAh7DhgJ6gViOAgABmJAA= Date: Tue, 17 Nov 2015 15:16:20 +0000 Message-ID: <1403E8DC-B5DA-48E0-8F3E-263342DFE1AE@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.6b2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.129.24.52] Content-Type: multipart/signed; boundary="Apple-Mail=_4F4C3BCD-F588-47CC-8692-EEEA00268ACF"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 15:17:23 -0000 --Apple-Mail=_4F4C3BCD-F588-47CC-8692-EEEA00268ACF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 17, 2015, at 02:10, Joe Hildebrand (jhildebr) = wrote: >=20 > On 11/14/15, 8:10 PM, "json on behalf of Tim Bray" = wrote: >=20 >=20 >=20 >> But I have a practical question. What exact effect to we expect this = to have? Will ECMA-404 be updated in place with a reference to 7159bis = (ECMA specs can be updated in place, because -404 already has been, >> to remove a silly typo). Will there be an ECMA-404bis, and if so, = should we work carefully with ECMA to make sure that the two -bis specs = mutually reference each other? >=20 > My understanding is that this is the intent. A normative reference = makes roughly the same amount of sense in the other direction (i.e. = Perhaps none, depending on your point of view), but that we have = pre-discussed with the -404 team this potential approach for moving = forward. >=20 > Our ECMA liaison might want to speak more formally to this point. >=20 This is what's been discussed with Ecma TC39. They will update 404 to = include a reference to 7159bis when it completes. As everyone surmises, = no further changes are expected in either documents. -- - m&m Matt Miller Cisco Systems, Inc. --Apple-Mail=_4F4C3BCD-F588-47CC-8692-EEEA00268ACF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWS0TFAAoJEDWi+S0W7cO1PMwIAKuN88IGP4waXlKojAuKpwOb rjKiJbjj9kf9KSQqj32xyGn0OyTGuijizPVcwg8izLSDKXSy0yna64gCAVFBNx6R aKSYsoygMZTtTlj6IDRLbXYvB/jKn1fDZpfIvHVDtocVL0tZYPFBfTa1UPKe1uYq 2Ec9epqWhbmZLpUMTQHk3Aoyv+l1i4rGmgXnVeJcQQdCJxSZd4nsQVAKa9wAEQFc 3i/hH64JYMnREVPjpTJ6pTtqR9U2L5qz1hWVwXpK7/86zFDy0qgJP6fJFeWGviFd /a/Q9FhYZtcBioDb3EsxvU06sIgBOP/UqjzNgW633kcziqOL6cSsYTTYHzKpUY8= =ZHRY -----END PGP SIGNATURE----- --Apple-Mail=_4F4C3BCD-F588-47CC-8692-EEEA00268ACF-- From nobody Tue Nov 17 08:31:15 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D0B1ACDBB for ; Tue, 17 Nov 2015 07:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7llTbtbABz9Q for ; Tue, 17 Nov 2015 07:45:26 -0800 (PST) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 8BA801ACDB6 for ; Tue, 17 Nov 2015 07:45:26 -0800 (PST) Received: from [10.47.60.90] (50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id tAHFjMPR029561 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Nov 2015 08:45:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110] claimed to be [10.47.60.90] From: "Paul Hoffman" To: "json@ietf.org" Date: Tue, 17 Nov 2015 07:45:22 -0800 Message-ID: In-Reply-To: <564AF072.6010901@gmx.de> References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> <73F1E21E-3E3D-4EFB-A1B2-AF713EA30461@cisco.com> <564AF072.6010901@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5141) Archived-At: X-Mailman-Approved-At: Tue, 17 Nov 2015 08:31:13 -0800 Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 15:45:27 -0000 On 17 Nov 2015, at 1:16, Julian Reschke wrote: > On 2015-11-17 10:06, Joe Hildebrand (jhildebr) wrote: >> ... >>> 2. I don't like this sort of nudge-nudge, wink-wink language. If we >>> want to provide this language, don't tell them to go search 404 for >>> “interoperability challenges”. Rather, a simple statement along >>> these >>> lines would be appropriate. “This document contains several >>> recommendations for best practices to avoid interoperability >>> problems. ECMA-404 enforces none of these, thus implementations >>> based on it might potentially emit JON texts which exhibit these >>> problems.“ >> >> Perhaps we need to reference 262 explicitly as well, then. >> ... > > > So one needs ECMA 262 (Javascript) to implement JSON? In the ECMA world, yes. I would hope that we would not require that for JSONbis other than by informational reference. --Paul Hoffman From nobody Tue Nov 17 09:15:29 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693FB1A1BB1 for ; Tue, 17 Nov 2015 09:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_BNd49xtpFA for ; Tue, 17 Nov 2015 09:15:27 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACD91A1BAE for ; Tue, 17 Nov 2015 09:15:26 -0800 (PST) Received: by qkfo3 with SMTP id o3so5016341qkf.1 for ; Tue, 17 Nov 2015 09:15:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=yipGbC7MwO2r4rsHxvPYd/uJcDvI2zk7LFFtQoN1Ca4=; b=pa5dlbl8nCzhfKtjqLahTQXwjBe4ENx7b136J0XPMFoG5Fb0DlFIy5eIgjzQSQpqbM 6a7hrZg4V1k9RYCndtXbMYP9UvGYYr+I8Gcr40Pbj0QM29RPVbma6iwki54/RjDs3emX C0uurHAffBhv/kkSVGFCoX7RI43Ka6lAj6IPwz5ebtxHVgsRlUs3vQdJNNjkmL4WqeUW 3mpQPqWlF+4FUGQ/jXyCA0MVcrf3rr8b9EQNm27H0NOQZMyt9aKGs2dY3K2g6HXDNPSy L5yPSEY6eA3kfiJNV69ZYppVKcfkR7OgVDsT8eGJNTwZ9SD0hsGjw3Ys/zxXJjm2LDvG uTGg== X-Received: by 10.55.75.84 with SMTP id y81mr41018214qka.96.1447780526094; Tue, 17 Nov 2015 09:15:26 -0800 (PST) Received: from idefix.nuance.com ([199.4.160.88]) by smtp.gmail.com with ESMTPSA id 63sm10433685qgl.31.2015.11.17.09.15.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Nov 2015 09:15:24 -0800 (PST) To: "Joe Hildebrand (jhildebr)" , Tim Bray References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> <73F1E21E-3E3D-4EFB-A1B2-AF713EA30461@cisco.com> From: "Peter F. Patel-Schneider" X-Enigmail-Draft-Status: N1110 Message-ID: <564B60AA.4080000@gmail.com> Date: Tue, 17 Nov 2015 09:15:22 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <73F1E21E-3E3D-4EFB-A1B2-AF713EA30461@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 17:15:28 -0000 On 11/17/2015 01:06 AM, Joe Hildebrand (jhildebr) wrote: > > On 11/14/15, 7:55 PM, "Tim Bray" wrote: > >> ​I just re-read ECMA-404 (I recommend this, it doesn’t take long) and I >> couldn't find examples of such specific choices, could you be more >> specific? > > They're not as much in 404 as they are in 262, which is referenced from > 404. For example, the double implementation for all numbers, leading to > the 2^53-1 issue. Also, some of the Unicode issues creep in through the > same door. > >> ​Actually ECMA-404 says exactly nothing about what any software should >> do.​ (Maybe I missed it?) > > I think it's implicit in 404's ties to 262. The ties between ECMA-404 and ECMA-262 are very weak. There is even explicit wording in ECMA-404 that JSON "does not attempt to impose ECMAScript’s internal data representations on other programming languages." [...] >> 2. I don't like this sort of nudge-nudge, wink-wink language. If we want >> to provide this language, don't tell them to go search 404 for >> “interoperability challenges”. Rather, a simple statement along these >> lines would be appropriate. “This document contains several >> recommendations for best practices to avoid interoperability problems. >> ECMA-404 enforces none of these, thus implementations based on it might >> potentially emit JON texts which exhibit these problems.“ > > Perhaps we need to reference 262 explicitly as well, then. Why? If so, then why not reference other definitions of how JSON is interpreted, for example how JSON is interpreted in Fortran? I thought that the whole idea of JSON was to not impose EcmaScript data structures or data models or serializations or parsing on producers or consumers of JSON text. [...] peter