From paul.hoffman@vpnc.org Tue Sep 3 14:10:32 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6204F21F9EF4 for ; Tue, 3 Sep 2013 14:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.633 X-Spam-Level: X-Spam-Status: No, score=-102.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgAuBvaWIdnk for ; Tue, 3 Sep 2013 14:10:32 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0901F21F9E5B for ; Tue, 3 Sep 2013 14:10:30 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r83LAT2a091011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 3 Sep 2013 14:10:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 3 Sep 2013 14:10:28 -0700 To: "json@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] Proposal for texts and string for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 21:10:32 -0000 Greetings again. The WG chairs are continuing the effort to get specific = wording for the next draft so that people will be able to see all the = proposed text changes together so that we can continue to hone each one. = We have recently done "numbers and precesion", and it's time to do "JSON = texts and strings". The following is the text that most recently seemed to enjoy general = agreement. Does anyone have any strong objection to adding the following = to the draft? A JSON text which is composed entirely of Unicode characters (however = encoded) will be interoperable in the sense that all Unicode-capable = software which parses it will agree on the contents of names and values = of object members. However, the ABNF in this specification allows = member names and string values to contain bit sequences which cannot = encode Unicode characters, for example "\udddd" (an unpaired UTF-16 = surrogate). Instances of this have been observed, for example when a = library truncates a UTF-16 string to a maximum allowable length without = checking whether the truncation split a surrogate pair. The behavior of = software which receives JSON texts containing such values is = unpredictable; for example, two different implementations might return = different values for the length of a string value, or even suffer a = fatal runtime exception. --Matt Miller and Paul Hoffman= From duerst@it.aoyama.ac.jp Wed Sep 4 19:05:54 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6849A11E8237 for ; Wed, 4 Sep 2013 19:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.333 X-Spam-Level: X-Spam-Status: No, score=-106.333 tagged_above=-999 required=5 tests=[AWL=-2.543, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7k0hOunmaQG for ; Wed, 4 Sep 2013 19:05:47 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6731411E8155 for ; Wed, 4 Sep 2013 19:05:46 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8525elm012582; Thu, 5 Sep 2013 11:05:42 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6b9e_d2cb_a9effe7a_15cf_11e3_8edc_001e6722eec2; Thu, 05 Sep 2013 11:05:40 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 5C1ABBFF7B; Thu, 5 Sep 2013 11:05:40 +0900 (JST) Message-ID: <5227E6E0.5000301@it.aoyama.ac.jp> Date: Thu, 05 Sep 2013 11:05:20 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "json@ietf.org WG" Subject: Re: [Json] Proposal for texts and string for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 02:05:54 -0000 Hello Paul, Seeing nobody else responding, I'll give it a start. On 2013/09/04 6:10, Paul Hoffman wrote: > Greetings again. The WG chairs are continuing the effort to get specific wording for the next draft so that people will be able to see all the proposed text changes together so that we can continue to hone each one. We have recently done "numbers and precesion", and it's time to do "JSON texts and strings". > > The following is the text that most recently seemed to enjoy general agreement. Does anyone have any strong objection to adding the following to the draft? I don't have any strong objection, so please go with this text if that helps move things forward. However, I have a number of minor improvements (I hope): > A JSON text which is composed entirely of Unicode characters (however encoded) will be interoperable in the sense that all Unicode-capable software which parses it will agree on the contents of names and values of object members. 1) Why use future tense here? It's not wrong, but present would work too, and would make the (rather lengthy) sentence a bit simpler. So: "will be interoperable" -> "is interoperable" and "will agree" -> "agrees". 2) It would be good to have a reference just after "Unicode characters", to make sure that any potential discussions can be resolved unambiguously. 3) "(however encoded)" has the potential to include stuff that we don't want to include. It might be preferable to leave it out or to be more precise (e.g. "either directly encoded or encoded using escaping"). This may be a bigger or smaller issue depending on context, and depending on what reference we use in 2). 4) "all Unicode-capable software": This seems to legitimize JSON processing software that isn't Unicode-capable. That's certainly not what I'd want, and I hope that's not what the group wants. So this is actually (at least close to) a non-editorial issue. > However, the ABNF in this specification allows member names and string values to contain bit sequences which cannot encode Unicode characters, for example "\udddd" (an unpaired UTF-16 surrogate). Instances of this have been observed, for example when a library truncates a UTF-16 string to a maximum allowable length without checking whether the truncation split a surrogate pair. The behavior of software which receives JSON texts containing such values is unpredictable; for example, two different implementations might return different values for the length of a string value, or even suffer a fatal runtime exception. 5) "to a maximum allowable length": There is a minor potential that this confuses some people to think that such limitations are part of JSON, or are a good idea for applications using JSON. So I'd personally prefer to remove these few words. 6) There is a number allignment problem in the last sentence. It becomes obvious if you remove one clause: "two different implementations might suffer a fatal runtime exception". Regards, Martin. > --Matt Miller and Paul Hoffman From jorge@jorgechamorro.com Fri Sep 6 03:50:46 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391F411E82A6 for ; Fri, 6 Sep 2013 03:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl70SC0boMZZ for ; Fri, 6 Sep 2013 03:50:40 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7339111E8294 for ; Fri, 6 Sep 2013 03:50:36 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x55so1682515wes.38 for ; Fri, 06 Sep 2013 03:50:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=6tdS3LaViZMDu7WR28wiK4nl2kgxi34drZi/w+GaauM=; b=kGTHF9uTYMAvq6f6TPtl0MYX9gWEVPGBug/9wQl1oDPA1iYuYmeGrM6r+SEsOyzntC 4VE4C1GEwfBpo3JgQj4+zTkhhHN7gQDE+No+CMaw5n1mZdMqBB6m+KaODwS4nP2lE73W 40lgYm8LzrEoce9eaE8iUFjJQYE6ky9R2aG51sLmb4llmA1ULPDFvlD4yEBSs2bqhZDG j2NhMaPGoaoN7NNUCdvGFVvJ7Ks5f+4kWzBxzKWmCrD0ZXhsLwYiyIoXczSHi3RCEbIM MGXm9/0ACrpdYSrEOXI1VPBvGP71BUN6lAkJO4fxIAt1OzurRw9NnTh369fWxmhklMXH tXig== X-Gm-Message-State: ALoCoQnhGxpUoEgRdVBO51tOAizWBFrtFtgrjfWaA2zACWeqbM7y5GIs7/LEyukTSJcptFqaEC9h X-Received: by 10.180.182.228 with SMTP id eh4mr9738693wic.45.1378464635289; Fri, 06 Sep 2013 03:50:35 -0700 (PDT) Received: from [192.168.10.50] ([80.30.55.250]) by mx.google.com with ESMTPSA id mb7sm2860709wic.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Sep 2013 03:50:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: <20130828190706.GB8176@mercury.ccil.org> Date: Fri, 6 Sep 2013 12:50:33 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20130828190706.GB8176@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1085) Cc: JSON WG Subject: Re: [Json] Proposal for numeric precision in JSON bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 10:50:46 -0000 On 28/08/2013, at 21:07, John Cowan wrote: > Attempting to represent numbers that cannot be > exactly encoded as an IEEE 754:2008 binary64 number, such as 1E400 or > 3.141592653589793238462643383279, may cause interoperability problems. I'd also put in that list a seemingly safe integer such as 9007199254740993: (2^53)+1 is === 2^53 Or (2^54)+2, which is === (2^54)+1 and === 2^54 Etc. -- ( Jorge )(); From cowan@ccil.org Fri Sep 6 13:45:34 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586F111E80F4 for ; Fri, 6 Sep 2013 13:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji7-1YBXZeic for ; Fri, 6 Sep 2013 13:45:29 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id E76EF11E80E0 for ; Fri, 6 Sep 2013 13:45:27 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VI2uD-000084-LE; Fri, 06 Sep 2013 16:45:25 -0400 Date: Fri, 6 Sep 2013 16:45:25 -0400 From: John Cowan To: Jorge Chamorro Message-ID: <20130906204525.GN28400@mercury.ccil.org> References: <20130828190706.GB8176@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: JSON WG Subject: Re: [Json] Proposal for numeric precision in JSON bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 20:45:34 -0000 Jorge Chamorro scripsit: > > Attempting to represent numbers that cannot be > > exactly encoded as an IEEE 754:2008 binary64 number, such as 1E400 or > > 3.141592653589793238462643383279, may cause interoperability problems. > > I'd also put in that list a seemingly safe integer such as 9007199254740993: +1 It's quite magic to open your favorite REPL: python, ruby, rhino, any Scheme, ghci, tclsh (with the "expr" command), or even bwbasic (with the 'print' command). Then type 9007199254740993.0 into it, and watch 9007199254740992.0 (or equivalent such as 9.007199254740992e15) come back out. (In Common Lisp you'll need 9007199254740993.0D0.) -- Unless it was by accident that I had John Cowan offended someone, I never apologized. cowan@ccil.org --Quentin Crisp http://www.ccil.org/~cowan From paul.hoffman@vpnc.org Fri Sep 6 14:12:06 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8418D11E812A for ; Fri, 6 Sep 2013 14:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.629 X-Spam-Level: X-Spam-Status: No, score=-102.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuv1Buk6pUN5 for ; Fri, 6 Sep 2013 14:12:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0826A11E8108 for ; Fri, 6 Sep 2013 14:12:06 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r86LC4Uw031127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 6 Sep 2013 14:12:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 6 Sep 2013 14:12:04 -0700 To: "json@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] Proposal for duplicate names in objects for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 21:12:06 -0000 Greetings again. The WG chairs are continuing the effort to get specific = wording for the next draft so that people will be able to see all the = proposed text changes together so that we can continue to hone each one. = We have recently done "numbers and precision" and "text model", and it's = time to do "objects and duplicate names". The following text reflects a summary that most recently seemed to enjoy = general agreement. Does anyone have any strong objection to adding the = following to the draft? An object whose names are all unique will be interoperable in the sense = that all software that receives that object will represent the object = the same way. When the names within an object are not unique, the = behavior of software that receives such an object is unpredictable. Many = implementations report the last name/value pair only; other = implementations report an error or fail to parse the object; other = implementations report all of the name/value pairs, including = duplicates.=20 --Matt Miller and Paul Hoffman From cowan@ccil.org Fri Sep 6 14:14:56 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644EA11E8119 for ; Fri, 6 Sep 2013 14:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvPVh4xW5atc for ; Fri, 6 Sep 2013 14:14:52 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 118A111E80E8 for ; Fri, 6 Sep 2013 14:14:52 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VI3Mg-0003PC-27; Fri, 06 Sep 2013 17:14:50 -0400 Date: Fri, 6 Sep 2013 17:14:50 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130906211449.GA12416@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org WG" Subject: Re: [Json] Proposal for duplicate names in objects for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 21:14:56 -0000 Paul Hoffman scripsit: > An object whose names are all unique will be interoperable in the > sense that all software that receives that object will represent > the object the same way. When the names within an object are not > unique, the behavior of software that receives such an object is > unpredictable. Many implementations report the last name/value pair > only; other implementations report an error or fail to parse the > object; other implementations report all of the name/value pairs, > including duplicates. I think for "unique" read "distinct", as "unique" could be misinterpreted as "globally unique". -- John Cowan http://ccil.org/~cowan cowan@ccil.org All "isms" should be "wasms". --Abbie From tbray@textuality.com Fri Sep 6 14:16:48 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8548311E8108 for ; Fri, 6 Sep 2013 14:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ydb77sE0XH6o for ; Fri, 6 Sep 2013 14:16:43 -0700 (PDT) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id A86D011E80E8 for ; Fri, 6 Sep 2013 14:16:43 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id c14so2028693vea.15 for ; Fri, 06 Sep 2013 14:16:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AxK/A1FJDJx4QFAjirkSQl/o8rsFA5FqftT0ygcbrGo=; b=RNu8UfxzwZG8MZxOrHNAdwZeEhZ7YbZpYXuc+DnelepKA7+Zs1cAzaV8/F+LQvUzSF S8nbNbNvO7weLV8TsQHLH2HpSgoJavzPBoM648Cub2jDL9vnAWZnT2zH58wgX+7UzjAv klHIvUOxjZoUSBDkQVKDcyG+d7LzO3WgGUF2odS3I3r4bJX4FY1gt/5kvKpfguNm34iU 4h8Ocfvg0aW4OoKXqWFVdHvBA2G2GpDmjyiePyBH3qtja7iIzI5hxrYXHz4ffDFq/zfG yp/qS9eSf+W7grIuPs7+A2txwA1g44UpYuqega88mLzdIE08JM4T0nsWVH8u7Fgvd2Nh BjWA== X-Gm-Message-State: ALoCoQnsfI69+mfxwtWYAo5DY1yz1upJurcD0uOKfxS8Ti4RHf6SJ4M7v3nzZsn6//s3pmcFyt3A MIME-Version: 1.0 X-Received: by 10.52.98.131 with SMTP id ei3mr3556355vdb.4.1378502202733; Fri, 06 Sep 2013 14:16:42 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Fri, 6 Sep 2013 14:16:42 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: Date: Fri, 6 Sep 2013 14:16:42 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=20cf307d03f41dca1a04e5bd8e9a Cc: "json@ietf.org WG" Subject: Re: [Json] Proposal for duplicate names in objects for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 21:16:48 -0000 --20cf307d03f41dca1a04e5bd8e9a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=9Cwill represent the object the same way=E2=80=9D is too strong. I = suggest instead ... in the sense that all software that receives that object will agree on the name-value mappings. On Fri, Sep 6, 2013 at 2:12 PM, Paul Hoffman wrote: > Greetings again. The WG chairs are continuing the effort to get specific > wording for the next draft so that people will be able to see all the > proposed text changes together so that we can continue to hone each one. = We > have recently done "numbers and precision" and "text model", and it's tim= e > to do "objects and duplicate names". > > The following text reflects a summary that most recently seemed to enjoy > general agreement. Does anyone have any strong objection to adding the > following to the draft? > > An object whose names are all unique will be interoperable in the sense > that all software that receives that object will represent the object the > same way. When the names within an object are not unique, the behavior of > software that receives such an object is unpredictable. Many > implementations report the last name/value pair only; other implementatio= ns > report an error or fail to parse the object; other implementations report > all of the name/value pairs, including duplicates. > > --Matt Miller and Paul Hoffman > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --20cf307d03f41dca1a04e5bd8e9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=9Cwill represent the object the same way=E2=80= =9D is too strong.=C2=A0 I suggest instead

... in the sense th= at all software that receives that object will agree on the name-value mapp= ings.


On Fri, Sep 6, 2013 at 2:12 PM, Paul Hof= fman <paul.hoffman@vpnc.org> wrote:
Greetings again. The WG chairs are continuing the effort to get specific wo= rding for the next draft so that people will be able to see all the propose= d text changes together so that we can continue to hone each one. We have r= ecently done "numbers and precision" and "text model", = and it's time to do "objects and duplicate names".

The following text reflects a summary that most recently seemed to enjoy ge= neral agreement. Does anyone have any strong objection to adding the follow= ing to the draft?

An object whose names are all unique will be interoperable in the sense tha= t all software that receives that object will represent the object the same= way. When the names within an object are not unique, the behavior of softw= are that receives such an object is unpredictable. Many implementations rep= ort the last name/value pair only; other implementations report an error or= fail to parse the object; other implementations report all of the name/val= ue pairs, including duplicates.

--Matt Miller and Paul Hoffman

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

--20cf307d03f41dca1a04e5bd8e9a-- From tbray@textuality.com Fri Sep 6 14:21:15 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0D011E80F8 for ; Fri, 6 Sep 2013 14:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=-1.355, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQdGA3tuDxRp for ; Fri, 6 Sep 2013 14:20:54 -0700 (PDT) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by ietfa.amsl.com (Postfix) with ESMTP id 19FDA11E80E8 for ; Fri, 6 Sep 2013 14:20:48 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id c14so1996244vea.38 for ; Fri, 06 Sep 2013 14:20:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mpE3PWowZ1N0+blARTd0/8v6jfpQI1um4qg70Gh41Wg=; b=jQUbj/v+h6hc51e1srHnzJM7yf0VKiZdjPpI6UX8RgYRBAHEqAEWhPdyLE+GPVBwaG qHgWnN2MneiaIPMYLinkv3MRTFmcfpnwNmWlmHHj+VcQSKLZqka8guzlMZ13aGQEaRji xSwyGOhwmbab/Vf6WCav+okuo9ERCaHr1JTma/vTa2lCdYDTYkiiU4BD/tpINlQq0/bS pLvSEOkHPPTd4QFOlhDIklyLShG72+hbfQXcFI+m4YgyTWKcq6/Dg6NxwthFDRTz3xFL q9LWmZZuQwAjMJyYYiuF8FW5wKLktP4XvBGbB9GcESgGg7WfA1bdBpa8scH7t/fqZxBI i9tQ== X-Gm-Message-State: ALoCoQlrsKXOQIkc2x38+kZ4Lgk4XRyyD6UkGEsNK97c//ZfelhcXwvbVTEuGzs2TblRrl5GIQkb MIME-Version: 1.0 X-Received: by 10.58.67.9 with SMTP id j9mr4283148vet.22.1378502448378; Fri, 06 Sep 2013 14:20:48 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Fri, 6 Sep 2013 14:20:48 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <5227E6E0.5000301@it.aoyama.ac.jp> References: <5227E6E0.5000301@it.aoyama.ac.jp> Date: Fri, 6 Sep 2013 14:20:48 -0700 Message-ID: From: Tim Bray To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=047d7b339e07c2089004e5bd9c1f Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposal for texts and string for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 21:21:15 -0000 --047d7b339e07c2089004e5bd9c1f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think most of Martin=E2=80=99s edits are improvements, specifically: On Wed, Sep 4, 2013 at 7:05 PM, "Martin J. D=C3=BCrst" wrote: > Seeing nobody else responding, I'll give it a start. [Paul called for objections, nobody responding is a GOOD THING. But thanks anyhow.] > 1) Why use future tense here? It's not wrong, but present would work too, > and would make the (rather lengthy) sentence a bit simpler. So: > "will be interoperable" -> "is interoperable" and > "will agree" -> "agrees". > Improvement 2) It would be good to have a reference just after "Unicode characters", to > make sure that any potential discussions can be resolved unambiguously.' > Improvement > 3) "(however encoded)" has the potential to include stuff that we don't > want to include. It might be preferable to leave it out or to be more > precise (e.g. "either directly encoded or encoded using escaping"). This > may be a bigger or smaller issue depending on context, and depending on > what reference we use in 2). > Not worried, but could live with Martin's =E2=80=9Ceither directly encoded.= .. > 4) "all Unicode-capable software": This seems to legitimize JSON > processing software that isn't Unicode-capable. That's certainly not what > I'd want, and I hope that's not what the group wants. > So this is actually (at least close to) a non-editorial issue. Meh 5) "to a maximum allowable length": There is a minor potential that this > confuses some people to think that such limitations are part of JSON, or > are a good idea for applications using JSON. So I'd personally prefer to > remove these few words. > Improvement. > 6) There is a number allignment problem in the last sentence. It becomes > obvious if you remove one clause: "two different implementations might > suffer a fatal runtime exception". > Yep > > Regards, Martin. > > > --Matt Miller and Paul Hoffman >> > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --047d7b339e07c2089004e5bd9c1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think most of Martin=E2=80=99s edits are improvements, s= pecifically:

O= n Wed, Sep 4, 2013 at 7:05 PM, "Martin J. D=C3=BCrst" <du= erst@it.aoyama.ac.jp> wrote:
Seeing nobody else responding, I'll give= it a start.

[Paul called for objections, n= obody responding is a GOOD THING.=C2=A0 But thanks anyhow.]
=C2=A0
1) Why use future ten= se here? It's not wrong, but present would work too, and would make the= (rather lengthy) sentence a bit simpler. So:
"will be interoperable" -> "is interoperable" and "will agree" -> "agrees".
=C2= =A0
Improvement

2) It would be good to have a reference just after "Unicode characters= ", to make sure that any potential discussions can be resolved unambig= uously.'

Improvement
=C2=A0
3) "(however encoded)" has the potential to include stuff that we= don't want to include. It might be preferable to leave it out or to be= more precise (e.g. "either directly encoded or encoded using escaping= "). This may be a bigger or smaller issue depending on context, and de= pending on what reference we use in 2).

Not worried, but could live with Martin= 9;s =E2=80=9Ceither directly encoded...
=C2=A0
4) "all Unicode-capable software": This seems to legitimize JSON = processing software that isn't Unicode-capable. That's certainly no= t what I'd want, and I hope that's not what the group wants.
So this is actually (at least close to) a non-editorial issue.=

Meh

5) "to a max= imum allowable length": There is a minor potential that this confuses = some people to think that such limitations are part of JSON, or are a good = idea for applications using JSON. So I'd personally prefer to remove th= ese few words.

Improvement.
=C2=A0
6) There is a number allignment problem in the last sentence. It becomes ob= vious if you remove one clause: "two different implementations might s= uffer a fatal runtime exception".

Yep
=C2=A0

Regards, =C2=A0 Martin.


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

--047d7b339e07c2089004e5bd9c1f-- From mamille2@cisco.com Fri Sep 6 14:30:00 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5E511E80E8 for ; Fri, 6 Sep 2013 14:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkxgQpaTTXop for ; Fri, 6 Sep 2013 14:29:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 160B311E80F1 for ; Fri, 6 Sep 2013 14:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7054; q=dns/txt; s=iport; t=1378502994; x=1379712594; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XF2ii/lzjYz47Y0GiOuOQOGxcE4aT3ectPoyPoxeUp8=; b=UvQNg0l80j1F130h4kG6LdENTaAqWHfRLhZ1DsbtrRz8yoAHd3EjY+oT wczyqlwAqxfuwLkWuUJtRAkPOUkdHGFfco8qlWimOvPbac80Akna2zNQO 8+0gi10UnZu30Ff0oIrZoslbaxjnigPCHVdTPdY6WpG16BNal+hedMzpr 8=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFADZIKlKtJXHA/2dsb2JhbABbgweBBoJjvnyBJhZ0giQBAQEDAXkFCwIBCCIkAjAlAgQOBQgGh24GvWCPSzEHgx2BAAOQI4EumAqDIIIq X-IronPort-AV: E=Sophos;i="4.90,857,1371081600"; d="p7s'?scan'208";a="256659579" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 06 Sep 2013 21:29:53 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r86LTrNj029944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 21:29:53 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.124]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 16:29:53 -0500 From: "Matt Miller (mamille2)" To: John Cowan Thread-Topic: [Json] Proposal for duplicate names in objects for next draft Thread-Index: AQHOq0Yk9Ry4xeTqIkWObcKTmHuqEJm5jbcA Date: Fri, 6 Sep 2013 21:29:52 +0000 Message-ID: References: <20130906211449.GA12416@mercury.ccil.org> In-Reply-To: <20130906211449.GA12416@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.123] Content-Type: multipart/signed; boundary="Apple-Mail=_8F2CBECA-D7E0-4D63-9678-519C16E87EE3"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposal for duplicate names in objects for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 21:30:00 -0000 --Apple-Mail=_8F2CBECA-D7E0-4D63-9678-519C16E87EE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 6, 2013, at 3:14 PM, John Cowan wrote: > Paul Hoffman scripsit: >=20 >> An object whose names are all unique will be interoperable in the >> sense that all software that receives that object will represent >> the object the same way. When the names within an object are not >> unique, the behavior of software that receives such an object is >> unpredictable. Many implementations report the last name/value pair >> only; other implementations report an error or fail to parse the >> object; other implementations report all of the name/value pairs, >> including duplicates. >=20 > I think for "unique" read "distinct", as "unique" could be = misinterpreted > as "globally unique". >=20 /me dons hat I will note that RFC 4627 uses the term "unique". Do you think it's = necessary changing all (one) instances of "unique" to "distinct" in = 4627bis? - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_8F2CBECA-D7E0-4D63-9678-519C16E87EE3 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5MDYyMTI5 NTNaMCMGCSqGSIb3DQEJBDEWBBSZL/k4OWIAKC8lEHsetH8a6jC85zCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAHZF f5TMHD8DvuBieDEeoSHPNMSrSYFedEv1mIzTy7a7ohzj0hk4XXDa2i3TO9PPlJqXy8+9+TWgn4g4 nRZpgdH0ZBuPO8GRQwVhSHJmUgsH4rMpGNV7hZNYk2Rckc3Sima9fSdeuhXdj26Kq0B95YwF0vN0 U2T3fhyEkTEwmoUTFF+Q4f/Go5vutjizq7jGBT0mZu0xrNNE1QuQGkZo/CiYcLqMmAbrpmrU9Q6G Y6HdHDjEFdXvxabYykT1bNAF+WL6QeC5qgpVOLwmnLR4C48fXqL7WHB8vCcUSrRi3rb6IUsRMoiT xwl2kNftGRFqFSL/d2BbWAm9Dq6tCmHvdX0AAAAAAAA= --Apple-Mail=_8F2CBECA-D7E0-4D63-9678-519C16E87EE3-- From cowan@ccil.org Fri Sep 6 14:32:59 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6354B11E813D for ; Fri, 6 Sep 2013 14:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7GLtjC4D797 for ; Fri, 6 Sep 2013 14:32:55 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 130A711E8119 for ; Fri, 6 Sep 2013 14:32:54 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VI3e9-0005BJ-CX; Fri, 06 Sep 2013 17:32:53 -0400 Date: Fri, 6 Sep 2013 17:32:53 -0400 From: John Cowan To: "Matt Miller (mamille2)" Message-ID: <20130906213253.GB12416@mercury.ccil.org> References: <20130906211449.GA12416@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposal for duplicate names in objects for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 21:32:59 -0000 Matt Miller (mamille2) scripsit: > I will note that RFC 4627 uses the term "unique". Do you think it's > necessary changing all (one) instances of "unique" to "distinct" > in 4627bis? I think that would be a Good Thing, yes. That would change the last sentence of 2.2 to: The names within an object SHOULD be distinct. -- A rabbi whose congregation doesn't want John Cowan to drive him out of town isn't a rabbi, http://www.ccil.org/~cowan and a rabbi who lets them do it cowan@ccil.org isn't a man. --Jewish saying From cowan@ccil.org Fri Sep 6 20:35:10 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AFE21F9C88 for ; Fri, 6 Sep 2013 20:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpRvpDGsGyqR for ; Fri, 6 Sep 2013 20:35:05 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id B3A4321F9CB5 for ; Fri, 6 Sep 2013 20:35:05 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VI9Id-0007YE-VF for json@ietf.org; Fri, 06 Sep 2013 23:35:04 -0400 Date: Fri, 6 Sep 2013 23:35:03 -0400 From: John Cowan To: json@ietf.org Message-ID: <20130907033503.GF9964@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Subject: [Json] Proposed language for name uniqueness X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2013 03:35:10 -0000 At the interim meeting a couple weeks ago, I volunteered to provide text on how to determine uniqueness (distinctness) of names. Here's my proposal: Names are distinct if they do not contain the same Unicode characters in the same order, after all two-character, six-character, and twelve-character escape sequences (see Section 2.5) that correspond to Unicode characters have been expanded to the corresponding character. The distinctness of names containing escape sequences that do not correspond to Unicode characters is undefined. Thus, the names "a" and "b" are distinct, whereas the names "j", "\u006a", and "\u006A" are not. It is undefined whether "\ud800" and "\\ud800" are distinct or not. -- You let them out again, Old Man Willow! John Cowan What you be a-thinking of? You should not be waking! cowan@ccil.org Eat earth! Dig deep! Drink water! Go to sleep! Bombadil is talking. http://ccil.org/~cowan From stefan@drees.name Fri Sep 6 22:45:47 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E7021F9E69 for ; Fri, 6 Sep 2013 22:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qepb1Ci+27-J for ; Fri, 6 Sep 2013 22:45:40 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id A193321F9DFB for ; Fri, 6 Sep 2013 22:45:39 -0700 (PDT) Received: from newyork.local.box ([93.129.84.190]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0LsQTc-1Vxrqk1s8e-011zjk for ; Sat, 07 Sep 2013 07:45:30 +0200 Message-ID: <522ABD78.8030106@drees.name> Date: Sat, 07 Sep 2013 07:45:28 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Cowan References: <20130906211449.GA12416@mercury.ccil.org> <20130906213253.GB12416@mercury.ccil.org> In-Reply-To: <20130906213253.GB12416@mercury.ccil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:AxT18/d5prdu71GXI+344DWwe8+wbFrFi9qwKhGHYYkwMv5UGrD gJmy1XPhmmYbLsBUU2iTj/jWqkd2VI062rLhflUZMNankE+DkG6af/DbGLmjDylosSNLCU5 myAeyd6hCg/AEXS+deSSnefxc8wMh9Vqa0oVeaK/IQrpT/PXrcbRt68Es+/BgyTfM/dwEEv MJ98ITLwiziQauwxoPB5Q== Cc: "json@ietf.org WG" , Paul Hoffman , "Matt Miller \(mamille2\)" Subject: Re: [Json] Proposal for duplicate names in objects for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 05:45:47 -0000 On 2013-09-06 23:32 +02:00, John Cowan wrote: > Matt Miller (mamille2) scripsit: > >> I will note that RFC 4627 uses the term "unique". Do you think it's >> necessary changing all (one) instances of "unique" to "distinct" >> in 4627bis? > > I think that would be a Good Thing, yes. That would change the last > sentence of 2.2 to: > > The names within an object SHOULD be distinct. I second to move away from the slippy unique, and embrace distinct but suggest to add pairwise, thus: The names within an object SHOULD be pairwise distinct. From stefan@drees.name Fri Sep 6 22:51:53 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5159A21F9E98 for ; Fri, 6 Sep 2013 22:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu4lA1FHo0L8 for ; Fri, 6 Sep 2013 22:51:47 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC9421F92C2 for ; Fri, 6 Sep 2013 22:51:47 -0700 (PDT) Received: from newyork.local.box ([93.129.84.190]) by smtp.web.de (mrweb001) with ESMTPSA (Nemesis) id 0MI6F4-1VGWD91z0Y-003tXR for ; Sat, 07 Sep 2013 07:51:46 +0200 Message-ID: <522ABEEE.5090907@drees.name> Date: Sat, 07 Sep 2013 07:51:42 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:l6ajQCGfLqHgGkri3BYqJyIdbD92cALwRzt3ZF97pUlpn6GHQrL 0z1c28ahPsVg4SclYCUaSeyzSUjQwNvSmNAVXmL0IU+33brbOs6sitMI0oZyIEwwjFauORa xgD+2I6KciMshSZ3MqHcLQzwtcJ+Qaw1xYMG7CT/y2yFCfycVYswwWFQhozrIc7vbnX0lAn kTo/9rfTOgkfWPRqmAqfw== Cc: Tim Bray , John Cowan , "json@ietf.org WG" Subject: Re: [Json] Proposal for duplicate names in objects for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 05:51:53 -0000 On 2013-09-06 23:12 +02:00, Paul Hoffman wrote: > ... > > An object whose names are all unique will be interoperable in the sense > that all software that receives that object will represent the object > the same way. When the names within an object are not unique, the > behavior of software that receives such an object is unpredictable. Many > implementations report the last name/value pair only; other > implementations report an error or fail to parse the object; other > implementations report all of the name/value pairs, including duplicates. I suggest - in unison with Tim Bray's proposal and my amendment to John Cowan's proposal - to change the first sentence of above paragraph into: An object whose names are pairwise distinct will be interoperable in the sense that all software that receives that object will agree on the name-value mappings. From stefan@drees.name Fri Sep 6 22:55:45 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0439321F9E98 for ; Fri, 6 Sep 2013 22:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoGjV1O5h4jQ for ; Fri, 6 Sep 2013 22:55:33 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.11]) by ietfa.amsl.com (Postfix) with ESMTP id ACA3821F9E7E for ; Fri, 6 Sep 2013 22:55:32 -0700 (PDT) Received: from newyork.local.box ([93.129.84.190]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0M6mL2-1WEODE3Eua-00wTAw for ; Sat, 07 Sep 2013 07:55:28 +0200 Message-ID: <522ABFCF.8040303@drees.name> Date: Sat, 07 Sep 2013 07:55:27 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Cowan References: <20130907033503.GF9964@mercury.ccil.org> In-Reply-To: <20130907033503.GF9964@mercury.ccil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:QFkJ1YFHTFyZPPuCw4jZzQE+0HbZgq3SX6CVsa/4C54llbJzOG9 HKpD0DAz2vecuejy3nsfaxDdxkeM+up+mBGCNQUmPhW7zONcsGyQi816IRe5cLELQ/Az00k dh4Tu0zjfnybzvBX3ezPa50xXcydZEWTYN6K6nBQfmpn3uffzele/7dDhgMNFJtHBg5TZuA z+wZXJPUXVrf5wVRVpVuA== Cc: json@ietf.org Subject: Re: [Json] Proposed language for name uniqueness X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 05:55:45 -0000 On 2013-09-07 05:35 +02:00, John Cowan wrote: > At the interim meeting a couple weeks ago, I volunteered to provide > text on how to determine uniqueness (distinctness) of names. Here's my > proposal: > > Names are distinct if they do not contain the same Unicode characters > in the same order, after all two-character, six-character, and > twelve-character escape sequences (see Section 2.5) that correspond to > Unicode characters have been expanded to the corresponding character. > The distinctness of names containing escape sequences that do not > correspond to Unicode characters is undefined. > > Thus, the names "a" and "b" are distinct, whereas the names "j", > "\u006a", and "\u006A" are not. It is undefined whether "\ud800" > and "\\ud800" are distinct or not. > I like this "recipe" but suggest to use pairwise distinctness instead, thus simply starting the first paragraph this way should be sufficient: Any two Names are distinct if they do not contain the same ... From cowan@ccil.org Fri Sep 6 23:59:36 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C2C21F9E48 for ; Fri, 6 Sep 2013 23:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2ANZ7zMqhSQ for ; Fri, 6 Sep 2013 23:59:32 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 95BC021F9DF3 for ; Fri, 6 Sep 2013 23:59:32 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VICUU-0001qE-Cg; Sat, 07 Sep 2013 02:59:30 -0400 Date: Sat, 7 Sep 2013 02:59:30 -0400 From: John Cowan To: Stefan Drees Message-ID: <20130907065930.GG9964@mercury.ccil.org> References: <20130907033503.GF9964@mercury.ccil.org> <522ABFCF.8040303@drees.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <522ABFCF.8040303@drees.name> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: json@ietf.org Subject: Re: [Json] Proposed language for name uniqueness X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2013 06:59:37 -0000 Stefan Drees scripsit: > I like this "recipe" but suggest to use pairwise distinctness > instead, thus simply starting the first paragraph this way should be > sufficient: > > Any two Names are distinct if they do not contain the same ... However, one of the examples is about three names, not two. Furthermore, a set of names are distinct iff they are pairwise distinct, so I see no benefit (but also no great harm) to adding "pairwise" elsewhere. -- John Cowan http://ccil.org/~cowan cowan@ccil.org Monday we watch-a Firefly's house, but he no come out. He wasn't home. Tuesday we go to the ball game, but he fool us. He no show up. Wednesday he go to the ball game, and we fool him. We no show up. Thursday was a double-header. Nobody show up. Friday it rained all day. There was no ball game, so we stayed home and we listened to it on-a the radio. --Chicolini From tbray@textuality.com Sat Sep 7 09:39:29 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01C311E8167 for ; Sat, 7 Sep 2013 09:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yX1I08zpGRF for ; Sat, 7 Sep 2013 09:39:25 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2F611E8163 for ; Sat, 7 Sep 2013 09:39:24 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id er20so3710049lab.35 for ; Sat, 07 Sep 2013 09:39:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jeasj87yOx1xvz2GGR4U9HecSF+xb9iqq1A7G9NaG1s=; b=gJJKT7OkIGlt3KPE2BdWVRfScLVJUOGlofL+vyJ8w8AKO1Mfyleq+ZeBrb4AtZFsUb 0Qd9sjOTmWSYnyZBZP6MCRYaKvPBYzQbfIO4hVniaif+84M6lS2nar+KOga6o0TN+XQ6 fy4vsyix84SECvW+aA5tFJZOnEjgwDK19z6jlRv2adTKdIPItkSfBCkviMwRxN9JChbn rqOWOfFi3ksPaliIWAR/5T57K/4DYFmgsa7ud0ENRLvuAezN1ROgCzTUsnUzhGzEE9Xh 4xnwlyMwXkCqEcWT215Slt7jQGb1rxHuGBb0692UjOAzJJePwN6gpls1RMhBzFZNlFfO LSew== X-Gm-Message-State: ALoCoQlJ38KscGh7msx1nEa5Os9KyX/Hb5Vn90bQlD+ToqbajMOAYmc24Iw0hcjnbg1qYxengMWt MIME-Version: 1.0 X-Received: by 10.152.44.225 with SMTP id h1mr7775544lam.15.1378571964029; Sat, 07 Sep 2013 09:39:24 -0700 (PDT) Received: by 10.114.175.138 with HTTP; Sat, 7 Sep 2013 09:39:23 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <20130907065930.GG9964@mercury.ccil.org> References: <20130907033503.GF9964@mercury.ccil.org> <522ABFCF.8040303@drees.name> <20130907065930.GG9964@mercury.ccil.org> Date: Sat, 7 Sep 2013 09:39:23 -0700 Message-ID: From: Tim Bray To: John Cowan Content-Type: multipart/alternative; boundary=089e0160b7be36acf104e5cdcc33 Cc: Stefan Drees , "json@ietf.org" Subject: Re: [Json] Proposed language for name uniqueness X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2013 16:39:30 -0000 --089e0160b7be36acf104e5cdcc33 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Editorial issue. I don=E2=80=99t think it=E2=80=99s possible for a human t= o be confused between elements of a collection being =E2=80=9Cdistinct=E2=80=9D vs =E2=80= =9Cpairwise distinct=E2=80=9D, but no biggie. I smell better-than-rough consensus. On Fri, Sep 6, 2013 at 11:59 PM, John Cowan wrote: > Stefan Drees scripsit: > > > I like this "recipe" but suggest to use pairwise distinctness > > instead, thus simply starting the first paragraph this way should be > > sufficient: > > > > Any two Names are distinct if they do not contain the same ... > > However, one of the examples is about three names, not two. Furthermore, > a set of names are distinct iff they are pairwise distinct, so I see > no benefit (but also no great harm) to adding "pairwise" elsewhere. > > -- > John Cowan http://ccil.org/~cowan cowan@ccil.org > Monday we watch-a Firefly's house, but he no come out. He wasn't home. > Tuesday we go to the ball game, but he fool us. He no show up. Wednesda= y > he > go to the ball game, and we fool him. We no show up. Thursday was a > double-header. Nobody show up. Friday it rained all day. There was no > ball > game, so we stayed home and we listened to it on-a the radio. --Chicolin= i > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e0160b7be36acf104e5cdcc33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Editorial issue.=C2=A0 I don=E2=80=99t think it=E2=80=99s = possible for a human to be confused between elements of a collection being = =E2=80=9Cdistinct=E2=80=9D vs =E2=80=9Cpairwise distinct=E2=80=9D, but no b= iggie.=C2=A0 I smell better-than-rough consensus.


On Fri, Sep 6= , 2013 at 11:59 PM, John Cowan <cowan@mercury.ccil.org>= wrote:
Stefan Drees scripsit:

> I like this "recipe" but suggest to use pairwise distinctnes= s
> instead, thus simply starting the first paragraph this way should be > sufficient:
>
> Any two Names are distinct if they do not contain the same ...

However, one of the examples is about three names, not two. =C2=A0Fur= thermore,
a set of names are distinct iff they are pairwise distinct, so I see
no benefit (but also no great harm) to adding "pairwise" elsewher= e.

--
John Cowan =C2=A0 =C2=A0 http://ccil.org/~cowan =C2=A0 =C2=A0cowan@ccil.org
Monday we watch-a Firefly's house, but he no come out. =C2=A0He wasn= 9;t home.
Tuesday we go to the ball game, but he fool us. =C2=A0He no show up. =C2=A0= Wednesday he
go to the ball game, and we fool him. =C2=A0We no show up. =C2=A0Thursday w= as a
double-header. =C2=A0Nobody show up. =C2=A0Friday it rained all day. =C2=A0= There was no ball
game, so we stayed home and we listened to it on-a the radio. =C2=A0--Chico= lini
_____________________= __________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e0160b7be36acf104e5cdcc33-- From mmorley@mpcm.com Mon Sep 9 08:44:38 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099DE21E81AE for ; Mon, 9 Sep 2013 08:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9ybV7VJfoqQ for ; Mon, 9 Sep 2013 08:44:27 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2E221F9C56 for ; Mon, 9 Sep 2013 08:28:44 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id u14so5203029lbd.12 for ; Mon, 09 Sep 2013 08:28:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G9P/fwzXhy2Wod6J9PRgdGprJVexqtkKv7FOnb1pb2c=; b=e58p/KmKlvHnSzn2y6r+ed7Am3ziwsFfOj3Hkic+TyP3cNjJOhok5NAvW3d/1KthVY ZmavAX6zLHhzvmYRR8v3QviE0PpBbI2SqSXTufiPd3hC9bMR7euPSRaXgbwa3zkPZn9T 18wQ8tlbkhraXpvonVUy3Xh75q57fLQl+bjGC88j6G31TquSNQihXmwd1C5kfQK0nQJZ bsyVlS1RQya43nMOUL/LMYn3agSIZs7uhuPQIrN1Eqitldv3QUmGZrSqN0gJS17oLuJd PRlnX2TmpZsn/hDsHowPkt3xAYidGWa3kr4axnBRC33hGsLf2SNuABN8v2nNTkC7glys 8r+Q== X-Gm-Message-State: ALoCoQkC8FrZ7e/rMYQ+jVhRex1CKQtjHVVFg6+iFrvXWsUjj8V3QBaFZ/KkNcz7UP7DgRRxAsj6 MIME-Version: 1.0 X-Received: by 10.112.0.242 with SMTP id 18mr16548390lbh.18.1378740519851; Mon, 09 Sep 2013 08:28:39 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.114.172.202 with HTTP; Mon, 9 Sep 2013 08:28:39 -0700 (PDT) In-Reply-To: <20130906213253.GB12416@mercury.ccil.org> References: <20130906211449.GA12416@mercury.ccil.org> <20130906213253.GB12416@mercury.ccil.org> Date: Mon, 9 Sep 2013 11:28:39 -0400 X-Google-Sender-Auth: eFnXfKR12MlzZShUcpkcP7JhnQ0 Message-ID: From: Matthew Morley To: John Cowan Content-Type: multipart/alternative; boundary=f46d042ac0e8ec5d6704e5f50aa0 Cc: "json@ietf.org WG" , Paul Hoffman , "Matt Miller \(mamille2\)" Subject: Re: [Json] Proposal for duplicate names in objects for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 15:44:38 -0000 --f46d042ac0e8ec5d6704e5f50aa0 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 6, 2013 at 5:32 PM, John Cowan wrote: > Matt Miller (mamille2) scripsit: > > > I will note that RFC 4627 uses the term "unique". Do you think it's > > necessary changing all (one) instances of "unique" to "distinct" > > in 4627bis? > > I think that would be a Good Thing, yes. That would change the last > sentence of 2.2 to: > > The names within an object SHOULD be distinct. > +1 (sent to the actual list this time) > > -- > A rabbi whose congregation doesn't want John Cowan > to drive him out of town isn't a rabbi, http://www.ccil.org/~cowan > and a rabbi who lets them do it cowan@ccil.org > isn't a man. --Jewish saying > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > -- Matthew P. C. Morley --f46d042ac0e8ec5d6704e5f50aa0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Sep 6, 2013 at 5:32 PM, John Cowan <cowan@mercury.cci= l.org> wrote:
Matt Miller (mamille2) scripsit:

> I will note that RFC 4627 uses the term "unique". =A0Do you = think it's
> necessary changing all (one) instances of "unique" to "= distinct"
> in 4627bis?

I think that would be a Good Thing, yes. =A0That would change the las= t
sentence of 2.2 to:

=A0 =A0The names within an object SHOULD be distinct.
=
= +1 (sent to the actual list this time)=A0

--
A rabbi whose congregation doesn't want =A0 =A0 =A0 =A0 John Cowan
to drive him out of town isn't a rabbi, =A0 =A0 =A0 =A0 http://www.ccil.org/~cowan and a rabbi who lets them do it =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cowan@ccil.org
isn't a man. =A0 =A0--Jewish saying
___________________________= ____________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json



--
= Matthew P. C. Morley
--f46d042ac0e8ec5d6704e5f50aa0-- From cabo@tzi.org Thu Sep 12 01:59:04 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C5121E819F for ; Thu, 12 Sep 2013 01:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.32 X-Spam-Level: X-Spam-Status: No, score=-105.32 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEzAF39vhWkQ for ; Thu, 12 Sep 2013 01:58:59 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2049E21E8194 for ; Thu, 12 Sep 2013 01:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8C8wt57013552 for ; Thu, 12 Sep 2013 10:58:55 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AB27A730; Thu, 12 Sep 2013 10:58:55 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Carsten Bormann Date: Thu, 12 Sep 2013 10:58:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52314018.4090302@gmail.com> To: JSON WG X-Mailer: Apple Mail (2.1508) Subject: [Json] People reading ECMA 262 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 08:59:04 -0000 The below message in JOSE is a current example of a recurring, interoperability-bug causing problem I have seen a lot: >> Correct. 34 chars must be escaped to comply with JSON, including = U+0000 to U+001F. >=20 > I will update the scheme but I'm a bit unsure on the result: >=20 > = http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf > "a Unicode escape sequence occurring within a string literal in an > ECMAScript program always contributes a character to the String value > of the literal and is never interpreted as a line terminator or as a > quote mark that might terminate the string literal" This message is an instance of a general problem: People read ECMA 262 and think that random statements in there about ECMAscript change the definition of JSON. (This becomes a problem because JavaScript is a non-trivial language and there is a lot of text in ECMA 262 that needs to read and understood in context to make sense. ECMA 262 is a rather good spec, but if people are picking statements there and try to interpret them as normative statements about JSON out of context of the JavaScript specification, this leads to peculiar results. For instance, one guy I know thinks there is one sentence in ECMA 262 that establishes that you can send only BMP characters, not non-BMP characters, unescaped in JSON strings, which of course is nonsense.) We need to make very clear in 4627bis that this is not the case: There is nothing in ECMA 262 that needs to be read or understood to understand 4627bis. ECMA 262 does not need to be read together with 4627bis to make sense out of the latter. In particular, we need to make sure that any reference to ECMA 262 in 4627bis is informative, not normative. But we also need to make the above clear in explanatory text. (I'll leave it to the diplomats in this group to write this text; clearly this is not trying to put down ECMA 262 in any way.) (None of this is taking away from the following two facts: -- Some versions of 262 define their own JSON. We try to stay compatible with that. -- 262 defines implementation features of the most important subset of the JSON implementations out there; it is a good source of information for maximizing interoperability. ) Gr=FC=DFe, Carsten From paul.hoffman@vpnc.org Fri Sep 13 16:57:42 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3424721E80C1 for ; Fri, 13 Sep 2013 16:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LV-6tr8f8oQ for ; Fri, 13 Sep 2013 16:57:40 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5500D21E8082 for ; Fri, 13 Sep 2013 16:57:37 -0700 (PDT) Received: from [192.168.3.208] (23-25-221-65-static.hfc.comcastbusiness.net [23.25.221.65]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8DNvWTv088515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 13 Sep 2013 16:57:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 23-25-221-65-static.hfc.comcastbusiness.net [23.25.221.65] claimed to be [192.168.3.208] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 13 Sep 2013 19:57:31 -0400 To: "json@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] Seeking volunteers for editorship of draft-ietf-json-rfc4627bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 23:57:42 -0000 Greetings. The WG has what feels like some good consensus on wording on = interoperability to be added to our main WG document, = draft-ietf-json-rfc4627bis. The chairs have reached out to the current = editor, Douglas Crockford, but we have not heard back from him after a = few attempts. In order to keep the work flowing, we are reluctantly = seeking a volunteer to replace Douglas as the editor for = draft-ietf-json-rfc4627bis. The role involves tracking the WG list = looking for additions and changes that seem to have consensus, working = with the chairs on the content of the drafts, and being timely in = updates. If you are interested in volunteering, please send a message to = Matt and Paul ASAP. And yes, the next draft will clearly acknowledge = Douglas' contribution as originator and editor of RFC 4627, on which the = -bis document is very heavily based. --Matt Miller and Paul Hoffman= From petejson@codalogic.com Tue Sep 17 02:35:12 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B683911E83C7 for ; Tue, 17 Sep 2013 02:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.085 X-Spam-Level: *** X-Spam-Status: No, score=3.085 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1, SARE_HEAD_XUNSENT=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTnMc5-o9KBp for ; Tue, 17 Sep 2013 02:35:07 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 0717011E81CA for ; Tue, 17 Sep 2013 02:35:05 -0700 (PDT) Received: (qmail 23146 invoked from network); 17 Sep 2013 10:34:55 +0100 Received: from host86-132-79-47.range86-132.btcentralplus.com (HELO codalogic) (86.132.79.47) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 17 Sep 2013 10:34:54 +0100 Message-ID: <1B23E14D0EDF4C848965C1F2F4052007@codalogic> From: "Pete Cordell" To: References: <20130906211449.GA12416@mercury.ccil.org><20130906213253.GB12416@mercury.ccil.org> <522ABD78.8030106@drees.name> X-Unsent: 1 Date: Tue, 17 Sep 2013 10:35:00 +0100 x-vipre-scanned: 005F9414005432005F9561 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: [Json] On "distinct" Was: Re: Proposal for duplicate names in objects for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 09:35:12 -0000 I don't feel that "distinct" is the best choice of words. http://www.thefreedictionary.com/distinct gives the following definitions for distinct: dis·tinct (d-stngkt) adj. 1. Readily distinguishable from all others; discrete: on two distinct occasions. 2. Easily perceived by the senses or intellect; clear: a distinct flavor. 3. Clearly defined; unquestionable: at a distinct disadvantage. 4. Very likely; probable: There is a distinct possibility that she won't come. 5. Notable: a distinct honor and high privilege. For some reason definitions 2 and 3 are what I most naturally think of when someone says "distinct". Would "locally unique" be a better choice? Or maybe just use "different": The names within an object SHOULD be different. and: An object whose names are all different will be interoperable in the sense that all software that receives that object will represent the object the same way. When the names within an object are not different, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only; other implementations report an error or fail to parse the object; other implementations report all of the name/value pairs, including duplicates. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com ----- Original Message ----- From: "Stefan Drees" To: "John Cowan" Cc: ; "Paul Hoffman" ; "Matt Miller (mamille2)" Sent: Saturday, September 07, 2013 6:45 AM Subject: Re: [Json] Proposal for duplicate names in objects for next draft > On 2013-09-06 23:32 +02:00, John Cowan wrote: >> Matt Miller (mamille2) scripsit: >> >>> I will note that RFC 4627 uses the term "unique". Do you think it's >>> necessary changing all (one) instances of "unique" to "distinct" >>> in 4627bis? >> >> I think that would be a Good Thing, yes. That would change the last >> sentence of 2.2 to: >> >> The names within an object SHOULD be distinct. > > I second to move away from the slippy unique, and embrace distinct but > suggest to add pairwise, thus: > > The names within an object SHOULD be pairwise distinct. > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From tbray@textuality.com Tue Sep 17 13:09:39 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6495B11E8141 for ; Tue, 17 Sep 2013 13:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.104 X-Spam-Level: * X-Spam-Status: No, score=1.104 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoxRr4BIpsMj for ; Tue, 17 Sep 2013 13:09:29 -0700 (PDT) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id 12D9411E810A for ; Tue, 17 Sep 2013 13:09:28 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id oz11so4823762veb.3 for ; Tue, 17 Sep 2013 13:09:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zt2DYAQeI9DTxKpGq1YbqWJQspR4xPRMlTnQEOoEyfk=; b=PWZ04cXMyKu98C1CR450tEDmNN/SuN0mMfFMV/XWAF2iSD/7oxlVlbRazlsryJciwb ROOUB7SCXI0qLeBdNG5N/I75zMCg8Q45FJ2cCVeVimeGJk7xtqr/4jrtEfEnn62NWAZ2 JSjjU27SvgOPNEIKWJZrVW4KO7QNZjOA37sNmsdtcIoV6yFRLFfVrdiBHWu3d2cMNywV /DQEZf9UFcgkkpyi8qYQVuJ+fR5tH93PpkIrD7yAknsmVRmn5XgrmvyN3O1a7SDXCERI n5TrRVY8JXnAeRPVaBTpsjp8zXXnCegHNHwBvWJrk9n43yLs/GAAVSwHdqz+v9mUsWOk yP6w== X-Gm-Message-State: ALoCoQnV0ueGH8cEZNwzUKNrZTOwWOCmN3DABFV6SyHuMcz5/WjajBkgcT62aQEm8uDwabacMEMc MIME-Version: 1.0 X-Received: by 10.58.235.193 with SMTP id uo1mr33511983vec.6.1379448568221; Tue, 17 Sep 2013 13:09:28 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Tue, 17 Sep 2013 13:09:28 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <1B23E14D0EDF4C848965C1F2F4052007@codalogic> References: <20130906211449.GA12416@mercury.ccil.org> <20130906213253.GB12416@mercury.ccil.org> <522ABD78.8030106@drees.name> <1B23E14D0EDF4C848965C1F2F4052007@codalogic> Date: Tue, 17 Sep 2013 13:09:28 -0700 Message-ID: From: Tim Bray To: Pete Cordell Content-Type: multipart/alternative; boundary=047d7bd6ac72e5235504e699e58b Cc: "json@ietf.org" Subject: Re: [Json] On "distinct" Was: Re: Proposal for duplicate names in objects for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:09:39 -0000 --047d7bd6ac72e5235504e699e58b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Actually, it might be simpler to turn it around: An object where the names constitute a set, i.e. no two of them are equal, will be interoperable in the sense.. And if we decide to write string comparison rules into the -bis, put a reference to that next to the word =E2=80=9Cequal=E2=80=9D. -T On Tue, Sep 17, 2013 at 2:35 AM, Pete Cordell wrote= : > I don't feel that "distinct" is the best choice of words. > http://www.thefreedictionary.**com/distinctgives the following definitions for distinct: > > dis=C2=B7tinct (d-stngkt) > adj. > 1. Readily distinguishable from all others; discrete: on two distinct > occasions. > 2. Easily perceived by the senses or intellect; clear: a distinct flavor. > 3. Clearly defined; unquestionable: at a distinct disadvantage. > 4. Very likely; probable: There is a distinct possibility that she won't > come. > 5. Notable: a distinct honor and high privilege. > > For some reason definitions 2 and 3 are what I most naturally think of > when someone says "distinct". Would "locally unique" be a better choice? > Or maybe just use "different": > > The names within an object SHOULD be different. > > and: > > An object whose names are all different will be interoperable in the > sense that all software that receives that object will represent > the object the same way. When the names within an object are not > different, the behavior of software that receives such an object is > unpredictable. Many implementations report the last name/value pair > only; other implementations report an error or fail to parse the > object; other implementations report all of the name/value pairs, > including duplicates. > > Pete Cordell > Codalogic Ltd > C++ tools for C++ programmers, http://codalogic.com > Read & write XML in C++, http://www.xml2cpp.com > ----- Original Message ----- From: "Stefan Drees" > To: "John Cowan" > Cc: ; "Paul Hoffman" ; "Matt Miller > (mamille2)" > Sent: Saturday, September 07, 2013 6:45 AM > Subject: Re: [Json] Proposal for duplicate names in objects for next draf= t > > > On 2013-09-06 23:32 +02:00, John Cowan wrote: >> >>> Matt Miller (mamille2) scripsit: >>> >>> I will note that RFC 4627 uses the term "unique". Do you think it's >>>> necessary changing all (one) instances of "unique" to "distinct" >>>> in 4627bis? >>>> >>> >>> I think that would be a Good Thing, yes. That would change the last >>> sentence of 2.2 to: >>> >>> The names within an object SHOULD be distinct. >>> >> >> I second to move away from the slippy unique, and embrace distinct but >> suggest to add pairwise, thus: >> >> The names within an object SHOULD be pairwise distinct. >> >> >> ______________________________**_________________ >> 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 > --047d7bd6ac72e5235504e699e58b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Actually, it might be simpler to turn it around:
=
An object where the names constitute a set, i.e. no two of them are equ= al, will be interoperable in the sense..

And if we decide to w= rite string comparison rules into the -bis, put a reference to that next to= the word =E2=80=9Cequal=E2=80=9D. -T


On Tue,= Sep 17, 2013 at 2:35 AM, Pete Cordell <petejson@codalogic.com>= ; wrote:
I don't feel that "distinct" i= s the best choice of words. http://www.thefreedictionary.com/distinct gives the following definitions for distinct:

dis=C2=B7tinct =C2=A0(d-stngkt)
adj.
1. Readily distinguishable from all others; discrete: on two distinct occas= ions.
2. Easily perceived by the senses or intellect; clear: a distinct flavor. 3. Clearly defined; unquestionable: at a distinct disadvantage.
4. Very likely; probable: There is a distinct possibility that she won'= t come.
5. Notable: a distinct honor and high privilege.

For some reason definitions 2 and 3 are what I most naturally think of when= someone says "distinct". =C2=A0Would "locally unique" = be a better choice? =C2=A0Or maybe just use "different":

=C2=A0 =C2=A0The names within an object SHOULD be different.

and:

=C2=A0 =C2=A0An object whose names are all different will be interoperable = in the
=C2=A0 =C2=A0sense that all software that receives that object will represe= nt
=C2=A0 =C2=A0the object the same way. When the names within an object are n= ot
=C2=A0 =C2=A0different, the behavior of software that receives such an obje= ct is
=C2=A0 =C2=A0unpredictable. Many implementations report the last name/value= pair
=C2=A0 =C2=A0only; other implementations report an error or fail to parse t= he
=C2=A0 =C2=A0object; other implementations report all of the name/value pai= rs,
=C2=A0 =C2=A0including duplicates.

Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com
----- Original Message ----- From: "Stefan Drees" <stefan@drees.name>
To: "John Cowan" <cowan@mercury.ccil.org>
Cc: <json@ietf.org>; "Paul Hoffman" <paul.hoffman@vpnc.org>; "Matt Miller (mamil= le2)" <mami= lle2@cisco.com>
Sent: Saturday, September 07, 2013 6:45 AM
Subject: Re: [Json] Proposal for duplicate names in objects for next draft<= br>

On 2013-09-06 23:32 +02:00, John Cowan wrote:
Matt Miller (mamille2) scripsit:

I will note that RFC 4627 uses the term "unique". =C2=A0Do you th= ink it's
necessary changing all (one) instances of "unique" to "disti= nct"
in 4627bis?

I think that would be a Good Thing, yes. =C2=A0That would change the last sentence of 2.2 to:

=C2=A0 =C2=A0 The names within an object SHOULD be distinct.

I second to move away from the slippy unique, and embrace distinct but sugg= est to add pairwise, thus:

=C2=A0 =C2=A0 The names within an object SHOULD be pairwise distinct.


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

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

--047d7bd6ac72e5235504e699e58b-- From paul.hoffman@vpnc.org Tue Sep 17 13:14:11 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A649E11E81A0 for ; Tue, 17 Sep 2013 13:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSrGOyg8afTW for ; Tue, 17 Sep 2013 13:14:10 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CCADF11E810A for ; Tue, 17 Sep 2013 13:14:10 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8HKE7bx042911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 17 Sep 2013 13:14:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Tue, 17 Sep 2013 13:14:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <784BEDD4-280F-4B0A-A37B-D774A7247F98@vpnc.org> References: To: "json@ietf.org WG" X-Mailer: Apple Mail (2.1510) Subject: Re: [Json] Seeking volunteers for editorship of draft-ietf-json-rfc4627bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:14:11 -0000 Thanks for the many kind offers of help. The chairs have chosen Tim Bray = (who contributed many of the words that will appear in the new draft) as = the new editor for the draft. He will have a new draft soon, and we can = move forwards from there. --Matt Miller and Paul Hoffman= From cowan@ccil.org Tue Sep 17 13:29:12 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E21A11E82EF for ; Tue, 17 Sep 2013 13:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZAy0vNV2Dxg for ; Tue, 17 Sep 2013 13:29:08 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 088C311E857F for ; Tue, 17 Sep 2013 13:29:07 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VM1tR-0003Vg-HR; Tue, 17 Sep 2013 16:29:05 -0400 Date: Tue, 17 Sep 2013 16:29:05 -0400 From: John Cowan To: Tim Bray Message-ID: <20130917202905.GA4083@mercury.ccil.org> References: <20130906211449.GA12416@mercury.ccil.org> <20130906213253.GB12416@mercury.ccil.org> <522ABD78.8030106@drees.name> <1B23E14D0EDF4C848965C1F2F4052007@codalogic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Pete Cordell , "json@ietf.org" Subject: Re: [Json] On "distinct" Was: Re: Proposal for duplicate names in objects for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:29:12 -0000 Tim Bray scripsit: > An object where the names constitute a set, i.e. no two of them are equal, > will be interoperable in the sense.. No, no. Saying "If you do this it's broken" is not equivalent to "If you don't do this it works", for after all it may be broken (not interoperable) for some other reason. -- Almost all theorems are true, John Cowan but almost all proofs have bugs. http://www.ccil.org/~cowan --Paul Pedersen From stedolan@stedolan.net Wed Sep 18 05:50:31 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46D411E828A for ; Wed, 18 Sep 2013 05:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZxWDmhvQgsW for ; Wed, 18 Sep 2013 05:50:25 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4E07D11E8288 for ; Wed, 18 Sep 2013 05:50:20 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id z5so6776962lbh.9 for ; Wed, 18 Sep 2013 05:50:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WJdWtJ6Xz74zqp8nIpoZNUwbWRef+ppUmanHWV0p/bs=; b=NJJBYPuM2C7XJ5M7awTCnnW3bFdPrLvc1nIu3TM6cHnyWu45iw2wqhaUEMbBNQxDau eNSK567ygEY8iaTcYmkLuEp8Hue1R1sXa1sDcTekIiR8ONsHZZjIlRKj8dBWEIAuVd5b bw9bpSmfX0WkDl/asiBsUTpTG4cBsUIC8YNa0Qi/tuxJprCZOM13olFqR9GkI4/RnfHa NizNQX7QT5nFQTrAo2nOITR2gnh7dS9g++l8IwWTVrpj/BI/1eejx5UYHCTHHTvSOB7q 5iUW8/zVVQ30xuyLyjQsoT4GiRC1kr1c8DcxQHW7ulOZVcvtmuKpDnyDsXRK4hMS9kr5 iVeA== X-Gm-Message-State: ALoCoQkFA2TjAQRBBNq3ouBMnbYpTzRtVQ2tVDG58rjZkiP3O04sUeBoE0rFIQ3xkjjN1mNXq7+6 MIME-Version: 1.0 X-Received: by 10.112.155.39 with SMTP id vt7mr10985216lbb.29.1379508619847; Wed, 18 Sep 2013 05:50:19 -0700 (PDT) Sender: stedolan@stedolan.net Received: by 10.114.79.103 with HTTP; Wed, 18 Sep 2013 05:50:19 -0700 (PDT) X-Originating-IP: [128.232.9.157] In-Reply-To: <1B23E14D0EDF4C848965C1F2F4052007@codalogic> References: <20130906211449.GA12416@mercury.ccil.org> <20130906213253.GB12416@mercury.ccil.org> <522ABD78.8030106@drees.name> <1B23E14D0EDF4C848965C1F2F4052007@codalogic> Date: Wed, 18 Sep 2013 13:50:19 +0100 X-Google-Sender-Auth: h7P8DDmvvDIrNRc5jehY3IRGKns Message-ID: From: Stephen Dolan To: Pete Cordell Content-Type: text/plain; charset=ISO-8859-1 Cc: "json@ietf.org" Subject: Re: [Json] On "distinct" Was: Re: Proposal for duplicate names in objects for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 12:50:31 -0000 On Tue, Sep 17, 2013 at 10:35 AM, Pete Cordell wrote: > For some reason definitions 2 and 3 are what I most naturally think of when > someone says "distinct". Would "locally unique" be a better choice? Or > maybe just use "different": > > The names within an object SHOULD be different. I see your point, but that still reads oddly to me. After reading that sentence, I ask "different from what?". How about: An object SHOULD NOT use the same name more than once. > and: > > An object whose names are all different will be interoperable in the > sense that all software that receives that object will represent > the object the same way. When the names within an object are not > different, the behavior of software that receives such an object is > unpredictable. Many implementations report the last name/value pair > only; other implementations report an error or fail to parse the > object; other implementations report all of the name/value pairs, > including duplicates. The first sentence seems wrong. All software that receives an object will definitely not represent the object the same way. Slightly reworded: When an object uses a given name twice, the behaviour of software that receives it is unpredictable. Many implementations report the only the last name/value pair which uses a given name; other implementations report an error or fail to parse the object; while other implementations report all of the name/value pairs, including those that share a name. Also, are implementations really allowed to reject such an object? I am not sure what the consensus is here. Stephen Dolan From petejson@codalogic.com Thu Sep 19 02:22:59 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F5F21F99EF for ; Thu, 19 Sep 2013 02:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.085 X-Spam-Level: *** X-Spam-Status: No, score=3.085 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GpxFNdueAQB for ; Thu, 19 Sep 2013 02:22:54 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id C237E21F99ED for ; Thu, 19 Sep 2013 02:22:50 -0700 (PDT) Received: (qmail 29638 invoked from network); 19 Sep 2013 10:22:42 +0100 Received: from host86-132-79-47.range86-132.btcentralplus.com (HELO codalogic) (86.132.79.47) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 19 Sep 2013 10:22:42 +0100 Message-ID: <813D0FF44C5A44FC973A08065AB7549F@codalogic> From: "Pete Cordell" To: "John Cowan" , "Tim Bray" References: <20130906211449.GA12416@mercury.ccil.org> <20130906213253.GB12416@mercury.ccil.org> <522ABD78.8030106@drees.name> <1B23E14D0EDF4C848965C1F2F4052007@codalogic> <20130917202905.GA4083@mercury.ccil.org> X-Unsent: 1 x-vipre-scanned: 006B5C0200546E006B5D4F Date: Thu, 19 Sep 2013 10:22:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: json@ietf.org Subject: Re: [Json] On "distinct" Was: Re: Proposal for duplicate names in objects for next draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 09:22:59 -0000 Original Message From: "John Cowan" > Tim Bray scripsit: > >> An object where the names constitute a set, i.e. no two of them are >> equal, >> will be interoperable in the sense.. > > No, no. Saying "If you do this it's broken" is not equivalent to > "If you don't do this it works", for after all it may be broken (not > interoperable) for some other reason. Looking back, I think "distinct" was first suggested in the following exchange: >> An object whose names are all unique will be interoperable in the >> sense that all software that receives that object will represent >> the object the same way. When the names within an object are not >> unique, the behavior of software that receives such an object is >> unpredictable. Many implementations report the last name/value pair >> only; other implementations report an error or fail to parse the >> object; other implementations report all of the name/value pairs, >> including duplicates. > > I think for "unique" read "distinct", as "unique" could be misinterpreted > as "globally unique". Looking at that, there's a case for saying "An object whose names ..." is ambiguous because "names" could be read as referring to the name of the objects themselves rather than the members therein. Therefore, would the scope of the uniqueness be clarified if the opening sentence was changed to: "An object whose members' names are all unique..."? Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From internet-drafts@ietf.org Thu Sep 19 13:57:12 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F87A21F8934; Thu, 19 Sep 2013 13:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kUAkBCmWhQ7; Thu, 19 Sep 2013 13:57:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C753E21F888F; Thu, 19 Sep 2013 13:57:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130919205710.2410.43363.idtracker@ietfa.amsl.com> Date: Thu, 19 Sep 2013 13:57:10 -0700 Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-rfc4627bis-03.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:57:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the JavaScript Object Notation Working Group = of the IETF. Title : The JSON Data Interchange Format Author(s) : Tim Bray Filename : draft-ietf-json-rfc4627bis-03.txt Pages : 13 Date : 2013-09-18 Abstract: JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tbray@textuality.com Thu Sep 19 14:04:03 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333EE21F8495 for ; Thu, 19 Sep 2013 14:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.936 X-Spam-Level: X-Spam-Status: No, score=-0.936 tagged_above=-999 required=5 tests=[AWL=2.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEeq-T5H2oXn for ; Thu, 19 Sep 2013 14:03:57 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 54BCB21F83E2 for ; Thu, 19 Sep 2013 14:03:57 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id ij15so6965426vcb.16 for ; Thu, 19 Sep 2013 14:03:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=F3WD+3bI4ygqpqN/8HIHCSgtqU6tXBA2BTEaQVzm0+E=; b=NCk4MSwIVmm6YURtMJdTA4EYGpQ+Lg/kypkjfrF1US0e5I7rtMWzgKP4083RZR9H20 vPpR5Z/3/tjeSNKatqS+rIn9xlYuTHEAjJF7ZKJrGLIuuoWZ2NjnWtzXugZ/hOzUw7lo yOzQeCUxb3NlMGNzM1g8trs8EX6au/1lr4z3gh9z9J8Nbn7dlyu+r9Wx23BW9jbM36Pb 8SJ1c+ectqJD/psR96LHaIKGRgTd13LWSWHqDrPYNO/6dvmnE9Nfd5xlRZqy/4Vvwy1c dcksbV0UlhduWkfUMF559q5N22aafUfaIEYzOpcC8DaaWIczrwkAMI8B+5JvxPYohnyF fTbA== X-Gm-Message-State: ALoCoQl45eeto+9KecfHQfdXMyVDV0xXM3W6S06f6aVzBVWv0S3vM6VMQAn6bvPBz8C2VTQTeZR3 MIME-Version: 1.0 X-Received: by 10.52.107.226 with SMTP id hf2mr2365338vdb.2.1379624636625; Thu, 19 Sep 2013 14:03:56 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 19 Sep 2013 14:03:56 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> Date: Thu, 19 Sep 2013 14:03:56 -0700 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=bcaec54859ae63c8a504e6c2e413 Subject: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-03.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 21:04:03 -0000 --bcaec54859ae63c8a504e6c2e413 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the invite to stand in for Douglas, whom I hope is OK and I=E2= =80=99m sad if our mob-pedantry drove him away. - A *real* HTML version is at https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-03.html - Paul insisted that I load up section 1.3 with all the changes I made. I checked by diffing the XML, so I think they=E2=80=99re about right. - The language is 95% straight outta the consensus calls, with the exception of the new section 1.2 (Introduction to this version), which I thought was necessary, and 8.3 (String comparison) which we=E2=80=99d agree= d on generally but nobody=E2=80=99d written language. Have fun! ---------- Forwarded message ---------- From: Date: Thu, Sep 19, 2013 at 1:57 PM Subject: New Version Notification for draft-ietf-json-rfc4627bis-03.txt To: Tim Bray A new version of I-D, draft-ietf-json-rfc4627bis-03.txt has been successfully submitted by Tim Bray and posted to the IETF repository. Filename: draft-ietf-json-rfc4627bis Revision: 03 Title: The JSON Data Interchange Format Creation date: 2013-09-18 Group: json Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-03.txt Status: http://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis Htmlized: http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-03 Abstract: JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --bcaec54859ae63c8a504e6c2e413 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the invite to stand in for Douglas, w= hom I hope is OK and I=E2=80=99m sad if our mob-pedantry drove him away.
- A *real* HTML version is at https://www.tbray.org/tmp/draft-ietf-json-= rfc4627bis-03.html

- Paul insisted that I load up section 1.3 with all the changes I= made. I checked by diffing the XML, so I think they=E2=80=99re about right= .

- The language is 95% straight outta the consensus call= s, with the exception of the new section 1.2 (Introduction to this version)= , which I thought was necessary, and 8.3 (String comparison) which we=E2=80= =99d agreed on generally but nobody=E2=80=99d written language.

Have fun!

---------- Forwar= ded message ----------
From: <internet-drafts@ietf.org= >
Date: Thu, Sep 19, 2013 at 1:57 PM
Subject: New Version Notification for= draft-ietf-json-rfc4627bis-03.txt
To: Tim Bray <tbray@textuality.com>



A new version of I-D, draft-ietf-json-rfc4627bis-03.txt
has been successfully submitted by Tim Bray and posted to the
IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-json-rfc4627bis
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A003
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The JSON Data Interchange Format<= br> Creation date: =C2=A0 2013-09-18
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 json
Number of pages: 13
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 htt= p://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-03.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatracker.= ietf.org/doc/draft-ietf-json-rfc4627bis
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html= /draft-ietf-json-rfc4627bis-03
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://w= ww.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-03

Abstract:
=C2=A0 =C2=A0JavaScript Object Notation (JSON) is a lightweight, text-based= ,
=C2=A0 =C2=A0language-independent data interchange format. =C2=A0It was der= ived from
=C2=A0 =C2=A0the ECMAScript Programming Language Standard. =C2=A0JSON defin= es a small
=C2=A0 =C2=A0set of formatting rules for the portable representation of str= uctured
=C2=A0 =C2=A0data.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--bcaec54859ae63c8a504e6c2e413-- From waldron.rick@gmail.com Thu Sep 19 14:22:22 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0640221F8613 for ; Thu, 19 Sep 2013 14:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIksdg+KGSRr for ; Thu, 19 Sep 2013 14:22:17 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C710921F88FB for ; Thu, 19 Sep 2013 14:22:09 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id x18so8477792lbi.3 for ; Thu, 19 Sep 2013 14:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=I3I19FrR37EYvMadavq49KcevOOcoXzJG7a+EfZy8x0=; b=IzUH+84NL3wgPTYrhLY9p1hV3P9A8H+9XgBR4SgINxgMZnzybp0HXxyUdS+bmM8Qey 0rBpIdR53mzSO2owwxSwWlNDVJAb/GtOz/Acv9ZFcLOC91zUu7N/AwKKWY62siIBFPXd FsM9M5pfAGLpKBoIIRziv14p1FGgAvb/A1tB10oMhLK2g7NQaKaM8mkJoOeLhO3PsTaI ccPJkze465vXsPOmATqf5MxdWaaFbhi4fAKOCPFiz33JwvGPCtHBnAgqsRHF/HUliQHa s9vEXB8wf+tF5ZZbFDFtl1RAZups00zHXpXJ3UmAO/OvvItTsEylNnypRtg6vhrGpfzS jI/Q== X-Received: by 10.152.243.42 with SMTP id wv10mr2845607lac.39.1379625711247; Thu, 19 Sep 2013 14:21:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.154.40 with HTTP; Thu, 19 Sep 2013 14:21:31 -0700 (PDT) In-Reply-To: References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> From: Rick Waldron Date: Thu, 19 Sep 2013 17:21:31 -0400 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=001a1134290c7125b004e6c32473 Cc: "json@ietf.org" Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-03.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 21:22:22 -0000 --001a1134290c7125b004e6c32473 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In section 2, JSON Grammar the definition of JSON-text is wrong. It shouldn't be restricted to just "object/array". JSON-text is the top most production and may consist of any JSON-value: object, array, string, number, true (literal), false (literal), null (literal) > A JSON text is a sequence of tokens. The set of tokens includes six structural characters, strings, numbers, and three literal names. > > A JSON text is a serialized object or array. > > JSON-text =3D object / array This is a compatibility breaking change. Rick On Thu, Sep 19, 2013 at 5:03 PM, Tim Bray wrote: > Thanks for the invite to stand in for Douglas, whom I hope is OK and I=92= m > sad if our mob-pedantry drove him away. > > - A *real* HTML version is at > https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-03.html > > - Paul insisted that I load up section 1.3 with all the changes I made. I > checked by diffing the XML, so I think they=92re about right. > > - The language is 95% straight outta the consensus calls, with the > exception of the new section 1.2 (Introduction to this version), which I > thought was necessary, and 8.3 (String comparison) which we=92d agreed on > generally but nobody=92d written language. > > Have fun! > > ---------- Forwarded message ---------- > From: > Date: Thu, Sep 19, 2013 at 1:57 PM > Subject: New Version Notification for draft-ietf-json-rfc4627bis-03.txt > To: Tim Bray > > > > A new version of I-D, draft-ietf-json-rfc4627bis-03.txt > has been successfully submitted by Tim Bray and posted to the > IETF repository. > > Filename: draft-ietf-json-rfc4627bis > Revision: 03 > Title: The JSON Data Interchange Format > Creation date: 2013-09-18 > Group: json > Number of pages: 13 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-03.txt > Status: > http://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis > Htmlized: http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-03 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-03 > > Abstract: > JavaScript Object Notation (JSON) is a lightweight, text-based, > language-independent data interchange format. It was derived from > the ECMAScript Programming Language Standard. JSON defines a small > set of formatting rules for the portable representation of structured > data. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --001a1134290c7125b004e6c32473 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
In section 2, JSON Grammar the definition of JSON-text is = wrong. It shouldn't be restricted to just "object/array". JSO= N-text is the top most production and may consist of any JSON-value: object= , array, string, number, true (literal), false (literal), null=A0(literal)<= div>
> =A0A JSON text is a sequence of tokens. =A0The set= of tokens includes six structural characters, strings, numbers, and three = literal names.
>
> =A0A JSON text is a serialized= object or array.
>
> =A0JSON-text =3D object / array
This is a compatibility breaking change.

<= div>Rick






On Thu, Sep 1= 9, 2013 at 5:03 PM, Tim Bray <tbray@textuality.com> wrote= :
Thanks for the invite to stand in for Douglas, w= hom I hope is OK and I=92m sad if our mob-pedantry drove him away.

-= A *real* HTML version is at https://www.tbray.org/tmp/draf= t-ietf-json-rfc4627bis-03.html

- Paul insisted that I load up section 1.3 with all the changes I= made. I checked by diffing the XML, so I think they=92re about right.
<= br>
- The language is 95% straight outta the consensus calls, wit= h the exception of the new section 1.2 (Introduction to this version), whic= h I thought was necessary, and 8.3 (String comparison) which we=92d agreed = on generally but nobody=92d written language.

Have fun!

---------- Forwar= ded message ----------
From: <intern= et-drafts@ietf.org>
Date: Thu, Sep 19, 2013 at 1:57 PM
Subject: New Version Notification for= draft-ietf-json-rfc4627bis-03.txt
To: Tim Bray <tbray@textuality.com>



A new version of I-D, draft-ietf-json-rfc4627bis-03.txt
has been successfully submitted by Tim Bray and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-ietf-json-rfc4627bis
Revision: =A0 =A0 =A0 =A003
Title: =A0 =A0 =A0 =A0 =A0 The JSON Data Interchange Format
Creation date: =A0 2013-09-18
Group: =A0 =A0 =A0 =A0 =A0 json
Number of pages: 13
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/i= nternet-drafts/draft-ietf-json-rfc4627bis-03.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/dr= aft-ietf-json-rfc4627bis
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-ietf-= json-rfc4627bis-03
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdif= f?url2=3Ddraft-ietf-json-rfc4627bis-03

Abstract:
=A0 =A0JavaScript Object Notation (JSON) is a lightweight, text-based,
=A0 =A0language-independent data interchange format. =A0It was derived from=
=A0 =A0the ECMAScript Programming Language Standard. =A0JSON defines a smal= l
=A0 =A0set of formatting rules for the portable representation of structure= d
=A0 =A0data.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



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


--001a1134290c7125b004e6c32473-- From tbray@textuality.com Thu Sep 19 14:24:27 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894A021F8415 for ; Thu, 19 Sep 2013 14:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=1.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WFKtAmYIIA4 for ; Thu, 19 Sep 2013 14:24:23 -0700 (PDT) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id D188421F8459 for ; Thu, 19 Sep 2013 14:24:22 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id jw12so7227232veb.37 for ; Thu, 19 Sep 2013 14:24:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XKpR2v/BfP2M0nzMcoyU8JB/yf+PsGGiD45CXfQKvsc=; b=B+f3Mp85HYd2KMOF4fz14K/Y4NpQcLdl4b98hxYcsh/ObNX2K8ax92adQvmDB/FMba jpAvU21C/EwuBITHwYTc3iAMx8AiZbMbO+qhH5pfNDRp8UfcLxu7ebFK7BXa94reAWBv ZXx76pAlCnl2O9DnQf7XbSws1iPqKvw8Vp6C2HtTGuEe5gKCyru+bAsHCWrdFvhCYTTf Hb0RVwkZ2gyXPXJZs8NNhDnfZ3ffyxWFQYUft6N5qOfexMhV2kso0ORZ+PRk4Fg3Q7Oy TIl7hCmh+AD9m9i3SIUz5600oVzcv4D7txvqNyN1LUsYLLuGTsraonLGzdBZ94pnAyXa Brgw== X-Gm-Message-State: ALoCoQk4pYYTVBAx+XrtmLyWXzviIiIEW7kKh8pDFR3w7GmLAayQGyEqSAzF9Es7/3ArXziV+4Ok MIME-Version: 1.0 X-Received: by 10.52.34.109 with SMTP id y13mr2447707vdi.8.1379625862304; Thu, 19 Sep 2013 14:24:22 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 19 Sep 2013 14:24:22 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> Date: Thu, 19 Sep 2013 14:24:22 -0700 Message-ID: From: Tim Bray To: Rick Waldron Content-Type: multipart/alternative; boundary=20cf30780c5c722c2704e6c32da5 Cc: "json@ietf.org" Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-03.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 21:24:27 -0000 --20cf30780c5c722c2704e6c32da5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Sep 19, 2013 at 2:21 PM, Rick Waldron wrote= : > In section 2, JSON Grammar the definition of JSON-text is wrong. It > shouldn't be restricted to just "object/array". JSON-text is the top most > production and may consist of any JSON-value: object, array, string, > number, true (literal), false (literal), null (literal) > I think it can=E2=80=99t be a breaking change because it=E2=80=99s not a ch= ange. I didn=E2=80=99t touch that part. > > > A JSON text is a sequence of tokens. The set of tokens includes six > structural characters, strings, numbers, and three literal names. > > > > A JSON text is a serialized object or array. > > > > JSON-text =3D object / array > > This is a compatibility breaking change. > > Rick > > > > > > > On Thu, Sep 19, 2013 at 5:03 PM, Tim Bray wrote: > >> Thanks for the invite to stand in for Douglas, whom I hope is OK and I= =E2=80=99m >> sad if our mob-pedantry drove him away. >> >> - A *real* HTML version is at >> https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-03.html >> >> - Paul insisted that I load up section 1.3 with all the changes I made. = I >> checked by diffing the XML, so I think they=E2=80=99re about right. >> >> - The language is 95% straight outta the consensus calls, with the >> exception of the new section 1.2 (Introduction to this version), which I >> thought was necessary, and 8.3 (String comparison) which we=E2=80=99d ag= reed on >> generally but nobody=E2=80=99d written language. >> >> Have fun! >> >> ---------- Forwarded message ---------- >> From: >> Date: Thu, Sep 19, 2013 at 1:57 PM >> Subject: New Version Notification for draft-ietf-json-rfc4627bis-03.txt >> To: Tim Bray >> >> >> >> A new version of I-D, draft-ietf-json-rfc4627bis-03.txt >> has been successfully submitted by Tim Bray and posted to the >> IETF repository. >> >> Filename: draft-ietf-json-rfc4627bis >> Revision: 03 >> Title: The JSON Data Interchange Format >> Creation date: 2013-09-18 >> Group: json >> Number of pages: 13 >> URL: >> http://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-03.txt >> Status: >> http://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis >> Htmlized: http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-0= 3 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-03 >> >> Abstract: >> JavaScript Object Notation (JSON) is a lightweight, text-based, >> language-independent data interchange format. It was derived from >> the ECMAScript Programming Language Standard. JSON defines a small >> set of formatting rules for the portable representation of structured >> data. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> >> > --20cf30780c5c722c2704e6c32da5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 19, 2013 at 2:21 PM, Rick Waldron <waldr= on.rick@gmail.com> wrote:
In section 2, JSON Grammar = the definition of JSON-text is wrong. It shouldn't be restricted to jus= t "object/array". JSON-text is the top most production and may co= nsist of any JSON-value: object, array, string, number, true (literal), fal= se (literal), null=C2=A0(literal)

I think it can=E2=80=99t be a breaking cha= nge because it=E2=80=99s not a change.=C2=A0 I didn=E2=80=99t touch that pa= rt.

=C2=A0

> =C2=A0A JSON text is a sequence of tokens. =C2=A0T= he set of tokens includes six structural characters, strings, numbers, and = three literal names.
>
> =C2=A0A JSON text is a s= erialized object or array.
>
> =C2=A0JSON-text =3D object / array

This is a compatibility breaking change.

Rick






On Thu, Sep 19, 2013 at 5:03 PM, Tim Bray <<= a href=3D"mailto:tbray@textuality.com" target=3D"_blank">tbray@textuality.c= om> wrote:
Thanks for the invite to stand in for Douglas, w= hom I hope is OK and I=E2=80=99m sad if our mob-pedantry drove him away.
- A *real* HTML version is at https://www.tbray.org/tm= p/draft-ietf-json-rfc4627bis-03.html

- Paul insisted that I load up section 1.3 with all the changes I= made. I checked by diffing the XML, so I think they=E2=80=99re about right= .

- The language is 95% straight outta the consensus call= s, with the exception of the new section 1.2 (Introduction to this version)= , which I thought was necessary, and 8.3 (String comparison) which we=E2=80= =99d agreed on generally but nobody=E2=80=99d written language.

Have fun!

---------- Forwar= ded message ----------
From: <intern= et-drafts@ietf.org>
Date: Thu, Sep 19, 2013 at 1:57 PM
Subject: New Version Notification for= draft-ietf-json-rfc4627bis-03.txt
To: Tim Bray <tbray@textuality.com>



A new version of I-D, draft-ietf-json-rfc4627bis-03.txt
has been successfully submitted by Tim Bray and posted to the
IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-json-rfc4627bis
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A003
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The JSON Data Interchange Format<= br> Creation date: =C2=A0 2013-09-18
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 json
Number of pages: 13
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 htt= p://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-03.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatracker.= ietf.org/doc/draft-ietf-json-rfc4627bis
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html= /draft-ietf-json-rfc4627bis-03
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://w= ww.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-03

Abstract:
=C2=A0 =C2=A0JavaScript Object Notation (JSON) is a lightweight, text-based= ,
=C2=A0 =C2=A0language-independent data interchange format. =C2=A0It was der= ived from
=C2=A0 =C2=A0the ECMAScript Programming Language Standard. =C2=A0JSON defin= es a small
=C2=A0 =C2=A0set of formatting rules for the portable representation of str= uctured
=C2=A0 =C2=A0data.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



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



--20cf30780c5c722c2704e6c32da5-- From paul.hoffman@vpnc.org Thu Sep 19 14:37:17 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF51921F84D0 for ; Thu, 19 Sep 2013 14:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5E6u8AsTHdJh for ; Thu, 19 Sep 2013 14:37:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B345D21F85EE for ; Thu, 19 Sep 2013 14:37:14 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8JLbB41047576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Sep 2013 14:37:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Thu, 19 Sep 2013 14:37:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0CFB59C6-4469-4444-A418-C27D6973B63C@vpnc.org> References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> To: Rick Waldron X-Mailer: Apple Mail (2.1510) Cc: "json@ietf.org WG" Subject: [Json] What is a JSON-text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 21:37:18 -0000 On Sep 19, 2013, at 2:21 PM, Rick Waldron = wrote: > In section 2, JSON Grammar the definition of JSON-text is wrong. It is identical to what is in RFC 4627. > It shouldn't be restricted to just "object/array". JSON-text is the = top most production and may consist of any JSON-value: object, array, = string, number, true (literal), false (literal), null (literal) >=20 > > A JSON text is a sequence of tokens. The set of tokens includes = six structural characters, strings, numbers, and three literal names. > > > > A JSON text is a serialized object or array. > > > > JSON-text =3D object / array >=20 > This is a compatibility breaking change. You mean compatibility with ECMAScript, yes? RFC 4627 and ECMAScript = disagree on this, and have disagreed on this for a very long time. Is = your proposal that the -bis document breaks compatibility with RFC 4627 = in the definition of JSON-text in order to be compatible with = ECMAScript? --Paul Hoffman= From cowan@ccil.org Thu Sep 19 14:45:12 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C8A21F883D for ; Thu, 19 Sep 2013 14:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iax7hcz-yRIV for ; Thu, 19 Sep 2013 14:45:08 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2D62A21F8704 for ; Thu, 19 Sep 2013 14:45:08 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VMm26-0007K4-5C; Thu, 19 Sep 2013 17:45:06 -0400 Date: Thu, 19 Sep 2013 17:45:06 -0400 From: John Cowan To: Rick Waldron Message-ID: <20130919214506.GB13122@mercury.ccil.org> References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-03.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 21:45:12 -0000 Rick Waldron scripsit: > In section 2, JSON Grammar the definition of JSON-text is wrong. It > shouldn't be restricted to just "object/array". It always has been so restricted. 123 is not a valid JSON text, nor is true. -- John Cowan http://www.ccil.org/~cowan Charles li reis, nostre emperesdre magnes, Set anz totz pleinz ad ested in Espagnes. From tbray@textuality.com Thu Sep 19 15:04:40 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319A721F88FB for ; Thu, 19 Sep 2013 15:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.680, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeY+wCZJolqh for ; Thu, 19 Sep 2013 15:04:35 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3A25021F85B8 for ; Thu, 19 Sep 2013 15:04:35 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id if17so6369779vcb.4 for ; Thu, 19 Sep 2013 15:04:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=T6agwc8gb78SF0iwx3+6eCsn7oYDh0ke9UhmHCWHG5c=; b=ifBi+GT1ZA+kAQ3WZLahEUEDjbHHTLqnui1txf3QTkeKUQxunikFDizBOWbTmnvuBi DWlzx9CHFM4x+SaE1Y1gC61hnEguql/vNF1UAZR0CepluZjU/iqneaVPIG4nu9b5wjMX qEwrMvNZG4HRUNb+60Tvr06aKx6CCmM8SltbJviSWrWaHwOIFR9EbK4+wqN2mTNt9msW y9pDjsy/c/xWwir8/wh3prGFUU+5YZP3Il17FNNoj81WiUGCfMs5jhkPX+8P9ymMpd0V 0oxZ7Grf2/6OJ/2nJfcLHGi3nr8Hxy0fsro+pBYlRFOTEf0fnknU4Dw6dXK8UJjmAVRu A75w== X-Gm-Message-State: ALoCoQke7NztIvurDxYrRV51YwTK99zXtGQ2n3uSYC96obJyy3kggBZ0HFUGLInC3faTGMK7jXXU MIME-Version: 1.0 X-Received: by 10.220.186.202 with SMTP id ct10mr3061933vcb.14.1379628274420; Thu, 19 Sep 2013 15:04:34 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 19 Sep 2013 15:04:34 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <0CFB59C6-4469-4444-A418-C27D6973B63C@vpnc.org> References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> <0CFB59C6-4469-4444-A418-C27D6973B63C@vpnc.org> Date: Thu, 19 Sep 2013 15:04:34 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b676fd038309f04e6c3bdc5 Cc: Rick Waldron , "json@ietf.org WG" Subject: Re: [Json] What is a JSON-text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 22:04:40 -0000 --047d7b676fd038309f04e6c3bdc5 Content-Type: text/plain; charset=UTF-8 I ran a quick check on the languages with their guts open on my desktop, to see how they behave given a top-level data item claimed to be JSON. Ruby: Blows up. Go: Works fine. On Thu, Sep 19, 2013 at 2:37 PM, Paul Hoffman wrote: > > > On Sep 19, 2013, at 2:21 PM, Rick Waldron wrote: > > > In section 2, JSON Grammar the definition of JSON-text is wrong. > > It is identical to what is in RFC 4627. > > > It shouldn't be restricted to just "object/array". JSON-text is the top > most production and may consist of any JSON-value: object, array, string, > number, true (literal), false (literal), null (literal) > > > > > A JSON text is a sequence of tokens. The set of tokens includes six > structural characters, strings, numbers, and three literal names. > > > > > > A JSON text is a serialized object or array. > > > > > > JSON-text = object / array > > > > This is a compatibility breaking change. > > You mean compatibility with ECMAScript, yes? RFC 4627 and ECMAScript > disagree on this, and have disagreed on this for a very long time. Is your > proposal that the -bis document breaks compatibility with RFC 4627 in the > definition of JSON-text in order to be compatible with ECMAScript? > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b676fd038309f04e6c3bdc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I ran a quick check on the languages with their guts = open on my desktop, to see how they behave given a top-level data item clai= med to be JSON.

Ruby: Blows up.
Go: Works fine.


On Thu, Sep 19, 2013 at 2:37 PM, Paul Ho= ffman <paul.hoffman@vpnc.org> wrote:
<chair hat on>

On Sep 19, 2013, at 2:21 PM, Rick Waldron <waldron.rick@gmail.com> wrote:

> In section 2, JSON Grammar the definition of JSON-text is wrong.

It is identical to what is in RFC 4627.

> It shouldn't be restricted to just "object/array". JSON-= text is the top most production and may consist of any JSON-value: object, = array, string, number, true (literal), false (literal), null (literal)
>
> > =C2=A0A JSON text is a sequence of tokens. =C2=A0The set of token= s includes six structural characters, strings, numbers, and three literal n= ames.
> >
> > =C2=A0A JSON text is a serialized object or array.
> >
> > =C2=A0JSON-text =3D object / array
>
> This is a compatibility breaking change.

You mean compatibility with ECMAScript, yes? RFC 4627 and ECMAScript disagr= ee on this, and have disagreed on this for a very long time. Is your propos= al that the -bis document breaks compatibility with RFC 4627 in the definit= ion of JSON-text in order to be compatible with ECMAScript?

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

--047d7b676fd038309f04e6c3bdc5-- From pfpschneider@gmail.com Thu Sep 19 15:51:22 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEB321F8C0C for ; Thu, 19 Sep 2013 15:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwQGSZ2WD2vW for ; Thu, 19 Sep 2013 15:51:21 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id B5A5621F84E0 for ; Thu, 19 Sep 2013 15:51:21 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id r5so5954527qcx.9 for ; Thu, 19 Sep 2013 15:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NNpfuGgWW2cwmZ0THFafPG9MuiL+n3jtbJOcPJ7kRIY=; b=0nIaglri2fDSyYdanaYi2lDcmilFhBw2UTivgzUn2RvuogIgxhskBWdXVGAKn99JrN kAvucELRMgDPPVG5rWCcpF43zDf/H0dD/12KCUji5WM+BMpdv1ogtAAShYvmBJrERH9h LxElKwc/JQcUZ/nvYLPF82l4sTDylfFeKyh3Mu2wvPurnM6Mh6LLAw128mVgfQGRInt2 BdDDCVfmEK16awKgTAI8MT9Ky+0KfewyNTUtc5LVDIj9vNxiRWii3k8/0ZfDYJ8VfFA5 2P0zJiqplICNakMVpQctKl19V4z55Wft+HJaNMBCRTa1CAhBDmZm60+Ir9ECl+VkdPNk jK+w== X-Received: by 10.229.201.67 with SMTP id ez3mr8141417qcb.1.1379631080167; Thu, 19 Sep 2013 15:51:20 -0700 (PDT) Received: from [192.168.1.101] (out-on-244.wireless.telus.com. [207.219.69.244]) by mx.google.com with ESMTPSA id h20sm13983762qen.5.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 19 Sep 2013 15:51:19 -0700 (PDT) Message-ID: <523B7FE5.6050200@gmail.com> Date: Thu, 19 Sep 2013 15:51:17 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tim Bray References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "json@ietf.org" Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-03.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 22:51:22 -0000 I was wondering about the required behaviour of JSON parsers on inputs that represent strings that are not valid JSON string (which are a sequence of zero or more Unicode characters). One such input is [ "\uDEAD" ] Are JSON parsers required to silently accept such inputs, and produce some valid JSON data, for example turning the above input into an array of the one-character string of the Unicode OBJECT REPLACEMENT CHARACTER (U+FFFC) (or something else). Or are JSON parsers required to silently accept such inputs, and produce an output that mirrors the input, here an array of the one-element sequence of the number 0xDEAD? Or are JSON parsers required to signal that this input is illegal, even though it matches the JSON grammar? This question is not about the behavior of software that uses the output of a JSON parser, just about the required behaviour of JSON parsers. (I'm very much hoping that JSON parsers are allowed to signal that such inputs are illegal so that downstream software does not have to worry about malformed strings nor about infidelities between the input and the output of a JSON parser.) Peter F. Patel-Schneider Nuance Communications From tbray@textuality.com Thu Sep 19 16:01:25 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F377521F8C20 for ; Thu, 19 Sep 2013 16:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta5eo7WdubJP for ; Thu, 19 Sep 2013 16:01:18 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id F31E221F8B07 for ; Thu, 19 Sep 2013 16:01:14 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lf11so6934419vcb.7 for ; Thu, 19 Sep 2013 16:01:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fW7bXjeCK3sA8iAq+pWMUKjo4o2xZjOGpbWIEx+iyM4=; b=XTXCiD2MTgCRRi6I9ErNVc5TtfBhn6oXRqHhicN3/3/HEn9fzcNBkQ6rZtyUwciu3q ouK3g6Cx7u4uIWqB/R5Fr9XPP7MOjFxNbHuYMua2Z24cL32l2dE32WPT4V9wKmixVZFa PkT0CELCNK85Qhff+67qZjpp30OJU64oi9smCAiekQVgaNr0fiMf6iOWPIBmdYVU6THD k2JLqpTX4/FIWK/PWr4B09RD4cQ6aClC7s+NUXjJ2qJBrrue7TmNP3IZHBd1R6f34rgP q2XCEdv96sMMh0cjpkN0MwS4J54mnZ//YIhcY8t5jcGb5xBr0frJAYukrNbyHWDTnu7a npBg== X-Gm-Message-State: ALoCoQlw9RIq9O0Ant0DslXw2rPvHF04jvvzjFF+r8j+B8G4LjFpsBBDfMD+eJx9MnSeyD8akGZW MIME-Version: 1.0 X-Received: by 10.220.16.73 with SMTP id n9mr3197162vca.24.1379631672828; Thu, 19 Sep 2013 16:01:12 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 19 Sep 2013 16:01:12 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <523B7FE5.6050200@gmail.com> References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> <523B7FE5.6050200@gmail.com> Date: Thu, 19 Sep 2013 16:01:12 -0700 Message-ID: From: Tim Bray To: "Peter F. Patel-Schneider" Content-Type: multipart/alternative; boundary=001a11c3bea0c7d25704e6c48710 Cc: "json@ietf.org" Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-03.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 23:01:25 -0000 --001a11c3bea0c7d25704e6c48710 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The RFC says the parser MUST accept it if it matches the grammar, and {"a" : "\uDEAD" } does, so it has to be accepted. The -bis says that emitting such JSON will potentially lead to interoperability problems including downstream crashes. I=E2=80=99m not sure that anything further can be said in the context of ou= r current charter. -T On Thu, Sep 19, 2013 at 3:51 PM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > I was wondering about the required behaviour of JSON parsers on inputs > that represent strings that are not valid JSON string (which are a sequen= ce > of zero or more Unicode characters). One such input is > > [ "\uDEAD" ] > > Are JSON parsers required to silently accept such inputs, and produce som= e > valid JSON data, for example turning the above input into an array of the > one-character string of the Unicode OBJECT REPLACEMENT CHARACTER (U+FFFC) > (or something else). > > Or are JSON parsers required to silently accept such inputs, and produce > an output that mirrors the input, here an array of the one-element sequen= ce > of the number 0xDEAD? > > Or are JSON parsers required to signal that this input is illegal, even > though it matches the JSON grammar? > > > This question is not about the behavior of software that uses the output > of a JSON parser, just about the required behaviour of JSON parsers. (I'= m > very much hoping that JSON parsers are allowed to signal that such inputs > are illegal so that downstream software does not have to worry about > malformed strings nor about infidelities between the input and the output > of a JSON parser.) > > > > Peter F. Patel-Schneider > Nuance Communications > > > > --001a11c3bea0c7d25704e6c48710 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The RFC says the parser MUST accept it if it mat= ches the grammar, and {"a" : "\uDEAD" } does, so it has= to be accepted.

The -bis says that emitting such JSON will p= otentially lead to interoperability problems including downstream crashes.<= br>
I=E2=80=99m not sure that anything further can be said in the con= text of our current charter.=C2=A0 -T
<= br>
On Thu, Sep 19, 2013 at 3:51 PM, Peter F.= Patel-Schneider <pfpschneider@gmail.com> wrote:
I was wondering about the required behaviour= of JSON parsers on inputs that represent strings that are not valid JSON s= tring (which are a sequence of zero or more Unicode characters). =C2=A0 One= such input is

[ "\uDEAD" ]

Are JSON parsers required to silently accept such inputs, and produce some = valid JSON data, for example turning the above input into an array of the o= ne-character string of the Unicode OBJECT REPLACEMENT CHARACTER (U+FFFC) (o= r something else).

Or are JSON parsers required to silently accept such inputs, and produce an= output that mirrors the input, here an array of the one-element sequence o= f the number 0xDEAD?

Or are JSON parsers required to signal that this input is illegal, even tho= ugh it matches the JSON grammar?


This question is not about the behavior of software that uses the output of= a JSON parser, just about the required behaviour of JSON parsers. =C2=A0(I= 'm very much hoping that JSON parsers are allowed to signal that such i= nputs are illegal so that downstream software does not have to worry about = malformed strings nor about infidelities between the input and the output o= f a JSON parser.)



Peter F. Patel-Schneider
Nuance Communications




--001a11c3bea0c7d25704e6c48710-- From pfpschneider@gmail.com Thu Sep 19 16:14:13 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD8F21F859C for ; Thu, 19 Sep 2013 16:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPWvwfd08aim for ; Thu, 19 Sep 2013 16:14:12 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id A25F621F8578 for ; Thu, 19 Sep 2013 16:14:12 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id x12so5852982qcv.8 for ; Thu, 19 Sep 2013 16:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jz19+OlM2oCFmEOGuefqCiGMsPfGMCd95yF19yTdhCQ=; b=k5zFhCEO/j8VXB1A+6z3aJT/AtRPJCTINIOonMszVq1W/0Diwr+khPOKQ/424msdId QuLkMhDAB6ubX/RJ/95ftZ7aefkjlm/pDyOQ4ust7AT0NK91RcbjKuXPcC1zKNwB8LQL lBTspP1Zu48zd5bbJUG03xdVgAWibEvqcYuYI1MkxnVlGf/tDjs46vMJgHWU6xK9cZ8c 07LdTmh8Udd5uJ3eZwIfekRlURRGt1uHIpPJ0s+dkMI591eqtomHQ9T+axC9qSq1E4Zi GlMTR0yrKRJnykEcB4DvcqjDUy/HlNykFhOePNvn/F+5U914ijzPuz//cRhTivROpBiE J/aQ== X-Received: by 10.49.95.234 with SMTP id dn10mr762734qeb.54.1379632452042; Thu, 19 Sep 2013 16:14:12 -0700 (PDT) Received: from [192.168.1.101] (out-on-244.wireless.telus.com. [207.219.69.244]) by mx.google.com with ESMTPSA id b9sm14841239qad.1.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 19 Sep 2013 16:14:11 -0700 (PDT) Message-ID: <523B8542.7000104@gmail.com> Date: Thu, 19 Sep 2013 16:14:10 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tim Bray References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> <523B7FE5.6050200@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "json@ietf.org" Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-03.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 23:14:13 -0000 OK, {"a":"\uDEAD"} matches the grammar, so a JSON parser is obligated to accept it. (YUCK!) However, what can a JSON parser produce for this input? JSON strings are sequences of Unicode characters, so, as I read the document, a sequence consisting of only 0xDEAD is not a JSON string, and a JSON parser that produces such an output is not compliant. peter On 09/19/2013 04:01 PM, Tim Bray wrote: > The RFC says the parser MUST accept it if it matches the grammar, and {"a" : > "\uDEAD" } does, so it has to be accepted. > > The -bis says that emitting such JSON will potentially lead to > interoperability problems including downstream crashes. > > I’m not sure that anything further can be said in the context of our current > charter. -T > > > On Thu, Sep 19, 2013 at 3:51 PM, Peter F. Patel-Schneider > > wrote: > > I was wondering about the required behaviour of JSON parsers on inputs > that represent strings that are not valid JSON string (which are a > sequence of zero or more Unicode characters). One such input is > > [ "\uDEAD" ] > > Are JSON parsers required to silently accept such inputs, and produce > some valid JSON data, for example turning the above input into an array > of the one-character string of the Unicode OBJECT REPLACEMENT CHARACTER > (U+FFFC) (or something else). > > Or are JSON parsers required to silently accept such inputs, and produce > an output that mirrors the input, here an array of the one-element > sequence of the number 0xDEAD? > > Or are JSON parsers required to signal that this input is illegal, even > though it matches the JSON grammar? > > > This question is not about the behavior of software that uses the output > of a JSON parser, just about the required behaviour of JSON parsers. > (I'm very much hoping that JSON parsers are allowed to signal that such > inputs are illegal so that downstream software does not have to worry > about malformed strings nor about infidelities between the input and the > output of a JSON parser.) > > > > Peter F. Patel-Schneider > Nuance Communications > > > > From tbray@textuality.com Thu Sep 19 16:19:35 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9468921F8AF4 for ; Thu, 19 Sep 2013 16:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KKjJy1VoFaY for ; Thu, 19 Sep 2013 16:19:29 -0700 (PDT) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 83FE021F8984 for ; Thu, 19 Sep 2013 16:19:29 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id f12so7126099vbg.11 for ; Thu, 19 Sep 2013 16:19:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g4Dpg2vMGsz0+xkJVlolwcLZin9xWvGPQ1NE2t2hPJA=; b=Zu1fu+EFF0+KreFTSQ/YZ2yJPsPSIJ9yHo1J2+a2QIbcDshEkRYRkQM5Pq6Ql5m0fW xnqDSV2plv6GvhmKgCAS6wTiNNtfeWDuQNyZAgj0R6ustyG5eJVO+Ogx2XHSywQNmkH1 tD11sVxWF3xpL1H77Opv+i4aq2/gZRQPwis/dSy6SrLGJPGaCJz2wVIwAQetZzykudcM RsT4V9TnIQYLx6Kk1GpKGOn7K/sKfXlG5P6UsAMJQ2nFJtatIjGAfexnTD3/FQELq+J4 eiTRfPuT7s2GFfdxrQb/WaZL1cIiGx+dBC065ZyD5AZWFPuFQekzQXc6JSfzzoAd/asx CLqg== X-Gm-Message-State: ALoCoQmYBV2UuZJbd/MWlqoEX6TFDxugvh6QBiCF3LD/e7V0lu3nrYFcoK3JCHXGjCSAHioT5Lof MIME-Version: 1.0 X-Received: by 10.220.11.7 with SMTP id r7mr3303956vcr.12.1379632768889; Thu, 19 Sep 2013 16:19:28 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 19 Sep 2013 16:19:28 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <523B8542.7000104@gmail.com> References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> <523B7FE5.6050200@gmail.com> <523B8542.7000104@gmail.com> Date: Thu, 19 Sep 2013 16:19:28 -0700 Message-ID: From: Tim Bray To: "Peter F. Patel-Schneider" Content-Type: multipart/alternative; boundary=001a11c3e47c1c46a604e6c4c92e Cc: "json@ietf.org" Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-03.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 23:19:35 -0000 --001a11c3e47c1c46a604e6c4c92e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The RFC describes the interchange format and is entirely silent on the subject of software behavior except to say that the text in question must be accepted. Getting into the business of specifying behavior, or what it is that a JSON parser emits, is a first step onto a very long and slippery slope. Let=E2= =80=99s not go there. On Thu, Sep 19, 2013 at 4:14 PM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > OK, {"a":"\uDEAD"} matches the grammar, so a JSON parser is obligated to > accept it. (YUCK!) > > However, what can a JSON parser produce for this input? JSON strings ar= e > sequences of Unicode characters, so, as I read the document, a sequence > consisting of only 0xDEAD is not a JSON string, and a JSON parser that > produces such an output is not compliant. > > peter > > > > > On 09/19/2013 04:01 PM, Tim Bray wrote: > >> The RFC says the parser MUST accept it if it matches the grammar, and >> {"a" : "\uDEAD" } does, so it has to be accepted. >> >> The -bis says that emitting such JSON will potentially lead to >> interoperability problems including downstream crashes. >> >> I=E2=80=99m not sure that anything further can be said in the context of= our >> current charter. -T >> >> >> On Thu, Sep 19, 2013 at 3:51 PM, Peter F. Patel-Schneider < >> pfpschneider@gmail.com > wrote: >> >> I was wondering about the required behaviour of JSON parsers on inpu= ts >> that represent strings that are not valid JSON string (which are a >> sequence of zero or more Unicode characters). One such input is >> >> [ "\uDEAD" ] >> >> Are JSON parsers required to silently accept such inputs, and produc= e >> some valid JSON data, for example turning the above input into an >> array >> of the one-character string of the Unicode OBJECT REPLACEMENT >> CHARACTER >> (U+FFFC) (or something else). >> >> Or are JSON parsers required to silently accept such inputs, and >> produce >> an output that mirrors the input, here an array of the one-element >> sequence of the number 0xDEAD? >> >> Or are JSON parsers required to signal that this input is illegal, >> even >> though it matches the JSON grammar? >> >> >> This question is not about the behavior of software that uses the >> output >> of a JSON parser, just about the required behaviour of JSON parsers. >> (I'm very much hoping that JSON parsers are allowed to signal that >> such >> inputs are illegal so that downstream software does not have to worr= y >> about malformed strings nor about infidelities between the input and >> the >> output of a JSON parser.) >> >> >> >> Peter F. Patel-Schneider >> Nuance Communications >> >> >> >> >> > --001a11c3e47c1c46a604e6c4c92e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The RFC describes the interchange format and is entirely s= ilent on the subject of software behavior except to say that the text in qu= estion must be accepted.=C2=A0

Getting into the business of specify= ing behavior, or what it is that a JSON parser emits, is a first step onto = a very long and slippery slope. Let=E2=80=99s not go there.


On Thu,= Sep 19, 2013 at 4:14 PM, Peter F. Patel-Schneider <pfpschneider@gmai= l.com> wrote:
OK, {"a":"\uDEAD"} match= es the grammar, so a JSON parser is obligated to accept it. =C2=A0(YUCK!)
However, what can a JSON parser produce for this input? =C2=A0 JSON strings= are sequences of Unicode characters, so, as I read the document, a sequenc= e consisting of only 0xDEAD is not a JSON string, and a JSON parser that pr= oduces such an output is not compliant.

peter




On 09/19/2013 04:01 PM, Tim Bray wrote:
The RFC says the parser MUST accept it if it matches the grammar, and {&quo= t;a" : "\uDEAD" } does, so it has to be accepted.

The -bis says that emitting such JSON will potentially lead to interoperabi= lity problems including downstream crashes.

I=E2=80=99m not sure that anything further can be said in the context of ou= r current charter. =C2=A0-T


On Thu, Sep 19, 2013 at 3:51 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com &= lt;mailto:pfpsc= hneider@gmail.com>> wrote:

=C2=A0 =C2=A0 I was wondering about the required behaviour of JSON parsers = on inputs
=C2=A0 =C2=A0 that represent strings that are not valid JSON string (which = are a
=C2=A0 =C2=A0 sequence of zero or more Unicode characters). One such input = is

=C2=A0 =C2=A0 [ "\uDEAD" ]

=C2=A0 =C2=A0 Are JSON parsers required to silently accept such inputs, and= produce
=C2=A0 =C2=A0 some valid JSON data, for example turning the above input int= o an array
=C2=A0 =C2=A0 of the one-character string of the Unicode OBJECT REPLACEMENT= CHARACTER
=C2=A0 =C2=A0 (U+FFFC) (or something else).

=C2=A0 =C2=A0 Or are JSON parsers required to silently accept such inputs, = and produce
=C2=A0 =C2=A0 an output that mirrors the input, here an array of the one-el= ement
=C2=A0 =C2=A0 sequence of the number 0xDEAD?

=C2=A0 =C2=A0 Or are JSON parsers required to signal that this input is ill= egal, even
=C2=A0 =C2=A0 though it matches the JSON grammar?


=C2=A0 =C2=A0 This question is not about the behavior of software that uses= the output
=C2=A0 =C2=A0 of a JSON parser, just about the required behaviour of JSON p= arsers.
=C2=A0 =C2=A0 =C2=A0(I'm very much hoping that JSON parsers are allowed= to signal that such
=C2=A0 =C2=A0 inputs are illegal so that downstream software does not have = to worry
=C2=A0 =C2=A0 about malformed strings nor about infidelities between the in= put and the
=C2=A0 =C2=A0 output of a JSON parser.)



=C2=A0 =C2=A0 Peter F. Patel-Schneider
=C2=A0 =C2=A0 Nuance Communications






--001a11c3e47c1c46a604e6c4c92e-- From pfpschneider@gmail.com Thu Sep 19 16:20:00 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0056021F8B12 for ; Thu, 19 Sep 2013 16:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E19LF44PBXNk for ; Thu, 19 Sep 2013 16:19:59 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC6221F8984 for ; Thu, 19 Sep 2013 16:19:59 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id bv4so38602qab.6 for ; Thu, 19 Sep 2013 16:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gxKtp1hHUq/A13HbMN2/JgjPVuPetfK69lBiiMQUR0k=; b=lj52YTL1VAgi9mP4GBGJK9Uz+fAYytKdLzcTU+uSNKwmIqCxaV44k8Y+GPkzopBZzY rhLFhPrpP4k2MUFukuG5YO3XUjnc2jEbfS2y9Bep65ul7x4/rxSoQ4iFyPJUZYaEMGY8 9D75XKwME5q3s5dI2ds4uJOdJAqG5gF0UOWqXoSsvwVRJkTgMO1RlayGBRY+UXj5ecjA gTGGLju58pPK3HxKpqW0dQRxxhyDwM9fiqao7+jK2chvsca5+oU9+4+wYeALhnfF78hU i6i/3dV1Hrdo3N2rxHqEwd3nrYFYQCjA7Y8T4HXn8WHLFUwSpqk/X2xnKXOfT8YTQONS Ah5g== X-Received: by 10.49.81.133 with SMTP id a5mr789502qey.55.1379632798679; Thu, 19 Sep 2013 16:19:58 -0700 (PDT) Received: from [192.168.1.101] (out-on-244.wireless.telus.com. [207.219.69.244]) by mx.google.com with ESMTPSA id e7sm6545575qag.7.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 19 Sep 2013 16:19:58 -0700 (PDT) Message-ID: <523B869C.2080507@gmail.com> Date: Thu, 19 Sep 2013 16:19:56 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tim Bray References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "json@ietf.org" Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-03.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 23:20:00 -0000 I find the advice about parsers somewhat contradictory, even though it carried over from the RFC. The first paragraph says that parsers must accept all JSON texts but then implementations may set limits on the size of texts that they accept. Are implementations parsers? If so, then they have to accept all JSON texts. If not, then what are they, and how do they reject JSON texts that are too big, or too complex, or ...? It might be a good idea to clarify this section. Peter F. Patel-Schneider 9. Parsers A JSON parser transforms a JSON text into another representation. A JSON parser MUST accept all texts that conform to the JSON grammar. A JSON parser MAY accept non-JSON forms or extensions. An implementation may set limits on the size of texts that it accepts. An implementation may set limits on the maximum depth of nesting. An implementation may set limits on the range of numbers. An implementation may set limits on the length and character contents of strings. From pfpschneider@gmail.com Thu Sep 19 16:30:11 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD5021F871B for ; Thu, 19 Sep 2013 16:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnYMkc0g48eJ for ; Thu, 19 Sep 2013 16:30:10 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8B36121F85F5 for ; Thu, 19 Sep 2013 16:30:10 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id l4so5947102qcv.38 for ; Thu, 19 Sep 2013 16:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UYl5mAXQTOxPqzO6o9/W7XYKFRR1Uvd8bTU41JALi+c=; b=fQSRfTz6DXDAM0/7iEc/4ejNq1cH5Wk6z0C7ydmyYMFFpwpnDHzT6pu5LbvNpB/cC1 qXnXQlo5uijACZ19FhK0GEyNwAk5wEV+XsgVGcvaetrJF0h9YSwGvjbP0CH+mgZFHsQo 7oHCUqVdP4ePAGk+KHOs3SkVJ4Jay8ZsK7mhuIaLVasmezGkBlRNtb6R0IUUnGqmBfe4 xVzfmDkQRUcjz9oJzFhPScHaws3e5/3y1uO2yZ2AAyP1a14FQEgABVeeGYcj5nct8dsT r6aUkTvvY2ZdthqOFQccd8H6RzhR+SUOp6UI4kDDwY+weqZh8aPUOaxQ9XB477r/J3z8 VBBw== X-Received: by 10.224.171.196 with SMTP id i4mr1800150qaz.38.1379633410037; Thu, 19 Sep 2013 16:30:10 -0700 (PDT) Received: from [192.168.1.101] (out-on-244.wireless.telus.com. [207.219.69.244]) by mx.google.com with ESMTPSA id n9sm6611093qag.8.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 19 Sep 2013 16:30:09 -0700 (PDT) Message-ID: <523B88FE.6080501@gmail.com> Date: Thu, 19 Sep 2013 16:30:06 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tim Bray References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> <523B7FE5.6050200@gmail.com> <523B8542.7000104@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "json@ietf.org" Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-03.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 23:30:11 -0000 Yeah, it's a tricky business to achieve interoperability. However, without touching on these issues, can JSON ever be used where the either the sending or the receiving software is unknown? It does appear that "An implementation may set limits on the length and character contents of strings." could provide cover for a JSON parser that signals an error on JSON texts that contain illegal Unicode characters. I do hope that this section is clarified to indicate that "implementation" includes "JSON parser" and that the entire paragraph overrides the previous paragraph. peter On 09/19/2013 04:19 PM, Tim Bray wrote: > The RFC describes the interchange format and is entirely silent on the > subject of software behavior except to say that the text in question must be > accepted. > > Getting into the business of specifying behavior, or what it is that a JSON > parser emits, is a first step onto a very long and slippery slope. Let’s not > go there. > > > On Thu, Sep 19, 2013 at 4:14 PM, Peter F. Patel-Schneider > > wrote: > > OK, {"a":"\uDEAD"} matches the grammar, so a JSON parser is obligated to > accept it. (YUCK!) > > However, what can a JSON parser produce for this input? JSON strings are > sequences of Unicode characters, so, as I read the document, a sequence > consisting of only 0xDEAD is not a JSON string, and a JSON parser that > produces such an output is not compliant. > > peter > > > > > On 09/19/2013 04:01 PM, Tim Bray wrote: > > The RFC says the parser MUST accept it if it matches the grammar, > and {"a" : "\uDEAD" } does, so it has to be accepted. > > The -bis says that emitting such JSON will potentially lead to > interoperability problems including downstream crashes. > > I’m not sure that anything further can be said in the context of our > current charter. -T > > > On Thu, Sep 19, 2013 at 3:51 PM, Peter F. Patel-Schneider > > >> wrote: > > I was wondering about the required behaviour of JSON parsers on > inputs > that represent strings that are not valid JSON string (which are a > sequence of zero or more Unicode characters). One such input is > > [ "\uDEAD" ] > > Are JSON parsers required to silently accept such inputs, and > produce > some valid JSON data, for example turning the above input into > an array > of the one-character string of the Unicode OBJECT REPLACEMENT > CHARACTER > (U+FFFC) (or something else). > > Or are JSON parsers required to silently accept such inputs, and > produce > an output that mirrors the input, here an array of the one-element > sequence of the number 0xDEAD? > > Or are JSON parsers required to signal that this input is > illegal, even > though it matches the JSON grammar? > > > This question is not about the behavior of software that uses > the output > of a JSON parser, just about the required behaviour of JSON parsers. > (I'm very much hoping that JSON parsers are allowed to signal > that such > inputs are illegal so that downstream software does not have to > worry > about malformed strings nor about infidelities between the input > and the > output of a JSON parser.) > > > > Peter F. Patel-Schneider > Nuance Communications > > > > > > From cowan@ccil.org Thu Sep 19 16:47:52 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BF521F8793 for ; Thu, 19 Sep 2013 16:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDs8JD9qYDmO for ; Thu, 19 Sep 2013 16:47:48 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2403421F841B for ; Thu, 19 Sep 2013 16:47:40 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VMnwh-0003O3-7f; Thu, 19 Sep 2013 19:47:39 -0400 Date: Thu, 19 Sep 2013 19:47:39 -0400 From: John Cowan To: Tim Bray Message-ID: <20130919234739.GA9517@mercury.ccil.org> References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-03.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 23:47:52 -0000 Tim Bray scripsit: > - The language is 95% straight outta the consensus calls, with the > exception of the new section 1.2 (Introduction to this version), which I > thought was necessary, and 8.3 (String comparison) which we’d agreed on > generally but nobody’d written language. There's a bug. The use of "code unit" in 8.3 is undefined unless it's specified whether 8-bit, 16-bit, or 32-bit code units are intended (see the Unicode glossary). I think changing the first instance to "16-bit code units" will suffice. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Be yourself. Especially do not feign a working knowledge of RDF where no such knowledge exists. Neither be cynical about RELAX NG; for in the face of all aridity and disenchantment in the world of markup, James Clark is as perennial as the grass. --DeXiderata, Sean McGrath From cowan@ccil.org Thu Sep 19 16:57:11 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9357B21F89F7 for ; Thu, 19 Sep 2013 16:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lireFuAic7Q for ; Thu, 19 Sep 2013 16:57:07 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5FB21F8A38 for ; Thu, 19 Sep 2013 16:57:05 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VMo5n-0004Ip-VG; Thu, 19 Sep 2013 19:57:04 -0400 Date: Thu, 19 Sep 2013 19:57:03 -0400 From: John Cowan To: "Peter F. Patel-Schneider" Message-ID: <20130919235703.GB9517@mercury.ccil.org> References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> <523B7FE5.6050200@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <523B7FE5.6050200@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-03.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 23:57:11 -0000 Peter F. Patel-Schneider scripsit: > Are JSON parsers required to silently accept such inputs, and produce > some valid JSON data, for example turning the above input into an > array of the one-character string of the Unicode OBJECT REPLACEMENT > CHARACTER (U+FFFC) (or something else). They MAY do that, but are not REQUIRED to. An internal string containing U+FFFD is also reasonable. > Or are JSON parsers required to silently accept such inputs, and > produce an output that mirrors the input, here an array of the > one-element sequence of the number 0xDEAD? I'd say that's too far away from reasonableness. Strings aren't numbers. > Or are JSON parsers required to signal that this input is illegal, > even though it matches the JSON grammar? They MAY do that, but are not REQUIRED to. Finally, if the parser's internal representation of JSON strings consists of a sequence of 16-bit code units, then of course it MAY return an array of a one-member sequence consisting of that code unit. This is what parsers written in Java, C#, or JavaScript generally do. -- weirdo: When is R7RS coming out? John Cowan Riastradh: As soon as the top is a beautiful cowan@ccil.org golden brown and if you stick a toothpick in it, the toothpick comes out dry. www.ccil.org/~cowan From waldron.rick@gmail.com Thu Sep 19 17:02:22 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F6B21F85C9 for ; Thu, 19 Sep 2013 17:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8HcF-SjT0pJ for ; Thu, 19 Sep 2013 17:02:22 -0700 (PDT) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1E95321F85B4 for ; Thu, 19 Sep 2013 17:02:22 -0700 (PDT) Received: by mail-vb0-f45.google.com with SMTP id e15so6873408vbg.4 for ; Thu, 19 Sep 2013 17:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ey+SNAY3Za0f0lGRhj/Ot6oIHCJ8x7h3wSOxV2mrx/4=; b=yyhKbVcq+8fiI6aynU3OIjR3m3kgiXOAYtz+KAxW6/YboThUQE7GO8tiY1dZyfNK8H thH6il71rwKGZ7OLntSqlomOPSBnCZhZcFBzB4BfJhEfFvXqr5eC1S403fjGjTAa9a8a 1Sdl2vnQXNEcWE5EyntMQDdoKnrRTWFq0aoHuaErK1SJCrLXETI/qdahHZxenutuAil6 Wx13l0b3TcUNSlLRwspienULPot56YGK0nlTbMfX5UjfIRKe90BSIZ/rgVklFDsP07zJ aTLxYPTCW6v7KRPx6zSGanDWnR6MQlTI5yhNvfUjkuEPXno214SluwfXJrTOjIQLZDTf t9UA== MIME-Version: 1.0 X-Received: by 10.52.98.131 with SMTP id ei3mr2877541vdb.4.1379635341474; Thu, 19 Sep 2013 17:02:21 -0700 (PDT) Received: by 10.220.140.195 with HTTP; Thu, 19 Sep 2013 17:02:21 -0700 (PDT) In-Reply-To: References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> Date: Thu, 19 Sep 2013 20:02:21 -0400 Message-ID: From: Rick Waldron To: Tim Bray Content-Type: multipart/alternative; boundary=20cf307d03f472c38404e6c5627e Cc: "json@ietf.org" Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-03.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 00:02:22 -0000 --20cf307d03f472c38404e6c5627e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thursday, September 19, 2013, Tim Bray wrote: > On Thu, Sep 19, 2013 at 2:21 PM, Rick Waldron > > wrote: > >> In section 2, JSON Grammar the definition of JSON-text is wrong. It >> shouldn't be restricted to just "object/array". JSON-text is the top mos= t >> production and may consist of any JSON-value: object, array, string, >> number, true (literal), false (literal), null (literal) >> > > I think it can=92t be a breaking change because it=92s not a change. I d= idn=92t > touch that part. > > Apologies, I was comparing to the JSON grammar spec in ES5.1 Rick > > --20cf307d03f472c38404e6c5627e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thursday, September 19, 2013, Tim Bray wrote:

Rick=A0=A0

--20cf307d03f472c38404e6c5627e-- From tsaloranta@gmail.com Thu Sep 19 17:07:17 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DF821F8682 for ; Thu, 19 Sep 2013 17:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JdtxGL227y1 for ; Thu, 19 Sep 2013 17:07:16 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9C19821F86BE for ; Thu, 19 Sep 2013 17:07:12 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq15so8736636wib.12 for ; Thu, 19 Sep 2013 17:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8Y3ESHesS0UdRs2QGZiRfgFjROqV8TrHRm+1HQ+G4TM=; b=jmNFGJrlb3eja4qJmpWTcOd1ze3q9KyhNlrx0B94FWPIE1ZUurA8GaWDaGfVZKxx9K 9Ka3yxbiREHbkBOfHLVPiQ9TIu3b58D2Lxoo5CZ5TDH5fsIokp44ohaxXil683yCeTSQ Z96PUtWRAtbzW5LVdL1YFiYrRMhbMlzR8RR98Y5bKvLdgpNW+CI0z6DNnqlTiqziCGWL h8kWLFcGRI6ftIjytFkPjF/DlWF22SvaAHUIETtpmRtXoc2X6qs0I5cJ3PUyYPY4pwaS np2wr1odge6MK8rbXtpHfEhReharFdPPF3MLB23CxCjb8q3nGJcb3AIy+WkirMM+Dq3Q /Bww== MIME-Version: 1.0 X-Received: by 10.194.123.8 with SMTP id lw8mr3613128wjb.40.1379635631799; Thu, 19 Sep 2013 17:07:11 -0700 (PDT) Received: by 10.216.122.132 with HTTP; Thu, 19 Sep 2013 17:07:11 -0700 (PDT) In-Reply-To: <523B88FE.6080501@gmail.com> References: <20130919205712.2410.87679.idtracker@ietfa.amsl.com> <523B7FE5.6050200@gmail.com> <523B8542.7000104@gmail.com> <523B88FE.6080501@gmail.com> Date: Thu, 19 Sep 2013 17:07:11 -0700 Message-ID: From: Tatu Saloranta To: "Peter F. Patel-Schneider" Content-Type: multipart/alternative; boundary=089e012282c8c0c4b604e6c573bc Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-03.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 00:07:17 -0000 --089e012282c8c0c4b604e6c573bc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Sep 19, 2013 at 4:30 PM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > Yeah, it's a tricky business to achieve interoperability. However, > without touching on these issues, can JSON ever be used where the either > the sending or the receiving software is unknown? > > It is and has been used that way for years now. Twitter, Facebook et al do not know or care about kind of JSON processing library that the other end has. As nice as it would be to straighten these out, these potential issues haven't slowed down JSON adoption in any meaningful way so far. -+ Tatu +- > On 09/19/2013 04:19 PM, Tim Bray wrote: > >> The RFC describes the interchange format and is entirely silent on the >> subject of software behavior except to say that the text in question mus= t >> be accepted. >> >> Getting into the business of specifying behavior, or what it is that a >> JSON parser emits, is a first step onto a very long and slippery slope. >> Let=92s not go there. >> >> >> On Thu, Sep 19, 2013 at 4:14 PM, Peter F. Patel-Schneider < >> pfpschneider@gmail.com > wrote: >> >> OK, {"a":"\uDEAD"} matches the grammar, so a JSON parser is obligate= d >> to >> accept it. (YUCK!) >> >> However, what can a JSON parser produce for this input? JSON strings >> are >> sequences of Unicode characters, so, as I read the document, a >> sequence >> consisting of only 0xDEAD is not a JSON string, and a JSON parser th= at >> produces such an output is not compliant. >> >> peter >> >> >> >> >> On 09/19/2013 04:01 PM, Tim Bray wrote: >> >> The RFC says the parser MUST accept it if it matches the grammar= , >> and {"a" : "\uDEAD" } does, so it has to be accepted. >> >> The -bis says that emitting such JSON will potentially lead to >> interoperability problems including downstream crashes. >> >> I=92m not sure that anything further can be said in the context = of >> our >> current charter. -T >> >> >> On Thu, Sep 19, 2013 at 3:51 PM, Peter F. Patel-Schneider >> >> = >> >> wrote: >> >> I was wondering about the required behaviour of JSON parsers >> on >> inputs >> that represent strings that are not valid JSON string (which >> are a >> sequence of zero or more Unicode characters). One such input >> is >> >> [ "\uDEAD" ] >> >> Are JSON parsers required to silently accept such inputs, an= d >> produce >> some valid JSON data, for example turning the above input in= to >> an array >> of the one-character string of the Unicode OBJECT REPLACEMEN= T >> CHARACTER >> (U+FFFC) (or something else). >> >> Or are JSON parsers required to silently accept such inputs, >> and >> produce >> an output that mirrors the input, here an array of the >> one-element >> sequence of the number 0xDEAD? >> >> Or are JSON parsers required to signal that this input is >> illegal, even >> though it matches the JSON grammar? >> >> >> This question is not about the behavior of software that use= s >> the output >> of a JSON parser, just about the required behaviour of JSON >> parsers. >> (I'm very much hoping that JSON parsers are allowed to sign= al >> that such >> inputs are illegal so that downstream software does not have >> to >> worry >> about malformed strings nor about infidelities between the >> input >> and the >> output of a JSON parser.) >> >> >> >> Peter F. Patel-Schneider >> Nuance Communications >> >> >> >> >> >> >> > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --089e012282c8c0c4b604e6c573bc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 19, 2013 at 4:30 PM, Peter F. Patel-Schneider = <pfpschneider@gmail.com> wrote:
Yeah, it's a = tricky business to achieve interoperability. =A0However, without touching o= n these issues, can JSON ever be used where the either the sending or the r= eceiving software is unknown?


It is and has been used that way for years = now. Twitter, Facebook et al do not know or care about kind of JSON process= ing library that the other end has.
As nice as it would be to straighten= these out, these potential issues haven't slowed down JSON adoption in= any meaningful way so far.

-+ Tatu +-

=A0<= /div>
On 09/19/2013 04:19 PM, Tim Bray wrote:
The RFC describes the interchange format and is entirely silent on the subj= ect of software behavior except to say that the text in question must be ac= cepted.

Getting into the business of specifying behavior, or what it is that a JSON= parser emits, is a first step onto a very long and slippery slope. Let=92s= not go there.


On Thu, Sep 19, 2013 at 4:14 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com &= lt;mailto:pfpsc= hneider@gmail.com>> wrote:

=A0 =A0 OK, {"a":"\uDEAD"} matches the grammar, so a JS= ON parser is obligated to
=A0 =A0 accept it. =A0(YUCK!)

=A0 =A0 However, what can a JSON parser produce for this input? JSON string= s are
=A0 =A0 sequences of Unicode characters, so, as I read the document, a sequ= ence
=A0 =A0 consisting of only 0xDEAD is not a JSON string, and a JSON parser t= hat
=A0 =A0 produces such an output is not compliant.

=A0 =A0 peter




=A0 =A0 On 09/19/2013 04:01 PM, Tim Bray wrote:

=A0 =A0 =A0 =A0 The RFC says the parser MUST accept it if it matches the gr= ammar,
=A0 =A0 =A0 =A0 and {"a" : "\uDEAD" } does, so it has t= o be accepted.

=A0 =A0 =A0 =A0 The -bis says that emitting such JSON will potentially lead= to
=A0 =A0 =A0 =A0 interoperability problems including downstream crashes.

=A0 =A0 =A0 =A0 I=92m not sure that anything further can be said in the con= text of our
=A0 =A0 =A0 =A0 current charter. =A0-T


=A0 =A0 =A0 =A0 On Thu, Sep 19, 2013 at 3:51 PM, Peter F. Patel-Schneider =A0 =A0 =A0 =A0 <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>
=
=A0 =A0 =A0 =A0 <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>= ;> wrote:

=A0 =A0 =A0 =A0 =A0 =A0 I was wondering about the required behaviour of JSO= N parsers on
=A0 =A0 =A0 =A0 inputs
=A0 =A0 =A0 =A0 =A0 =A0 that represent strings that are not valid JSON stri= ng (which are a
=A0 =A0 =A0 =A0 =A0 =A0 sequence of zero or more Unicode characters). One s= uch input is

=A0 =A0 =A0 =A0 =A0 =A0 [ "\uDEAD" ]

=A0 =A0 =A0 =A0 =A0 =A0 Are JSON parsers required to silently accept such i= nputs, and
=A0 =A0 =A0 =A0 produce
=A0 =A0 =A0 =A0 =A0 =A0 some valid JSON data, for example turning the above= input into
=A0 =A0 =A0 =A0 an array
=A0 =A0 =A0 =A0 =A0 =A0 of the one-character string of the Unicode OBJECT R= EPLACEMENT
=A0 =A0 =A0 =A0 CHARACTER
=A0 =A0 =A0 =A0 =A0 =A0 (U+FFFC) (or something else).

=A0 =A0 =A0 =A0 =A0 =A0 Or are JSON parsers required to silently accept suc= h inputs, and
=A0 =A0 =A0 =A0 produce
=A0 =A0 =A0 =A0 =A0 =A0 an output that mirrors the input, here an array of = the one-element
=A0 =A0 =A0 =A0 =A0 =A0 sequence of the number 0xDEAD?

=A0 =A0 =A0 =A0 =A0 =A0 Or are JSON parsers required to signal that this in= put is
=A0 =A0 =A0 =A0 illegal, even
=A0 =A0 =A0 =A0 =A0 =A0 though it matches the JSON grammar?


=A0 =A0 =A0 =A0 =A0 =A0 This question is not about the behavior of software= that uses
=A0 =A0 =A0 =A0 the output
=A0 =A0 =A0 =A0 =A0 =A0 of a JSON parser, just about the required behaviour= of JSON parsers.
=A0 =A0 =A0 =A0 =A0 =A0 =A0(I'm very much hoping that JSON parsers are = allowed to signal
=A0 =A0 =A0 =A0 that such
=A0 =A0 =A0 =A0 =A0 =A0 inputs are illegal so that downstream software does= not have to
=A0 =A0 =A0 =A0 worry
=A0 =A0 =A0 =A0 =A0 =A0 about malformed strings nor about infidelities betw= een the input
=A0 =A0 =A0 =A0 and the
=A0 =A0 =A0 =A0 =A0 =A0 output of a JSON parser.)



=A0 =A0 =A0 =A0 =A0 =A0 Peter F. Patel-Schneider
=A0 =A0 =A0 =A0 =A0 =A0 Nuance Communications







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

--089e012282c8c0c4b604e6c573bc-- From tbray@textuality.com Thu Sep 19 17:12:42 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBE221F898A for ; Thu, 19 Sep 2013 17:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77CMXm1KS5Gb for ; Thu, 19 Sep 2013 17:12:38 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id D7F3F21F89EB for ; Thu, 19 Sep 2013 17:12:37 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id if17so6765186vcb.32 for ; Thu, 19 Sep 2013 17:12:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=cRcYpAPzDL4BHunSJsuHr7PLrsD4GsQqsq8dGsnSLxo=; b=PfZpi4WA/WoWfFIkej1pW99fY1OOCBgUWoEKNXHKocFKqnv7+fXKDZWrICZ1Cn/LDp vQ4Dpe8TEHKD21LtNpKTDhOEub8RNSBFYXD7OCPTmalKP4U1K5WGWR0lu3V6QobJCQC9 rBYU5+nvPPrBHpkrlUocDIQGfyPM3n/QUuy95WYYFdUSBZR75rogZ78MuL/9/hddq4K+ HrLPsF+auJOcre589PQqbv1gPi9r+WmBNXkEpGzIIDoN9EsXulrLqOiaVrD+enb+5bzR PXeuL5X3sgBb/frRJZI5ORCoPzCZFdETAz8plzR2hXheFod3N6A+MxF8JPF7K3q9SabF 16Rg== X-Gm-Message-State: ALoCoQnDHr1BYAlA29NvN2xviyr+qlp/l7vPJ+PLm3D1vAV+3EBo2LjePokyP9pXzEK4LLhS4CWd MIME-Version: 1.0 X-Received: by 10.220.164.70 with SMTP id d6mr3420669vcy.19.1379635956966; Thu, 19 Sep 2013 17:12:36 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 19 Sep 2013 17:12:36 -0700 (PDT) X-Originating-IP: [24.84.235.32] Date: Thu, 19 Sep 2013 17:12:36 -0700 Message-ID: From: Tim Bray To: John Cowan Content-Type: multipart/alternative; boundary=047d7b414aa4227abd04e6c5877e Cc: "json@ietf.org" Subject: [Json] Code units X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 00:12:42 -0000 --047d7b414aa4227abd04e6c5877e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Sep 19, 2013 at 4:47 PM, John Cowan wrote: > There's a bug. The use of "code unit" in 8.3 is undefined unless it's > specified whether 8-bit, 16-bit, or 32-bit code units are intended > (see the Unicode glossary). I think changing the first instance to > "16-bit code units" will suffice. > Hm, section 2.5 of Unicode repeatedly uses the term =E2=80=9Ccode unit=E2= =80=9D without a bit-size prefix. And an implementation might well parse the text into wchar_t arrays, which are usually 32 bits per. So I=E2=80=99m not convince= d that the code units are *necessarily* 16-bit. And I think the text is perfectly clear. Also, the official definition isn=E2=80=99t terribly helpful: http://www.unicode.org/glossary/#code_unit > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > Be yourself. Especially do not feign a working knowledge of RDF where > no such knowledge exists. Neither be cynical about RELAX NG; for in > the face of all aridity and disenchantment in the world of markup, > James Clark is as perennial as the grass. --DeXiderata, Sean McGrath > --047d7b414aa4227abd04e6c5877e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 19, 2013 at 4:47 PM, John Cowan <cowan@m= ercury.ccil.org> wrote:
There's a bug. =C2=A0= The use of "code unit" in 8.3 is undefined unless it's
specified whether 8-bit, 16-bit, or 32-bit code units are intended
(see the Unicode glossary). =C2=A0I think changing the first instance to "16-bit code units" will suffice.

=
Hm, section 2.5 of Unicode repeatedly uses the term =E2=80=9Ccode unit= =E2=80=9D without a bit-size prefix.=C2=A0 And an implementation might well= parse the text into wchar_t arrays, which are usually 32 bits per.=C2=A0 S= o I=E2=80=99m not convinced that the code units are *necessarily* 16-bit.= =C2=A0 And I think the text is perfectly clear.

Also, the official definition isn=E2=80=99t terribly helpful: http://www.unicode.org/glos= sary/#code_unit
=C2=A0

--
John Cowan =C2=A0 =C2=A0 =C2=A0http://www.ccil.org/~cowan =C2=A0 =C2=A0 =C2=A0cowan@ccil.org
Be yourself. =C2=A0Especially do not feign a working knowledge of RDF where=
no such knowledge exists. =C2=A0Neither be cynical about RELAX NG; for in the face of all aridity and disenchantment in the world of markup,
James Clark is as perennial as the grass. =C2=A0--DeXiderata, Sean McGrath<= br>

--047d7b414aa4227abd04e6c5877e-- From paul.hoffman@vpnc.org Thu Sep 19 17:16:28 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620D321F89EB for ; Thu, 19 Sep 2013 17:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbXKImy9VEHp for ; Thu, 19 Sep 2013 17:16:28 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E8D1E21F898A for ; Thu, 19 Sep 2013 17:16:27 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8K0GNLo053625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Sep 2013 17:16:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Thu, 19 Sep 2013 17:16:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77BD8417-533F-4080-8EE2-46266EDE8E25@vpnc.org> References: To: Tim Bray X-Mailer: Apple Mail (2.1510) Cc: John Cowan , "json@ietf.org" Subject: Re: [Json] Code units X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 00:16:28 -0000 On Sep 19, 2013, at 5:12 PM, Tim Bray wrote: > On Thu, Sep 19, 2013 at 4:47 PM, John Cowan = wrote: > There's a bug. The use of "code unit" in 8.3 is undefined unless it's > specified whether 8-bit, 16-bit, or 32-bit code units are intended > (see the Unicode glossary). I think changing the first instance to > "16-bit code units" will suffice. >=20 > Hm, section 2.5 of Unicode repeatedly uses the term =93code unit=94 = without a bit-size prefix. And an implementation might well parse the = text into wchar_t arrays, which are usually 32 bits per. So I=92m not = convinced that the code units are *necessarily* 16-bit. And I think the = text is perfectly clear. The definition of "code unit" in the Unicode Standard, D77, specifically = ties the size of the unit to the encoding form. Section 8.3 is not about = a specific encoding form, and therefore I would say that it would be an = error to specify any size. --Paul Hoffman= From cowan@ccil.org Thu Sep 19 17:42:22 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D7621F866E for ; Thu, 19 Sep 2013 17:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rsfc2oIcNvL8 for ; Thu, 19 Sep 2013 17:42:18 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3F55C21F8640 for ; Thu, 19 Sep 2013 17:42:18 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VMonX-0000gb-DT; Thu, 19 Sep 2013 20:42:15 -0400 Date: Thu, 19 Sep 2013 20:42:15 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130920004215.GD9517@mercury.ccil.org> References: <77BD8417-533F-4080-8EE2-46266EDE8E25@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <77BD8417-533F-4080-8EE2-46266EDE8E25@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Code units X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 00:42:22 -0000 Paul Hoffman scripsit: > On Sep 19, 2013, at 5:12 PM, Tim Bray wrote: > > > Hm, section 2.5 of Unicode repeatedly uses the term “code unit†> > without a bit-size prefix. And an implementation might well > > parse the text into wchar_t arrays, which are usually 32 bits per. > > So I’m not convinced that the code units are *necessarily* 16-bit. > > And I think the text is perfectly clear. Either 16-bit or 32-bit code units would be fine, but 8-bit code units would not, because there is simply no representation of unpaired-surrogate code points in terms of 8-bit code units, which would render the whole section useless. I wrote "16-bit" solely for concreteness. > The definition of "code unit" in the Unicode Standard, D77, specifically > ties the size of the unit to the encoding form. Section 8.3 is not > about a specific encoding form, and therefore I would say that it > would be an error to specify any size. In that case, why not speak of code points, particularly as that term is already used in 4627 and 4627bis? -- Her he asked if O'Hare Doctor tidings sent from far John Cowan coast and she with grameful sigh him answered that http://ccil.org/~cowan O'Hare Doctor in heaven was. Sad was the man that word cowan@ccil.org to hear that him so heavied in bowels ruthful. All she there told him, ruing death for friend so young, James Joyce, Ulysses algate sore unwilling God's rightwiseness to withsay. "Oxen of the Sun" From tbray@textuality.com Thu Sep 19 17:49:02 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FC221F8415 for ; Thu, 19 Sep 2013 17:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibEgqrZr-cAQ for ; Thu, 19 Sep 2013 17:48:57 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9894F21F8698 for ; Thu, 19 Sep 2013 17:48:57 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id if17so6557493vcb.18 for ; Thu, 19 Sep 2013 17:48:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u1a5u1BrQZH+pWBjucubrC6fh3kHjSLCCBQXS+8HfhM=; b=ChSQF87+q1TbNn0Zlp/cQoQ8LCZKWRWrDjNnZgvsERvg3Khp3tIDtoLA8S/8+68wbM FnYN8+KFaNqKBkmwC6c6Xvl5/wej/4zhHkJz6nTk70iu3OGH3qPFBZigtdyXveg/V9EW B7tjFXFLe6APdCPgE/PdySOE+3FAZCicGXgkOJ9/OaWHGCWfzRg8LOJXCvYmyhOfDWIo ND4hiOviy8CicZlvdY5eyfg7mlF1cMEIgsGhOmjTja8oJzAYzZdRfO5WayHNyCt3tZjq Stz7aYs5dbWAMzT924fPuYFZM/iPn86CqMakhINuR4TyP1xTRKWobvYXMuEkiZ/+72uF wZ6A== X-Gm-Message-State: ALoCoQmG506NrbQAi6knTrXj+/6f7ihghF+kTNi8SAyqo8M6H1JHHE9BT1rCcqeCcOxn3gupfDDl MIME-Version: 1.0 X-Received: by 10.221.40.10 with SMTP id to10mr3590456vcb.22.1379638136698; Thu, 19 Sep 2013 17:48:56 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 19 Sep 2013 17:48:56 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <20130920004215.GD9517@mercury.ccil.org> References: <77BD8417-533F-4080-8EE2-46266EDE8E25@vpnc.org> <20130920004215.GD9517@mercury.ccil.org> Date: Thu, 19 Sep 2013 17:48:56 -0700 Message-ID: From: Tim Bray To: John Cowan Content-Type: multipart/alternative; boundary=001a113375760e8bfc04e6c60967 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Code units X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 00:49:02 -0000 --001a113375760e8bfc04e6c60967 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Because \uDEAD isn=E2=80=99t a code point but it is a code unit. You actua= lly have a point because if it weren=E2=80=99t for \uDEAD we could could write the discussion in terms of code points, which would be much more humane, so it=E2=80=99s only because JSON allows some particular icky non-code-point 1= 6-bit code units that we have to write about code units. But I don=E2=80=99t thin= k that the correctness of the language in the spec depends on the code units being of any particular bit-ness. On Thu, Sep 19, 2013 at 5:42 PM, John Cowan wrote: > Paul Hoffman scripsit: > > > On Sep 19, 2013, at 5:12 PM, Tim Bray wrote: > > > > > Hm, section 2.5 of Unicode repeatedly uses the term =E2=80=9Ccode uni= t=E2=80=9D > > > without a bit-size prefix. And an implementation might well > > > parse the text into wchar_t arrays, which are usually 32 bits per. > > > So I=E2=80=99m not convinced that the code units are *necessarily* 16= -bit. > > > And I think the text is perfectly clear. > > Either 16-bit or 32-bit code units would be fine, but 8-bit code units > would not, because there is simply no representation of unpaired-surrogat= e > code points in terms of 8-bit code units, which would render the whole > section useless. I wrote "16-bit" solely for concreteness. > > > The definition of "code unit" in the Unicode Standard, D77, specificall= y > > ties the size of the unit to the encoding form. Section 8.3 is not > > about a specific encoding form, and therefore I would say that it > > would be an error to specify any size. > > In that case, why not speak of code points, particularly as that term > is already used in 4627 and 4627bis? > > -- > Her he asked if O'Hare Doctor tidings sent from far John Cowan > coast and she with grameful sigh him answered that > http://ccil.org/~cowan > O'Hare Doctor in heaven was. Sad was the man that word cowan@ccil.org > to hear that him so heavied in bowels ruthful. All > she there told him, ruing death for friend so young, James Joyce, > Ulysses > algate sore unwilling God's rightwiseness to withsay. "Oxen of the Sun" > --001a113375760e8bfc04e6c60967 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Because \uDEAD isn=E2=80=99t a code point but it is a code= unit.=C2=A0 You actually have a point because if it weren=E2=80=99t for \u= DEAD we could could write the discussion in terms of code points, which wou= ld be much more humane, so it=E2=80=99s only because JSON allows some parti= cular icky non-code-point 16-bit code units that we have to write about cod= e units. But I don=E2=80=99t think that the correctness of the language in = the spec depends on the code units being of any particular bit-ness.


On Thu,= Sep 19, 2013 at 5:42 PM, John Cowan <cowan@mercury.ccil.org><= /span> wrote:
Paul Hoffman scripsit:

> On Sep 19, 2013, at 5:12 PM, Tim Bray <tbray@textuality.com> wrote:
>
> > Hm, section 2.5 of Unicode repeatedly use= s the term =E2=80=9Ccode unit=E2=80=9D
> > without a bit-size prefix. =C2=A0And an implementation might well=
> > parse the text into wchar_t arrays, which are usually 32 bits per= .
> > So I=E2=80=99m not convinced that the code units are *necessarily= * 16-bit.
> > And I think the text is perfectly clear.

Either 16-bit or 32-bit code units would be fine, but 8-bit code unit= s
would not, because there is simply no representation of unpaired-surrogate<= br> code points in terms of 8-bit code units, which would render the whole
section useless. =C2=A0I wrote "16-bit" solely for concreteness.<= br>

> The definition of "code unit" in the Unicode Standard, D77, = specifically
> ties the size of the unit to the encoding form. Section 8.3 is not
> about a specific encoding form, and therefore I would say that it
> would be an error to specify any size.

In that case, why not speak of code points, particularly as that term=
is already used in 4627 and 4627bis?

--
Her he asked if O'Hare Doctor tidings sent from far =C2=A0 =C2=A0 John = Cowan
coast and she with grameful sigh him answered that =C2=A0 =C2=A0 =C2=A0http://ccil.org/~cowan=
O'Hare Doctor in heaven was. Sad was the man that word =C2=A0cowan@ccil.org
to hear that him so heavied in bowels ruthful. =C2=A0All
she there told him, ruing death for friend so young, =C2=A0 =C2=A0James Joy= ce, Ulysses
algate sore unwilling God's rightwiseness to withsay. =C2=A0 "Oxen= of the Sun"

--001a113375760e8bfc04e6c60967-- From jwilson@squareup.com Thu Sep 19 18:29:30 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D603121F8445 for ; Thu, 19 Sep 2013 18:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.223 X-Spam-Level: * X-Spam-Status: No, score=1.223 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3J22s9-p+Tfx for ; Thu, 19 Sep 2013 18:29:30 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0026821F8443 for ; Thu, 19 Sep 2013 18:29:29 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id cb5so8789210wib.15 for ; Thu, 19 Sep 2013 18:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=squareup.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=UbYJlVtlQyjKiNEmYRwFQ1ylF0PpM9thppRrtVvFNek=; b=D/c+dzcg87rJ9dJqw8XoGNvDc42k24GxhYggmnWugwSyl4jxyxQXSul5MPkzBegXGS zWtS+U1leVzxHu5tC5Or5WDhCPrB5Cl4YHCN/XDcbl+mUo5ypWIhG30yA9SFgq3adSuf KXbRrxwAT7yA50heY4NSq+5Xxf6dRw3g75ufI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=UbYJlVtlQyjKiNEmYRwFQ1ylF0PpM9thppRrtVvFNek=; b=h+/U2I4/CIt1O7iPODfAoibonSA75wL4t0WkhDaz5MYKYC+4+936VJ1pxzOIYqACEW 4hsmXhqn4uZIcAVvm3NMm+roJNEG1LG0t4pX2Ax951T6sDl6FbXB39DZuPI+zPfPW1f5 jaaJxoKLQmuUt0kFnyJ1I2FcADakveK81Eq4LRCFpLX/E5Q/NohZpDx7KN1jivXfwAey 6r/bJmQuc1E3HRZ6PXdvSU71KjjCJEoYM+haiqHSuiifAhmaRZbSI9FwNOreTo6eqmdV v/UI72LyQB1SW8QnWhi0yRx8BkthlSLnS4pbgwPRgnuc1ZaI3/5tu2HXrqcZE6dV7iaM MQPA== X-Gm-Message-State: ALoCoQkhKecX7t6tNUsXd9KlYcA6myiLoeSFO/M2a+bNNd3NZpKvNhrKxtbp25mGDQsPEqTkb8BB MIME-Version: 1.0 X-Received: by 10.180.198.79 with SMTP id ja15mr680301wic.36.1379640568991; Thu, 19 Sep 2013 18:29:28 -0700 (PDT) Received: by 10.194.122.197 with HTTP; Thu, 19 Sep 2013 18:29:28 -0700 (PDT) Received: by 10.194.122.197 with HTTP; Thu, 19 Sep 2013 18:29:28 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Sep 2013 21:29:28 -0400 Message-ID: From: jwilson To: json@ietf.org Content-Type: multipart/alternative; boundary=047d7b6242520864fc04e6c69a6e X-Mailman-Approved-At: Thu, 19 Sep 2013 18:43:03 -0700 Subject: [Json] JSON comments /* ... */ and // ... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 01:31:52 -0000 --047d7b6242520864fc04e6c69a6e Content-Type: text/plain; charset=UTF-8 Several popular JSON libraries I've used permit comments in messages. Jackson supports comments with its Feature.ALLOW_COMMENTS flag, Gson supports them with setLenient(true) and the org.json Java parser accepts them by default. Here's my best description of how comments work in practice: There are two kinds of comments used by JSON: /*multiline comment terminated by asterix slash*/ //single line comment terminated by \r\n or \r or \n Zero or more comments may occur wherever ignorable whitespace occurs. The processors ignore comments in the same way they do ignorable whitespace. Comments do not nest. Unlike many XML processors, JSON processors do not attempt to provide character-for-character fidelity for modeled documents. The document model does not typically retain or emit comments. Comments are useful in manually edited documents. For example, here's a JSON file for configuring an application: { "country_whitelist": [ "CA", "US", // Japan & France haven't launched yet // "JP", // "FR", "GB", // (United Kingdom) "BR" ] } Note that comments are used to both document the content as well as to suppress it. Can we include this in the new spec? Thanks! --047d7b6242520864fc04e6c69a6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Several popular JSON libraries I've used permit comments= in messages. Jackson supports comments with its Feature.ALLOW_COMMENTS fla= g, Gson supports them with setLenient(true) and the org.json Java parser ac= cepts them by default.

Here's my best description of how comments work in pract= ice:

There are two kinds of comments used by JSON:

/*multiline comment terminated by asterix slash*/

//single line comment terminated by \r\n or \r or \n

Zero or more comments may occur wherever ignorable whitespac= e occurs. The processors ignore comments in the same way they do ignorable = whitespace. Comments do not nest.

Unlike many XML processors, JSON processors do not attempt t= o provide character-for-character fidelity for modeled documents. The docum= ent model does not typically retain or emit comments.

Comments are useful in manually edited documents. For exampl= e, here's a JSON file for configuring an application:

{
=C2=A0 "country_whitelist": [
=C2=A0=C2=A0=C2=A0 "CA",
=C2=A0=C2=A0=C2=A0 "US",
=C2=A0=C2=A0=C2=A0 // Japan & France haven't launched yet
=C2=A0=C2=A0=C2=A0 // "JP",
=C2=A0=C2=A0=C2=A0 // "FR",
=C2=A0=C2=A0=C2=A0 "GB", // (United Kingdom)
=C2=A0=C2=A0=C2=A0 "BR"
=C2=A0 ]
}

Note that comments are used to both document the content as = well as to suppress it.

Can we include this in the new spec?

Thanks!

--047d7b6242520864fc04e6c69a6e-- From cowan@ccil.org Thu Sep 19 19:10:14 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F0421F867B for ; Thu, 19 Sep 2013 19:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rlVlUa1cyzB for ; Thu, 19 Sep 2013 19:10:10 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7873221F8640 for ; Thu, 19 Sep 2013 19:10:10 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VMqAa-0001To-0I; Thu, 19 Sep 2013 22:10:08 -0400 Date: Thu, 19 Sep 2013 22:10:07 -0400 From: John Cowan To: Tim Bray Message-ID: <20130920021007.GE9517@mercury.ccil.org> References: <77BD8417-533F-4080-8EE2-46266EDE8E25@vpnc.org> <20130920004215.GD9517@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Code units X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 02:10:15 -0000 Tim Bray scripsit: > Because \uDEAD isn’t a code point but it is a code unit. You have a hold of the right spade, but you are calling it a shovel. The integer 0xDEAD = 57005: 0) does not represent a character; 1) is not a Unicode scalar value (USV) (integer in the range 0-0xD7FF or 0xE000-0x10FFFF); 2) is a code point (integer in the range 0-0x10FFFF); 3) is a 32-bit code unit (integer in the range 0-0x10FFFF); 4) is a 16-bit code unit (integer in the range 0-0xFFFF); 5) is not an 8-bit code unit (integer in the range 0-0xFF) and cannot be represented as a valid sequence of 8-bit code units either. > [I]f it weren’t for \uDEAD we could could write the discussion in > terms of code points, which would be much more humane, If it weren't for \uDEAD we could write the discussion in terms of Unicode scalar values or characters, which *would* be much more humane. Since we do have to account for \uDEAD, we have to use code points, 16-bit code units, or 32-bit code units. > it’s only because JSON allows some particular icky non-code-point 16-bit > code units that we have to write about code units. It's only because JSON allows some particular icky non-USV code points that we have to write about code points or 16-bit code units or 32-bit code units rather than USVs or characters. -- They tried to pierce your heart John Cowan with a Morgul-knife that remains in the http://www.ccil.org/~cowan wound. If they had succeeded, you would become a wraith under the domination of the Dark Lord. --Gandalf From sayrer@gmail.com Thu Sep 19 19:16:39 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61FD21F871B for ; Thu, 19 Sep 2013 19:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPl-V3zEYroM for ; Thu, 19 Sep 2013 19:16:38 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 74B0021F8415 for ; Thu, 19 Sep 2013 19:16:38 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id k4so84547qaq.18 for ; Thu, 19 Sep 2013 19:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+smbmSIEmJIbDkydUVmVbB8XrdI1Q/foUK0VLPokF/Y=; b=0GjGvWyz6L1mNZINxFhgAJGDWb0Fnz+H8PJeFlys0r1rYr4ezoMLiH3vQbfH11CBa7 /kdnJYIX8Gsq8vAjCzISP+OtBEhrjKG7W0kwFYvA2Y7wWdzd3bRz5S2KIqpWkdMEW4fW qqFfzkWp3t44D5F7e+Xp2juJVgDRnHraaOqp+32VS9lvN0GvGbVGcUEQFUYUpQNfYafu 2NG47ssbhaIHRr1gBSvBAzhq4XJlrRr/CNACxQb9ng18qONH3yU+fMgBXfWRqknvDNZ4 6vIKJlqfdj7nVb1qrYLOR9Twg+XTwwzz03gUqe9pGS4NH1FuCd3MlDs3oCCRC/Yd3jyq vZjg== MIME-Version: 1.0 X-Received: by 10.224.12.76 with SMTP id w12mr2306677qaw.99.1379643397716; Thu, 19 Sep 2013 19:16:37 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Thu, 19 Sep 2013 19:16:37 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Thu, 19 Sep 2013 19:16:37 -0700 (PDT) In-Reply-To: <20130920021007.GE9517@mercury.ccil.org> References: <77BD8417-533F-4080-8EE2-46266EDE8E25@vpnc.org> <20130920004215.GD9517@mercury.ccil.org> <20130920021007.GE9517@mercury.ccil.org> Date: Thu, 19 Sep 2013 19:16:37 -0700 Message-ID: From: R S To: John Cowan Content-Type: multipart/alternative; boundary=089e01537288a3458a04e6c7423b Cc: Tim Bray , Paul Hoffman , json@ietf.org Subject: Re: [Json] Code units X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 02:16:39 -0000 --089e01537288a3458a04e6c7423b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable What if we left Unicode specifics out of the spec? The current RFC is actually OK, otherwise JSON wouldn't work. This thread is veering into Unicode conformance, which is not controlled by JSON implementors, in general. - Rob On Sep 19, 2013 7:10 PM, "John Cowan" wrote: > Tim Bray scripsit: > > > Because \uDEAD isn=92t a code point but it is a code unit. > > You have a hold of the right spade, but you are calling it a shovel. > The integer 0xDEAD =3D 57005: > > 0) does not represent a character; > > 1) is not a Unicode scalar value (USV) (integer in the range 0-0xD7FF > or 0xE000-0x10FFFF); > > 2) is a code point (integer in the range 0-0x10FFFF); > > 3) is a 32-bit code unit (integer in the range 0-0x10FFFF); > > 4) is a 16-bit code unit (integer in the range 0-0xFFFF); > > 5) is not an 8-bit code unit (integer in the range 0-0xFF) and cannot > be represented as a valid sequence of 8-bit code units either. > > > [I]f it weren=92t for \uDEAD we could could write the discussion in > > terms of code points, which would be much more humane, > > If it weren't for \uDEAD we could write the discussion in terms of > Unicode scalar values or characters, which *would* be much more humane. > Since we do have to account for \uDEAD, we have to use code points, > 16-bit code units, or 32-bit code units. > > > it=92s only because JSON allows some particular icky non-code-point 16-= bit > > code units that we have to write about code units. > > It's only because JSON allows some particular icky non-USV code points > that we have to write about code points or 16-bit code units or 32-bit > code units rather than USVs or characters. > > -- > They tried to pierce your heart John Cowan > with a Morgul-knife that remains in the http://www.ccil.org/~cowa= n > wound. If they had succeeded, you would > become a wraith under the domination of the Dark Lord. --Gandalf > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e01537288a3458a04e6c7423b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

What if we left Unicode specifics out of the spec? The curre= nt RFC is actually OK, otherwise JSON wouldn't work.

This thread is veering into Unicode conformance, which is no= t controlled by JSON implementors, in general.

- Rob

On Sep 19, 2013 7:10 PM, "John Cowan" = <cowan@mercury.ccil.org>= ; wrote:
Tim Bray scripsit:

> Because \uDEAD isn=92t a code point but it is a code unit.

You have a hold of the right spade, but you are calling it a shovel.
The integer 0xDEAD =3D 57005:

0) does not represent a character;

1) is not a Unicode scalar value (USV) (integer in the range 0-0xD7FF
or 0xE000-0x10FFFF);

2) is a code point (integer in the range 0-0x10FFFF);

3) is a 32-bit code unit (integer in the range 0-0x10FFFF);

4) is a 16-bit code unit (integer in the range 0-0xFFFF);

5) is not an 8-bit code unit (integer in the range 0-0xFF) and cannot
be represented as a valid sequence of 8-bit code units either.

> [I]f it weren=92t for \uDEAD we could could write the discussion in > terms of code points, which would be much more humane,

If it weren't for \uDEAD we could write the discussion in terms of
Unicode scalar values or characters, which *would* be much more humane.
Since we do have to account for \uDEAD, we have to use code points,
16-bit code units, or 32-bit code units.

> it=92s only because JSON allows some particular icky non-code-point 16= -bit
> code units that we have to write about code units.

It's only because JSON allows some particular icky non-USV code points<= br> that we have to write about code points or 16-bit code units or 32-bit
code units rather than USVs or characters.

--
They tried to pierce your heart =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 John Cowan<= br> with a Morgul-knife that remains in the =A0 =A0 =A0 =A0 http://www.ccil.org/~cowan
wound. =A0If they had succeeded, you would
become a wraith under the domination of the Dark Lord. =A0 =A0 =A0 =A0 --Ga= ndalf
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json
--089e01537288a3458a04e6c7423b-- From mamille2@cisco.com Thu Sep 19 19:27:54 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9328721F8546 for ; Thu, 19 Sep 2013 19:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvGBg9enno3x for ; Thu, 19 Sep 2013 19:27:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D63D521F860A for ; Thu, 19 Sep 2013 19:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7808; q=dns/txt; s=iport; t=1379644069; x=1380853669; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=F8KmvJEMnjWc5J8xg0vyVfILPE2WFWgTohR3CHGmtJ0=; b=a4MmnBkTwtY1YdKzSX5yTVCvwm3riwqI0doZntsXwYgYbkcIP9eKOW8T TeRA923uk5XO70XCebwoZPeFyazQpOEK0tuNS3uQkJIYkyrWzvzeIPwCv SDDeyuTw3HJsdFtQ6MF4JHWkD3DVVNtOPL0XJDyxlIYo9Zd4eSTjVPjSq 0=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAJqxO1KtJXG8/2dsb2JhbABbgweBCsExgSAWdIIlAQEBAwF5BQsCAQgiJAIwJQIEDgUIBodvBro+jzYxB4MegQADkCaBL5gcgySCKg X-IronPort-AV: E=Sophos;i="4.90,941,1371081600"; d="p7s'?scan'208";a="262197277" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 20 Sep 2013 02:27:48 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8K2RmWk003954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Sep 2013 02:27:48 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.253]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 19 Sep 2013 21:27:48 -0500 From: "Matt Miller (mamille2)" To: jwilson Thread-Topic: [Json] JSON comments /* ... */ and // ... Thread-Index: AQHOtaL6LHy0QBh6tkGUlsjU8JkeopnOOoaA Date: Fri, 20 Sep 2013 02:27:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.93.226] Content-Type: multipart/signed; boundary="Apple-Mail=_29AF6AAE-3D20-415E-A2A2-E609CA94DAC0"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [Json] JSON comments /* ... */ and // ... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 02:27:54 -0000 --Apple-Mail=_29AF6AAE-3D20-415E-A2A2-E609CA94DAC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 19, 2013, at 7:29 PM, jwilson wrote: > Several popular JSON libraries I've used permit comments in messages. = Jackson supports comments with its Feature.ALLOW_COMMENTS flag, Gson = supports them with setLenient(true) and the org.json Java parser accepts = them by default. >=20 > Here's my best description of how comments work in practice: >=20 > There are two kinds of comments used by JSON: >=20 > /*multiline comment terminated by asterix slash*/ >=20 > //single line comment terminated by \r\n or \r or \n >=20 > Zero or more comments may occur wherever ignorable whitespace occurs. = The processors ignore comments in the same way they do ignorable = whitespace. Comments do not nest. >=20 > Unlike many XML processors, JSON processors do not attempt to provide = character-for-character fidelity for modeled documents. The document = model does not typically retain or emit comments. >=20 > Comments are useful in manually edited documents. For example, here's = a JSON file for configuring an application: >=20 > { > "country_whitelist": [ > "CA", > "US", > // Japan & France haven't launched yet > // "JP", > // "FR", > "GB", // (United Kingdom) > "BR" > ] > } >=20 > Note that comments are used to both document the content as well as to = suppress it. >=20 > Can we include this in the new spec? >=20 > Thanks! >=20 /me dons hat Thank you for your contribution, but it cannot be accepted. This = contribution does not fit within the bounds of the Working Group = charter, as it does not correct a significant error or inconsistency. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_29AF6AAE-3D20-415E-A2A2-E609CA94DAC0 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5MjAwMjI3 NDZaMCMGCSqGSIb3DQEJBDEWBBRyUWFlvOwOksvbwlf4RPjsf3dOEzCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAHss AlEsSXVfLJJFPLYz4OPnwMIuJjXTwIBfJXY2ggoo5hL8XM9FUAHD1YjgqKqreT62od9gSzIUeTuP vRRTLemvD4WdBVP7vz1bjqdObMiN64DSjXr1WfWKJeRs5DtPdjj9KO0C2UNabdbKPeRc1vPWHlhm fyFCD5P5jgD5/GPGa6s8fYFN88GIlR10AxPp4aeXaV643H73Uihbqm2NBlzdN59nv1ED1wP/oKVS dMMQx6t+b+UOvAko3or3TBgB8OlyQGWOymAf+0pY6KuuaPz0/D7XFAqwh7s4Lo45Cwf6kYrZESej B0029OWK+Hw5yBPjYsJsOt+uBQwZ3Ykp0CEAAAAAAAA= --Apple-Mail=_29AF6AAE-3D20-415E-A2A2-E609CA94DAC0-- From jwilson@squareup.com Thu Sep 19 19:46:48 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDDF21F85C9 for ; Thu, 19 Sep 2013 19:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6t7-j76TMwn for ; Thu, 19 Sep 2013 19:46:47 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id BE9DF21F847C for ; Thu, 19 Sep 2013 19:46:45 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hn9so6493848wib.11 for ; Thu, 19 Sep 2013 19:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=squareup.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CKRrTOtbFtpNbdayF0P+SsOWvKVkoI3vYHF4P1Ah+F4=; b=Jho+2Z4sOZdWNs5VstUmOn/3N//Nx5oCrWfGTFTs8iG44tjUcTgCU4p0a7vESHcS9A Ou3fqjO4K3aoJHWXszR8TOSsyMX+eDxbnjRteSHJsO3xGMrYsChxt0xumr5j4V1F0EqF 5TuiEFWl7/vGkhRsbITbVKYSNEmkxzbdqD3bE= 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=CKRrTOtbFtpNbdayF0P+SsOWvKVkoI3vYHF4P1Ah+F4=; b=fV0x3Pkw4OkjVvcOm0lPR/nTb+9B5Hn9M51VxE9MtEk2FZ70PO/1T5Xj0d0T4ijCBo pwNpvzN65X006OOYNY5V8Ck7KpiJO7+gJMRCZraHK87fQdCXCpt/ObyYzocRHR0+W1hQ Ag3YSzvCPGmedR2VjocgOsW+y+O+c9nnzPk27v6AnHxJLGr0Ld1jW2VwJKcNjVlMRKNe baY151c19p6Oi3ucItbEro7J/2/0G7HwFNb85v7gV4SNmPQfv75/ZzQmFm2hN4Hm7Vxn Vkq7QibK7tL/NTz9i9djAB9WhJaogXjIw2mwIn0fiiGKiKR/4ig11m9vB4EoI3aIVdoi 4scA== X-Gm-Message-State: ALoCoQl8SzYa5w/vfQAZKuMIoEmMCfqaO5winy9fE9irjvan6U65aVdVy/ToKNoHCfgV5xjsaIO9 X-Received: by 10.180.20.77 with SMTP id l13mr857989wie.40.1379645205138; Thu, 19 Sep 2013 19:46:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.122.197 with HTTP; Thu, 19 Sep 2013 19:46:24 -0700 (PDT) In-Reply-To: References: From: jwilson Date: Thu, 19 Sep 2013 22:46:24 -0400 Message-ID: To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=bcaec53f346f5e631904e6c7ae07 Cc: "" Subject: Re: [Json] JSON comments /* ... */ and // ... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 02:46:48 -0000 --bcaec53f346f5e631904e6c7ae07 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Real JSON in the wild has comments. Real JSON processors handle these comments. The hypothetical JSON in draft-ietf-json-rfc4627bis-03 doesn=E2=80=98t incl= ude the word =E2=80=99comment' or acknowledge that comments exist. This is not an inconsistency? If it isn't, we may need a new document "Real world JSON" that admits that comments exist and offers advice on how to handle them! --bcaec53f346f5e631904e6c7ae07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Real JSON in t= he wild has comments. Real JSON processors handle these comments.

The hypothetical JSON in draft-ietf-json-rfc4627bis-03 doesn=E2= =80=98t include the word =E2=80=99comment' or acknowledge that comments= exist. This is not an inconsistency? If it isn't, we may need a new do= cument "Real world JSON" that admits that comments exist and offe= rs advice on how to handle them!

--bcaec53f346f5e631904e6c7ae07-- From James.H.Manger@team.telstra.com Thu Sep 19 19:49:49 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEDB21F85C9 for ; Thu, 19 Sep 2013 19:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[AWL=-2.424, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lACxvboO5JAA for ; Thu, 19 Sep 2013 19:49:38 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6B31C21F847C for ; Thu, 19 Sep 2013 19:49:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,941,1371045600"; d="scan'208";a="160580927" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 20 Sep 2013 12:49:35 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7203"; a="159894739" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcdvi.tcif.telstra.com.au with ESMTP; 20 Sep 2013 12:49:35 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Fri, 20 Sep 2013 12:49:35 +1000 From: "Manger, James H" To: Tim Bray , John Cowan Date: Fri, 20 Sep 2013 12:49:34 +1000 Thread-Topic: [Json] Code units Thread-Index: Ac61mzeRg/eWfgFuSA+9SrIHcRMNRgADqxFA Message-ID: <255B9BB34FB7D647A506DC292726F6E11530F69308@WSMSG3153V.srv.dir.telstra.com> References: <77BD8417-533F-4080-8EE2-46266EDE8E25@vpnc.org> <20130920004215.GD9517@mercury.ccil.org> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Code units X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 02:49:49 -0000 PiBCZWNhdXNlIFx1REVBRCBpc27igJl0IGEgY29kZSBwb2ludCBidXQgaXQgaXMgYSBjb2RlIHVu aXQuDQoNCkJ1dCBzZWN0aW9uIDguMy4gIlN0cmluZyBDb21wYXJpc29uIiB0YWxrcyBhYm91dCBp bXBsZW1lbnRhdGlvbnMgdGhhdCAiYXJlIGludGVyb3BlcmFibGUiLiBDb21wYXJpc29uIGlzIG5v dCBpbnRlcm9wZXJhYmxlIGZvciAiXHVERUFEIiBzbyBpdCBkb2VzIG5vdCBoYXZlIHRvIGJlIGFj Y29tbW9kYXRlZCBpbiB0aGlzIHNlbnRlbmNlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBJbXBsZW1lbnRhdGlvbnMgd2hpY2ggdHJhbnNmb3JtIHRoZQkNCiAJICAg dGV4dHVhbCByZXByZXNlbnRhdGlvbiBpbnRvIHNlcXVlbmNlcyBvZiBVbmljb2RlIGNvZGUgdW5p dHMsIGFuZCB0aGVuCQ0KIAkgICBwZXJmb3JtIHRoZSBjb21wYXJpc29uIG51bWVyaWNhbGx5LCBj b2RlIHVuaXQgYnkgY29kZSB1bml0LCBhcmUJDQogCSAgIGludGVyb3BlcmFibGUgaW4gdGhlIHNl bnNlIHRoYXQgaW1wbGVtZW50YXRpb25zIHdpbGwgYWdyZWUgaW4gYWxsCQ0KIAkgICBjYXNlcyBv biBlcXVhbGl0eSBvciBpbmVxdWFsaXR5IG9mIHR3byBzdHJpbmdzLg0KDQpJIHRoaW5rIHRoZSBj b3JyZWN0IGZpeCBpcyB0byBjaGFuZ2UgImNvZGUgdW5pdCIgdG8gInNjYWxhciB2YWx1ZSIgaW4g dGhpcyBzZW50ZW5jZS4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From duerst@it.aoyama.ac.jp Thu Sep 19 19:55:20 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B5121F85E8 for ; Thu, 19 Sep 2013 19:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.96 X-Spam-Level: X-Spam-Status: No, score=-105.96 tagged_above=-999 required=5 tests=[AWL=-2.170, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9PA2-3HafYj for ; Thu, 19 Sep 2013 19:55:13 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6375621F85F5 for ; Thu, 19 Sep 2013 19:55:12 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8K2t7Cp004937; Fri, 20 Sep 2013 11:55:07 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 1b9d_69b5_0eac9720_21a0_11e3_aded_001e6722eec2; Fri, 20 Sep 2013 11:55:07 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 19B46BF54F; Fri, 20 Sep 2013 11:55:07 +0900 (JST) Message-ID: <523BB8F9.4060901@it.aoyama.ac.jp> Date: Fri, 20 Sep 2013 11:54:49 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John Cowan References: <77BD8417-533F-4080-8EE2-46266EDE8E25@vpnc.org> <20130920004215.GD9517@mercury.ccil.org> <20130920021007.GE9517@mercury.ccil.org> In-Reply-To: <20130920021007.GE9517@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Code units X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 02:55:20 -0000 There has just be an extensive discussion on the Unicode list about=20 terms such as "code unit", "code point" and "Unicode scalar value"=20 including experts and references to the standard that confirms John's=20 points below. Regards, Martin. On 2013/09/20 11:10, John Cowan wrote: > Tim Bray scripsit: > >> Because \uDEAD isn=E2=80=99t a code point but it is a code unit. > > You have a hold of the right spade, but you are calling it a shovel. > The integer 0xDEAD =3D 57005: > > 0) does not represent a character; > > 1) is not a Unicode scalar value (USV) (integer in the range 0-0xD7FF > or 0xE000-0x10FFFF); > > 2) is a code point (integer in the range 0-0x10FFFF); > > 3) is a 32-bit code unit (integer in the range 0-0x10FFFF); > > 4) is a 16-bit code unit (integer in the range 0-0xFFFF); > > 5) is not an 8-bit code unit (integer in the range 0-0xFF) and cannot > be represented as a valid sequence of 8-bit code units either. > >> [I]f it weren=E2=80=99t for \uDEAD we could could write the discussion= in >> terms of code points, which would be much more humane, > > If it weren't for \uDEAD we could write the discussion in terms of > Unicode scalar values or characters, which *would* be much more humane. > Since we do have to account for \uDEAD, we have to use code points, > 16-bit code units, or 32-bit code units. > >> it=E2=80=99s only because JSON allows some particular icky non-code-po= int 16-bit >> code units that we have to write about code units. > > It's only because JSON allows some particular icky non-USV code points > that we have to write about code points or 16-bit code units or 32-bit > code units rather than USVs or characters. > From James.H.Manger@team.telstra.com Thu Sep 19 20:31:03 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC76821F85E3 for ; Thu, 19 Sep 2013 20:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=-1.616, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njuGy7pLIunF for ; Thu, 19 Sep 2013 20:30:57 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 783D921F8424 for ; Thu, 19 Sep 2013 20:30:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,941,1371045600"; d="scan'208";a="160594425" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 20 Sep 2013 13:30:52 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7203"; a="160916575" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcbvi.tcif.telstra.com.au with ESMTP; 20 Sep 2013 13:30:52 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Fri, 20 Sep 2013 13:30:51 +1000 From: "Manger, James H" To: "json@ietf.org" Date: Fri, 20 Sep 2013 13:30:50 +1000 Thread-Topic: 8.2. "A JSON text which is composed entirely of Unicode characters" Thread-Index: Ac61sc3m7D9VWjvaQBKJuQCtoUK5CQ== Message-ID: <255B9BB34FB7D647A506DC292726F6E11531058CC4@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Json] 8.2. "A JSON text which is composed entirely of Unicode characters" X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 03:31:04 -0000 U2VjdGlvbiA4LjIuICJVbmljb2RlIENoYXJhY3RlcnMiIG9mIGRyYWZ0LWlldGYtanNvbi1yZmM0 NjI3YmlzLTAzIHNheXMgSlNPTiB0ZXh0IGlzIGludGVyb3BlcmFibGUgd2hlbiBpdCBpcyAiY29t cG9zZWQgZW50aXJlbHkgb2YgVW5pY29kZSBjaGFyYWN0ZXJzIi4NCg0KVGhpcyBpcyBwb29ybHkg d29yZGVkLiB7IlxERUFEIjoxfSBpcyBhIEpTT04gdGV4dCBjb21wb3NlZCBvZiAxMSBjaGFyYWN0 ZXJzIOKAlCBhbGwgMTEgb2Ygd2hpY2ggYXJlIFVuaWNvZGUgY2hhcmFjdGVycyDigJQgYnV0IGl0 IGlzIE5PVCBpbnRlcm9wZXJhYmxlLg0KDQpQcmVzdW1hYmx5IHdlIHdhbnQgdG8gc2F5IHRoYXQg aWYgYWxsIHRoZSBsb2dpY2FsIHN0cmluZ3MgdGhhdCBhcmUgcmVwcmVzZW50ZWQgaW4gYSBKU09O IHRleHQgYXJlIGNvbXBvc2VkIGVudGlyZWx5IG9mIFVuaWNvZGUgY2hhcmFjdGVycyB0aGVuIGl0 IGlzIGludGVyb3BlcmFibGUuDQoNCg0KU3VnZ2VzdGlvbjogbW9kaWZ5IHRoZSBmaXJzdCBzZW50 ZW5jZSBvZiA4LjMgdG86DQoNCiAgIFdoZW4gYWxsIHRoZSBzdHJpbmdzIHJlcHJlc2VudGVkIGlu IGEgSlNPTiB0ZXh0IGFyZSBjb21wb3NlZA0KICAgZW50aXJlbHkgb2YgVW5pY29kZSBjaGFyYWN0 ZXJzIFtVTklDT0RFXSAoaG93ZXZlciBlc2NhcGVkKSwNCiAgIHRoZW4gdGhhdCBKU09OIHRleHQg aXMgaW50ZXJvcGVyYWJsZSBpbiB0aGUgc2Vuc2UgdGhhdCBhbGwNCiAgIHNvZnR3YXJlIGltcGxl bWVudGF0aW9ucyB3aGljaCBwYXJzZSBpdCB3aWxsIGFncmVlIG9uIHRoZSBjb250ZW50cy4NCg0K DQpQLlMuIFRoaXMgc2VudGVuY2UgYWxzbyBkcm9wcyB0aGUgbGFzdCBsaW5lIGFzIGltcGxlbWVu dGF0aW9ucyB3aWxsDQphZ3JlZSBvbiBhcnJheSBpdGVtcyBldGMsIG5vdCBqdXN0IG9iamVjdCBt ZW1iZXJzLg0KDQoNCltGb3IgY29tcGFyaXNvbiwgdGhlIGRyYWZ0IDMgc2VudGVuY2UgaXM6DQoN CiAgIEEgSlNPTiB0ZXh0IHdoaWNoIGlzIGNvbXBvc2VkIGVudGlyZWx5IG9mIFVuaWNvZGUgY2hh cmFjdGVycw0KICAgW1VOSUNPREVdIChob3dldmVyIGVuY29kZWQpIGlzIGludGVyb3BlcmFibGUg aW4gdGhlIHNlbnNlIHRoYXQgYWxsDQogICBzb2Z0d2FyZSBpbXBsZW1lbnRhdGlvbnMgd2hpY2gg cGFyc2UgaXQgd2lsbCBhZ3JlZSBvbiB0aGUgY29udGVudHMgb2YNCiAgIG5hbWVzIGFuZCB2YWx1 ZXMgb2Ygb2JqZWN0IG1lbWJlcnMuIF0NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCg== From tbray@textuality.com Thu Sep 19 20:35:43 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA20F21F8528 for ; Thu, 19 Sep 2013 20:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMSiB0mdn0sa for ; Thu, 19 Sep 2013 20:35:31 -0700 (PDT) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 72AE721F8447 for ; Thu, 19 Sep 2013 20:35:31 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id db12so7385324veb.22 for ; Thu, 19 Sep 2013 20:35:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5zzbLIcp/l97HpB/0l0PP++Vz87CNLo6HL/Vj7hvKSU=; b=jZcTm3l4LicqVPjnkAj7PmysDzjTQ/0ZwbFe63ykIOdGeDKE5MIgkyhJWQVgOoTHIQ M0WYvc9RrEkojJ8uyvASMf7fqBypLdTV5tfaohFxx4F25UN597kGVDFiImnVZCxOcW8P mcgU1h1ZrHlzahgY4EO47cPGbj2KK/k6xuwI1rA00jjpJoHY9k4p5dwsG5aIzz3PilWK J4kiQOkoWZXXGqab4BVLDAIW6A4H66OEs4zeQe56DHwRFo4gBdNAF9KFtF61LgJqTTpJ WwGCugm6dnKGBN6LkJIdOO6q/inA9J0splyrviEoRqaq7c5XCJPD9nARBMbwRX/0rl02 72xg== X-Gm-Message-State: ALoCoQlxfHcjjhDO6Vv+c+5piM/qT0w21Zvz3IcPgmH+zdlhqj+h9252pedl893bVsNiVjsFKp+u MIME-Version: 1.0 X-Received: by 10.52.122.68 with SMTP id lq4mr3554629vdb.21.1379648130859; Thu, 19 Sep 2013 20:35:30 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 19 Sep 2013 20:35:30 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11530F69308@WSMSG3153V.srv.dir.telstra.com> References: <77BD8417-533F-4080-8EE2-46266EDE8E25@vpnc.org> <20130920004215.GD9517@mercury.ccil.org> <255B9BB34FB7D647A506DC292726F6E11530F69308@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 19 Sep 2013 20:35:30 -0700 Message-ID: From: Tim Bray To: "Manger, James H" Content-Type: multipart/alternative; boundary=089e013a0c88c1576504e6c85ca9 Cc: John Cowan , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Code units X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 03:35:43 -0000 --089e013a0c88c1576504e6c85ca9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Sep 19, 2013 at 7:49 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > > > I think the correct fix is to change "code unit" to "scalar value" in thi= s > sentence. > I am wide open to arguments as to what words we should use to refer to the integers that we parse out of JSON strings and then use in comparison, but they should be backed up by specific arguments from scripture^H^H^H^H^H^H^H^H^H the Unicode standard. I think =E2=80=9Ccode un= it=E2=80=9D is plausible on that basis but we=E2=80=99re prepared to be convinced that the= re=E2=80=99s a better alternative. > > -- > James Manger > --089e013a0c88c1576504e6c85ca9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 19, 2013 at 7:49 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote:


I think the correct fix is to change "code unit" to "scalar = value" in this sentence.

I am wide= open to arguments as to what words we should use to refer to the integers = that we parse out of JSON strings and then use in comparison, but they shou= ld be backed up by specific arguments from scripture^H^H^H^H^H^H^H^H^H the = Unicode standard.=C2=A0 I think =E2=80=9Ccode unit=E2=80=9D is plausible on= that basis but we=E2=80=99re prepared to be convinced that there=E2=80=99s= a better alternative.
=C2=A0

--
James Manger

--089e013a0c88c1576504e6c85ca9-- From tbray@textuality.com Thu Sep 19 20:54:12 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC66621F8447 for ; Thu, 19 Sep 2013 20:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGOLPZUWzOSP for ; Thu, 19 Sep 2013 20:54:08 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3B721F841B for ; Thu, 19 Sep 2013 20:54:07 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id jx11so7418134veb.7 for ; Thu, 19 Sep 2013 20:54:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gDSjy6HrhBsp1AAZG8UdflJh5LAc8rgKojNXjIb5aik=; b=h2cbSZeQFLc2NOeXeZJjZVd9XQ1xBDhHKhDKQipQKobyDTICh2Y3WFTNpgweAZcQqS eXsVeDc54bR/g9Ihop0StNhSbK2sskhMqDm5IIl/NGJA1Wko3ENR2PaAnetMCiGMNgZC RAG3BFtwMlEkW7Q0fH6l+dwv/AbWjbl8OPTqw5aRXtWev3HzZxjiNhXh+KAxuwXaZblc faeipqqw+OaiobJqnqGnx3XPOImZER2KY5Hd51PBModeZiVeCcN5keP7TO9DOBeRYwcP iFVc/TkzbFNoydVh9NFwSYbE6Hs/uKn1PvmOm2r391etcvpEmVWo/vopVCjfE/U1s39s aioQ== X-Gm-Message-State: ALoCoQmsLpnotORqKEH9lOr1hDWANOWLfFTZqf35Z2GtWjNlZN9EQdZhpZiZmL61wrjCLftABjZl MIME-Version: 1.0 X-Received: by 10.221.40.10 with SMTP id to10mr4270601vcb.22.1379649247166; Thu, 19 Sep 2013 20:54:07 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 19 Sep 2013 20:54:07 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <523BB8F9.4060901@it.aoyama.ac.jp> References: <77BD8417-533F-4080-8EE2-46266EDE8E25@vpnc.org> <20130920004215.GD9517@mercury.ccil.org> <20130920021007.GE9517@mercury.ccil.org> <523BB8F9.4060901@it.aoyama.ac.jp> Date: Thu, 19 Sep 2013 20:54:07 -0700 Message-ID: From: Tim Bray To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=001a113375764ad1e904e6c89fa6 Cc: John Cowan , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Code units X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 03:54:13 -0000 --001a113375764ad1e904e6c89fa6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin, you are closer to Unicode than the rest of us. How would you write that sentence in a way that best combines Unicode correctness and human readability? On Thu, Sep 19, 2013 at 7:54 PM, "Martin J. D=C3=BCrst" wrote: > There has just be an extensive discussion on the Unicode list about terms > such as "code unit", "code point" and "Unicode scalar value" including > experts and references to the standard that confirms John's points below. > > Regards, Martin. > > > On 2013/09/20 11:10, John Cowan wrote: > >> Tim Bray scripsit: >> >> Because \uDEAD isn=E2=80=99t a code point but it is a code unit. >>> >> >> You have a hold of the right spade, but you are calling it a shovel. >> The integer 0xDEAD =3D 57005: >> >> 0) does not represent a character; >> >> 1) is not a Unicode scalar value (USV) (integer in the range 0-0xD7FF >> or 0xE000-0x10FFFF); >> >> 2) is a code point (integer in the range 0-0x10FFFF); >> >> 3) is a 32-bit code unit (integer in the range 0-0x10FFFF); >> >> 4) is a 16-bit code unit (integer in the range 0-0xFFFF); >> >> 5) is not an 8-bit code unit (integer in the range 0-0xFF) and cannot >> be represented as a valid sequence of 8-bit code units either. >> >> [I]f it weren=E2=80=99t for \uDEAD we could could write the discussion = in >>> terms of code points, which would be much more humane, >>> >> >> If it weren't for \uDEAD we could write the discussion in terms of >> Unicode scalar values or characters, which *would* be much more humane. >> Since we do have to account for \uDEAD, we have to use code points, >> 16-bit code units, or 32-bit code units. >> >> it=E2=80=99s only because JSON allows some particular icky non-code-poi= nt 16-bit >>> code units that we have to write about code units. >>> >> >> It's only because JSON allows some particular icky non-USV code points >> that we have to write about code points or 16-bit code units or 32-bit >> code units rather than USVs or characters. >> >> ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --001a113375764ad1e904e6c89fa6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin, you are closer to Unicode than the rest of us.=C2= =A0 How would you write that sentence in a way that best combines Unicode c= orrectness and human readability?=C2=A0


On Thu, Sep 19, 2013 at 7:54 PM, "Martin J. D=C3=BCrst" <du= erst@it.aoyama.ac.jp> wrote:


On 2013/09/20 11:10, John Cowan wrote:
Tim Bray scripsit:

Because \uDEAD isn=E2=80=99t a code point but it is a code unit.

You have a hold of the right spade, but you are calling it a shovel.
The integer 0xDEAD =3D 57005:

0) does not represent a character;

1) is not a Unicode scalar value (USV) (integer in the range 0-0xD7FF
or 0xE000-0x10FFFF);

2) is a code point (integer in the range 0-0x10FFFF);

3) is a 32-bit code unit (integer in the range 0-0x10FFFF);

4) is a 16-bit code unit (integer in the range 0-0xFFFF);

5) is not an 8-bit code unit (integer in the range 0-0xFF) and cannot
be represented as a valid sequence of 8-bit code units either.

[I]f it weren=E2=80=99t for \uDEAD we could could write the discussion in terms of code points, which would be much more humane,

If it weren't for \uDEAD we could write the discussion in terms of
Unicode scalar values or characters, which *would* be much more humane.
Since we do have to account for \uDEAD, we have to use code points,
16-bit code units, or 32-bit code units.

it=E2=80=99s only because JSON allows some particular icky non-code-point 1= 6-bit
code units that we have to write about code units.

It's only because JSON allows some particular icky non-USV code points<= br> that we have to write about code points or 16-bit code units or 32-bit
code units rather than USVs or characters.

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

--001a113375764ad1e904e6c89fa6-- From cowan@ccil.org Thu Sep 19 21:01:00 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FA621F859A for ; Thu, 19 Sep 2013 21:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.282 X-Spam-Level: X-Spam-Status: No, score=-3.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge-u3FuqRo5l for ; Thu, 19 Sep 2013 21:00:50 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id E160D21F841D for ; Thu, 19 Sep 2013 21:00:49 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VMrte-0003mq-LS; Fri, 20 Sep 2013 00:00:46 -0400 Date: Fri, 20 Sep 2013 00:00:46 -0400 From: John Cowan To: R S Message-ID: <20130920040046.GB5939@mercury.ccil.org> References: <77BD8417-533F-4080-8EE2-46266EDE8E25@vpnc.org> <20130920004215.GD9517@mercury.ccil.org> <20130920021007.GE9517@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , Paul Hoffman , json@ietf.org Subject: Re: [Json] Code units X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 04:01:00 -0000 R S scripsit: > What if we left Unicode specifics out of the spec? The current RFC is > actually OK, otherwise JSON wouldn't work. If you don't believe the RFC needs any revision, what are you doing here? (This is not intended to be insulting; it's a genuine question.) -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin From tbray@textuality.com Thu Sep 19 21:01:07 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC8221F84DB for ; Thu, 19 Sep 2013 21:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4W5lQkPX3bM for ; Thu, 19 Sep 2013 21:01:03 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id 01DFE21F85C9 for ; Thu, 19 Sep 2013 21:01:02 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id oy12so7377835veb.26 for ; Thu, 19 Sep 2013 21:01:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wHA+waRVvB1JHjVoDAwWSTn7JkES3uIMMoH6GmvfeVQ=; b=g5IgeFuuxkLRfQFKyvPwO9zGzGoMWHWpqFV/gL49l+8jO7gnEhCAaJr51Ku5afsCDG 8lzuYr++fwKcNjMqn8BRpVEE2+XXcYv3QapJ6DH58tAI21FHcvVlTuDFoEte8LD62NZn NDcNAI+JwolMqeI8Ftl7oI89CfxCK4tWnWpBtCSk03UIZs2VucXIp1eDbroqURJyKyGz laTTp7CzHeYDpr7ZA90VTMhB+fnDPMGpTSmu9MBUSg4qLpuY+ZsRRTaBnNLLBo/F8ozm kiz5oYiWBP/U6tpMe95bo9xaTS0AifD5yBCdaxaTMFvJ8Gf1KgUkCwSTq7PjncyEKy4y M23g== X-Gm-Message-State: ALoCoQk891+/9wSq2qgOVUn2KTDG5dgwfQ36nFxZ9vHGo5fJCeCGGO1E42Cpj6J/TrwVcdkz5nQv MIME-Version: 1.0 X-Received: by 10.52.64.143 with SMTP id o15mr3646657vds.16.1379649662422; Thu, 19 Sep 2013 21:01:02 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 19 Sep 2013 21:01:02 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11531058CC4@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11531058CC4@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 19 Sep 2013 21:01:02 -0700 Message-ID: From: Tim Bray To: "Manger, James H" Content-Type: multipart/alternative; boundary=20cf307761530b23a104e6c8b84d Cc: "json@ietf.org" Subject: Re: [Json] 8.2. "A JSON text which is composed entirely of Unicode characters" X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 04:01:08 -0000 --20cf307761530b23a104e6c8b84d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You mean \uDEAD in your example, but I take your point. Actually both your points, because there are strings in arrays too, d=E2=80=99oh. Let=E2=80=99= s take James=E2=80=99 edit for the next draft unless someone sees something he and I missed. Hm, except for they might not agree on the contents of too-big numbers, so it'll have to be =E2=80=9Cagree on the content of names and string values i= n objects and arrays=E2=80=9D. -T On Thu, Sep 19, 2013 at 8:30 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Section 8.2. "Unicode Characters" of draft-ietf-json-rfc4627bis-03 says > JSON text is interoperable when it is "composed entirely of Unicode > characters". > > This is poorly worded. {"\DEAD":1} is a JSON text composed of 11 > characters =E2=80=94 all 11 of which are Unicode characters =E2=80=94 but= it is NOT > interoperable. > > Presumably we want to say that if all the logical strings that are > represented in a JSON text are composed entirely of Unicode characters th= en > it is interoperable. > > > Suggestion: modify the first sentence of 8.3 to: > > When all the strings represented in a JSON text are composed > entirely of Unicode characters [UNICODE] (however escaped), > then that JSON text is interoperable in the sense that all > software implementations which parse it will agree on the contents. > > > P.S. This sentence also drops the last line as implementations will > agree on array items etc, not just object members. > > > [For comparison, the draft 3 sentence is: > > A JSON text which is composed entirely of Unicode characters > [UNICODE] (however encoded) is interoperable in the sense that all > software implementations which parse it will agree on the contents of > names and values of object members. ] > > -- > James Manger > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --20cf307761530b23a104e6c8b84d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You mean \uDEAD in your example, but I take your point. Ac= tually both your points, because there are strings in arrays too, d=E2=80= =99oh. Let=E2=80=99s take James=E2=80=99 edit for the next draft unless som= eone sees something he and I missed.=C2=A0 Hm, except for they might not ag= ree on the contents of too-big numbers, so it'll have to be =E2=80=9Cag= ree on the content of names and string values in objects and arrays=E2=80= =9D.=C2=A0=C2=A0 -T


On Thu,= Sep 19, 2013 at 8:30 PM, Manger, James H <James.H.Manger@te= am.telstra.com> wrote:
Section 8.2. "Unicode Characters" = of draft-ietf-json-rfc4627bis-03 says JSON text is interoperable when it is= "composed entirely of Unicode characters".

This is poorly worded. {"\DEAD":1} is a JSON text composed of 11 = characters =E2=80=94 all 11 of which are Unicode characters =E2=80=94 but i= t is NOT interoperable.

Presumably we want to say that if all the logical strings that are represen= ted in a JSON text are composed entirely of Unicode characters then it is i= nteroperable.


Suggestion: modify the first sentence of 8.3 to:

=C2=A0 =C2=A0When all the strings represented in a JSON text are composed =C2=A0 =C2=A0entirely of Unicode characters [UNICODE] (however escaped), =C2=A0 =C2=A0then that JSON text is interoperable in the sense that all
=C2=A0 =C2=A0software implementations which parse it will agree on the cont= ents.


P.S. This sentence also drops the last line as implementations will
agree on array items etc, not just object members.


[For comparison, the draft 3 sentence is:

=C2=A0 =C2=A0A JSON text which is composed entirely of Unicode characters =C2=A0 =C2=A0[UNICODE] (however encoded) is interoperable in the sense that= all
=C2=A0 =C2=A0software implementations which parse it will agree on the cont= ents of
=C2=A0 =C2=A0names and values of object members. ]

--
James Manger


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

--20cf307761530b23a104e6c8b84d-- From tbray@textuality.com Thu Sep 19 21:24:07 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA2D21F85B8 for ; Thu, 19 Sep 2013 21:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXRtP4pbEyOb for ; Thu, 19 Sep 2013 21:24:01 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7679A21F842A for ; Thu, 19 Sep 2013 21:24:01 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id ij15so7227282vcb.16 for ; Thu, 19 Sep 2013 21:24:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=sCFnN7yeiR+7ex1i/soUiiai4HNRTRMOVE4Pc7+U0SE=; b=BuyjTx/Pe+P5kJDE9lnvlVgmCWJh2L06m9XQMZIdkygsVm8LXyPa1fEBFYqhF1mxrm MKNPZ1K/DROKGHno7Kpn4x+EIuz+npsHxaJj32/buOB/KBQFwS9jryrkt9j7v2RXG64+ 0yxrpQ2RoCL3sGU5XX4au49B2iSBUCS7RAuGY/2P9H1GVGg32ui37AgFeYa/yzMlR2Li gI0Y9g/sFBpNzw6/Lw1xT6iD5RfHIAbwt+NiVzabpq/WrK8xK0a/OfGNDZYhFM2u1vb/ VYfQI9K4oTbrxK7cPWhvqgEtskaQnZiczFXu2wasbT3N2HFJhTslodjtvZJkq4QOu3wg lcoQ== X-Gm-Message-State: ALoCoQnc91dyl8e8pOUySLSrcKhmLN5UXAc7k1gTcif9qvyYt3wPTHNoGjAgc21IpGRIkwLhA2kQ MIME-Version: 1.0 X-Received: by 10.220.199.5 with SMTP id eq5mr4423177vcb.16.1379651040781; Thu, 19 Sep 2013 21:24:00 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 19 Sep 2013 21:24:00 -0700 (PDT) X-Originating-IP: [24.84.235.32] Date: Thu, 19 Sep 2013 21:24:00 -0700 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5db26a333cb904e6c90aef Subject: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 04:24:07 -0000 --047d7b5db26a333cb904e6c90aef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In section 6, the language asserts that =E2=80=9Cwide interoperability=E2= =80=9D can be achieved by staying within the IEEE754 binary64 bounds. I think the reason we=E2=80=99re saying that is that we believe that softwa= re which correctly implements IEEE754 is generally available and widely used. So maybe we should just say that. And if we do, we might also point out that, on that basis, if your numbers are integers and of magnitude < 2**53, you will achieve complete interoperability when your JSON is processed by such software. So maybe rephrase to say: This specification allows implementations to set limits on the range of numbers accepted. While absolute interoperability cannot be guaranteed, wide interoperability can be achieved by limiting numbers in JSON texts to those within the precision and magnitude expressible in an IEEE 754:20008 binary64 (double precision) number [IEEE754], because software that correctly implements that standard is generally available and widely deployed. Note that when such software is used, numbers which are integers and of magnitude less than 2**53 will be interoperable in the sense that such implementations will agree exactly on the numeric values. Numeric values that cannot be represented in the grammar above (such as Infinity and NaN) are not permitted. Attempting to represent numbers that cannot be exactly encoded as an IEEE 754:2008 binary64 number, such as 1E400, 9007199254740993, or 3.141592653589793238462643383279, may cause interoperability problems. Worth the change? --047d7b5db26a333cb904e6c90aef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In section 6, the language asserts that =E2=80= =9Cwide interoperability=E2=80=9D can be achieved by staying within the IEE= E754 binary64 bounds.=C2=A0

I think the reason we=E2=80=99re saying= that is that we believe that software which correctly implements IEEE754 i= s generally available and widely used.=C2=A0 So maybe we should just say th= at.=C2=A0 And if we do, we might also point out that, on that basis, if you= r numbers are integers and of magnitude < 2**53, you will achieve comple= te interoperability when your JSON is processed by such software.

So maybe rephrase to say:=C2=A0

<new>
This specification allows implementations to set limits on the range = of numbers accepted. While absolute interoperability cannot be guaranteed, = wide interoperability can be achieved by limiting numbers in JSON texts to = those within the precision and magnitude expressible in an IEEE 754:20008 b= inary64 (double precision) number [IEEE754], because software that correctl= y implements that standard is generally available and widely deployed.=C2= =A0 Note that when such software is used, numbers which are integers and of= magnitude less than 2**53 will be interoperable in the sense that such imp= lementations will agree exactly on the numeric values.

Numeric values that cannot be represented in the grammar above (such as= Infinity and NaN) are not permitted. Attempting to represent numbers that = cannot be exactly encoded as an IEEE 754:2008 binary64 number, such as 1E40= 0, 9007199254740993, or 3.141592653589793238462643383279, may cause interop= erability problems.
</new>

Worth the change?
--047d7b5db26a333cb904e6c90aef-- From sayrer@gmail.com Thu Sep 19 21:25:29 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A4421F85B8 for ; Thu, 19 Sep 2013 21:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZMg6D6u-e7V for ; Thu, 19 Sep 2013 21:25:28 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8F51421F842A for ; Thu, 19 Sep 2013 21:25:28 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id c3so6082689qcv.4 for ; Thu, 19 Sep 2013 21:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gU7ucpq26uj+yyiDWmDZVlymLUQkgNVyXWvR+KpBW+o=; b=HUQZYMcjtI7pFEVEn12+upILmMI/+6DV+n0ApoXGsfdF80acyZucxWkCTneowCUoXD rtD4zeg3Dsej2BS4MRYXYbWVTMcPwouoevqXPFW1/RI01cak/5bRVh3RAIX214ofbRwL 3hlbusULJEHntAamnvKxuB/DqnErCeZy3ybzf2CTPpnA9179HcttSf4yGK1MGBu/vnb8 L3GCRzg2tKJAe2bfozDt14y40H/o/KasSNamk2EJ7e85OQahMX+h+inCTOTfDOfmPZDH I0JayYOxd5SulMs8bZwjsM9xUvB0o/ZvV7z+Jgf5eKuoIQMheOcS6WUvA/AawxqUARCa SQOw== MIME-Version: 1.0 X-Received: by 10.224.29.69 with SMTP id p5mr2993707qac.30.1379651127894; Thu, 19 Sep 2013 21:25:27 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Thu, 19 Sep 2013 21:25:27 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Thu, 19 Sep 2013 21:25:27 -0700 (PDT) In-Reply-To: <20130920040046.GB5939@mercury.ccil.org> References: <77BD8417-533F-4080-8EE2-46266EDE8E25@vpnc.org> <20130920004215.GD9517@mercury.ccil.org> <20130920021007.GE9517@mercury.ccil.org> <20130920040046.GB5939@mercury.ccil.org> Date: Thu, 19 Sep 2013 21:25:27 -0700 Message-ID: From: R S To: John Cowan Content-Type: multipart/alternative; boundary=047d7bf0de3e6466a204e6c90f75 Cc: Tim Bray , Paul Hoffman , json@ietf.org Subject: Re: [Json] Code units X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 04:25:29 -0000 --047d7bf0de3e6466a204e6c90f75 Content-Type: text/plain; charset=ISO-8859-1 On Sep 19, 2013 9:00 PM, "John Cowan" wrote: > > R S scripsit: > > > What if we left Unicode specifics out of the spec? The current RFC is > > actually OK, otherwise JSON wouldn't work. > > If you don't believe the RFC needs any revision, what are you doing here? > (This is not intended to be insulting; it's a genuine question.) The current RFC's vague Unicode text seems to work in practice. Further, the WG could do harm. In fact, that seems likely. For example, any JSON library that one might actually want to use handles duplicate keys in objects and primitives at the root level. - Rob > > -- > John Cowan > cowan@ccil.org > I am a member of a civilization. --David Brin --047d7bf0de3e6466a204e6c90f75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 19, 2013 9:00 PM, "John Cowan" <cowan@mercury.ccil.org> wrote:
>
> R S scripsit:
>
> > What if we left Unicode specifics out of the spec? The current RF= C is
> > actually OK, otherwise JSON wouldn't work.
>
> If you don't believe the RFC needs any revision, what are you doin= g here?
> (This is not intended to be insulting; it's a genuine question.)

The current RFC's vague Unicode text seems to work in pr= actice.

Further, the WG could do harm. In fact, that seems likely.

For example, any JSON library that one might actually want t= o use handles duplicate keys in objects and primitives at the root level.

- Rob

>
> --
> John Cowan
> =A0 =A0 =A0 =A0 cowan@ccil.org > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I am a member of a civilization. --Dav= id Brin

--047d7bf0de3e6466a204e6c90f75-- From cowan@ccil.org Thu Sep 19 22:26:10 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384B721F8517 for ; Thu, 19 Sep 2013 22:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeTXBHujtxeg for ; Thu, 19 Sep 2013 22:26:05 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id D872F21F84EA for ; Thu, 19 Sep 2013 22:26:05 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VMtEC-0004IR-6E; Fri, 20 Sep 2013 01:26:04 -0400 Date: Fri, 20 Sep 2013 01:26:04 -0400 From: John Cowan To: Tim Bray Message-ID: <20130920052604.GC5939@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 05:26:10 -0000 Tim Bray scripsit: > > This specification allows implementations to set limits on the range of > numbers accepted. While absolute interoperability cannot be guaranteed, > wide interoperability can be achieved by limiting numbers in JSON texts to > those within the precision and magnitude expressible in an IEEE 754:20008 > binary64 (double precision) number [IEEE754], because software that > correctly implements that standard is generally available and widely > deployed. Note that when such software is used, numbers which are integers > and of magnitude less than 2**53 will be interoperable in the sense that > such implementations will agree exactly on the numeric values. > > Numeric values that cannot be represented in the grammar above (such as > Infinity and NaN) are not permitted. Attempting to represent numbers that > cannot be exactly encoded as an IEEE 754:2008 binary64 number, such as > 1E400, 9007199254740993, or 3.141592653589793238462643383279, may cause > interoperability problems. > +1 -- Here lies the Christian, John Cowan judge, and poet Peter, http://www.ccil.org/~cowan Who broke the laws of God cowan@ccil.org and man and metre. From cabo@tzi.org Thu Sep 19 22:54:06 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E275C21F853A for ; Thu, 19 Sep 2013 22:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnH+CfrTgbAW for ; Thu, 19 Sep 2013 22:54:01 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C0DEB21F84EF for ; Thu, 19 Sep 2013 22:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8K5rvYt018985; Fri, 20 Sep 2013 07:53:57 +0200 (CEST) Received: from [192.168.217.105] (p54894434.dip0.t-ipconnect.de [84.137.68.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 75AF7A61; Fri, 20 Sep 2013 07:53:57 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Fri, 20 Sep 2013 07:53:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0EE831F6-6D61-47CD-B953-630F8F5446AA@tzi.org> References: <77BD8417-533F-4080-8EE2-46266EDE8E25@vpnc.org> <20130920004215.GD9517@mercury.ccil.org> <255B9BB34FB7D647A506DC292726F6E11530F69308@WSMSG3153V.srv.dir.telstra.com> To: Tim Bray X-Mailer: Apple Mail (2.1510) Cc: json@ietf.org Subject: Re: [Json] Code units X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 05:54:07 -0000 On Sep 20, 2013, at 05:35, Tim Bray wrote: > On Thu, Sep 19, 2013 at 7:49 PM, Manger, James H = wrote: >=20 >=20 > I think the correct fix is to change "code unit" to "scalar value" in = this sentence. >=20 > I am wide open to arguments as to what words we should use to refer to = the integers that we parse out of JSON strings and then use in = comparison, but they should be backed up by specific arguments from = scripture^H^H^H^H^H^H^H^H^H the Unicode standard. I think =93code unit=94= is plausible on that basis but we=92re prepared to be convinced that = there=92s a better alternative. JSON is not concerned with code units (which are something that occurs = in a transformation format aka coding scheme), so any occurrence of = "code unit" in 4627bis is bound to be an error. Gr=FC=DFe, Carsten From James.H.Manger@team.telstra.com Fri Sep 20 00:29:38 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5548621F84EA for ; Fri, 20 Sep 2013 00:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=-1.213, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPNPOhCkwjO5 for ; Fri, 20 Sep 2013 00:29:32 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 61B3121F84D0 for ; Fri, 20 Sep 2013 00:29:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,941,1371045600"; d="scan'208,217";a="158813912" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 20 Sep 2013 17:29:30 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7203"; a="169040325" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipccni.tcif.telstra.com.au with ESMTP; 20 Sep 2013 17:29:30 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Fri, 20 Sep 2013 17:29:29 +1000 From: "Manger, James H" To: Tim Bray Date: Fri, 20 Sep 2013 17:29:28 +1000 Thread-Topic: [Json] Code units Thread-Index: Ac61sna3cqDVD7b2Tw+DLJ7DeYYmBwAAFCVg Message-ID: <255B9BB34FB7D647A506DC292726F6E115310591DB@WSMSG3153V.srv.dir.telstra.com> References: <77BD8417-533F-4080-8EE2-46266EDE8E25@vpnc.org> <20130920004215.GD9517@mercury.ccil.org> <255B9BB34FB7D647A506DC292726F6E11530F69308@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115310591DBWSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Code units X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 07:29:38 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115310591DBWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXZlbiBpZiB0d28gaW1wbGVtZW50YXRpb25zIGJvdGggY29tcGFyZSBzdHJpbmdzIGNvZGUgdW5p dCBieSBjb2RlIHVuaXQsIHRoZXkgYXJlIG5vdCBnb2luZyB0byDigJxhZ3JlZSBpbiBhbGwgY2Fz ZXPigJ0uIE9uZSBjYW4gdGhyb3dzIGEg4oCcZmF0YWwgcnVudGltZSBleGNlcHRpb27igJ0gb24g Ilx1REVBRCIgKGFzIGFsbG93ZWQgYnkgdGhlIHByZXZpb3VzIHNlY3Rpb24pLCBmb3IgaW5zdGFu Y2UuIEJ5IHN1Z2dlc3RpbmcgYSBzd2l0Y2ggdG8gdGhlIHRlcm0g4oCcc2NhbGFyIHZhbHVl4oCd IEkgaG9wZWQgdG8gdGFrZSB0aG9zZSBwcm9ibGVtYXRpYyBjYXNlcyBvdXQtb2Ytc2NvcGUgZm9y IHRoZSBzZW50ZW5jZSBvbiBpbnRlcm9wZXJhYmxlIHN0cmluZyBjb21wYXJpc29uLg0KDQpQZXJo YXBzIHRoYXQgaXNu4oCZdCB0aGUgcmlnaHQgYXBwcm9hY2ggdGhvdWdoLg0KDQpJIGFzc3VtZSB0 aGUgcG9pbnQgb2Ygc2VjdGlvbiA4LjMuIOKAnFN0cmluZyBDb21wYXJpc29u4oCdIGlzIHRvIHRl bGwgaW1wbGVtZW50YXRpb25zIHRoYXQgdGhleSBtdXN0IHVuZG8gZXNjYXBlcywgYnV0IHRoZXkg ZG9u4oCZdCBoYXZlIHRvIGdvIHRvIHRoZSBlZmZvcnQgb2YgVW5pY29kZSBub3JtYWxpemF0aW9u IHdoZW4gdGhleSBjb21wYXJlIG9iamVjdCBlbGVtZW50IG5hbWVzLiBBZnRlciB1bmRvaW5nIGVz Y2FwZXMgb24gcGFyc2luZywgaXQgaXMgc3VmZmljaWVudCB0byBjb21wYXJlIGNvZGUgdW5pdCBi eSBjb2RlIHVuaXQsIHdpdGggd2hhdGV2ZXIgY29kZSB1bml0IHNpemUgdGhlIGltcGxlbWVudGF0 aW9uIHVzZXMuDQoNCk5vdCBoYXZpbmcgdG8gbm9ybWFsaXplIGlzIG5vdCB0aGUgc2FtZSBhcyBu b3QgYmVpbmcgYWxsb3dlZCB0byBub3JtYWxpemUsIGhvd2V2ZXIuDQoNCkFyZSB3ZSBzdXJlIG5v IEpTT04gbGlicmFyaWVzIChvciBubyBhcHBzIHRoYXQgdXNlIEpTT04gbGlicmFyaWVzKSBldmVy IGRvIG5vcm1hbGl6YXRpb24/DQoNCkkgd291bGQgYmUgcXVpdGUgaGFwcHkgaWYgYSBKU09OIHBh cnNlciByZWplY3RlZCB7Ilx1MDBjNCI6MCwgIlx1MDA0MVx1MDMwOCI6MX0gYXMgaGF2aW5nIGR1 cGxpY2F0ZXMgKMOEIHZzIEHMiCksIHRob3VnaCBvYnZpb3VzbHkgSSBjYW5ub3QgcmVseSBvbiB0 aGlzIGJlaGF2aW91ci4gSSB3b25kZXIgaWYgYW55IG5vbi1tYWxpY2lvdXMgc3lzdGVtcyBuZWVk IEpTT04gbGlrZSB0aGF0IHRvIHdvcms/DQoNClRoZSBuZXcgdGV4dCBpbiByZmM0NjI3YmlzIG9u IFVuaWNvZGUgY2hhcnMgKDguMiksIG51bWJlcnMgKDYpLCBhbmQgdW5pcXVlIG5hbWVzIGluIG9i amVjdHMgKDQpIGlzIGFpbWVkIGF0IHBlb3BsZSB1c2luZyBKU09OLiBJdCBkb2VzbuKAmXQgYWRk IG5ldyBNVVNUczsgaXQgYWRkcyBzZW50ZW5jZXMgc2F5aW5nIGlmIHlvdSB3cml0ZSBKU09OIHdp dGhpbiB0aGlzIHN1YnNldCB5b3Ugd2lsbCBnZXQgaW50ZXJvcC4gVGhlIHN0cmluZyBjb21wYXJp c29uIHRleHQgZmVlbHMgZGlmZmVyZW50LiBJdCBpcyBhaW1lZCBhdCBsaWJyYXJ5IGltcGxlbWVu dGVycyBzbyBJIHRoaW5rIHRoZSBpbnRlcm9wIGxhbmd1YWdlIG5lZWRzIGEgZGlmZmVyZW50IGZv cm0uDQoNClN1Z2dlc3Rpb246DQoNCjguMy4gIFN0cmluZyBDb21wYXJpc29uDQoNCiAgIFNvZnR3 YXJlIGltcGxlbWVudGF0aW9ucyBhcmUgdHlwaWNhbGx5IHJlcXVpcmVkIHRvIHRlc3QgbmFtZXMg b2YNCiAgIG9iamVjdCBtZW1iZXJzIGZvciBlcXVhbGl0eS4gIEVzY2FwZXMgTVVTVCBiZSB1bmRv bmUgYmVmb3JlIGFueSBzdWNoDQogICB0ZXN0LiBGb3IgZXhhbXBsZSwgdGhlIGZvbGxvd2luZyBm b3VyIHN0cmluZ3MgYXJlIGVxdWFsOg0KICAgIi8iLCAiXC8iLCAiXHUwMDJGIiwgIlx1MDAyZiIu IE5vIG90aGVyIG5vcm1hbGl6YXRpb24gaXMgcmVxdWlyZWQuDQogICBBZnRlciB1bmRvaW5nIGVz Y2FwZXMsIGFuIGltcGxlbWVudGF0aW9uIGNhbiBjb21wYXJlIHRoZSByZXN1bHRpbmcgY29kZSB1 bml0cw0KICAgTnVtZXJpY2FsbHkgKHdoYXRldmVyIHNpemUgb2YgY29kZSB1bml0IGl0IHVzZXMp Lg0KDQpJIGRvdWJ0IHdlIHdhbnQgKG9yIG5lZWQpIHRvIHNheSB3aGljaCBzdWJzZXQgb2YgSlNP TiB5b3UgbmVlZCB0byB1c2UgdG8gZW5zdXJlIHlvdXIgb2JqZWN0IG5hbWVzIGFyZSBub3QgY29u c2lkZXJlZCBlcXVhbCwgaW50ZXJvcGVyYWJseS4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQpGcm9t OiBUaW0gQnJheSBbbWFpbHRvOnRicmF5QHRleHR1YWxpdHkuY29tXQ0KU2VudDogRnJpZGF5LCAy MCBTZXB0ZW1iZXIgMjAxMyAxOjM2IFBNDQpUbzogTWFuZ2VyLCBKYW1lcyBIDQpDYzogSm9obiBD b3dhbjsgUGF1bCBIb2ZmbWFuOyBqc29uQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0pzb25dIENv ZGUgdW5pdHMNCg0KT24gVGh1LCBTZXAgMTksIDIwMTMgYXQgNzo0OSBQTSwgTWFuZ2VyLCBKYW1l cyBIIDxKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPG1haWx0bzpKYW1lcy5ILk1hbmdl ckB0ZWFtLnRlbHN0cmEuY29tPj4gd3JvdGU6DQoNCg0KSSB0aGluayB0aGUgY29ycmVjdCBmaXgg aXMgdG8gY2hhbmdlICJjb2RlIHVuaXQiIHRvICJzY2FsYXIgdmFsdWUiIGluIHRoaXMgc2VudGVu Y2UuDQoNCkkgYW0gd2lkZSBvcGVuIHRvIGFyZ3VtZW50cyBhcyB0byB3aGF0IHdvcmRzIHdlIHNo b3VsZCB1c2UgdG8gcmVmZXIgdG8gdGhlIGludGVnZXJzIHRoYXQgd2UgcGFyc2Ugb3V0IG9mIEpT T04gc3RyaW5ncyBhbmQgdGhlbiB1c2UgaW4gY29tcGFyaXNvbiwgYnV0IHRoZXkgc2hvdWxkIGJl IGJhY2tlZCB1cCBieSBzcGVjaWZpYyBhcmd1bWVudHMgZnJvbSBzY3JpcHR1cmVeSF5IXkheSF5I XkheSF5IXkggdGhlIFVuaWNvZGUgc3RhbmRhcmQuICBJIHRoaW5rIOKAnGNvZGUgdW5pdOKAnSBp cyBwbGF1c2libGUgb24gdGhhdCBiYXNpcyBidXQgd2XigJlyZSBwcmVwYXJlZCB0byBiZSBjb252 aW5jZWQgdGhhdCB0aGVyZeKAmXMgYSBiZXR0ZXIgYWx0ZXJuYXRpdmUuDQoNCg0KLS0NCkphbWVz IE1hbmdlcg0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E115310591DBWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUg dmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkV2ZW4gaWYgdHdvIGltcGxlbWVudGF0aW9ucyBib3RoIGNv bXBhcmUgc3RyaW5ncyBjb2RlIHVuaXQgYnkgY29kZSB1bml0LCB0aGV5IGFyZSBub3QgZ29pbmcg dG8g4oCcYWdyZWUgaW4gPGk+YWxsPC9pPiBjYXNlc+KAnS4gT25lIGNhbiB0aHJvd3MgYSDigJxm YXRhbCBydW50aW1lIGV4Y2VwdGlvbuKAnSBvbiAmcXVvdDtcdURFQUQmcXVvdDsgKGFzIGFsbG93 ZWQgYnkgdGhlIHByZXZpb3VzIHNlY3Rpb24pLCBmb3IgaW5zdGFuY2UuIEJ5IHN1Z2dlc3Rpbmcg YSBzd2l0Y2ggdG8gdGhlIHRlcm0g4oCcc2NhbGFyIHZhbHVl4oCdIEkgaG9wZWQgdG8gdGFrZSB0 aG9zZSBwcm9ibGVtYXRpYyBjYXNlcyBvdXQtb2Ytc2NvcGUgZm9yIHRoZSBzZW50ZW5jZSBvbiBp bnRlcm9wZXJhYmxlIHN0cmluZyBjb21wYXJpc29uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UGVyaGFw cyB0aGF0IGlzbuKAmXQgdGhlIHJpZ2h0IGFwcHJvYWNoIHRob3VnaC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPkkgYXNzdW1lIHRoZSBwb2ludCBvZiBzZWN0aW9uIDguMy4g4oCcU3RyaW5nIENvbXBhcmlz b27igJ0gaXMgdG8gdGVsbCBpbXBsZW1lbnRhdGlvbnMgdGhhdCB0aGV5IG11c3QgdW5kbyBlc2Nh cGVzLCBidXQgdGhleSBkb27igJl0IGhhdmUgdG8gZ28gdG8gdGhlIGVmZm9ydCBvZiBVbmljb2Rl IG5vcm1hbGl6YXRpb24gd2hlbiB0aGV5IGNvbXBhcmUgb2JqZWN0IGVsZW1lbnQgbmFtZXMuIEFm dGVyIHVuZG9pbmcgZXNjYXBlcyBvbiBwYXJzaW5nLCBpdCBpcyBzdWZmaWNpZW50IHRvIGNvbXBh cmUgY29kZSB1bml0IGJ5IGNvZGUgdW5pdCwgd2l0aCB3aGF0ZXZlciBjb2RlIHVuaXQgc2l6ZSB0 aGUgaW1wbGVtZW50YXRpb24gdXNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk5vdCBoYXZpbmcgdG8g bm9ybWFsaXplIGlzIG5vdCB0aGUgc2FtZSBhcyBub3QgYmVpbmcgPGk+YWxsb3dlZDwvaT4gdG8g bm9ybWFsaXplLCBob3dldmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QXJlIHdlIHN1cmUgbm8gSlNP TiBsaWJyYXJpZXMgKG9yIG5vIGFwcHMgdGhhdCB1c2UgSlNPTiBsaWJyYXJpZXMpIGV2ZXIgZG8g bm9ybWFsaXphdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgd291bGQgYmUgcXVpdGUgaGFwcHkg aWYgYSBKU09OIHBhcnNlciByZWplY3RlZCB7JnF1b3Q7XHUwMGM0JnF1b3Q7OjAsICZxdW90O1x1 MDA0MVx1MDMwOCZxdW90OzoxfSBhcyBoYXZpbmcgZHVwbGljYXRlcyAow4QgdnMgQcyIKSwgdGhv dWdoIG9idmlvdXNseSBJIGNhbm5vdCByZWx5IG9uIHRoaXMgYmVoYXZpb3VyLiBJIHdvbmRlciBp ZiBhbnkgbm9uLW1hbGljaW91cyBzeXN0ZW1zIG5lZWQgSlNPTiBsaWtlIHRoYXQgdG8gd29yaz88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBuZXcgdGV4dCBpbiByZmM0NjI3YmlzIG9uIFVuaWNvZGUg Y2hhcnMgKDguMiksIG51bWJlcnMgKDYpLCBhbmQgdW5pcXVlIG5hbWVzIGluIG9iamVjdHMgKDQp IGlzIGFpbWVkIGF0IHBlb3BsZSB1c2luZyBKU09OLiBJdCBkb2VzbuKAmXQgYWRkIG5ldyBNVVNU czsgaXQgYWRkcyBzZW50ZW5jZXMgc2F5aW5nIGlmIHlvdSB3cml0ZSBKU09OIHdpdGhpbiB0aGlz IHN1YnNldCB5b3Ugd2lsbCBnZXQgaW50ZXJvcC4gVGhlIHN0cmluZyBjb21wYXJpc29uIHRleHQg ZmVlbHMgZGlmZmVyZW50LiBJdCBpcyBhaW1lZCBhdCBsaWJyYXJ5IGltcGxlbWVudGVycyBzbyBJ IHRoaW5rIHRoZSBpbnRlcm9wIGxhbmd1YWdlIG5lZWRzIGEgZGlmZmVyZW50IGZvcm0uPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5TdWdnZXN0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6Z3JlZW4nPjguMy7CoCBTdHJpbmcgQ29tcGFy aXNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6 Z3JlZW4nPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7Y29sb3I6Z3JlZW4nPsKgwqAgU29mdHdhcmUgaW1wbGVtZW50YXRpb25zIGFyZSB0eXBpY2Fs bHkgcmVxdWlyZWQgdG8gdGVzdCBuYW1lcyBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6Z3JlZW4nPsKgwqAgb2JqZWN0IG1lbWJlcnMgZm9yIGVx dWFsaXR5LsKgIEVzY2FwZXMgTVVTVCBiZSB1bmRvbmUgYmVmb3JlIGFueSBzdWNoPG86cD48L286 cD48L3NwYW4+PC9iPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpncmVlbic+wqDCoCB0 ZXN0LiBGb3IgZXhhbXBsZSwgdGhlIGZvbGxvd2luZyBmb3VyIHN0cmluZ3MgYXJlIGVxdWFsOjxv OnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6Z3JlZW4n PsKgIMKgJnF1b3Q7LyZxdW90OywgJnF1b3Q7XC8mcXVvdDssICZxdW90O1x1MDAyRiZxdW90Oywg JnF1b3Q7XHUwMDJmJnF1b3Q7LiBObyBvdGhlciBub3JtYWxpemF0aW9uIGlzIHJlcXVpcmVkLjxv OnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6Z3JlZW4n PsKgwqAgQWZ0ZXIgdW5kb2luZyBlc2NhcGVzLCBhbiBpbXBsZW1lbnRhdGlvbiBjYW4gY29tcGFy ZSB0aGUgcmVzdWx0aW5nIGNvZGUgdW5pdHM8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciO2NvbG9yOmdyZWVuJz7CoMKgIE51bWVyaWNhbGx5ICh3aGF0ZXZlciBz aXplIG9mIGNvZGUgdW5pdCBpdCB1c2VzKS48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciO2NvbG9yOmdyZWVuJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2I+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgZG91YnQgd2Ug d2FudCAob3IgbmVlZCkgdG8gc2F5IHdoaWNoIHN1YnNldCBvZiBKU09OIHlvdSBuZWVkIHRvIHVz ZSB0byBlbnN1cmUgeW91ciBvYmplY3QgbmFtZXMgYXJlIG5vdCBjb25zaWRlcmVkIGVxdWFsLCBp bnRlcm9wZXJhYmx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2VyPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gVGltIEJyYXkg W21haWx0bzp0YnJheUB0ZXh0dWFsaXR5LmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBGcmlkYXksIDIw IFNlcHRlbWJlciAyMDEzIDE6MzYgUE08YnI+PGI+VG86PC9iPiBNYW5nZXIsIEphbWVzIEg8YnI+ PGI+Q2M6PC9iPiBKb2huIENvd2FuOyBQYXVsIEhvZmZtYW47IGpzb25AaWV0Zi5vcmc8YnI+PGI+ U3ViamVjdDo8L2I+IFJlOiBbSnNvbl0gQ29kZSB1bml0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+T24gVGh1LCBTZXAgMTksIDIwMTMgYXQgNzo0OSBQTSwgTWFuZ2Vy LCBKYW1lcyBIICZsdDs8YSBocmVmPSJtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJh LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtJz48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PGJyPkkgdGhpbmsgdGhlIGNvcnJlY3QgZml4IGlzIHRvIGNoYW5nZSAmcXVvdDtjb2RlIHVu aXQmcXVvdDsgdG8gJnF1b3Q7c2NhbGFyIHZhbHVlJnF1b3Q7IGluIHRoaXMgc2VudGVuY2UuPG86 cD48L286cD48L3A+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgYW0gd2lkZSBvcGVu IHRvIGFyZ3VtZW50cyBhcyB0byB3aGF0IHdvcmRzIHdlIHNob3VsZCB1c2UgdG8gcmVmZXIgdG8g dGhlIGludGVnZXJzIHRoYXQgd2UgcGFyc2Ugb3V0IG9mIEpTT04gc3RyaW5ncyBhbmQgdGhlbiB1 c2UgaW4gY29tcGFyaXNvbiwgYnV0IHRoZXkgc2hvdWxkIGJlIGJhY2tlZCB1cCBieSBzcGVjaWZp YyBhcmd1bWVudHMgZnJvbSBzY3JpcHR1cmVeSF5IXkheSF5IXkheSF5IXkggdGhlIFVuaWNvZGUg c3RhbmRhcmQuJm5ic3A7IEkgdGhpbmsg4oCcY29kZSB1bml04oCdIGlzIHBsYXVzaWJsZSBvbiB0 aGF0IGJhc2lzIGJ1dCB3ZeKAmXJlIHByZXBhcmVkIHRvIGJlIGNvbnZpbmNlZCB0aGF0IHRoZXJl 4oCZcyBhIGJldHRlciBhbHRlcm5hdGl2ZS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20nPjxwIGNs YXNzPU1zb05vcm1hbD48YnI+LS08YnI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3A+PC9ibG9j a3F1b3RlPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E115310591DBWSMSG3153Vsrv_-- From markus.lanthaler@gmx.net Fri Sep 20 01:49:47 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F49921F8C93 for ; Fri, 20 Sep 2013 01:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzqoZvNj-DvQ for ; Fri, 20 Sep 2013 01:49:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9342E21F84B1 for ; Fri, 20 Sep 2013 01:49:41 -0700 (PDT) Received: from Vostro3500 ([79.48.108.27]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lbi2Z-1Vm8Cm1max-00lCQH for ; Fri, 20 Sep 2013 10:49:39 +0200 From: "Markus Lanthaler" To: References: In-Reply-To: Date: Fri, 20 Sep 2013 10:49:35 +0200 Message-ID: <011f01ceb5de$56902ee0$03b08ca0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac61uUFV2uYU6YZ/T2ycmgBe6d6BFgAJNxOQ Content-Language: de X-Provags-ID: V03:K0:NYJ2qIxgUaVDV7qOdEIVGNeG5T6tuJEpJdIyH1mQ3wx2nMWksAy 2VFPSTO3fc+mWMjnem96fzY+bZGzq3a35jdvuHNKefp+MVTUJ3VK9VJFKXEbIGK6Dz2B4/F UjcLBZ6G1IdJX2RgJTqcCElep9HE4LFLBcstTEg8iD2Rw1QjGy79AX2ZOLEc4aUEKszNNy0 1XNq6UawRHS75+qco68EQ== Subject: Re: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 08:49:47 -0000 On Friday, September 20, 2013 6:24 AM, Tim Bray wrote: > In section 6, the language asserts that =E2=80=9Cwide = interoperability=E2=80=9D can be > achieved by staying within the IEEE754 binary64 bounds. >=20 > I think the reason we=E2=80=99re saying that is that we believe that = software which > correctly implements IEEE754 is generally available and widely used. = So > maybe we should just say that. And if we do, we might also point out = that, > on that basis, if your numbers are integers and of magnitude < 2**53, = you > will achieve complete interoperability when your JSON is processed by = such > software. So maybe rephrase to say: >=20 > > This specification allows implementations to set limits on the range = of > numbers accepted. While absolute interoperability cannot be = guaranteed, wide > interoperability can be achieved by limiting numbers in JSON texts to = those > within the precision and magnitude expressible in an IEEE 754:20008 = binary64 > (double precision) number [IEEE754], because software that correctly > implements that standard is generally available and widely deployed. = Note > that when such software is used, numbers which are integers and of = magnitude > less than 2**53 will be interoperable in the sense that such = implementations > will agree exactly on the numeric values. >=20 > Numeric values that cannot be represented in the grammar above (such = as > Infinity and NaN) are not permitted. Attempting to represent numbers = that > cannot be exactly encoded as an IEEE 754:2008 binary64 number, such as > 1E400, 9007199254740993, or 3.141592653589793238462643383279, may = cause > interoperability problems. > >=20 > Worth the change? +1 -- Markus Lanthaler @markuslanthaler From duerst@it.aoyama.ac.jp Fri Sep 20 02:31:31 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0C521F8F07 for ; Fri, 20 Sep 2013 02:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.417 X-Spam-Level: X-Spam-Status: No, score=-105.417 tagged_above=-999 required=5 tests=[AWL=-1.627, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yncOiT8w7Pva for ; Fri, 20 Sep 2013 02:31:26 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id B4FE221F8DA3 for ; Fri, 20 Sep 2013 02:31:25 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8K9VKXX020761; Fri, 20 Sep 2013 18:31:22 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 1b9d_f2e3_68441a56_21d7_11e3_aded_001e6722eec2; Fri, 20 Sep 2013 18:31:20 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 7218FBF54F; Fri, 20 Sep 2013 18:31:19 +0900 (JST) Message-ID: <523C15D5.8080006@it.aoyama.ac.jp> Date: Fri, 20 Sep 2013 18:31:01 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "json@ietf.org" Subject: Re: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 09:31:31 -0000 +1, except that I would change "precision and magnitude" to "magnitude=20 and precision", because it sounds more natural (magnitude is the=20 "bigger" of the two things, and so deserves to come first). Regards, Martin. On 2013/09/20 13:24, Tim Bray wrote: > In section 6, the language asserts that =E2=80=9Cwide interoperability=E2= =80=9D can be > achieved by staying within the IEEE754 binary64 bounds. > > I think the reason we=E2=80=99re saying that is that we believe that so= ftware which > correctly implements IEEE754 is generally available and widely used. S= o > maybe we should just say that. And if we do, we might also point out t= hat, > on that basis, if your numbers are integers and of magnitude< 2**53, y= ou > will achieve complete interoperability when your JSON is processed by s= uch > software. > > So maybe rephrase to say: > > > This specification allows implementations to set limits on the range of > numbers accepted. While absolute interoperability cannot be guaranteed, > wide interoperability can be achieved by limiting numbers in JSON texts= to > those within the precision and magnitude expressible in an IEEE 754:200= 08 > binary64 (double precision) number [IEEE754], because software that > correctly implements that standard is generally available and widely > deployed. Note that when such software is used, numbers which are inte= gers > and of magnitude less than 2**53 will be interoperable in the sense tha= t > such implementations will agree exactly on the numeric values. > > Numeric values that cannot be represented in the grammar above (such as > Infinity and NaN) are not permitted. Attempting to represent numbers th= at > cannot be exactly encoded as an IEEE 754:2008 binary64 number, such as > 1E400, 9007199254740993, or 3.141592653589793238462643383279, may cause > interoperability problems. > > > Worth the change? > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From cowan@ccil.org Fri Sep 20 06:40:29 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661EA21F9A3D for ; Fri, 20 Sep 2013 06:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUlSHGxQBASI for ; Fri, 20 Sep 2013 06:40:21 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 86E0621F999C for ; Fri, 20 Sep 2013 06:40:20 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VN0wP-0003Ns-Cg; Fri, 20 Sep 2013 09:40:13 -0400 Date: Fri, 20 Sep 2013 09:40:13 -0400 From: John Cowan To: "Manger, James H" Message-ID: <20130920134013.GA2798@mercury.ccil.org> References: <77BD8417-533F-4080-8EE2-46266EDE8E25@vpnc.org> <20130920004215.GD9517@mercury.ccil.org> <255B9BB34FB7D647A506DC292726F6E11530F69308@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115310591DB@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115310591DB@WSMSG3153V.srv.dir.telstra.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Code units X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 13:40:29 -0000 Manger, James H scripsit: > Are we sure no JSON libraries (or no apps that use JSON libraries) > ever do normalization? No. Nor are we sure that no JSON libraries or apps do case folding or accent stripping or ISO 9 transliteration, nor that their authors are not secret masters of international terrorism. Absence of evidence may not be evidence of absence, but sometimes it's all you're gonna get. > The new text in rfc4627bis on Unicode chars (8.2), numbers (6), > and unique names in objects (4) is aimed at people using JSON. It > doesn’t add new MUSTs; it adds sentences saying if you write JSON > within this subset you will get interop. More accurately, that if you exceed this subset you might not get interop. Interop is *never* guaranteed. -- I now introduce Professor Smullyan, John Cowan who will prove to you that either cowan@ccil.org he doesn't exist or you don't exist, http://www.ccil.org/~cowan but you won't know which. --Melvin Fitting From paul.hoffman@vpnc.org Fri Sep 20 07:44:30 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC1A21F8EDF for ; Fri, 20 Sep 2013 07:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRG5bN03XDyd for ; Fri, 20 Sep 2013 07:44:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B4D5D21F8EC3 for ; Fri, 20 Sep 2013 07:44:29 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8KEiOWU083874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Sep 2013 07:44:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Fri, 20 Sep 2013 07:44:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1EA739DD-F862-4AE1-94A0-75702051FE48@vpnc.org> References: To: jwilson X-Mailer: Apple Mail (2.1510) Cc: "" , "Matt Miller \(mamille2\)" Subject: Re: [Json] JSON comments /* ... */ and // ... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 14:44:30 -0000 On Sep 19, 2013, at 7:46 PM, jwilson wrote: > Real JSON in the wild has comments. Real JSON processors handle these = comments. Some python parsers probably implement the style of comments you give, = even if they are not documented in RFC 4627 or ECMAScript. Some clearly don't. My first attempt to validate your statement (Python) = threw an error. > The hypothetical JSON in draft-ietf-json-rfc4627bis-03 doesn=91t = include the word =92comment' or acknowledge that comments exist. This is = not an inconsistency? Nope. > If it isn't, we may need a new document "Real world JSON" that admits = that comments exist and offers advice on how to handle them! That could be considered later, certainly. Another thing that could be = considered later are extensions to JSON that people have proposed over = the years. Having said that, I believe your view that comments are in "Real world = JSON" is probably quite wrong, given that one of the most widely-used = libraries doesn't handle what you say. --Paul Hoffman= From tsaloranta@gmail.com Fri Sep 20 08:21:50 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B4F21F9A8C for ; Fri, 20 Sep 2013 08:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OR7YA+8fZqjx for ; Fri, 20 Sep 2013 08:21:49 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 34F1D21F9A49 for ; Fri, 20 Sep 2013 08:21:49 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id ez12so709345wid.15 for ; Fri, 20 Sep 2013 08:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Uu/WdIGOpfqfJQAiCWN00fq4usIW4YIezU6dkm0bVZg=; b=vS4MVo+/E7IkODBvvG9f8z3dbTbesrCIsHyxbfLYSOogjBZ8mZdCLRhz3XU3HN0gBz XPQUz5tYq04Kfxb/UXoMjWg2HTYdPPfk8+n2MyCTRbK4q9/R+knQqNE65w0IMRgZ6uyo iJPTZmlb87pVb3VqWujWfiW9zLn4E12bqtBt0ikEZ1Tomf1sNqMzsymXeikKjaEUUyCW rJNSID4Ayd3cobrF43W7Z+Uy/a9gigtMyFg8mceSxI0yEIbZ7fF908n6dmf6U8/Q4ev4 M2DSSh3g42BNi7vi8/C0A7SaIFzPs4LHRzt2aetYEMgLtOXx4CdkFPNhRnrLCerq073h YegA== MIME-Version: 1.0 X-Received: by 10.180.20.77 with SMTP id l13mr3238178wie.40.1379690502814; Fri, 20 Sep 2013 08:21:42 -0700 (PDT) Received: by 10.216.122.132 with HTTP; Fri, 20 Sep 2013 08:21:42 -0700 (PDT) In-Reply-To: <1EA739DD-F862-4AE1-94A0-75702051FE48@vpnc.org> References: <1EA739DD-F862-4AE1-94A0-75702051FE48@vpnc.org> Date: Fri, 20 Sep 2013 08:21:42 -0700 Message-ID: From: Tatu Saloranta To: Paul Hoffman Content-Type: multipart/alternative; boundary=bcaec53f346f5202c804e6d23a3f Cc: "Matt Miller \(mamille2\)" , jwilson , "" Subject: Re: [Json] JSON comments /* ... */ and // ... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 15:21:50 -0000 --bcaec53f346f5202c804e6d23a3f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Sep 20, 2013 at 7:44 AM, Paul Hoffman wrote= : > > > On Sep 19, 2013, at 7:46 PM, jwilson wrote: > > > Real JSON in the wild has comments. Real JSON processors handle these > comments. > > Some python parsers probably implement the style of comments you give, > even if they are not documented in RFC 4627 or ECMAScript. > > Some clearly don't. My first attempt to validate your statement (Python) > threw an error. > > > The hypothetical JSON in draft-ietf-json-rfc4627bis-03 doesn=91t includ= e > the word =92comment' or acknowledge that comments exist. This is not an > inconsistency? > > Nope. > > > If it isn't, we may need a new document "Real world JSON" that admits > that comments exist and offers advice on how to handle them! > > That could be considered later, certainly. Another thing that could be > considered later are extensions to JSON that people have proposed over th= e > years. > > Having said that, I believe your view that comments are in "Real world > JSON" is probably quite wrong, given that one of the most widely-used > libraries doesn't handle what you say. > > I can't really rank wide usage aspect to comment, but one thing worth noting is that some libraries default to strict handling, but allow explicit loosening of restrictions. So using default settings could fail, while library would be able to accept comments when explicitly enabled. I did that for Jackson (Java), since while I personally feel comments should always have been in JSON, I also think deviations from standards must be done explicitly, and only if user/dev indicates this is to be done. I think that having such settings is common with Java libraries; perhaps this is not done on other platforms. I also only added this after getting multiple requests by users to support this: so my data point (for what it is worth) is that there is enough such usage that users do expect support. So, I realize that such changes are not in scope of this update; but I hope this issue is included in a list of possible future work. It is one of more controversial subjects, mostly because JSON author feels strongly against addition, but where there isn't consensus as far as I know, regarding where inclusion itself would be right or wrong. Just that it may be impractical after being excluded for so long. -+ Tatu +- --bcaec53f346f5202c804e6d23a3f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 20, 2013 at 7:44 AM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:
<hat on>

On Sep 19, 2013, at 7:46 PM, jwilson <jwilson@squareup.com> wrote:

> Real JSON in the wild has comments. Real JSON processors handle these = comments.

Some python parsers probably implement the style of comments you give, even= if they are not documented in RFC 4627 or ECMAScript.

Some clearly don't. My first attempt to validate your statement (Python= ) threw an error.

> The hypothetical JSON in draft-ietf-json-rfc4627bis-03 doesn=91t inclu= de the word =92comment' or acknowledge that comments exist. This is not= an inconsistency?

Nope.

> If it isn't, we may need a new document "Real world JSON"= ; that admits that comments exist and offers advice on how to handle them!<= br>
That could be considered later, certainly. Another thing that could be cons= idered later are extensions to JSON that people have proposed over the year= s.

Having said that, I believe your view that comments are in "Real world= JSON" is probably quite wrong, given that one of the most widely-used= libraries doesn't handle what you say.


I can't really rank wide usage = aspect to comment, but one thing worth noting is that some libraries defaul= t to strict handling, but allow explicit loosening of restrictions.
So using default settings could fail, whil= e library would be able to accept comments when explicitly enabled.

=A0I did that for Jackson (Java), since wh= ile I personally feel comments should always have been in JSON, I also thin= k deviations from standards must be done explicitly, and only if user/dev i= ndicates this is to be done. I think that having such settings is common wi= th Java libraries; perhaps this is not done on other platforms.

I also only added this after getting m= ultiple requests by users to support this: so my data point (for what it is= worth) is that there is enough such usage that users do expect support.
So, I realize that such changes are no= t in scope of this update; but I hope this issue is included in a list of p= ossible future work. It is one of more controversial subjects, mostly becau= se JSON author feels strongly against addition, but where there isn't c= onsensus as far as I know, regarding where inclusion itself would be right = or wrong. Just that it may be impractical after being excluded for so long.=

-+ Ta= tu +-


--bcaec53f346f5202c804e6d23a3f-- From tbray@textuality.com Fri Sep 20 09:16:03 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCD321F9C47 for ; Fri, 20 Sep 2013 09:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5R4oM28mjZpj for ; Fri, 20 Sep 2013 09:15:58 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9262C21F9C40 for ; Fri, 20 Sep 2013 09:15:51 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id oy12so502903veb.13 for ; Fri, 20 Sep 2013 09:15:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tUjWl40m1gFSnXuuV5L75x0HjmEKXWbW78w8MqUec3I=; b=QQGPr1S6SxVwP+YT+fLsAlDOXwFSlRzUKoJcXVSC87wB0krJc8gd4UViEvCIUF7uim 7Vcdgto/6OjPgxrTRyCpXjqqs/QczoEgsdRsNKWuplUYq71edRnFqcQNusBsMjHkKLPk GZj/jUnXWqnySOLt6zvz/qB0M5JQeu+NoXT/DjlfPAwnlx9KcWjarrPkxZJXJzAzlDLi EmqRf1qUYapJg/H4+xM0DrFTQdJqK1GqB5FIXADNQH0uwh+jxKKY2EYQMAlIrfb+KS1m p56OoKqNf/IKagysSRJjylLc238Bw32ToqAzH8auQla35zdXQDJOnZakXJgeyj8rMBx4 Bsvw== X-Gm-Message-State: ALoCoQkigQp6oo1llH+IDLSY6M3JTKqx670+E1A8JJCekWcu5quq+iUqPYWh/YTnSIQ4diIJi9pH MIME-Version: 1.0 X-Received: by 10.58.218.225 with SMTP id pj1mr1395130vec.24.1379693750819; Fri, 20 Sep 2013 09:15:50 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Fri, 20 Sep 2013 09:15:50 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <523C15D5.8080006@it.aoyama.ac.jp> References: <523C15D5.8080006@it.aoyama.ac.jp> Date: Fri, 20 Sep 2013 09:15:50 -0700 Message-ID: From: Tim Bray To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=047d7bd7623eeab84504e6d2fb11 Cc: "json@ietf.org" Subject: Re: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 16:16:03 -0000 --047d7bd7623eeab84504e6d2fb11 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin, the only way we can settle that issue is in a remote location, at dawn. Pistols or rapiers? On Fri, Sep 20, 2013 at 2:31 AM, "Martin J. D=C3=BCrst" wrote: > +1, except that I would change "precision and magnitude" to "magnitude an= d > precision", because it sounds more natural (magnitude is the "bigger" of > the two things, and so deserves to come first). > > Regards, Martin. > > > On 2013/09/20 13:24, Tim Bray wrote: > >> In section 6, the language asserts that =E2=80=9Cwide interoperability= =E2=80=9D can be >> achieved by staying within the IEEE754 binary64 bounds. >> >> I think the reason we=E2=80=99re saying that is that we believe that sof= tware >> which >> correctly implements IEEE754 is generally available and widely used. So >> maybe we should just say that. And if we do, we might also point out >> that, >> on that basis, if your numbers are integers and of magnitude< 2**53, yo= u >> will achieve complete interoperability when your JSON is processed by su= ch >> software. >> >> So maybe rephrase to say: >> >> >> This specification allows implementations to set limits on the range of >> numbers accepted. While absolute interoperability cannot be guaranteed, >> wide interoperability can be achieved by limiting numbers in JSON texts = to >> those within the precision and magnitude expressible in an IEEE 754:2000= 8 >> binary64 (double precision) number [IEEE754], because software that >> correctly implements that standard is generally available and widely >> deployed. Note that when such software is used, numbers which are >> integers >> and of magnitude less than 2**53 will be interoperable in the sense that >> such implementations will agree exactly on the numeric values. >> >> Numeric values that cannot be represented in the grammar above (such as >> Infinity and NaN) are not permitted. Attempting to represent numbers tha= t >> cannot be exactly encoded as an IEEE 754:2008 binary64 number, such as >> 1E400, 9007199254740993, or 3.**141592653589793238462643383279**, may >> cause >> interoperability problems. >> >> >> Worth the change? >> >> >> >> >> ______________________________**_________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/**listinfo/json >> > --047d7bd7623eeab84504e6d2fb11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin, the only way we can settle that issue is in a remo= te location, at dawn. Pistols or rapiers?


On Fri, Sep 20, 2013 at 2:31 AM, &quo= t;Martin J. D=C3=BCrst" <duerst@it.aoyama.ac.jp> w= rote:
+1, except that I would change "precisi= on and magnitude" to "magnitude and precision", because it s= ounds more natural (magnitude is the "bigger" of the two things, = and so deserves to come first).

Regards, =C2=A0 Martin.


On 2013/09/20 13:24, Tim Bray wrote:
In section 6, the language asserts that =E2=80=9Cwide interoperability=E2= =80=9D can be
achieved by staying within the IEEE754 binary64 bounds.

I think the reason we=E2=80=99re saying that is that we believe that softwa= re which
correctly implements IEEE754 is generally available and widely used. =C2=A0= So
maybe we should just say that. =C2=A0And if we do, we might also point out = that,
on that basis, if your numbers are integers and of magnitude< =C2=A02**5= 3, you
will achieve complete interoperability when your JSON is processed by such<= br> software.

So maybe rephrase to say:

<new>
This specification allows implementations to set limits on the range of
numbers accepted. While absolute interoperability cannot be guaranteed,
wide interoperability can be achieved by limiting numbers in JSON texts to<= br> those within the precision and magnitude expressible in an IEEE 754:20008 binary64 (double precision) number [IEEE754], because software that
correctly implements that standard is generally available and widely
deployed. =C2=A0Note that when such software is used, numbers which are int= egers
and of magnitude less than 2**53 will be interoperable in the sense that such implementations will agree exactly on the numeric values.

Numeric values that cannot be represented in the grammar above (such as
Infinity and NaN) are not permitted. Attempting to represent numbers that cannot be exactly encoded as an IEEE 754:2008 binary64 number, such as
1E400, 9007199254740993, or 3.141592653589793238462643383279,= may cause
interoperability problems.
</new>

Worth the change?




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

--047d7bd7623eeab84504e6d2fb11-- From mamille2@cisco.com Fri Sep 20 09:44:22 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D0121F9A99 for ; Fri, 20 Sep 2013 09:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQDdvDmwpuQ9 for ; Fri, 20 Sep 2013 09:44:16 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 41D1121F9A65 for ; Fri, 20 Sep 2013 09:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6660; q=dns/txt; s=iport; t=1379695453; x=1380905053; h=from:to:subject:date:message-id:mime-version; bh=GGhfjeCINN/QUIOiamn2eVLc0kcaGiqcWsZVC6JTVpw=; b=evO9AtPCic8UTDYmdtPJRZZffXvzAY6dID906nzx6T5O8vwk51AL4T+5 AbesnhI9KdJVF57ya/7MELWS/aUhnw5jyoyXMSpivxK/hYM7mbVx61bT/ x1HFmPI4y8bYtfLiDNy+Ypto7IZVjsC+x/YkHPYUkHQkbzvqiWqLPDAPF Q=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOZ6PFKtJV2d/2dsb2JhbABbgweBCsE5gRoWdIInAQSBCwEqJjAnBBsGh3eZNqE6jzSDVoEAA5AmgS+YHYMkgio X-IronPort-AV: E=Sophos;i="4.90,945,1371081600"; d="p7s'?scan'208";a="262471218" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 20 Sep 2013 16:44:12 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8KGiC78028029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 20 Sep 2013 16:44:12 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.253]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 11:44:12 -0500 From: "Matt Miller (mamille2)" To: " WG" Thread-Topic: Outstanding Issues for 4627bis Thread-Index: AQHOtiCiDiA4k0sQukOVXg2WOoBOiw== Date: Fri, 20 Sep 2013 16:44:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.48] Content-Type: multipart/signed; boundary="Apple-Mail=_018A294C-8305-48E0-BFDF-8109B9A2254C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [Json] Outstanding Issues for 4627bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 16:44:22 -0000 --Apple-Mail=_018A294C-8305-48E0-BFDF-8109B9A2254C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello all, The chairs again thank Douglas Crockford for his contributions to date, = especially for the original RFC 4627. We also thank Tim Bray for taking = on editing 4627bis, and getting revision -03 published. Everyone please = review the latest revision and post any comments you have. The chairs are interested to know the Working Group's opinion on what = issues still exist for 4627bis. There is active discussion on further = refining numeric precision and Unicode terminology. Are there others = that need to be addressed? -- Paul Hoffman and Matt Miller --Apple-Mail=_018A294C-8305-48E0-BFDF-8109B9A2254C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5MjAxNjQ0 MTJaMCMGCSqGSIb3DQEJBDEWBBSotA7tgr4+fiXeqmNx1OUY2l+o5jCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAJHt CwLOMoFkBUOLrhmkeCC6zQIWPxVblJhgvdYlV/0p3WryPPs1UfdtzEv+0/KoSCQM4fA0VZNcQvr0 ImXfy1IHU9xDIleTj8z2FSi0NcSh2qRlF5awQYHaMJdvp0bYgd0XuAn07iJngeUIx8Yg0AeU2dyh WcKTCByIUfM5OQE/X8NPKWMxX0JkpFYazFcy59akXg4qfuQAa0kMGLeOxmM9TYLWgdF8kIxFfNBV 792CEllHGSPHb3XOmBYyHzenr1fP9FTqoKG3SnG6sgNgmH1v53+z71aJC1jcpc/lp+p7sOQ02HQ9 hcvP0FKDlUzkPP6dxDoVXzy6t46xPzOiVkkAAAAAAAA= --Apple-Mail=_018A294C-8305-48E0-BFDF-8109B9A2254C-- From mamille2@cisco.com Fri Sep 20 09:45:59 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA91121F9A44 for ; Fri, 20 Sep 2013 09:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-ZPXEOb5CHs for ; Fri, 20 Sep 2013 09:45:53 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C811921F9433 for ; Fri, 20 Sep 2013 09:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9248; q=dns/txt; s=iport; t=1379695553; x=1380905153; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JHigRQVglyKRErvc8RMEIHSVR4nVnSdd/A2g0nWVNm0=; b=e1EOLFprFj/lIVY0eNsGtvxylmVz1pGnHQIcpw12oCAMSNXF/0ALL5NZ kL3uIcbM8JgOz8nn2p4Ewt73E6xaKgC/etJVNaBY3kpJjwawGw7Ph6pVu 223OMaNcu5By/TljGKCI4Ih8r0IVVMK81byeIBTqgJZJdTZxyHP4i9tc6 o=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAF97PFKtJV2Z/2dsb2JhbABbgweBCsE5gRoWdIIlAQEBAwF5BQsCAQgOCgokAh8RJQIEDgUIBodlAwkGsHINiWqMd4I9MQeDHoEAA5AmgS+EPo4shTODJIFqJBw X-IronPort-AV: E=Sophos;i="4.90,945,1371081600"; d="p7s'?scan'208";a="262457023" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 20 Sep 2013 16:45:52 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8KGjqWs007339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Sep 2013 16:45:52 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.253]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 11:45:51 -0500 From: "Matt Miller (mamille2)" To: Tatu Saloranta Thread-Topic: [Json] JSON comments /* ... */ and // ... Thread-Index: AQHOtaL6LHy0QBh6tkGUlsjU8JkeopnOOoaAgAAFNgCAAMibAIAACmwAgAAXggA= Date: Fri, 20 Sep 2013 16:45:51 +0000 Message-ID: References: <1EA739DD-F862-4AE1-94A0-75702051FE48@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.48] Content-Type: multipart/signed; boundary="Apple-Mail=_2DEF1EC3-CFE5-4347-843C-A4FDB305AFA8"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" , Paul Hoffman , jwilson Subject: Re: [Json] JSON comments /* ... */ and // ... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 16:45:59 -0000 --Apple-Mail=_2DEF1EC3-CFE5-4347-843C-A4FDB305AFA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 20, 2013, at 9:21 AM, Tatu Saloranta = wrote: > On Fri, Sep 20, 2013 at 7:44 AM, Paul Hoffman = wrote: > >=20 > On Sep 19, 2013, at 7:46 PM, jwilson wrote: >=20 > > Real JSON in the wild has comments. Real JSON processors handle = these comments. >=20 > Some python parsers probably implement the style of comments you give, = even if they are not documented in RFC 4627 or ECMAScript. >=20 > Some clearly don't. My first attempt to validate your statement = (Python) threw an error. >=20 > > The hypothetical JSON in draft-ietf-json-rfc4627bis-03 doesn=91t = include the word =92comment' or acknowledge that comments exist. This is = not an inconsistency? >=20 > Nope. >=20 > > If it isn't, we may need a new document "Real world JSON" that = admits that comments exist and offers advice on how to handle them! >=20 > That could be considered later, certainly. Another thing that could be = considered later are extensions to JSON that people have proposed over = the years. >=20 > Having said that, I believe your view that comments are in "Real world = JSON" is probably quite wrong, given that one of the most widely-used = libraries doesn't handle what you say. >=20 >=20 > I can't really rank wide usage aspect to comment, but one thing worth = noting is that some libraries default to strict handling, but allow = explicit loosening of restrictions. > So using default settings could fail, while library would be able to = accept comments when explicitly enabled. >=20 > I did that for Jackson (Java), since while I personally feel comments = should always have been in JSON, I also think deviations from standards = must be done explicitly, and only if user/dev indicates this is to be = done. I think that having such settings is common with Java libraries; = perhaps this is not done on other platforms. >=20 > I also only added this after getting multiple requests by users to = support this: so my data point (for what it is worth) is that there is = enough such usage that users do expect support. >=20 > So, I realize that such changes are not in scope of this update; but I = hope this issue is included in a list of possible future work. It is one = of more controversial subjects, mostly because JSON author feels = strongly against addition, but where there isn't consensus as far as I = know, regarding where inclusion itself would be right or wrong. Just = that it may be impractical after being excluded for so long. >=20 > -+ Tatu +- /me dons hat The Working Group could decide to recharter to accomplish other goals; = support for comments could be under consideration. Others have = suggested canonicalization, best practices, and profiles, et cetera. = The current charter already states additional proposals will be = considered once -bis is "done". The chairs and our venerable Area Director request the Working Group = first complete its current milestone before trying to take on more work. = Bear with us! - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_2DEF1EC3-CFE5-4347-843C-A4FDB305AFA8 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5MjAxNjQ1 NTFaMCMGCSqGSIb3DQEJBDEWBBSufCoBPUJTW+sIcngEnlWLyfLCdTCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBADF/ 0yp8/hoqCJSnrbySdyklrRzpKWJu9bTcvXREcrjDhH57wkwSCli9Zpa0HVaA+D5sOgp1ptujmTiS Ql4qByrpzqrulqs1oaMpVx7WXEuvhoVaaoAWdvYN+p0w1zCWx5vMr7TloGs0K324EtoCRCgzBDZC DPfKaizlTT+8DLxqFRii7sZskXQRbQ/JFyEwRtGb6gnvq5Pk6mLT1/SoY58EXOZB6BRnHMrDSNLj YAWkrz1rbFpaiT6AufApRG131A/Rv3tcVoqae0Sdq+FGNOwml4U2sazAxXIzIVtGkIvOigVPyeXs ryy+N60qdSO/DHTiYuNkoko93KfE7OtQ1QIAAAAAAAA= --Apple-Mail=_2DEF1EC3-CFE5-4347-843C-A4FDB305AFA8-- From jorge@jorgechamorro.com Fri Sep 20 09:47:48 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDEF21F9CAD for ; Fri, 20 Sep 2013 09:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWfo-ASpnmmA for ; Fri, 20 Sep 2013 09:47:43 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id A622021F9CA8 for ; Fri, 20 Sep 2013 09:47:42 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id q59so748519wes.41 for ; Fri, 20 Sep 2013 09:47:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=aXfEF8eGh78XZfQ1Yw/RJ1N6x4PQ0V0PDruZFVvd8uo=; b=BNcs2gs/6cmMIu9sgh9BfN3H8fPfSovFJmHBEJtKV1KZ26CZtsYO8UY+FdYh877fIm 3b1RSXWsmX0ffddE8FQx02ePmpCSPTzROgQ0+2GXSBqFf8Dx2qU9wsiKRCSS2GvP2Q9O 5xFu52aQylBh6F0pkSs8shfGbkzFICSJjJJBHfAUr/CJ4ss+NZgvtU3+qjy7bhr2iL45 ay+k9kgPuV4QsRbC4R+6kI5aZYDSzbpuFwzwfWkLIhGIQhTUGgeyx2nxQTsPiMXqU21/ 8SoIohKr/PdWHgjdJfOrlS9GQOnK0SkWUtg5OGY7cO2eiQo2Dn1gXBxzc6OrPNjaHmLK Vrjw== X-Gm-Message-State: ALoCoQmw9+kfKwpz9Ic65+PAYP0MZsJXxZZ0aSF6dVnmvjNRqZL8gi81SWmWCgUmh5fhIVmLakL6 X-Received: by 10.180.9.69 with SMTP id x5mr3470920wia.41.1379695661802; Fri, 20 Sep 2013 09:47:41 -0700 (PDT) Received: from [192.168.10.50] (170.Red-83-41-147.dynamicIP.rima-tde.net. [83.41.147.170]) by mx.google.com with ESMTPSA id l9sm5757518wif.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Sep 2013 09:47:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: Date: Fri, 20 Sep 2013 18:47:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <51970539-6C60-4590-8C6A-230E83296468@jorgechamorro.com> References: To: Tim Bray X-Mailer: Apple Mail (2.1085) Cc: "json@ietf.org" Subject: Re: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 16:47:48 -0000 On 20/09/2013, at 06:24, Tim Bray wrote: > numbers which are integers and of magnitude less than 2**53 will be = interoperable in the sense that such implementations will agree exactly = on the numeric values. And > -2**53 The interval is (-2**53, 2**53). But I think it would be better to put it as [(-2**53)+1, (2**53)-1] to = emphasize that neither 2**53 nor -2**53 are 'safe', because it's a = *very* common mistake to assume that they are. --=20 ( Jorge )();= From jorge@jorgechamorro.com Fri Sep 20 09:55:33 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC0E21F96E4 for ; Fri, 20 Sep 2013 09:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUwhC9oMlTy0 for ; Fri, 20 Sep 2013 09:55:27 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id CB8DB21F9C46 for ; Fri, 20 Sep 2013 09:55:22 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hm2so9799155wib.10 for ; Fri, 20 Sep 2013 09:55:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=I/PXLYZx0IejGbunN1gYJ+v/b2Z6W9MPErY3A26bDAI=; b=NIHXDCZNpD4Eiy3E+uRBi/UynCDD64VRL7e95xlmRTA2fk2hQ6lfr/xRMY4/TctfpN LjIA1ibOffFrS1fWkFI1+xwWuFOCVtV0Q09ENVvAj/PhWupoSccGSjDaJx01dn0KF4ix Sv9KPVukiBwQ4ORXXkubpUMUeH8qyMY1Ea4pgsu9a2lR+e5Zi3XAW+foBpo2CSpEvuZK TLtjUX6KLR0rNl+pocHbfaBatPIJHFa91G5/DkmBge8kBIfDof48QbLapvF/DDzD18L+ J7P4hBs9nGQv+M1XxCpzQZoDmN+5GfB94PWPPIc3G4Oq6kk4UOPArkErKoAmMR1vcV9X jFNw== X-Gm-Message-State: ALoCoQlYwD6qM34LvyV5BTOpfHVtonORkGwwx/VhQ5gK8SJp7u2ZV//4pS03PnKHIv03eB6pdeIc X-Received: by 10.180.38.36 with SMTP id d4mr3504695wik.7.1379696121572; Fri, 20 Sep 2013 09:55:21 -0700 (PDT) Received: from [192.168.10.50] (170.Red-83-41-147.dynamicIP.rima-tde.net. [83.41.147.170]) by mx.google.com with ESMTPSA id ev4sm5816179wib.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Sep 2013 09:55:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: Date: Fri, 20 Sep 2013 18:55:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C6F7677-5184-43D1-AD59-1B6F2906D342@jorgechamorro.com> References: To: Tim Bray X-Mailer: Apple Mail (2.1085) Cc: "json@ietf.org" Subject: Re: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 16:55:33 -0000 On 20/09/2013, at 06:24, Tim Bray wrote: > expressible in an IEEE 754:20008 binary64 (double precision) number = [IEEE754] There's a typo: 20008 :-) --=20 ( Jorge )();= From johnl@iecc.com Fri Sep 20 10:01:58 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB8D21F99BD for ; Fri, 20 Sep 2013 10:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.608 X-Spam-Level: X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZrSawbfiRuf for ; Fri, 20 Sep 2013 10:01:53 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7C06621F99D0 for ; Fri, 20 Sep 2013 10:01:42 -0700 (PDT) Received: (qmail 1429 invoked from network); 20 Sep 2013 17:01:41 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Sep 2013 17:01:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=523c7f75.xn--3zv.k1309; i=johnl@user.iecc.com; bh=ntNnp+pt/5/bK3v+NhXV3Q0CEfnErKInR9aA8Ovsknk=; b=sP8Gxt2zX0iRBuBgStILc/6pqjpENxPYeA2bqdaq6+Fh3ulNuJubqmcsyEdfZZ/KJkIkm+UaQ+mazm4GhJHNVqxm9n02nqWewN8PRr1xNHI8oAvLGXeV31cA+MemCsPHhzPOreDVzyMZP47J5/zf2yAumSqPHML5g6BziaVahiRE35qV2CXRlnvHgWGfh9+hj3WgZ14PhcU1YMTGvj78RFOeV75FiK8ZH8BWiMpPm3qe4tmMcm8BciilDHLKHtVv DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=523c7f75.xn--3zv.k1309; olt=johnl@user.iecc.com; bh=ntNnp+pt/5/bK3v+NhXV3Q0CEfnErKInR9aA8Ovsknk=; b=g2x7uEitudrrj2f2GrODm0XzKVx+mxpVQOa8eJj9tbK9Iq9JXxIfnQV7YtbnrsbvZQaM3sFlujd7bma1eBoj7U8odE+3z35LQlB3nu2qy/Ywpj8BpLPM/ZqREjJ6IimCeT933IUjTSRrrwMypTmJovVcbo3U678/m0OTrtkuDKNvnCrNa5JuBQx7tzLKQFTER6xBSXXHE9cEW9s9zg+NAuFWuDbSrs8crBUVCyAv3c5b06C9w1DnY8ni3QzDbI/e Date: 20 Sep 2013 17:01:19 -0000 Message-ID: <20130920170119.34597.qmail@joyce.lan> From: "John Levine" To: json@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: tbray@textuality.com Subject: Re: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 17:01:58 -0000 In article you write: >-=-=-=-=-=- >-=-=-=-=-=- > >Martin, the only way we can settle that issue is in a remote location, at >dawn. Pistols or rapiers? This is the IETF. Cookies. From cowan@ccil.org Fri Sep 20 10:46:14 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA1821F9D0F for ; Fri, 20 Sep 2013 10:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.285 X-Spam-Level: X-Spam-Status: No, score=-3.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALubOP9EQSR6 for ; Fri, 20 Sep 2013 10:46:10 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1428921F9808 for ; Fri, 20 Sep 2013 10:46:09 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VN4mK-00048X-1z; Fri, 20 Sep 2013 13:46:04 -0400 Date: Fri, 20 Sep 2013 13:46:04 -0400 From: John Cowan To: Tim Bray Message-ID: <20130920174603.GC8075@mercury.ccil.org> References: <523C15D5.8080006@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Martin =?iso-8859-1?Q?J=2E_D=FCrst?= , "json@ietf.org" Subject: Re: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 17:46:14 -0000 Tim Bray scripsit: > Martin, the only way we can settle that issue is in a remote location, at > dawn. Pistols or rapiers? I think you mean "Rapiers or pistols?" -- Samuel Johnson on playing the violin: John Cowan "Difficult do you call it, Sir? cowan@ccil.org I wish it were impossible." http://www.ccil.org/~cowan From tbray@textuality.com Fri Sep 20 10:49:48 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EA921F9C89 for ; Fri, 20 Sep 2013 10:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9ZS+oyNGyiB for ; Fri, 20 Sep 2013 10:49:42 -0700 (PDT) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3F021F9609 for ; Fri, 20 Sep 2013 10:49:42 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id c14so611316vea.29 for ; Fri, 20 Sep 2013 10:49:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=CS4tgWVMp0Vk8z8dVhW05jUDalP/F4DdKf4/uZ/rB8c=; b=XzgEkvxAAdPIp9NalQTWftNFcISdy7kMRbxRQ3365dm4BUvfyJtwZTjDtk54c4xB0b RA0yo4WSViNdBeR9t02ztue7UNMTk6WgC4afxvLwNrXIu/8LV+hJidXZYjVt5FgtGLEj 1c1tyoc1hsDljdsFwfYdIcJJuor/7pHoNqtLETeNMK5CQP+yUf255EZrC2CRpoq5lEUM 7ZwAf24QCQHUk2AtMddL+2OtIMN2sxaK+HbSnVicoAzB0uUaGBxi+zNwCYXGfQ43KZ7c rD7TP0iS3q1qx0gy2dZvI/XW+QfGI6bvC8RjXS/ryY3wHOcZXOsnNmaeHHAjRZn/6kIe 9Ayw== X-Gm-Message-State: ALoCoQkloghXA7yMcc3RWaIhvQJqmX7By2q6fnFnD5ucN8B3Mfj48Awp06qkfqFq1VThisu48UDS MIME-Version: 1.0 X-Received: by 10.220.16.73 with SMTP id n9mr1774824vca.24.1379699381940; Fri, 20 Sep 2013 10:49:41 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Fri, 20 Sep 2013 10:49:41 -0700 (PDT) X-Originating-IP: [96.49.81.176] Date: Fri, 20 Sep 2013 10:49:41 -0700 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3bea08ec66d04e6d44b52 Subject: [Json] Dupe language on NaN & Infinity in -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 17:49:48 -0000 --001a11c3bea08ec66d04e6d44b52 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The consensus-call language that went into Section 6 includes =E2=80=9CNume= ric values that cannot be represented in the grammar above (such as Infinity and NaN) are not permitted.=E2=80=9D I=E2=80=99m not sure why this is here= ... the paragraph before the number grammar already reads =E2=80=9CNumeric values t= hat cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted.=E2=80=9D I think this is just a drafting error and we should remove this sentence from the last paragraph of section 6. --001a11c3bea08ec66d04e6d44b52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The consensus-call language that went into Section 6 = includes =E2=80=9CNumeric values that cannot be represented in the grammar = above (such as Infinity and NaN) are not permitted.=E2=80=9D=C2=A0 I=E2=80= =99m not sure why this is here... the paragraph before the number grammar a= lready reads =E2=80=9CNumeric values that cannot be represented as sequence= s of digits (such as Infinity and NaN) are not permitted.=E2=80=9D

I think this is just a drafting error and we should remove this s= entence from the last paragraph of section 6.


--001a11c3bea08ec66d04e6d44b52-- From jorge@jorgechamorro.com Fri Sep 20 11:02:34 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB3521F9D1F for ; Fri, 20 Sep 2013 11:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNFqMspIW2Of for ; Fri, 20 Sep 2013 11:02:28 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD6721F99DD for ; Fri, 20 Sep 2013 11:02:24 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id l18so836591wgh.4 for ; Fri, 20 Sep 2013 11:02:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=aeP0Hca0SwDHPZThw98HO0oTqR4ROAFU6xgqefiRPk4=; b=SsZqARPgUtGstkieMVfca6gXZvxAC0m5tVGIrCiUeBURDsJlyS8YkbeyeiN8DSzKxD hqd1njb42nPPmL4uUItV/ZvHmQTgSxJGBRzbQYoLFHLQaY/Ie9c7GiWIxawqtQpOVFLo tnDeaEB8NxyQviNbky4U0UgZ9Wur2ZTpbHXnWet/U2qcfJiWEMLlPpyxzv4FjDb2CdqQ CPpoCibKR4Qs2e88cZZEex736et+1Wv+RYudDIDlMTA5Rl3BFZfHO6MGVcDDLuOfJwvY ib6YfByZxg9oHHX2i8R8IWZPNT4eDiH967p51MlmesY7tI1dSEk5VzyTCGia4a8BG1PT A7Ag== X-Gm-Message-State: ALoCoQk/HAAQAP+W765/oYI1ri96vYlGOegNT554NS2KfZNyG8//9YiJe48y3gl02W/19I0iJF2Z X-Received: by 10.180.211.206 with SMTP id ne14mr3822332wic.30.1379700142348; Fri, 20 Sep 2013 11:02:22 -0700 (PDT) Received: from [192.168.10.50] (170.Red-83-41-147.dynamicIP.rima-tde.net. [83.41.147.170]) by mx.google.com with ESMTPSA id mw9sm3958743wib.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Sep 2013 11:02:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: <51970539-6C60-4590-8C6A-230E83296468@jorgechamorro.com> Date: Fri, 20 Sep 2013 20:02:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <40F25CFF-056E-4FA4-9053-785F2E724F9C@jorgechamorro.com> References: <51970539-6C60-4590-8C6A-230E83296468@jorgechamorro.com> To: "json@ietf.org WG" X-Mailer: Apple Mail (2.1085) Cc: Tim Bray Subject: Re: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 18:02:34 -0000 On 20/09/2013, at 18:47, Jorge Chamorro wrote: > On 20/09/2013, at 06:24, Tim Bray wrote: >=20 >> numbers which are integers and of magnitude less than 2**53 will be = interoperable in the sense that such implementations will agree exactly = on the numeric values. >=20 > And > -2**53 >=20 > The interval is (-2**53, 2**53). >=20 > But I think it would be better to put it as [(-2**53)+1, (2**53)-1] to = emphasize that neither 2**53 nor -2**53 are 'safe', because it's a = *very* common mistake to assume that they are. Oh well, I just realized that you wrote "of magnitude" so mathematically = it's right. But I'd use instead "absolute value". And something else to = emphasize that neither 2**53 nor -2**53 are 'safe', only the integers in = between them. --=20 ( Jorge )();= From cowan@ccil.org Fri Sep 20 12:49:11 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3442321F9AFE for ; Fri, 20 Sep 2013 12:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.316 X-Spam-Level: X-Spam-Status: No, score=-3.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o4+XR7B86Xo for ; Fri, 20 Sep 2013 12:49:06 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id DCA8721F8A38 for ; Fri, 20 Sep 2013 12:49:06 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VN6hM-0008LO-04; Fri, 20 Sep 2013 15:49:04 -0400 Date: Fri, 20 Sep 2013 15:49:03 -0400 From: John Cowan To: Tim Bray Message-ID: <20130920194903.GG8075@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Dupe language on NaN & Infinity in -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 19:49:11 -0000 Tim Bray scripsit: > I think this is just a drafting error and we should remove this sentence > from the last paragraph of section 6. We should remove it from one place or the other. -- John Cowan cowan@ccil.org http://ccil.org/~cowan If I have seen farther than others, it is because I was standing on the shoulders of giants. --Isaac Newton From tony@att.com Fri Sep 20 13:18:30 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86AC221F9E3B for ; Fri, 20 Sep 2013 13:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.443 X-Spam-Level: X-Spam-Status: No, score=-106.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tH596KrbknKd for ; Fri, 20 Sep 2013 13:18:23 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7B36E21F9E43 for ; Fri, 20 Sep 2013 13:18:23 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id f8dac325.0.4183470.00-110.11551170.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 20 Sep 2013 20:18:23 +0000 (UTC) X-MXL-Hash: 523cad8f790f6af3-77b2a56f56aa901098f829b8aee178e5382ef57c Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8KKIMMk009434 for ; Fri, 20 Sep 2013 16:18:22 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8KKIGkk009369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Sep 2013 16:18:21 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Fri, 20 Sep 2013 20:18:01 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8KKI1pF001853 for ; Fri, 20 Sep 2013 16:18:01 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8KKHui7001688 for ; Fri, 20 Sep 2013 16:17:59 -0400 Received: from [135.70.213.172] (vpn-135-70-213-172.vpn.east.att.com[135.70.213.172]) by maillennium.att.com (mailgw1) with ESMTP id <20130920201755gw1004nhm4e> (Authid: tony); Fri, 20 Sep 2013 20:17:56 +0000 X-Originating-IP: [135.70.213.172] Message-ID: <523CAD72.9080405@att.com> Date: Fri, 20 Sep 2013 16:17:54 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tim Bray References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=WrCcx6jv c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=mh2JtSt6KlAA:10 a=sCfsyOEanakA:10 a=Mxd2lbx1o0EA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=N659UExz7-8A:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=D9aYKWkxwpQA:10 a=MHMOU0lYH46qXKeMTLsA:9 a=pILNO] X-AnalysisOut: [xqGKmIA:10 a=n4x6vO1oZoxpP5kY:21 a=g3GKbEaFzS_rE7sd:21] Cc: "json@ietf.org" Subject: Re: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 20:18:30 -0000 On 9/20/2013 12:24 AM, Tim Bray wrote: > In section 6, the language asserts that “wide interoperability” can be > achieved by staying within the IEEE754 binary64 bounds. > > I think the reason we’re saying that is that we believe that software > which correctly implements IEEE754 is generally available and widely > used. So maybe we should just say that. And if we do, we might also > point out that, on that basis, if your numbers are integers and of > magnitude < 2**53, you will achieve complete interoperability when > your JSON is processed by such software. > > So maybe rephrase to say: > > > This specification allows implementations to set limits on the range > of numbers accepted. While absolute interoperability cannot be > guaranteed, wide interoperability can be achieved by limiting numbers > in JSON texts to those within the precision and magnitude expressible > in an IEEE 754:20008 binary64 (double precision) number [IEEE754], > because software that correctly implements that standard is generally > available and widely deployed. Note that when such software is used, > numbers which are integers and of magnitude less than 2**53 will be > interoperable in the sense that such implementations will agree > exactly on the numeric values. > > Numeric values that cannot be represented in the grammar above (such > as Infinity and NaN) are not permitted. Attempting to represent > numbers that cannot be exactly encoded as an IEEE 754:2008 binary64 > number, such as 1E400, 9007199254740993, or > 3.141592653589793238462643383279, may cause interoperability problems. > > > Worth the change? I think this is consistent with what was discussed on the call a few weeks ago. So +1 s/20008/2008/ Tony Hansen From tony@att.com Fri Sep 20 14:53:16 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E1921F9EAE for ; Fri, 20 Sep 2013 14:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.465 X-Spam-Level: X-Spam-Status: No, score=-106.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ckep6FYGZWSZ for ; Fri, 20 Sep 2013 14:53:09 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 193BA21F9E9D for ; Fri, 20 Sep 2013 14:53:07 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 2c3cc325.0.6102427.00-344.16941371.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 20 Sep 2013 21:53:07 +0000 (UTC) X-MXL-Hash: 523cc3c30f6b0c93-5af3b0b62b4f606ea933860a9640538095095b88 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8KLr6nV025467 for ; Fri, 20 Sep 2013 17:53:06 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8KLqrC2025372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Sep 2013 17:52:59 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor) for ; Fri, 20 Sep 2013 21:52:45 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8KLqjIF007681 for ; Fri, 20 Sep 2013 17:52:45 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8KLqdUS007562 for ; Fri, 20 Sep 2013 17:52:40 -0400 Received: from [135.70.213.172] (vpn-135-70-213-172.vpn.east.att.com[135.70.213.172]) by maillennium.att.com (mailgw1) with ESMTP id <20130920215237gw1004nhm5e> (Authid: tony); Fri, 20 Sep 2013 21:52:39 +0000 X-Originating-IP: [135.70.213.172] Message-ID: <523CC3A5.7000106@att.com> Date: Fri, 20 Sep 2013 17:52:37 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Cowan References: <20130920194903.GG8075@mercury.ccil.org> In-Reply-To: <20130920194903.GG8075@mercury.ccil.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=dr9s/Sc4 c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=mh2JtSt6KlAA:10 a=sCfsyOEanakA:10 a=EUfyvdrujCEA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=bvRzA_Xfa5QA:10 a=t71Dnl9FyUITuJGpsjsA:9 a=wPNLv] X-AnalysisOut: [fGTeEIA:10 a=ZQXALjhLKcMA:10 a=L7YtSnEAPtIA:10] Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Dupe language on NaN & Infinity in -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 21:53:16 -0000 On 9/20/2013 3:49 PM, John Cowan wrote: > Tim Bray scripsit: >> I think this is just a drafting error and we should remove this sentence >> from the last paragraph of section 6. > We should remove it from one place or the other. +1 From cabo@tzi.org Fri Sep 20 16:07:59 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B7721F9F01 for ; Fri, 20 Sep 2013 16:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmBOfbTrsB7R for ; Fri, 20 Sep 2013 16:07:54 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF5621F9EFE for ; Fri, 20 Sep 2013 16:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8KN7lJV000514; Sat, 21 Sep 2013 01:07:47 +0200 (CEST) Received: from [192.168.217.105] (p54893981.dip0.t-ipconnect.de [84.137.57.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 761FBE84; Sat, 21 Sep 2013 01:07:47 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Sat, 21 Sep 2013 01:07:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <609F997A-F10F-44EA-9834-8386229165F5@tzi.org> References: To: Tim Bray X-Mailer: Apple Mail (2.1510) Cc: "json@ietf.org" Subject: Re: [Json] Dupe language on NaN & Infinity in -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 23:07:59 -0000 On Sep 20, 2013, at 19:49, Tim Bray wrote: > Numeric values that cannot be represented as sequences of digits So 3.5 should not be permitted? I think this is the one that has to go. Gr=FC=DFe, Carsten From tbray@textuality.com Fri Sep 20 16:35:19 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6624B21F9D0A for ; Fri, 20 Sep 2013 16:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66TNe8QCNLeY for ; Fri, 20 Sep 2013 16:35:04 -0700 (PDT) Received: from mail-vb0-f47.google.com (mail-vb0-f47.google.com [209.85.212.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9529D21F9C6C for ; Fri, 20 Sep 2013 16:34:51 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id h10so792299vbh.20 for ; Fri, 20 Sep 2013 16:34:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h7H8es09jYP7u01xR1Ld5lsHwHf3Tv1O7C8jez8FrO4=; b=bIVC/ogg7NBv3FghPO52pphj5eEsN0tOVfVQ4Fam1SO9QDq6QyCLm9cLJJBDKz1XBk ZgcTOvMuPdKYB/4tGv8yQLQ8E+V1hQqEpXb6rHR1x59rTdMqmtGScD1UAi9GYAe/IX24 cKhJiH2nNX0sKMSiRiPqxRv1zLy5Bd+gbbcAJPUAJX01uo3Kn9+qxSiimdHhDVlwUpfw CFYg6EjiVwk1WqZLtvoZmsNElB8cSYh2e8Okq+fSRM3ovW+nWKE2iyqpPKEMFaD+FPx9 UepgzL0mKLC/OlqVjheZ+1sWknzCKQj/aX8ctGpyPDHlVcyAR2q4x5/i4Vokz45VJrdL JLUg== X-Gm-Message-State: ALoCoQm22jmpgCE6JuBS+Xi0AQMZVHZLDkVoLGm2t/feP3EVyXlV1qAjq0ficUTNm2nPU04JBqx/ MIME-Version: 1.0 X-Received: by 10.221.40.10 with SMTP id to10mr3589903vcb.22.1379720090830; Fri, 20 Sep 2013 16:34:50 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Fri, 20 Sep 2013 16:34:50 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <609F997A-F10F-44EA-9834-8386229165F5@tzi.org> References: <609F997A-F10F-44EA-9834-8386229165F5@tzi.org> Date: Fri, 20 Sep 2013 16:34:50 -0700 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11337576e75bc304e6d91df8 Cc: "json@ietf.org" Subject: Re: [Json] Dupe language on NaN & Infinity in -03 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 23:35:20 -0000 --001a11337576e75bc304e6d91df8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, the cleanest thing is to patch the text above the grammar to say =E2=80=9Ccannot be represented in the grammar below=E2=80=9D, and lose the = dupe text from the new interop material. Because nowhere else in the new material does it forbid or require things, and I=E2=80=99d like to keep it this way. The = =E2=80=9Csequences of digits=E2=80=9D language is just an erratum. On Fri, Sep 20, 2013 at 4:07 PM, Carsten Bormann wrote: > On Sep 20, 2013, at 19:49, Tim Bray wrote: > > > Numeric values that cannot be represented as sequences of digits > > So 3.5 should not be permitted? > > I think this is the one that has to go. > > Gr=C3=BC=C3=9Fe, Carsten > > --001a11337576e75bc304e6d91df8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, the cleanest thing is to patch the text above the gr= ammar to say =E2=80=9Ccannot be represented in the grammar below=E2=80=9D, = and lose the dupe text from the new interop material.=C2=A0 Because nowhere= else in the new material does it forbid or require things, and I=E2=80=99d= like to keep it this way.=C2=A0 The =E2=80=9Csequences of digits=E2=80=9D = language is just an erratum.


On Fri,= Sep 20, 2013 at 4:07 PM, Carsten Bormann <cabo@tzi.org> wrote:
On Sep 20, 2013, at 19:49, Tim Bray <tbray@textuality.com> wrote:

> Numeric values that cannot be represented as sequences of digits

So 3.5 should not be permitted?

I think this is the one that has to go.

Gr=C3=BC=C3=9Fe, Carsten


--001a11337576e75bc304e6d91df8-- From James.H.Manger@team.telstra.com Fri Sep 20 22:00:44 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEC921F9FBA for ; Fri, 20 Sep 2013 22:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=-0.970, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hdMt+HoELy7 for ; Fri, 20 Sep 2013 22:00:36 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 50A2C11E80F2 for ; Fri, 20 Sep 2013 22:00:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,951,1371045600"; d="scan'208";a="160829311" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 21 Sep 2013 15:00:32 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7204"; a="160057013" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcdvi.tcif.telstra.com.au with ESMTP; 21 Sep 2013 15:00:19 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Sat, 21 Sep 2013 15:00:19 +1000 From: "Manger, James H" To: "Matt Miller (mamille2)" , " WG" Date: Sat, 21 Sep 2013 15:00:18 +1000 Thread-Topic: json-pointer as URI fragment syntax for application/json Thread-Index: AQHOtiCiDiA4k0sQukOVXg2WOoBOi5nPn/rQ Message-ID: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2013 05:00:44 -0000 UkZDIDQ2MjcgZG9lc24ndCBkZWZpbmUgaG93IFVSSSBmcmFnbWVudHMgd29yayBmb3IgYXBwbGlj YXRpb24vanNvbiBjb250ZW50Lg0KDQpJdCB3b3VsZCBiZSBoZWxwZnVsIGZvciA0NjI3YmlzIHRv IHNheSB0aGF0IGEgZnJhZ21lbnQgKHRoYXQgYmVnaW5zIHdpdGggYSAiLyIgb3IgaXMgZW1wdHkp IGlzIGEgSlNPTiBQb2ludGVyIFtSRkMgNjkwMV0uIEEgSlNPTiBQb2ludGVyIGlkZW50aWZpZXMg YSBzcGVjaWZpYyB2YWx1ZSBpbiBhIEpTT04gdGV4dC4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoN Cj4gLS0tLS0tLS0tLQ0KPiBTdWJqZWN0OiBbSnNvbl0gT3V0c3RhbmRpbmcgSXNzdWVzIGZvciA0 NjI3YmlzDQo+IC4uLg0KPiBUaGUgY2hhaXJzIGFyZSBpbnRlcmVzdGVkIHRvIGtub3cgdGhlIFdv cmtpbmcgR3JvdXAncyBvcGluaW9uIG9uIHdoYXQNCj4gaXNzdWVzIHN0aWxsIGV4aXN0IGZvciA0 NjI3YmlzLiAgVGhlcmUgaXMgYWN0aXZlIGRpc2N1c3Npb24gb24gZnVydGhlcg0KPiByZWZpbmlu ZyBudW1lcmljIHByZWNpc2lvbiBhbmQgVW5pY29kZSB0ZXJtaW5vbG9neS4gIEFyZSB0aGVyZSBv dGhlcnMNCj4gdGhhdCBuZWVkIHRvIGJlIGFkZHJlc3NlZD8NCg0K From James.H.Manger@team.telstra.com Fri Sep 20 22:18:29 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A50D11E80F4 for ; Fri, 20 Sep 2013 22:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=-0.808, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrIuCmvAnBpB for ; Fri, 20 Sep 2013 22:18:23 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id D01E011E80F5 for ; Fri, 20 Sep 2013 22:18:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,951,1371045600"; d="scan'208";a="160831912" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 21 Sep 2013 15:18:21 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7204"; a="160697539" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipccvi.tcif.telstra.com.au with ESMTP; 21 Sep 2013 15:18:22 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Sat, 21 Sep 2013 15:18:21 +1000 From: "Manger, James H" To: Jorge Chamorro Date: Sat, 21 Sep 2013 15:18:19 +1000 Thread-Topic: [Json] Strengthen interop language on numbers? Thread-Index: Ac62ISVvZjBlQMg0Qx+Rz9JV0kjFggAZ7Mfw Message-ID: <255B9BB34FB7D647A506DC292726F6E115310592C9@WSMSG3153V.srv.dir.telstra.com> References: <51970539-6C60-4590-8C6A-230E83296468@jorgechamorro.com> In-Reply-To: <51970539-6C60-4590-8C6A-230E83296468@jorgechamorro.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2013 05:18:29 -0000 Sm9yZ2UsDQoNCj4gVGhlIGludGVydmFsIGlzICgtMioqNTMsIDIqKjUzKS4NCj4gDQo+IEJ1dCBJ IHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBwdXQgaXQgYXMgWygtMioqNTMpKzEsICgyKio1 MyktMV0gdG8NCj4gZW1waGFzaXplIHRoYXQgbmVpdGhlciAyKio1MyBub3IgLTIqKjUzIGFyZSAn c2FmZScsIGJlY2F1c2UgaXQncyBhDQo+ICp2ZXJ5KiBjb21tb24gbWlzdGFrZSB0byBhc3N1bWUg dGhhdCB0aGV5IGFyZS4NCg0KV2h5IGlzIHRoYXQgYSBtaXN0YWtlPw0KSSBiZWxpZXZlIGEgNjQt Yml0IGRvdWJsZSBjYW4gZXhhY3RseSByZXByZXNlbnQgKy8tMioqNTMuDQoyKio1MyBpbiA4IGJ5 dGVzIGlzIDQzIDQwIDAwIDAwIDAwIDAwIDAwIDAwLg0KDQpUaGUgZmlyc3QgaW50ZWdlciB5b3Ug Y2Fubm90IHJlcHJlc2VudCBpcyAyKio1MyArIDEuDQoNCi0tDQpKYW1lcyBNYW5nZXIgDQo= From jorge@jorgechamorro.com Sat Sep 21 08:24:51 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645AF21F90A7 for ; Sat, 21 Sep 2013 08:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bb4fT1atIaD for ; Sat, 21 Sep 2013 08:24:45 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 514C521F8FB6 for ; Sat, 21 Sep 2013 08:24:45 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id y10so1626321wgg.24 for ; Sat, 21 Sep 2013 08:24:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=RvgzhLLhMZ3sv4SdScxyEB/g3kcoz+1QxDCt9p4t558=; b=XJjG6E3CiJ4Uf/VtNd7uJQk+LkBc4mSZexMXh6HFV3nL5sZUo1Xf96MuecBH8fF+qL l3s9AGhF40gjDbDggJcvRzqbM4Ke2JiRVJDAV/XawCH3lRrgfKFzbT1a5aqJbZhP1F5n sJ4uxqBzrwWWSGl67M7uG261DohGreaVTWee6oul4aFqbhtVR8Q3Vqax9UhQ7CepYJmU 9hkt3yDmzz/xEBtdgdMdr2e1fAeEKpSj5TidTukWJpezeySRt889zVvjMSPHgorPm+Pg aVyl7JL28oCmkOJi6FDKQOeLPCbfc+Xh8VjqzosLMcCLpgbpxMHwnOdnyTLb57FwbK6J PL9A== X-Gm-Message-State: ALoCoQkGPxZhrLM9qvNBCitA2GVBf8oUWYqkKZsB6aOv/lMqPqRPR5vSLCobA4mPmEJpSMKp5AzB X-Received: by 10.180.91.16 with SMTP id ca16mr6701441wib.57.1379777084406; Sat, 21 Sep 2013 08:24:44 -0700 (PDT) Received: from [192.168.10.50] (160.Red-88-0-222.dynamicIP.rima-tde.net. [88.0.222.160]) by mx.google.com with ESMTPSA id ey4sm12654297wic.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 08:24:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115310592C9@WSMSG3153V.srv.dir.telstra.com> Date: Sat, 21 Sep 2013 17:24:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0656B646-A168-452B-A23D-FDA5CF574A9F@jorgechamorro.com> References: <51970539-6C60-4590-8C6A-230E83296468@jorgechamorro.com> <255B9BB34FB7D647A506DC292726F6E115310592C9@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1085) Cc: "json@ietf.org" Subject: Re: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2013 15:24:51 -0000 On 21/09/2013, at 07:18, Manger, James H wrote: > Jorge, >=20 >> The interval is (-2**53, 2**53). >>=20 >> But I think it would be better to put it as [(-2**53)+1, (2**53)-1] = to >> emphasize that neither 2**53 nor -2**53 are 'safe', because it's a >> *very* common mistake to assume that they are. >=20 > Why is that a mistake? > I believe a 64-bit double can exactly represent +/-2**53. > 2**53 in 8 bytes is 43 40 00 00 00 00 00 00. >=20 > The first integer you cannot represent is 2**53 + 1. Well yes and no. When you receive a (2**53)-1 you can be sure it's a = (2**53)-1 and nothing else, but when you receive a 2**53 it could be = both a 2**53 or a (2**53)+1, but you can't tell which one it was. N bits can represent numbers between 0 and (2**N)-1, but not 2**N = because it's one bit too long. There are 53 bits in the mantissa of an iee754 double, and 2**53 is 54 = bits long. What you get when you put a 2**53 in a 754:double is a 2**53 = with its last bit dropped, a bit pattern that represents both 2**53 and = (2**53)+1. So it's equal to itself + 1. If your JSON text happens to contain a 9007199254740993, the receiving = end will see it as a 9007199254740992. If your JSON text happens to contain a 9007199254740992, the receiving = can't tell for sure whether it was a 9007199254740992 or a = 9007199254740993. This also happens with (2**53)+2 and (2**53)+3, and with (2**53)+4 and = (2**53)+5, etc., all the way up, first in groups of 2, then in groups of = 4, etc., but 2**53 is at the frontier between the good and the evil and = is often thought to be good, although it's evil. It's not a safe integer and I think this deserves to be said in the RFC. Cheers, --=20 ( Jorge )();= From tbray@textuality.com Sat Sep 21 09:18:06 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984AA11E8132 for ; Sat, 21 Sep 2013 09:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78aLCfFjsTwX for ; Sat, 21 Sep 2013 09:18:01 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id B1E2021F9C05 for ; Sat, 21 Sep 2013 09:18:01 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id ld13so1108335vcb.25 for ; Sat, 21 Sep 2013 09:17:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cDSTleK+ZBHu5593ZB7RcqvJpWbKNNlYGPlYktSfD8Y=; b=WdCUrukUeKfN6CKJC5jJufWR2Z3UNoiF5XyRsmfbhnAgombA80y3aTrwbVV1PtYe50 0oDH2B9spvr2/QBJvFWR7ssudijouIbuQGUECxBTGRM7npgTVSz1Qndi09yY9zjsYUSZ RSwr22mrsHwFSXeJtH7GAhHN2y/i2GjNxisnLNknqF+v64MOl/D6wrEy+cbycn9T2zn5 gLuacmpujwxCk5cO43WHjJtSZxI8TUQUG95TwZigAiV4So9izSk49NIhob8PJkW5JiM8 tI5D1cgfwS8OPcBww75LK6XqUZb+SNCFCsEraZ/UZv+bolfDTcTURBU66sWXzxxJp9AD LNug== X-Gm-Message-State: ALoCoQnpPub3UGW6YaRLyfaW79Ti7hGKQWj6Pz424Qpbxrn11wjpwTlsRXzeODQAr/RsmJuPilho MIME-Version: 1.0 X-Received: by 10.52.230.102 with SMTP id sx6mr10250087vdc.15.1379780278598; Sat, 21 Sep 2013 09:17:58 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Sat, 21 Sep 2013 09:17:58 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <0656B646-A168-452B-A23D-FDA5CF574A9F@jorgechamorro.com> References: <51970539-6C60-4590-8C6A-230E83296468@jorgechamorro.com> <255B9BB34FB7D647A506DC292726F6E115310592C9@WSMSG3153V.srv.dir.telstra.com> <0656B646-A168-452B-A23D-FDA5CF574A9F@jorgechamorro.com> Date: Sat, 21 Sep 2013 09:17:58 -0700 Message-ID: From: Tim Bray To: Jorge Chamorro Content-Type: multipart/alternative; boundary=089e0111ae345fce9d04e6e7217d Cc: "Manger, James H" , "json@ietf.org" Subject: Re: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2013 16:18:06 -0000 --089e0111ae345fce9d04e6e7217d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, best suggestion I=E2=80=99ve heard yet is: =E2=80=9Cnumbers which are= integers and in the range [(-2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on the numeric values=E2=80=9D On Sat, Sep 21, 2013 at 8:24 AM, Jorge Chamorro wr= ote: > On 21/09/2013, at 07:18, Manger, James H wrote: > > > Jorge, > > > >> The interval is (-2**53, 2**53). > >> > >> But I think it would be better to put it as [(-2**53)+1, (2**53)-1] to > >> emphasize that neither 2**53 nor -2**53 are 'safe', because it's a > >> *very* common mistake to assume that they are. > > > > Why is that a mistake? > > I believe a 64-bit double can exactly represent +/-2**53. > > 2**53 in 8 bytes is 43 40 00 00 00 00 00 00. > > > > The first integer you cannot represent is 2**53 + 1. > > Well yes and no. When you receive a (2**53)-1 you can be sure it's a > (2**53)-1 and nothing else, but when you receive a 2**53 it could be both= a > 2**53 or a (2**53)+1, but you can't tell which one it was. > > N bits can represent numbers between 0 and (2**N)-1, but not 2**N because > it's one bit too long. > > There are 53 bits in the mantissa of an iee754 double, and 2**53 is 54 > bits long. What you get when you put a 2**53 in a 754:double is a 2**53 > with its last bit dropped, a bit pattern that represents both 2**53 and > (2**53)+1. > > So it's equal to itself + 1. > > If your JSON text happens to contain a 9007199254740993, the receiving en= d > will see it as a 9007199254740992. > If your JSON text happens to contain a 9007199254740992, the receiving > can't tell for sure whether it was a 9007199254740992 or a 90071992547409= 93. > > This also happens with (2**53)+2 and (2**53)+3, and with (2**53)+4 and > (2**53)+5, etc., all the way up, first in groups of 2, then in groups of = 4, > etc., but 2**53 is at the frontier between the good and the evil and is > often thought to be good, although it's evil. > > It's not a safe integer and I think this deserves to be said in the RFC. > > Cheers, > -- > ( Jorge )(); > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e0111ae345fce9d04e6e7217d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, best suggestion I=E2=80=99ve heard yet is: =E2=80=9C= numbers which are integers and in the range [(-2**53)+1, (2**53)-1] are int= eroperable in the sense that implementations will agree exactly on the nume= ric values=E2=80=9D


On Sat,= Sep 21, 2013 at 8:24 AM, Jorge Chamorro <jorge@jorgechamorro.com> wrote:
On 21/09/2013, at 07:18, M= anger, James H wrote:

> Jorge,
>
>> The interval is (-2**53, 2**53).
>>
>> But I think it would be better to put it as [(-2**53)+1, (2**53)-1= ] to
>> emphasize that neither 2**53 nor -2**53 are 'safe', becaus= e it's a
>> *very* common mistake to assume that they are.
>
> Why is that a mistake?
> I believe a 64-bit double can exactly represent +/-2**53.
> 2**53 in 8 bytes is 43 40 00 00 00 00 00 00.
>
> The first integer you cannot represent is 2**53 + 1.

Well yes and no. When you receive a (2**53)-1 you can be sure it'= s a (2**53)-1 and nothing else, but when you receive a 2**53 it could be bo= th a 2**53 or a (2**53)+1, but you can't tell which one it was.

N bits can represent numbers between 0 and (2**N)-1, but not 2**N because i= t's one bit too long.

There are 53 bits in the mantissa of an iee754 double, and 2**53 is 54 bits= long. What you get when you put a 2**53 in a 754:double is a 2**53 with it= s last bit dropped, a bit pattern that represents both 2**53 and (2**53)+1.=

So it's equal to itself + 1.

If your JSON text happens to contain a 9007199254740993, the receiving end = will see it as a 9007199254740992.
If your JSON text happens to contain a 9007199254740992, the receiving can&= #39;t tell for sure whether it was a 9007199254740992 or a 9007199254740993= .

This also happens with (2**53)+2 and (2**53)+3, and with (2**53)+4 and (2**= 53)+5, etc., all the way up, first in groups of 2, then in groups of 4, etc= ., but 2**53 is at the frontier between the good and the evil and is often = thought to be good, although it's evil.

It's not a safe integer and I think this deserves to be said in the RFC= .

Cheers,
--
( Jorge )();
_____________________= __________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e0111ae345fce9d04e6e7217d-- From masinter@adobe.com Sat Sep 21 11:42:21 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2F211E8181 for ; Sat, 21 Sep 2013 11:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.347 X-Spam-Level: X-Spam-Status: No, score=-6.347 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VONJaGazrU5l for ; Sat, 21 Sep 2013 11:42:16 -0700 (PDT) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id F125521F992A for ; Sat, 21 Sep 2013 11:42:15 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUj3og5asjqfEOXkZVObrHhpZ13mPZCjW@postini.com; Sat, 21 Sep 2013 11:42:16 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8LIcZiH018369; Sat, 21 Sep 2013 11:38:35 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8LIgAOU002710; Sat, 21 Sep 2013 11:42:10 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Sat, 21 Sep 2013 11:42:10 -0700 From: Larry Masinter To: Tim Bray , Jorge Chamorro Date: Sat, 21 Sep 2013 11:42:06 -0700 Thread-Topic: [Json] Strengthen interop language on numbers? Thread-Index: Ac625ipbRVl/dwvYQgeZVabTMeOiAQAEmecw Message-ID: References: <51970539-6C60-4590-8C6A-230E83296468@jorgechamorro.com> <255B9BB34FB7D647A506DC292726F6E115310592C9@WSMSG3153V.srv.dir.telstra.com> <0656B646-A168-452B-A23D-FDA5CF574A9F@jorgechamorro.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C68CB012D9182D408CED7B884F441D4D3481F53FBEnambxv01acorp_" MIME-Version: 1.0 Cc: "Manger, James H" , "json@ietf.org" Subject: Re: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2013 18:42:21 -0000 --_000_C68CB012D9182D408CED7B884F441D4D3481F53FBEnambxv01acorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b25kZXIgaWYgaXQgd291bGQgYmUgaGVscGZ1bCB0byBpbnZlcnQgdGhlIOKAnGludGVyb3Bl cmFibGXigJ0gZGlzY3Vzc2lvbiBieSB0YWxraW5nIGFib3V0IHRoZSBpbnRlcm9wZXJhYmlsaXR5 IG9mICDigJxjb25mb3JtaW5nIGltcGxlbWVudGF0aW9uc+KAnSByYXRoZXIgdGhhbiDigJxpbnRl cm9wZXJhYmxlIG51bWJlcnPigJ0uIFRoYXQgaXM6DQoNCkRlZmluZSDigJxjb25mb3JtaW5nIEpT T04gaW1wbGVtZW50YXRpb27igJ0gdG8gYmUgYSBKU09OIGltcGxlbWVudGF0aW9uIGNvbnNpc3Rp bmcgb2YNCg0KICogICBhIHBhcnNlciB3aGljaCByZWFkcyBKU09OIGFuZCBwcm9kdWNlcyBhbiBp bnRlcm5hbCBkYXRhIHN0cnVjdHVyZSwgYW5kDQogKiAgIGEgc2VyaWFsaXplciB3aGljaCB0YWtl cyBhbiBpbnRlcm5hbCBkYXRhIHN0cnVjdHVyZSBhbmQgY3JlYXRlcyBKU09OIHRleHQNCnN1Y2gg dGhhdCBzZXJpYWxpemUocGFyc2UoWCkpIGlzIGVxdWl2YWxlbnQgdG8gWA0KDQogKiAgIHVzaW5n IGEgKGRlZmluZWQpIGVxdWl2YWxlbmNlIHJlbGF0aW9uc2hpcA0KICogICBhcyBsb25nIGFzIFgg dXNlcyBudW1iZXJzIGluIHRoZSBmb2xsb3dpbmcgc2V0IChudW1iZXJzIHdoaWNoIGFyZSBpbnRl Z2VycyBpbiByYW5nZSBZIG9yIGZsb2F0aW5nIHBvaW50IG51bWJlcnMgc2F0aXNmeWluZyBwcm9w ZXJ0eSBaKQ0KDQpUaGF0IGlzLCBERUZJTkUgd2hhdCBjb25zdGl0dXRlcyBhbiBpbnRlcm9wZXJh YmxlIG51bWJlciwgZG9u4oCZdCB0cnkgdG8gZGlzY292ZXIgaXQuDQpJbXBsZW1lbnRhdGlvbnMg d2hpY2ggaGF2ZSBvbmx5IDEyLWJpdCBpbnRlZ2VycyBhcmUganVzdCBub3QgY29uZm9ybWluZyBp bXBsZW1lbnRhdGlvbnMgc2luY2UgdGhleSBkb27igJl0IHJvdW5kLXRyaXAgZXZlcnl0aGluZy4N Cg0KTGFycnkNCg0KDQoNCg0KDQoNCkZyb206IGpzb24tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Ompzb24tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRpbSBCcmF5DQpTZW50OiBTYXR1 cmRheSwgU2VwdGVtYmVyIDIxLCAyMDEzIDk6MTggQU0NClRvOiBKb3JnZSBDaGFtb3Jybw0KQ2M6 IE1hbmdlciwgSmFtZXMgSDsganNvbkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtKc29uXSBTdHJl bmd0aGVuIGludGVyb3AgbGFuZ3VhZ2Ugb24gbnVtYmVycz8NCg0KWWVhaCwgYmVzdCBzdWdnZXN0 aW9uIEnigJl2ZSBoZWFyZCB5ZXQgaXM6IOKAnG51bWJlcnMgd2hpY2ggYXJlIGludGVnZXJzIGFu ZCBpbiB0aGUgcmFuZ2UgWygtMioqNTMpKzEsICgyKio1MyktMV0gYXJlIGludGVyb3BlcmFibGUg aW4gdGhlIHNlbnNlIHRoYXQgaW1wbGVtZW50YXRpb25zIHdpbGwgYWdyZWUgZXhhY3RseSBvbiB0 aGUgbnVtZXJpYyB2YWx1ZXPigJ0NCg0KT24gU2F0LCBTZXAgMjEsIDIwMTMgYXQgODoyNCBBTSwg Sm9yZ2UgQ2hhbW9ycm8gPGpvcmdlQGpvcmdlY2hhbW9ycm8uY29tPG1haWx0bzpqb3JnZUBqb3Jn ZWNoYW1vcnJvLmNvbT4+IHdyb3RlOg0KT24gMjEvMDkvMjAxMywgYXQgMDc6MTgsIE1hbmdlciwg SmFtZXMgSCB3cm90ZToNCg0KPiBKb3JnZSwNCj4NCj4+IFRoZSBpbnRlcnZhbCBpcyAoLTIqKjUz LCAyKio1MykuDQo+Pg0KPj4gQnV0IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIHB1dCBp dCBhcyBbKC0yKio1MykrMSwgKDIqKjUzKS0xXSB0bw0KPj4gZW1waGFzaXplIHRoYXQgbmVpdGhl ciAyKio1MyBub3IgLTIqKjUzIGFyZSAnc2FmZScsIGJlY2F1c2UgaXQncyBhDQo+PiAqdmVyeSog Y29tbW9uIG1pc3Rha2UgdG8gYXNzdW1lIHRoYXQgdGhleSBhcmUuDQo+DQo+IFdoeSBpcyB0aGF0 IGEgbWlzdGFrZT8NCj4gSSBiZWxpZXZlIGEgNjQtYml0IGRvdWJsZSBjYW4gZXhhY3RseSByZXBy ZXNlbnQgKy8tMioqNTMuDQo+IDIqKjUzIGluIDggYnl0ZXMgaXMgNDMgNDAgMDAgMDAgMDAgMDAg MDAgMDAuDQo+DQo+IFRoZSBmaXJzdCBpbnRlZ2VyIHlvdSBjYW5ub3QgcmVwcmVzZW50IGlzIDIq KjUzICsgMS4NCldlbGwgeWVzIGFuZCBuby4gV2hlbiB5b3UgcmVjZWl2ZSBhICgyKio1MyktMSB5 b3UgY2FuIGJlIHN1cmUgaXQncyBhICgyKio1MyktMSBhbmQgbm90aGluZyBlbHNlLCBidXQgd2hl biB5b3UgcmVjZWl2ZSBhIDIqKjUzIGl0IGNvdWxkIGJlIGJvdGggYSAyKio1MyBvciBhICgyKio1 MykrMSwgYnV0IHlvdSBjYW4ndCB0ZWxsIHdoaWNoIG9uZSBpdCB3YXMuDQoNCk4gYml0cyBjYW4g cmVwcmVzZW50IG51bWJlcnMgYmV0d2VlbiAwIGFuZCAoMioqTiktMSwgYnV0IG5vdCAyKipOIGJl Y2F1c2UgaXQncyBvbmUgYml0IHRvbyBsb25nLg0KDQpUaGVyZSBhcmUgNTMgYml0cyBpbiB0aGUg bWFudGlzc2Egb2YgYW4gaWVlNzU0IGRvdWJsZSwgYW5kIDIqKjUzIGlzIDU0IGJpdHMgbG9uZy4g V2hhdCB5b3UgZ2V0IHdoZW4geW91IHB1dCBhIDIqKjUzIGluIGEgNzU0OmRvdWJsZSBpcyBhIDIq KjUzIHdpdGggaXRzIGxhc3QgYml0IGRyb3BwZWQsIGEgYml0IHBhdHRlcm4gdGhhdCByZXByZXNl bnRzIGJvdGggMioqNTMgYW5kICgyKio1MykrMS4NCg0KU28gaXQncyBlcXVhbCB0byBpdHNlbGYg KyAxLg0KDQpJZiB5b3VyIEpTT04gdGV4dCBoYXBwZW5zIHRvIGNvbnRhaW4gYSA5MDA3MTk5MjU0 NzQwOTkzLCB0aGUgcmVjZWl2aW5nIGVuZCB3aWxsIHNlZSBpdCBhcyBhIDkwMDcxOTkyNTQ3NDA5 OTIuDQpJZiB5b3VyIEpTT04gdGV4dCBoYXBwZW5zIHRvIGNvbnRhaW4gYSA5MDA3MTk5MjU0NzQw OTkyLCB0aGUgcmVjZWl2aW5nIGNhbid0IHRlbGwgZm9yIHN1cmUgd2hldGhlciBpdCB3YXMgYSA5 MDA3MTk5MjU0NzQwOTkyIG9yIGEgOTAwNzE5OTI1NDc0MDk5My4NCg0KVGhpcyBhbHNvIGhhcHBl bnMgd2l0aCAoMioqNTMpKzIgYW5kICgyKio1MykrMywgYW5kIHdpdGggKDIqKjUzKSs0IGFuZCAo MioqNTMpKzUsIGV0Yy4sIGFsbCB0aGUgd2F5IHVwLCBmaXJzdCBpbiBncm91cHMgb2YgMiwgdGhl biBpbiBncm91cHMgb2YgNCwgZXRjLiwgYnV0IDIqKjUzIGlzIGF0IHRoZSBmcm9udGllciBiZXR3 ZWVuIHRoZSBnb29kIGFuZCB0aGUgZXZpbCBhbmQgaXMgb2Z0ZW4gdGhvdWdodCB0byBiZSBnb29k LCBhbHRob3VnaCBpdCdzIGV2aWwuDQoNCkl0J3Mgbm90IGEgc2FmZSBpbnRlZ2VyIGFuZCBJIHRo aW5rIHRoaXMgZGVzZXJ2ZXMgdG8gYmUgc2FpZCBpbiB0aGUgUkZDLg0KDQpDaGVlcnMsDQotLQ0K KCBKb3JnZSApKCk7DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KanNvbiBtYWlsaW5nIGxpc3QNCmpzb25AaWV0Zi5vcmc8bWFpbHRvOmpzb25AaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pzb24NCg0K --_000_C68CB012D9182D408CED7B884F441D4D3481F53FBEnambxv01acorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPVByb2dJZCBjb250ZW50PVdv cmQuRG9jdW1lbnQ+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQg MTQiPjxtZXRhIG5hbWU9T3JpZ2luYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCI+PGxp bmsgcmVsPUZpbGUtTGlzdCBocmVmPSJjaWQ6ZmlsZWxpc3QueG1sQDAxQ0VCNkJGLjk5NzJGNjIw Ij48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQo8 bzpBbGxvd1BORy8+DQo8bzpEb05vdFJlbHlPbkNTUy8+DQo8L286T2ZmaWNlRG9jdW1lbnRTZXR0 aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6V29y ZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0KPHc6 R3JhbW1hclN0YXRlPkNsZWFuPC93OkdyYW1tYXJTdGF0ZT4NCjx3OlRyYWNrTW92ZXMvPg0KPHc6 VHJhY2tGb3JtYXR0aW5nLz4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlkYXRlQWdhaW5zdFNj aGVtYXMvPg0KPHc6U2F2ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0K PHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCjx3OkFs d2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4 dD4NCjx3OkRvTm90UHJvbW90ZVFGLz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8L3c6TGlkVGhl bWVPdGhlcj4NCjx3OkxpZFRoZW1lQXNpYW4+WC1OT05FPC93OkxpZFRoZW1lQXNpYW4+DQo8dzpM aWRUaGVtZUNvbXBsZXhTY3JpcHQ+WC1OT05FPC93OkxpZFRoZW1lQ29tcGxleFNjcmlwdD4NCjx3 OkNvbXBhdGliaWxpdHk+DQo8dzpEb05vdEV4cGFuZFNoaWZ0UmV0dXJuLz4NCjx3OkJyZWFrV3Jh cHBlZFRhYmxlcy8+DQo8dzpTcGxpdFBnQnJlYWtBbmRQYXJhTWFyay8+DQo8dzpFbmFibGVPcGVu VHlwZUtlcm5pbmcvPg0KPC93OkNvbXBhdGliaWxpdHk+DQo8bTptYXRoUHI+DQo8bTptYXRoRm9u dCBtOnZhbD0iQ2FtYnJpYSBNYXRoIi8+DQo8bTpicmtCaW4gbTp2YWw9ImJlZm9yZSIvPg0KPG06 YnJrQmluU3ViIG06dmFsPSImIzQ1Oy0iLz4NCjxtOnNtYWxsRnJhYyBtOnZhbD0ib2ZmIi8+DQo8 bTpkaXNwRGVmLz4NCjxtOmxNYXJnaW4gbTp2YWw9IjAiLz4NCjxtOnJNYXJnaW4gbTp2YWw9IjAi Lz4NCjxtOmRlZkpjIG06dmFsPSJjZW50ZXJHcm91cCIvPg0KPG06d3JhcEluZGVudCBtOnZhbD0i MTQ0MCIvPg0KPG06aW50TGltIG06dmFsPSJzdWJTdXAiLz4NCjxtOm5hcnlMaW0gbTp2YWw9InVu ZE92ciIvPg0KPC9tOm1hdGhQcj48L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8dzpMYXRlbnRTdHlsZXMgRGVmTG9ja2VkU3RhdGU9 ImZhbHNlIiBEZWZVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgRGVmU2VtaUhpZGRlbj0idHJ1ZSIgRGVm UUZvcm1hdD0iZmFsc2UiIERlZlByaW9yaXR5PSI5OSIgTGF0ZW50U3R5bGVDb3VudD0iMjY3Ij4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm9ybWFs Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Imhl YWRpbmcgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUi IE5hbWU9ImhlYWRpbmcgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGlu ZyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3Jt YXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjM5IiBOYW1lPSJ0b2MgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIzOSIgTmFtZT0idG9jIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMzkiIE5hbWU9InRvYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgNyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDgiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA5Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM1IiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJjYXB0aW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjEwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0 cnVlIiBOYW1lPSJUaXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIxIiBOYW1lPSJEZWZhdWx0IFBhcmFncmFwaCBGb250Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjExIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0aXRsZSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3Ryb25nIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIwIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJFbXBoYXNpcyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1OSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iVGFibGUgR3JpZCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i UGxhY2Vob2xkZXIgVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJObyBTcGFjaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJMaWdodCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJMaWdodCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJM aWdodCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYz IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g U2hhZGluZyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g U2hhZGluZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g TGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlz dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmciLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n IDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBMaXN0IDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlJldmlzaW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJMaXN0IFBhcmFncmFwaCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyOSIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iUXVvdGUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzAiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2Ug UXVvdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0 IDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBHcmlkIDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQg MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBB Y2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNo YWRpbmcgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5n IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcy IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJD b2xvcmZ1bCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3Jp ZCAxIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gR3JpZCAzIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50 IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n IDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2Nl bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlz dCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3Jm dWwgR3JpZCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TGlnaHQgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBB Y2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdy aWQgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIEdyaWQgMyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iRGFyayBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA2Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gTGlzdCAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNj ZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdy aWQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MTkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRy dWUiIE5hbWU9IlN1YnRsZSBFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIyMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIFJlZmVyZW5jZSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMiIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50 ZW5zZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9 InRydWUiIE5hbWU9IkJvb2sgVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzciIE5hbWU9IkJpYmxpb2dyYXBoeSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRp bmciLz4NCjwvdzpMYXRlbnRTdHlsZXM+DQo8L3htbD48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0K LyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGlu Z3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDsNCgltc28tZm9udC1jaGFyc2V0OjI7 DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCgltc28tZm9udC1waXRjaDp2YXJpYWJs ZTsNCgltc28tZm9udC1zaWduYXR1cmU6MCAyNjg0MzU0NTYgMCAwIC0yMTQ3NDgzNjQ4IDA7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAw IDAgMCAwIDAgMDsNCgltc28tZm9udC1jaGFyc2V0OjI7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1p bHk6YXV0bzsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6 MCAyNjg0MzU0NTYgMCAwIC0yMTQ3NDgzNjQ4IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0Ow0KCW1zby1mb250LWFs dDoiQ2VudHVyeSBHb3RoaWMiOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1m b250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1z aWduYXR1cmU6LTUyMDA5MjkyOSAxMDczNzg2MTExIDkgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDsNCglt c28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNv LWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MjAwODE2NjUgLTEw NzM3MTcxNTcgNDEgMCA2NjA0NyAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS11bmhpZGU6bm87 DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3Jw aGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0 LXVuZGVybGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpz aW5nbGU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiOw0KCW1zby1zdHls ZS11bmhpZGU6bm87fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsN Cgltc28tYW5zaS1mb250LXNpemU6MTEuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tYXNjaWktZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1o YW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5TcGVsbEUNCgl7bXNvLXN0eWxlLW5h bWU6IiI7DQoJbXNvLXNwbC1lOnllczt9DQpzcGFuLkdyYW1FDQoJe21zby1zdHlsZS1uYW1lOiIi Ow0KCW1zby1ncmFtLWU6eWVzO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGli cmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjsNCgltc28taGVhZGVyLW1hcmdpbjouNWluOw0KCW1zby1mb290ZXItbWFyZ2luOi41 aW47DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3Qt aWQ6MTY1ODg3NTE3NDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTEyMTY5NTI1MjggLTEwMTY4MjQ1MjQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyAxMF0+PHN0 eWxlPi8qIFN0eWxlIERlZmluaXRpb25zICovDQp0YWJsZS5Nc29Ob3JtYWxUYWJsZQ0KCXttc28t c3R5bGUtbmFtZToiVGFibGUgTm9ybWFsIjsNCgltc28tdHN0eWxlLXJvd2JhbmQtc2l6ZTowOw0K CW1zby10c3R5bGUtY29sYmFuZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbXNvLXBhZGRpbmct YWx0OjBpbiA1LjRwdCAwaW4gNS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2luOjBpbjsNCgltc28tcGFy YS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6 Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQo8L3N0 eWxlPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZSBzdHls ZT0ndGFiLWludGVydmFsOi41aW4nPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O21zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO2NvbG9yOiMxRjQ5N0QnPkkg d29uZGVyIGlmIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gaW52ZXJ0IHRoZSDigJxpbnRlcm9wZXJh Ymxl4oCdIGRpc2N1c3Npb24gYnkgdGFsa2luZyBhYm91dCB0aGUgaW50ZXJvcGVyYWJpbGl0eSA8 c3BhbiBjbGFzcz1HcmFtRT5vZiA8c3BhbiBzdHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+wqA8L3Nw YW4+4oCcPC9zcGFuPmNvbmZvcm1pbmcgaW1wbGVtZW50YXRpb25z4oCdIHJhdGhlciB0aGFuIOKA nGludGVyb3BlcmFibGUgbnVtYmVyc+KAnS4gVGhhdCBpczogPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBm YWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjttc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO21zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO2NvbG9yOiMxRjQ5 N0QnPkRlZmluZSDigJxjb25mb3JtaW5nIEpTT04gaW1wbGVtZW50YXRpb27igJ0gdG8gYmUgYSBK U09OIGltcGxlbWVudGF0aW9uIGNvbnNpc3Rpbmcgb2YgPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD48dWwgc3R5bGU9J21hcmdpbi10b3A6MGluJyB0eXBlPWRpc2M+PGxpIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nY29sb3I6IzFGNDk3RDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PGZvbnQg c2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+YSBwYXJzZXIgd2hpY2ggcmVhZHMgSlNPTiBhbmQg cHJvZHVjZXMgYW4gaW50ZXJuYWwgZGF0YSBzdHJ1Y3R1cmUsIGFuZDxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L2xpPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2NvbG9yOiMxRjQ5N0Q7bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjxmb250IHNpemU9MiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1D YWxpYnJpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiBh IDxzcGFuIGNsYXNzPVNwZWxsRT5zZXJpYWxpemVyPC9zcGFuPiB3aGljaCB0YWtlcyBhbiBpbnRl cm5hbCBkYXRhIHN0cnVjdHVyZSBhbmQgY3JlYXRlcyBKU09OIHRleHQgPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvbGk+PC91bD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9R3JhbUU+ PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjojMUY0OTdEJz5zdWNoPC9zcGFu PjwvZm9udD48L3NwYW4+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjttc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjojMUY0 OTdEJz4gdGhhdCBzZXJpYWxpemUocGFyc2UoWCkpIGlzIGVxdWl2YWxlbnQgdG8gWDxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+PHVsIHN0eWxlPSdtYXJnaW4tdG9wOjBpbicgdHlwZT1kaXNj PjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2NvbG9yOiMxRjQ5N0Q7bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzEnPjxmb250IHNpemU9MiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPnVzaW5nIGEgKGRlZmlu ZWQpIGVxdWl2YWxlbmNlIHJlbGF0aW9uc2hpcCA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9s aT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdjb2xvcjojMUY0OTdEO21zby1saXN0OmwwIGxl dmVsMSBsZm8xJz48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO21zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz5hcyBsb25nIGFzIFgg dXNlcyBudW1iZXJzIGluIHRoZSBmb2xsb3dpbmcgc2V0IChudW1iZXJzIHdoaWNoIGFyZSBpbnRl Z2VycyBpbiByYW5nZSBZIG9yIGZsb2F0aW5nIHBvaW50IG51bWJlcnMgc2F0aXNmeWluZyBwcm9w ZXJ0eSBaKTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2xpPjwvdWw+PHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7bXNv LWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6 ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjojMUY0OTdEJz5UaGF0IGlzLCBERUZJTkUgd2hh dCBjb25zdGl0dXRlcyBhbiBpbnRlcm9wZXJhYmxlIG51bWJlciwgZG9u4oCZdCB0cnkgdG8gZGlz Y292ZXIgaXQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjojMUY0OTdEJz5JbXBsZW1lbnRh dGlvbnMgd2hpY2ggaGF2ZSBvbmx5IDEyLWJpdCBpbnRlZ2VycyBhcmUganVzdCBub3QgY29uZm9y bWluZyBpbXBsZW1lbnRhdGlvbnMgc2luY2UgdGhleSBkb27igJl0IHJvdW5kLXRyaXAgZXZlcnl0 aGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7bXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7Y29sb3I6IzFGNDk3RCc+TGFycnk8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7Y29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj0iIzFmNDk3 ZCIgZmFjZT1DYWxpYnJpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGli cmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjttc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjxkaXYgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFs PjxiPjxmb250IHNpemU9MiBmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7bXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7Zm9udC13ZWlnaHQ6Ym9sZCc+RnJvbTo8L3NwYW4+PC9mb250 PjwvYj48Zm9udCBzaXplPTIgZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO21zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4ganNvbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86anNv bi1ib3VuY2VzQGlldGYub3JnXSA8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+T24g QmVoYWxmIE9mIDwvc3Bhbj48L2I+VGltIEJyYXk8YnI+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2Vp Z2h0OmJvbGQnPlNlbnQ6PC9zcGFuPjwvYj4gU2F0dXJkYXksIFNlcHRlbWJlciAyMSwgMjAxMyA5 OjE4IEFNPGJyPjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5Ubzo8L3NwYW4+PC9i PiBKb3JnZSBDaGFtb3Jybzxicj48Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+Q2M6 PC9zcGFuPjwvYj4gTWFuZ2VyLCBKYW1lcyBIOyBqc29uQGlldGYub3JnPGJyPjxiPjxzcGFuIHN0 eWxlPSdmb250LXdlaWdodDpib2xkJz5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJlOiBbSnNvbl0gU3Ry ZW5ndGhlbiBpbnRlcm9wIGxhbmd1YWdlIG9uIG51bWJlcnM/PG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4w cHQnPlllYWgsIGJlc3Qgc3VnZ2VzdGlvbiBJ4oCZdmUgaGVhcmQgeWV0IGlzOiDigJxudW1iZXJz IHdoaWNoIGFyZSBpbnRlZ2VycyBhbmQgaW4gdGhlIHJhbmdlIFsoLTIqKjUzKSsxLCAoMioqNTMp LTFdIGFyZSBpbnRlcm9wZXJhYmxlIGluIHRoZSBzZW5zZSB0aGF0IGltcGxlbWVudGF0aW9ucyB3 aWxsIGFncmVlIGV4YWN0bHkgb24gdGhlIG51bWVyaWMgdmFsdWVz4oCdPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWJvdHRvbToxMi4wcHQnPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5PbiBTYXQsIFNlcCAyMSwgMjAx MyBhdCA4OjI0IEFNLCBKb3JnZSBDaGFtb3JybyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvcmdlQGpv cmdlY2hhbW9ycm8uY29tIiB0YXJnZXQ9Il9ibGFuayI+am9yZ2VAam9yZ2VjaGFtb3Jyby5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPk9uIDIxLzA5 LzIwMTMsIGF0IDA3OjE4LCBNYW5nZXIsIEphbWVzIEggd3JvdGU6PGJyPjxicj4mZ3Q7IEpvcmdl LDxicj4mZ3Q7PGJyPiZndDsmZ3Q7IFRoZSBpbnRlcnZhbCBpcyAoLTIqKjUzLCAyKio1MykuPGJy PiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IEJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBw dXQgaXQgYXMgWygtMioqNTMpKzEsICgyKio1MyktMV0gdG88YnI+Jmd0OyZndDsgZW1waGFzaXpl IHRoYXQgbmVpdGhlciAyKio1MyBub3IgLTIqKjUzIGFyZSAnc2FmZScsIGJlY2F1c2UgaXQncyBh PGJyPiZndDsmZ3Q7ICp2ZXJ5KiBjb21tb24gbWlzdGFrZSB0byBhc3N1bWUgdGhhdCB0aGV5IGFy ZS48YnI+Jmd0Ozxicj4mZ3Q7IFdoeSBpcyB0aGF0IGEgbWlzdGFrZT88YnI+Jmd0OyBJIGJlbGll dmUgYSA2NC1iaXQgZG91YmxlIGNhbiBleGFjdGx5IHJlcHJlc2VudCArLy0yKio1My48YnI+Jmd0 OyAyKio1MyBpbiA4IGJ5dGVzIGlzIDQzIDQwIDAwIDAwIDAwIDAwIDAwIDAwLjxicj4mZ3Q7PGJy PiZndDsgVGhlIGZpcnN0IGludGVnZXIgeW91IGNhbm5vdCByZXByZXNlbnQgaXMgMioqNTMgKyAx LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTIuMHB0Jz5XZWxsIHllcyBhbmQgbm8uIFdoZW4geW91IHJlY2VpdmUgYSAoMioqNTMpLTEgeW91 IGNhbiBiZSBzdXJlIGl0J3MgYSAoMioqNTMpLTEgYW5kIG5vdGhpbmcgZWxzZSwgYnV0IHdoZW4g eW91IHJlY2VpdmUgYSAyKio1MyBpdCBjb3VsZCBiZSBib3RoIGEgMioqNTMgb3IgYSAoMioqNTMp KzEsIGJ1dCB5b3UgY2FuJ3QgdGVsbCB3aGljaCBvbmUgaXQgd2FzLjxicj48YnI+TiBiaXRzIGNh biByZXByZXNlbnQgbnVtYmVycyBiZXR3ZWVuIDAgYW5kICgyKipOKS0xLCBidXQgbm90IDIqKk4g YmVjYXVzZSBpdCdzIG9uZSBiaXQgdG9vIGxvbmcuPGJyPjxicj5UaGVyZSBhcmUgNTMgYml0cyBp biB0aGUgbWFudGlzc2Egb2YgYW4gaWVlNzU0IGRvdWJsZSwgYW5kIDIqKjUzIGlzIDU0IGJpdHMg bG9uZy4gV2hhdCB5b3UgZ2V0IHdoZW4geW91IHB1dCBhIDIqKjUzIGluIGEgNzU0OmRvdWJsZSBp cyBhIDIqKjUzIHdpdGggaXRzIGxhc3QgYml0IGRyb3BwZWQsIGEgYml0IHBhdHRlcm4gdGhhdCBy ZXByZXNlbnRzIGJvdGggMioqNTMgYW5kICgyKio1MykrMS48YnI+PGJyPlNvIGl0J3MgZXF1YWwg dG8gaXRzZWxmICsgMS48YnI+PGJyPklmIHlvdXIgSlNPTiB0ZXh0IGhhcHBlbnMgdG8gY29udGFp biBhIDkwMDcxOTkyNTQ3NDA5OTMsIHRoZSByZWNlaXZpbmcgZW5kIHdpbGwgc2VlIGl0IGFzIGEg OTAwNzE5OTI1NDc0MDk5Mi48YnI+SWYgeW91ciBKU09OIHRleHQgaGFwcGVucyB0byBjb250YWlu IGEgOTAwNzE5OTI1NDc0MDk5MiwgdGhlIHJlY2VpdmluZyBjYW4ndCB0ZWxsIGZvciBzdXJlIHdo ZXRoZXIgaXQgd2FzIGEgOTAwNzE5OTI1NDc0MDk5MiBvciBhIDkwMDcxOTkyNTQ3NDA5OTMuPGJy Pjxicj5UaGlzIGFsc28gaGFwcGVucyB3aXRoICgyKio1MykrMiBhbmQgKDIqKjUzKSszLCBhbmQg d2l0aCAoMioqNTMpKzQgYW5kICgyKio1MykrNSwgZXRjLiwgYWxsIHRoZSB3YXkgdXAsIGZpcnN0 IGluIGdyb3VwcyBvZiAyLCB0aGVuIGluIGdyb3VwcyBvZiA0LCBldGMuLCBidXQgMioqNTMgaXMg YXQgdGhlIGZyb250aWVyIGJldHdlZW4gdGhlIGdvb2QgYW5kIHRoZSBldmlsIGFuZCBpcyBvZnRl biB0aG91Z2h0IHRvIGJlIGdvb2QsIGFsdGhvdWdoIGl0J3MgZXZpbC48YnI+PGJyPkl0J3Mgbm90 IGEgc2FmZSBpbnRlZ2VyIGFuZCBJIHRoaW5rIHRoaXMgZGVzZXJ2ZXMgdG8gYmUgc2FpZCBpbiB0 aGUgUkZDLjxicj48YnI+Q2hlZXJzLDxicj48c3BhbiBjbGFzcz1ob2VuemI+PGZvbnQgY29sb3I9 IiM4ODg4ODgiPjxzcGFuIHN0eWxlPSdjb2xvcjojODg4ODg4Jz4tLTwvc3Bhbj48L2ZvbnQ+PC9z cGFuPjxmb250IGNvbG9yPSIjODg4ODg4Ij48c3BhbiBzdHlsZT0nY29sb3I6Izg4ODg4OCc+PGJy PjxzcGFuIGNsYXNzPWhvZW56Yj4oIEpvcmdlICkoKTs8L3NwYW4+PC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox Mi4wcHQnPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pmpzb24gbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpqc29uQGlldGYub3JnIj5qc29u QGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2pzb24iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2pzb248L2E+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD48L2Rpdj48L2Rp dj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_C68CB012D9182D408CED7B884F441D4D3481F53FBEnambxv01acorp_-- From tbray@textuality.com Sat Sep 21 16:09:24 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475A121F92B2 for ; Sat, 21 Sep 2013 16:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.582 X-Spam-Level: X-Spam-Status: No, score=-1.582 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcvqbJblcNLt for ; Sat, 21 Sep 2013 16:09:19 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD7721F90A7 for ; Sat, 21 Sep 2013 16:09:18 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id kw10so1345258vcb.1 for ; Sat, 21 Sep 2013 16:09:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=iIdSc/ISH0CXQBw/cLtVgLnbmxB9rouw1pxY7WnU4Bg=; b=YO4Vnhy8uEkO39PzeKraUREXhJ0EoH+cEHPS/oVaeF7TekztRtM6HgkXkxIwA5lcPX NJdGUMe4F309pq3ZOIAiz+C/ig6DUTSH2cqAULK7atPqq+DUDrz3oYaLPfRRzROBk6I3 DwOscorxL9gZpRPs+1IttU1qDeSTh+G28RKpPfKN8vgFDWu61QjxptMdQ4zX62bJPypd z5lthgdaCdVokUF/xaCnh6jtxi518zInmqfUVSDktnrV3I9STrPH2XY2tU6rxR10bNAX rpBrpgK3fHQItrn0Fs1tTuvBg6ANK+tFJ70wOR3JVz88bMvUYWHpp0cMLo+c3KKTyZcX 2/Fw== X-Gm-Message-State: ALoCoQlRm8dlAoH1je05aRzTfvMiLNa4C6tpr0/5FygJvEil0di8YanxkFPo2z7JUXeLD/AWSgTk MIME-Version: 1.0 X-Received: by 10.52.34.109 with SMTP id y13mr11809211vdi.8.1379804958426; Sat, 21 Sep 2013 16:09:18 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Sat, 21 Sep 2013 16:09:18 -0700 (PDT) X-Originating-IP: [24.84.235.32] Date: Sat, 21 Sep 2013 16:09:18 -0700 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=20cf30780c5c681b3004e6ece00c Subject: [Json] Interop problem report with number nasties X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2013 23:09:24 -0000 --20cf30780c5c681b3004e6ece00c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Deron Meranda commented on my blog at https://www.tbray.org/ongoing/When/201x/2013/09/18/Editing-JSON#c1379796840= .898519 None of these have bit me, but maybe they=E2=80=99re worth worrying about. = Deron=E2=80=99s comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D I know from having been involved with several JSON implementations in different languages, that there are still some real-world interoperability concerns that have not yet been addressed. These include: * Some implementations can not handle strings with the character U+0000, however encoded or escaped. This most often occurs when trying to embed raw binary data into a JSON value, and usually affects C language based implementations. * Negative zeros, whether -0 or -0.0 are distinct from 0 and 0.0. The IEEE floating point standard, as well as JavaScript, require the negative sign for floating-point zeros to be preserved. Other implementations may not. So encoding a -0.0 in JSON may lead to interoperability problems. I've not seen any implementations that preserves negatives for integer zeros. * Integer vs. floating point. The JSON spec makes no distinction between integer or floating point numbers. However most, but not all, JSON implementations do, so again this can lead to interoperability problems. Some implementations may treat 1.0, 1E3, 1000E-2, etc. as integers; as mathematically they are. Adding some language about the "interpretation" of numbers in JSON may be welcome. --20cf30780c5c681b3004e6ece00c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
None of these have bit me, but maybe they=E2=80=99re worth worryi= ng about. Deron=E2=80=99s comment:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I know from having b= een involved with several JSON implementations in different languages, that= there are still some real-world interoperability concerns that have not ye= t been addressed. These include:

* Some implementations can not handle strings with the character U+0000= , however encoded or escaped. This most often occurs when trying to embed r= aw binary data into a JSON value, and usually affects C language based impl= ementations.

* Negative zeros, whether -0 or -0.0 are distinct from 0 and 0.0. The I= EEE floating point standard, as well as JavaScript, require the negative si= gn for floating-point zeros to be preserved. Other implementations may not.= So encoding a -0.0 in JSON may lead to interoperability problems. I've= not seen any implementations that preserves negatives for integer zeros.
* Integer vs. floating point. The JSON spec makes no distinction betwee= n integer or floating point numbers. However most, but not all, JSON implem= entations do, so again this can lead to interoperability problems. Some imp= lementations may treat 1.0, 1E3, 1000E-2, etc. as integers; as mathematical= ly they are. Adding some language about the "interpretation" of n= umbers in JSON may be welcome.
--20cf30780c5c681b3004e6ece00c-- From cowan@ccil.org Sat Sep 21 18:48:17 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B6B11E81EC for ; Sat, 21 Sep 2013 18:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.329 X-Spam-Level: X-Spam-Status: No, score=-1.329 tagged_above=-999 required=5 tests=[AWL=-1.755, BAYES_20=-0.74, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDLKjj0V3MMn for ; Sat, 21 Sep 2013 18:48:01 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0847111E81F5 for ; Sat, 21 Sep 2013 18:47:59 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VNYmD-0001b4-4f; Sat, 21 Sep 2013 21:47:57 -0400 Date: Sat, 21 Sep 2013 21:47:57 -0400 From: John Cowan To: Tim Bray Message-ID: <20130922014757.GB29699@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Interop problem report with number nasties X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Sep 2013 01:48:17 -0000 Tim Bray scripsit: > * Some implementations can not handle strings with the character U+0000, > however encoded or escaped. This most often occurs when trying to embed raw > binary data into a JSON value, and usually affects C language based > implementations. I think this should be included. > * Negative zeros, whether -0 or -0.0 are distinct from 0 and 0.0. The IEEE > floating point standard, as well as JavaScript, require the negative sign > for floating-point zeros to be preserved. Other implementations may not. So > encoding a -0.0 in JSON may lead to interoperability problems. I've not > seen any implementations that preserves negatives for integer zeros. This too. > * Integer vs. floating point. The JSON spec makes no distinction between > integer or floating point numbers. However most, but not all, JSON > implementations do, so again this can lead to interoperability problems. > Some implementations may treat 1.0, 1E3, 1000E-2, etc. as integers; as > mathematically they are. Adding some language about the "interpretation" of > numbers in JSON may be welcome. I can't see this as making any difference: it is purely a difference in the internal model, which is no concern of this RFC. -- Real FORTRAN programmers can program FORTRAN John Cowan in any language. --Ed Post cowan@ccil.org From tbray@textuality.com Sat Sep 21 22:54:42 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19F211E80D3 for ; Sat, 21 Sep 2013 22:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN1Vul6GPBD8 for ; Sat, 21 Sep 2013 22:54:36 -0700 (PDT) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id AA24921F9F2D for ; Sat, 21 Sep 2013 22:54:36 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id c14so1578313vea.1 for ; Sat, 21 Sep 2013 22:54:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=5PIhRU7sK9akm0RWrdOJLQmUkrT19ThklzQgDB9qR1c=; b=ZuqHRrjT6pDBEfWp9KuJhOZ/ZEQWyBTUtaF9eYcg/407q6zdjRj4k1aiTABYDSxhFC ENhRpvEJO2M5kH0B7xjjxCMbY5ViSntMeb8qydwss19EX8sS/+Vsij3djwS7Q9j/IJ25 YkIdVZhcTIWz8HYtEc34X3uBVjAkVSSeiWSVZSbKJYtSNgkKEQILP9gxbQUQBf5dzkWk qveQ7XWZbo7N3fEgysK8kTHRqZFhOKCNiCdFLlxAQ4g1QqEuTCxwHG4E/wXreEdMf5bt Qyfkbh95YpDxhwT2BB2hkjfErPOcR4PFIcza5LxPHQxyyZDrKKxCFM6voaa/SDOIxqE9 v4Bg== X-Gm-Message-State: ALoCoQmd6SCfEJezav+OGJ6ZAgYWwnIiOg+yzt3dRYSfBYjYsPN/3/EO8xWy8A9qrqq1yUO05Kxq MIME-Version: 1.0 X-Received: by 10.58.161.116 with SMTP id xr20mr14983566veb.2.1379829275761; Sat, 21 Sep 2013 22:54:35 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Sat, 21 Sep 2013 22:54:35 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Sat, 21 Sep 2013 22:54:35 -0700 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7b6dcc96d5d12c04e6f28914 Subject: Re: [Json] Interop problem report with number nasties X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Sep 2013 05:54:42 -0000 --047d7b6dcc96d5d12c04e6f28914 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Replying to myself. The point about embedded zeros seems worth a one-line warning; as an old C-lang hacker, I can certainly believe in the possibility of breakage. Can someone provide an example of a situation where +/-0 would cause an actual practical problem? I can=E2=80=99t. As for integer-or-not, pfui, that=E2=80=99s up to implementers to not be st= upid with. -T On Sat, Sep 21, 2013 at 4:09 PM, Tim Bray wrote: > Deron Meranda commented on my blog at > https://www.tbray.org/ongoing/When/201x/2013/09/18/Editing-JSON#c13797968= 40.898519 > > None of these have bit me, but maybe they=E2=80=99re worth worrying about= . Deron=E2=80=99s > comment: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > I know from having been involved with several JSON implementations in > different languages, that there are still some real-world interoperabilit= y > concerns that have not yet been addressed. These include: > > * Some implementations can not handle strings with the character U+0000, > however encoded or escaped. This most often occurs when trying to embed r= aw > binary data into a JSON value, and usually affects C language based > implementations. > > * Negative zeros, whether -0 or -0.0 are distinct from 0 and 0.0. The IEE= E > floating point standard, as well as JavaScript, require the negative sign > for floating-point zeros to be preserved. Other implementations may not. = So > encoding a -0.0 in JSON may lead to interoperability problems. I've not > seen any implementations that preserves negatives for integer zeros. > > * Integer vs. floating point. The JSON spec makes no distinction between > integer or floating point numbers. However most, but not all, JSON > implementations do, so again this can lead to interoperability problems. > Some implementations may treat 1.0, 1E3, 1000E-2, etc. as integers; as > mathematically they are. Adding some language about the "interpretation" = of > numbers in JSON may be welcome. > --047d7b6dcc96d5d12c04e6f28914 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Replying to myself. The point about embedded zeros se= ems worth a one-line warning; as an old C-lang hacker, I can certainly beli= eve in the possibility of breakage.

Can someone provide an exa= mple of a situation where +/-0 would cause an actual practical problem? I c= an=E2=80=99t.

As for integer-or-not, pfui, that=E2=80=99s up to implementers to not b= e stupid with.=C2=A0 -T


On Sat, Sep 21, 2013 at 4:09 PM, Tim Bray <tbray@te= xtuality.com> wrote:
None of these have bit me, but maybe they=E2=80=99re worth worryi= ng about. Deron=E2=80=99s comment:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I know from having b= een involved with several JSON implementations in different languages, that= there are still some real-world interoperability concerns that have not ye= t been addressed. These include:

* Some implementations can not handle strings with the character U+0000= , however encoded or escaped. This most often occurs when trying to embed r= aw binary data into a JSON value, and usually affects C language based impl= ementations.

* Negative zeros, whether -0 or -0.0 are distinct from 0 and 0.0. The I= EEE floating point standard, as well as JavaScript, require the negative si= gn for floating-point zeros to be preserved. Other implementations may not.= So encoding a -0.0 in JSON may lead to interoperability problems. I've= not seen any implementations that preserves negatives for integer zeros.
* Integer vs. floating point. The JSON spec makes no distinction betwee= n integer or floating point numbers. However most, but not all, JSON implem= entations do, so again this can lead to interoperability problems. Some imp= lementations may treat 1.0, 1E3, 1000E-2, etc. as integers; as mathematical= ly they are. Adding some language about the "interpretation" of n= umbers in JSON may be welcome.

--047d7b6dcc96d5d12c04e6f28914-- From cabo@tzi.org Sun Sep 22 00:31:17 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119F521F9E02 for ; Sun, 22 Sep 2013 00:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.505 X-Spam-Level: X-Spam-Status: No, score=-105.505 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHi3eyPxrLJ3 for ; Sun, 22 Sep 2013 00:31:05 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D140E21F9E01 for ; Sun, 22 Sep 2013 00:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8M7Uwqw001605; Sun, 22 Sep 2013 09:31:01 +0200 (CEST) Received: from [192.168.217.105] (p5489315D.dip0.t-ipconnect.de [84.137.49.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5B76DF8F; Sun, 22 Sep 2013 09:30:58 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Sun, 22 Sep 2013 09:30:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2589A1DC-2DF8-464A-B5B8-2A6312BAA184@tzi.org> References: To: Tim Bray X-Mailer: Apple Mail (2.1510) Cc: "json@ietf.org" Subject: Re: [Json] Interop problem report with number nasties X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Sep 2013 07:31:17 -0000 On Sep 22, 2013, at 01:09, Tim Bray wrote: > So encoding a -0.0 in JSON may lead to interoperability problems.=20 As with the other number issues, it is not the encoding of a specific = value by a sender that leads to an interoperability problem, but the = sender relying on a specific interpretation of that value by the = recipient. Here, an interoperability problem would be caused if the sender relies = on the recipient preserving the negativeness of the number, or on it = differentiating it from a positive zero. Say, if the required application semantics is that of a lookup table = (alist), and a sender sends; [[-2, "joe"], [-1, "jill"], [-0, "bob"], [0, "jack"], [1, "alice"], [2, "john"]] Similar, a sender might rely on the recipient to preserve differences in = encoding the same number, such as 0 vs. 0.0 vs. 0e0. Example: [[0, "joe"], [0.0, "jill"], [0.00, "bob"], [0e0, "jack"], [0e00, "alice"]] Many programming languages make a strong distinction between NR1 (1) on = one hand and NR2 (1.0) and NR3 (1e0) on the other hand. Since the JSON = spec says numbers look like they do in programming languages, inferring = that there is a difference between them may be an excusable = misinterpretation. (I don't think anyone would justify relying on = distinguishing 0e0 and 0e00, and only very few people would claim that = 0.0 clearly differs from 0.00.) I don't want to beat dead horses, but the interoperability issues come = from us not defining the data model, but relying on implementers to pick = it up from their background knowledge -- that background knowledge does = differ in such details. Example 2: 1 vs. 1.0. https://jira.talendforge.org/browse/TDI-26517 is a random example of a bug report highlighting a data model problem. The bug reporter expected the JSON library to make available to the application a number as an Integer type independent of whether it was notated sign-digits only (ISO 6093 "NR1", "integer") or has a decimal point and/or an exponent (ISO 6093 "NR2/NR3", "real"). They were rebuffed by the developer stating that JSON numbers notated as "real"s can't be integers in the decoder's data model. (Historically, most programming languages have made such a distinction in number literals. While RFC 4627 says, "The representation of numbers is similar to that used in most programming languages.", this is expressly about the representation, not the data model.) Gr=FC=DFe, Carsten PS.: Fun with just two implementations: >> require 'json' =3D> true >> JSON.load('[-0]') =3D> [0] >> JSON.load('[-0.0]') =3D> [-0.0] >> require 'oj' =3D> true >> Oj.load('[-0]') =3D> [0] >> Oj.load('[-0.0]') =3D> [-0.0] But: >> Oj.load('[-0e0]') =3D> [0] >> JSON.load('[-0e0]') =3D> [-0.0] So this is an example where 1) the apparent floatingpointness of the number influences the = preservation of the negativeness 2) the interpretation of the floatingpointness differs between = implementations. From barryleiba@gmail.com Sun Sep 22 08:16:29 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC17511E80F7 for ; Sun, 22 Sep 2013 08:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.974 X-Spam-Level: X-Spam-Status: No, score=-101.974 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tglrtjIvFniQ for ; Sun, 22 Sep 2013 08:16:29 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 33AF521F9FE9 for ; Sun, 22 Sep 2013 08:16:28 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id k4so886598qaq.11 for ; Sun, 22 Sep 2013 08:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=m1wLXAjP17y4zJS549jd5YXrL7nupgGAsBR2V98gQUY=; b=XWWG4HOQTYU+Y2z8OnF0cbdGc65bKm27ZSCpys1f4Z+6yDidHsBQMykjHgw083/hFc yLMIWHQjka9qDZJBLhr0YtOhZ+SDiWSdFeJg4TwSJ6PXhTvA/lNh7mSoBRxObKKqDpXT COzPGKo961A7ka+kE00+Iyezv+GxKkKvfZ4Z2WQ/oCKelMQpxPxmcf67tL3eZMCWqhwH /sWdmeZl26ipwGEXjzjfwQ2NXQSV3YceDbXB7mM9b2SNoOSt222Hx6OfwMxuJmU39Muy 0tAmMwYZsZogUbeEZ2q5jjEmTJgtgZVHaxEh2YC5cF7hpOpi31Nr8QpUYLuX0hB4TBIB te+A== MIME-Version: 1.0 X-Received: by 10.229.191.7 with SMTP id dk7mr24730649qcb.4.1379862987619; Sun, 22 Sep 2013 08:16:27 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.67.130 with HTTP; Sun, 22 Sep 2013 08:16:27 -0700 (PDT) Date: Sun, 22 Sep 2013 11:16:27 -0400 X-Google-Sender-Auth: 0KB6gHOfJIB-FBLuRpWanPUJkH0 Message-ID: From: Barry Leiba To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [Json] Small ABNF change to do some semantic separation X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Sep 2013 15:16:29 -0000 The repute working group has defined a response object in JSON.[1] At first they did it using ABNF. That means that it (badly) duplicated the ABNF that's already in 4627, trying to say where "ws" can go, defining what has to have DQUOTE around it (for which the repute doc used "%x22"), worrying about when to use value-separator and when to use name-separator (and sometimes using "," instead, in some versions), using "{" instead of citing begin-object, and so on. It was messy, error-prone, and subject to deviations from JSON ABNF if that should change. In the -13 version of the repute document, at my instigation, Murray changed it to use a definition based on primitives from JSON -- not ABNF primitives, but JSON primitives, objects and members and arrays, names and values, strings and ints. See draft-ietf-repute-media-type-13, Section 6.2. I intend, eventually, to write a document suggesting a consistent way to do this, so others who come to the same place to the same thing in the same(-ish) way. The only hassle was that there are some semantic gaps in the ABNF, which don't affect the grammar per se, but which do affect how we can refer to the grammar for the semantic elements. In particular, "member" is defined as a "string" and a "value", not as a member name and member value. And "array" is defined as a set of "value", losing the semantic distinction between a member value and an array value. There's no way to refer to the semantic element that is the member name, for instance -- the fact that it's syntactically represented by a "string" is fine, but there's a step missing. I strongly suggest making a small editorial change to the JSON ABNF, to separate these semantic entities from their type definitions: OLD member = string name-separator value NEW member = member-name name-separator member-value member-name = string member-value = value END OLD array = begin-array [ value *( value-separator value ) ] end-array NEW array = begin-array [ array-value *( value-separator array-value ) ] end-array array-value = value END This doesn't change how JSON is represented in the ABNF, but it allows us to better use the ABNF to refer to the semantic elements. Barry [1] See https://datatracker.ietf.org/doc/draft-ietf-repute-media-type/ From cowan@ccil.org Sun Sep 22 08:24:02 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6D111E80F9 for ; Sun, 22 Sep 2013 08:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[AWL=-1.979, BAYES_50=0.001, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5KIoPbeOhI7 for ; Sun, 22 Sep 2013 08:23:58 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9B98C11E80FD for ; Sun, 22 Sep 2013 08:23:58 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VNlVt-0006gt-Nd; Sun, 22 Sep 2013 11:23:57 -0400 Date: Sun, 22 Sep 2013 11:23:57 -0400 From: John Cowan To: Tim Bray Message-ID: <20130922152357.GD29699@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Interop problem report with number nasties X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Sep 2013 15:24:02 -0000 Tim Bray scripsit: > Can someone provide an example of a situation where +/-0 would cause an > actual practical problem? I can’t. tl;dr answer: Yes, but in those circumstances other problems with JSON and JSON implementations probably swamp it. The introduction of -0.0 into IEEE 754 primarily serves the needs of scientific computing, where it may be important to correctly preserve the sign of a result which is larger than the largest representable negative float, namely -2^-149. Negative zero represents an unspecified number x such that -2^-149 < x <= 0. By the same token, ordinary 0.0 represents an unspecified number y such that 0 <= y < 2^-149. Although 0.0 and -0.0 compare equal, applying certain functions to them produce results that are unequal. (Just another reason why floating-point numbers aren't really numbers.) In particular, dividing by 0.0 produces positive infinity, but dividing by -0.0 produces negative infinity, which are as different as they can be. Similarly, atan2(0.0, -0.0) is an approximation to \pi, whereas atan2(-0.0, -0.0) is an approximation to -\pi. (The function atan2(y, x) computes the principal arc tangent of the complex number x + yi; see for motivation and explanations.) The applicability to JSON is, of course, that if scientific data is being passed via JSON, it should reach the other end accurately and as-is. Against this is the fact that there is no JSON representation for positive infinity, negative infinity, or NaN, so they would have to be sent as strings, and sending -0.0 as a string wouldn't be that much of an additional burden. What is more, most languages don't guarantee either accurate printing or accurate reading of floating-point numbers. A safe approach, then, would be to send floats as quoted strings of hex digits. In practice, people probably won't bother and will feed arbitrary floats to JSON generators, which will print out whatever the implementation of the floating-point printing routine (often ultimately sprintf()) they are using prints out, most likely without bothering to check for the four special cases. This is what happens in Scheme, which *does* require accuracy in floating-point reading and printing, and (in later versions of the standard) prescribes syntax for non-finite numbers, but a good many implementations get it wrong: see for details. -- If you have ever wondered if you are in hell, John Cowan it has been said, then you are on a well-traveled http://www.ccil.org/~cowan road of spiritual inquiry. If you are absolutely cowan@ccil.org sure you are in hell, however, then you must be on the Cross Bronx Expressway. --Alan Feuer, NYTimes, 2002-09-20 From cabo@tzi.org Sun Sep 22 09:36:44 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4034211E80FE for ; Sun, 22 Sep 2013 09:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAnMpxuj6IMt for ; Sun, 22 Sep 2013 09:36:36 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id EE23E11E80FD for ; Sun, 22 Sep 2013 09:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8MGaPTf026459; Sun, 22 Sep 2013 18:36:25 +0200 (CEST) Received: from [192.168.217.105] (p54892010.dip0.t-ipconnect.de [84.137.32.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DCA1A3F; Sun, 22 Sep 2013 18:36:24 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Sun, 22 Sep 2013 18:36:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <60657131-5BE9-493E-A3C6-D5ABE8C917FD@tzi.org> References: To: Barry Leiba X-Mailer: Apple Mail (2.1510) Cc: "json@ietf.org" Subject: Re: [Json] Small ABNF change to do some semantic separation X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Sep 2013 16:36:44 -0000 On Sep 22, 2013, at 17:16, Barry Leiba wrote: > At > first they did it using ABNF. That means that it (badly) duplicated > the ABNF that's already in 4627, We don't have a good way to specialize ABNF. Because of this, specializing ABNF should never be done: -- it is very likely that the attempt at specialization will destroy = some equivalence relationship that holds in the encoding standard*); -- it is quite unlikely that the ABNF actually captures what the = specialization is about. Instead, standards using other standards for their encoding should = describe their specialization at the data model level. (This might give a hint about what might be missing from the encoding = standards we have.) Gr=FC=DFe, Carsten *) This is not a theoretical concern. E.g., in RFC 6690 we had to take great pains not to accidentally = restrict RFC 5988's link-extension production. We had that wrong for = quite some time. If we hadn't fixed that, we would almost certainly = have interoperability problems between parsers that specifically = implement RFC 6690 and those that just use an RFC 5988 parser. Of course, this is much less likely with JSON, which will be parsed with = stock JSON parsers, which just means that the ABNF in repute will need = to be ignored for interoperability purposes. From tbray@textuality.com Sun Sep 22 10:27:02 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC4C11E810B for ; Sun, 22 Sep 2013 10:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHgoT88uwQhY for ; Sun, 22 Sep 2013 10:26:54 -0700 (PDT) Received: from mail-vb0-f47.google.com (mail-vb0-f47.google.com [209.85.212.47]) by ietfa.amsl.com (Postfix) with ESMTP id 31BA221F9EAE for ; Sun, 22 Sep 2013 10:26:54 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id h10so1558457vbh.20 for ; Sun, 22 Sep 2013 10:26:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WnFCkrt8/b422yC8MuPZq6HF6MVn68JIybz3uAt4OgU=; b=kJ5dgVao8r8ZLnrqa9+Q+4DOh2Ns+HNFEwv79MW8NZTVqoFivGrCmvbHBuQD14SXYV payhOhxDXdl+5yDUIltBH/IAvmUu0i1kqPgfBpEuYc5xJizlQc/syZnrqIsCdRoHwlhN nP80YG6kQPL2OMxtCyCFwR4VtGPAJur/b6nwRcLIAnsoJFL9HDNzDu4gSCcDXpMfFDQN ApOLAL6no0ocef7p5pSugo/r3S/WOUysDdNYjwn9bXttCXNUENmUk+gBKUi97DPoufVT iysjhoFuzYGgscrMLu3Rj4HyNhKY7WFkDMBkogdo8Zc4BYJ9wQHgAb4t9DdOHqrLmjJm ETxw== X-Gm-Message-State: ALoCoQnrAMlvpXxhdxXkwZGHChwOkZ8iD/wMKU0pvIi9lGmz0KvmfPqv0KR+mX8mpH9/17IEyPdT MIME-Version: 1.0 X-Received: by 10.220.91.16 with SMTP id k16mr1949697vcm.21.1379870813335; Sun, 22 Sep 2013 10:26:53 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Sun, 22 Sep 2013 10:26:53 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Sun, 22 Sep 2013 10:26:53 -0700 Message-ID: From: Tim Bray To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7b343f1aaa575504e6fc3556 Cc: "json@ietf.org" Subject: Re: [Json] Small ABNF change to do some semantic separation X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Sep 2013 17:27:02 -0000 --047d7b343f1aaa575504e6fc3556 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I completely agree with Barry=E2=80=99s objective here. I had thought one = could unambiguously refer to all the parts of a JSON text using various combinations of object, array, string, number, boolean, member, member name, and member value, e.g. =E2=80=9Cnumber array value=E2=80=9D and =E2= =80=9Cboolean member value=E2=80=9D But if I'm wrong let=E2=80=99s fix that. Rather than twiddling the ABNF, t= hough, we could also just introduce a small =E2=80=9Cterminology=E2=80=9D section.= Let me write up a couple paras and we=E2=80=99ll see how it looks. Anyhow, this is pretty clearly safe territory because it doesn=E2=80=99t ch= ange the definition of what JSON is or impose any new requirements on producers and consumers. -T On Sun, Sep 22, 2013 at 8:16 AM, Barry Leiba wrote= : > The repute working group has defined a response object in JSON.[1] At > first they did it using ABNF. That means that it (badly) duplicated > the ABNF that's already in 4627, trying to say where "ws" can go, > defining what has to have DQUOTE around it (for which the repute doc > used "%x22"), worrying about when to use value-separator and when to > use name-separator (and sometimes using "," instead, in some > versions), using "{" instead of citing begin-object, and so on. It > was messy, error-prone, and subject to deviations from JSON ABNF if > that should change. > > In the -13 version of the repute document, at my instigation, Murray > changed it to use a definition based on primitives from JSON -- not > ABNF primitives, but JSON primitives, objects and members and arrays, > names and values, strings and ints. See > draft-ietf-repute-media-type-13, Section 6.2. > > I intend, eventually, to write a document suggesting a consistent way > to do this, so others who come to the same place to the same thing in > the same(-ish) way. The only hassle was that there are some semantic > gaps in the ABNF, which don't affect the grammar per se, but which do > affect how we can refer to the grammar for the semantic elements. In > particular, "member" is defined as a "string" and a "value", not as a > member name and member value. And "array" is defined as a set of > "value", losing the semantic distinction between a member value and an > array value. There's no way to refer to the semantic element that is > the member name, for instance -- the fact that it's syntactically > represented by a "string" is fine, but there's a step missing. > > I strongly suggest making a small editorial change to the JSON ABNF, > to separate these semantic entities from their type definitions: > > OLD > member =3D string name-separator value > NEW > member =3D member-name name-separator member-value > member-name =3D string > member-value =3D value > END > > OLD > array =3D begin-array [ value *( value-separator value ) ] end-array > NEW > array =3D begin-array [ array-value *( value-separator array-value ) ] > end-array > array-value =3D value > END > > This doesn't change how JSON is represented in the ABNF, but it allows > us to better use the ABNF to refer to the semantic elements. > > Barry > > [1] See https://datatracker.ietf.org/doc/draft-ietf-repute-media-type/ > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b343f1aaa575504e6fc3556 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I completely agree with Barry=E2=80=99s objective her= e.=C2=A0 I had thought one could unambiguously refer to all the parts of a = JSON text using various combinations of object, array, string, number, bool= ean, member, member name, and member value, e.g. =E2=80=9Cnumber array valu= e=E2=80=9D and =E2=80=9Cboolean member value=E2=80=9D

But if I'm wrong let=E2=80=99s fix that.=C2=A0 Rather than twiddlin= g the ABNF, though, we could also just introduce a small =E2=80=9Cterminolo= gy=E2=80=9D section.=C2=A0 Let me write up a couple paras and we=E2=80=99ll= see how it looks.

Anyhow, this is pretty clearly safe territory bec= ause it doesn=E2=80=99t change the definition of what JSON is or impose any= new requirements on producers and consumers. -T


O= n Sun, Sep 22, 2013 at 8:16 AM, Barry Leiba <barryleiba@computer.o= rg> wrote:
The repute working group has defined a respo= nse object in JSON.[1] =C2=A0At
first they did it using ABNF. =C2=A0That means that it (badly) duplicated the ABNF that's already in 4627, trying to say where "ws" can= go,
defining what has to have DQUOTE around it (for which the repute doc
used "%x22"), worrying about when to use value-separator and when= to
use name-separator (and sometimes using "," instead, in some
versions), using "{" instead of citing begin-object, and so on. = =C2=A0It
was messy, error-prone, and subject to deviations from JSON ABNF if
that should change.

In the -13 version of the repute document, at my instigation, Murray
changed it to use a definition based on primitives from JSON -- not
ABNF primitives, but JSON primitives, objects and members and arrays,
names and values, strings and ints. =C2=A0See
draft-ietf-repute-media-type-13, Section 6.2.

I intend, eventually, to write a document suggesting a consistent way
to do this, so others who come to the same place to the same thing in
the same(-ish) way. =C2=A0The only hassle was that there are some semantic<= br> gaps in the ABNF, which don't affect the grammar per se, but which do affect how we can refer to the grammar for the semantic elements. =C2=A0In<= br> particular, "member" is defined as a "string" and a &qu= ot;value", not as a
member name and member value. =C2=A0And "array" is defined as a s= et of
"value", losing the semantic distinction between a member value a= nd an
array value. =C2=A0There's no way to refer to the semantic element that= is
the member name, for instance -- the fact that it's syntactically
represented by a "string" is fine, but there's a step missing= .

I strongly suggest making a small editorial change to the JSON ABNF,
to separate these semantic entities from their type definitions:

OLD
member =3D string name-separator value
NEW
member =3D member-name name-separator member-value
member-name =3D string
member-value =3D value
END

OLD
array =3D begin-array [ value *( value-separator value ) ] end-array
NEW
array =3D begin-array [ array-value *( value-separator array-value ) ] end-= array
array-value =3D value
END

This doesn't change how JSON is represented in the ABNF, but it allows<= br> us to better use the ABNF to refer to the semantic elements.

Barry

[1] See https://datatracker.ietf.org/doc/draft-ietf-reput= e-media-type/
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7b343f1aaa575504e6fc3556-- From paul.hoffman@vpnc.org Mon Sep 23 08:47:02 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C3D11E80E3 for ; Mon, 23 Sep 2013 08:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOVWrIO2uJBG for ; Mon, 23 Sep 2013 08:47:01 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C891811E80E4 for ; Mon, 23 Sep 2013 08:46:55 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8NFkncj039268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Sep 2013 08:46:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 23 Sep 2013 08:46:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1510) Cc: " WG" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 15:47:02 -0000 On Sep 20, 2013, at 10:00 PM, "Manger, James H" = wrote: > RFC 4627 doesn't define how URI fragments work for application/json = content. >=20 > It would be helpful for 4627bis to say that a fragment (that begins = with a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointer = identifies a specific value in a JSON text. Changing the IANA MIME registry entry can be done, but I propose that we = don't do it as part of the -bis because it is not really a = clarification. This update can be done with a separate draft that = updates the registry, but I admit that people tend to just read the = RFCs, not the registry and therefore this is likely to be missed. How do others feel about making a change in the -bis that is "things = that have happened since 4627" that don't change the JSON grammar? --Paul Hoffman= From paul.hoffman@vpnc.org Mon Sep 23 08:53:20 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490A521F9AE6 for ; Mon, 23 Sep 2013 08:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.372 X-Spam-Level: X-Spam-Status: No, score=-101.372 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_00=-2.599, FRT_ADOBE2=2.455, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2a7nfgHvRIp for ; Mon, 23 Sep 2013 08:53:18 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 52F4121F9AA2 for ; Mon, 23 Sep 2013 08:53:18 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8NFrE6N039450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Sep 2013 08:53:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Mon, 23 Sep 2013 08:53:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51970539-6C60-4590-8C6A-230E83296468@jorgechamorro.com> <255B9BB34FB7D647A506DC292726F6E115310592C9@WSMSG3153V.srv.dir.telstra.com> <0656B646-A168-452B-A23D-FDA5CF574A9F@jorgechamorro.com> To: Larry Masinter X-Mailer: Apple Mail (2.1510) Cc: json@ietf.org Subject: Re: [Json] Strengthen interop language on numbers? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 15:53:20 -0000 On Sep 21, 2013, at 11:42 AM, Larry Masinter wrote: > I wonder if it would be helpful to invert the =93interoperable=94 = discussion by talking about the interoperability of =93conforming = implementations=94 rather than =93interoperable numbers=94. That is: > =20 > Define =93conforming JSON implementation=94 to be a JSON = implementation consisting of > =95 a parser which reads JSON and produces an internal data = structure, and > =95 a serializer which takes an internal data structure and = creates JSON text > such that serialize(parse(X)) is equivalent to X > =95 using a (defined) equivalence relationship > =95 as long as X uses numbers in the following set (numbers = which are integers in range Y or floating point numbers satisfying = property Z) > =20 > That is, DEFINE what constitutes an interoperable number, don=92t try = to discover it. The strong consensus of the WG has been to not add new conformance = requirements to the -bis. While your proposal is more definitive than = the current wording, it is similar to other conformance proposals that = have gone against the WG consensus. --Paul Hoffman= From paul.hoffman@vpnc.org Mon Sep 23 08:56:04 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944F621F9CE8 for ; Mon, 23 Sep 2013 08:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi3xA6EH3lER for ; Mon, 23 Sep 2013 08:56:02 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 863AD21F9BF7 for ; Mon, 23 Sep 2013 08:55:57 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8NFtoaO039543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Sep 2013 08:55:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Mon, 23 Sep 2013 08:55:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1BB38F24-8147-417B-9A48-B9D96A12770C@vpnc.org> References: To: Tim Bray X-Mailer: Apple Mail (2.1510) Cc: Barry Leiba , "json@ietf.org" Subject: Re: [Json] Small ABNF change to do some semantic separation X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 15:56:04 -0000 On Sep 22, 2013, at 10:26 AM, Tim Bray wrote: > I completely agree with Barry=92s objective here. I had thought one = could unambiguously refer to all the parts of a JSON text using various = combinations of object, array, string, number, boolean, member, member = name, and member value, e.g. =93number array value=94 and =93boolean = member value=94 >=20 > But if I'm wrong let=92s fix that. Rather than twiddling the ABNF, = though, we could also just introduce a small =93terminology=94 section. = Let me write up a couple paras and we=92ll see how it looks. The terminology section seems like a much safer idea than changing the = ABNF. Having said that, the "implementation guidance" document that many = people have proposed as a later work item would probably be a better = place for such a section, and we are not in a rush for that text. --Paul Hoffman=20= From paul.hoffman@vpnc.org Mon Sep 23 08:58:01 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6D821F9EDA for ; Mon, 23 Sep 2013 08:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLchP7gdqByv for ; Mon, 23 Sep 2013 08:58:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB3921F9DA1 for ; Mon, 23 Sep 2013 08:58:00 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8NFvwok039600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Sep 2013 08:57:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Mon, 23 Sep 2013 08:57:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tim Bray X-Mailer: Apple Mail (2.1510) Cc: "json@ietf.org" Subject: [Json] Implementations that do not handle U+0000 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 15:58:01 -0000 On Sep 21, 2013, at 4:09 PM, Tim Bray wrote: > * Some implementations can not handle strings with the character = U+0000, however encoded or escaped. This most often occurs when trying = to embed raw binary data into a JSON value, and usually affects C = language based implementations. Those are broken implementations, not non-interoperable implementations. = There is no sense in this WG trying to list the valid Unicode characters = that some broken implementations have problems with. --Paul Hoffman= From cabo@tzi.org Mon Sep 23 09:00:10 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BE021F91F2 for ; Mon, 23 Sep 2013 09:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.135 X-Spam-Level: X-Spam-Status: No, score=-106.135 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIIjLy87bvUL for ; Mon, 23 Sep 2013 09:00:03 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 94F6E21F9EDA for ; Mon, 23 Sep 2013 09:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8NFxk1m005512; Mon, 23 Sep 2013 17:59:46 +0200 (CEST) Received: from [192.168.217.105] (p548903C6.dip0.t-ipconnect.de [84.137.3.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 58B4DA06; Mon, 23 Sep 2013 17:59:46 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> Date: Mon, 23 Sep 2013 17:59:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <87C14962-3BCD-4272-83FB-5F90488A4706@tzi.org> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1510) Cc: "Manger, James H" , " WG" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 16:00:11 -0000 On Sep 23, 2013, at 17:46, Paul Hoffman wrote: > How do others feel about making a change in the -bis that is "things = that have happened since 4627" that don't change the JSON grammar? Uneasy, if the intention is normative. My other question would be: Are we ready to say that RFC 6901 is *the* fragment identifier syntax = for JSON? RFC 6901 actually says: In particular, the fragment identifier syntax for application/json is not JSON Pointer. I don't know enough about the history of that sentence to understand = whether that is a statement of fact (obviously true at the time) or a = statement of intention. Gr=FC=DFe, Carsten From paul.hoffman@vpnc.org Mon Sep 23 09:00:50 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22E721F91F2 for ; Mon, 23 Sep 2013 09:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSR7BrAIlWVu for ; Mon, 23 Sep 2013 09:00:49 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CDB9121F942D for ; Mon, 23 Sep 2013 09:00:41 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8NG0VxD039718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Sep 2013 09:00:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: <2589A1DC-2DF8-464A-B5B8-2A6312BAA184@tzi.org> Date: Mon, 23 Sep 2013 09:00:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44DD1B27-6F20-47A3-ABBB-F474BF7AAD84@vpnc.org> References: <2589A1DC-2DF8-464A-B5B8-2A6312BAA184@tzi.org> To: Tim Bray X-Mailer: Apple Mail (2.1510) Cc: "json@ietf.org WG" Subject: [Json] Dealing with -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 16:00:51 -0000 On Sep 22, 2013, at 12:30 AM, Carsten Bormann wrote: > On Sep 22, 2013, at 01:09, Tim Bray wrote: >=20 >> So encoding a -0.0 in JSON may lead to interoperability problems.=20 >=20 > As with the other number issues, it is not the encoding of a specific = value by a sender that leads to an interoperability problem, but the = sender relying on a specific interpretation of that value by the = recipient. > Here, an interoperability problem would be caused if the sender relies = on the recipient preserving the negativeness of the number, or on it = differentiating it from a positive zero. +1. There are all sorts of ways that JSON parsers can interpret numbers = that will surprise other implementations but make perfect sense on the = platform in question. I don't see any value to trying to list all of = these. --Paul Hoffman From paul.hoffman@vpnc.org Mon Sep 23 09:05:02 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2D521F999C for ; Mon, 23 Sep 2013 09:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrKdHcupC54i for ; Mon, 23 Sep 2013 09:05:02 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 32A4121F9635 for ; Mon, 23 Sep 2013 09:05:02 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8NG50xH039865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Sep 2013 09:05:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Mon, 23 Sep 2013 09:05:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <78CA86B5-F76D-4F32-AD51-4A65F8C8176D@vpnc.org> References: To: Tim Bray X-Mailer: Apple Mail (2.1510) Cc: "json@ietf.org" Subject: [Json] Integer vs. floating point X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 16:05:02 -0000 On Sep 21, 2013, at 4:09 PM, Tim Bray wrote: > * Integer vs. floating point. The JSON spec makes no distinction = between integer or floating point numbers. However most, but not all, = JSON implementations do, Fully agree, but... > so again this can lead to interoperability problems. No, it leads to an interpretation problem. > Some implementations may treat 1.0, 1E3, 1000E-2, etc. as integers; as = mathematically they are. Adding some language about the "interpretation" = of numbers in JSON may be welcome. That sounds useful. Proposed text: JSON numbers can be interpreted in many ways. For example, the number 1 = and the number 1.0 might be considered the same by some interpreters but = different in others; similarly, 0, +0, and -0 might be considered to be = the same or different. JSON encoders should not make any assumptions how = JSON decoders will handle any particular type of number. --Paul Hoffman= From sayrer@gmail.com Mon Sep 23 09:21:17 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E12621F86B2 for ; Mon, 23 Sep 2013 09:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rW81EExK8Fvg for ; Mon, 23 Sep 2013 09:21:16 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB5D21F9E54 for ; Mon, 23 Sep 2013 09:21:11 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id k15so1629309qaq.9 for ; Mon, 23 Sep 2013 09:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xi6yxlOtLrWvwbXHvlo1UxLy9sdW+EhCZXBDHE1vAIw=; b=09ri/6mNgUSGIT9xtUkuMZvwCv62O0EhpehqsBZZoPdMC+ecjSJyo/FnSGjTPVvwDR waCp9Umni3yoJCM97oPQKcl8D/tV2EiYgXWueKWsDKtpUwS9VZrZaAnVwU47AubD3V+R CfXVNSfFZixvcqdsQA+oRtCSpxFCxSMYvnTPGLdrGaCvmb5VC+LhGVZkb8J/NPR9wcCP llXkSI1gdDVjWTNElY+9gfyTcBNRAZcPfJ13fWUfRwyjcq1xrRr3fhWlzEtNm4QiU2tI cdl26p0BGqSTgCIo72UTgO75xcOzAUHbqEmk6Ie+CBFuUGDPk++B6rEuQBLuU/E5Ee1q +RhQ== MIME-Version: 1.0 X-Received: by 10.49.88.3 with SMTP id bc3mr23466572qeb.30.1379952683046; Mon, 23 Sep 2013 09:11:23 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 09:11:23 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 09:11:23 -0700 (PDT) In-Reply-To: <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> Date: Mon, 23 Sep 2013 09:11:23 -0700 Message-ID: From: R S To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7bd6aeba7adf2504e70f45df Cc: "Manger, James H" , json@ietf.org Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 16:21:17 -0000 --047d7bd6aeba7adf2504e70f45df Content-Type: text/plain; charset=ISO-8859-1 This is a bad idea. JSON pointer was designed for a narrow patch use case, and can't disambiguate objects and arrays. The JSON RFC shouldn't list every RFC that uses JSON. - Rob On Sep 20, 2013, at 10:00 PM, "Manger, James H" < james.h.manger@team.telstra.com> wrote: > RFC 4627 doesn't define how URI fragments work for application/json content. > > It would be helpful for 4627bis to say that a fragment (that begins with a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointer identifies a specific value in a JSON text. Changing the IANA MIME registry entry can be done, but I propose that we don't do it as part of the -bis because it is not really a clarification. This update can be done with a separate draft that updates the registry, but I admit that people tend to just read the RFCs, not the registry and therefore this is likely to be missed. How do others feel about making a change in the -bis that is "things that have happened since 4627" that don't change the JSON grammar? --Paul Hoffman _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json --047d7bd6aeba7adf2504e70f45df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

This is a bad idea. JSON pointer was designed for a narrow p= atch use case, and can't disambiguate objects and arrays.

The JSON RFC shouldn't list every RFC that uses JSON.

- Rob

<no hat>

On Sep 20, 2013, at 10:00 PM, "Manger, James H" &l= t;james.h.manger@team.te= lstra.com> wrote:

> RFC 4627 doesn't define how URI fragments work for = application/json content.
>
> It would be helpful for 4627bis to say that a fragment (that begins wi= th a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointe= r identifies a specific value in a JSON text.

Changing the IANA MIME registry entry can be done, but I pro= pose that we don't do it as part of the -bis because it is not really a= clarification. This update can be done with a separate draft that updates = the registry, but I admit that people tend to just read the RFCs, not the r= egistry and therefore this is likely to be missed.

How do others feel about making a change in the -bis that is= "things that have happened since 4627" that don't change the= JSON grammar?

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

--047d7bd6aeba7adf2504e70f45df-- From johnl@iecc.com Mon Sep 23 09:29:13 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859D911E80EA for ; Mon, 23 Sep 2013 09:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oUMB7gtnNYx for ; Mon, 23 Sep 2013 09:29:09 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC4E21F9FBF for ; Mon, 23 Sep 2013 09:28:57 -0700 (PDT) Received: (qmail 84449 invoked from network); 23 Sep 2013 16:28:56 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Sep 2013 16:28:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52406c48.xn--30v786c.k1309; i=johnl@user.iecc.com; bh=iX0Mz3MUg115aW0wzPMGrSTki+X5e3iEMCX4ga6pFfE=; b=L9Gn51jxhqGbvIm7BFkrtWYMwWqm1Y4WR7vTXli5C0JuFS8YBWDj1/a6OBPP6/BR09UOeyz8+OSIiYQbj4XBZsWqwVEVDNfd0BHWeFexvU96JY4vpfE6MqMubxXmTVfuPW56gH82PAqRCcNBsbg70fn26VbQKr9Bb4Pzig0TlKkxOkiy2gkeqJMGXgicJMFZbnfyndlc7zkKQRHmBUg+YMV1fLEdE4CUMxaj3vrdv87BagAHjSDM1TWfK0Js3fDI DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52406c48.xn--30v786c.k1309; olt=johnl@user.iecc.com; bh=iX0Mz3MUg115aW0wzPMGrSTki+X5e3iEMCX4ga6pFfE=; b=EjA0mKjA7MHub5yGclSVILuR2iBzlJiG9ElwXJbO4ZxTsczDnhkXOUyFX/be8EATIpYgsnw2pWhiD0i8GxV4tuxPcXzAN1EoLDw2R7GWsKNuvPGjVOc+oFxDITNOW6rS8WcS3ox3Nyq/gduUZYo9PXR1mg+ITwetmWUIi9yG1TUOtkrbHMtnLZjNdBjaoDBATwJ/o+6voqUAzwm0Q6mGkEPRdoZa8jPqeilrWcSPcDweomAjmQkX3APeNoNAfUTy Date: 23 Sep 2013 16:28:34 -0000 Message-ID: <20130923162834.344.qmail@joyce.lan> From: "John Levine" To: json@ietf.org In-Reply-To: <44DD1B27-6F20-47A3-ABBB-F474BF7AAD84@vpnc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: paul.hoffman@vpnc.org Subject: Re: [Json] Dealing with -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 16:29:13 -0000 >+1. There are all sorts of ways that JSON parsers can interpret numbers that will surprise other implementations but make perfect >sense on the platform in question. I don't see any value to trying to list all of these. +0.5. I worry that a list of surprises will be misinterpreted as definitive, particularly if someone comes up with some corner case later that we didn't think of. I do think it's reasonable give examples, something along the lines of JSON parsers may interpret strings that represent numbers that are mathematically equal as different values. Examples might be, 0, +0 and -0, or 1, 1.0, and 0.1e1. R's, John From cowan@ccil.org Mon Sep 23 09:44:58 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7211921F9FC8 for ; Mon, 23 Sep 2013 09:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5whyc00sUO4 for ; Mon, 23 Sep 2013 09:44:52 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 88FC921F9F45 for ; Mon, 23 Sep 2013 09:44:48 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VO9FX-00017i-N0; Mon, 23 Sep 2013 12:44:39 -0400 Date: Mon, 23 Sep 2013 12:44:39 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130923164439.GB16656@mercury.ccil.org> References: <78CA86B5-F76D-4F32-AD51-4A65F8C8176D@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78CA86B5-F76D-4F32-AD51-4A65F8C8176D@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Integer vs. floating point X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 16:44:58 -0000 Paul Hoffman scripsit: > JSON numbers can be interpreted in many ways. For example, the number > 1 and the number 1.0 might be considered the same by some interpreters > but different in others; similarly, 0, +0, and -0 might be considered to > be the same or different. JSON encoders should not make any assumptions > how JSON decoders will handle any particular type of number. +1, but needs reformulation into interoperability language, something like this: JSON numbers can be interpreted in many ways. For example, the number 1 and the number 1.0 might be considered the same by some processes but different by others; similarly, 0, +0, and -0 might be considered to be the same or different. Therefore, it is not interoperable for a process that generates JSON numbers to make assumptions about how processes that consume them will handle the numbers. -- John Cowan http://ccil.org/~cowan cowan@ccil.org Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash, The day and hour soon are coming / When all the IT folks say "Gosh!" It isn't from a clever lawsuit / That Windowsland will finally fall, But thousands writing open source code / Like mice who nibble through a wall. --The Linux-nationale by Greg Baker From paul.hoffman@vpnc.org Mon Sep 23 09:51:51 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA8A21F9FDE for ; Mon, 23 Sep 2013 09:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKSwJjtO7h2D for ; Mon, 23 Sep 2013 09:51:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CB30B21F9FD7 for ; Mon, 23 Sep 2013 09:51:46 -0700 (PDT) Received: from [192.168.1.40] (c-107-3-147-42.hsd1.ca.comcast.net [107.3.147.42]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8NGpc0D041386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 23 Sep 2013 09:51:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host c-107-3-147-42.hsd1.ca.comcast.net [107.3.147.42] claimed to be [192.168.1.40] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: <20130923164439.GB16656@mercury.ccil.org> Date: Mon, 23 Sep 2013 09:51:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <78CA86B5-F76D-4F32-AD51-4A65F8C8176D@vpnc.org> <20130923164439.GB16656@mercury.ccil.org> To: "json@ietf.org WG" X-Mailer: Apple Mail (2.1510) Subject: Re: [Json] Integer vs. floating point X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 16:51:51 -0000 On Sep 23, 2013, at 9:44 AM, John Cowan wrote: > Paul Hoffman scripsit: >=20 >> JSON numbers can be interpreted in many ways. For example, the number >> 1 and the number 1.0 might be considered the same by some = interpreters >> but different in others; similarly, 0, +0, and -0 might be considered = to >> be the same or different. JSON encoders should not make any = assumptions >> how JSON decoders will handle any particular type of number. >=20 > +1, but needs reformulation into interoperability language, something = like this: >=20 > JSON numbers can be interpreted in many ways. For example, the = number 1 > and the number 1.0 might be considered the same by some processes = but > different by others; similarly, 0, +0, and -0 might be considered to = be > the same or different. Therefore, it is not interoperable for a = process > that generates JSON numbers to make assumptions about how processes = that > consume them will handle the numbers. +1 to John's wording over mine. --Paul Hoffman= From cowan@ccil.org Mon Sep 23 10:12:36 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E650921F9EAD for ; Mon, 23 Sep 2013 10:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.99 X-Spam-Level: X-Spam-Status: No, score=-2.99 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWEKknPq-8AZ for ; Mon, 23 Sep 2013 10:12:32 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id D33BF21F9D31 for ; Mon, 23 Sep 2013 10:12:32 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VO9gV-0004Gx-9y; Mon, 23 Sep 2013 13:12:31 -0400 Date: Mon, 23 Sep 2013 13:12:31 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130923171231.GC16656@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Implementations that do not handle U+0000 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 17:12:37 -0000 Paul Hoffman scripsit: > Those are broken implementations, not non-interoperable > implementations. There is no sense in this WG trying to list the valid > Unicode characters that some broken implementations have problems with. At least 9 out of the 16 JSON implementations written in C and listed at json.org have some form of the U+0000 bug. I think that makes it well worth warning about. The hall of shame: LibU, json-c, json-parser, WJElement, M's JSON parser aka mjson, cJSON, Jansson, parson, nxjson. I determined this by code inspection rather than testing, so there may be others. Some exhibit the bug only in the form of a call to parse JSON from a C string. -- "But I am the real Strider, fortunately," John Cowan he said, looking down at them with his face cowan@ccil.org softened by a sudden smile. "I am Aragorn son http://www.ccil.org/~cowan of Arathorn, and if by life or death I can save you, I will." --LotR Book I Chapter 10 From mamille2@cisco.com Mon Sep 23 10:48:39 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D2B21F9FA4 for ; Mon, 23 Sep 2013 10:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqH4Xm2+zNJR for ; Mon, 23 Sep 2013 10:48:33 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2493421F9F80 for ; Mon, 23 Sep 2013 10:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6566; q=dns/txt; s=iport; t=1379958513; x=1381168113; h=from:to:subject:date:message-id:mime-version; bh=zJycJbgefwpcwLDCflLDEL0HsqOJnfisaCAhPE3Qs1g=; b=hPjETRBcDtSZbwS92k2+keqg6aTGPvqloYEgGMNNo2XmWQeT5/SnwHSP Cv1ZsTzWn/J7FHYgn9GeEQ5mh1YOn9ZZ9VOTVjMoDbW/VlarRSdb3UnHR kn5b9zCQaXkoCvD988rPkdtqnQ4r7F3uZTFn5tExLgURll7lhU+WD1OaY 4=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAO99QFKtJV2b/2dsb2JhbABZgweBCsEogSIWdIInAQSBCwEqJjAnBBMIBod3mi2hMY80g1aBAAOQJoEvmB6DJIIq X-IronPort-AV: E=Sophos;i="4.90,964,1371081600"; d="p7s'?scan'208";a="263417571" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 23 Sep 2013 17:48:32 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8NHmW7j016417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Sep 2013 17:48:32 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.253]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 23 Sep 2013 12:48:32 -0500 From: "Matt Miller (mamille2)" To: " WG" Thread-Topic: Update [ECMA] Reference Thread-Index: AQHOuIUe13dYLmOz+E+b0xWzyCgrNQ== Date: Mon, 23 Sep 2013 17:48:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.48] Content-Type: multipart/signed; boundary="Apple-Mail=_C0B4F3EF-4532-40CE-B02C-B9E5527A22C9"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [Json] Update [ECMA] Reference X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 17:48:39 -0000 --Apple-Mail=_C0B4F3EF-4532-40CE-B02C-B9E5527A22C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii /me doffs hat I notice the reference to ECMAScript is for "3rd Edition" (December = 1999), while following the reference leads to "5.1 Edition" (June 2011). = Also, the official name for this organization is just "Ecma = International" now, not "European Computer Manufacturers Association". Do we want to update the [ECMA] reference now, or wait until 4627bis is = closer to publication (or not update at all)? - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_C0B4F3EF-4532-40CE-B02C-B9E5527A22C9 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5MjMxNzQ4 MzJaMCMGCSqGSIb3DQEJBDEWBBQ8jLpOFllUxDMgewrjrrq4WgQgcDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBABIg Hn5noljeS9+OKeuqacV280JhlhYwUlKhKaBgbRZRjXerjxoUGlSXkbcM1Oh9dBC8aifyJQ/+oO/2 jhgiMEMa7pH8r+QFEyVljVGs8WuA0ErbPRh0vY2Z/O+ggmouBXv1qIrUVKJBmBzFOlLEpRrKZGkq VYCP4Vrp8SOf7im2hNkrPy7W8cmAw79oZINr8Lx7LjXCUUW3/8IHt33naXxhXKV2uHTnzew17PXa HH8r7KeGZ9ZmGtJwG9hLyn+sVGoEOITguqeQNoPFH6qDDFSkAO7brqKLBGFmce5MfmSVHrLbedFe EXsyFHs0IVPlg5NJ91f9Lkkor3IjDWDpk0kAAAAAAAA= --Apple-Mail=_C0B4F3EF-4532-40CE-B02C-B9E5527A22C9-- From tbray@textuality.com Mon Sep 23 11:18:16 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19F811E80EA for ; Mon, 23 Sep 2013 11:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTZGdxl-DHe3 for ; Mon, 23 Sep 2013 11:18:12 -0700 (PDT) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id D54E411E80EC for ; Mon, 23 Sep 2013 11:18:11 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id jw12so2734991veb.9 for ; Mon, 23 Sep 2013 11:18:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XtEritcOfCMlj5KYHjKlrOI/Fgmrrx3NNhELQwxubl8=; b=GLXbkmah2AGFsxdpFK9Zl11jf3vL++iKilUy6NWMIVoODh4Xn8ZY3HvfLrTIoM4DF7 IXIImaj6XsT6Wn2myDA67U0KQWDqmu7A+GEJIuYGwX4BqfmyTJxybz4i85/qz81F4+s0 Li5laZEmhXVHlaBjuAK/MLIj9NWS8KPkegCx/prc/a9lrvtcwV1ZeDjmrUaYY+MHQShN Kryc8gr46x18ODobUmUZk272Uw5CFK7BJKQR8dJschFnQe//P4jh5xPyUxXtdT/s7rYY chfEx1sC+RC5JbOTo8bplCGKRJ/dbb5849Qq+gONejbFKuPYZfxsS8eSDFoSO20DN4rR WfcQ== X-Gm-Message-State: ALoCoQkcGjiSJ7vbFg+wA8TGxpFPgnxzc184kqbzb/jdOJvXY0tXnj4abwS2aSEks8zpmwNUgwT1 MIME-Version: 1.0 X-Received: by 10.220.173.134 with SMTP id p6mr220610vcz.36.1379960291219; Mon, 23 Sep 2013 11:18:11 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Mon, 23 Sep 2013 11:18:11 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <20130923162834.344.qmail@joyce.lan> References: <44DD1B27-6F20-47A3-ABBB-F474BF7AAD84@vpnc.org> <20130923162834.344.qmail@joyce.lan> Date: Mon, 23 Sep 2013 11:18:11 -0700 Message-ID: From: Tim Bray To: John Levine Content-Type: multipart/alternative; boundary=089e0158b154f6741f04e7110a8e Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Dealing with -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:18:16 -0000 --089e0158b154f6741f04e7110a8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So far, all the changes we=E2=80=99ve made are of the form =E2=80=9CIf you = do $X, $JSON_construct_Y will be interoperable in the sense that implementations will $Z. If you don=E2=80=99t problems of the form $W can happen.=E2=80=9D I think it would be useful if we could stay with that rhythm, as anything that can be phrased that way is pretty clearly within our charter, and furthermore has the advantage of being actionable. So I think it=E2=80=99d be good if people who are proposing changes (includ= ing me) could try to package their thoughts up that way. On Mon, Sep 23, 2013 at 9:28 AM, John Levine wrote: > >+1. There are all sorts of ways that JSON parsers can interpret numbers > that will surprise other implementations but make perfect > >sense on the platform in question. I don't see any value to trying to > list all of these. > > +0.5. I worry that a list of surprises will be misinterpreted as > definitive, particularly if someone comes up with some corner case > later that we didn't think of. > > I do think it's reasonable give examples, something along the lines of > > JSON parsers may interpret strings that represent numbers that are > mathematically equal as different values. Examples might be, 0, +0 > and -0, or 1, 1.0, and 0.1e1. > > R's, > John > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e0158b154f6741f04e7110a8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<editorial-hat>
So far, all the ch= anges we=E2=80=99ve made are of the form =E2=80=9CIf you do $X, $JSON_const= ruct_Y will be interoperable in the sense that implementations will $Z. If = you don=E2=80=99t problems of the form $W can happen.=E2=80=9D

I think it would be useful if we could stay with that rhyth= m, as anything that can be phrased that way is pretty clearly within our ch= arter, and furthermore has the advantage of being actionable.

So I t= hink it=E2=80=99d be good if people who are proposing changes (including me= ) could try to package their thoughts up that way.=C2=A0
</editorial-hat>


On Mon, Sep 23, 2013 at 9:28 AM, John Levine <johnl= @taugh.com> wrote:
>+1. There are all sort= s of ways that JSON parsers can interpret numbers that will surprise other = implementations but make perfect
>sense on the platform in question. I don't see any value to trying = to list all of these.

+0.5. =C2=A0I worry that a list of surprises will be misinterpreted a= s
definitive, particularly if someone comes up with some corner case
later that we didn't think of.

I do think it's reasonable give examples, something along the lines of<= br>
JSON parsers may interpret strings that represent numbers that are
mathematically equal as different values. =C2=A0Examples might be, 0, +0 and -0, or 1, 1.0, and 0.1e1.

R's,
John
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e0158b154f6741f04e7110a8e-- From paul.hoffman@vpnc.org Mon Sep 23 11:27:59 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CCE21F9A72 for ; Mon, 23 Sep 2013 11:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKHTlFEI+xWM for ; Mon, 23 Sep 2013 11:27:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9744321F9A6D for ; Mon, 23 Sep 2013 11:27:58 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8NIRudD045001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Sep 2013 11:27:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Mon, 23 Sep 2013 11:27:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0027859F-C891-4279-A507-1D19F2E46720@vpnc.org> References: <44DD1B27-6F20-47A3-ABBB-F474BF7AAD84@vpnc.org> <20130923162834.344.qmail@joyce.lan> To: Tim Bray X-Mailer: Apple Mail (2.1510) Cc: "json@ietf.org WG" Subject: Re: [Json] Dealing with -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:28:01 -0000 On Sep 23, 2013, at 11:18 AM, Tim Bray wrote: > > So far, all the changes we=92ve made are of the form =93If you do $X, = $JSON_construct_Y will be interoperable in the sense that = implementations will $Z. If you don=92t problems of the form $W can = happen.=94 >=20 > I think it would be useful if we could stay with that rhythm, as = anything that can be phrased that way is pretty clearly within our = charter, and furthermore has the advantage of being actionable. >=20 > So I think it=92d be good if people who are proposing changes = (including me) could try to package their thoughts up that way. =20 > For numbers like -0.0, do we have any clue at all about what ($X $Z) is? = I propose we don't. --Paul Hoffman= From tbray@textuality.com Mon Sep 23 11:37:10 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F116221F9C7A for ; Mon, 23 Sep 2013 11:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeTAWQhSof7e for ; Mon, 23 Sep 2013 11:36:52 -0700 (PDT) Received: from mail-vb0-f47.google.com (mail-vb0-f47.google.com [209.85.212.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0919421F9C3A for ; Mon, 23 Sep 2013 11:36:51 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id h10so2416458vbh.6 for ; Mon, 23 Sep 2013 11:36:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LwxN0/IxVtKAvNTd5a1d64JqgxZgbgptu07rb1ijPmY=; b=AwI3GejxhePeQf4trAfmuAXN+Ry95rh+8VdsIKs04+QHD6fJj0kvR1C3f2iz89awQK q4+/wzVrIEKwjP/je39vbJKwM35GN5IaTeYRohkPEKxPTNYnH8B3AvebBcf9/s+R8fHY IeyVhNSfnkIwRpRTU0ustmIczYKyehNzw/vnWxg/3SNK1sENQlA2PirFq7Y/kMSz4THP YGuxNbkzyRac9Fk9ZeyHgjo4Ct+hxr/Am0TS06E3FJ2sIFHES+Y1joO1Nu8bd9GTIp77 bN12pUIRKzrvTWZxSPmLVGOAMOH8NDZF6o6vrr7mcSq+td79G2MqQWx/davJo8koqlHv 8EqQ== X-Gm-Message-State: ALoCoQmcpS98cJ0A9m2pVgSAL7aJxtBfgSYpoUhYp2OXJh8CbnzoFo78Jjzecnjo8K3m604UNRJe MIME-Version: 1.0 X-Received: by 10.58.29.109 with SMTP id j13mr60633veh.81.1379961411312; Mon, 23 Sep 2013 11:36:51 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Mon, 23 Sep 2013 11:36:51 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <0027859F-C891-4279-A507-1D19F2E46720@vpnc.org> References: <44DD1B27-6F20-47A3-ABBB-F474BF7AAD84@vpnc.org> <20130923162834.344.qmail@joyce.lan> <0027859F-C891-4279-A507-1D19F2E46720@vpnc.org> Date: Mon, 23 Sep 2013 11:36:51 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b6da0e2b9b2e704e7114d13 Cc: "json@ietf.org WG" Subject: Re: [Json] Dealing with -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:37:10 -0000 --047d7b6da0e2b9b2e704e7114d13 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 23, 2013 at 11:27 AM, Paul Hoffman wrote= : > > So far, all the changes we=E2=80=99ve made are of the form =E2=80=9CIf = you do $X, > $JSON_construct_Y will be interoperable in the sense that implementations > will $Z. If you don=E2=80=99t problems of the form $W can happen.=E2=80= =9D > > For numbers like -0.0, do we have any clue at all about what ($X $Z) is? = I > propose we don't. > Well, that could be evidence that this isn=E2=80=99t worth putting in, whic= h I=E2=80=99m OK with because I don't think it=E2=80=99s really actionable. But let=E2=80= =99s see. =E2=80=9CJSON numbers which use 0 or 0.0 for zero, as opposed to -0 or -0.0= , will be interoperable in that software implementations will agree on the zero value. The difference between 0 and -0 is significant in some numerically-intensive applications, but implementations which read JSON texts cannot be relied upon to preserve that distinction.=E2=80=9D The equivalent text for x.0 vs x is left as an exercise for someone who thinks it=E2=80=99s important. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b6da0e2b9b2e704e7114d13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 23, 2013 at 11:27 AM, Paul Hoffman <pau= l.hoffman@vpnc.org> wrote:
> So far, all the changes we=E2=80=99ve m= ade are of the form =E2=80=9CIf you do $X, $JSON_construct_Y will be intero= perable in the sense that implementations will $Z. If you don=E2=80=99t pro= blems of the form $W can happen.=E2=80=9D
=C2=A0
For numbers li= ke -0.0, do we have any clue at all about what ($X $Z) is? I propose we don= 't.

Well, that could be evidence that this isn= =E2=80=99t worth putting in, which I=E2=80=99m OK with because I don't = think it=E2=80=99s really actionable.=C2=A0 But let=E2=80=99s see.

<= /div>
=E2=80=9CJSON numbers which use 0 or 0.0 for zero, as opposed to = -0 or -0.0, will be interoperable in that software implementations will agr= ee on the zero value. The difference between 0 and -0 is significant in som= e numerically-intensive applications, but implementations which read JSON t= exts cannot be relied upon to preserve that distinction.=E2=80=9D

The equivalent text for x.0 vs x is left as an exercise for someone who= thinks it=E2=80=99s important.
=C2=A0

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

--047d7b6da0e2b9b2e704e7114d13-- From cowan@ccil.org Mon Sep 23 14:21:48 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E1421F9FDE for ; Mon, 23 Sep 2013 14:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.031 X-Spam-Level: X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbHP7SXhwjku for ; Mon, 23 Sep 2013 14:21:40 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 27DF021F9EAD for ; Mon, 23 Sep 2013 14:21:33 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VODZQ-00061j-EU; Mon, 23 Sep 2013 17:21:28 -0400 Date: Mon, 23 Sep 2013 17:21:28 -0400 From: John Cowan To: Tim Bray Message-ID: <20130923212128.GA8032@mercury.ccil.org> References: <44DD1B27-6F20-47A3-ABBB-F474BF7AAD84@vpnc.org> <20130923162834.344.qmail@joyce.lan> <0027859F-C891-4279-A507-1D19F2E46720@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Dealing with -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 21:21:48 -0000 Tim Bray scripsit: > “JSON numbers which use 0 or 0.0 for zero, as opposed to -0 or -0.0, will > be interoperable in that software implementations will agree on the zero > value. The difference between 0 and -0 is significant in some > numerically-intensive applications, but implementations which read JSON > texts cannot be relied upon to preserve that distinction.†+1 > The equivalent text for x.0 vs x is left as an exercise for someone who > thinks it’s important. I certainly don't. From the Scheme viewpoint, x.0 is an inexact integer, whereas x is an exact integer, but both are considered integers. -- John Cowan cowan@ccil.org http://ccil.org/~cowan You cannot enter here. Go back to the abyss prepared for you! Go back! Fall into the nothingness that awaits you and your Master. Go! --Gandalf From mnot@mnot.net Mon Sep 23 17:00:28 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F8321F8947 for ; Mon, 23 Sep 2013 17:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.394 X-Spam-Level: X-Spam-Status: No, score=-105.394 tagged_above=-999 required=5 tests=[AWL=-2.795, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afkf3lSrzAk2 for ; Mon, 23 Sep 2013 17:00:23 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE1B11E80FC for ; Mon, 23 Sep 2013 17:00:23 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.135.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4E48F50A87; Mon, 23 Sep 2013 20:00:17 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Mark Nottingham In-Reply-To: <87C14962-3BCD-4272-83FB-5F90488A4706@tzi.org> Date: Tue, 24 Sep 2013 10:00:13 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <98062D9F-5020-46D2-9BDB-3E636BAEADEA@mnot.net> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <87C14962-3BCD-4272-83FB-5F90488A4706@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1510) Cc: "Manger, James H" , Paul Hoffman , " WG" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 00:00:28 -0000 On 24/09/2013, at 1:59 AM, Carsten Bormann wrote: > On Sep 23, 2013, at 17:46, Paul Hoffman wrote: >=20 >> How do others feel about making a change in the -bis that is "things = that have happened since 4627" that don't change the JSON grammar? >=20 > Uneasy, if the intention is normative. > My other question would be: > Are we ready to say that RFC 6901 is *the* fragment identifier syntax = for JSON? >=20 > RFC 6901 actually says: >=20 > In > particular, the fragment identifier syntax for application/json is > not JSON Pointer. >=20 > I don't know enough about the history of that sentence to understand = whether that is a statement of fact (obviously true at the time) or a = statement of intention. It was a statement of fact at the time; we couldn't retroactively change = the fragment identifier syntax for JSON without a much broader mandate. Regards, -- Mark Nottingham http://www.mnot.net/ From tbray@textuality.com Mon Sep 23 18:57:47 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9594D21F9E8B for ; Mon, 23 Sep 2013 18:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIm87dn-bCup for ; Mon, 23 Sep 2013 18:57:38 -0700 (PDT) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 623F021F9FE9 for ; Mon, 23 Sep 2013 18:57:37 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id f12so2945566vbg.11 for ; Mon, 23 Sep 2013 18:57:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ev62C8zmjIlgKxM97GcEFrfGQ9wT4rMLXH1q8pB9slA=; b=WAhrRGJdj9w3rl+WQyz98YQv6WYLr+/6tjS8XdHfVQhusFPKnHlI1L1y0mTbuPw+P9 3YnPkJDZ1BnQJY3ejkldIDwfOry9B4g5STXlrRpWSUuBie1GJsdXB5bPhFxbJPyZAiRX qmIWe+u6g0slsKNzcGuvwOCLj96j8fxgGl+V7TLtq3pX1Jx5W6cZhgHHEXTJX8sHhMYJ GmRww0Z39YZi4PB9AvQEU4+CsXGeciURjndIevKzxGh2afG3c3LHkOBu4H/YugBM/2pU fWAsDKchv86VIdoEAA6v7zbKdjC0uV90PSYbI9bAIAyn2J+s0Wl328C84CaiYmf9pQw4 4eow== X-Gm-Message-State: ALoCoQmlVHE7OBZs65O2t4/MN2PiWsXZu+vafhW+mjPywZ4GfkbMK3Ry6JzUCTio6/4UWXnPdS/m MIME-Version: 1.0 X-Received: by 10.52.171.198 with SMTP id aw6mr1630072vdc.51.1379987854162; Mon, 23 Sep 2013 18:57:34 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Mon, 23 Sep 2013 18:57:34 -0700 (PDT) X-Originating-IP: [24.84.235.32] Date: Mon, 23 Sep 2013 18:57:34 -0700 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=089e0163427ad78df904e7177592 Subject: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 01:57:47 -0000 --089e0163427ad78df904e7177592 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How about we enhance the text following the ABNF in the =E2=80=9CNumbers=E2= =80=9D section to say: This specification allows implementations to set limits on the range of numbers accepted. Since software which correctly implements IEEE 754-2008 [IEEE754] is generally available and widely used, good interoperability can be achieved by limiting numbers in JSON texts to those within the precision and magnitude expressible in an IEEE 754 binary64 (double precision) number. Note that when such software is used, numbers which are integers, in the range [(-2**53)+1, (2**53)-1], and are represented without "frac" parts, for example as 3 not 3.0, are interoperable in the sense that implementations will agree exactly on the numeric values. Attempting to represent numbers that cannot be exactly encoded as an IEEE 754:2008 binary64 number, such as 1E400, 9007199254740993, or 3.141592653589793238462643383279, may cause interoperability problems. Numbers which represent zero without a sign, for example as 0 or 0.0 not -0 or +0.0, are interoperable in the sense that software implementations will agree on the zero value. Signed zeros are significant in some numerically-intensive applications, but implementations which read JSON texts cannot be relied upon to preserve that distinction. --089e0163427ad78df904e7177592 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How about we enhance the text following the ABNF in the = =E2=80=9CNumbers=E2=80=9D section to say:

This specification allows = implementations to set limits on the range of numbers accepted. Since softw= are which correctly implements IEEE 754-2008 [IEEE754] is generally availab= le and widely used, good interoperability can be achieved by limiting numbe= rs in JSON texts to those within the precision and magnitude expressible in= an IEEE 754 binary64 (double precision) number. Note that when such softwa= re is used, numbers which are integers, in the range [(-2**53)+1, (2**53)-1= ], and are represented without "frac" parts, for example as 3 not= 3.0, are interoperable in the sense that implementations will agree exactl= y on the numeric values.

Attempting to represent numbers that cannot be exactly encoded as an IE= EE 754:2008 binary64 number, such as 1E400, 9007199254740993, or 3.14159265= 3589793238462643383279, may cause interoperability problems.

Numbers= which represent zero without a sign, for example as 0 or 0.0 not -0 or +0.= 0, are interoperable in the sense that software implementations will agree = on the zero value. Signed zeros are significant in some numerically-intensi= ve applications, but implementations which read JSON texts cannot be relied= upon to preserve that distinction.
--089e0163427ad78df904e7177592-- From sayrer@gmail.com Mon Sep 23 19:11:14 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AC321F9A5F for ; Mon, 23 Sep 2013 19:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgs8bT4FNm0t for ; Mon, 23 Sep 2013 19:11:14 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBBB21F99D5 for ; Mon, 23 Sep 2013 19:11:14 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id q4so2684251qcx.26 for ; Mon, 23 Sep 2013 19:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8i97JQ1++nzF8DijkRT+XG7yaz2MMARcEgKCCM9Obs8=; b=S0/s1Jk1RqoJt6qiadbGfsbpQ2zIoz5Htdfyj1ZuYcN9Vpzw0Ct9agnyXOYDbqsX26 aPdMqOYaWK52PXuEpOOSsvtrYwsi6+tp/yk//9mPlPEbOLwNkL+lrpvqMkj45fHW97yB QHL4eitcTtapxjzkhUBV8JS8Mpj7kJuqXwguOk64Q80FHYJmVciAdwpgb1PiAQ6KdAFG 67x4Bye4fU7SQSrdIw1mjwHcd6Tijgbkx7MESPusSmwTYW+vlMbzQ1+hJWHYIVtRN7VB tYsKH5PtwObILfRZ1LAxpQjKoFXUY4Z6oubkw0mzR2QMKXcnMWdA7vI/jwubkmIk6CCi CsAA== MIME-Version: 1.0 X-Received: by 10.224.167.18 with SMTP id o18mr5317203qay.87.1379988673675; Mon, 23 Sep 2013 19:11:13 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 19:11:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Sep 2013 19:11:13 -0700 Message-ID: From: R S To: Tim Bray Content-Type: multipart/alternative; boundary=089e01294f5ab04b6504e717a689 Cc: "json@ietf.org" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 02:11:14 -0000 --089e01294f5ab04b6504e717a689 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 23, 2013 at 6:57 PM, Tim Bray wrote: > > Signed zeros are significant in some numerically-intensive applications, > but implementations which read JSON texts cannot be relied upon to preserve > that distinction. > Aren't these implementations just buggy? This works in the JavaScript implementations I checked: > var input = '{"pos":0, "neg":-0}' undefined > var obj = JSON.parse(input) undefined > 1/obj.pos Infinity > 1/obj.neg -Infinity - Rob > --089e01294f5ab04b6504e717a689 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 23, 2013 at 6:57 PM, Tim Bray <tbray@textu= ality.com> wrote:

=A0Signed zeros are significant in some numerically-intensive applicati= ons, but implementations which read JSON texts cannot be relied upon to pre= serve that distinction.

Aren't th= ese implementations just buggy?

This works in the JavaScript implementations I checked:=

> var input =3D '{"pos":0, = "neg":-0}'
undefined
> var obj =3D JSO= N.parse(input)
undefined
> 1/obj.pos
Infinity
> 1= /obj.neg
-Infinity

- Rob
><= /div>
--089e01294f5ab04b6504e717a689-- From paul.hoffman@vpnc.org Mon Sep 23 19:37:14 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF7A21F9DE1 for ; Mon, 23 Sep 2013 19:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmESNuUxYBdN for ; Mon, 23 Sep 2013 19:37:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2851E21F9D94 for ; Mon, 23 Sep 2013 19:37:13 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8O2b8k0059835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Sep 2013 19:37:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Mon, 23 Sep 2013 19:37:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1E04055A-D000-4BE0-BE18-D9F7447B2253@vpnc.org> References: To: R S X-Mailer: Apple Mail (2.1510) Cc: "json@ietf.org WG" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 02:37:14 -0000 On Sep 23, 2013, at 7:11 PM, R S wrote: > On Mon, Sep 23, 2013 at 6:57 PM, Tim Bray = wrote: >=20 > Signed zeros are significant in some numerically-intensive = applications, but implementations which read JSON texts cannot be relied = upon to preserve that distinction. >=20 > Aren't these implementations just buggy? Not that I can see from RFC 4627. It is silent on the meaning of = numbers. > This works in the JavaScript implementations I checked: >=20 > > var input =3D '{"pos":0, "neg":-0}' > undefined > > var obj =3D JSON.parse(input) > undefined > > 1/obj.pos > Infinity > > 1/obj.neg > -Infinity JSON !=3D JavaScript, of course. --Paul Hoffman From sayrer@gmail.com Mon Sep 23 19:43:23 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAD411E80F8 for ; Mon, 23 Sep 2013 19:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNofEA+yol8V for ; Mon, 23 Sep 2013 19:43:23 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id F208F11E80F5 for ; Mon, 23 Sep 2013 19:43:22 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id r5so2707598qcx.37 for ; Mon, 23 Sep 2013 19:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Noj3tSwkD3FjkqOJv9kIPnC8XOWXj3Q9BOOkU0ovGEk=; b=v9TMpetk7BSf6v2pJXohJqtNrdYs52GNFVxp/aYru/ixXD1Z5rWi9CZ1aRSanUOjkl WZnVjenMtMm6m/0Wlq14hhFtWAtayH7p7lzbicZ3DGCRuykmNrKzXGM0OVqodqROaB0E rpJpBYrjAF5RvkCSxVlOPWG/XZw1Dlm7u9a7Dx0sax7hnNm3CLPQmmuuTlNpNSdGUnRA +bv5AwezjkkjUjg/27o4QIuqaxMMWNVrnl3K2rBVJY/x0mUAqltBpsqBBVrVc1L7QQ6p 27akgiOLvndO5hVXdlVB/+nAWAJ6XKAgTiQWNnoQRTKxxM77Mtxpf+eICWLpnPz7GeFq LOkw== MIME-Version: 1.0 X-Received: by 10.224.167.18 with SMTP id o18mr5389368qay.87.1379990602321; Mon, 23 Sep 2013 19:43:22 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 19:43:22 -0700 (PDT) In-Reply-To: <1E04055A-D000-4BE0-BE18-D9F7447B2253@vpnc.org> References: <1E04055A-D000-4BE0-BE18-D9F7447B2253@vpnc.org> Date: Mon, 23 Sep 2013 19:43:22 -0700 Message-ID: From: R S To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e01294f5aa5155f04e71819cd Cc: "json@ietf.org WG" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 02:43:23 -0000 --089e01294f5aa5155f04e71819cd Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 23, 2013 at 7:37 PM, Paul Hoffman wrote: > > > JSON != JavaScript, of course. I think the issue has more to do with IEEE754, but I am not a floating point lawyer. n.b. that the sign of zero may be disregarded by a language's equality operator (it is in JavaScript) $ ruby -v ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-linux] $ irb 2.0.0p247 :001 > require 'yajl' => true 2.0.0p247 :002 > parser = Yajl::Parser.new => # 2.0.0p247 :003 > a = parser.parse('{"a":0.0, "b":-0.0}') => {"a"=>0.0, "b"=>-0.0} 2.0.0p247 :004 > a['a'] == a['b'] => true 2.0.0p247 :005 > 1/a['a'] => Infinity 2.0.0p247 :006 > 1/a['b'] => -Infinity - Rob --089e01294f5aa5155f04e71819cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 23, 2013 at 7:37 PM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:


JSON !=3D JavaScript, of course.

I th= ink the issue has more to do with IEEE754, but I am not a floating point la= wyer.

n.b. that the sign of zero may be disregarde= d by a language's equality operator (it is in JavaScript)=A0

$ ruby -v
ruby 2.0.0p247 (2013-06-= 27 revision 41674) [x86_64-linux]

$ irb
2.0.0p247 :001 > require 'yajl'
=A0=3D> true= =A0

2.0.0p247 :002 > parser =3D Yajl::Parser.new
=A0=3D> #<Yajl::Parser:0x00000000c0f6c0>=A0

2.0.0p247 :003 > a =3D parser.parse('{"a":0.0, "= ;b":-0.0}')
=A0=3D> {"a"=3D>0.0, "b"=3D>-0.0}=A0

2.0.0p247 :004 > a['a'] =3D=3D a['b'= ;]
=A0=3D> true=A0

2.0.0p247 :005 >= ; 1/a['a']
=A0=3D> Infinity=A0

2.0.0p247 :006 > 1/= a['b']
=A0=3D> -Infinity=A0

-= Rob
--089e01294f5aa5155f04e71819cd-- From johnl@iecc.com Mon Sep 23 19:50:33 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F62421F938E for ; Mon, 23 Sep 2013 19:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBfkFAMwbZvw for ; Mon, 23 Sep 2013 19:50:29 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 50E2521F849C for ; Mon, 23 Sep 2013 19:50:28 -0700 (PDT) Received: (qmail 48600 invoked from network); 24 Sep 2013 02:50:26 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Sep 2013 02:50:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5240fdf2.xn--btvx9d.k1309; i=johnl@user.iecc.com; bh=LNgnkHui5P/b/gt6jpXnAzskvY48rALVaATIFNKJzRk=; b=t7HC0g7pkoiwLeSP7JuRCNzT6daaIoAhX8/VJftHcjgXTKek6tbdqXa2PQ0qcT2d8lewftWkWG0HZNKDqYq0IBtlE3bofNriQMxFYdiipCo5vXhr9mAJQvDJQzjO5sRWLa4qw2nxt2HyInqjTljz5h3whBf3u0oAxXtO3vCXAz/rc2iW++aeXe/tkjWIJGGgp0s4US3FuEfIes+HyUNwK0fWNkrUD3xGTEK1fravfXSWjCqka6gQ6Z5UMJ3Nk0Yp DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5240fdf2.xn--btvx9d.k1309; olt=johnl@user.iecc.com; bh=LNgnkHui5P/b/gt6jpXnAzskvY48rALVaATIFNKJzRk=; b=anry2sq5MbYjZi7NH+KMafG70j42GPPjpwv6DV1izFgtQbzHLy3oiGPPL6cy+714e6GdQG5sSkPWea/joIMcbxcyqFmr/QQPcFk8EcZskjIadTuNLARfznVSIySIqQIZY30WiuXEw04VO7SkiQUIeeZOFOurJh+o0o3UrrZesQhULpu1jUqzUonp07jjLKHwG7fJcObHA+YrMOUva0AOrXFOZcDJvdFp2ClyUDhmxDyx7GKIk8aXNiN960sEUt6n Date: 24 Sep 2013 02:50:04 -0000 Message-ID: <20130924025004.2582.qmail@joyce.lan> From: "John Levine" To: json@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: sayrer@gmail.com Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 02:50:33 -0000 >> Signed zeros are significant in some numerically-intensive applications, >> but implementations which read JSON texts cannot be relied upon to preserve >> that distinction. > >Aren't these implementations just buggy? No. It's perfectly legitimate to have an implementation that only handles integers, if you know that's all your application will need. They don't do signed zeros. There are also still some non-IEEE floating point formats in use that don't reliably preserve the sign of a zero. R's, John From tbray@textuality.com Mon Sep 23 20:29:27 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1055921F9BB6 for ; Mon, 23 Sep 2013 20:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yd5Ah517t+dj for ; Mon, 23 Sep 2013 20:29:22 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id E962F21F9BB1 for ; Mon, 23 Sep 2013 20:29:21 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id oy12so3198339veb.27 for ; Mon, 23 Sep 2013 20:29:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ET0RvWZ1u7EL1TOlaaVkjil+LnrmOqnbcdeYFV7r7Q8=; b=gy00f/dM+7JuXoOlPw9flQZetCbQFWPWk3jRy73kZrgrltwe7XzSuM/TjoM+aQlDGt RriQs6cFCc7V7HhX53HKkXTiHpBmrPbv5PHtyfLh/vuBYwmFmpBCr8lCcP0/k0AW/rK6 3a79BeslvqRH+G7H/6uDI5PyHXOZuG9ejN0n3mXrwhXFlXVL/uM1WJ9kjCkV3W0Ew6JQ 9pXI40dF4J+khEqjgt/+eOgV0aZGSrsEUrLTrWAP3Xkj15syABHMI/foaU7jRCAEI/nz 6uMQrClfJ163NyZt5qXWSs3GFHAQu+ga/AzTKXdakBs0XCLo9jRY8Z9zYqFgSiUcBvaj JPlA== X-Gm-Message-State: ALoCoQnVGwyuDyFNDeTzIiXUf5TTxHaGtRpHXRmcJ9qiSpMCClSLCh7LkGhS4KHC4UO2Wq2Lek0l MIME-Version: 1.0 X-Received: by 10.220.249.67 with SMTP id mj3mr4570883vcb.23.1379993360340; Mon, 23 Sep 2013 20:29:20 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Mon, 23 Sep 2013 20:29:20 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <1E04055A-D000-4BE0-BE18-D9F7447B2253@vpnc.org> Date: Mon, 23 Sep 2013 20:29:20 -0700 Message-ID: From: Tim Bray To: R S Content-Type: multipart/alternative; boundary=089e013a15e6092be604e718be53 Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 03:29:27 -0000 --089e013a15e6092be604e718be53 Content-Type: text/plain; charset=UTF-8 So, we observe that two different json libraries in one language have incompatible behavior. I think this is evidence that the proposed language is useful. -T On Mon, Sep 23, 2013 at 7:43 PM, R S wrote: > On Mon, Sep 23, 2013 at 7:37 PM, Paul Hoffman wrote: > >> >> >> JSON != JavaScript, of course. > > > I think the issue has more to do with IEEE754, but I am not a floating > point lawyer. > > n.b. that the sign of zero may be disregarded by a language's equality > operator (it is in JavaScript) > > $ ruby -v > ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-linux] > > $ irb > 2.0.0p247 :001 > require 'yajl' > => true > > 2.0.0p247 :002 > parser = Yajl::Parser.new > => # > > 2.0.0p247 :003 > a = parser.parse('{"a":0.0, "b":-0.0}') > => {"a"=>0.0, "b"=>-0.0} > > 2.0.0p247 :004 > a['a'] == a['b'] > => true > > 2.0.0p247 :005 > 1/a['a'] > => Infinity > > 2.0.0p247 :006 > 1/a['b'] > => -Infinity > > - Rob > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --089e013a15e6092be604e718be53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, we observe that two different json libraries in one la= nguage have incompatible behavior. I think this is evidence that the propos= ed language is useful.=C2=A0 -T

On Mon, Sep 23, 2013 at 7:43 PM, R S <sayrer@gmail.com> wrote= :
On Mon, Sep 23, 2013 at 7:37 PM, Paul Ho= ffman <paul.hoffman@vpnc.org> wrote:


JSON !=3D JavaScript, of course.

I think the issue has more to do with IEEE754, but I am not a floating po= int lawyer.

n.b. that the sign of zero may be disr= egarded by a language's equality operator (it is in JavaScript)=C2=A0

$ ruby -v
ruby 2.0.0p247 (2013-06-= 27 revision 41674) [x86_64-linux]

$ irb
2.0.0p247 :001 > require 'yajl'
=C2=A0=3D> tr= ue=C2=A0

2.0.0p247 :002 > parser =3D Yajl::Parser.new
=C2=A0=3D> #<Yajl::Parser:0x00000000c0f6c0>=C2=A0
2.0.0p247 :003 > a =3D parser.parse('{"a":0.0,= "b":-0.0}')
=C2=A0=3D> {"a"=3D>0.0, "b"=3D>-0.0}=C2= =A0

2.0.0p247 :004 > a['a'] =3D=3D a[&#= 39;b']
=C2=A0=3D> true=C2=A0

2.0.= 0p247 :005 > 1/a['a']
=C2=A0=3D> Infinity=C2=A0

2.0.0p247 :006 &= gt; 1/a['b']
=C2=A0=3D> -Infinity=C2=A0

=
- Rob

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


--089e013a15e6092be604e718be53-- From pbryan@anode.ca Mon Sep 23 20:35:03 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D3521F9D3A for ; Mon, 23 Sep 2013 20:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqxyxBmKQqIE for ; Mon, 23 Sep 2013 20:34:58 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id E0FAB21F9D3E for ; Mon, 23 Sep 2013 20:34:57 -0700 (PDT) Received: from [192.168.1.4] (S0106a021b762dbb3.vf.shawcable.net [174.1.50.247]) by maple.anode.ca (Postfix) with ESMTPSA id 61E9B64CA; Tue, 24 Sep 2013 03:34:56 +0000 (UTC) Message-ID: <1379993594.19960.2.camel@dilithium> From: "Paul C. Bryan" To: R S Date: Mon, 23 Sep 2013 20:33:14 -0700 In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> Content-Type: multipart/alternative; boundary="=-ozUEPxNd+AB0hjK74DPq" X-Mailer: Evolution 3.4.4-4+b1 Mime-Version: 1.0 Cc: "Manger, James H" , Paul Hoffman , json@ietf.org Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 03:35:03 -0000 --=-ozUEPxNd+AB0hjK74DPq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit JSON Pointer was designed for multiple purposes, including as a fragment identifier in URIs. On Mon, 2013-09-23 at 09:11 -0700, R S wrote: > This is a bad idea. JSON pointer was designed for a narrow patch use > case, and can't disambiguate objects and arrays. > > The JSON RFC shouldn't list every RFC that uses JSON. > > - Rob > > > > On Sep 20, 2013, at 10:00 PM, "Manger, James H" > wrote: > > > RFC 4627 doesn't define how URI fragments work for application/json > content. > > > > It would be helpful for 4627bis to say that a fragment (that begins > with a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointer > identifies a specific value in a JSON text. > > Changing the IANA MIME registry entry can be done, but I propose that > we don't do it as part of the -bis because it is not really a > clarification. This update can be done with a separate draft that > updates the registry, but I admit that people tend to just read the > RFCs, not the registry and therefore this is likely to be missed. > > How do others feel about making a change in the -bis that is "things > that have happened since 4627" that don't change the JSON grammar? > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --=-ozUEPxNd+AB0hjK74DPq Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit JSON Pointer was designed for multiple purposes, including as a fragment identifier in URIs.

On Mon, 2013-09-23 at 09:11 -0700, R S wrote:
This is a bad idea. JSON pointer was designed for a narrow patch use case, and can't disambiguate objects and arrays.

The JSON RFC shouldn't list every RFC that uses JSON.

- Rob

<no hat>

On Sep 20, 2013, at 10:00 PM, "Manger, James H" <james.h.manger@team.telstra.com> wrote:

> RFC 4627 doesn't define how URI fragments work for application/json content.
>
> It would be helpful for 4627bis to say that a fragment (that begins with a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointer identifies a specific value in a JSON text.

Changing the IANA MIME registry entry can be done, but I propose that we don't do it as part of the -bis because it is not really a clarification. This update can be done with a separate draft that updates the registry, but I admit that people tend to just read the RFCs, not the registry and therefore this is likely to be missed.

How do others feel about making a change in the -bis that is "things that have happened since 4627" that don't change the JSON grammar?

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


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

--=-ozUEPxNd+AB0hjK74DPq-- From sayrer@gmail.com Mon Sep 23 20:41:58 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B8D21F9D94 for ; Mon, 23 Sep 2013 20:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmAD0qkJvcGr for ; Mon, 23 Sep 2013 20:41:57 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id A92B321F9D71 for ; Mon, 23 Sep 2013 20:41:57 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id k4so2145005qaq.12 for ; Mon, 23 Sep 2013 20:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3qZmB9uhZUHr1qVAthMkFWRkFkxPT5ea9du0QeXU4JM=; b=FFdHoX5oA4NLNbBVCa9Y7iPBYQr1aISRR2TMOtLsgYwDhXSLWFcJrCRyFkvJh0IdpC bZvAdzAJ8eidb6TaLL8xorgCsm1TrahwuYNxdH8Hc5pAFL4SaFDN0E5cxLdWTvwz3HGJ 14VxCTv5eSXpms+Sed1DxlJ36pSIrjaGXhydhonxRImX8CMPZEsXGxefeJ8+UGs5K0S8 hnwbIkhCQlJrCWQvlU+8g3C9eFnaMwfFWZtsBbuMLrWJe6buEFCPkOz/ndD+heOkycMV 6pjdKoxqra53hbShr8iiys2fj1FNZ7DXaIp3Uw3v5wJEfsqYikOQMU68QLaE1G2NL1On UeUA== MIME-Version: 1.0 X-Received: by 10.229.251.201 with SMTP id mt9mr5116149qcb.26.1379994116943; Mon, 23 Sep 2013 20:41:56 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 20:41:56 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 20:41:56 -0700 (PDT) In-Reply-To: <1379993594.19960.2.camel@dilithium> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> Date: Mon, 23 Sep 2013 20:41:56 -0700 Message-ID: From: R S To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=001a1134a8e221f6dc04e718eb08 Cc: "Manger, James H" , Paul Hoffman , json@ietf.org Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 03:41:58 -0000 --001a1134a8e221f6dc04e718eb08 Content-Type: text/plain; charset=ISO-8859-1 Who designed it? Anyway, it is buggy as a general purpose fragment identifier. - Rob On Sep 23, 2013 8:34 PM, "Paul C. Bryan" wrote: > ** > JSON Pointer was designed for multiple purposes, including as a fragment > identifier in URIs. > > On Mon, 2013-09-23 at 09:11 -0700, R S wrote: > > This is a bad idea. JSON pointer was designed for a narrow patch use case, > and can't disambiguate objects and arrays. > > The JSON RFC shouldn't list every RFC that uses JSON. > > - Rob > > > > On Sep 20, 2013, at 10:00 PM, "Manger, James H" < > james.h.manger@team.telstra.com> wrote: > > > RFC 4627 doesn't define how URI fragments work for application/json > content. > > > > It would be helpful for 4627bis to say that a fragment (that begins with > a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointer identifies > a specific value in a JSON text. > > Changing the IANA MIME registry entry can be done, but I propose that we > don't do it as part of the -bis because it is not really a clarification. > This update can be done with a separate draft that updates the registry, > but I admit that people tend to just read the RFCs, not the registry and > therefore this is likely to be missed. > > How do others feel about making a change in the -bis that is "things that > have happened since 4627" that don't change the JSON grammar? > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > > _______________________________________________ > json mailing listjson@ietf.orghttps://www.ietf.org/mailman/listinfo/json > > > --001a1134a8e221f6dc04e718eb08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Who designed it?

Anyway, it is buggy as a general purpose fragment identifier= .

- Rob

On Sep 23, 2013 8:34 PM, "Paul C. Bryan&quo= t; <pbryan@anode.ca> wrote:
=20 =20
JSON Pointer was designed for multiple purposes, including as a fragment id= entifier in URIs.

On Mon, 2013-09-23 at 09:11 -0700, R S wrote:
This is a bad idea. JSON pointer was designed for a narrow patch use ca= se, and can't disambiguate objects and arrays.

The JSON RFC shouldn't list every RFC that uses JSON.

- Rob

<no hat>

On Sep 20, 2013, at 10:00 PM, "Manger, James H" <james.h.mange= r@team.telstra.com> wrote:

> RFC 4627 doesn't define how URI fragments work for application= /json content.
>
> It would be helpful for 4627bis to say that a fragment (that begin= s with a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Po= inter identifies a specific value in a JSON text.

Changing the IANA MIME registry entry can be done, but I propose that w= e don't do it as part of the -bis because it is not really a clarificat= ion. This update can be done with a separate draft that updates the registr= y, but I admit that people tend to just read the RFCs, not the registry and= therefore this is likely to be missed.

How do others feel about making a change in the -bis that is "thin= gs that have happened since 4627" that don't change the JSON gramm= ar?

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


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

--001a1134a8e221f6dc04e718eb08-- From pbryan@anode.ca Mon Sep 23 20:44:17 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC3221F9DAD for ; Mon, 23 Sep 2013 20:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkOU6otuaMeA for ; Mon, 23 Sep 2013 20:44:13 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0A921F9DAA for ; Mon, 23 Sep 2013 20:44:13 -0700 (PDT) Received: from [192.168.1.4] (S0106a021b762dbb3.vf.shawcable.net [174.1.50.247]) by maple.anode.ca (Postfix) with ESMTPSA id CBD4064CA; Tue, 24 Sep 2013 03:44:11 +0000 (UTC) Message-ID: <1379994149.19960.4.camel@dilithium> From: "Paul C. Bryan" To: R S Date: Mon, 23 Sep 2013 20:42:29 -0700 In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> Content-Type: multipart/alternative; boundary="=-apWeLiBfgIUthMQKoqrT" X-Mailer: Evolution 3.4.4-4+b1 Mime-Version: 1.0 Cc: "Manger, James H" , Paul Hoffman , json@ietf.org Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 03:44:17 -0000 --=-apWeLiBfgIUthMQKoqrT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit It was designed by the JSON Schema working group. On Mon, 2013-09-23 at 20:41 -0700, R S wrote: > Who designed it? > > Anyway, it is buggy as a general purpose fragment identifier. > > - Rob > > > On Sep 23, 2013 8:34 PM, "Paul C. Bryan" wrote: > > JSON Pointer was designed for multiple purposes, including as > a fragment identifier in URIs. > > On Mon, 2013-09-23 at 09:11 -0700, R S wrote: > > > This is a bad idea. JSON pointer was designed for a narrow > > patch use case, and can't disambiguate objects and arrays. > > > > The JSON RFC shouldn't list every RFC that uses JSON. > > > > - Rob > > > > > > > > On Sep 20, 2013, at 10:00 PM, "Manger, James H" > > wrote: > > > > > RFC 4627 doesn't define how URI fragments work for > > application/json content. > > > > > > It would be helpful for 4627bis to say that a fragment > > (that begins with a "/" or is empty) is a JSON Pointer [RFC > > 6901]. A JSON Pointer identifies a specific value in a JSON > > text. > > > > Changing the IANA MIME registry entry can be done, but I > > propose that we don't do it as part of the -bis because it > > is not really a clarification. This update can be done with > > a separate draft that updates the registry, but I admit that > > people tend to just read the RFCs, not the registry and > > therefore this is likely to be missed. > > > > How do others feel about making a change in the -bis that is > > "things that have happened since 4627" that don't change the > > JSON grammar? > > > > --Paul Hoffman > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > > > > > > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > > --=-apWeLiBfgIUthMQKoqrT Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit It was designed by the JSON Schema working group.

On Mon, 2013-09-23 at 20:41 -0700, R S wrote:
Who designed it?

Anyway, it is buggy as a general purpose fragment identifier.

- Rob

On Sep 23, 2013 8:34 PM, "Paul C. Bryan" <pbryan@anode.ca> wrote:
JSON Pointer was designed for multiple purposes, including as a fragment identifier in URIs.

On Mon, 2013-09-23 at 09:11 -0700, R S wrote:
This is a bad idea. JSON pointer was designed for a narrow patch use case, and can't disambiguate objects and arrays.

The JSON RFC shouldn't list every RFC that uses JSON.

- Rob

<no hat>

On Sep 20, 2013, at 10:00 PM, "Manger, James H" <james.h.manger@team.telstra.com> wrote:

> RFC 4627 doesn't define how URI fragments work for application/json content.
>
> It would be helpful for 4627bis to say that a fragment (that begins with a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointer identifies a specific value in a JSON text.

Changing the IANA MIME registry entry can be done, but I propose that we don't do it as part of the -bis because it is not really a clarification. This update can be done with a separate draft that updates the registry, but I admit that people tend to just read the RFCs, not the registry and therefore this is likely to be missed.

How do others feel about making a change in the -bis that is "things that have happened since 4627" that don't change the JSON grammar?

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


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



--=-apWeLiBfgIUthMQKoqrT-- From sayrer@gmail.com Mon Sep 23 20:46:04 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50A421F9C90 for ; Mon, 23 Sep 2013 20:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD1ALG4hRg9X for ; Mon, 23 Sep 2013 20:46:03 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8685621F9946 for ; Mon, 23 Sep 2013 20:46:03 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id j7so2146284qaq.16 for ; Mon, 23 Sep 2013 20:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2aCibyaByFfIRRzbKZCmCNu2or7ApsVOFhosGC+5S4Y=; b=uIv1ZISfZgiAXg9vua2EQUQeyoIvLKcqUajDNTD5Ce9nBHpWnYH0z2rpeD6pBXClSW 9M15RWKsfyskyyuUrBVGP/j3XNF/b1VjOFydSyG+d3r7WrVlRaMZQ07q5sTXWkdukAni YxY3TPbAnFjt3yo7ljGyW6IFuuuLVSWzG557ai4YKg1InosnJSS0uAn0BQvYqXquvmnw Fa/b9aNoa8mfjCbdmyxnEG7mvQz1EYwV3NFkY8pQJNkOEkraW5V9W4ceQnBNUcAEQesO 9Uio52aJ5pDafe8YIcqCJJRFrMG6zcrW/BfOh+Rj7adf5x+SeizDW7QHQHCGcUmps7nt Xasw== MIME-Version: 1.0 X-Received: by 10.229.73.6 with SMTP id o6mr33616984qcj.2.1379994362469; Mon, 23 Sep 2013 20:46:02 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 20:46:02 -0700 (PDT) In-Reply-To: References: <1E04055A-D000-4BE0-BE18-D9F7447B2253@vpnc.org> Date: Mon, 23 Sep 2013 20:46:02 -0700 Message-ID: From: R S To: Tim Bray Content-Type: multipart/alternative; boundary=001a11c2c8a2c4642b04e718f94f Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 03:46:04 -0000 --001a11c2c8a2c4642b04e718f94f Content-Type: text/plain; charset=ISO-8859-1 Fully disagree with this rationale and the proposed text. The rationale is wrong because it can be used to allow an exception for any buggy implementation, and the text is wrong because "implementations which read JSON texts" can be relied upon to preserve negative zeros. - Rob On Mon, Sep 23, 2013 at 8:29 PM, Tim Bray wrote: > So, we observe that two different json libraries in one language have > incompatible behavior. I think this is evidence that the proposed language > is useful. -T > > > On Mon, Sep 23, 2013 at 7:43 PM, R S wrote: > >> On Mon, Sep 23, 2013 at 7:37 PM, Paul Hoffman wrote: >> >>> >>> >>> JSON != JavaScript, of course. >> >> >> I think the issue has more to do with IEEE754, but I am not a floating >> point lawyer. >> >> n.b. that the sign of zero may be disregarded by a language's equality >> operator (it is in JavaScript) >> >> $ ruby -v >> ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-linux] >> >> $ irb >> 2.0.0p247 :001 > require 'yajl' >> => true >> >> 2.0.0p247 :002 > parser = Yajl::Parser.new >> => # >> >> 2.0.0p247 :003 > a = parser.parse('{"a":0.0, "b":-0.0}') >> => {"a"=>0.0, "b"=>-0.0} >> >> 2.0.0p247 :004 > a['a'] == a['b'] >> => true >> >> 2.0.0p247 :005 > 1/a['a'] >> => Infinity >> >> 2.0.0p247 :006 > 1/a['b'] >> => -Infinity >> >> - Rob >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> >> > --001a11c2c8a2c4642b04e718f94f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Fully disagree with this rationale and the proposed text. The rationale is= wrong because it can be used to allow an exception for any buggy implement= ation, and the text is wrong because "implementations which read JSON = texts" can be relied upon to preserve negative zeros.

- Rob


On Mon, Sep 23, 20= 13 at 8:29 PM, Tim Bray <tbray@textuality.com> wrote:
So, we observe that two dif= ferent json libraries in one language have incompatible behavior. I think t= his is evidence that the proposed language is useful.=A0 -T


On Mon, Sep 23, 2013 at 7:43 PM, R S <sayrer@gmail.com> wrote= :
On Mon, Sep 23, 2013 at 7:37 PM, Paul Hoffman <p= aul.hoffman@vpnc.org> wrote:


JSON !=3D JavaScript, of course.

I think the issue has more to do with IEEE754, but I am not a floating po= int lawyer.

n.b. that the sign of zero may be disr= egarded by a language's equality operator (it is in JavaScript)=A0

$ ruby -v
ruby 2.0.0p247 (2013-06-= 27 revision 41674) [x86_64-linux]

$ irb
2.0.0p247 :001 > require 'yajl'
=A0=3D> true= =A0

2.0.0p247 :002 > parser =3D Yajl::Parser.new
=A0=3D> #<Yajl::Parser:0x00000000c0f6c0>=A0

2.0.0p247 :003 > a =3D parser.parse('{"a":0.0, "= ;b":-0.0}')
=A0=3D> {"a"=3D>0.0, "b"=3D>-0.0}=A0

2.0.0p247 :004 > a['a'] =3D=3D a['b'= ;]
=A0=3D> true=A0

2.0.0p247 :005 >= ; 1/a['a']
=A0=3D> Infinity=A0

2.0.0p247 :006 > 1/= a['b']
=A0=3D> -Infinity=A0

-= Rob

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



--001a11c2c8a2c4642b04e718f94f-- From sayrer@gmail.com Mon Sep 23 20:49:26 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BEC11E80AD for ; Mon, 23 Sep 2013 20:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDOy3AA6+sMw for ; Mon, 23 Sep 2013 20:49:25 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 90C4021F9FF9 for ; Mon, 23 Sep 2013 20:49:25 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id m20so2798591qcx.1 for ; Mon, 23 Sep 2013 20:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bsS+XPKyG3i25O85a3StL0JB0+Z46K4iASn4aHBEnm4=; b=lTeXP6dD/paGqqp2femOFpXfEGCZV66TL7OfSwAnHg8SJ5GxmwiRiJysdLL9thomic +5paE2GxfIF3i4fRwMPGnz1nwN+HeQ6hYv7rnUacGWyqD+k4weJ6jeyWPx6Trdm+0cNT LAiuw59TqxEXeBCKH7TwFrB9KlePaFVW+PeAkZ4x7OFBzK6u4ETkqMOrW82igq4Ijg1v gEuL28O8dqIOLPWZjDJJFzAyRXKe7BhoOXFUeOQZIh06gY+KTkTT43bo50y/avznUsq7 /V6rPp3GR9XYNImMJDWWcNCl8nHZ/6xOPoGJGyMjSDDAdHGvAum8ZwdgtHgE0vf97YLi wNUw== MIME-Version: 1.0 X-Received: by 10.224.166.2 with SMTP id k2mr5562080qay.88.1379994565071; Mon, 23 Sep 2013 20:49:25 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 20:49:25 -0700 (PDT) In-Reply-To: <1379994149.19960.4.camel@dilithium> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> Date: Mon, 23 Sep 2013 20:49:25 -0700 Message-ID: From: R S To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=047d7bfe957ad7db4504e7190572 Cc: "Manger, James H" , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 03:49:26 -0000 --047d7bfe957ad7db4504e7190572 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 23, 2013 at 8:42 PM, Paul C. Bryan wrote: > ** > It was designed by the JSON Schema working group. > Oh, I see. That credit doesn't appear in RFC 6901. Still seems buggy as a general-purpose fragment identifier, since it can't distinguish between arrays and objects. - Rob > > > On Mon, 2013-09-23 at 20:41 -0700, R S wrote: > > Who designed it? > > Anyway, it is buggy as a general purpose fragment identifier. > > - Rob > > On Sep 23, 2013 8:34 PM, "Paul C. Bryan" wrote: > > JSON Pointer was designed for multiple purposes, including as a fragment > identifier in URIs. > > On Mon, 2013-09-23 at 09:11 -0700, R S wrote: > > This is a bad idea. JSON pointer was designed for a narrow patch use case, > and can't disambiguate objects and arrays. > > The JSON RFC shouldn't list every RFC that uses JSON. > > - Rob > > > > On Sep 20, 2013, at 10:00 PM, "Manger, James H" < > james.h.manger@team.telstra.com> wrote: > > > RFC 4627 doesn't define how URI fragments work for application/json > content. > > > > It would be helpful for 4627bis to say that a fragment (that begins with > a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointer identifies > a specific value in a JSON text. > > Changing the IANA MIME registry entry can be done, but I propose that we > don't do it as part of the -bis because it is not really a clarification. > This update can be done with a separate draft that updates the registry, > but I admit that people tend to just read the RFCs, not the registry and > therefore this is likely to be missed. > > How do others feel about making a change in the -bis that is "things that > have happened since 4627" that don't change the JSON grammar? > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > _______________________________________________ > json mailing listjson@ietf.orghttps://www.ietf.org/mailman/listinfo/json > > > > > --047d7bfe957ad7db4504e7190572 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 23, 2013 at 8:42 PM, Paul C. Bryan <pbryan@an= ode.ca> wrote:
=20 =20
It was designed by the JSON Schema working group.

Oh, I see. That credit doesn't appear in RF= C 6901.

Still seems buggy as a general-purpose fra= gment identifier, since it can't distinguish between arrays and objects= .

- Rob

=A0


On Mon, 2013-09-23 at 20:41 -0700, R S wrote:
Who designed it?

Anyway, it is buggy as a general purpose fragment identifier.

- Rob

On Sep 23, 2013 8:34 PM, "Paul C. Bryan" <pbryan@anode.ca> wrote:
JSON Pointer was designed for multiple purposes, including as a fra= gment identifier in URIs.

On Mon, 2013-09-23 at 09:11 -0700, R S wrote:
This is a bad idea. JSON pointer was designed for a narrow patc= h use case, and can't disambiguate objects and arrays.

The JSON RFC shouldn't list every RFC that uses JSON.

- Rob

<no hat>

On Sep 20, 2013, at 10:00 PM, "Manger, James H" <<= a href=3D"mailto:james.h.manger@team.telstra.com" target=3D"_blank">james.h= .manger@team.telstra.com> wrote:

> RFC 4627 doesn't define how URI fragments work for app= lication/json content.
>
> It would be helpful for 4627bis to say that a fragment (th= at begins with a "/" or is empty) is a JSON Pointer [RFC 6901]. A= JSON Pointer identifies a specific value in a JSON text.

Changing the IANA MIME registry entry can be done, but I propos= e that we don't do it as part of the -bis because it is not really a cl= arification. This update can be done with a separate draft that updates the= registry, but I admit that people tend to just read the RFCs, not the regi= stry and therefore this is likely to be missed.

How do others feel about making a change in the -bis that is &q= uot;things that have happened since 4627" that don't change the JS= ON grammar?

--Paul Hoffman
_______________________________________________
json mailing list
json@ietf.or= g
https://www.ietf.org/mailman/listinfo/json


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




--047d7bfe957ad7db4504e7190572-- From pbryan@anode.ca Mon Sep 23 20:51:28 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D56221F918F for ; Mon, 23 Sep 2013 20:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1PQYdeh+3Jl for ; Mon, 23 Sep 2013 20:51:23 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id C087221F9223 for ; Mon, 23 Sep 2013 20:51:21 -0700 (PDT) Received: from [192.168.1.4] (S0106a021b762dbb3.vf.shawcable.net [174.1.50.247]) by maple.anode.ca (Postfix) with ESMTPSA id AA91D64CA; Tue, 24 Sep 2013 03:51:20 +0000 (UTC) Message-ID: <1379994578.19960.6.camel@dilithium> From: "Paul C. Bryan" To: R S Date: Mon, 23 Sep 2013 20:49:38 -0700 In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> Content-Type: multipart/alternative; boundary="=-nMYPx2Qj8+ElBx9grQtY" X-Mailer: Evolution 3.4.4-4+b1 Mime-Version: 1.0 Cc: "Manger, James H" , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 03:51:28 -0000 --=-nMYPx2Qj8+ElBx9grQtY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Kris Zyp was one of the two leads in the JSON Schema working group, and whose contributions are attributable. He is co-author of RFC 6901. On Mon, 2013-09-23 at 20:49 -0700, R S wrote: > On Mon, Sep 23, 2013 at 8:42 PM, Paul C. Bryan > wrote: > > It was designed by the JSON Schema working group. > > > > > Oh, I see. That credit doesn't appear in RFC 6901. > > > Still seems buggy as a general-purpose fragment identifier, since it > can't distinguish between arrays and objects. > > > - Rob > > > > > > On Mon, 2013-09-23 at 20:41 -0700, R S wrote: > > > Who designed it? > > > > Anyway, it is buggy as a general purpose fragment > > identifier. > > > > - Rob > > > > On Sep 23, 2013 8:34 PM, "Paul C. Bryan" > > wrote: > > > > JSON Pointer was designed for multiple purposes, > > including as a fragment identifier in URIs. > > > > On Mon, 2013-09-23 at 09:11 -0700, R S wrote: > > > > > This is a bad idea. JSON pointer was designed for > > > a narrow patch use case, and can't disambiguate > > > objects and arrays. > > > > > > The JSON RFC shouldn't list every RFC that uses > > > JSON. > > > > > > - Rob > > > > > > > > > > > > On Sep 20, 2013, at 10:00 PM, "Manger, James H" > > > wrote: > > > > > > > RFC 4627 doesn't define how URI fragments work > > > for application/json content. > > > > > > > > It would be helpful for 4627bis to say that a > > > fragment (that begins with a "/" or is empty) is a > > > JSON Pointer [RFC 6901]. A JSON Pointer identifies > > > a specific value in a JSON text. > > > > > > Changing the IANA MIME registry entry can be done, > > > but I propose that we don't do it as part of the > > > -bis because it is not really a clarification. > > > This update can be done with a separate draft that > > > updates the registry, but I admit that people tend > > > to just read the RFCs, not the registry and > > > therefore this is likely to be missed. > > > > > > How do others feel about making a change in the > > > -bis that is "things that have happened since > > > 4627" that don't change the JSON grammar? > > > > > > --Paul Hoffman > > > _______________________________________________ > > > json mailing list > > > json@ietf.org > > > https://www.ietf.org/mailman/listinfo/json > > > > > > > > > > > > _______________________________________________ > > > json mailing list > > > json@ietf.org > > > https://www.ietf.org/mailman/listinfo/json > > > > > > > > > > > > --=-nMYPx2Qj8+ElBx9grQtY Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Kris Zyp was one of the two leads in the JSON Schema working group, and whose contributions are attributable. He is co-author of RFC 6901.

On Mon, 2013-09-23 at 20:49 -0700, R S wrote:
On Mon, Sep 23, 2013 at 8:42 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
It was designed by the JSON Schema working group.




Oh, I see. That credit doesn't appear in RFC 6901.


Still seems buggy as a general-purpose fragment identifier, since it can't distinguish between arrays and objects.


- Rob


 


On Mon, 2013-09-23 at 20:41 -0700, R S wrote:
Who designed it?

Anyway, it is buggy as a general purpose fragment identifier.

- Rob

On Sep 23, 2013 8:34 PM, "Paul C. Bryan" <pbryan@anode.ca> wrote:
JSON Pointer was designed for multiple purposes, including as a fragment identifier in URIs.

On Mon, 2013-09-23 at 09:11 -0700, R S wrote:
This is a bad idea. JSON pointer was designed for a narrow patch use case, and can't disambiguate objects and arrays.

The JSON RFC shouldn't list every RFC that uses JSON.

- Rob

<no hat>

On Sep 20, 2013, at 10:00 PM, "Manger, James H" <james.h.manger@team.telstra.com> wrote:

> RFC 4627 doesn't define how URI fragments work for application/json content.
>
> It would be helpful for 4627bis to say that a fragment (that begins with a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointer identifies a specific value in a JSON text.

Changing the IANA MIME registry entry can be done, but I propose that we don't do it as part of the -bis because it is not really a clarification. This update can be done with a separate draft that updates the registry, but I admit that people tend to just read the RFCs, not the registry and therefore this is likely to be missed.

How do others feel about making a change in the -bis that is "things that have happened since 4627" that don't change the JSON grammar?

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


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







--=-nMYPx2Qj8+ElBx9grQtY-- From sayrer@gmail.com Mon Sep 23 20:57:31 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AE021F9E5B for ; Mon, 23 Sep 2013 20:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKdkN2Pl64PA for ; Mon, 23 Sep 2013 20:57:30 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 08D7421F9E6C for ; Mon, 23 Sep 2013 20:57:25 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id p19so2693310qcv.25 for ; Mon, 23 Sep 2013 20:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=id21Zh3WtNNx/LAuBh8h/VjkHDeE8ge3PizR6brijkY=; b=U9KYmvGX995hKxXS+C5amBSY5ZrhpDHRnfpHxTFJ9vyD0Y5bVfLw0FXYj2FB41l/0D 1rSf/SuNCrhFjh3+0HFTTDiZvglTK3JlUExnmi5faL/OnBemeqbof/aWnLZygmE0egUv ye5PcnG0eFSq3A+tOl2xEmAvkP+Zb8EOlJ/4RkpnQYLCa3MKnGfWZx3YmRscpNOV67Zx D9MNp47jMhP4yrkfb+yv8GgZhEeDd6tsip4TmrntNGuKg8MNcX6L6kZSgWFu4YA3mRMH xg6JJwEnQAZnlRWf8usaotp9R+ZUu5Z5dpavo47ZoLXpTwCSIlQH+PQDz/42LcCay5yJ mQBA== MIME-Version: 1.0 X-Received: by 10.224.114.81 with SMTP id d17mr26476658qaq.18.1379995044737; Mon, 23 Sep 2013 20:57:24 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 20:57:24 -0700 (PDT) In-Reply-To: <1379994578.19960.6.camel@dilithium> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <1379994578.19960.6.camel@dilithium> Date: Mon, 23 Sep 2013 20:57:24 -0700 Message-ID: From: R S To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=047d7bea3a346efb4f04e719223d Cc: "Manger, James H" , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 03:57:31 -0000 --047d7bea3a346efb4f04e719223d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 23, 2013 at 8:49 PM, Paul C. Bryan wrote: > ** > Kris Zyp was one of the two leads in the JSON Schema working group, and > whose contributions are attributable. He is co-author of RFC 6901. > Sure, sure. What about the other point? - Rob > > > On Mon, 2013-09-23 at 20:49 -0700, R S wrote: > > On Mon, Sep 23, 2013 at 8:42 PM, Paul C. Bryan wrote: > > It was designed by the JSON Schema working group. > > > > > > Oh, I see. That credit doesn't appear in RFC 6901. > > > > Still seems buggy as a general-purpose fragment identifier, since it > can't distinguish between arrays and objects. > > > > - Rob > > > > > > > > On Mon, 2013-09-23 at 20:41 -0700, R S wrote: > > Who designed it? > > Anyway, it is buggy as a general purpose fragment identifier. > > - Rob > > On Sep 23, 2013 8:34 PM, "Paul C. Bryan" wrote: > > JSON Pointer was designed for multiple purposes, including as a fragment > identifier in URIs. > > On Mon, 2013-09-23 at 09:11 -0700, R S wrote: > > This is a bad idea. JSON pointer was designed for a narrow patch use case, > and can't disambiguate objects and arrays. > > The JSON RFC shouldn't list every RFC that uses JSON. > > - Rob > > > > On Sep 20, 2013, at 10:00 PM, "Manger, James H" < > james.h.manger@team.telstra.com> wrote: > > > RFC 4627 doesn't define how URI fragments work for application/json > content. > > > > It would be helpful for 4627bis to say that a fragment (that begins with > a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointer identifies > a specific value in a JSON text. > > Changing the IANA MIME registry entry can be done, but I propose that we > don't do it as part of the -bis because it is not really a clarification. > This update can be done with a separate draft that updates the registry, > but I admit that people tend to just read the RFCs, not the registry and > therefore this is likely to be missed. > > How do others feel about making a change in the -bis that is "things that > have happened since 4627" that don't change the JSON grammar? > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > _______________________________________________ > json mailing listjson@ietf.orghttps://www.ietf.org/mailman/listinfo/json > > > > > > > > > --047d7bea3a346efb4f04e719223d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 23, 2013 at 8:49 PM, Paul C. Bryan <pbryan@an= ode.ca> wrote:
=20 =20
Kris Zyp was one of the two leads in the JSON Schema working group, and who= se contributions are attributable. He is co-author of RFC 6901.

Sure, sure.

What about = the other point?

- Rob


=A0
=


On Mon, 2013-09-23 at 20:49 -0700, R S wrote:
On Mon, Sep 23, 2013 at 8:42 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
It was designed by the JSON Schema working group.




Oh, I see. That credit doesn't appear in RFC 6901.


Still seems buggy as a general-purpose fragment identifier, since it ca= n't distinguish between arrays and objects.


- Rob


=A0


On Mon, 2013-09-23 at 20:41 -0700, R S wrote:
Who designed it?

Anyway, it is buggy as a general purpose fragment identifier.
- Rob

On Sep 23, 2013 8:34 PM, "Paul C. Bryan" <pbryan@anode.ca> wrote= :
JSON Pointer was designed for multiple purposes, including = as a fragment identifier in URIs.

On Mon, 2013-09-23 at 09:11 -0700, R S wrote:
This is a bad idea. JSON pointer was designed for a nar= row patch use case, and can't disambiguate objects and arrays.

The JSON RFC shouldn't list every RFC that uses JSO= N.

- Rob

<no hat>

On Sep 20, 2013, at 10:00 PM, "Manger, James H&quo= t; <james.h.manger@team.telstra.com> wrote:

> RFC 4627 doesn't define how URI fragments work= for application/json content.
>
> It would be helpful for 4627bis to say that a frag= ment (that begins with a "/" or is empty) is a JSON Pointer [RFC = 6901]. A JSON Pointer identifies a specific value in a JSON text.

Changing the IANA MIME registry entry can be done, but = I propose that we don't do it as part of the -bis because it is not rea= lly a clarification. This update can be done with a separate draft that upd= ates the registry, but I admit that people tend to just read the RFCs, not = the registry and therefore this is likely to be missed.

How do others feel about making a change in the -bis th= at is "things that have happened since 4627" that don't chang= e the JSON grammar?

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


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








--047d7bea3a346efb4f04e719223d-- From James.H.Manger@team.telstra.com Mon Sep 23 21:04:55 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FF421F9425 for ; Mon, 23 Sep 2013 21:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghRoQPgs0I3o for ; Mon, 23 Sep 2013 21:04:39 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9514721F93F8 for ; Mon, 23 Sep 2013 21:04:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,968,1371045600"; d="scan'208";a="157557380" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 24 Sep 2013 14:04:38 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7207"; a="161481458" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcbvi.tcif.telstra.com.au with ESMTP; 24 Sep 2013 14:04:38 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Tue, 24 Sep 2013 14:04:37 +1000 From: "Manger, James H" To: R S , "Paul C. Bryan" Date: Tue, 24 Sep 2013 14:04:36 +1000 Thread-Topic: [Json] json-pointer as URI fragment syntax for application/json Thread-Index: Ac642RFY9VNeL5VhSBWTDy1DjA+PPQAABcdw Message-ID: <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 04:04:55 -0000 PiBTdGlsbCBzZWVtcyBidWdneSBhcyBhIGdlbmVyYWwtcHVycG9zZSBmcmFnbWVudCBpZGVudGlm aWVyLCBzaW5jZSBpdA0KPiBjYW4ndCBkaXN0aW5ndWlzaCBiZXR3ZWVuIGFycmF5cyBhbmQgb2Jq ZWN0cy4NCg0KV2h5IGRvZXMgdGhpcyBtYWtlIGl0IGJ1Z2d5IGFzIGEgZnJhZ21lbnQgaWQ/DQoN CkEgSlNPTiBwb2ludGVyIG1pZ2h0IG5vdCBiZSBzdWl0YWJsZSBmb3IgZ2VuZXJhdGluZyBuZXcg SlNPTiBzbyB0aGF0IGEgZ2l2ZW4gcG9pbnRlciBkb2Vzbid0IHJlZmVyIHRvIG5vdGhpbmcuIEZv ciBleGFtcGxlLCBnaXZlbiB7ImEiOjF9IGFuZCBhIHBvaW50ZXIgL2IvMiwgeW91IGNvdWxkIGFk ZCAiYiI6eyIyIjp0cnVlfSBvciAiYiI6WzAsMSwyXSBzbyAvYi8yIHBvaW50cyB0byBzb21ldGhp bmcuDQoNCkhvd2V2ZXIsIGEgSlNPTiBwb2ludGVyIGlzIHBlcmZlY3RseSB1bmFtYmlndW91cyBm b3Igc2VsZWN0aW5nIGFuIGV4aXN0aW5nIHZhbHVlIGZyb20gYSBKU09OIHRleHQgLS0gd2hpY2gg aXMgdGhlIHByaW1hcnkgdXNlIGNhc2UgZm9yIGEgZnJhZ21lbnQgaWQuDQoNCkEgZnJhZ21lbnQg aWQgZm9yIGFuIFhNTCBkb2MgdGhhdCBwaWNrIHRoZSBlbGVtZW50IHdpdGggYSBtYXRjaGluZyBp ZCBhdHRyaWJ1dGUgc2VlbXMgc2Vuc2libGUuIEkgZG9uJ3QgdGhpbmsgaXQgaXMgYnVnZ3kganVz dCBiZWNhdXNlIHRoZSBmcmFnbWVudCBpZCBhbG9uZSBkb2Vzbid0IGluZGljYXRlIHdoZXRoZXIg dGhlIGVsZW1lbnQgaXMgYSA8cD4gb3IgPGRpdj4sIG9yIGlzIGluc2lkZSBhIDxzZWN0aW9uPi4N Cg0KLS0NCkphbWVzIE1hbmdlcg0K From sayrer@gmail.com Mon Sep 23 21:07:22 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9286321F9D35 for ; Mon, 23 Sep 2013 21:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNqlNXIu3nVW for ; Mon, 23 Sep 2013 21:07:22 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 05F3021F9D33 for ; Mon, 23 Sep 2013 21:07:21 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id gh4so2847737qeb.30 for ; Mon, 23 Sep 2013 21:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XbXnEJf/EybpFXwE864FuKI7JETu0wW26XJbtvX7ow8=; b=WExsRZuRhqkML6moFECRMX3BFZEdIYEgUe55bnKbP7MSqyhqpeYqpOyOH/Ho49g2og KS0uIi5+eDnf6xGf3CaholjhYx2emCwjlwOFwmrRKH4gLxUNG4Mz1/28QYgiKSxIzksf uMyo3kx1McX0ne3HmsZY/EwE3RSswLdy8DM4ZCNP3mun+Oj0Bpizvll5NItYGCunKXp4 S+ekmsmix5jmZ/AoC/WVZucX1UuNrEkj06oClu80aaKgab1IY/8Ce2x07SohYz/8bxti EG00h0SxkIyMVsK1OApYOsxz+r0KkCOW2VvkF38AKQ0w+1xoXO2+kfVgGiWP1lKbXaR4 2uWg== MIME-Version: 1.0 X-Received: by 10.224.76.10 with SMTP id a10mr27439950qak.9.1379995641504; Mon, 23 Sep 2013 21:07:21 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 21:07:21 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 23 Sep 2013 21:07:21 -0700 Message-ID: From: R S To: "Manger, James H" Content-Type: multipart/alternative; boundary=001a11c305a400ecdc04e71946bd Cc: Paul Hoffman , "Paul C. Bryan" , "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 04:07:22 -0000 --001a11c305a400ecdc04e71946bd Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 23, 2013 at 9:04 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > > Still seems buggy as a general-purpose fragment identifier, since it > > can't distinguish between arrays and objects. > > Why does this make it buggy as a fragment id? > It is straightforwardly unsound. > A fragment id for an XML doc that pick the element with a matching id > attribute seems sensible. I don't think it is buggy just because the > fragment id alone doesn't indicate whether the element is a

or

, > or is inside a
. > A better comparison would be an XPath syntax that couldn't distinguish between an attribute and an element. - Rob --001a11c305a400ecdc04e71946bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Sep 23, 2013 at 9:04 PM, Manger, James H = <Ja= mes.H.Manger@team.telstra.com> wrote:
> Still seems buggy as = a general-purpose fragment identifier, since it
> can't distinguish between arrays and objects.

Why does this make it buggy as a fragment id?
It is straightforwardly unsound.
=A0
A fragment id for an XML doc that pick the element with a matching id attri= bute seems sensible. I don't think it is buggy just because the fragmen= t id alone doesn't indicate whether the element is a <p> or <d= iv>, or is inside a <section>.

A better comparison= would be an XPath syntax that couldn't distinguish between an attribut= e and an element.

- Rob
--001a11c305a400ecdc04e71946bd-- From pbryan@anode.ca Mon Sep 23 21:10:16 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E659E21F9EDA for ; Mon, 23 Sep 2013 21:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-sKrd8jAEvc for ; Mon, 23 Sep 2013 21:10:12 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 151CC21F9EBE for ; Mon, 23 Sep 2013 21:10:12 -0700 (PDT) Received: from [192.168.1.4] (S0106a021b762dbb3.vf.shawcable.net [174.1.50.247]) by maple.anode.ca (Postfix) with ESMTPSA id ABF3266BC; Tue, 24 Sep 2013 04:10:10 +0000 (UTC) Message-ID: <1379995708.22312.10.camel@dilithium> From: "Paul C. Bryan" To: R S Date: Mon, 23 Sep 2013 21:08:28 -0700 In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <1379994578.19960.6.camel@dilithium> Content-Type: multipart/alternative; boundary="=-GWJBJd5ttuZ5Iowd6qoJ" X-Mailer: Evolution 3.4.4-4+b1 Mime-Version: 1.0 Cc: "Manger, James H" , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 04:10:17 -0000 --=-GWJBJd5ttuZ5Iowd6qoJ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit The Application Area Working group raised and addressed the question of ambiguity during review of the Internet-Drafts. It concluded, by consensus, that it was not a substantive issue, despite your protestations. On Mon, 2013-09-23 at 20:57 -0700, R S wrote: > On Mon, Sep 23, 2013 at 8:49 PM, Paul C. Bryan > wrote: > > Kris Zyp was one of the two leads in the JSON Schema working > group, and whose contributions are attributable. He is > co-author of RFC 6901. > > > Sure, sure. > > > What about the other point? > > > - Rob > > > > > > > > On Mon, 2013-09-23 at 20:49 -0700, R S wrote: > > > On Mon, Sep 23, 2013 at 8:42 PM, Paul C. Bryan > > wrote: > > > > It was designed by the JSON Schema working group. > > > > > > > > > > > > Oh, I see. That credit doesn't appear in RFC 6901. > > > > > > Still seems buggy as a general-purpose fragment identifier, > > since it can't distinguish between arrays and objects. > > > > > > - Rob > > > > > > > > > > > > > > On Mon, 2013-09-23 at 20:41 -0700, R S wrote: > > > > > Who designed it? > > > > > > Anyway, it is buggy as a general purpose fragment > > > identifier. > > > > > > - Rob > > > > > > On Sep 23, 2013 8:34 PM, "Paul C. Bryan" > > > wrote: > > > > > > JSON Pointer was designed for multiple > > > purposes, including as a fragment > > > identifier in URIs. > > > > > > On Mon, 2013-09-23 at 09:11 -0700, R S > > > wrote: > > > > > > > This is a bad idea. JSON pointer was > > > > designed for a narrow patch use case, > > > > and can't disambiguate objects and > > > > arrays. > > > > > > > > The JSON RFC shouldn't list every RFC > > > > that uses JSON. > > > > > > > > - Rob > > > > > > > > > > > > > > > > On Sep 20, 2013, at 10:00 PM, "Manger, > > > > James H" > > > > wrote: > > > > > > > > > RFC 4627 doesn't define how URI > > > > fragments work for application/json > > > > content. > > > > > > > > > > It would be helpful for 4627bis to say > > > > that a fragment (that begins with a "/" > > > > or is empty) is a JSON Pointer [RFC > > > > 6901]. A JSON Pointer identifies a > > > > specific value in a JSON text. > > > > > > > > Changing the IANA MIME registry entry > > > > can be done, but I propose that we don't > > > > do it as part of the -bis because it is > > > > not really a clarification. This update > > > > can be done with a separate draft that > > > > updates the registry, but I admit that > > > > people tend to just read the RFCs, not > > > > the registry and therefore this is > > > > likely to be missed. > > > > > > > > How do others feel about making a change > > > > in the -bis that is "things that have > > > > happened since 4627" that don't change > > > > the JSON grammar? > > > > > > > > --Paul Hoffman > > > > _______________________________________________ > > > > json mailing list > > > > json@ietf.org > > > > https://www.ietf.org/mailman/listinfo/json > > > > > > > > > > > > > > > > _______________________________________________ > > > > json mailing list > > > > json@ietf.org > > > > https://www.ietf.org/mailman/listinfo/json > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --=-GWJBJd5ttuZ5Iowd6qoJ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit The Application Area Working group raised and addressed the question of ambiguity during review of the Internet-Drafts. It concluded, by consensus, that it was not a substantive issue, despite your protestations.

On Mon, 2013-09-23 at 20:57 -0700, R S wrote:
On Mon, Sep 23, 2013 at 8:49 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
Kris Zyp was one of the two leads in the JSON Schema working group, and whose contributions are attributable. He is co-author of RFC 6901.


Sure, sure.


What about the other point?


- Rob




 


On Mon, 2013-09-23 at 20:49 -0700, R S wrote:
On Mon, Sep 23, 2013 at 8:42 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
It was designed by the JSON Schema working group.




Oh, I see. That credit doesn't appear in RFC 6901.


Still seems buggy as a general-purpose fragment identifier, since it can't distinguish between arrays and objects.


- Rob


 


On Mon, 2013-09-23 at 20:41 -0700, R S wrote:
Who designed it?

Anyway, it is buggy as a general purpose fragment identifier.

- Rob

On Sep 23, 2013 8:34 PM, "Paul C. Bryan" <pbryan@anode.ca> wrote:
JSON Pointer was designed for multiple purposes, including as a fragment identifier in URIs.

On Mon, 2013-09-23 at 09:11 -0700, R S wrote:
This is a bad idea. JSON pointer was designed for a narrow patch use case, and can't disambiguate objects and arrays.

The JSON RFC shouldn't list every RFC that uses JSON.

- Rob

<no hat>

On Sep 20, 2013, at 10:00 PM, "Manger, James H" <james.h.manger@team.telstra.com> wrote:

> RFC 4627 doesn't define how URI fragments work for application/json content.
>
> It would be helpful for 4627bis to say that a fragment (that begins with a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointer identifies a specific value in a JSON text.

Changing the IANA MIME registry entry can be done, but I propose that we don't do it as part of the -bis because it is not really a clarification. This update can be done with a separate draft that updates the registry, but I admit that people tend to just read the RFCs, not the registry and therefore this is likely to be missed.

How do others feel about making a change in the -bis that is "things that have happened since 4627" that don't change the JSON grammar?

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


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











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

--=-GWJBJd5ttuZ5Iowd6qoJ-- From sayrer@gmail.com Mon Sep 23 21:16:24 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE4621F9D3A for ; Mon, 23 Sep 2013 21:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CHsOMFZl0uX for ; Mon, 23 Sep 2013 21:16:23 -0700 (PDT) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 40C5921F9D0D for ; Mon, 23 Sep 2013 21:16:22 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id a11so2834244qen.9 for ; Mon, 23 Sep 2013 21:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6l+Jq3vDMQH6S+mlSI4hePi61jIetB6PpPxYCVyoRLI=; b=T3VxnJmeIKOmsJw3taeb3E9tNQautwCotkX08KrwR42eMQC3qW+RsyB+gJAm+31ZIk 0DHze5XsNADxgEwmIrDMPqfO9gNtqzvN4UKqP1ZZDbZuQjHhPu/LMzEgS2fsmSh9273w Jm+tjl4s9GjGDrKr8BbQE8bfmZjdigIArhxuF+ysgnzzFYC/vz44MWhOvdQJei02ilfo DtVu3aF5UtOQ/hZOQeKrcwo6iMON7mk8qNKzr1Ot0SD37+rbMOQ//vKe3TEruzyx8HdG F8TRvmL25l64FTaqt1HvQPguEL9ouCQ+GpSRwx2Sk0lHEED6AsF6Kf/3Hoi/UrrMI7yO qaMA== MIME-Version: 1.0 X-Received: by 10.224.112.130 with SMTP id w2mr26697838qap.50.1379996181723; Mon, 23 Sep 2013 21:16:21 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 21:16:21 -0700 (PDT) In-Reply-To: <1379995708.22312.10.camel@dilithium> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <1379994578.19960.6.camel@dilithium> <1379995708.22312.10.camel@dilithium> Date: Mon, 23 Sep 2013 21:16:21 -0700 Message-ID: From: R S To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=001a11c2c7d834022004e719666c Cc: "Manger, James H" , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 04:16:24 -0000 --001a11c2c7d834022004e719666c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 23, 2013 at 9:08 PM, Paul C. Bryan wrote: > ** > The Application Area Working group raised and addressed the question of > ambiguity during review of the Internet-Drafts. It concluded, by consensus, > that it was not a substantive issue, despite your protestations. > I agree that the WG agreed to use it. It did not get IETF consensus as a general-purpose JSON fragment identifier, and the RFC contains text saying exactly that: "the fragment identifier syntax for application/json is not JSON Pointer." Feel free to argue the actual technical point, btw. - Rob > On Mon, 2013-09-23 at 20:57 -0700, R S wrote: > > On Mon, Sep 23, 2013 at 8:49 PM, Paul C. Bryan wrote: > > Kris Zyp was one of the two leads in the JSON Schema working group, and > whose contributions are attributable. He is co-author of RFC 6901. > > > > Sure, sure. > > > > What about the other point? > > > > - Rob > > > > > > > > > > On Mon, 2013-09-23 at 20:49 -0700, R S wrote: > > On Mon, Sep 23, 2013 at 8:42 PM, Paul C. Bryan wrote: > > It was designed by the JSON Schema working group. > > > > > > Oh, I see. That credit doesn't appear in RFC 6901. > > > Still seems buggy as a general-purpose fragment identifier, since it can't > distinguish between arrays and objects. > > > - Rob > > > > > > > On Mon, 2013-09-23 at 20:41 -0700, R S wrote: > > Who designed it? > > Anyway, it is buggy as a general purpose fragment identifier. > > - Rob > > On Sep 23, 2013 8:34 PM, "Paul C. Bryan" wrote: > > JSON Pointer was designed for multiple purposes, including as a fragment > identifier in URIs. > > On Mon, 2013-09-23 at 09:11 -0700, R S wrote: > > This is a bad idea. JSON pointer was designed for a narrow patch use case, > and can't disambiguate objects and arrays. > > The JSON RFC shouldn't list every RFC that uses JSON. > > - Rob > > > > On Sep 20, 2013, at 10:00 PM, "Manger, James H" < > james.h.manger@team.telstra.com> wrote: > > > RFC 4627 doesn't define how URI fragments work for application/json > content. > > > > It would be helpful for 4627bis to say that a fragment (that begins with > a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointer identifies > a specific value in a JSON text. > > Changing the IANA MIME registry entry can be done, but I propose that we > don't do it as part of the -bis because it is not really a clarification. > This update can be done with a separate draft that updates the registry, > but I admit that people tend to just read the RFCs, not the registry and > therefore this is likely to be missed. > > How do others feel about making a change in the -bis that is "things that > have happened since 4627" that don't change the JSON grammar? > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > _______________________________________________ > json mailing listjson@ietf.orghttps://www.ietf.org/mailman/listinfo/json > > > > > > > > > > > > _______________________________________________ > json mailing listjson@ietf.orghttps://www.ietf.org/mailman/listinfo/json > > > --001a11c2c7d834022004e719666c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 23, 2013 at 9:08 PM, Paul C. Bryan <pbryan@an= ode.ca> wrote:
=20 =20
The Application Area Working group raised and addressed the question of amb= iguity during review of the Internet-Drafts. It concluded, by consensus, th= at it was not a substantive issue, despite your protestations.

I agree that the WG agreed to use it.=A0

=
It did not get IETF consensus as a general-purpose JSON fragment= identifier, and the RFC contains text saying exactly that: "the fragment identifier syntax for ap= plication/json is not JSON Pointer."=A0

Feel free to argue the actual technical point, btw.

- Rob



=A0
On Mon, 2013-09-23 at 20:57 -0700, R S wrote:
On Mon, Sep 23, 2013 at 8:49 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
Kris Zyp was one of the two leads in the JSON Schema working group,= and whose contributions are attributable. He is co-author of RFC 6901.


Sure, sure.


What about the other point?


- Rob




=A0


On Mon, 2013-09-23 at 20:49 -0700, R S wrote:
On Mon, Sep 23, 2013 at 8:42 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
It was designed by the JSON Schema working group.




Oh, I see. That credit doesn't appear in RFC 6901.


Still seems buggy as a general-purpose fragment identifier, sin= ce it can't distinguish between arrays and objects.


- Rob


=A0


On Mon, 2013-09-23 at 20:41 -0700, R S wrote:
Who designed it?

Anyway, it is buggy as a general purpose fragment ident= ifier.

- Rob

On Sep 23, 2013 8:34 PM, "Paul C. Bryan" <= pbryan@anode.ca>= ; wrote:
JSON Pointer was designed for multiple purposes, in= cluding as a fragment identifier in URIs.

On Mon, 2013-09-23 at 09:11 -0700, R S wrote:
This is a bad idea. JSON pointer was designed f= or a narrow patch use case, and can't disambiguate objects and arrays.<= br>
The JSON RFC shouldn't list every RFC that = uses JSON.

- Rob

<no hat>

On Sep 20, 2013, at 10:00 PM, "Manger, Jam= es H" <james.h.manger@team.telstra.com> wrote:

> RFC 4627 doesn't define how URI fragme= nts work for application/json content.
>
> It would be helpful for 4627bis to say tha= t a fragment (that begins with a "/" or is empty) is a JSON Point= er [RFC 6901]. A JSON Pointer identifies a specific value in a JSON text.
Changing the IANA MIME registry entry can be do= ne, but I propose that we don't do it as part of the -bis because it is= not really a clarification. This update can be done with a separate draft = that updates the registry, but I admit that people tend to just read the RF= Cs, not the registry and therefore this is likely to be missed.

How do others feel about making a change in the= -bis that is "things that have happened since 4627" that don'= ;t change the JSON grammar?

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

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











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


--001a11c2c7d834022004e719666c-- From cowan@ccil.org Mon Sep 23 21:23:18 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEA321F9EDA for ; Mon, 23 Sep 2013 21:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.066 X-Spam-Level: X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gd1cv1YAq3M2 for ; Mon, 23 Sep 2013 21:23:14 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id A209E11E810B for ; Mon, 23 Sep 2013 21:22:47 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VOK92-0007Bh-GQ; Tue, 24 Sep 2013 00:22:40 -0400 Date: Tue, 24 Sep 2013 00:22:40 -0400 From: John Cowan To: R S Message-ID: <20130924042240.GA18283@mercury.ccil.org> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "Manger, James H" , Paul Hoffman , "Paul C. Bryan" , "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 04:23:18 -0000 R S scripsit: > > Why does this make [JSON Pointer] buggy as a fragment id? > > It is straightforwardly unsound. Inspecting a Posix path doesn't tell you if its referent is a device, a directory, or a file. Is this also "straightforwardly unsound"? It's generally considered a virtue. > > A fragment id for an XML doc that pick the element with a matching id > > attribute seems sensible. I don't think it is buggy just because the > > fragment id alone doesn't indicate whether the element is a

or

, > > or is inside a
. > > A better comparison would be an XPath syntax that couldn't distinguish > between an attribute and an element. They aren't comparable. XML labels nodes, whereas JSON (like Posix paths) labels edges. A JSON Pointer tells you which edges to traverse to get to the anonymous value at the end, whereas an XPath tells you which nodes to traverse to get to a specific named and typed node. -- But the next day there came no dawn, John Cowan and the Grey Company passed on into the cowan@ccil.org darkness of the Storm of Mordor and were http://www.ccil.org/~cowan lost to mortal sight; but the Dead followed them. --"The Passing of the Grey Company" From cabo@tzi.org Mon Sep 23 21:24:39 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C9C21F9EDA for ; Mon, 23 Sep 2013 21:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.141 X-Spam-Level: X-Spam-Status: No, score=-106.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5fEeg0TvgxE for ; Mon, 23 Sep 2013 21:24:33 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABE521F9E88 for ; Mon, 23 Sep 2013 21:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8O4OPhJ019151; Tue, 24 Sep 2013 06:24:25 +0200 (CEST) Received: from [192.168.217.105] (p548903C6.dip0.t-ipconnect.de [84.137.3.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AC25AB65; Tue, 24 Sep 2013 06:24:24 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 24 Sep 2013 06:24:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> To: R S X-Mailer: Apple Mail (2.1510) Cc: json@ietf.org Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 04:24:39 -0000 > On Mon, Sep 23, 2013 at 9:04 PM, Manger, James H = wrote: > > Still seems buggy as a general-purpose fragment identifier, since it > > can't distinguish between arrays and objects. >=20 > Why does this make it buggy as a fragment id? >=20 > It is straightforwardly unsound. You keep saying that, and we keep explaining that there is no need = (really: no point) for type checking in a fragment identifier. > A fragment id for an XML doc that pick the element with a matching id = attribute seems sensible. I don't think it is buggy just because the = fragment id alone doesn't indicate whether the element is a

or =

, or is inside a
. >=20 > A better comparison would be an XPath syntax that couldn't distinguish = between an attribute and an element. That would indeed be buggy (actually: ambiguous in certain cases), as = XML allows to have one element to have an attribute and a subelement of = the same name. A JSON data item can only be an array *or* a map ("object"). There is = no need (no point) for a path element in a fragment identifier to = indicate which of the two is desired. In particular, there is no = ambiguity (a term that you keep throwing around). I understand that one may have an aesthetic preference for = distinguishing array indexing from map indexing, But, at the = engineering level, that is about as useful as distinguishing indexing in = even length arrays from indexing odd length arrays. Gr=FC=DFe, Carsten From cowan@ccil.org Mon Sep 23 21:25:16 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFDE21F9E88 for ; Mon, 23 Sep 2013 21:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wopB5lbP5KGx for ; Mon, 23 Sep 2013 21:25:11 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB8A21F9FF6 for ; Mon, 23 Sep 2013 21:25:11 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VOKBJ-0007Rb-97; Tue, 24 Sep 2013 00:25:01 -0400 Date: Tue, 24 Sep 2013 00:25:01 -0400 From: John Cowan To: Tim Bray Message-ID: <20130924042501.GB18283@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 04:25:16 -0000 Tim Bray scripsit: > in the range [(-2**53)+1, (2**53)-1], Since [] means something different in JSON than it does here, I suggest "in the range (-2**53)+1 to (2&&53)-1 inclusive" instead. Otherwise +1. -- John Cowan http://ccil.org/~cowan cowan@ccil.org We want more school houses and less jails; more books and less arsenals; more learning and less vice; more constant work and less crime; more leisure and less greed; more justice and less revenge; in fact, more of the opportunities to cultivate our better natures. --Samuel Gompers From duerst@it.aoyama.ac.jp Mon Sep 23 21:30:44 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2238021F92B5 for ; Mon, 23 Sep 2013 21:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.841 X-Spam-Level: X-Spam-Status: No, score=-103.841 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05M5-I96pLpH for ; Mon, 23 Sep 2013 21:30:38 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7633221F9193 for ; Mon, 23 Sep 2013 21:30:37 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8O4UW6f021924; Tue, 24 Sep 2013 13:30:32 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 644c_8f8a_0ca80ede_24d2_11e3_b9f5_001e6722eec2; Tue, 24 Sep 2013 13:30:31 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id EA5F6BF535; Tue, 24 Sep 2013 13:30:31 +0900 (JST) Message-ID: <52411551.7000305@it.aoyama.ac.jp> Date: Tue, 24 Sep 2013 13:30:09 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "json@ietf.org" , Paul Hoffman , "Paul C. Bryan" , R S Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 04:30:44 -0000 For the record, this specific issue was discussed in the appsawg. Regards, Martin. On 2013/09/24 13:04, Manger, James H wrote: >> Still seems buggy as a general-purpose fragment identifier, since it >> can't distinguish between arrays and objects. > > Why does this make it buggy as a fragment id? > > A JSON pointer might not be suitable for generating new JSON so that a given pointer doesn't refer to nothing. For example, given {"a":1} and a pointer /b/2, you could add "b":{"2":true} or "b":[0,1,2] so /b/2 points to something. > > However, a JSON pointer is perfectly unambiguous for selecting an existing value from a JSON text -- which is the primary use case for a fragment id. > > A fragment id for an XML doc that pick the element with a matching id attribute seems sensible. I don't think it is buggy just because the fragment id alone doesn't indicate whether the element is a

or

, or is inside a
. > > -- > James Manger > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From cowan@ccil.org Mon Sep 23 21:31:43 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FEF21F9302 for ; Mon, 23 Sep 2013 21:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CE7ZXGb-yJev for ; Mon, 23 Sep 2013 21:31:38 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id CE5E121F92B5 for ; Mon, 23 Sep 2013 21:31:38 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VOKHi-000821-2k; Tue, 24 Sep 2013 00:31:38 -0400 Date: Tue, 24 Sep 2013 00:31:38 -0400 From: John Cowan To: R S Message-ID: <20130924043138.GC18283@mercury.ccil.org> References: <1E04055A-D000-4BE0-BE18-D9F7447B2253@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 04:31:43 -0000 R S scripsit: > I think the issue has more to do with IEEE754, but I am not a floating > point lawyer. > > n.b. that the sign of zero may be disregarded by a language's equality > operator (it is in JavaScript) Just so. Indeed, a language which conforms either absolutely or conditionally to IEEE 754 MUST treat 0.0 and -0.0 as equal, even though they don't produce equal results when certain functions are applied to them. Tim Bray scripsit: > So, we observe that two different json libraries in one language have > incompatible behavior. I think this is evidence that the proposed language > is useful. -T Sorry, which two libraries? -- John Cowan http://www.ccil.org/~cowan Adam [...] did not want the apple for the apple's sake, he wanted it only because it was forbidden. The mistake was not forbidding the serpent; then he would have eaten the serpent. --Mark Twain From cabo@tzi.org Mon Sep 23 21:49:14 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3637C11E80D9 for ; Mon, 23 Sep 2013 21:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.147 X-Spam-Level: X-Spam-Status: No, score=-106.147 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbagcY0lclEl for ; Mon, 23 Sep 2013 21:49:08 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 10B2011E80A2 for ; Mon, 23 Sep 2013 21:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8O4n5S9006297; Tue, 24 Sep 2013 06:49:05 +0200 (CEST) Received: from [192.168.217.105] (p548903C6.dip0.t-ipconnect.de [84.137.3.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CB358B73; Tue, 24 Sep 2013 06:49:04 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 24 Sep 2013 06:49:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E04055A-D000-4BE0-BE18-D9F7447B2253@vpnc.org> To: R S X-Mailer: Apple Mail (2.1510) Cc: "json@ietf.org WG" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 04:49:14 -0000 On Sep 24, 2013, at 05:46, R S wrote: > Fully disagree with this rationale and the proposed text. The = rationale is wrong because it can be used to allow an exception for any = buggy implementation, and the text is wrong because "implementations = which read JSON texts" can be relied upon to preserve negative zeros. One's complement is a bit out of fashion, no? As Paul said: JSON is silent on the specific number representation to be = used by a receiving implementation. There is a general expectation that = conversion (commonly from JSON's decimal form to *some* binary form) is = happening on decoding, and the specifics of that conversion, including = the set of representable numbers and how the set of numbers = representable in JSON is mapped to that set, is implementation specific. = (RFC 4627 just fails to say that these may differ in precision, not = only range; this is an erratum, not a feature.) Integer-only implementations of JSON are acceptable. Integers outside of the range between -(2**53)+1 and +(2**53)-1 are = endangered in practice, as floating-point-only implementations with that = precision abound. An implementation that cannot distinguish 2**53 from 2**53+1 is exactly = as buggy as one that cannot distinguish +0.0 from -0.0: not buggy at = all. The much more interesting point was that there are implementations that = can distinguish +0.0 from -0.0, but don't distinguish +0 from -0. These = implementations then go on to differ in whether they distinguish +0e0 = from -0e0! All bets are off here. =20 Many JSON implementations distinguish 0 from 0.0. I'm still waiting for = a report from the first implementation that distinguishes 0.0 from 0.00; = there would be nothing wrong with that. Gr=FC=DFe, Carsten PS.: Plus signs (and other arithmetic) in the above for exposition only; = they are not allowed in JSON. From sayrer@gmail.com Mon Sep 23 21:53:01 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3D111E8103 for ; Mon, 23 Sep 2013 21:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgQl5CsQkPUw for ; Mon, 23 Sep 2013 21:53:01 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DA60E11E8102 for ; Mon, 23 Sep 2013 21:53:00 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id l13so2789791qcy.17 for ; Mon, 23 Sep 2013 21:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+4weE3ZnxEDCqOBjYgzAC/7wLE8SyMK/TWIvMuXHKhk=; b=zOVMN+HF8rR3n/zR/ndBmZrY3VMhCOyD5kxSw3orJ3dSqNLKN7ZA5mr0eUuDDmEfIz n6B6Fp8stepeBuT/APafFCb2hdd5CZH+drdudugbu7lN5wML6KVI868jLxbACGbuC5l5 ak1qZ7vrLJglt1x7fZ3PkcgEsma1XQ2UK8cQ1f9ikbFwCDL6SgPO9yMqsCA1WNLioILk 1KwmkQD56xu9MwU6IdOsWF06qH/hg49bSqr4bXTzynUrJahONPX2vrKuiIMF1vpfe+ab InEDdMTSeh/lVtO5Q9kZP8IW6ASL4OdKzX74hp0J1Z46y/TNPVDeEHSabo9CJ58pcwlI BHIQ== MIME-Version: 1.0 X-Received: by 10.224.112.130 with SMTP id w2mr26780896qap.50.1379998380157; Mon, 23 Sep 2013 21:53:00 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 21:53:00 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 23 Sep 2013 21:53:00 -0700 Message-ID: From: R S To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c2c7d83d715804e719e921 Cc: "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 04:53:01 -0000 --001a11c2c7d83d715804e719e921 Content-Type: text/plain; charset=ISO-8859-1 On Monday, September 23, 2013, Carsten Bormann wrote: > > I understand that one may have an aesthetic preference for distinguishing > array indexing from map indexing, But, at the engineering level, that is > about as useful as distinguishing indexing in even length arrays from > indexing odd length arrays. > At the engineering level, it may be useful to distinguish between ordered and unordered collections. Anyway, it isn't within this WG charter's scope to obsolete RFC 6901. Let me remind you, that RFC reads: "the fragment identifier syntax for application/json is not JSON Pointer." and, as Mark wrote: "we couldn't retroactively change the fragment identifier syntax for JSON without a much broader mandate." that is, the WG didn't have the mandate to specify a general purpose JSON fragment identifier. That makes sense, since every argument in that WG was along the lines of "well, we're just trying to make this work for our little use case." I can link you to those emails if you want. - Rob --001a11c2c7d83d715804e719e921 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Monday, September 23, 2013, Carsten Bormann wrote:
=

I understand that one may have an aesthetic preference for distinguishing a= rray indexing from map indexing, =A0But, at the engineering level, that is = about as useful as distinguishing indexing in even length arrays from index= ing odd length arrays.

At the engineering level, it may be useful= to distinguish between ordered and unordered collections.

Anyway, it isn't within this WG charter's scope to obsolet= e RFC 6901. Let me remind you, that RFC reads: "the fragment identifier syntax for app= lication/json is not JSON Pointer."=A0

and, as Mark wrote:

"we couldn't ret= roactively change the fragment identifier syntax for JSON without a much br= oader mandate."

tha= t is, the WG didn't have the mandate to specify a general purpose JSON = fragment identifier. That makes sense, since every argument in that WG was = along the lines of "well, we're just trying to make this work for = our little use case." I can link you to those emails if you want.

- R= ob

=A0
--001a11c2c7d83d715804e719e921-- From sayrer@gmail.com Mon Sep 23 21:56:02 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D925821F91BF for ; Mon, 23 Sep 2013 21:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yc6E1nxCq2nT for ; Mon, 23 Sep 2013 21:56:02 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5059D21F91B7 for ; Mon, 23 Sep 2013 21:56:02 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id k15so2152926qaq.16 for ; Mon, 23 Sep 2013 21:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mpdWzD79MHaecEwDRMHlunMgyuPeH9A8iyDLQ5kcOmo=; b=xcj5LQEbnIopgklMI+/vyJO/uFdrW3uDiR9yAd05JpZ86ra5dEtDGEGBXW2Gss/GBf pCusPJ9QFEM+U4kAdzB6x1PTXCVK7YoM2kMQ5b1Zlnr5nzM+T7ZGKzy7DWYqlU5pVvt9 s2Tbml0x5ppcyJtOJbURm/L8HOAFbOhE1taTa4qIrdbKozGbeKssVy50QFL1+kav+s+D NlfIEmDBwj3Jty7YdEDwv9LDru+6zCZvHG3Wlnh9I3w36UpiXcsmM6Wht/LRqz7SwAbK z6Cn7FbHKGuXY46gnfaZCWTCzzvoAnPl0mfa37xDi84xSot0qdQzNSFosaDf+pcBoyZ9 wa7g== MIME-Version: 1.0 X-Received: by 10.224.112.130 with SMTP id w2mr26788006qap.50.1379998561800; Mon, 23 Sep 2013 21:56:01 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 21:56:01 -0700 (PDT) In-Reply-To: References: <1E04055A-D000-4BE0-BE18-D9F7447B2253@vpnc.org> Date: Mon, 23 Sep 2013 21:56:01 -0700 Message-ID: From: R S To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c2c7d81119a504e719f4e0 Cc: "json@ietf.org WG" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 04:56:03 -0000 --001a11c2c7d81119a504e719f4e0 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 23, 2013 at 9:49 PM, Carsten Bormann wrote: > > > Integer-only implementations of JSON are acceptable. > Tim's proposal reads "Since software which correctly implements IEEE 754-2008 [IEEE754] is generally available and widely used". Should it instead read "Since software which [in]correctly implements IEEE 754-2008 [IEEE754] is generally available and widely used" ? - Rob --001a11c2c7d81119a504e719f4e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 23, 2013 at 9:49 PM, Carsten Bormann <cabo@tzi.org= > wrote:


Integer-only implementations of JSON are acceptable.
<= br>
Tim's proposal reads "Since software which correctly implements IEE= E 754-2008 [IEEE754] is generally available and widely used".

Should it instead read "Since software which [in]correctly implem= ents IEEE 754-2008 [IEEE754] is generally available and widely used"=A0?

- Rob
--001a11c2c7d81119a504e719f4e0-- From cabo@tzi.org Mon Sep 23 22:05:06 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092D511E8107 for ; Mon, 23 Sep 2013 22:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.152 X-Spam-Level: X-Spam-Status: No, score=-106.152 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiIwOk4BPKcV for ; Mon, 23 Sep 2013 22:05:00 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1800A11E80D9 for ; Mon, 23 Sep 2013 22:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8O54u6K007752; Tue, 24 Sep 2013 07:04:56 +0200 (CEST) Received: from [192.168.217.105] (p548903C6.dip0.t-ipconnect.de [84.137.3.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D6688B79; Tue, 24 Sep 2013 07:04:55 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 24 Sep 2013 07:04:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <31ADADB9-4EBE-49E9-BAC6-55CBEBC6C905@tzi.org> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> To: R S X-Mailer: Apple Mail (2.1510) Cc: "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 05:05:06 -0000 On Sep 24, 2013, at 06:53, R S wrote: > the WG didn't have the mandate to specify a general purpose JSON = fragment identifier. Which is exactly why I asked "are we sure we want to do this now?". (I don't have an opinion whether the JSON WG is currently chartered to = define the fragment identifier for application/json. Ignoring the = specifics of our current charter, it would clearly be in the remit of a = JSON WG.) All I wanted to point out is that the decision not to do type checking = is not a suitable technical argument against adopting RFC 6901 as *the* = JSON fragment identifier syntax. > [...] I can link you to those emails if you want. If there are more consequential technical shortcomings of RFC 6901 as a = fragment identifier syntax for JSON, it might indeed be useful for this = WG to know. Gr=FC=DFe, Carsten From James.H.Manger@team.telstra.com Mon Sep 23 22:27:08 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8398A21F9E53 for ; Mon, 23 Sep 2013 22:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.507 X-Spam-Level: X-Spam-Status: No, score=-1.507 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1NSBPgS8vAx for ; Mon, 23 Sep 2013 22:26:48 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5342921F9D33 for ; Mon, 23 Sep 2013 22:26:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,968,1371045600"; d="scan'208";a="161470060" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 24 Sep 2013 15:26:44 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7207"; a="160475224" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcdvi.tcif.telstra.com.au with ESMTP; 24 Sep 2013 15:26:44 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Tue, 24 Sep 2013 15:26:44 +1000 From: "Manger, James H" To: R S , Carsten Bormann Date: Tue, 24 Sep 2013 15:26:42 +1000 Thread-Topic: [Json] json-pointer as URI fragment syntax for application/json Thread-Index: Ac644fglKxRRnsBPRom6fYHrvYNmcQAAEDpQ Message-ID: <255B9BB34FB7D647A506DC292726F6E115312E3CFA@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 05:27:08 -0000 PiBBbnl3YXksIGl0IGlzbid0IHdpdGhpbiB0aGlzIFdHIGNoYXJ0ZXIncyBzY29wZSB0byBvYnNv bGV0ZSBSRkMgNjkwMS4NCj4gTGV0IG1lIHJlbWluZCB5b3UsIHRoYXQgUkZDIHJlYWRzOiAidGhl IGZyYWdtZW50IGlkZW50aWZpZXIgc3ludGF4IGZvcg0KPiBhcHBsaWNhdGlvbi9qc29uIGlzIG5v dCBKU09OIFBvaW50ZXIuIg0KPiANCj4gYW5kLCBhcyBNYXJrIHdyb3RlOg0KPiANCj4gIndlIGNv dWxkbid0IHJldHJvYWN0aXZlbHkgY2hhbmdlIHRoZSBmcmFnbWVudCBpZGVudGlmaWVyIHN5bnRh eCBmb3INCj4gSlNPTiB3aXRob3V0IGEgbXVjaCBicm9hZGVyIG1hbmRhdGUuIg0KDQpUaGUgd2hv bGUgaWRlYSBpcyB0aGF0IHRoaXMgSlNPTi1zcGVjaWZpYyBJRVRGIFdHIGhhcyB0aGUgYnJvYWRl ciBtYW5kYXRlLg0KVGhpcyBXRyBpcyB1cGRhdGluZyB0aGUgUkZDIHRoYXQgZGVmaW5lcyBhbmQg cmVnaXN0ZXJzIGFwcGxpY2F0aW9uL2pzb24sDQp3aGljaCBpcyBwcmVjaXNlbHkgd2hlcmUgdGhl IGZyYWdtZW50IHN5bnRheCBmb3IgdGhlIG1lZGlhIHR5cGUgbmVlZHMgdG8NCmJlIHNwZWNpZmll ZC4NCg0KPiB0aGF0IGlzLCB0aGUgV0cgZGlkbid0IGhhdmUgdGhlIG1hbmRhdGUgdG8gc3BlY2lm eSBhIGdlbmVyYWwgcHVycG9zZQ0KPiBKU09OIGZyYWdtZW50IGlkZW50aWZpZXIuDQoNCkkgZGlz YWdyZWUuIFRoZSBXRyBkaWQgc3BlY2lmeSBKU09OIHBvaW50ZXIgYXMgYSBnZW5lcmFsIHB1cnBv c2UgSlNPTg0KZnJhZ21lbnQgaWRlbnRpZmllci4gUHVibGlzaGluZyB0aGUgSlNPTiBwb2ludGVy IHN5bnRheCAod2hpY2ggY2FuIGJlDQp1c2VkIGluIGxvdHMgb2YgcGxhY2VzKSwgYW5kIG1vZGlm eWluZyB0aGUgYXBwbGljYXRpb24vanNvbiByZWdpc3RyYXRpb24NCmFyZSBkaXN0aW5jdCB0YXNr cy4gSXQgd2FzIGVhc2llciBmb3IgUkZDIDY5MDEgIkpTT04gUG9pbnRlciIgdG8gb25seQ0KZG8g dGhlIGZvcm1lciwgbGVhdmluZyB0aGUgbGF0dGVyIHRvIGEgbW9yZSBhcHByb3ByaWF0ZSBmb3J1 bSAtLSB3aGljaA0KaXMgdGhpcyBXRyBhdCB0aGlzIHRpbWUuDQoNCg0KTm9ib2R5IGNhbiB1c2Ug YW55IGZyYWdtZW50IHN5bnRheCB3aXRoIGFwcC4vanNvbiBpbnRlcm9wZXJhYmx5IGF0IHRoZQ0K bW9tZW50LCBhcyBub25lIGlzIGRlZmluZWQgZm9yIHRoaXMgbWVkaWEgdHlwZSAtLSBkZXNwaXRl IG1lZGlhIHR5cGVzDQphbmQgVVJJIGZyYWdtZW50cyBiZWluZyBhIGNvcmUgY29tcG9uZW50cyBv ZiBvdXIgd2ViIGFyY2hpdGVjdHVyZS4NCg0KQXMgYSBib251cyB3ZSBjYW4gc2F5IHRoZSBmcmFn bWVudCBzeW50YXggaXMgYSBKU09OIHBvaW50ZXIgaWYsIGFuZCBvbmx5IGlmLA0KdGhlIGZyYWdt ZW50IHN0YXJ0cyB3aXRoIGEgIi8iIChvciBpcyBlbXB0eSkuIFRoYXQgbGVhdmVzIHJvb20gZm9y IG90aGVyDQphcHAuL2pzb24gZnJhZ21lbnQgc2NoZW1lcyBpbiBmdXR1cmUgaWYgcmVxdWlyZWQu DQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From cabo@tzi.org Mon Sep 23 22:27:17 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA0121F9D33 for ; Mon, 23 Sep 2013 22:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.156 X-Spam-Level: X-Spam-Status: No, score=-106.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XH1OvxVv9w5y for ; Mon, 23 Sep 2013 22:27:11 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD8A21F9E5B for ; Mon, 23 Sep 2013 22:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8O5R8AU020074; Tue, 24 Sep 2013 07:27:08 +0200 (CEST) Received: from [192.168.217.105] (p548903C6.dip0.t-ipconnect.de [84.137.3.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 52514B7B; Tue, 24 Sep 2013 07:27:08 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Tue, 24 Sep 2013 07:27:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <29C29B1D-81DF-438D-AF3E-1631CECDC324@tzi.org> References: To: Tim Bray X-Mailer: Apple Mail (2.1510) Cc: "json@ietf.org" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 05:27:17 -0000 My summary from the discussion so far: On Sep 24, 2013, at 03:57, Tim Bray wrote: > How about we enhance the text following the ABNF in the =93Numbers=94 = section to say: >=20 > This specification allows implementations to set limits on the range = of numbers accepted. Since software which correctly Drop the "correctly" (doesn't add anything). > implements IEEE 754-2008 [IEEE754] is generally available and widely = used, good interoperability can be achieved by limiting numbers in JSON = texts to those within the precision and magnitude expressible in an IEEE = 754 binary64 (double precision) number. Note that when such software is = used, numbers which are integers, in the range [(-2**53)+1, (2**53)-1], = and are represented without "frac" parts, for example as 3 not 3.0, or exp parts... Maybe say "use only the int part and optionally the minus". > are interoperable in the sense that implementations will agree exactly = on the numeric values. >=20 > Attempting to represent numbers that cannot be exactly encoded as an = IEEE 754:2008 binary64 number, such as 1E400, 9007199254740993, or = 3.141592653589793238462643383279, may cause interoperability problems. As I mentioned before, 1.1 "cannot be exactly encoded as an IEEE = 754:2008 binary64 number", and there are fewer interop problems with = that than with the first two examples you give here. Also, it is not the attempt to represent 9007199254740993, but the = expectation that an implementation will be able to distinguish = 9007199254740993 from 9007199254740992, that causes interop problems = (same with 3.141592653589793238462643383279). > Numbers which represent zero without a sign, for example as 0 or 0.0 = not -0 or +0.0, +0.0 isn't JSON. > are interoperable in the sense that software implementations will = agree on the zero value. Signed zeros are significant in some = numerically-intensive applications, but implementations which read JSON = texts cannot be relied upon to preserve that distinction. (Maybe be more specific that this is about the distinction between 0.0 = and -0.0, not about the presence or absence of a sign, even though that = is actually the same in JSON.) Gr=FC=DFe, Carsten From sayrer@gmail.com Mon Sep 23 22:38:15 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADF011E8102 for ; Mon, 23 Sep 2013 22:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in1ZGZhASpd6 for ; Mon, 23 Sep 2013 22:38:14 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9966311E80D1 for ; Mon, 23 Sep 2013 22:38:13 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id l13so2811227qcy.3 for ; Mon, 23 Sep 2013 22:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6BdI9F1i1cWEPSAMKNw9hPWaqwvdONYryjwXiOkKzrg=; b=O/PDa39txfp1UAYmOJm6H+WO4f3PxZQRVH/ODKjFCkpzFMNDRrCL8VZwMpnthPSUCl UMHIKLf2VVwHNUbAjuYfPM2bA5XhCLU/9tWTgZvQ5UPEiRYmJ8r3Fpl7dq+GGZbxRJVo qcqhETnJfs5/Mpr08VupmrEk+iwHlwA8uha1ZZwAUCXrBMubj/Fmtj0Zhzg3z7lKj9AY /nPeybzG2vu6n46pYw14XcyYo/drfdppzqjKeX2zulvi8TJNHE0ghdnTm6dmZXV6iYxM Um3L93nQJW3tpT7D2SlzTj3gLfQ/TBbyrHFLtK+goFkNvTF/aSWqg4h74K5qyg019ie1 KBMQ== MIME-Version: 1.0 X-Received: by 10.224.76.10 with SMTP id a10mr27652254qak.9.1380001093147; Mon, 23 Sep 2013 22:38:13 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 22:38:13 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115312E3CFA@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115312E3CFA@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 23 Sep 2013 22:38:13 -0700 Message-ID: From: R S To: "Manger, James H" Content-Type: multipart/alternative; boundary=001a11c305a4f261ef04e71a8ad8 Cc: Carsten Bormann , "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 05:38:15 -0000 --001a11c305a4f261ef04e71a8ad8 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 23, 2013 at 10:26 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Publishing the JSON pointer syntax (which can be > used in lots of places), and modifying the application/json registration > are distinct tasks. It was easier for RFC 6901 "JSON Pointer" to only > do the former, leaving the latter to a more appropriate forum -- which > is this WG at this time. > That is incorrect. RFC 6901 explicitly rules itself out of being the application/json fragment identifer syntax: "the fragment identifier syntax for application/json is not JSON Pointer." Could that be any clearer? - Rob --001a11c305a4f261ef04e71a8ad8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 23, 2013 at 10:26 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
Publishing the JSON pointer syntax (which can be
used in lots of places), and modifying the application/json registration are distinct tasks. It was easier for RFC 6901 "JSON Pointer" to = only
do the former, leaving the latter to a more appropriate forum -- which
is this WG at this time.

That is incorrect. = RFC 6901 explicitly rules itself out of being the application/json fragment= identifer syntax: "the fragment identifier syntax for=A0application/json is not JSON Pointer." Could that be any clearer?

= - Rob

--001a11c305a4f261ef04e71a8ad8-- From cowan@ccil.org Mon Sep 23 22:46:04 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C99F21F91BF for ; Mon, 23 Sep 2013 22:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.15 X-Spam-Level: X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oU1ZOsH61ylN for ; Mon, 23 Sep 2013 22:46:00 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9DB21F90E5 for ; Mon, 23 Sep 2013 22:45:57 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VOLRV-0006vq-HJ; Tue, 24 Sep 2013 01:45:49 -0400 Date: Tue, 24 Sep 2013 01:45:49 -0400 From: John Cowan To: R S Message-ID: <20130924054549.GE18283@mercury.ccil.org> References: <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115312E3CFA@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Carsten Bormann , "Manger, James H" , "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 05:46:04 -0000 R S scripsit: > That is incorrect. RFC 6901 explicitly rules itself out of being the > application/json fragment identifer syntax: "the fragment identifier syntax > for application/json is not JSON Pointer." Could that be any clearer? It merely says that was true as of last April. There is no reason to suppose that it will be true into the indefinite future, as it can be overridden by a later RFC at any time. -- The experiences of the past show John Cowan that there has always been a discrepancy cowan@ccil.org between plans and performance. http://www.ccil.org/~cowan --Emperor Hirohito, August 1945 From sayrer@gmail.com Mon Sep 23 22:52:20 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB15221F9CB0 for ; Mon, 23 Sep 2013 22:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9+hBAbljDqr for ; Mon, 23 Sep 2013 22:52:16 -0700 (PDT) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4C51F21F9CAC for ; Mon, 23 Sep 2013 22:52:16 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id a11so2811497qen.37 for ; Mon, 23 Sep 2013 22:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DZSLn2ZkcYJgYWANBd7LV/LC0D5FtVTmNosbyucZCRY=; b=MrzDb5si52rgFpLsu2lSqAWO+9sOZDeeimMeUHPnlPhnoHvNwZYUOiFLxj5ZDuWtAr 8hqteKrr36X2Ydo9++sPGCBonmPrVk+P4k9KdBOHRZ6NDP5ECvcWAC+kyHS0URQDKFJQ onhjswnRfY/3zP5+SXIFSAYfcIlJmoN+0Yv+ED0AQHcm9Tp1bDdZTG3Ry5lGHDClknIg o7xgQSvYCSHhZOV7vWNJqgVtVNpUSbdksSkCcxoU5tw9SVI5Q8YazNmqg2Cj2ECr+gHP mzkF2DPHwhPM413OPOmSTZuZzqpGQZoUVGtGurWMPo7l2DNX+MyywY+pL7KfN5euxHPF BBPQ== MIME-Version: 1.0 X-Received: by 10.224.112.130 with SMTP id w2mr26913683qap.50.1380001935781; Mon, 23 Sep 2013 22:52:15 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 22:52:15 -0700 (PDT) In-Reply-To: <20130924054549.GE18283@mercury.ccil.org> References: <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115312E3CFA@WSMSG3153V.srv.dir.telstra.com> <20130924054549.GE18283@mercury.ccil.org> Date: Mon, 23 Sep 2013 22:52:15 -0700 Message-ID: From: R S To: John Cowan Content-Type: multipart/alternative; boundary=001a11c2c7d82bf8d404e71abdc1 Cc: Carsten Bormann , "Manger, James H" , "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 05:52:20 -0000 --001a11c2c7d82bf8d404e71abdc1 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 23, 2013 at 10:45 PM, John Cowan wrote: > R S scripsit: > > > That is incorrect. RFC 6901 explicitly rules itself out of being the > > application/json fragment identifer syntax: "the fragment identifier > syntax > > for application/json is not JSON Pointer." Could that be any clearer? > > It merely says that was true as of last April. There is no reason to > suppose that it will be true into the indefinite future, as it can be > overridden by a later RFC at any time. "The JSON working group will have as its only initial task the minor revision of RFC 4627 to bring it onto the Standards Track. As noted above, RFC 4627 is a mature and widely cited specification. The work is essentially a reclassification in place, with minimal changes. The working group will review errata and update the document as needed to incorporate those, and will correct significant errors and inconsistencies, but will keep changes to a minimum." Let's entertain all intellectually-honest interpretations of that text that include defining a fragment identifier syntax in URIs which can't distinguish between the two core JSON data structures. - Rob --001a11c2c7d82bf8d404e71abdc1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Sep 23, 2013 at 10:45 PM, John Cowan <= cowan@mercury.c= cil.org> wrote:
R S scripsit:

> That is incorrect. RFC 6901 explicitly rules itself out of being the > application/json fragment identifer syntax: "the fragment identif= ier syntax
> for application/json is not JSON Pointer." Could that be any clea= rer?

It merely says that was true as of last April. =A0There is no reason = to
suppose that it will be true into the indefinite future, as it can be
overridden by a later RFC at any time.


=
"The JSON working group will = have as its only initial task the minor
revision of RFC 4627 to bring it onto th= e Standards Track. As noted
above, RFC 4627 is a mature and widely c= ited specification. The work is
essentially a reclassification in place,= with minimal changes. The
working group will review errata and upd= ate the document as needed to
incorporate those, and will correct sign= ificant errors and
inconsistencies, but will keep chan= ges to a minimum."=A0

Let's entert= ain all intellectually-honest interpretations of that text that include def= ining a fragment identifier syntax in URIs which can't distinguish betw= een the two core JSON data structures.

- Rob

--001a11c2c7d82bf8d404e71abdc1-- From tbray@textuality.com Mon Sep 23 22:54:05 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD9D21F9D2E for ; Mon, 23 Sep 2013 22:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd9OAlH4f34v for ; Mon, 23 Sep 2013 22:54:00 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC6C21F9CF8 for ; Mon, 23 Sep 2013 22:54:00 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id ha12so3087742vcb.9 for ; Mon, 23 Sep 2013 22:54:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GS6S+rOOHI+dDeNrpMLuUihRUlDPGSEpXnqEnyosZK8=; b=d3aHPuisFBJ68GbR9htNMLz7Yv7yOOuVo420SNs7Lrzvok60X1U9A2uuo6R0qaKloE LTficD98ibAs7EdZRJqWhr6mEuKCTA0tbdKKyS3kogxbEeQjXuHbL4wjRARsleyWmsYW Z4Lh4QVptvGN4ebdqebdRQWYmjEfyzTpIYdUR1wzk/NutSIi4l/h2IUw+J86+Ew5YxZL WqjTn7QIKT/kf000E38gtgv3QqVDeM7D2+W08rMd7mfv+VXLWLN5BLRbVWES9g9k+XJ3 vZVkgqYsuz49RPJeInwffVhFgOniIXhxaXnHCDOT49fE6pPggRKLgxDn2oBspNk39Kj8 Sc9g== X-Gm-Message-State: ALoCoQlYU0TCevQd8nUysSd5nAykIONzW+bAz/3wuomvDHkjGmHHxjWY6mlYAglwMcwzFCJuQ3Ed MIME-Version: 1.0 X-Received: by 10.58.100.144 with SMTP id ey16mr4837668veb.25.1380002039905; Mon, 23 Sep 2013 22:53:59 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Mon, 23 Sep 2013 22:53:59 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <20130924054549.GE18283@mercury.ccil.org> References: <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115312E3CFA@WSMSG3153V.srv.dir.telstra.com> <20130924054549.GE18283@mercury.ccil.org> Date: Mon, 23 Sep 2013 22:53:59 -0700 Message-ID: From: Tim Bray To: John Cowan Content-Type: multipart/alternative; boundary=089e012946ba60cf6604e71ac32f Cc: Carsten Bormann , "json@ietf.org" , "Manger, James H" , R S Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 05:54:05 -0000 --089e012946ba60cf6604e71ac32f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Whether or not this WG/charter combo is empowered to decree #fragment semantics for the application/json media type is a matter for our chairs/ADs. But I have to admit that this one scares me. Because people will notice and they=E2=80=99ll start using it. One of the things I like about JSON-ba= sed APIs is that they=E2=80=99re simple and and have few degrees of freedom. People= are going to start working the #fragment into API specifications and this has to me the smell of plenty enough rope for self-hanging. -T On Mon, Sep 23, 2013 at 10:45 PM, John Cowan wrote= : > R S scripsit: > > > That is incorrect. RFC 6901 explicitly rules itself out of being the > > application/json fragment identifer syntax: "the fragment identifier > syntax > > for application/json is not JSON Pointer." Could that be any clearer? > > It merely says that was true as of last April. There is no reason to > suppose that it will be true into the indefinite future, as it can be > overridden by a later RFC at any time. > > -- > The experiences of the past show John Cowan > that there has always been a discrepancy cowan@ccil.org > between plans and performance. http://www.ccil.org/~cowa= n > --Emperor Hirohito, August 1945 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e012946ba60cf6604e71ac32f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Whether or not this WG/charter combo is empowered to decre= e #fragment semantics for the application/json media type is a matter for o= ur chairs/ADs.

But I have to admit that this one scares me.=C2=A0 B= ecause people will notice and they=E2=80=99ll start using it.=C2=A0 One of = the things I like about JSON-based APIs is that they=E2=80=99re simple and = and have few degrees of freedom.=C2=A0 People are going to start working th= e #fragment into API specifications and this has to me the smell of plenty = enough rope for self-hanging.=C2=A0 -T


On Mon,= Sep 23, 2013 at 10:45 PM, John Cowan <cowan@mercury.ccil.org>= wrote:
R S scripsit:

> That is incorrect. RFC 6901 explicitly rules itself out of being the > application/json fragment identifer syntax: "the fragment identif= ier syntax
> for application/json is not JSON Pointer." Could that be any clea= rer?

It merely says that was true as of last April. =C2=A0There is no reas= on to
suppose that it will be true into the indefinite future, as it can be
overridden by a later RFC at any time.

--
The experiences of the past show =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0John Cowan
that there has always been a discrepancy =C2=A0 =C2=A0 =C2=A0 =C2=A0cowan@ccil.org
between plans and performance. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0http://www.ccil.org/~cowan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --Emperor Hirohito, August 1945
_____________________= __________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e012946ba60cf6604e71ac32f-- From James.H.Manger@team.telstra.com Mon Sep 23 22:57:46 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F9821F9D23 for ; Mon, 23 Sep 2013 22:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvIsHTPtAlmn for ; Mon, 23 Sep 2013 22:57:37 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id A501121F9CE9 for ; Mon, 23 Sep 2013 22:57:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,968,1371045600"; d="scan'208,217";a="159439349" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 24 Sep 2013 15:57:30 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7207"; a="111927965" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcani.tcif.telstra.com.au with ESMTP; 24 Sep 2013 15:57:30 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Tue, 24 Sep 2013 15:57:30 +1000 From: "Manger, James H" To: Tim Bray Date: Tue, 24 Sep 2013 15:57:29 +1000 Thread-Topic: [Json] json-pointer as URI fragment syntax for application/json Thread-Index: Ac646nlGIEY3TCptRnSwWkZfaFwjbAAABgUQ Message-ID: <255B9BB34FB7D647A506DC292726F6E115312E3DFC@WSMSG3153V.srv.dir.telstra.com> References: <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115312E3CFA@WSMSG3153V.srv.dir.telstra.com> <20130924054549.GE18283@mercury.ccil.org> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115312E3DFCWSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 05:57:46 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115312E3DFCWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGltLA0KRG8geW91IG5vdCBsaWtlIGZyYWdtZW50IGlkcyB3aXRoIGFueSBtZWRpYSB0eXBlPyBP ciBpcyB0aGVyZSBzb21lIHJlYXNvbiB3aHkgdGhleSBtaWdodCBiZSB3b3JzZSBmb3IgSlNPTiBp biBwYXJ0aWN1bGFyPw0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCkZyb206IFRpbSBCcmF5IFttYWls dG86dGJyYXlAdGV4dHVhbGl0eS5jb21dDQpTZW50OiBUdWVzZGF5LCAyNCBTZXB0ZW1iZXIgMjAx MyAzOjU0IFBNDQpUbzogSm9obiBDb3dhbg0KQ2M6IFIgUzsgQ2Fyc3RlbiBCb3JtYW5uOyBNYW5n ZXIsIEphbWVzIEg7IGpzb25AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSnNvbl0ganNvbi1wb2lu dGVyIGFzIFVSSSBmcmFnbWVudCBzeW50YXggZm9yIGFwcGxpY2F0aW9uL2pzb24NCg0KV2hldGhl ciBvciBub3QgdGhpcyBXRy9jaGFydGVyIGNvbWJvIGlzIGVtcG93ZXJlZCB0byBkZWNyZWUgI2Zy YWdtZW50IHNlbWFudGljcyBmb3IgdGhlIGFwcGxpY2F0aW9uL2pzb24gbWVkaWEgdHlwZSBpcyBh IG1hdHRlciBmb3Igb3VyIGNoYWlycy9BRHMuDQoNCkJ1dCBJIGhhdmUgdG8gYWRtaXQgdGhhdCB0 aGlzIG9uZSBzY2FyZXMgbWUuICBCZWNhdXNlIHBlb3BsZSB3aWxsIG5vdGljZSBhbmQgdGhleeKA mWxsIHN0YXJ0IHVzaW5nIGl0LiAgT25lIG9mIHRoZSB0aGluZ3MgSSBsaWtlIGFib3V0IEpTT04t YmFzZWQgQVBJcyBpcyB0aGF0IHRoZXnigJlyZSBzaW1wbGUgYW5kIGFuZCBoYXZlIGZldyBkZWdy ZWVzIG9mIGZyZWVkb20uICBQZW9wbGUgYXJlIGdvaW5nIHRvIHN0YXJ0IHdvcmtpbmcgdGhlICNm cmFnbWVudCBpbnRvIEFQSSBzcGVjaWZpY2F0aW9ucyBhbmQgdGhpcyBoYXMgdG8gbWUgdGhlIHNt ZWxsIG9mIHBsZW50eSBlbm91Z2ggcm9wZSBmb3Igc2VsZi1oYW5naW5nLiAgLVQNCg0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E115312E3DFCWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tQVUgbGluaz1ibHVlIHZs aW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5UaW0sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkRvIHlvdSBub3QgbGlrZSBmcmFnbWVudCBp ZHMgd2l0aCBhbnkgbWVkaWEgdHlwZT8gT3IgaXMgdGhlcmUgc29tZSByZWFzb24gd2h5IHRoZXkg bWlnaHQgYmUgd29yc2UgZm9yIEpTT04gaW4gcGFydGljdWxhcj88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn Pi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBj bGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+IFRpbSBCcmF5IFttYWlsdG86dGJyYXlAdGV4dHVhbGl0eS5jb21dIDxi cj48Yj5TZW50OjwvYj4gVHVlc2RheSwgMjQgU2VwdGVtYmVyIDIwMTMgMzo1NCBQTTxicj48Yj5U bzo8L2I+IEpvaG4gQ293YW48YnI+PGI+Q2M6PC9iPiBSIFM7IENhcnN0ZW4gQm9ybWFubjsgTWFu Z2VyLCBKYW1lcyBIOyBqc29uQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW0pzb25d IGpzb24tcG9pbnRlciBhcyBVUkkgZnJhZ21lbnQgc3ludGF4IGZvciBhcHBsaWNhdGlvbi9qc29u PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5XaGV0aGVyIG9yIG5vdCB0 aGlzIFdHL2NoYXJ0ZXIgY29tYm8gaXMgZW1wb3dlcmVkIHRvIGRlY3JlZSAjZnJhZ21lbnQgc2Vt YW50aWNzIGZvciB0aGUgYXBwbGljYXRpb24vanNvbiBtZWRpYSB0eXBlIGlzIGEgbWF0dGVyIGZv ciBvdXIgY2hhaXJzL0FEcy4gPGJyPjxicj5CdXQgSSBoYXZlIHRvIGFkbWl0IHRoYXQgdGhpcyBv bmUgc2NhcmVzIG1lLiZuYnNwOyBCZWNhdXNlIHBlb3BsZSB3aWxsIG5vdGljZSBhbmQgdGhleeKA mWxsIHN0YXJ0IHVzaW5nIGl0LiZuYnNwOyBPbmUgb2YgdGhlIHRoaW5ncyBJIGxpa2UgYWJvdXQg SlNPTi1iYXNlZCBBUElzIGlzIHRoYXQgdGhleeKAmXJlIHNpbXBsZSBhbmQgYW5kIGhhdmUgZmV3 IGRlZ3JlZXMgb2YgZnJlZWRvbS4mbmJzcDsgUGVvcGxlIGFyZSBnb2luZyB0byBzdGFydCB3b3Jr aW5nIHRoZSAjZnJhZ21lbnQgaW50byBBUEkgc3BlY2lmaWNhdGlvbnMgYW5kIHRoaXMgaGFzIHRv IG1lIHRoZSBzbWVsbCBvZiBwbGVudHkgZW5vdWdoIHJvcGUgZm9yIHNlbGYtaGFuZ2luZy4mbmJz cDsgLVQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1s Pg== --_000_255B9BB34FB7D647A506DC292726F6E115312E3DFCWSMSG3153Vsrv_-- From mnot@mnot.net Mon Sep 23 23:12:08 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D9B11E80D1 for ; Mon, 23 Sep 2013 23:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.427 X-Spam-Level: X-Spam-Status: No, score=-105.427 tagged_above=-999 required=5 tests=[AWL=-2.828, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ3LrPo3iafc for ; Mon, 23 Sep 2013 23:11:56 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id DEEE321F9CCC for ; Mon, 23 Sep 2013 23:11:56 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.135.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A7A21509B6; Tue, 24 Sep 2013 02:11:54 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Mark Nottingham In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115312E3CFA@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 24 Sep 2013 16:11:51 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <60668F6F-403F-4430-89D1-CC3E1645B643@mnot.net> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115312E3CFA@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1510) Cc: Carsten Bormann , "json@ietf.org" , R S Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 06:12:09 -0000 On 24/09/2013, at 3:26 PM, "Manger, James H" = wrote: >> Anyway, it isn't within this WG charter's scope to obsolete RFC 6901. >> Let me remind you, that RFC reads: "the fragment identifier syntax = for >> application/json is not JSON Pointer." >>=20 >> and, as Mark wrote: >>=20 >> "we couldn't retroactively change the fragment identifier syntax for >> JSON without a much broader mandate." >=20 > The whole idea is that this JSON-specific IETF WG has the broader = mandate. > This WG is updating the RFC that defines and registers = application/json, > which is precisely where the fragment syntax for the media type needs = to > be specified. >=20 >> that is, the WG didn't have the mandate to specify a general purpose >> JSON fragment identifier. >=20 > I disagree. The WG did specify JSON pointer as a general purpose JSON > fragment identifier. Publishing the JSON pointer syntax (which can be > used in lots of places), and modifying the application/json = registration > are distinct tasks. It was easier for RFC 6901 "JSON Pointer" to only > do the former, leaving the latter to a more appropriate forum -- which > is this WG at this time. >=20 >=20 > Nobody can use any fragment syntax with app./json interoperably at the > moment, as none is defined for this media type -- despite media types > and URI fragments being a core components of our web architecture. >=20 > As a bonus we can say the fragment syntax is a JSON pointer if, and = only if, > the fragment starts with a "/" (or is empty). That leaves room for = other > app./json fragment schemes in future if required. Exactly. -- Mark Nottingham http://www.mnot.net/ From sayrer@gmail.com Mon Sep 23 23:23:15 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4D121F91BF for ; Mon, 23 Sep 2013 23:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEgfQuXc+gFo for ; Mon, 23 Sep 2013 23:23:15 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABF921F9195 for ; Mon, 23 Sep 2013 23:23:15 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id j7so2202237qaq.2 for ; Mon, 23 Sep 2013 23:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I5UyG3+fmgq+Ad9yjzG/OlEL2j3tUoNGOvimqPJhGLY=; b=lPqZOJCbew6a+qzKHWx+4m8Zvd4zxsjdXnSGO/FWAojWtxZBcRQFtqKG3SqC3jVoOn pWyqWPkcZn+54N/mG/1pSc+ZikwAlrdsnMQjaV1RGZnf7r2GVsMAUiaRrM+t2pVMg1er cJIl91bQ99DC1mVnK6TRUHd7NVzez66rjUYzkbN+DPO7cvaVYBGXEaxR7+C1enzKNYYk UZTKZdHkx6/nbDHLGZhuQpgACXWtSojFa85K/KDyC0X+7/k8AnQ4e1WpLDy6xAHc4Ix7 wzlZuNMcoL1aGuHgqGI0wLWJyM38qUhxm0EZRcG+BjL+6hSCOSI3uUMRMZ3oki+juwzi 0SBg== MIME-Version: 1.0 X-Received: by 10.224.114.81 with SMTP id d17mr26797693qaq.18.1380003791656; Mon, 23 Sep 2013 23:23:11 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 23 Sep 2013 23:23:11 -0700 (PDT) In-Reply-To: <60668F6F-403F-4430-89D1-CC3E1645B643@mnot.net> References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115312E3CFA@WSMSG3153V.srv.dir.telstra.com> <60668F6F-403F-4430-89D1-CC3E1645B643@mnot.net> Date: Mon, 23 Sep 2013 23:23:11 -0700 Message-ID: From: R S To: Mark Nottingham Content-Type: multipart/alternative; boundary=047d7bea3a34ca5e0704e71b2b43 Cc: Carsten Bormann , "Manger, James H" , "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 06:23:16 -0000 --047d7bea3a34ca5e0704e71b2b43 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 23, 2013 at 11:11 PM, Mark Nottingham wrote: > > On 24/09/2013, at 3:26 PM, "Manger, James H" < > James.H.Manger@team.telstra.com> wrote: > > > > The WG did specify JSON pointer as a general purpose JSON > > fragment identifier. > > Exactly. No, this is wrong. The WG specified what the draft says, which is: ""the fragment identifier syntax for application/json is not JSON Pointer." If it were otherwise, that would mean some important-sounding person could come along and say "oh, no, what we actually specified was _______". Surely that would never happen in the IETF. - Rob --047d7bea3a34ca5e0704e71b2b43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 23, 2013 at 11:11 PM, Mark Nottingham <mnot@mnot.= net> wrote:

On 24/09/2013, at 3:26 PM, "Manger, James H" <James.H.Manger@team.telstra.com> = wrote:
>
> The WG did specify JSON pointer as a general purpose JSON
> fragment identifier.=A0

Exactly.

No, this is wrong. The= WG specified what the draft says, which is: ""the fragment i= dentifier syntax for=A0application/json is not JSON Pointer.&quo= t;

If it were otherwise, that would mean some important-sounding person= could come along and say "oh, no, what we actually specified was ____= ___". Surely that would never happen in the IETF.

- Rob
--047d7bea3a34ca5e0704e71b2b43-- From duerst@it.aoyama.ac.jp Tue Sep 24 01:03:31 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B2C21F9CED for ; Tue, 24 Sep 2013 01:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.836 X-Spam-Level: X-Spam-Status: No, score=-101.836 tagged_above=-999 required=5 tests=[AWL=-2.046, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mlodu5M7n2-5 for ; Tue, 24 Sep 2013 01:03:24 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id CD5F021F9CCA for ; Tue, 24 Sep 2013 01:03:18 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8O837Qi032763; Tue, 24 Sep 2013 17:03:07 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6448_d418_bf6b7a98_24ef_11e3_addf_001e6722eec2; Tue, 24 Sep 2013 17:03:07 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 2283BBF535; Tue, 24 Sep 2013 17:03:07 +0900 (JST) Message-ID: <52414724.1060407@it.aoyama.ac.jp> Date: Tue, 24 Sep 2013 17:02:44 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: R S References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> <3AC0F7BB-3FED-4614-B73B-5A693968285B@vpnc.org> <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 08:03:31 -0000 On 2013/09/24 13:53, R S wrote: > On Monday, September 23, 2013, Carsten Bormann wrote: >> I understand that one may have an aesthetic preference for distinguishing >> array indexing from map indexing, But, at the engineering level, that is >> about as useful as distinguishing indexing in even length arrays from >> indexing odd length arrays. > At the engineering level, it may be useful to distinguish between ordered > and unordered collections. > > Anyway, it isn't within this WG charter's scope to obsolete RFC 6901. There is no need to obsolete RFC 6901. The IETF clearly distinguishes between "obsoletes" and "updates". > Let > me remind you, that RFC reads: "the fragment identifier syntax for > application/json is not JSON Pointer." Yes, that would be the sentence that would be updated (not by changing the sentence itself, but by specifying something different to what it says). > and, as Mark wrote: > > "we couldn't retroactively change the fragment identifier syntax for JSON > without a much broader mandate." > > that is, the WG didn't have the mandate to specify a general purpose JSON > fragment identifier. That was the APPSA WG. This is the JSON WG. > That makes sense, since every argument in that WG was > along the lines of "well, we're just trying to make this work for our > little use case." I can link you to those emails if you want. As far as I remember, the arguments were along the same lines as the ones we have seen so far in this mailing list. The use case of a fragment identifier is fragment identification. It may well be that JSON Pointer isn't suited for some particular tasks, but I haven't yet seen an argument as to why it is not suited for the task of fragment identification. As for the claims that JSON Pointer isn't suited for some particular tasks, I'd like such claims to be a bit more specific that "can't distinguish between array and object" or "may be useful to distinguish between ordered and unordered collections". They sound nice and somewhat plausible, but they don't show where the rubber hits (or misses) the road. Regards, Martin. From duerst@it.aoyama.ac.jp Tue Sep 24 01:35:44 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8A321F9649 for ; Tue, 24 Sep 2013 01:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.666 X-Spam-Level: X-Spam-Status: No, score=-101.666 tagged_above=-999 required=5 tests=[AWL=-1.876, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qkacypfkS1j for ; Tue, 24 Sep 2013 01:35:37 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 87EB321F949F for ; Tue, 24 Sep 2013 01:35:37 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8O8ZXsS022660; Tue, 24 Sep 2013 17:35:33 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 644c_f1d9_46e14b3e_24f4_11e3_b9f5_001e6722eec2; Tue, 24 Sep 2013 17:35:32 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 5A366BF535; Tue, 24 Sep 2013 17:35:32 +0900 (JST) Message-ID: <52414EBA.6050606@it.aoyama.ac.jp> Date: Tue, 24 Sep 2013 17:35:06 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: R S References: <1379993594.19960.2.camel@dilithium> <1379994149.19960.4.camel@dilithium> <255B9BB34FB7D647A506DC292726F6E115312E3A5F@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115312E3CFA@WSMSG3153V.srv.dir.telstra.com> <20130924054549.GE18283@mercury.ccil.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Manger, James H" , Carsten Bormann , John Cowan , "json@ietf.org" Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 08:35:44 -0000 On 2013/09/24 14:52, R S wrote: > "The JSON working group will have as its only initial task the minor > revision of RFC 4627 to bring it onto the Standards Track. As noted > above, RFC 4627 is a mature and widely cited specification. The work is > essentially a reclassification in place, with minimal changes. The > working group will review errata and update the document as needed to > incorporate those, and will correct significant errors and > inconsistencies, but will keep changes to a minimum." > > Let's entertain all intellectually-honest interpretations of that text that > include defining a fragment identifier syntax in URIs It says that changes should be kept to a minimum, so this is a strong argument to not add anything about fragment identifier syntax. However, "keep changes to a minimum" doesn't mean no changes at all. If the WG (and later the IETF) came to the conclusion that e.g. it would be better to include the definition (by reference) of a fragment identifier syntax in the JSON base specification, e.g. because that wouldn't fit well in a "best practices" document and it wouldn't make sense to republish the JSON spec (which is after all the application/json spec) yet again under a new charter just with the fragment identifier bit added. In some way, this might be done just by rechartering the WG slightly before sending the current work deliverable to the IESG, or by including the fragment identifier bit as something anticipated to be included in the new charter. The WG and IETF last calls could even be sent out explicitly noting this fact. This would just be a way to avoid useless carter and/or document churn. Another solution is of course to process a tiny charter update that adds the the fragment identifier deliverable to the charter. All the above discussion is mostly for the chairs and the ADs to decide on. I just wrote it to make clear that the IETF works by (rough) consensus, and the legalistic bit can be dealt with if necessary (preferably the easier, the better). Of course, what's most important is what the WG and the IETF wants. > which can't > distinguish between the two core JSON data structures. Which isn't needed for fragment identification in about the same way Ruby (and other programming languages) don't have a problem with not distinguishing between Arrays and Hashes on access. Please, please show us a JSON document together with a json pointer fragment identifier where there is an ambiguity as to what the json pointer points to. Regards, Martin. From derhoermi@gmx.net Tue Sep 24 05:05:47 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB4211E8116 for ; Tue, 24 Sep 2013 05:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcMiccR52NRy for ; Tue, 24 Sep 2013 05:05:43 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id A75FB21F93F3 for ; Tue, 24 Sep 2013 05:05:42 -0700 (PDT) Received: from netb.Speedport_W_700V ([91.35.39.163]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0LzGV3-1Vswr70jsf-014XC8 for ; Tue, 24 Sep 2013 14:05:40 +0200 From: Bjoern Hoehrmann To: R S Date: Tue, 24 Sep 2013 14:05:41 +0200 Message-ID: <0vu2499uucgmdhqb0m9897t809rbkkh7re@hive.bjoern.hoehrmann.de> References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:w4qRh+pKwI5F1sxGWS7pyhS02JaZYQtZ1Hu2glXBhU67iFXeW0f gd3ViSjD0vxHwb2HCwdCWm6rcnsCi1fddYhISptKG2thu8+xdi3gGmDZonqmPXXE/bClhih mWh2UcZxlz9TwukKRDkOV+MmIgNSjgvW/r7s8Au5IzHbxKDZuBt8Z9qeTkkhRJ3LGE+70PJ 7ON2JsjGnLVUedL5sM2ig== Cc: "json@ietf.org" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 12:05:48 -0000 * R S wrote: >On Mon, Sep 23, 2013 at 6:57 PM, Tim Bray wrote: >> Signed zeros are significant in some numerically-intensive applications, >> but implementations which read JSON texts cannot be relied upon to preserve >> that distinction. > >Aren't these implementations just buggy? > >This works in the JavaScript implementations I checked: > >> var input = '{"pos":0, "neg":-0}' >undefined >> var obj = JSON.parse(input) >undefined >> 1/obj.pos >Infinity >> 1/obj.neg >-Infinity However, ecmascript's JSON.stringify does not preserve the sign, and so 1 / JSON.parse(JSON.stringify(JSON.parse('-0'))) is positive infinity. Since `(-0).toString()` and `String(-0)` are `0` that should not be too surprising, but such anomalies attract bugs, and sure enough, Opera 12.x's JSON.parse does not preserve the zero sign. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From jorge@jorgechamorro.com Tue Sep 24 05:15:16 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C043811E811F for ; Tue, 24 Sep 2013 05:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsanPU2G2OWU for ; Tue, 24 Sep 2013 05:15:11 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 78BD511E8110 for ; Tue, 24 Sep 2013 05:15:10 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id cb5so3670190wib.9 for ; Tue, 24 Sep 2013 05:15:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Trs7R+ofWhoR+7rH31+MHp+mGvco+boOIO+wMAac170=; b=EC+fi1LvyqLPtX9PObLP240th9QhreuAPLocqNuGySSN1OnM9EARwxQkfofwht9h7Y xMc7r0+YXt0pynfPxYjqT6B/q0z0nePqWPAZ6PGmsGJTOHOOmQ5N2fVaSefIznzEcnJ2 qgRnF0Bv88s5xjR4xsqL/m7cGtY1uwfyy71Ywb/E08c7S65a49r7mfJ2RIewClpwvzds sX+lPzyJk298Tslw6ICnRBIiVbKvyr5uXvT5UJyM+bOq6uACDE26bTx31Tfy90VXbhJI 26XFh9hMG9lT+lCmrTyaJDneu6ALX4vxsvPb7B7bJurYCdkF6217EyVk1hdWp5Sr4uld Vjgw== X-Gm-Message-State: ALoCoQlAAh3MVUm0Mcd+LVU4gJFOsAlDaIu2hTJrI2sOKpWosTX8Uy2wlr6fGKIu1nTmKm5wxa2e X-Received: by 10.194.120.68 with SMTP id la4mr9894964wjb.33.1380024908345; Tue, 24 Sep 2013 05:15:08 -0700 (PDT) Received: from [192.168.10.50] (160.Red-88-0-222.dynamicIP.rima-tde.net. [88.0.222.160]) by mx.google.com with ESMTPSA id jf2sm7038803wic.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 05:15:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: Date: Tue, 24 Sep 2013 14:15:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tim Bray X-Mailer: Apple Mail (2.1085) Cc: "json@ietf.org" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 12:15:16 -0000 On 24/09/2013, at 03:57, Tim Bray wrote: > numbers which are integers, in the range [(-2**53)+1, (2**53)-1], and = are represented without "frac" parts I'd move that minus out of the parenthesis: [-(2**53)+1, (2**53)-1] --=20 ( Jorge )();= From tbray@textuality.com Tue Sep 24 13:37:59 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A701721F9D89 for ; Tue, 24 Sep 2013 13:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.772 X-Spam-Level: X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOZo5KqXU26N for ; Tue, 24 Sep 2013 13:37:46 -0700 (PDT) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id 371F821F8EA8 for ; Tue, 24 Sep 2013 13:37:45 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id x14so3701135vbb.23 for ; Tue, 24 Sep 2013 13:37:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gDgYLj0XbkX3nA7T+hENNKq0hz3yoXBVGvbTaGaBv6c=; b=DvH1B0AxL3ZkeiwWZgU5FCRS2MeksBDmN/TYDC2NJCHuHJzV9zXjVCBwdbGAPpu6k0 +G5qytBQaqDDn4jHWzu5Bfq4OG5SvmpVTSZiwDvvdndjNhY0ZvTVO/+hHNI3zrtL1GL+ x5KNlONuplPioE1cmn6ldcf5ErPbllAkUjjN4yDBu1Un2eupcuv0lZHMZs0oEQzfCzOs 3eMDH4dUo1IVbRFpd8cGifb3wGRPbAqCv8v+bOrTkEGpKw8t4IYwsFHSb1Rn3WaBIv57 phDfMfBIt6Fv984vyaHYxG+iqcqeW+8NhKm6d9eYPmQe0mknY/n2XHW6KxPyvF6YVB6j 96hg== X-Gm-Message-State: ALoCoQkXVPg5FPruHRqqxcbAyLpDCDtkw0QUtvm76WSc+eSMphniz1tTAgVsBpz/aJyYlGgrpgaz MIME-Version: 1.0 X-Received: by 10.220.11.7 with SMTP id r7mr29396286vcr.12.1380055064480; Tue, 24 Sep 2013 13:37:44 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Tue, 24 Sep 2013 13:37:44 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <29C29B1D-81DF-438D-AF3E-1631CECDC324@tzi.org> References: <29C29B1D-81DF-438D-AF3E-1631CECDC324@tzi.org> Date: Tue, 24 Sep 2013 13:37:44 -0700 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c3e47ce3a24804e7271b88 Cc: "json@ietf.org" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 20:37:59 -0000 --001a11c3e47ce3a24804e7271b88 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carsten, I like your edits, but: On Mon, Sep 23, 2013 at 10:27 PM, Carsten Bormann wrote: > > Attempting to represent numbers that cannot be exactly encoded as an > IEEE 754:2008 binary64 number, such as 1E400, 9007199254740993, or > 3.141592653589793238462643383279, may cause interoperability problems. > > As I mentioned before, 1.1 "cannot be exactly encoded as an IEEE 754:2008 > binary64 number", and there are fewer interop problems with that than wit= h > the first two examples you give here. > Also, it is not the attempt to represent 9007199254740993, but the > expectation that an implementation will be able to distinguish > 9007199254740993 from 9007199254740992, that causes interop problems (sam= e > with 3.141592653589793238462643383279). > I totally don=E2=80=99t get what you=E2=80=99re trying to say about 1.1. I= t seems to me that despite the fact that lots of decimal fractions can=E2=80=99t be repre= sented in binary FP, conforming to 754 gives, as we say =E2=80=9Cgood interoperabi= lity=E2=80=9D, in the sense that people who worry about arithmetic mean. And that round-tripping 1.1 through JSON is generally unlikely to break your program. Maybe you=E2=80=99re arguing for more exactness, something like =E2=80=9C9007199254740993 (2**53+1) and 3.141592653589793238462643383279 ex= press more precision than is available in an IEEE754 binary64, and IE400 exceeds the greatest possible magnitude expressible in such a number.=E2=80=9D If I=E2=80=99m missing your point (quite likely), please provide alternativ= e language that would give better guidance about the kinds of numeric values to avoid, and why. -T > > Numbers which represent zero without a sign, for example as 0 or 0.0 no= t > -0 or +0.0, > > +0.0 isn't JSON. > > > are interoperable in the sense that software implementations will agree > on the zero value. Signed zeros are significant in some > numerically-intensive applications, but implementations which read JSON > texts cannot be relied upon to preserve that distinction. > > (Maybe be more specific that this is about the distinction between 0.0 an= d > -0.0, not about the presence or absence of a sign, even though that is > actually the same in JSON.) > > Gr=C3=BC=C3=9Fe, Carsten > > --001a11c3e47ce3a24804e7271b88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carsten, I like your edits, but:

On Mon, Sep 23, 2013 at 10:27 PM, = Carsten Bormann <cabo@tzi.org> wrote:
> Attempting to repres= ent numbers that cannot be exactly encoded as an IEEE 754:2008 binary64 num= ber, such as 1E400, 9007199254740993, or 3.141592653589793238462643383279, = may cause interoperability problems.

As I mentioned before, 1.1 "cannot be exactly encoded as an IEEE= 754:2008 binary64 number", and there are fewer interop problems with = that than with the first two examples you give here.
Also, it is not the attempt to represent 9007199254740993, but the expectat= ion that an implementation will be able to distinguish 9007199254740993 fro= m 9007199254740992, that causes interop problems (same with 3.1415926535897= 93238462643383279).

I totally don=E2=80=99t get what you=E2=80= =99re trying to say about 1.1.=C2=A0 It seems to me that despite the fact t= hat lots of decimal fractions can=E2=80=99t be represented in binary FP, co= nforming to 754 gives, as we say =E2=80=9Cgood interoperability=E2=80=9D, i= n the sense that people who worry about arithmetic mean.=C2=A0 And that rou= nd-tripping 1.1 through JSON is generally unlikely to break your program. M= aybe you=E2=80=99re arguing for more exactness, something like =E2=80=9C900= 7199254740993 (2**53+1) and 3.141592653589793238462643383279 express more p= recision than is available in an IEEE754 binary64, and IE400 exceeds the gr= eatest possible magnitude expressible in such a number.=E2=80=9D=C2=A0

If I=E2=80=99m missing your point (quite likely), please pro= vide alternative language that=C2=A0 would give better guidance about the k= inds of numeric values to avoid, and why.

=C2=A0-T



> Numbers which represent zero without a sign, for example as 0 or 0.0 n= ot -0 or +0.0,

+0.0 isn't JSON.

> are interoperable in the sense that software implementations will agre= e on the zero value. Signed zeros are significant in some numerically-inten= sive applications, but implementations which read JSON texts cannot be reli= ed upon to preserve that distinction.

(Maybe be more specific that this is about the distinction between 0.= 0 and -0.0, not about the presence or absence of a sign, even though that i= s actually the same in JSON.)

Gr=C3=BC=C3=9Fe, Carsten


--001a11c3e47ce3a24804e7271b88-- From cabo@tzi.org Tue Sep 24 14:43:28 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388CE11E817C for ; Tue, 24 Sep 2013 14:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.164 X-Spam-Level: X-Spam-Status: No, score=-106.164 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIPygm7MCXsL for ; Tue, 24 Sep 2013 14:43:22 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id ED56011E80E3 for ; Tue, 24 Sep 2013 14:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8OLhFUU025941; Tue, 24 Sep 2013 23:43:15 +0200 (CEST) Received: from [192.168.217.105] (p54892095.dip0.t-ipconnect.de [84.137.32.149]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D8F82FA; Tue, 24 Sep 2013 23:43:14 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Tue, 24 Sep 2013 23:43:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <689B99BA-783F-4A76-A9AA-49DD46224850@tzi.org> References: <29C29B1D-81DF-438D-AF3E-1631CECDC324@tzi.org> To: Tim Bray X-Mailer: Apple Mail (2.1510) Cc: "json@ietf.org" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 21:43:28 -0000 > I totally don=92t get what you=92re trying to say about 1.1. =20 I'm trying to say there is no difference between 1.1 and the other = numbers with respect to the question: "can it be exactly encoded as an = IEEE 754:2008 binary64 number"? The difference that you are most likely after is that most = implementations will convert this number back to decimal 1.1, even = though it is internally represented as = 1.100000000000000088817841970012523233890533447265625. But we shouldn't try to single out the numbers that "cannot be exactly = encoded as an IEEE 754:2008 binary64 number", because there are lot of = those, and not all of their uses cause interop problems. > It seems to me that despite the fact that lots of decimal fractions = can=92t be represented in binary FP, conforming to 754 gives, as we say = =93good interoperability=94, in the sense that people who worry about = arithmetic mean. And that round-tripping 1.1 through JSON is generally = unlikely to break your program. That depends on whether the 1.1 was meant to be precise or not. You = cannot say by looking at the number. > Maybe you=92re arguing for more exactness, something like = =939007199254740993 (2**53+1) and 3.141592653589793238462643383279 But again, you cannot say by looking at the JSON whether the given = precision actually matters or not. That somebody generated = 3.141592653589793238462643383279 with all those digits may be absolutely = crucial for the application or the = 3.141592653589793115997963468544185161590576171875 you actually get from = IEEE 754 may well be good enough. Again, you cannot tell by looking at = the JSON. > express more precision 1.1 expresses a *lot* of precision. It is precisely 10 % more than = 1.0... There is no semantic difference in JSON between 1.1 and 1.100000000000000000000000000000000000000000000000000000 > than is available in an IEEE754 binary64, and IE400 exceeds the = greatest possible magnitude expressible in such a number.=94 =20 Converting 1e400 into binary64 leads to a more catastrophic loss of = precision, indeed. (But if the application is trying to express an upper limit on an = electron count, there still is no practical difference between 1e400 and = Infinity.) > If I=92m missing your point (quite likely), please provide alternative = language that would give better guidance about the kinds of numeric = values to avoid, and why. How about: Representing numbers that cannot be exactly encoded as an IEEE 754:2008 = binary64 number, such as 1E400, 9007199254740993, = 3.141592653589793238462643383279, or even 1.1, may cause = interoperability problems if the application relies on the decimally = encoded JSON number being exactly preserved in the decimal-to-binary = conversion during the decoding process. Gr=FC=DFe, Carsten From tbray@textuality.com Tue Sep 24 15:07:44 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54B411E80E3 for ; Tue, 24 Sep 2013 15:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjA7c4Bc70Du for ; Tue, 24 Sep 2013 15:07:33 -0700 (PDT) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7559C11E8180 for ; Tue, 24 Sep 2013 15:07:31 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id c14so4165937vea.29 for ; Tue, 24 Sep 2013 15:07:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pCAswcL8I/+JArgXyn4tSp7/lHHr9JvrYwoznBFmJmM=; b=DV6G4Knhx+QZ0h3Y+6cRvR/ITJZh+U7uVeCZ2GQKpQq92ZVlVWd6jEi1DTTM6y3xXr F2tRfAObmQaJnFwEli65Zlkg5Fi39PPMluK0M1xnlETXl0jQKMioUdd7zQ0OC7DLBLUC fz77r4WE6IyGrTPRCrsSh7mTrWPm3diUVtCjnYbBEGBE3lSGrp0QEm0ZofbgA22TIKFg zsUDoAiav2dHcmyZd0DfrJISL/T7ESGRhz9Gfgc+ad3+vfbRFhScpVX1RScczI1er58U Q8y7gMEzhTk7fE4gih3vi1AOWBcNVAg3AEbCCygI4ESgTGFQMkJLImlvWlwxHEMCrKcJ bA0A== X-Gm-Message-State: ALoCoQmc5oz8xNMmK7GuNkspuQHsyp4dhwIIBpgxsuH8j63KaJ72rpRSFkbpfUw9jPoYjo6uIM1y MIME-Version: 1.0 X-Received: by 10.52.157.134 with SMTP id wm6mr7681005vdb.26.1380060450882; Tue, 24 Sep 2013 15:07:30 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Tue, 24 Sep 2013 15:07:30 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <689B99BA-783F-4A76-A9AA-49DD46224850@tzi.org> References: <29C29B1D-81DF-438D-AF3E-1631CECDC324@tzi.org> <689B99BA-783F-4A76-A9AA-49DD46224850@tzi.org> Date: Tue, 24 Sep 2013 15:07:30 -0700 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e0160d0acf1a1dc04e7285c53 Cc: "json@ietf.org" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 22:07:44 -0000 --089e0160d0acf1a1dc04e7285c53 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Sep 24, 2013 at 2:43 PM, Carsten Bormann wrote: > How about: > > Representing numbers that cannot be exactly encoded as an IEEE 754:2008 > binary64 number, such as 1E400, 9007199254740993, > 3.141592653589793238462643383279, or even 1.1, may cause interoperability > problems if the application relies on the decimally encoded JSON number > being exactly preserved in the decimal-to-binary conversion during the > decoding process. > OK, but it feels to me that there=E2=80=99s an important difference between= the normal binary/decimal fraction you get with 1.1, and the guaranteed-breakage you=E2=80=99re getting with the others. > > Gr=C3=BC=C3=9Fe, Carsten > > --089e0160d0acf1a1dc04e7285c53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 24, 2013 at 2:43 PM, Carsten Bormann <cabo@tzi.org= > wrote:
How about:

Representing numbers that cannot be exactly encoded as an IEEE 754:2008 bin= ary64 number, such as 1E400, 9007199254740993, 3.14159265358979323846264338= 3279, or even 1.1, may cause interoperability problems if the application r= elies on the decimally encoded JSON number being exactly preserved in the d= ecimal-to-binary conversion during the decoding process.

OK, but it feels to me that there=E2=80=99= s an important difference between the normal binary/decimal fraction you ge= t with 1.1, and the guaranteed-breakage you=E2=80=99re getting with the oth= ers.
=C2=A0

Gr=C3=BC=C3=9Fe, Carsten


--089e0160d0acf1a1dc04e7285c53-- From tbray@textuality.com Tue Sep 24 15:21:29 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABD711E8188 for ; Tue, 24 Sep 2013 15:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.806 X-Spam-Level: X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1MpleMXTsRz for ; Tue, 24 Sep 2013 15:21:21 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9233E21F9C4D for ; Tue, 24 Sep 2013 15:20:57 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id ht10so3734610vcb.24 for ; Tue, 24 Sep 2013 15:20:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Z9hJnI5B5xu0iGhWm3s9Y2gQTEZ+wug7QYpU+0quzKg=; b=jOZVcfb2l9Btg7Apic+W5t+GllmWSpGn0L4PZ5PjQDFv2DoHnCBXjp8SEUTrDmQ5WK YFJiY1RpgZ1YeYKjojQ65zUzVN2I6FDxJwdjZ9B4vTPtMRy568RNzqH/y9IKLQxojs2M /9Wbfhp6bHgByMK0pdy22eecYio0Fe7+gwjEkHMRsk/1p1/x0wKwHyDX4ltjYqgYbuYF YR6Cb7zw508RcZrxtw4L1yrFic7zldOgkPpa7cpbAOllWyRAEzpl1cxSYoKuh8MBzFKL fs5PK/VsirG6JXpKzk/2r1iwKe/vZrBhX+2wYwCzwmYv3Y7rvusKLBgzPIzuC5Qo/ApB ihXg== X-Gm-Message-State: ALoCoQlfmJzTbNWR8xPpPTi89YGUElx6E9dRHizrgjtkdKKC4npX/uONGSl/OC9agVkWquurdLWc MIME-Version: 1.0 X-Received: by 10.221.56.194 with SMTP id wd2mr30167713vcb.7.1380061254222; Tue, 24 Sep 2013 15:20:54 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Tue, 24 Sep 2013 15:20:54 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <29C29B1D-81DF-438D-AF3E-1631CECDC324@tzi.org> <689B99BA-783F-4A76-A9AA-49DD46224850@tzi.org> Date: Tue, 24 Sep 2013 15:20:54 -0700 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11337ef6d39b8d04e7288c64 Cc: "json@ietf.org" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 22:21:29 -0000 --001a11337ef6d39b8d04e7288c64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I meant to say: OK, but it feels to me that there=E2=80=99s an important di= fference between the normal binary/decimal friction you get with 1.1, and the guaranteed-breakage you=E2=80=99re getting with the others. Friction not f= raction. On Tue, Sep 24, 2013 at 3:07 PM, Tim Bray wrote: > On Tue, Sep 24, 2013 at 2:43 PM, Carsten Bormann wrote: > >> How about: >> >> Representing numbers that cannot be exactly encoded as an IEEE 754:2008 >> binary64 number, such as 1E400, 9007199254740993, >> 3.141592653589793238462643383279, or even 1.1, may cause interoperabilit= y >> problems if the application relies on the decimally encoded JSON number >> being exactly preserved in the decimal-to-binary conversion during the >> decoding process. >> > > OK, but it feels to me that there=E2=80=99s an important difference betwe= en the > normal binary/decimal fraction you get with 1.1, and the > guaranteed-breakage you=E2=80=99re getting with the others. > > >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> > --001a11337ef6d39b8d04e7288c64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I meant to say: OK, but it feels to me that there=E2=80=99= s an important difference between the=20 normal binary/decimal friction you get with 1.1, and the=20 guaranteed-breakage you=E2=80=99re getting with the others.=C2=A0 Friction = not fraction.


On Tue, Sep 24, 2013 at 3:07 PM, Tim Bray <<= a href=3D"mailto:tbray@textuality.com" target=3D"_blank">tbray@textuality.c= om> wrote:
On Tue, S= ep 24, 2013 at 2:43 PM, Carsten Bormann <cabo@tzi.org> wrote:
How about:

Representing numbers that cannot be exactly encoded as an IEEE 754:2008 bin= ary64 number, such as 1E400, 9007199254740993, 3.14159265358979323846264338= 3279, or even 1.1, may cause interoperability problems if the application r= elies on the decimally encoded JSON number being exactly preserved in the d= ecimal-to-binary conversion during the decoding process.

OK, but it feels to me that there=E2= =80=99s an important difference between the normal binary/decimal fraction = you get with 1.1, and the guaranteed-breakage you=E2=80=99re getting with t= he others.
=C2=A0

Gr=C3=BC=C3=9Fe, Carsten



--001a11337ef6d39b8d04e7288c64-- From mamille2@cisco.com Tue Sep 24 15:22:00 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4725711E8193 for ; Tue, 24 Sep 2013 15:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXav8VA71Oua for ; Tue, 24 Sep 2013 15:21:49 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4E44F11E8183 for ; Tue, 24 Sep 2013 15:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7016; q=dns/txt; s=iport; t=1380061266; x=1381270866; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=a2mXddAlZgLAUYYOBQjfGtLmzENQvaYFXGoJi5PI4mc=; b=O/da4JHEzN7jQl1QVc/wy2QRFPZoEHzJjFR830+lyxkxI0MsRnL/NMO3 jBaUy9ZftRQqCBCIM6wG/dYvcgJiLYK7cIoV9WqEfF3RHuqKsbHR/sJgb CnjeivzSlWncDpz54keXtqkKReaQtoP4bRugyEYnM2i20mriZf9ODTnYY s=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAOgPQlKtJV2Y/2dsb2JhbABbgweBCsBigSAWdIImAQEEgQkCAQgiJAIwJQIEGwaHd7xPjyA4gx2BAAOQJoEvmB6DJIIq X-IronPort-AV: E=Sophos;i="4.90,974,1371081600"; d="p7s'?scan'208";a="264014601" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 24 Sep 2013 22:20:59 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8OMKxSm002395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 24 Sep 2013 22:20:59 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.253]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 17:20:59 -0500 From: "Matt Miller (mamille2)" To: WG Thread-Topic: json-pointer as URI fragment syntax for application/json Thread-Index: AQHOtod7MctwqAYE7EWfjnfwScDavpnVz3IA Date: Tue, 24 Sep 2013 22:20:58 +0000 Message-ID: References: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115310592C5@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.48] Content-Type: multipart/signed; boundary="Apple-Mail=_6D1BF8D9-F5ED-487C-AF9E-F837E586826F"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: Re: [Json] json-pointer as URI fragment syntax for application/json X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 22:22:00 -0000 --Apple-Mail=_6D1BF8D9-F5ED-487C-AF9E-F837E586826F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It does not appear there is any consensus to incorporate JSON pointer, = although it seems premature to declare one way or another. It is also = not clear that this proposal is addressing a significant error or = inconsistency in either RFC4627 or ECMA-262. However, the overall goal of this Working Group is to produce an update = to JSON that improves interoperability. If the lack of a syntax for URI = fragments is harming interoperability, then defining one would seem to = be within the scope of the current charter. To that end, anyone willing to propose specific texts to incorporate = into 4627bis -- whether for JSON pointer or another syntax -- might help = the Working Group come to some consensus. We also need to understand = whether or not the lack of a syntax for URI fragments is actually = harming interoperability, so discussion of this is still in scope for = the WG. - Paul Hoffman and Matt Miller= --Apple-Mail=_6D1BF8D9-F5ED-487C-AF9E-F837E586826F Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5MjQyMjIw NTlaMCMGCSqGSIb3DQEJBDEWBBSXCT7w0g82njulV6MqZTzA25X17jCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBABEc 3ttfydNfhnEj29z57Jw4RuZ2ypcot4Z9o1lKdDspomUOtlVNUOH4ye/fOlXRJdGRu2vOYqw39Xc9 rjHt5MN49g3vtqh2faAl2LP3TOvtLpKk4oWXavurk2GmXD9jeSujSEtA0FwbinT5invGoymwoAMr jCQH4v52UBZYoslYVpoUpWRmoFdMJouJeWE01Et+bPrLGyVBn45/4ePrfAgQqtYFLTg3ZFtCLvAz BJL+s1zhzih4KREDYcWG07MKtyrG+91kflPv7ITUvdJ6ko9HmHn0dQwadHZSkX+8pHtew0gFyfIX 7pPvooXUUAgTRED/kmkMbxMR9a6Jnxkj9ekAAAAAAAA= --Apple-Mail=_6D1BF8D9-F5ED-487C-AF9E-F837E586826F-- From johnl@iecc.com Tue Sep 24 17:39:35 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C6E11E81A7 for ; Tue, 24 Sep 2013 17:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwIwUlOtLjbg for ; Tue, 24 Sep 2013 17:39:31 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B1B3311E81A2 for ; Tue, 24 Sep 2013 17:39:29 -0700 (PDT) Received: (qmail 67707 invoked from network); 25 Sep 2013 00:39:24 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Sep 2013 00:39:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=524230bc.xn--hew.k1309; i=johnl@user.iecc.com; bh=u59S2ubcYzLAMLnOUWpvNKMduRdszo/24yarHlq4MQY=; b=t6cOVWKdSI77Hg9iPNWFNnRqLO0pkV6p4BvWbN7kMt4+BLG5Jtv9zL8X+QJg7miIC74OndIO3Wp8hfWWxvm+8/cf0wB/RrBpOSJcBePZuL5z1VPsUlnL1Q7HdaTNISJsVa4S4rh7wPAl3ZTcncBNBXc5lSOsZPspOAB4qVXhUlXjXNOIMtd4kTdNK43RtLl8I8xrN8qdmjpLwP/WgILMAo0a9MzEDmdWJAxceV7nnooPJJidZjOdcYnmyfuKimA0 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=524230bc.xn--hew.k1309; olt=johnl@user.iecc.com; bh=u59S2ubcYzLAMLnOUWpvNKMduRdszo/24yarHlq4MQY=; b=kOB+Ii4zyehzSpivde4iMn6voIbkjyRynSw2YxlkKfuRMaQff7KlPPJEAnb82HXVDFzuxaJGkIa1YUrV+q8ven7+iPBXKb17Bx2ZJHYyPnCKyimynnNX4Bemg1ZZEAmU7eR7crmwtwBh4rX8qzCqIPYcRumNulC0xn3+y3/uh9kYL7WklUga2eCA9T0TzN887IVWHq7bGGZnA7MwVp9qmBninjEEcKousyTKBsxIGkzUz2Mi0Hbbb9vP69hQyAGK Date: 25 Sep 2013 00:39:02 -0000 Message-ID: <20130925003902.17796.qmail@joyce.lan> From: "John Levine" To: json@ietf.org In-Reply-To: <689B99BA-783F-4A76-A9AA-49DD46224850@tzi.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: cabo@tzi.org Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2013 00:39:35 -0000 >The difference that you are most likely after is that most implementations will convert this number back to decimal 1.1, even though >it is internally represented as 1.100000000000000088817841970012523233890533447265625. My zSeries mainframe represents 1.1 as 1.100000 and will generally print that value as 1.1 or maybe 1.10 depending on the picture. That's because it has decimal floating point. (See the z/Architecture Principles of Operation, chapter 20.) Really, anyone who thinks that JSON is tied to IEEE or any other particular internal numeric representation is just mistaken, and the sooner we get past that misconception, the better. R's, John From cowan@ccil.org Tue Sep 24 18:55:19 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F053F11E80FE for ; Tue, 24 Sep 2013 18:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-aE+nstQ5cu for ; Tue, 24 Sep 2013 18:55:12 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id A878211E81A5 for ; Tue, 24 Sep 2013 18:55:12 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VOeJp-0004sr-9K; Tue, 24 Sep 2013 21:55:09 -0400 Date: Tue, 24 Sep 2013 21:55:09 -0400 From: John Cowan To: John Levine Message-ID: <20130925015509.GF11428@mercury.ccil.org> References: <689B99BA-783F-4A76-A9AA-49DD46224850@tzi.org> <20130925003902.17796.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130925003902.17796.qmail@joyce.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: cabo@tzi.org, json@ietf.org Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2013 01:55:19 -0000 John Levine scripsit: > My zSeries mainframe represents 1.1 as 1.100000 and will generally > print that value as 1.1 or maybe 1.10 depending on the picture. > That's because it has decimal floating point. (See the z/Architecture > Principles of Operation, chapter 20.) Those decimal floats are in fact IEEE 754:2008 compliant. I note that if you compile a HLL runtime with gcc -funsafe-math-optimizations, it no longer distinguishes 0.0 and -0.0. > Really, anyone who thinks that JSON is tied to IEEE or any other > particular internal numeric representation is just mistaken, and > the sooner we get past that misconception, the better. +1 -- John Cowan cowan@ccil.org "Not to know The Smiths is not to know K.X.U." --K.X.U. From James.H.Manger@team.telstra.com Tue Sep 24 21:19:32 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5908E1F0D13 for ; Tue, 24 Sep 2013 21:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.235 X-Spam-Level: X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[AWL=-1.635, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, MANGLED_SEX=2.3, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV1nFicWjJc0 for ; Tue, 24 Sep 2013 21:19:26 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5619711E819A for ; Tue, 24 Sep 2013 21:19:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,976,1371045600"; d="scan'208,217";a="159641319" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 25 Sep 2013 14:19:18 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7208"; a="112143932" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcani.tcif.telstra.com.au with ESMTP; 25 Sep 2013 14:19:19 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Wed, 25 Sep 2013 14:19:18 +1000 From: "Manger, James H" To: Tim Bray , Carsten Bormann Date: Wed, 25 Sep 2013 14:19:17 +1000 Thread-Topic: [Json] All those number ideas Thread-Index: Ac65dId6Ngh5I0QASlegn4JIhVTXvwAK1wYA Message-ID: <255B9BB34FB7D647A506DC292726F6E115313A0FCD@WSMSG3153V.srv.dir.telstra.com> References: <29C29B1D-81DF-438D-AF3E-1631CECDC324@tzi.org> <689B99BA-783F-4A76-A9AA-49DD46224850@tzi.org> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115313A0FCDWSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2013 04:19:32 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115313A0FCDWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgZ3Vlc3MgaXMgdGhhdCBuZWl0aGVyIDMuMTQxNTkyNjUzNTg5NzkzMjM4NDYyNjQzMzgzMjc5 IG5vciAxLjEgY2F1c2UgaW50ZXJvcCBwcm9ibGVtcyAoaW4gZ2VuZXJhbCkuIEkgYXNzdW1lICho b3BlKSBiYXNpY2FsbHkgYWxsIEpTT04gcGFyc2VycyB3aWxsIHBhcnNlIGJvdGgsIGV2ZW4gaWYg dGhleSBhcHByb3hpbWF0ZSB0aGUgbnVtYmVyIGluIHRoZWlyIGludGVybmFsIGJpbmFyeSByZXBy ZXNlbnRhdGlvbi4gSSBkb3VidCB0aGF0IHJvdW5kaW5nIGNhdXNlcyBtYW55IGludGVyb3AgcHJv YmxlbXMgYXMgcm91bmRpbmcgY29tZXMgd2l0aCB0aGUgdGVycml0b3J5IHdoZW4gZGVhbGluZyB3 aXRoIGZsb2F0cy4gRm9yIGluc3RhbmNlLCBlcXVhbGl0eSB0ZXN0aW5nIGlzIGFsbW9zdCBhbHdh eXMgZG9kZ3kgd2l0aCBmbG9hdHMgKHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBKU09OIGlzIGludm9s dmVkKSwgYW5kIDwgYW5kL29yID4gc2hvdWxkIGJlIHVzZWQgaW5zdGVhZC4NCg0KUGVyaGFwcyBz YXk6DQogIElmIHlvdSBleGNoYW5nZSBudW1iZXJzIGV4cGVjdGluZyBubyBtb3JlIHByZWNpc2lv biBvciByYW5nZSB0aGFuDQogIGF2YWlsYWJsZSB3aXRoIGFuIElFRUUgNjQtYml0IGRvdWJsZSAo ZWcgNTIgYml0cyBvZiBwcmVjaXNpb24sDQogIHdoaWNoIGlzIGFib3V0IDE2IGRlY2ltYWwgZGln aXRzKSwgdGhlbiBhIEpTT04gbnVtYmVyIHdpbGwgYmUNCiBpbnRlcm9wZXJhYmxlIGluIHRoZSBz ZW5zZSB0aGF0IGltcGxlbWVudGF0aW9ucyB3aWxsDQogYXBwcm94aW1hdGUgdGhlIG51bWJlciB3 aXRoaW4gdGhlIGV4cGVjdGVkIHByZWNpc2lvbi4gSWYgeW91IGV4cGVjdA0KIGEgZ3JlYXRlciBw cmVjaXNpb24gb3IgcmFuZ2UgdGhlbiBwcm9ibGVtcyBvZiByb3VuZGluZyBjYW4gaGFwcGVuLg0K DQoNCkZvciBpbnRlZ2Vycywgb24gdGhlIG90aGVyIGhhbmQsIHdlIG5lZWQgYSBkaWZmZXJlbnQg d2FybmluZy4gUGVyaGFwczoNCg0KICBJZiB5b3UgZXhjaGFuZ2UgYW4gaW50ZWdlciB4LCB3aGVy ZSAtMioqNTMgPCB4IDwgMioqNTMsIGluIEpTT04NCiB3aXRob3V0IGEgZnJhY3Rpb24gb3IgZXhw b25lbnQgcGFydCwgdGhlIG51bWJlciB3aWxsIGJlIGludGVyb3BlcmFibGUNCiAgaW4gdGhlIHNl bnNlIHRoYXQgbW9zdCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBhZ3JlZSBvbiB0aGUgdmFsdWUgcHJl Y2lzZWx5Lg0KICBJbnRlZ2VycyBvdXRzaWRlIHRoaXMgcmFuZ2UsIG9yIGV4cHJlc3NlZCB3aXRo IGZyYWN0aW9uIG9yIGV4cG9uZW50IHBhcnRzLA0KICBjYW4gZmFjZSBwcm9ibGVtcyBvZiBiZWlu ZyBhcHByb3hpbWF0ZWQsIG9yIG5vdCB0cmVhdGVkIGFzIGludGVnZXJzDQogIChlZyByZXR1cm5l ZCBieSBhbiBBUEkgb25seSBhcyBhIGRvdWJsZSkuDQoNCiAgTm90ZTogMioqNTMgPSA5MDA3MTk5 MjU0NzQwOTkyDQoNCg0KLS0NCkphbWVzIE1hbmdlcg0KDQpGcm9tOiBqc29uLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpqc29uLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaW0gQnJh eQ0KU2VudDogV2VkbmVzZGF5LCAyNSBTZXB0ZW1iZXIgMjAxMyA4OjIxIEFNDQpUbzogQ2Fyc3Rl biBCb3JtYW5uDQpDYzoganNvbkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtKc29uXSBBbGwgdGhv c2UgbnVtYmVyIGlkZWFzDQoNCkkgbWVhbnQgdG8gc2F5OiBPSywgYnV0IGl0IGZlZWxzIHRvIG1l IHRoYXQgdGhlcmXigJlzIGFuIGltcG9ydGFudCBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIG5vcm1h bCBiaW5hcnkvZGVjaW1hbCBmcmljdGlvbiB5b3UgZ2V0IHdpdGggMS4xLCBhbmQgdGhlIGd1YXJh bnRlZWQtYnJlYWthZ2UgeW914oCZcmUgZ2V0dGluZyB3aXRoIHRoZSBvdGhlcnMuICBGcmljdGlv biBub3QgZnJhY3Rpb24uDQoNCk9uIFR1ZSwgU2VwIDI0LCAyMDEzIGF0IDM6MDcgUE0sIFRpbSBC cmF5IDx0YnJheUB0ZXh0dWFsaXR5LmNvbTxtYWlsdG86dGJyYXlAdGV4dHVhbGl0eS5jb20+PiB3 cm90ZToNCk9uIFR1ZSwgU2VwIDI0LCAyMDEzIGF0IDI6NDMgUE0sIENhcnN0ZW4gQm9ybWFubiA8 Y2Fib0B0emkub3JnPG1haWx0bzpjYWJvQHR6aS5vcmc+PiB3cm90ZToNCkhvdyBhYm91dDoNCg0K UmVwcmVzZW50aW5nIG51bWJlcnMgdGhhdCBjYW5ub3QgYmUgZXhhY3RseSBlbmNvZGVkIGFzIGFu IElFRUUgNzU0OjIwMDggYmluYXJ5NjQgbnVtYmVyLCBzdWNoIGFzIDFFNDAwLCA5MDA3MTk5MjU0 NzQwOTkzLCAzLjE0MTU5MjY1MzU4OTc5MzIzODQ2MjY0MzM4MzI3OSwgb3IgZXZlbiAxLjEsIG1h eSBjYXVzZSBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zIGlmIHRoZSBhcHBsaWNhdGlvbiByZWxp ZXMgb24gdGhlIGRlY2ltYWxseSBlbmNvZGVkIEpTT04gbnVtYmVyIGJlaW5nIGV4YWN0bHkgcHJl c2VydmVkIGluIHRoZSBkZWNpbWFsLXRvLWJpbmFyeSBjb252ZXJzaW9uIGR1cmluZyB0aGUgZGVj b2RpbmcgcHJvY2Vzcy4NCg0KT0ssIGJ1dCBpdCBmZWVscyB0byBtZSB0aGF0IHRoZXJl4oCZcyBh biBpbXBvcnRhbnQgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBub3JtYWwgYmluYXJ5L2RlY2ltYWwg ZnJhY3Rpb24geW91IGdldCB3aXRoIDEuMSwgYW5kIHRoZSBndWFyYW50ZWVkLWJyZWFrYWdlIHlv deKAmXJlIGdldHRpbmcgd2l0aCB0aGUgb3RoZXJzLg0KDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0K DQo= --_000_255B9BB34FB7D647A506DC292726F6E115313A0FCDWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVh ZD48Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3Jk U2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+TXkgZ3Vl c3MgaXMgdGhhdCBuZWl0aGVyIDMuMTQxNTkyNjUzNTg5NzkzMjM4NDYyNjQzMzgzMjc5IG5vciAx LjEgY2F1c2UgaW50ZXJvcCBwcm9ibGVtcyAoaW4gZ2VuZXJhbCkuIEkgYXNzdW1lIChob3BlKSBi YXNpY2FsbHkgYWxsIEpTT04gcGFyc2VycyB3aWxsIHBhcnNlIGJvdGgsIGV2ZW4gaWYgdGhleSBh cHByb3hpbWF0ZSB0aGUgbnVtYmVyIGluIHRoZWlyIGludGVybmFsIGJpbmFyeSByZXByZXNlbnRh dGlvbi4gSSBkb3VidCB0aGF0IHJvdW5kaW5nIGNhdXNlcyBtYW55IGludGVyb3AgcHJvYmxlbXMg YXMgcm91bmRpbmcgY29tZXMgd2l0aCB0aGUgdGVycml0b3J5IHdoZW4gZGVhbGluZyB3aXRoIGZs b2F0cy4gRm9yIGluc3RhbmNlLCBlcXVhbGl0eSB0ZXN0aW5nIGlzIGFsbW9zdCBhbHdheXMgZG9k Z3kgd2l0aCBmbG9hdHMgKHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBKU09OIGlzIGludm9sdmVkKSwg YW5kICZsdDsgYW5kL29yICZndDsgc2hvdWxkIGJlIHVzZWQgaW5zdGVhZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPlBlcmhhcHMgc2F5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6IzFGNDk3RCc+wqAgSWYgeW91IGV4Y2hhbmdlIG51bWJlcnMgZXhwZWN0aW5nIG5vIG1vcmUg cHJlY2lzaW9uIG9yIHJhbmdlIHRoYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMxRjQ5N0QnPsKgIGF2YWlsYWJsZSB3aXRoIGFuIElFRUUgNjQtYml0IGRvdWJsZSAo ZWcgNTIgYml0cyBvZiBwcmVjaXNpb24sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjojMUY0OTdEJz7CoCB3aGljaCBpcyBhYm91dCAxNiBkZWNpbWFsIGRpZ2l0cyksIHRo ZW4gYSBKU09OIG51bWJlciB3aWxsIGJlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjojMUY0OTdEJz4gwqBpbnRlcm9wZXJhYmxlIGluIHRoZSBzZW5zZSB0aGF0IGltcGxl bWVudGF0aW9ucyB3aWxsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj MUY0OTdEJz4gwqBhcHByb3hpbWF0ZSB0aGUgbnVtYmVyIHdpdGhpbiB0aGUgZXhwZWN0ZWQgcHJl Y2lzaW9uLiBJZiB5b3UgZXhwZWN0PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjojMUY0OTdEJz4gwqBhIGdyZWF0ZXIgcHJlY2lzaW9uIG9yIHJhbmdlIHRoZW4gcHJvYmxl bXMgb2Ygcm91bmRpbmcgY2FuIGhhcHBlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5Gb3IgaW50ZWdlcnMsIG9uIHRoZSBvdGhlciBoYW5kLCB3ZSBuZWVkIGEgZGlmZmVyZW50IHdh cm5pbmcuIFBlcmhhcHM6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzFGNDk3RCc+wqAgSWYgeW91IGV4Y2hhbmdlIGFuIGludGVnZXIgeCwgd2hl cmUgLTIqKjUzICZsdDsgeCAmbHQ7IDIqKjUzLCBpbiBKU09OPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz4gwqB3aXRob3V0IGEgZnJhY3Rpb24gb3IgZXhw b25lbnQgcGFydCwgdGhlIG51bWJlciB3aWxsIGJlIGludGVyb3BlcmFibGU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgIGluIHRoZSBzZW5zZSB0aGF0 IG1vc3QgaW1wbGVtZW50YXRpb25zIHdpbGwgYWdyZWUgb24gdGhlIHZhbHVlIHByZWNpc2VseS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgIEludGVn ZXJzIG91dHNpZGUgdGhpcyByYW5nZSwgb3IgZXhwcmVzc2VkIHdpdGggZnJhY3Rpb24gb3IgZXhw b25lbnQgcGFydHMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0 OTdEJz7CoCBjYW4gZmFjZSBwcm9ibGVtcyBvZiBiZWluZyBhcHByb3hpbWF0ZWQsIG9yIG5vdCB0 cmVhdGVkIGFzIGludGVnZXJzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEJz7CoCAoZWcgcmV0dXJuZWQgYnkgYW4gQVBJIG9ubHkgYXMgYSBkb3VibGUpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7CoCBOb3RlOiAy Kio1MyA9IDkwMDcxOTkyNTQ3NDA5OTI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMxRjQ5N0QnPsKgIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFtZXMgTWFu Z2VyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4ganNv bi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86anNvbi1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBC ZWhhbGYgT2YgPC9iPlRpbSBCcmF5PGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIDI1IFNlcHRl bWJlciAyMDEzIDg6MjEgQU08YnI+PGI+VG86PC9iPiBDYXJzdGVuIEJvcm1hbm48YnI+PGI+Q2M6 PC9iPiBqc29uQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW0pzb25dIEFsbCB0aG9z ZSBudW1iZXIgaWRlYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkg bWVhbnQgdG8gc2F5OiBPSywgYnV0IGl0IGZlZWxzIHRvIG1lIHRoYXQgdGhlcmXigJlzIGFuIGlt cG9ydGFudCBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIG5vcm1hbCBiaW5hcnkvZGVjaW1hbCBmcmlj dGlvbiB5b3UgZ2V0IHdpdGggMS4xLCBhbmQgdGhlIGd1YXJhbnRlZWQtYnJlYWthZ2UgeW914oCZ cmUgZ2V0dGluZyB3aXRoIHRoZSBvdGhlcnMuJm5ic3A7IEZyaWN0aW9uIG5vdCBmcmFjdGlvbi48 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPk9uIFR1ZSwgU2VwIDI0LCAyMDEzIGF0IDM6MDcgUE0sIFRpbSBCcmF5ICZsdDs8YSBocmVm PSJtYWlsdG86dGJyYXlAdGV4dHVhbGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj50YnJheUB0ZXh0 dWFsaXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+T24gVHVlLCBTZXAgMjQsIDIwMTMgYXQgMjo0MyBQTSwgQ2Fyc3RlbiBCb3Jt YW5uICZsdDs8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2Fi b0B0emkub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48ZGl2Pjxk aXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+SG93IGFib3V0Ojxicj48YnI+UmVwcmVz ZW50aW5nIG51bWJlcnMgdGhhdCBjYW5ub3QgYmUgZXhhY3RseSBlbmNvZGVkIGFzIGFuIElFRUUg NzU0OjIwMDggYmluYXJ5NjQgbnVtYmVyLCBzdWNoIGFzIDFFNDAwLCA5MDA3MTk5MjU0NzQwOTkz LCAzLjE0MTU5MjY1MzU4OTc5MzIzODQ2MjY0MzM4MzI3OSwgb3IgZXZlbiAxLjEsIG1heSBjYXVz ZSBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zIGlmIHRoZSBhcHBsaWNhdGlvbiByZWxpZXMgb24g dGhlIGRlY2ltYWxseSBlbmNvZGVkIEpTT04gbnVtYmVyIGJlaW5nIGV4YWN0bHkgcHJlc2VydmVk IGluIHRoZSBkZWNpbWFsLXRvLWJpbmFyeSBjb252ZXJzaW9uIGR1cmluZyB0aGUgZGVjb2Rpbmcg cHJvY2Vzcy48bzpwPjwvbzpwPjwvcD48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+T0ssIGJ1dCBpdCBmZWVscyB0byBtZSB0aGF0IHRoZXJl4oCZcyBhbiBpbXBvcnRhbnQgZGlm ZmVyZW5jZSBiZXR3ZWVuIHRoZSBub3JtYWwgYmluYXJ5L2RlY2ltYWwgZnJhY3Rpb24geW91IGdl dCB3aXRoIDEuMSwgYW5kIHRoZSBndWFyYW50ZWVkLWJyZWFrYWdlIHlvdeKAmXJlIGdldHRpbmcg d2l0aCB0aGUgb3RoZXJzLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSc+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPkdyw7zDn2UsIENhcnN0ZW48bzpw PjwvbzpwPjwvcD48L2Jsb2NrcXVvdGU+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E115313A0FCDWSMSG3153Vsrv_-- From jorge@jorgechamorro.com Wed Sep 25 02:04:28 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E00821F9FF2 for ; Wed, 25 Sep 2013 02:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_SEX=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvef4FZFH9QY for ; Wed, 25 Sep 2013 02:04:22 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6B04621F9C46 for ; Wed, 25 Sep 2013 02:04:22 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id y10so5861089wgg.12 for ; Wed, 25 Sep 2013 02:04:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=uAmzqaH4rQQUoywOI51axVCiPUKLWyuPoi81VO8iMBY=; b=N/cBDQAWIK8ux8p4TuV24CKzIVvU0OsFW3PoW/yXPl0z/iOCLdqc5eZH9c/aNqk+Q6 jLxjYgtX8emOiW0Hrfe453Vuw/83fNamcwqxiLq1+CtYYRP+BkrCj1wJDVS/VIY2q1es mCQRbc9EeFU5FEbN2sOoKvG4M4eEyIjRFJ80W+QClzqMAf3PTtN8GJWcjBiRgOPPjYOX eGgfRyBf0ODAcYjS44bzGC2/ubCptNkHUNJbB0q/UNXgsbORosXZ6q8ufql8qaNaepLS EwjsmtvOqQzKSKf9XDnCcsUa1ssdqg1oayjwUL/Yws0+pDY1zVeKehQgnBm957Bcg/0z /+zg== X-Gm-Message-State: ALoCoQkVvIJyQvQ12YuMyN+Lvc+THfO2NEy2t5a/zKqwIgg0NCkJbU8QQ/RvZ6OCX77AGAezo3N3 X-Received: by 10.180.11.37 with SMTP id n5mr21732336wib.25.1380099859035; Wed, 25 Sep 2013 02:04:19 -0700 (PDT) Received: from [192.168.10.50] (160.Red-88-0-222.dynamicIP.rima-tde.net. [88.0.222.160]) by mx.google.com with ESMTPSA id ey4sm15671563wic.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 02:04:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115313A0FCD@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 25 Sep 2013 11:04:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <27FBA412-6BEB-45CC-A35D-01D17E725AFC@jorgechamorro.com> References: <29C29B1D-81DF-438D-AF3E-1631CECDC324@tzi.org> <689B99BA-783F-4A76-A9AA-49DD46224850@tzi.org> <255B9BB34FB7D647A506DC292726F6E115313A0FCD@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1085) Cc: Carsten Bormann , Tim Bray , "json@ietf.org" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2013 09:04:28 -0000 On 25/09/2013, at 06:19, Manger, James H wrote: > =20 > For integers, on the other hand, we need a different warning. Perhaps: > =20 > If you exchange an integer x, where -2**53 < x < 2**53, in JSON > without a fraction or exponent part, the number will be interoperable > in the sense that most implementations will agree on the value = precisely. > Integers outside this range, or expressed with fraction or exponent = parts, > can face problems of being approximated, or not treated as integers > (eg returned by an API only as a double). > =20 > Note: 2**53 =3D 9007199254740992 > =20 Even though that's ok, I'd prefer to see the +1 and the -1 after the -/+ = 2**53s. If not, people tend to think that 2**53 is ok too. If they see the +/-1 they'll remember it, if instead it's got to be = 'seen' by the less-than-s, it may easily pass unnoticed. --=20 ( Jorge )(); From tbray@textuality.com Wed Sep 25 17:02:01 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6E621F99F4 for ; Wed, 25 Sep 2013 17:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.993, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_SEX=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or4KFVb-Y6kM for ; Wed, 25 Sep 2013 17:01:56 -0700 (PDT) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD5211E8123 for ; Wed, 25 Sep 2013 17:01:55 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id x16so324438vbf.10 for ; Wed, 25 Sep 2013 17:01:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0IP9wMYK1BWW2251M0LJivAt1njwQI/UTH+ZLyznxYU=; b=a2cZ/ofu72tmZBSsTdBSDVfOape3xC+oB/O5sNff2hkpYWyE/1txfyNPuD3gDIV7xC k3lyKcW4eZ4KE1EpdMJomZGj1LEHduB2tSE6t2e9akYMbbIjEYoP/LTM9XJnCVsZiHI5 eAGQ4rIMHhps5ZWPCNdGuhe8kBD4EW9gqSllVjY1vRI3hrf4B+PnijpLt6r2nZSVpg9i T8G4QN+M5tZud5V1h2XGbq8XvTc5k6aPJgsAliDS1urAkCzg/QWagH/kqtoOX3A4cHNI CGO801czGhWYNDGS4I8/pdbgmAQcAyC4M3pauB7gj92bCWgdwd8sQqMkcXkxF1SrM6NR 3bog== X-Gm-Message-State: ALoCoQkmYnYhL93iXd3/9qaiLSoth2qy1EKnZ82tnZSIFO3s0uhjMiS+sVRvvLC0khOc4w+EFIQh MIME-Version: 1.0 X-Received: by 10.58.108.74 with SMTP id hi10mr36295965veb.14.1380153709472; Wed, 25 Sep 2013 17:01:49 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Wed, 25 Sep 2013 17:01:49 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115313A0FCD@WSMSG3153V.srv.dir.telstra.com> References: <29C29B1D-81DF-438D-AF3E-1631CECDC324@tzi.org> <689B99BA-783F-4A76-A9AA-49DD46224850@tzi.org> <255B9BB34FB7D647A506DC292726F6E115313A0FCD@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 25 Sep 2013 17:01:49 -0700 Message-ID: From: Tim Bray To: "Manger, James H" Content-Type: multipart/alternative; boundary=001a1130ca2e96bfd804e73e1326 Cc: Carsten Bormann , "json@ietf.org" Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 00:02:02 -0000 --001a1130ca2e96bfd804e73e1326 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m inclined to adopt James=E2=80=99 language here, edited to flow = more like the other cautions, but the =E2=80=9Cexpecting no more precision or range than = IEEE=E2=80=9D seems like about the right warning to give. On Tue, Sep 24, 2013 at 9:19 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > My guess is that neither 3.141592653589793238462643383279 nor 1.1 cause > interop problems (in general). I assume (hope) basically all JSON parsers > will parse both, even if they approximate the number in their internal > binary representation. I doubt that rounding causes many interop problems > as rounding comes with the territory when dealing with floats. For > instance, equality testing is almost always dodgy with floats (regardless > of whether JSON is involved), and < and/or > should be used instead.**** > > ** ** > > Perhaps say:**** > > If you exchange numbers expecting no more precision or range than**** > > available with an IEEE 64-bit double (eg 52 bits of precision,**** > > which is about 16 decimal digits), then a JSON number will be**** > > interoperable in the sense that implementations will**** > > approximate the number within the expected precision. If you expect**** > > a greater precision or range then problems of rounding can happen.**** > > ** ** > > ** ** > > For integers, on the other hand, we need a different warning. Perhaps:***= * > > ** ** > > If you exchange an integer x, where -2**53 < x < 2**53, in JSON**** > > without a fraction or exponent part, the number will be interoperable***= * > > in the sense that most implementations will agree on the value precisel= y. > **** > > Integers outside this range, or expressed with fraction or exponent > parts,**** > > can face problems of being approximated, or not treated as integers**** > > (eg returned by an API only as a double).**** > > ** ** > > Note: 2**53 =3D 9007199254740992**** > > **** > > ** ** > > --**** > > James Manger**** > > ** ** > > *From:* json-bounces@ietf.org [mailto:json-bounces@ietf.org] *On Behalf > Of *Tim Bray > *Sent:* Wednesday, 25 September 2013 8:21 AM > *To:* Carsten Bormann > *Cc:* json@ietf.org > *Subject:* Re: [Json] All those number ideas**** > > ** ** > > I meant to say: OK, but it feels to me that there=E2=80=99s an important > difference between the normal binary/decimal friction you get with 1.1, a= nd > the guaranteed-breakage you=E2=80=99re getting with the others. Friction= not > fraction.**** > > ** ** > > On Tue, Sep 24, 2013 at 3:07 PM, Tim Bray wrote:**= * > * > > On Tue, Sep 24, 2013 at 2:43 PM, Carsten Bormann wrote:***= * > > How about: > > Representing numbers that cannot be exactly encoded as an IEEE 754:2008 > binary64 number, such as 1E400, 9007199254740993, > 3.141592653589793238462643383279, or even 1.1, may cause interoperability > problems if the application relies on the decimally encoded JSON number > being exactly preserved in the decimal-to-binary conversion during the > decoding process.**** > > ** ** > > OK, but it feels to me that there=E2=80=99s an important difference betwe= en the > normal binary/decimal fraction you get with 1.1, and the > guaranteed-breakage you=E2=80=99re getting with the others.**** > > **** > > > Gr=C3=BC=C3=9Fe, Carsten**** > > ** ** > > ** ** > --001a1130ca2e96bfd804e73e1326 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I=E2=80=99m inclined to adopt James=E2=80=99 language here= , edited to flow more like the other cautions, but the =E2=80=9Cexpecting n= o more precision or range than IEEE=E2=80=9D seems like about the right war= ning to give.


On Tue, Sep 24, 2013 at 9:19 PM, Manger,= James H <James.H.Manger@team.telstra.com> wro= te:

My guess is t= hat neither 3.141592653589793238462643383279 nor 1.1 cause interop problems= (in general). I assume (hope) basically all JSON parsers will parse both, = even if they approximate the number in their internal binary representation= . I doubt that rounding causes many interop problems as rounding comes with= the territory when dealing with floats. For instance, equality testing is = almost always dodgy with floats (regardless of whether JSON is involved), a= nd < and/or > should be used instead.

=C2=A0

Perhaps say:=

=C2=A0 If you exchange numbers expecting no more precision = or range than

=C2=A0 available with= an IEEE 64-bit double (eg 52 bits of precision,

=C2=A0 which is about 16 decimal digits), then a JSON numbe= r will be

=C2=A0interoperable in t= he sense that implementations will

=C2=A0approximate the number within the expected precision= . If you expect

=C2=A0a greater p= recision or range then problems of rounding can happen.

=C2=A0

=C2=A0

For integers, on the othe= r hand, we need a different warning. Perhaps:

=C2=A0

= =C2=A0 If you exchange an integer x, where -2**53 < x < 2**53, in JSO= N

=C2=A0without a fraction or exponent part, the number will= be interoperable

=C2=A0 in the sen= se that most implementations will agree on the value precisely.

=C2=A0 Integers outside this range, or expressed with fract= ion or exponent parts,

=C2=A0 can f= ace problems of being approximated, or not treated as integers

=C2=A0 (eg returned by an API only as a double).<= /u>

=C2=A0

=C2=A0 Note: 2**53 =3D 9007199254740992

=C2=A0

=C2=A0

--

James Manger

=C2=A0=

F= rom: json-bounces@ietf.org [mailto:json-bounces@ietf.org] = On Behalf Of Tim Bray
Sent: Wednesday, 25 September 2013 8:21 AM
To: Carsten Bor= mann
Cc: json@= ietf.org
Subject: Re: [Json] All those number ideas=

=C2=A0<= /u>

I meant to say: OK, but it feels to me t= hat there=E2=80=99s an important difference between the normal binary/decim= al friction you get with 1.1, and the guaranteed-breakage you=E2=80=99re ge= tting with the others.=C2=A0 Friction not fraction.

=C2=A0

=C2=A0


--001a1130ca2e96bfd804e73e1326-- From tony@att.com Wed Sep 25 20:02:14 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00C821E8055 for ; Wed, 25 Sep 2013 20:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.482 X-Spam-Level: X-Spam-Status: No, score=-106.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZLD0ZDoimDE for ; Wed, 25 Sep 2013 20:02:08 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id AEEED11E8134 for ; Wed, 25 Sep 2013 20:02:07 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id fa3a3425.0.1833756.00-253.4886035.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 26 Sep 2013 03:02:07 +0000 (UTC) X-MXL-Hash: 5243a3af14f2fcb3-75be5f917b54fc9d50740ac175d100f4cb531cc6 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8Q327Co027279 for ; Wed, 25 Sep 2013 23:02:07 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8Q31wns027234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Sep 2013 23:02:02 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor) for ; Thu, 26 Sep 2013 03:01:47 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8Q31lPd009286 for ; Wed, 25 Sep 2013 23:01:47 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8Q31h7L009121 for ; Wed, 25 Sep 2013 23:01:46 -0400 Received: from [135.70.20.78] (vpn-135-70-20-78.vpn.west.att.com[135.70.20.78]) by maillennium.att.com (mailgw1) with ESMTP id <20130926030141gw1004nhode> (Authid: tony); Thu, 26 Sep 2013 03:01:43 +0000 X-Originating-IP: [135.70.20.78] Message-ID: <5243A394.1040502@att.com> Date: Wed, 25 Sep 2013 23:01:40 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "json@ietf.org" References: <29C29B1D-81DF-438D-AF3E-1631CECDC324@tzi.org> <689B99BA-783F-4A76-A9AA-49DD46224850@tzi.org> <255B9BB34FB7D647A506DC292726F6E115313A0FCD@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=Rv1y2laK c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=p7AKjx7tdKMA:10 a=sCfsyOEanakA:10 a=_ncfMxlqgsYA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=N659UExz7-8A:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=2ZWXRX9xR_UA:10 a=CFanRel66qMxHAIal5oA:9 a=pILNO] X-AnalysisOut: [xqGKmIA:10 a=LFlWfzvbt7EA:10 a=r2FO5AWLohUA:10] Subject: Re: [Json] All those number ideas X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 03:02:14 -0000 On 9/25/2013 8:01 PM, Tim Bray wrote: > I’m inclined to adopt James’ language here, edited to flow more like > the other cautions, but the “expecting no more precision or range than > IEEE” seems like about the right warning to give. I can live with James' language. Tony Hansen From internet-drafts@ietf.org Thu Sep 26 09:58:34 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5A121F9343; Thu, 26 Sep 2013 09:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hga1CT8v3Ord; Thu, 26 Sep 2013 09:58:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AAD21F9D44; Thu, 26 Sep 2013 09:58:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130926165817.29653.21861.idtracker@ietfa.amsl.com> Date: Thu, 26 Sep 2013 09:58:17 -0700 Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-rfc4627bis-04.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 16:58:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the JavaScript Object Notation Working Group = of the IETF. Title : The JSON Data Interchange Format Author(s) : Tim Bray Filename : draft-ietf-json-rfc4627bis-04.txt Pages : 14 Date : 2013-09-26 Abstract: JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tbray@textuality.com Thu Sep 26 10:00:30 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E595021E8099 for ; Thu, 26 Sep 2013 10:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx15BdXGJf2g for ; Thu, 26 Sep 2013 10:00:22 -0700 (PDT) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5613D21F9FA4 for ; Thu, 26 Sep 2013 09:59:59 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id f12so1063313vbg.11 for ; Thu, 26 Sep 2013 09:59:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=vlbkKs1Zv9+lq+YS5YKpX7O1mH1lD6y6RHH7k22LDJE=; b=gaoZlCICEl5KJ209BwNujNk56zpK2Sl3kDk3THSydhCfNg/Xlgz0wrDttsJcDrLdNE PZXmk71Y6CQLf2EG/2LuzeX+lZndZGU9EnOUqO7t2+7k6WjsFWw/35mMDJvhhs08qulg URX7em+xhdHZ3bNhY4bdUW/z6k1kvsumUcMqH13uQV86PIJtkaq5J+4+pZ77JsJJoV6F 6dw3GpJxu3TD+2QxPgJCZJ9/Aaa17+WGbP+y5GXLEBMF6FIv1QGgVN1NmixDasCIVJm9 Ad5DklPP85KHfymYLfobiDIjLMsfXFQL9+G4PSn6wAes+AS2JFnZYznebOdJ5gXY07jx vcFg== X-Gm-Message-State: ALoCoQn65BWDAaXbBzG+UovruQx2tf4JyDo8P99I684nGM/j8MYxjYW/nNNcdGoxsY6KlSa6NvrZ MIME-Version: 1.0 X-Received: by 10.58.134.16 with SMTP id pg16mr1514619veb.21.1380214798643; Thu, 26 Sep 2013 09:59:58 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 26 Sep 2013 09:59:58 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <20130926165817.29653.83100.idtracker@ietfa.amsl.com> References: <20130926165817.29653.83100.idtracker@ietfa.amsl.com> Date: Thu, 26 Sep 2013 09:59:58 -0700 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=089e01294920c9915204e74c4ca2 Subject: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-04.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 17:00:30 -0000 --089e01294920c9915204e74c4ca2 Content-Type: text/plain; charset=UTF-8 I think this catches up with the state of WG discussion. -T ---------- Forwarded message ---------- From: Date: Thu, Sep 26, 2013 at 9:58 AM Subject: New Version Notification for draft-ietf-json-rfc4627bis-04.txt To: Tim Bray A new version of I-D, draft-ietf-json-rfc4627bis-04.txt has been successfully submitted by Tim Bray and posted to the IETF repository. Filename: draft-ietf-json-rfc4627bis Revision: 04 Title: The JSON Data Interchange Format Creation date: 2013-09-26 Group: json Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-04.txt Status: http://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis Htmlized: http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-rfc4627bis-04 Abstract: JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --089e01294920c9915204e74c4ca2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this catches up with the state of WG discussion. -= T

---------- Forwarded message -----= -----
From: <internet-drafts@ietf.org>
Date: Thu, Sep 26, 2013 at 9:58 AM
Subject: New Version Notification for= draft-ietf-json-rfc4627bis-04.txt
To: Tim Bray <tbray@textuality.com>



A new version of I-D, draft-ietf-json-rfc4627bis-04.txt
has been successfully submitted by Tim Bray and posted to the
IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-json-rfc4627bis
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A004
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The JSON Data Interchange Format<= br> Creation date: =C2=A0 2013-09-26
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 json
Number of pages: 14
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 htt= p://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-04.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatracker.= ietf.org/doc/draft-ietf-json-rfc4627bis
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html= /draft-ietf-json-rfc4627bis-04
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://w= ww.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-04

Abstract:
=C2=A0 =C2=A0JavaScript Object Notation (JSON) is a lightweight, text-based= ,
=C2=A0 =C2=A0language-independent data interchange format. =C2=A0It was der= ived from
=C2=A0 =C2=A0the ECMAScript Programming Language Standard. =C2=A0JSON defin= es a small
=C2=A0 =C2=A0set of formatting rules for the portable representation of str= uctured
=C2=A0 =C2=A0data.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--089e01294920c9915204e74c4ca2-- From mamille2@cisco.com Thu Sep 26 10:16:45 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2ED121F8F24 for ; Thu, 26 Sep 2013 10:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ct0q80c1yH3 for ; Thu, 26 Sep 2013 10:16:37 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2C521F9AD5 for ; Thu, 26 Sep 2013 10:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6615; q=dns/txt; s=iport; t=1380215676; x=1381425276; h=from:to:subject:date:message-id:mime-version; bh=GAFdPZsOW4k+JL8cGgwb8Wy+QeYp1Rhp+iBEwKPfEnY=; b=AZ9LgqHa7hTU1YAsaZBoSqrQiNGCmYJdUiMJ1C6NiMoyrZCzC8BfztHH bQF+1DLwv3ymdTSAUi5lsvVATxg9R6JmfAauKHKrksy3v0F4Q+rsarIoj Mc2j9gSf2LyBMqETILMHl2XSvnjMEzT2qNeNsba/AM7L6QjAZoPvZkp5H g=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFADRqRFKtJV2d/2dsb2JhbABbgwc4UsBUgSAWdIInAQRuHQEqJjAnBBsGh3ibCqFHjyCDVYEBA5AngS+HVpBJgySCKg X-IronPort-AV: E=Sophos;i="4.90,986,1371081600"; d="p7s'?scan'208";a="264921286" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 26 Sep 2013 17:14:36 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8QHEZf4031586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Sep 2013 17:14:35 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.253]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 12:14:35 -0500 From: "Matt Miller (mamille2)" To: JSON WG Thread-Topic: Working Group Last Call of draft-ietf-json-rfc4627bis-04 Thread-Index: AQHOutveYZPkp5J8/EuBThMG3Fu+pw== Date: Thu, 26 Sep 2013 17:14:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.48] Content-Type: multipart/signed; boundary="Apple-Mail=_95204221-5B4B-4CD7-B589-7B3B67FD3E79"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [Json] Working Group Last Call of draft-ietf-json-rfc4627bis-04 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 17:16:45 -0000 --Apple-Mail=_95204221-5B4B-4CD7-B589-7B3B67FD3E79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello All, This message begins the Working Group Last Call (WGLC) on "The JSON Data = Interchange Format" < draft-ietf-json-rfc4627bis-04 >. WGLC will end in = two weeks, on October 11. Please review the document and send comments to the Working Group = mailing list < json at ietf.org > or the co-chairs before the end of the WGLC. Note that suggested = changes which include proposed text will be more strongly considered = than those without. Thanks, - Paul Hoffman and Matt Miller --Apple-Mail=_95204221-5B4B-4CD7-B589-7B3B67FD3E79 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5MjYxNzE0 MzVaMCMGCSqGSIb3DQEJBDEWBBTxrJZqKHSjmW4EP2qS8r8k9GijpzCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBACfp pgPpapJ5/EGlrSt6h3lWkIHrBNPqN0uQ3Pr4Jx+PrYDGj/kDe/7FDEqpQ95ar4gUg71q4blkMvl4 vJAUPeK5MtOf0N3qUm7dxdsQMXmVgE+9Epte9xUI7IQDijJnRAKX7MFj0yhzEsVablphe29/Y7Rd F2Xl0pvIjBX+Rkdwb+Z8uli4i25bMk/wNRS7LaA5vLOnB+AS68DnEQZgvsI9LbTw6fo1Df+DrBEk 0t/8rqlFYrIAYJ1TBE2SUpIb6YcU9KXe337WObp18G3ZVVzvBayd70bpSez9tdvli2q5nNw6z1d0 wC9iNcuFe4Ld/DEFbtqhk6h86TssPEPphu0AAAAAAAA= --Apple-Mail=_95204221-5B4B-4CD7-B589-7B3B67FD3E79-- From sayrer@gmail.com Thu Sep 26 10:31:22 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4863521F9FB0 for ; Thu, 26 Sep 2013 10:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bY+n-t4PbgC for ; Thu, 26 Sep 2013 10:31:21 -0700 (PDT) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 05BCC21F9E5A for ; Thu, 26 Sep 2013 10:31:20 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id i11so1028997qej.39 for ; Thu, 26 Sep 2013 10:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T6gYByn8YDleuYdlUiIWWxaflm4jQu5uo56TLACt0X8=; b=jLpGmaFpWEiP8EzpU98QfQLqIs4odsm3XMujEMXZDSn3hQYhJpO2wemH44u13kBVQB ufVwAT9JgalppbDUDI+Nv0QGWvAomrYn+WRO8/iO2JOrSBL2R+QLs6oKp6rS3enUT145 E2J3d5r6qIByNFDQ1OfDUUSet1f/H/vEYcOSy0/ZVRyKQRbvk+i31OaI+J4qpFuRYgxg G8erUNmDtvCwNPf60D8hwKMDUknga3PSwfIzHiXSMsn+ycMUIqAziz8cIz//E+GmJtfN 6TgOv4/2NX8P679HZESY2oWUtedf0oaxk02g9FInQwEF+Zk1H5ualj8FdHAFg5nf7nI5 J6Vg== MIME-Version: 1.0 X-Received: by 10.224.167.18 with SMTP id o18mr8031837qay.87.1380216677637; Thu, 26 Sep 2013 10:31:17 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Thu, 26 Sep 2013 10:31:17 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Sep 2013 10:31:17 -0700 Message-ID: From: R S To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=089e01294f5ac8de2204e74cbcce Cc: JSON WG Subject: Re: [Json] Working Group Last Call of draft-ietf-json-rfc4627bis-04 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 17:31:22 -0000 --089e01294f5ac8de2204e74cbcce Content-Type: text/plain; charset=ISO-8859-1 Charter: > > All differences between RFC 4627 or the current ECMAScript specification > will be documented in the new RFC. The ECMAScript specification allows primitives at the root level, specifies exactly how to interpret numbers, and can handle " bit sequences which cannot encode Unicode characters" just fine. Other issues: I don't think we've seen a JSON implementation "suffer fatal runtime exceptions" in the presence of the aforementioned bit sequences. Carsten showed the Python 3 print function throwing an exception, but its standard JSON module parsed and then stringified them without error. I don't think there is a rationale for the text on -0.0. Is it for non-IEE754 implementations? - Rob On Thu, Sep 26, 2013 at 10:14 AM, Matt Miller (mamille2) wrote: > Hello All, > > This message begins the Working Group Last Call (WGLC) on "The JSON Data > Interchange Format" < draft-ietf-json-rfc4627bis-04 >. WGLC will end in > two weeks, on October 11. > > Please review the document and send comments to the Working Group mailing > list < json at ietf.org > or the co-chairs before the end of the WGLC. Note that suggested changes which include > proposed text will be more strongly considered than those without. > > > Thanks, > > - Paul Hoffman and Matt Miller > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --089e01294f5ac8de2204e74cbcce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Charter:
>
> All differences between RFC 4627 or the current=A0ECMAScript specification > will be docu= mented in the new RFC.

The ECMAScript specification allows primitives at the root= level, specifies exactly how to interpret numbers, and can handle " bit sequences w= hich cannot encode Unicode characters" just fine.

Other issues:

<= /span>
I don't thin= k we've seen a JSON implementation "suffer fatal runtime exceptions"= in the presence of the aforementioned bit sequences. Carsten showed the Py= thon 3 print function throwing an exception, but its standard JSON module p= arsed and then stringified them without error.

I don= 9;t think there is a rationale for the text on -0.0. Is it for non-IEE754 i= mplementations?

- Rob



On Thu, Sep 26, 2013 at 10:14 AM, Matt Miller (mamille2) <mamille2@= cisco.com> wrote:
Hello All,

This message begins the Working Group Last Call (WGLC) on "The JSON Da= ta Interchange Format" < draft-ietf-json-rfc4627bis-04 >. =A0WGL= C will end in two weeks, on October 11.

Please review the document and send comments to the Working Group mailing l= ist < json at ietf.org= > or the co-chairs <json-chairs at tools.ietf.org > before the end of the WGLC. =A0N= ote that suggested changes which include proposed text will be more strongl= y considered than those without.


Thanks,

- Paul Hoffman and Matt Miller


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


--089e01294f5ac8de2204e74cbcce-- From tbray@textuality.com Thu Sep 26 11:14:14 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD4711E80DE for ; Thu, 26 Sep 2013 11:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.763 X-Spam-Level: X-Spam-Status: No, score=-2.763 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3fAp6wCNW6C for ; Thu, 26 Sep 2013 11:14:06 -0700 (PDT) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id BE5C921F9FEE for ; Thu, 26 Sep 2013 11:14:06 -0700 (PDT) Received: by mail-vb0-f49.google.com with SMTP id w16so1103885vbb.8 for ; Thu, 26 Sep 2013 11:14:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CSYZrc8vM9xqFNmDgvm62DvLKfzq0t5AoBfP39l/jfw=; b=UGgvqeVIxiIVqsANQwTltrdiFihHzriYOVtIvvb5GhqODa5Qq6dbzigRfs+j92uc6+ ep+g8qyT7AN0Sf6QiTtanQkxosAfV3o2sy1c5UZx2Po2pzpHK93rLuzKj8M9kzSxYe5g weSVSbYArs1DOXzdJt2R+tFXemUp9vAgWFoT2vThfbAUIMiZJkCoWBLZGZ/8x7syAWBA qvCXdLOlR9eLepnPDEM5wNYKdY2MZtOhSx0UlHyDBm5jq6gjAOFbtQn9kn5NvaMj7quP N9VE165DdwfIVz4r5n0gunj1AsYHd2oE5rY8y59LipGlFM/50Z+H/r1TWELCvyUy5REl T3pQ== X-Gm-Message-State: ALoCoQnjE/EklBXoEEIPngf3KgjyUDfiXy2mLBUI/Yp2dr2nKSxEjvVc+sZPQlaQLDSFNj6Fhmkj MIME-Version: 1.0 X-Received: by 10.58.67.9 with SMTP id j9mr1826396vet.3.1380219245856; Thu, 26 Sep 2013 11:14:05 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 26 Sep 2013 11:14:05 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: Date: Thu, 26 Sep 2013 11:14:05 -0700 Message-ID: From: Tim Bray To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=047d7b339e07dca4c804e74d5591 Cc: JSON WG Subject: Re: [Json] Working Group Last Call of draft-ietf-json-rfc4627bis-04 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:14:14 -0000 --047d7b339e07dca4c804e74d5591 Content-Type: text/plain; charset=UTF-8 A real HTML version is at https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-04.html On Thu, Sep 26, 2013 at 10:14 AM, Matt Miller (mamille2) wrote: > Hello All, > > This message begins the Working Group Last Call (WGLC) on "The JSON Data > Interchange Format" < draft-ietf-json-rfc4627bis-04 >. WGLC will end in > two weeks, on October 11. > > Please review the document and send comments to the Working Group mailing > list < json at ietf.org > or the co-chairs before the end of the WGLC. Note that suggested changes which include > proposed text will be more strongly considered than those without. > > > Thanks, > > - Paul Hoffman and Matt Miller > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --047d7b339e07dca4c804e74d5591 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 26, 2013 at 10:14 AM, Matt Miller (mamille2) = <mamille2@cisco.= com> wrote:
Hello All,

This message begins the Working Group Last Call (WGLC) on "The JSON Da= ta Interchange Format" < draft-ietf-json-rfc4627bis-04 >. =C2=A0= WGLC will end in two weeks, on October 11.

Please review the document and send comments to the Working Group mailing l= ist < json at ietf.org= > or the co-chairs <json-chairs at tools.ietf.org > before the end of the WGLC. =C2= =A0Note that suggested changes which include proposed text will be more str= ongly considered than those without.


Thanks,

- Paul Hoffman and Matt Miller


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


--047d7b339e07dca4c804e74d5591-- From tbray@textuality.com Thu Sep 26 11:19:21 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73D321F9433 for ; Thu, 26 Sep 2013 11:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IX8bOllP8vO for ; Thu, 26 Sep 2013 11:19:16 -0700 (PDT) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id 04CBF21E80AA for ; Thu, 26 Sep 2013 11:18:16 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id x16so1137569vbf.10 for ; Thu, 26 Sep 2013 11:18:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ALcIp2HeJzzOxyf3BsKoXJlXZAtK6SXDnitsG7AAKYg=; b=QLG+18Y+xyjPFnxjFfRN4tATTYMGyiAj0sbW7Ct8507ACSkFOLm5b8m8ANw5lTbNeW /KPY1eMih0f/co3/v1K8eNYrSQT1mEHVURhLwM8j2S4oH6dxRu8Q/ZbpRcHHmxnyXXK7 5gMM5Y0HYgIFssJpOLWK0kChv2WfPYtBZ4GfOMYLXiymg/qPX1XAD0bn9wop3c8/kYen cPxpua398ycnGXHj6jc5+oyjzXCHFnkB03Z6TMXfV77Wt4jgYEiCDyRD52YNl5yZ59md cqiIMZDCBAHIkLurJPco4VBb/3nRUIv+GaBeR89iwYGeXDzcyqAmSKyJpS17wxfsYJM2 0s6w== X-Gm-Message-State: ALoCoQmEmhS/98ltDqtlrdd28GIRokeGM6GB3ybgXTA//AVytEu5MJxNugsFAgKsfcDxghMCQpGu MIME-Version: 1.0 X-Received: by 10.52.170.136 with SMTP id am8mr1537613vdc.33.1380219495142; Thu, 26 Sep 2013 11:18:15 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 26 Sep 2013 11:18:15 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <1BB38F24-8147-417B-9A48-B9D96A12770C@vpnc.org> References: <1BB38F24-8147-417B-9A48-B9D96A12770C@vpnc.org> Date: Thu, 26 Sep 2013 11:18:15 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=e89a8ff24c75b86a6604e74d6495 Cc: Barry Leiba , "json@ietf.org" Subject: Re: [Json] Small ABNF change to do some semantic separation X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:19:22 -0000 --e89a8ff24c75b86a6604e74d6495 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just noticed that I didn=E2=80=99t do anything on this in the -04 draft. O= n the other hand, this thread is pretty short and doing so might have been overreach. Speak up if you care. On Mon, Sep 23, 2013 at 8:55 AM, Paul Hoffman wrote= : > > > On Sep 22, 2013, at 10:26 AM, Tim Bray wrote: > > > I completely agree with Barry=E2=80=99s objective here. I had thought = one could > unambiguously refer to all the parts of a JSON text using various > combinations of object, array, string, number, boolean, member, member > name, and member value, e.g. =E2=80=9Cnumber array value=E2=80=9D and =E2= =80=9Cboolean member value=E2=80=9D > > > > But if I'm wrong let=E2=80=99s fix that. Rather than twiddling the ABN= F, > though, we could also just introduce a small =E2=80=9Cterminology=E2=80= =9D section. Let me > write up a couple paras and we=E2=80=99ll see how it looks. > > The terminology section seems like a much safer idea than changing the > ABNF. Having said that, the "implementation guidance" document that many > people have proposed as a later work item would probably be a better plac= e > for such a section, and we are not in a rush for that text. > > --Paul Hoffman --e89a8ff24c75b86a6604e74d6495 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just noticed that I didn=E2=80=99t do anything on this in = the -04 draft.=C2=A0 On the other hand, this thread is pretty short and doi= ng so might have been overreach.=C2=A0 Speak up if you care.


On Mon, Sep 23, 2013 at 8:55 AM, Paul Ho= ffman <paul.hoffman@vpnc.org> wrote:
<no hat>

On Sep 22, 2013, at 10:26 AM, Tim Bray <tbray@textuality.com> wrote:

> I completely agree with Barry=E2=80=99s objective here. =C2=A0I had th= ought one could unambiguously refer to all the parts of a JSON text using v= arious combinations of object, array, string, number, boolean, member, memb= er name, and member value, e.g. =E2=80=9Cnumber array value=E2=80=9D and = =E2=80=9Cboolean member value=E2=80=9D
>
> But if I'm wrong let=E2=80=99s fix that. =C2=A0Rather than twiddli= ng the ABNF, though, we could also just introduce a small =E2=80=9Cterminol= ogy=E2=80=9D section. =C2=A0Let me write up a couple paras and we=E2=80=99l= l see how it looks.

The terminology section seems like a much safer idea than changing th= e ABNF. Having said that, the "implementation guidance" document = that many people have proposed as a later work item would probably be a bet= ter place for such a section, and we are not in a rush for that text.

--Paul Hoffman

--e89a8ff24c75b86a6604e74d6495-- From barryleiba.mailing.lists@gmail.com Thu Sep 26 11:24:47 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8879A21F9CA4 for ; Thu, 26 Sep 2013 11:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.038 X-Spam-Level: X-Spam-Status: No, score=-102.038 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNnnrvJrij7a for ; Thu, 26 Sep 2013 11:24:47 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 00F4021F8503 for ; Thu, 26 Sep 2013 11:24:26 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id gd11so1130536vcb.5 for ; Thu, 26 Sep 2013 11:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=US6fHWhDnwYc7r7p+s412UKdFwh/+IePLm4hYc2kLhw=; b=r7cDA0C4OBH/P2C9RqpoJutbskeLsJoWuzXBOjw899j3I43w46pYdVSIwoNlStX2ki enSq2WkKQoLNoDleHlOfz9TvTrtBG643lTi8eOL64/IF7mZGKsFJTBIRYS6270vZXAgx dEgkL7hBZP8CvPSM1/EtGz5TTUMRuxbs9jEDlc4Ez3IOOJeXqPa4rdaUmgFEc07bMXpe l+F/Gs1g/ZHmuYbO4uGYQP85l0H2Hit7jQhqBVjK+edPnw1wVKtqC2ycIHsmMDbH+YU6 GXSCDecgJ1gCHbcbdN8fntx3wNY/g/gKLdPfFre3dlvuxTOsuLHcYQ3ZMsu/uHa0bQNq qiuw== MIME-Version: 1.0 X-Received: by 10.220.43.19 with SMTP id u19mr1844855vce.3.1380219866347; Thu, 26 Sep 2013 11:24:26 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.215.16 with HTTP; Thu, 26 Sep 2013 11:24:26 -0700 (PDT) In-Reply-To: References: <1BB38F24-8147-417B-9A48-B9D96A12770C@vpnc.org> Date: Thu, 26 Sep 2013 14:24:26 -0400 X-Google-Sender-Auth: OqWV0qYH7hqaHsMlVMSnnqoZgGE Message-ID: From: Barry Leiba To: Tim Bray Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Small ABNF change to do some semantic separation X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:24:47 -0000 > Just noticed that I didn=92t do anything on this in the -04 draft. On th= e > other hand, this thread is pretty short and doing so might have been > overreach. Speak up if you care. I'll just say that I think the ABNF change that I suggested is simple and not risky... but I won't pursue it further if the WG doesn't want to do it. I can write a "representing things in JSON" document more easily and nicely with such a change, but I can do it without that change also, so I'm not waving my arms wildly and screaming. Barry > On Mon, Sep 23, 2013 at 8:55 AM, Paul Hoffman wro= te: >> >> >> >> On Sep 22, 2013, at 10:26 AM, Tim Bray wrote: >> >> > I completely agree with Barry=92s objective here. I had thought one c= ould >> > unambiguously refer to all the parts of a JSON text using various >> > combinations of object, array, string, number, boolean, member, member= name, >> > and member value, e.g. =93number array value=94 and =93boolean member = value=94 >> > >> > But if I'm wrong let=92s fix that. Rather than twiddling the ABNF, >> > though, we could also just introduce a small =93terminology=94 section= . Let me >> > write up a couple paras and we=92ll see how it looks. >> >> The terminology section seems like a much safer idea than changing the >> ABNF. Having said that, the "implementation guidance" document that many >> people have proposed as a later work item would probably be a better pla= ce >> for such a section, and we are not in a rush for that text. >> >> --Paul Hoffman > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From cowan@ccil.org Thu Sep 26 11:25:15 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF6A21F8503 for ; Thu, 26 Sep 2013 11:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.193 X-Spam-Level: X-Spam-Status: No, score=-3.193 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ou4sBDuDYqK9 for ; Thu, 26 Sep 2013 11:25:07 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id B66D621F88B4 for ; Thu, 26 Sep 2013 11:25:05 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VPGFI-0004RT-4D; Thu, 26 Sep 2013 14:25:00 -0400 Date: Thu, 26 Sep 2013 14:25:00 -0400 From: John Cowan To: Tim Bray Message-ID: <20130926182500.GE12171@mercury.ccil.org> References: <1BB38F24-8147-417B-9A48-B9D96A12770C@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Barry Leiba , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Small ABNF change to do some semantic separation X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:25:15 -0000 Tim Bray scripsit: > Just noticed that I didn’t do anything on this in the -04 draft. On the > other hand, this thread is pretty short and doing so might have been > overreach. Speak up if you care. +1. Cool ABNF Rule Names Don't Change. -- Values of beeta will give rise to dom! John Cowan (5th/6th edition 'mv' said this if you tried http://www.ccil.org/~cowan to rename '.' or '..' entries; see cowan@ccil.org http://cm.bell-labs.com/cm/cs/who/dmr/odd.html) From paul.hoffman@vpnc.org Thu Sep 26 11:36:03 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D8A21F9E54 for ; Thu, 26 Sep 2013 11:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id affQ6sB9Lckr for ; Thu, 26 Sep 2013 11:36:02 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C1A9221F9343 for ; Thu, 26 Sep 2013 11:36:02 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8QIa0UB013828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Sep 2013 11:36:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Thu, 26 Sep 2013 11:36:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> References: To: JSON WG X-Mailer: Apple Mail (2.1510) Subject: [Json] Differences between RFC 4627 or the current ECMAScript specification X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:36:03 -0000 On Sep 26, 2013, at 10:31 AM, R S wrote: > Charter: > > > > All differences between RFC 4627 or the current ECMAScript = specification > will be documented in the new RFC. >=20 > The ECMAScript specification allows primitives at the root level, = specifies exactly how to interpret numbers, and can handle " bit = sequences which cannot encode Unicode characters" just fine. Based on what we have learned in the last six months, it might be better = for this RFC *not* to do what the charter says. - TC39 is actively revising ECMAScript and it is not clear whether the = -bis draft of their version will be out first. - Some of what ECMAscript says about JSON is intertwingled with the = definition of ECMAscript, such as "exactly how to interpret numbers" I'm no longer sure that a long-lasting RFC interpreting parts of another = SDO's spec is a good idea. --Paul Hoffman= From paul.hoffman@vpnc.org Thu Sep 26 11:38:21 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2833E21F9EFE for ; Thu, 26 Sep 2013 11:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ms6vn74r5eF3 for ; Thu, 26 Sep 2013 11:38:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B81E521F9E54 for ; Thu, 26 Sep 2013 11:38:20 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8QIcJlF013912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Sep 2013 11:38:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Thu, 26 Sep 2013 11:38:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <30C5C3AF-2CC7-44FA-A164-74B6F46E1E7F@vpnc.org> References: To: JSON WG X-Mailer: Apple Mail (2.1510) Subject: [Json] "suffer fatal runtime exceptions" X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:38:21 -0000 On Sep 26, 2013, at 10:31 AM, R S wrote: > I don't think we've seen a JSON implementation "suffer fatal runtime = exceptions" in the presence of the aforementioned bit sequences. Carsten = showed the Python 3 print function throwing an exception, but its = standard JSON module parsed and then stringified them without error. Suggested wording differences are appreciated. --Paul Hoffman= From paul.hoffman@vpnc.org Thu Sep 26 11:41:27 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F63C21F9F50 for ; Thu, 26 Sep 2013 11:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoDW+bnoRE94 for ; Thu, 26 Sep 2013 11:41:27 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0575C21F9F45 for ; Thu, 26 Sep 2013 11:41:25 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8QIfPY6014067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Sep 2013 11:41:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Thu, 26 Sep 2013 11:41:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> References: To: JSON WG X-Mailer: Apple Mail (2.1510) Subject: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:41:27 -0000 Numbers which represent zero without a sign, for example as 0 or 0.0 not -0 or -0.0, are interoperable in the sense that software implementations will agree on the zero value. Signed zeros are significant in some numerically-intensive applications, but implementations which read JSON texts cannot be relied upon to preserve that distinction. On Sep 26, 2013, at 10:31 AM, R S wrote: > I don't think there is a rationale for the text on -0.0. Is it for = non-IEE754 implementations? Do we need to state a rationale here, or does the text stand on its own? --Paul Hoffman From sayrer@gmail.com Thu Sep 26 11:48:27 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C1C21F9D53 for ; Thu, 26 Sep 2013 11:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOsrnQLSneTN for ; Thu, 26 Sep 2013 11:48:26 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7BE21E8087 for ; Thu, 26 Sep 2013 11:48:22 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id k4so1106512qaq.11 for ; Thu, 26 Sep 2013 11:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xPzA7SzyHKLl6QGGaRdxKNUEg4OKhoVEqccoBwfYhAE=; b=zJT+1D3eMJaoUdJg1BNeyPgxeRlEeMF68UBKjd/1Gq7MATNtxhJcb3BuCSXgTKXJq4 xMGA9I/2l5Qz47dPpkSXnKySfEgmyiSFsy8vVufoE5jgNud2N3AZR9OeGSijznz53eHR Z067AVePj8gLR3v3v/HU4OZVhuLczfNXpWDV9noGrtBBB5HybAThXDHFTb7KR0OBvNCb +stf9So/oJWCDLHLM4sxWyHYlGAJ5x99RyZLJ38/GH/tqhdCkibT11gt1EVLdskQ+Y/4 Qij2uACbxdgh3R/8bEqLYfhX4q1ggiwDiYES9npqnsimO5u20r3hHzDkbqxBtM3toBQy ljcg== MIME-Version: 1.0 X-Received: by 10.224.167.18 with SMTP id o18mr8508489qay.87.1380221299621; Thu, 26 Sep 2013 11:48:19 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Thu, 26 Sep 2013 11:48:19 -0700 (PDT) In-Reply-To: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> Date: Thu, 26 Sep 2013 11:48:19 -0700 Message-ID: From: R S To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e01294f5a46885404e74dd0ae Cc: JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:48:27 -0000 --089e01294f5a46885404e74dd0ae Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 26, 2013 at 11:41 AM, Paul Hoffman wrote: > Numbers which represent zero without a sign, for example as 0 or 0.0 > not -0 or -0.0, are interoperable in the sense that software > implementations will agree on the zero value. Signed zeros are > significant in some numerically-intensive applications, but > implementations which read JSON texts cannot be relied upon to > preserve that distinction. > > On Sep 26, 2013, at 10:31 AM, R S wrote: > > > I don't think there is a rationale for the text on -0.0. Is it for > non-IEE754 implementations? > > Do we need to state a rationale here, or does the text stand on its own? > > I meant that I don't see why it's in the draft at all. I propose deleting this paragraph, since I don't believe it is correct. Most implementations can be relied upon to preserve signed zeros. - Rob --089e01294f5a46885404e74dd0ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 26, 2013 at 11:41 AM, Paul Hoffman <pau= l.hoffman@vpnc.org> wrote:
=A0 =A0Numbers which represent zero without = a sign, for example as 0 or 0.0
=A0 =A0not -0 or -0.0, are interoperable in the sense that software
=A0 =A0implementations will agree on the zero value. =A0Signed zeros are =A0 =A0significant in some numerically-intensive applications, but
=A0 =A0implementations which read JSON texts cannot be relied upon to
=A0 =A0preserve that distinction.

On Sep 26, 2013, at 10:31 AM, R S <s= ayrer@gmail.com> wrote:

> I don't think there is a rationale for the text on -0.0. Is it for= non-IEE754 implementations?

Do we need to state a rationale here, or does the text stand on its own?

I meant that I don't see why it&#= 39;s in the draft at all. I propose deleting this paragraph, since I don= 9;t believe it is correct. Most implementations can be relied upon to prese= rve signed zeros.

- Rob=A0

--089e01294f5a46885404e74dd0ae-- From tbray@textuality.com Thu Sep 26 11:48:55 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0245321F9AE7 for ; Thu, 26 Sep 2013 11:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElLsZ1qU8Ohk for ; Thu, 26 Sep 2013 11:48:50 -0700 (PDT) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by ietfa.amsl.com (Postfix) with ESMTP id 0B30C21F8514 for ; Thu, 26 Sep 2013 11:48:49 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id i3so1142964vbh.26 for ; Thu, 26 Sep 2013 11:48:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mvtMDOsvChwgubeLifR2Ypj7+ekh1m+KN8SsqZdDqYs=; b=SDlhqkF781V250TmjBZkgWfYPg4ElSTkWHbJUtJ8P/rTkGdsIcBT7245Rvi2AVbfD7 MiTDda7x0oqfQ1OL0jQqhJWD9M7cGv86Ng5iH3qLMPXdIyypXr1JSQVKR61k8yXlP+QA VceEYkLo0xL3XzGOUinZGQvXKicm0V8SnlU+et8RgYBtwFi9oOKiDHZ83j5CtsCJfL03 NKm/2Rrlvryw+3cSfAdWCYUjNbUqiJprcf1rbGlgKvgPuKwJvLN+tmKZPDQWLdP7d8vx Jy1p8GRwtw6MrHtcUyNtJ34kl+TK4itPRYOjTCQq4GuNMm9fjSpeZ9Mc4wjbxjdg/J1a vLOA== X-Gm-Message-State: ALoCoQneK8b5skagk+VH2brexaK52vWtkgOfkQh8G6agoL3EbaNx9ow/jNgLW1LWJedP0swHWp4a MIME-Version: 1.0 X-Received: by 10.220.174.200 with SMTP id u8mr2004315vcz.6.1380221329373; Thu, 26 Sep 2013 11:48:49 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 26 Sep 2013 11:48:49 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> Date: Thu, 26 Sep 2013 11:48:49 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e0149ca3a0c931d04e74dd26b Cc: JSON WG Subject: Re: [Json] Differences between RFC 4627 or the current ECMAScript specification X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:48:55 -0000 --089e0149ca3a0c931d04e74dd26b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m with Rob on this one. There is de facto a stable ECMA spec that= has language defining JSON, the definition is different, and people who go and try to do some of the things it allows will likely have interoperability issues, so I=E2=80=99d put this in. Yeah, they might do another spec or sp= ecs but that wouldn't invalidate our reference to the existing one. On Thu, Sep 26, 2013 at 11:36 AM, Paul Hoffman wrote= : > On Sep 26, 2013, at 10:31 AM, R S wrote: > > > Charter: > > > > > > All differences between RFC 4627 or the current ECMAScript > specification > will be documented in the new RFC. > > > > The ECMAScript specification allows primitives at the root level, > specifies exactly how to interpret numbers, and can handle " bit sequence= s > which cannot encode Unicode characters" just fine. > > > > Based on what we have learned in the last six months, it might be better > for this RFC *not* to do what the charter says. > > - TC39 is actively revising ECMAScript and it is not clear whether the > -bis draft of their version will be out first. > > - Some of what ECMAscript says about JSON is intertwingled with the > definition of ECMAscript, such as "exactly how to interpret numbers" > > I'm no longer sure that a long-lasting RFC interpreting parts of another > SDO's spec is a good idea. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e0149ca3a0c931d04e74dd26b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I=E2=80=99m with Rob on this one. There is de facto a stab= le ECMA spec that has language defining JSON, the definition is different, = and people who go and try to do some of the things it allows will likely ha= ve interoperability issues, so I=E2=80=99d put this in.=C2=A0 Yeah, they mi= ght do another spec or specs but that wouldn't invalidate our reference= to the existing one.


On Thu,= Sep 26, 2013 at 11:36 AM, Paul Hoffman <paul.hoffman@vpnc.org>= wrote:
On Sep 26, 2013, at 10:31 AM, R S <sayrer@gmail.com> wrote:

> Charter:
> >
> > All differences between RFC 4627 or the current ECMAScript specif= ication > will be documented in the new RFC.
>
> The ECMAScript specification allows primitives at the root level, spec= ifies exactly how to interpret numbers, and can handle " bit sequences= which cannot encode Unicode characters" just fine.

<no hat>

Based on what we have learned in the last six months, it might be better fo= r this RFC *not* to do what the charter says.

- TC39 is actively revising ECMAScript and it is not clear whether the -bis= draft of their version will be out first.

- Some of what ECMAscript says about JSON is intertwingled with the definit= ion of ECMAscript, such as "exactly how to interpret numbers"

I'm no longer sure that a long-lasting RFC interpreting parts of anothe= r SDO's spec is a good idea.

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

--089e0149ca3a0c931d04e74dd26b-- From tbray@textuality.com Thu Sep 26 11:50:35 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA3B21F9AE7 for ; Thu, 26 Sep 2013 11:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Rkav94IsMmt for ; Thu, 26 Sep 2013 11:50:30 -0700 (PDT) Received: from mail-vb0-f42.google.com (mail-vb0-f42.google.com [209.85.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1412921F9991 for ; Thu, 26 Sep 2013 11:50:29 -0700 (PDT) Received: by mail-vb0-f42.google.com with SMTP id e12so1148424vbg.15 for ; Thu, 26 Sep 2013 11:50:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YCqoU0k5HKSMT7UWg7FJu/oVgSxJ9JwPlASgZQ31LrM=; b=BrOO+K/qcY1zdPEdzW6gWcZf2lRL9jobemqHv1UnT/pkpwwo8dTFxTwy+2wL9DuGz9 UxMZQfhTePr038ETrladGvtBICiNuE9jD/vax7beU8ktig/OL6xwr5n7dWgeZ8nYCEGF dDQ5+on6HnRHFOjhEzSLtjcrDfYgbIS0Vm1Lf34RYR2iFs/F1s+5+aiQsdEh6RjRl64b S3t5XhxituZhQmCSX+OM7dm7qoEr2PpAXXlPxVURnhCwtABbbES8IkGyOXzxvBGSuchb /sn0k4VYVyn83UpLmKhqvS2X9YAG+frmUEPTza5lJT0LE/HDhYjDrz7sRKH9H5uvSF9i hiqw== X-Gm-Message-State: ALoCoQkBNyuocVfGqfWZPDVADueECL7TASRdB84WeO5YDYKT/dSecoA5qg7JvnWVaEkFCwwIV32P MIME-Version: 1.0 X-Received: by 10.52.37.69 with SMTP id w5mr1621754vdj.32.1380221427494; Thu, 26 Sep 2013 11:50:27 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 26 Sep 2013 11:50:27 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> Date: Thu, 26 Sep 2013 11:50:27 -0700 Message-ID: From: Tim Bray To: R S Content-Type: multipart/alternative; boundary=20cf30780db0e5db5704e74dd7c7 Cc: Paul Hoffman , JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:50:35 -0000 --20cf30780db0e5db5704e74dd7c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, except for the very first thing I tried, a modern Ruby with the default "require 'json'", did not preserve the sign. I think Rob=E2=80=99s right that a large majority of modern implementations= do... is that enough reason to take out the caution? On Thu, Sep 26, 2013 at 11:48 AM, R S wrote: > On Thu, Sep 26, 2013 at 11:41 AM, Paul Hoffman wro= te: > >> Numbers which represent zero without a sign, for example as 0 or 0.0 >> not -0 or -0.0, are interoperable in the sense that software >> implementations will agree on the zero value. Signed zeros are >> significant in some numerically-intensive applications, but >> implementations which read JSON texts cannot be relied upon to >> preserve that distinction. >> >> On Sep 26, 2013, at 10:31 AM, R S wrote: >> >> > I don't think there is a rationale for the text on -0.0. Is it for >> non-IEE754 implementations? >> >> Do we need to state a rationale here, or does the text stand on its own? >> >> > I meant that I don't see why it's in the draft at all. I propose deleting > this paragraph, since I don't believe it is correct. Most implementations > can be relied upon to preserve signed zeros. > > - Rob > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --20cf30780db0e5db5704e74dd7c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, except for the very first thing I tried, a modern Ru= by with the default "require 'json'", did not preserve th= e sign.=C2=A0

I think Rob=E2=80=99s right that a large majority of = modern implementations do... is that enough reason to take out the caution?=


On Thu,= Sep 26, 2013 at 11:48 AM, R S <sayrer@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On Thu, Sep 26, 2013 at 11:41 AM, Paul H= offman <paul.hoffman@vpnc.org> wrote:
=C2=A0 =C2=A0Numbers which represent zero wi= thout a sign, for example as 0 or 0.0
=C2=A0 =C2=A0not -0 or -0.0, are interoperable in the sense that software =C2=A0 =C2=A0implementations will agree on the zero value. =C2=A0Signed zer= os are
=C2=A0 =C2=A0significant in some numerically-intensive applications, but =C2=A0 =C2=A0implementations which read JSON texts cannot be relied upon to=
=C2=A0 =C2=A0preserve that distinction.

On Sep 26, 2013, at 10:31 AM, R S <sayrer@gmail.com> wrote:

> I don't think there is a rationale for the text on -0.0. Is it for= non-IEE754 implementations?

Do we need to state a rationale here, or does the text stand on its own?

I meant that I don't see wh= y it's in the draft at all. I propose deleting this paragraph, since I = don't believe it is correct. Most implementations can be relied upon to= preserve signed zeros.

- Rob=C2=A0


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


--20cf30780db0e5db5704e74dd7c7-- From sayrer@gmail.com Thu Sep 26 11:51:02 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1994A21E8099 for ; Thu, 26 Sep 2013 11:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPufeGhXDUO0 for ; Thu, 26 Sep 2013 11:51:01 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6304921E80A6 for ; Thu, 26 Sep 2013 11:50:57 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id t7so1027609qcv.21 for ; Thu, 26 Sep 2013 11:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2gWFZQ/95a9IvvvrTy13vB7XLscaLFeijtKHITzg7OU=; b=BI8KQBAnw4NcpxRnJ2KkBBX8rFSRC2adpsPjnG8qC/vBEhKBAOG/+GTMH5ClrJ08wq 98w1XRiU8IRpeJavkFI4iXEMbpWbXdJ9ffxTyp+iGxcYH7oLwlcVjTsDBgbDsfZEk0ag bqybm9SqwejM14SECDgHXThFHw8xnJSvwmPvNQJUEn6iiPMjZ1rG0zQIEb2RKlkHpqyQ n2Y0AK+h33yv9orrPs/Z2qxT5kdSQt8n5gDSUd7vGcM4TY9IE+MgyEaohm6CMgWkv9En nT8ewSPLlK5tyUFWYhrqU8NxjXhNj3ncZxtYqNrHiJ6sKHrrkMLyujSwGtOEI1K/WOxk 0K5A== MIME-Version: 1.0 X-Received: by 10.49.81.237 with SMTP id d13mr3664991qey.44.1380221456409; Thu, 26 Sep 2013 11:50:56 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Thu, 26 Sep 2013 11:50:56 -0700 (PDT) In-Reply-To: <30C5C3AF-2CC7-44FA-A164-74B6F46E1E7F@vpnc.org> References: <30C5C3AF-2CC7-44FA-A164-74B6F46E1E7F@vpnc.org> Date: Thu, 26 Sep 2013 11:50:56 -0700 Message-ID: From: R S To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b6d99929eea3e04e74dd900 Cc: JSON WG Subject: Re: [Json] "suffer fatal runtime exceptions" X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:51:02 -0000 --047d7b6d99929eea3e04e74dd900 Content-Type: text/plain; charset=ISO-8859-1 Leave this part: However, the ABNF in this specification allows member names and string values to contain bit sequences which cannot encode Unicode characters, for example "\uDEAD" (a single unpaired UTF-16 surrogate). Instances of this have been observed, for example when a library truncates a UTF-16 string without checking whether the truncation split a surrogate pair. Remove this part: The behavior of software which receives JSON texts containing such values is unpredictable; for example, implementations might return different values for the length of a string value, or even suffer fatal runtime exceptions. - Rob On Thu, Sep 26, 2013 at 11:38 AM, Paul Hoffman wrote: > On Sep 26, 2013, at 10:31 AM, R S wrote: > > > I don't think we've seen a JSON implementation "suffer fatal runtime > exceptions" in the presence of the aforementioned bit sequences. Carsten > showed the Python 3 print function throwing an exception, but its standard > JSON module parsed and then stringified them without error. > > Suggested wording differences are appreciated. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b6d99929eea3e04e74dd900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Leave this part:

However, the ABNF in this specification allows member names an= d string values to contain bit sequences which cannot encode Unicode charac= ters, for example "\uDEAD" (a single unpaired UTF-16 surrogate). = Instances of this have been observed, for example when a library truncates = a UTF-16 string without checking whether the truncation split a surrogate p= air.=A0

Remove this p= art:

The beha= vior of software which receives JSON texts containing such values is unpred= ictable; for example, implementations might return different values for the= length of a string value, or even suffer fatal runtime exceptions.<= br>

- = Rob

=

On Thu, Sep 26, 2013 at 11:38 AM, Paul H= offman <paul.hoffman@vpnc.org> wrote:
On Sep 26, 2013, at 10:31 AM, R S <sayrer@gmail.com> wrote:

> I don't think we've seen a JSON implementation "suffer fa= tal runtime exceptions" in the presence of the aforementioned bit sequ= ences. Carsten showed the Python 3 print function throwing an exception, bu= t its standard JSON module parsed and then stringified them without error.<= br>
Suggested wording differences are appreciated.

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

--047d7b6d99929eea3e04e74dd900-- From lear@cisco.com Thu Sep 26 11:52:14 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F8A21E80AB for ; Thu, 26 Sep 2013 11:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.506 X-Spam-Level: X-Spam-Status: No, score=-110.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibwdEidJpwkB for ; Thu, 26 Sep 2013 11:52:09 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1F221E8094 for ; Thu, 26 Sep 2013 11:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1634; q=dns/txt; s=iport; t=1380221528; x=1381431128; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wM7JfkK1W4Ievkjx2ab72GMcpabmgqBuxEu3SuouUAk=; b=dXPQTgkSpLbKF3eU8E27wZvg9aD//cVBlmxCbQ+WAK4GY2WngfIW0mqF DI9iNM54/S9bzX30m3S+O6dn3TSQg7cx5MpulnNhtFj+xdK4Ltzk2ADrL mroat5dH4fouxT/7LDM4TKSrmVUXYVuulBVPyVSU7WLB5eGQBDL39Znaa 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFADGBRFKQ/khN/2dsb2JhbABbgweEM70qCoEgFnSCJQEBAQQjVQEQCxgCAgUWCwICCQMCAQIBKxoGDQEHAQGIAqokkkKBKY4oB4JogTYDl32ReIMmOg X-IronPort-AV: E=Sophos;i="4.90,987,1371081600"; d="scan'208";a="18308028" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 26 Sep 2013 18:52:07 +0000 Received: from mctiny.local ([10.61.168.117]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8QIq5kJ026697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Sep 2013 18:52:05 GMT Message-ID: <52448254.5090209@cisco.com> Date: Thu, 26 Sep 2013 20:52:04 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Hoffman References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> In-Reply-To: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: JSON WG Subject: Re: [Json] Differences between RFC 4627 or the current ECMAScript specification X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:52:15 -0000 Paul, On 9/26/13 8:36 PM, Paul Hoffman wrote: > I've got an IAB hat, and it involves this, but I am but a member of the IAB, and the below is my advice. > > Based on what we have learned in the last six months, it might be better for this RFC *not* to do what the charter says. This is a matter for Pete. He hinted at something about this in a previous message, but... > > - TC39 is actively revising ECMAScript and it is not clear whether the -bis draft of their version will be out first. > > - Some of what ECMAscript says about JSON is intertwingled with the definition of ECMAscript, such as "exactly how to interpret numbers" > > I'm no longer sure that a long-lasting RFC interpreting parts of another SDO's spec is a good idea. > > What I would suggest is that at the very least we understand the differences, so that we know what we're getting into. My understanding is that what is proposed in the latest draft is in line with what they've produced, although we provide interoperability guidance that is somewhat more constraining. Some eyes here would be good. If we agree on all of this, there is the question on whether or not the document should simply normatively reference ECMA. But I would only do this if we are agreed that the normative specifications are intended to be identical, and then I would think it a good idea (even though I'm entirely non-plussed by the approach taken by ECMA members), simply to avoid unintended differences. If, however, the working group has diverged intentionally, I would suggest that those differences be called out. Eliot From tbray@textuality.com Thu Sep 26 11:52:53 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7111821E80A7 for ; Thu, 26 Sep 2013 11:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.808 X-Spam-Level: X-Spam-Status: No, score=-2.808 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgpAtkHYUU7O for ; Thu, 26 Sep 2013 11:52:46 -0700 (PDT) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAC321E80AA for ; Thu, 26 Sep 2013 11:52:38 -0700 (PDT) Received: by mail-vb0-f43.google.com with SMTP id h11so1161232vbh.16 for ; Thu, 26 Sep 2013 11:52:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bEU5FlQpPOu40hDdWvDw7nIbMlF+yIgSecIbJej7eMc=; b=FuUPOQaB2UMK1k7yzZ+ASNPpG/0BaL2d56sAhq5zg6voAIosBeXT2z3+Z6B1aBfLGx hnKE5jttN1FgqAJDx6ZtcSwTg5R+Qw4h96pWM2aTk8l7vyqzABwTKLajsThidNmUWYP9 Ye5kCS8/mnnRvz1vg7ode8b2MBGmXYyuwj4weePCQnrNaF7oaG1Soq8YJHWybUtA/3+L EV/c6W5d1j8O7Yx2pw/S3Y8KxHsgHHhQjJZelevFy9FY+tIzKZFW1swc8o6RYUStoBR9 4U8qjIrpJt6+6TuO6cmfTvqDOdz4Iegtd8BiEIFNYGT8tlhEC2pg53Zh124KFgooE2gs D4Qg== X-Gm-Message-State: ALoCoQksPHqTxAhTlG6J6HkitHz7RA18h0D6ClkYmb396xuYLX47ga9Qu5TFp6fl5EP3MreXdRi7 MIME-Version: 1.0 X-Received: by 10.52.173.165 with SMTP id bl5mr1732935vdc.18.1380221558023; Thu, 26 Sep 2013 11:52:38 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 26 Sep 2013 11:52:37 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <30C5C3AF-2CC7-44FA-A164-74B6F46E1E7F@vpnc.org> References: <30C5C3AF-2CC7-44FA-A164-74B6F46E1E7F@vpnc.org> Date: Thu, 26 Sep 2013 11:52:37 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=bcaec51b9cfdad82c504e74ddfd5 Cc: JSON WG Subject: Re: [Json] "suffer fatal runtime exceptions" X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:52:53 -0000 --bcaec51b9cfdad82c504e74ddfd5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think we should leave this in; I speak as a person who has written quite a lot of low-level C code that, frankly, looking in the rearview mirror, I have no idea whether or not it'll silently work around, throw an orderly error, or blow up on a singleton \uDEAD. I suspect there=E2=80=99s a lot o= f that out there. On Thu, Sep 26, 2013 at 11:38 AM, Paul Hoffman wrote= : > On Sep 26, 2013, at 10:31 AM, R S wrote: > > > I don't think we've seen a JSON implementation "suffer fatal runtime > exceptions" in the presence of the aforementioned bit sequences. Carsten > showed the Python 3 print function throwing an exception, but its standar= d > JSON module parsed and then stringified them without error. > > Suggested wording differences are appreciated. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --bcaec51b9cfdad82c504e74ddfd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think we should leave this in; I speak as a person who h= as written quite a lot of low-level C code that, frankly, looking in the re= arview mirror, I have no idea whether or not it'll silently work around= , throw an orderly error, or blow up on a singleton \uDEAD.=C2=A0 I suspect= there=E2=80=99s a lot of that out there.


On Thu,= Sep 26, 2013 at 11:38 AM, Paul Hoffman <paul.hoffman@vpnc.org>= wrote:
On Sep 26, 2013, at 10:31 AM, R S <sayrer@gmail.com> wrote:

> I don't think we've seen a JSON implementation "suffer fa= tal runtime exceptions" in the presence of the aforementioned bit sequ= ences. Carsten showed the Python 3 print function throwing an exception, bu= t its standard JSON module parsed and then stringified them without error.<= br>
Suggested wording differences are appreciated.

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

--bcaec51b9cfdad82c504e74ddfd5-- From sayrer@gmail.com Thu Sep 26 11:52:54 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020EC21E80A7 for ; Thu, 26 Sep 2013 11:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ng+L1sKq72vW for ; Thu, 26 Sep 2013 11:52:53 -0700 (PDT) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBDD21E80A6 for ; Thu, 26 Sep 2013 11:52:48 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id a11so1114074qen.9 for ; Thu, 26 Sep 2013 11:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dR7VlwMj7NMEA00nBIpUVqUDVBoLOStMFrZBaIFZFYk=; b=PbI2MrBWJ+KVI7wOFGkINGLOb320vlyBWUcrh5lz8LynyHGjlCvAYiVG8oxiPE+OOD P3Z4H923M/NSMaDqsWa0rlMxKEITZFQ9P9ZaBd7BX1HdZz7mUMjoNtxLTYkjSAE3smws ksiIsk5t7yyRYaehh26zZPGwHInbKJtbvZmRgcjqENKdWZvKhAunJLlGwC+wjoogO7pw GPyO6sCbC6lYn37Wt2mu6OOz2HoIT4C36n3aCcYfan+w/BknlIDJp+EItQaZcsxf0WZ6 dDD/lv1mqbyOxim1HVn9Clii/P3W070KZNAU9+/RoW9jUI71iEj/xfgKJwQY2FoP8kiT WNbQ== MIME-Version: 1.0 X-Received: by 10.49.107.135 with SMTP id hc7mr3543624qeb.43.1380221567859; Thu, 26 Sep 2013 11:52:47 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Thu, 26 Sep 2013 11:52:47 -0700 (PDT) In-Reply-To: References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> Date: Thu, 26 Sep 2013 11:52:47 -0700 Message-ID: From: R S To: Tim Bray Content-Type: multipart/alternative; boundary=047d7bdc13ee4382e704e74de08c Cc: Paul Hoffman , JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:52:54 -0000 --047d7bdc13ee4382e704e74de08c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 26, 2013 at 11:50 AM, Tim Bray wrote: > Well, except for the very first thing I tried, a modern Ruby with the > default "require 'json'", did not preserve the sign. > I bet they would take a patch, though. I was wondering whether we were enshrining a bug in the spec or catering to other floating point implementations. - Rob --047d7bdc13ee4382e704e74de08c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 26, 2013 at 11:50 AM, Tim Bray <tbray@text= uality.com> wrote:
Well, except for the very f= irst thing I tried, a modern Ruby with the default "require 'json&= #39;", did not preserve the sign.=A0

I bet they would take a patch, thoug= h. I was wondering whether we were enshrining a bug in the spec or catering= to other floating point implementations.

- Rob
--047d7bdc13ee4382e704e74de08c-- From tbray@textuality.com Thu Sep 26 11:57:19 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D9121E80AD for ; Thu, 26 Sep 2013 11:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.817 X-Spam-Level: X-Spam-Status: No, score=-2.817 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHPfAdM7y4Zf for ; Thu, 26 Sep 2013 11:57:12 -0700 (PDT) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id C49B721E8094 for ; Thu, 26 Sep 2013 11:57:12 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id pa12so1265640veb.16 for ; Thu, 26 Sep 2013 11:57:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=C6dmY21FFj2oQJcriWsyaCSuG+lxbutkcfXFd/Y4SFk=; b=QzYAJ013KsRHvQwKW16c+kY6yI4/p7ojlfWhaHnv7SHVuOGjtBVjMfnNQU3HwqyWF8 EhwYSBkevZhvJ6XeWu0+cFP9ZdxZ52dzFk7eznOF6679xjlIlgv5wH71LNx0MdUccT2M 63WgTqM1A8Rdxhgd/O79Jfkuq89+TTvG5mMgUyloYC5RPFpxbU/I8IEarGbsI1neTLEh 8Yr+9KFQHnJ/7FVkPJM5anCjcvHs6uZVnwxpnHUuU2Exocj6DDtQBynks1Z0JO6xV2+a kkmf4fApJPeCNkGjQpijzcXAsuez9IAKoEVPmbm4Ccrj5iQukJegVsqHBxnG9ElmwBaD DOQw== X-Gm-Message-State: ALoCoQkMc1UUSf0+vy1CrfqNKjgxbIuSKNezTeh3iTKXPPrDFL9rtpQzJWSUlvgYiz+AglLaYiNX MIME-Version: 1.0 X-Received: by 10.58.190.34 with SMTP id gn2mr2008536vec.34.1380221832234; Thu, 26 Sep 2013 11:57:12 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 26 Sep 2013 11:57:12 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> Date: Thu, 26 Sep 2013 11:57:12 -0700 Message-ID: From: Tim Bray To: R S Content-Type: multipart/alternative; boundary=089e0158bee8059f3904e74df052 Cc: Paul Hoffman , JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:57:19 -0000 --089e0158bee8059f3904e74df052 Content-Type: text/plain; charset=UTF-8 Hm, I bet that there are languages that look at the JSON number and if there's no exp or frac parts, jam it into an integer; do modern *integer* implementations preserve negative zero? On Thu, Sep 26, 2013 at 11:52 AM, R S wrote: > On Thu, Sep 26, 2013 at 11:50 AM, Tim Bray wrote: > >> Well, except for the very first thing I tried, a modern Ruby with the >> default "require 'json'", did not preserve the sign. >> > > I bet they would take a patch, though. I was wondering whether we were > enshrining a bug in the spec or catering to other floating point > implementations. > > - Rob > --089e0158bee8059f3904e74df052 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hm, I bet that there are languages that look at the JSON n= umber and if there's no exp or frac parts, jam it into an integer; do m= odern *integer* implementations preserve negative zero?


On Thu, Sep 26, 2013 at 11:52 AM, R S <s= ayrer@gmail.com> wrote:
On Thu, Sep 26, 2013 at 11:50 AM, Tim Br= ay <tbray@textuality.com> wrote:
Well, except for the very f= irst thing I tried, a modern Ruby with the default "require 'json&= #39;", did not preserve the sign.=C2=A0

I bet they would take a patch,= though. I was wondering whether we were enshrining a bug in the spec or ca= tering to other floating point implementations.

- Rob

--089e0158bee8059f3904e74df052-- From cowan@ccil.org Thu Sep 26 12:31:30 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C933421E80AB for ; Thu, 26 Sep 2013 12:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.212 X-Spam-Level: X-Spam-Status: No, score=-3.212 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rfgmAnT91T2 for ; Thu, 26 Sep 2013 12:31:24 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id AEA5D11E8118 for ; Thu, 26 Sep 2013 12:31:12 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VPHHK-0002zO-F3; Thu, 26 Sep 2013 15:31:10 -0400 Date: Thu, 26 Sep 2013 15:31:10 -0400 From: John Cowan To: R S Message-ID: <20130926193110.GA8186@mercury.ccil.org> References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 19:31:31 -0000 R S scripsit: > I meant that I don't see why it's in the draft at all. I propose > deleting this paragraph, since I don't believe it is correct. An implementation written in C cannot be counted on to either produce or preserve sign on zero, at least not if it uses sscanf/sprintf, since they are not required to be IEEE-compliant. Indeed, few languages defined by spec (as opposed to by a unique or predominant implementation) require IEEE compliance. > Most implementations can be relied upon to preserve signed zeros. Evidence for this statement is lacking. -- Evolutionary psychology is the theory John Cowan that men are nothing but horn-dogs, http://www.ccil.org/~cowan and that women only want them for their money. cowan@ccil.org --Susan McCarthy (adapted) From cowan@ccil.org Thu Sep 26 12:36:37 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAA821E80BA for ; Thu, 26 Sep 2013 12:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFnxqGyb1YOk for ; Thu, 26 Sep 2013 12:36:32 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC1D21F9CC6 for ; Thu, 26 Sep 2013 12:36:31 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VPHMS-0003Y9-Di; Thu, 26 Sep 2013 15:36:28 -0400 Date: Thu, 26 Sep 2013 15:36:28 -0400 From: John Cowan To: Tim Bray Message-ID: <20130926193628.GB8186@mercury.ccil.org> References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: JSON WG , Paul Hoffman , R S Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 19:36:38 -0000 Tim Bray scripsit: > Hm, I bet that there are languages that look at the JSON number and > if there's no exp or frac parts, jam it into an integer; do modern > *integer* implementations preserve negative zero? By definition, no language that provides a exact representation of numbers (whether fixed-point or integral) can differentiate 0 and -0. It is because floating-point values represent *ranges* of numbers that it makes sense to differentiate between too-small numbers that cannot be negative (0.0) and too-large numbers that cannot be positive (-0.0). -- John Cowan cowan@ccil.org http://ccil.org/~cowan The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. --Edsger Dijkstra From sayrer@gmail.com Thu Sep 26 13:39:20 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C07521F9D2C for ; Thu, 26 Sep 2013 13:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg3JPAfopKCY for ; Thu, 26 Sep 2013 13:39:20 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id D1D4B21F964C for ; Thu, 26 Sep 2013 13:39:16 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c9so1147634qcz.14 for ; Thu, 26 Sep 2013 13:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SNU+qRNJEeknX109yIoSKTlNdkNsXYIwhXZY1AUpPtk=; b=RbAw3lN1u/tIJL0L/fuLExKGDTuq7wgWPqQ/rkRuVhEHoups/820nOvIOvquwwZ4qR TGBp8TFLXamUFMWNu7gLALOMD1KEzqVCmT6nH4yZmgH5afYAyfb9MomHgBHPQskAHkdN jZBUpgGldfuJGYOtpqukLuwVnaWTI2ijE9srTwkhmSAjQYHsGzWkRwFed4S5HYO6ucUi 7MHJc/0nFfZuTW3kWCskvVOHXtaxDsHMz8OmnKRLX+0iWiJfisdNloDTCeRIxVks27MG MFGxzu+xVyI+/yaHSQnaHI2Yrav+DRyM8NnOCPme+aIhgqkR4KvAFhEtMuyyZzczzEYK KreA== MIME-Version: 1.0 X-Received: by 10.224.167.18 with SMTP id o18mr9127526qay.87.1380227955812; Thu, 26 Sep 2013 13:39:15 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Thu, 26 Sep 2013 13:39:15 -0700 (PDT) In-Reply-To: <20130926193110.GA8186@mercury.ccil.org> References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <20130926193110.GA8186@mercury.ccil.org> Date: Thu, 26 Sep 2013 13:39:15 -0700 Message-ID: From: R S To: John Cowan Content-Type: multipart/alternative; boundary=089e01294f5a04019404e74f5d37 Cc: Paul Hoffman , JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 20:39:20 -0000 --089e01294f5a04019404e74f5d37 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 26, 2013 at 12:31 PM, John Cowan wrote: > > Most implementations can be relied upon to preserve signed zeros. > > Evidence for this statement is lacking. > Well, I wrote a widely-used implementation. And all of the implementations I use, including the C one, handle it. It is part of JSON, after all. I think the burden of proof is on those that want to leave this text in. - Rob --089e01294f5a04019404e74f5d37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 26, 2013 at 12:31 PM, John Cowan <cowan@= mercury.ccil.org> wrote:
=A0
> Most implementations can be relied upon to preserve signed zeros.

Evidence for this statement is lacking.

Well, I wrote a widely-used implementation. And all of the implement= ations I use, including the C one, handle it. It is part of JSON, after all= .=A0

I think the burden of proof is on those that want to le= ave this text in.

- Rob
--089e01294f5a04019404e74f5d37-- From sayrer@gmail.com Thu Sep 26 16:23:53 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBA121F9E02 for ; Thu, 26 Sep 2013 16:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGlrWl3w6nvT for ; Thu, 26 Sep 2013 16:23:48 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id AACA421F9CC8 for ; Thu, 26 Sep 2013 16:23:47 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id k4so32978qaq.5 for ; Thu, 26 Sep 2013 16:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KJ2jF5FR1n6GMEvNl70EHwaandeX068pulDnpWOHMhw=; b=GkxB9Dj2jdz14UWJG1u9ZGNLE/ad8p3Ho4YfGsbsQupqHKRGtiCqYmfsfMHuGxGuqy FnYJ1u7GMmDb66B6NsktSykmk3i0ocrhnjOlNT6s0+yuChyMZay4XSK0qat9sgkSQFD8 sA/u6R1JHccy8a2/usYUzP+jSSUuy3gD6RnwqOMDRKxrfxhZtp3OmlZ6+vFB0pup7BYl dcADP2DjemicDXQh/4yJ2IWsMriyOxFILxuuS+QZc/zCNQVmWPplV3VFIbudjVFmnCs2 T41rRrx8IYH+xlmydleoyoa+p37ZLvgdP08hbtliNozJOI5Izk/MpbsCCZqJ1E1CRkQv H9PQ== MIME-Version: 1.0 X-Received: by 10.49.132.233 with SMTP id ox9mr5191754qeb.36.1380237824581; Thu, 26 Sep 2013 16:23:44 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Thu, 26 Sep 2013 16:23:44 -0700 (PDT) In-Reply-To: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> Date: Thu, 26 Sep 2013 16:23:44 -0700 Message-ID: From: R S To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7bdc7ffa3d6c9304e751a90d Cc: JSON WG Subject: Re: [Json] Differences between RFC 4627 or the current ECMAScript specification X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 23:23:53 -0000 --047d7bdc7ffa3d6c9304e751a90d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 26, 2013 at 11:36 AM, Paul Hoffman wrote: > On Sep 26, 2013, at 10:31 AM, R S wrote: > > > Charter: > > > > > > All differences between RFC 4627 or the current ECMAScript > specification > will be documented in the new RFC. > > > > The ECMAScript specification allows primitives at the root level, > specifies exactly how to interpret numbers, and can handle " bit sequences > which cannot encode Unicode characters" just fine. > > > > Based on what we have learned in the last six months, it might be better > for this RFC *not* to do what the charter says. > Are you saying the concerns you list below warrant a recharter? If so, I disagree. > > - TC39 is actively revising ECMAScript and it is not clear whether the > -bis draft of their version will be out first. > We have a reference to ECMAScript in the draft already. > - Some of what ECMAscript says about JSON is intertwingled with the > definition of ECMAscript, such as "exactly how to interpret numbers" > We wouldn't even need to add a reference to explain this: "4.3.19 Number value primitive value corresponding to a double-precision 64-bit binary format IEEE 754 value" - Rob --047d7bdc7ffa3d6c9304e751a90d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 26, 2013 at 11:36 AM, Paul Hoffman <pau= l.hoffman@vpnc.org> wrote:
On Sep 26, 2013, at 10:31 AM, R S <sayrer@gmail.com> wrote:

> Charter:
> >
> > All differences between RFC 4627 or the current ECMAScript specif= ication > will be documented in the new RFC.
>
> The ECMAScript specification allows primitives at the root level, spec= ifies exactly how to interpret numbers, and can handle " bit sequences= which cannot encode Unicode characters" just fine.

<no hat>

Based on what we have learned in the last six months, it might be better fo= r this RFC *not* to do what the charter says.


Are you saying the concerns you list below warrant a = recharter? If so, I disagree.

=A0

- TC39 is actively revising ECMAScript and it is not clear whether the -bis= draft of their version will be out first.

<= div>We have a reference to ECMAScript in the draft already.

=A0
- Some of what ECMAscript says about JSON is intertwingled with the definit= ion of ECMAscript, such as "exactly how to interpret numbers"
=


We wouldn't even need t= o add a reference to explain this:

"4.3.19 Number value
primitive value cor= responding to a double-precision 64-bit binary format IEEE 754 value"<= br>


=A0- Rob
--047d7bdc7ffa3d6c9304e751a90d-- From mnot@mnot.net Thu Sep 26 16:25:06 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9714421F9E46 for ; Thu, 26 Sep 2013 16:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.366 X-Spam-Level: X-Spam-Status: No, score=-105.366 tagged_above=-999 required=5 tests=[AWL=-2.767, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfQ2yAzU1ABj for ; Thu, 26 Sep 2013 16:25:02 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 710B921F9E02 for ; Thu, 26 Sep 2013 16:24:58 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.29.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 727DE509B6; Thu, 26 Sep 2013 19:24:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Mark Nottingham In-Reply-To: Date: Fri, 27 Sep 2013 09:24:37 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Matt Miller (mamille2) X-Mailer: Apple Mail (2.1510) Cc: JSON WG Subject: Re: [Json] Working Group Last Call of draft-ietf-json-rfc4627bis-04 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 23:25:06 -0000 I haven't been following this document terribly closely, but it looks = good from what I see. FWIW, other reviewers may find this useful: = http://www.ietf.org/rfcdiff?url1=3Drfc4627&url2=3Ddraft-ietf-json-rfc4627b= is-04 A couple of nits (which may have already been discussed, pardon my = ignorance): * Shouldn't this document obsolete 4627? * Since this document is so similar to 4627, have you considered leaving = Crockford on the author list? * Is section 1.3 intended to be in the final, published document? If so, = it contains a needless amount of detail (e.g., a link to a consensus = call, a note that the 'changes' section has been added, WG attribution, = adding Tim as editor) * Appendix.A is supposed to be removed by the RFC Editor, right? Cheers, On 27/09/2013, at 3:14 AM, Matt Miller (mamille2) = wrote: > Hello All, >=20 > This message begins the Working Group Last Call (WGLC) on "The JSON = Data Interchange Format" < draft-ietf-json-rfc4627bis-04 >. WGLC will = end in two weeks, on October 11. >=20 > Please review the document and send comments to the Working Group = mailing list < json at ietf.org > or the co-chairs before the end of the WGLC. Note that suggested = changes which include proposed text will be more strongly considered = than those without. >=20 >=20 > Thanks, >=20 > - Paul Hoffman and Matt Miller >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Mark Nottingham http://www.mnot.net/ From stpeter@stpeter.im Thu Sep 26 16:27:17 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A5E21F9CC8 for ; Thu, 26 Sep 2013 16:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.256 X-Spam-Level: X-Spam-Status: No, score=-102.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGIlpOEGocco for ; Thu, 26 Sep 2013 16:27:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 514FF21E80C5 for ; Thu, 26 Sep 2013 16:27:08 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E3AB541509; Thu, 26 Sep 2013 17:32:19 -0600 (MDT) Message-ID: <5244C2C5.9010608@stpeter.im> Date: Thu, 26 Sep 2013 17:27:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark Nottingham References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: JSON WG , "Matt Miller \(mamille2\)" Subject: Re: [Json] Working Group Last Call of draft-ietf-json-rfc4627bis-04 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 23:27:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/26/13 5:24 PM, Mark Nottingham wrote: > * Since this document is so similar to 4627, have you considered > leaving Crockford on the author list? IMHO that is the right thing to do, unless he objects. The Area Director might need to perform an AD-override on AUTH48 approvals if Mr. Crockford has in fact disappeared or is uncommunicative. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSRMLFAAoJEOoGpJErxa2p1HAQAJNQpOnjgHJJ/Vvn/4Rw4a3T AuF3MFRN1c1rXa4a3vvAv/H64tXjgVZXbBzNQScB3P0F1jOdL1DGzeyCYQlSci30 Nl1Kn3GF9aLFSaD7JkgnSOkTjkptQuZS9tj5ybm0ub9M8rQBXMPFRSCuzMczJOiV ZuQyXbx2maSX/Nm1UIZo+wpFw34NnmE2+pTnBeIvclIY+LVJTmPkXoUvDW8Nq3WQ Ng2klJ8f7Qyd6OFOitsdmci7xNuxqQgu8taZn1fHWJa9KsQ20xg41UoHKpI5+C6a 4/xzBicLTKGLdJY6Fp+paXfxk6EL2P3EV0IFHI8E66B8cPi3x+y1/lfxDSH5Gl8z M9uXbDj7s8FzKBFUc8trlyFk5cXbHcBv/yqJOQAK07UuWo95VGKbsVL8Z9VxnbPe 2gQn83HRa04RfZUzEqUCGqoSIOQBIV0YqzLbRfowR7mI2sKCvo6v2fasGDLw19Ik D4HH3uCaBbmPr04lGH+XdfOmAeSJdqsA9tVnmAL4/XmvyX7vzca6o5g2tzjqA2m6 E3vWk9MEFBmx29tNU/etg1sLVQsKqIQmbyHLaQDmwl6Q2JZuNnI/0ugt+QARqngs oXJNWtvXOsztaeS6HR1sqWWU+vHWRdV04wk3R24QnS/DrcYwg43m0TDIojBCQdCq 9xElSZ6E1K7fhUHZNCKJ =dz4j -----END PGP SIGNATURE----- From tbray@textuality.com Thu Sep 26 16:36:14 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34AD21E8094 for ; Thu, 26 Sep 2013 16:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.824 X-Spam-Level: X-Spam-Status: No, score=-2.824 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo8AlM5a2cEK for ; Thu, 26 Sep 2013 16:36:10 -0700 (PDT) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id 86BEB11E80E3 for ; Thu, 26 Sep 2013 16:36:07 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id jy13so1457239veb.5 for ; Thu, 26 Sep 2013 16:36:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pM/GxzoLj9VmH/3+287CYR66Xc+5TuiF/xE1wvFmvrs=; b=eXgFjOiN27WZp62YM5cRG+AS+tTD2DmQPNV2AeuIwQtqNamAWhAk3KV21qdNCzldmu n/X9ImbncTFJYm9JbZS3spnA89+3C5nM6BKxxbJi1oEUrwTY34c4KF7akI3IrQNXwyNR QEZ69DOgk4bSncEI4rVKbTUdmiyJ05pDoKbYZcm/V97RrrEQ+JtXJfQ0djg67eIMIMDP PnLd8ObbjbSyqFoGjsOx67ZOP7BhM/fS7CHh/xwI0rHIYJzBTi48wSNQIwzuuS31kHpB i3+fJzzmap5d6Vkv/th2juOJluQ9vgEgB2U5QI8dGOATtVPGRs/2VUHaoeEObwBNHXqI J3/w== X-Gm-Message-State: ALoCoQlh6MvYa4ZLyJLcFZtZ9IanzrhvSEg/aVsMdcK/C0SMah+8xLENv260O/4sylkXpfg/ZFZB MIME-Version: 1.0 X-Received: by 10.58.108.74 with SMTP id hi10mr3175146veb.14.1380238566508; Thu, 26 Sep 2013 16:36:06 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 26 Sep 2013 16:36:06 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <5244C2C5.9010608@stpeter.im> References: <5244C2C5.9010608@stpeter.im> Date: Thu, 26 Sep 2013 16:36:06 -0700 Message-ID: From: Tim Bray To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=001a1130ca2e765b2b04e751d56a Cc: Mark Nottingham , "Matt Miller \(mamille2\)" , JSON WG Subject: Re: [Json] Working Group Last Call of draft-ietf-json-rfc4627bis-04 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 23:36:15 -0000 --001a1130ca2e765b2b04e751d56a Content-Type: text/plain; charset=UTF-8 +1, I think the only sane thing is to list Douglas as an author since a large majority of the text is his. I was told to put it this way for now. -T On Thu, Sep 26, 2013 at 4:27 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/26/13 5:24 PM, Mark Nottingham wrote: > > > * Since this document is so similar to 4627, have you considered > > leaving Crockford on the author list? > > IMHO that is the right thing to do, unless he objects. The Area > Director might need to perform an AD-override on AUTH48 approvals if > Mr. Crockford has in fact disappeared or is uncommunicative. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSRMLFAAoJEOoGpJErxa2p1HAQAJNQpOnjgHJJ/Vvn/4Rw4a3T > AuF3MFRN1c1rXa4a3vvAv/H64tXjgVZXbBzNQScB3P0F1jOdL1DGzeyCYQlSci30 > Nl1Kn3GF9aLFSaD7JkgnSOkTjkptQuZS9tj5ybm0ub9M8rQBXMPFRSCuzMczJOiV > ZuQyXbx2maSX/Nm1UIZo+wpFw34NnmE2+pTnBeIvclIY+LVJTmPkXoUvDW8Nq3WQ > Ng2klJ8f7Qyd6OFOitsdmci7xNuxqQgu8taZn1fHWJa9KsQ20xg41UoHKpI5+C6a > 4/xzBicLTKGLdJY6Fp+paXfxk6EL2P3EV0IFHI8E66B8cPi3x+y1/lfxDSH5Gl8z > M9uXbDj7s8FzKBFUc8trlyFk5cXbHcBv/yqJOQAK07UuWo95VGKbsVL8Z9VxnbPe > 2gQn83HRa04RfZUzEqUCGqoSIOQBIV0YqzLbRfowR7mI2sKCvo6v2fasGDLw19Ik > D4HH3uCaBbmPr04lGH+XdfOmAeSJdqsA9tVnmAL4/XmvyX7vzca6o5g2tzjqA2m6 > E3vWk9MEFBmx29tNU/etg1sLVQsKqIQmbyHLaQDmwl6Q2JZuNnI/0ugt+QARqngs > oXJNWtvXOsztaeS6HR1sqWWU+vHWRdV04wk3R24QnS/DrcYwg43m0TDIojBCQdCq > 9xElSZ6E1K7fhUHZNCKJ > =dz4j > -----END PGP SIGNATURE----- > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a1130ca2e765b2b04e751d56a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1, I think the only sane thing is to list Douglas as an a= uthor since a large majority of the text is his.=C2=A0 I was told to put it= this way for now. -T


On Thu, Sep 26, 2013 at 4:27 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/26/13 5:24 PM, Mark Nottingham wrote:

> * Since this document is so similar to 4627, have you considered
> leaving Crockford on the author list?

IMHO that is the right thing to do, unless he objects. The Area
Director might need to perform an AD-override on AUTH48 approvals if
Mr. Crockford has in fact disappeared or is uncommunicative.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http:= //gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSRMLFAAoJEOoGpJErxa2p1HAQAJNQpOnjgHJJ/Vvn/4Rw4a3T
AuF3MFRN1c1rXa4a3vvAv/H64tXjgVZXbBzNQScB3P0F1jOdL1DGzeyCYQlSci30
Nl1Kn3GF9aLFSaD7JkgnSOkTjkptQuZS9tj5ybm0ub9M8rQBXMPFRSCuzMczJOiV
ZuQyXbx2maSX/Nm1UIZo+wpFw34NnmE2+pTnBeIvclIY+LVJTmPkXoUvDW8Nq3WQ
Ng2klJ8f7Qyd6OFOitsdmci7xNuxqQgu8taZn1fHWJa9KsQ20xg41UoHKpI5+C6a
4/xzBicLTKGLdJY6Fp+paXfxk6EL2P3EV0IFHI8E66B8cPi3x+y1/lfxDSH5Gl8z
M9uXbDj7s8FzKBFUc8trlyFk5cXbHcBv/yqJOQAK07UuWo95VGKbsVL8Z9VxnbPe
2gQn83HRa04RfZUzEqUCGqoSIOQBIV0YqzLbRfowR7mI2sKCvo6v2fasGDLw19Ik
D4HH3uCaBbmPr04lGH+XdfOmAeSJdqsA9tVnmAL4/XmvyX7vzca6o5g2tzjqA2m6
E3vWk9MEFBmx29tNU/etg1sLVQsKqIQmbyHLaQDmwl6Q2JZuNnI/0ugt+QARqngs
oXJNWtvXOsztaeS6HR1sqWWU+vHWRdV04wk3R24QnS/DrcYwg43m0TDIojBCQdCq
9xElSZ6E1K7fhUHZNCKJ
=3Ddz4j
-----END PGP SIGNATURE-----
___________________________________= ____________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a1130ca2e765b2b04e751d56a-- From paul.hoffman@vpnc.org Thu Sep 26 17:20:48 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632D711E80ED for ; Thu, 26 Sep 2013 17:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQI9gYeY2b3R for ; Thu, 26 Sep 2013 17:20:46 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5C09A21F918C for ; Thu, 26 Sep 2013 17:20:46 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8R0Kei6025671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Sep 2013 17:20:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Thu, 26 Sep 2013 17:20:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0FA0EFFF-2109-4D78-8723-2ECD990C0F82@vpnc.org> References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> To: R S X-Mailer: Apple Mail (2.1510) Cc: JSON WG Subject: Re: [Json] Differences between RFC 4627 or the current ECMAScript specification X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 00:20:48 -0000 On Sep 26, 2013, at 4:23 PM, R S wrote: > Are you saying the concerns you list below warrant a recharter? If so, = I disagree. No, I was suggesting we ignore the charter and beg for forgiveness. A different thought is to (a) assume that version 5.1 is the "current = ECMAScript" and (b) simply mimic the two bullets from the beginning of = Section 15.12. This worries me because the JSON definition in 5.1 is not = exactly the same as 3 (which is what 4627 was based on), and it is not = exactly the same as the JSON definition in the current draft of 6. = Therefore, us saying "here are some differences" seems to be of more = danger than actual value. > - TC39 is actively revising ECMAScript and it is not clear whether the = -bis draft of their version will be out first. >=20 > We have a reference to ECMAScript in the draft already. So? It clearly is not to the current ECMAScript specification. > - Some of what ECMAscript says about JSON is intertwingled with the = definition of ECMAscript, such as "exactly how to interpret numbers" >=20 >=20 > We wouldn't even need to add a reference to explain this: >=20 > "4.3.19 Number value > primitive value corresponding to a double-precision 64-bit binary = format IEEE 754 value" >=20 > That seems irrelevant. Section 15.12.2 and 15.12.3 talk about "Numbers", = not "number values". TC39 might change this in version 6, or they might = not; we cannot tell. But you seem keen on us having such a section. Please provide the full = wording for what you think would be valuable to include. --Paul Hoffman= From paul.hoffman@vpnc.org Thu Sep 26 17:29:26 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57BB11E80ED for ; Thu, 26 Sep 2013 17:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWTNMncdMi17 for ; Thu, 26 Sep 2013 17:29:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7C20211E810F for ; Thu, 26 Sep 2013 17:29:25 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8R0TOTO025899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Sep 2013 17:29:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Thu, 26 Sep 2013 17:29:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> References: To: JSON WG X-Mailer: Apple Mail (2.1510) Subject: [Json] Authorship X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 00:29:27 -0000 On Sep 26, 2013, at 4:24 PM, Mark Nottingham wrote: > * Since this document is so similar to 4627, have you considered = leaving Crockford on the author list? As we said not long ago, we have not heard back from Douglas, even after = multiple attempts to reach him. Leaving his name as a co-author means a = few things: - He agrees with everything in the document that has his name on it. We = cannot tell if that is true, and we suspect it might not be. - He can cause the eventual RFC to never be published by never = responding during AUTH48, the last step in the RFC publication process. = That would mean that the hard work that many people have done here would = be a waste of time and energy. If Douglas himself asks to be the lead editor again under normal IETF = rules, the co-chairs would be happy to have him back and happier to have = his name where it should be on the eventual RFC. Without any such = agreement, or even acknowledgement that we have tried to reach him, we = were forced to move on. --Paul Hoffman= From paul.hoffman@vpnc.org Thu Sep 26 17:30:18 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD7011E8113 for ; Thu, 26 Sep 2013 17:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf0RyhPmACgw for ; Thu, 26 Sep 2013 17:30:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 52C5C11E8119 for ; Thu, 26 Sep 2013 17:30:15 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8R0TOTP025899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Sep 2013 17:30:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Thu, 26 Sep 2013 17:30:14 -0700 Content-Transfer-Encoding: 7bit Message-Id: <95AA0989-6473-4E83-861B-E84140EC083F@vpnc.org> References: To: JSON WG X-Mailer: Apple Mail (2.1510) Subject: [Json] Obsoletes RFC 4627 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 00:30:18 -0000 On Sep 26, 2013, at 4:24 PM, Mark Nottingham wrote: > * Shouldn't this document obsolete 4627? Er, yes, it probably should. Does anyone have any objection to this? --Paul Hoffman From paul.hoffman@vpnc.org Thu Sep 26 17:33:42 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7133F21F9950 for ; Thu, 26 Sep 2013 17:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQS8ySYIrval for ; Thu, 26 Sep 2013 17:33:42 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E497D21F84EA for ; Thu, 26 Sep 2013 17:33:40 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8R0XdGk026032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Sep 2013 17:33:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Thu, 26 Sep 2013 17:33:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: JSON WG X-Mailer: Apple Mail (2.1510) Subject: [Json] Section 1.3, "Changes from RFC 4627" X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 00:33:42 -0000 On Sep 26, 2013, at 4:24 PM, Mark Nottingham wrote: > * Is section 1.3 intended to be in the final, published document? Yes. > If so, it contains a needless amount of detail (e.g., a link to a = consensus call, a note that the 'changes' section has been added, WG = attribution, adding Tim as editor) The link to the consensus call is probably worth removing. The rest = should stay because they are, pedantically, changes from RFC 4627. > * Appendix.A is supposed to be removed by the RFC Editor, right? Yes. --Paul Hoffman= From sayrer@gmail.com Thu Sep 26 17:54:35 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AE321F91F2 for ; Thu, 26 Sep 2013 17:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bCYjiTRZ9+d for ; Thu, 26 Sep 2013 17:54:35 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id C492E21F963F for ; Thu, 26 Sep 2013 17:54:34 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id t7so1282437qcv.21 for ; Thu, 26 Sep 2013 17:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Us19mLF7uocV1+9vcL7Kc/FuAVOHilqB1azA8n4eR4M=; b=fJ8sXKRr5EgB7Uxdob0noDZPYQe9skROQvhxPwmU36Ti9tVklnZrt+bi8LE3Al0NYp NK3rBb6v65UafqgVgFyWS89V1uceJXVULLJ8Pz1YKnTJRecHXHKPg1Urr4QZsqNspjvK ZLokvk6E3rlEh1erZJFFKGMNXS3VAhl/LGUigiv48fWRzvMuTZyQbq9OSAqhzaMvdBKm TC2Ra/ALHX/KTpV984l+1up6UjR+tB+UhTH9B6gmjQ0ClwnuuNN+Ixk9bc6JRjX3bf1D oneQ6p25WTuKxSxtE57pW6nWvZPvuuBu6g7ThRFJQuWBNZNZwbTma31+IF2j7hXMT+bM F2AA== MIME-Version: 1.0 X-Received: by 10.224.89.1 with SMTP id c1mr10597704qam.100.1380243269213; Thu, 26 Sep 2013 17:54:29 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Thu, 26 Sep 2013 17:54:29 -0700 (PDT) In-Reply-To: <0FA0EFFF-2109-4D78-8723-2ECD990C0F82@vpnc.org> References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <0FA0EFFF-2109-4D78-8723-2ECD990C0F82@vpnc.org> Date: Thu, 26 Sep 2013 17:54:29 -0700 Message-ID: From: R S To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c3c798c3e68a04e752ed2d Cc: JSON WG Subject: Re: [Json] Differences between RFC 4627 or the current ECMAScript specification X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 00:54:36 -0000 --001a11c3c798c3e68a04e752ed2d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 26, 2013 at 5:20 PM, Paul Hoffman wrote: > On Sep 26, 2013, at 4:23 PM, R S wrote: > > > Are you saying the concerns you list below warrant a recharter? If so, I > disagree. > > No, I was suggesting we ignore the charter and beg for forgiveness. > Bad suggestion--the charter means what it says. If it doesn't, integrity would compel us to consider all of the suggestions that fall outside of the charter. > > A different thought is to (a) assume that version 5.1 is the "current > ECMAScript" and (b) simply mimic the two bullets from the beginning of > Section 15.12. This worries me because the JSON definition in 5.1 is not > exactly the same as 3 (which is what 4627 was based on), There is no JSON definition in ECMAScript 3. > and it is not exactly the same as the JSON definition in the current draft > of 6. Therefore, us saying "here are some differences" seems to be of more > danger than actual value. > We are free to cite the current version of ECMAScript, as Tim points out. > > > - Some of what ECMAscript says about JSON is intertwingled with the > definition of ECMAscript, such as "exactly how to interpret numbers" > > > > > > We wouldn't even need to add a reference to explain this: > > > > "4.3.19 Number value > > primitive value corresponding to a double-precision 64-bit binary format > IEEE 754 value" > > > > > > That seems irrelevant. Disagree. > Section 15.12.2 and 15.12.3 talk about "Numbers", not "number values". It's the same: > TC39 might change this in version 6, or they might not; we cannot tell. > Again, we won't be citing a future version with hypothetical changes. > But you seem keen on us having such a section. Please provide the full wording for what you > think would be valuable to include. I already have--feel free to reuse it. - Rob --001a11c3c798c3e68a04e752ed2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 26, 2013 at 5:20 PM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:
On Sep 26, 2013, at 4:23 PM, R S <sayrer@gmail.com> wrote:

> Are you saying the concerns you list below warrant a recharter? If so,= I disagree.

No, I was suggesting we ignore the charter and beg for forgiveness.

Bad suggestion--the charter means what i= t says. If it doesn't, integrity would compel us to consider all of the= suggestions that fall outside of the charter.

=A0

A different thought is to (a) assume that version 5.1 is the "current = ECMAScript" and (b) simply mimic the two bullets from the beginning of= Section 15.12. This worries me because the JSON definition in 5.1 is not e= xactly the same as 3 (which is what 4627 was based on),

There is no JSON definition in ECMAScript 3.
<= div>

=A0
and it is not exactly the same as the JSON definition in the current draft= of 6. Therefore, us saying "here are some differences" seems to = be of more danger than actual value.


We are free to cite the current version of ECMAScript, as Ti= m points out.=A0

=A0

> - Some of what ECMAscript says about JSON is intertwingled with the de= finition of ECMAscript, such as "exactly how to interpret numbers"= ;
>
>
> We wouldn't even need to add a reference to explain this:
>
> "4.3.19 Number value
> primitive value corresponding to a double-precision 64-bit binary form= at IEEE 754 value"
>
> <http://www.ecma-international.org/ecma-262/5.1/#sec-= 4.3.19>

That seems irrelevant.

Disagree.

=A0
Section 15.12.2 and 15.12.3 talk about "Numbers", not "numbe= r values".

It's the same:
<= http://www.ecma-international.org/ecma-262/5.1/#sec-8.5>

=A0
TC39 might change this in ver= sion 6, or they might not; we cannot tell.

Again, we won't be citing a future ver= sion with hypothetical changes.=A0

> But you seem keen on us h= aving such a section. Please provide the full wording for what you
> think= would be valuable to include.

I already have--feel free to reuse it.

- Rob
--001a11c3c798c3e68a04e752ed2d-- From sayrer@gmail.com Thu Sep 26 18:05:29 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4061E21E80D3 for ; Thu, 26 Sep 2013 18:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRppEJ-GB2tA for ; Thu, 26 Sep 2013 18:05:28 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id AD52711E80A2 for ; Thu, 26 Sep 2013 18:05:28 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id l4so1321080qcv.10 for ; Thu, 26 Sep 2013 18:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0rlz4lxhoRZqBWLWAiB0imEkWgSq5bfgm8hPCmPgD/4=; b=FPlS/sH5eqQHBvpIQ/d9vXjy4djnpxkG0iPFtRvrPOB6RIshXV5rJV9b/zC1fBAdt9 fZg1Ly+gy1fvECgFFJoT36m61ZRs/eZpArAkAug9CWSYRG/IeCGuZqXKkWZ8A7rz/3qR UkfPVM3DHjJE9nspdRx+G2sCjujvA315jJ0dLkUDwaz0D6L6JdGpVH7UdD54ezmSNhve +ULhUwKA3Z22B+vjZExrY+LOsTqSVwKCdLvmcHOjQXK56nvv+6yO2lSdEit5k/0wM27B fV2X9Zzw4PV7gf5QOqTFuuHNs6IspA1naVllsia+AKy2bZsufZdpDXd4nPTnmJLlDiTG eMoQ== MIME-Version: 1.0 X-Received: by 10.49.132.233 with SMTP id ox9mr5609635qeb.36.1380243928185; Thu, 26 Sep 2013 18:05:28 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Thu, 26 Sep 2013 18:05:28 -0700 (PDT) In-Reply-To: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> References: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> Date: Thu, 26 Sep 2013 18:05:28 -0700 Message-ID: From: R S To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7bdc7ffa0b078904e7531587 Cc: JSON WG Subject: Re: [Json] Authorship X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 01:05:29 -0000 --047d7bdc7ffa0b078904e7531587 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 26, 2013 at 5:29 PM, Paul Hoffman wrote: > > - He agrees with everything in the document that has his name on it. We > cannot tell if that is true, and we suspect it might not be. > Maybe that should make us question the value of the current draft. - Rob --047d7bdc7ffa0b078904e7531587 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 26, 2013 at 5:29 PM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:

- He agrees with everything in the document that has his name on it. We can= not tell if that is true, and we suspect it might not be.
<= div>
Maybe that should make us question the value of the curr= ent draft.

- Rob=A0
--047d7bdc7ffa0b078904e7531587-- From paul.hoffman@vpnc.org Thu Sep 26 18:18:30 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3A421E80D6 for ; Thu, 26 Sep 2013 18:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCvfJlk5g0KH for ; Thu, 26 Sep 2013 18:18:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4C92A21E80CB for ; Thu, 26 Sep 2013 18:18:28 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8R1ILJP027173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Sep 2013 18:18:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Thu, 26 Sep 2013 18:18:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7058DBBD-9DCE-4A5C-B11D-5FC41A839407@vpnc.org> References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <0FA0EFFF-2109-4D78-8723-2ECD990C0F82@vpnc.org> To: R S X-Mailer: Apple Mail (2.1510) Cc: JSON WG Subject: Re: [Json] Differences between RFC 4627 or the current ECMAScript specification X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 01:18:31 -0000 On Sep 26, 2013, at 5:54 PM, R S wrote: > On Thu, Sep 26, 2013 at 5:20 PM, Paul Hoffman = wrote: > On Sep 26, 2013, at 4:23 PM, R S wrote: >=20 > > Are you saying the concerns you list below warrant a recharter? If = so, I disagree. >=20 > No, I was suggesting we ignore the charter and beg for forgiveness. >=20 > Bad suggestion--the charter means what it says. If it doesn't, = integrity would compel us to consider all of the suggestions that fall = outside of the charter. Sorry if you don't feel that we are acting in "integrity". > There is no JSON definition in ECMAScript 3. Whatever you want to call the third edition: [ECMA] European Computer Manufacturers Association, "ECMAScript Language Specification 3rd Edition", December 1999, . > We are free to cite the current version of ECMAScript, as Tim points = out. Only if we can agree on what that version is. And if we can agree that = doing so actually brings value to the document. The latter is more = important to me than the coin we use for the former. > Again, we won't be citing a future version with hypothetical changes.=20= >=20 > > But you seem keen on us having such a section. Please provide the = full wording for what you > > think would be valuable to include. >=20 > I already have--feel free to reuse it. It was: The ECMAScript specification allows primitives at the root level, = specifies exactly how to interpret numbers, and can handle "bit = sequences which cannot encode Unicode characters" just fine. Do others here agree with all three parts? Or is there different = suggested wording? Also: You did not include the second bullet from ECMAScript 5.1, Section = 15.12. Is there a reason for that? --Paul Hoffman= From sayrer@gmail.com Thu Sep 26 18:29:41 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D120021F967A for ; Thu, 26 Sep 2013 18:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL-DCfbLBH3M for ; Thu, 26 Sep 2013 18:29:41 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id E8C3121F935A for ; Thu, 26 Sep 2013 18:29:40 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id l4so1312422qcv.24 for ; Thu, 26 Sep 2013 18:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cyL101eEO5Tlgf1O6vGD7uJ+A7UpsJn6x+fs/5J/5P8=; b=FDnY84Za8Q3ubrFHlFmD5F3jZBopnQeJhQyJpJnRUK5aQelppa/zemw+8XxnbIjwaj 4r4v30UBuQePr478IP+E+XPKP07xjJvDdbnJ8HS3Wrq2EmnYc27UD6Qcoid1Hjbcii2H lgvWUj5R6PWg4ytJdacEkyJbWtgNVb+z36WvfePzxK/wgdAtNt7uX0ElwvWEPyCy7r+c rHvDdozWQ5k5PamyzgeOleehN/91vWPB9IoOhLuJQCLWdRT7scKuJ6W2x5meaMkhpsqc bSdJTKenTPdqhfZz7nyY6cvZk9ilMfm3/2vEaDmDVd7fBxYEJdtFb7iBHzWm2ZcIOt0u hIDg== MIME-Version: 1.0 X-Received: by 10.49.132.233 with SMTP id ox9mr5711948qeb.36.1380245380364; Thu, 26 Sep 2013 18:29:40 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Thu, 26 Sep 2013 18:29:40 -0700 (PDT) In-Reply-To: <7058DBBD-9DCE-4A5C-B11D-5FC41A839407@vpnc.org> References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <0FA0EFFF-2109-4D78-8723-2ECD990C0F82@vpnc.org> <7058DBBD-9DCE-4A5C-B11D-5FC41A839407@vpnc.org> Date: Thu, 26 Sep 2013 18:29:40 -0700 Message-ID: From: R S To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7bdc7ffa99812904e7536bcf Cc: JSON WG Subject: Re: [Json] Differences between RFC 4627 or the current ECMAScript specification X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 01:29:41 -0000 --047d7bdc7ffa99812904e7536bcf Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 26, 2013 at 6:18 PM, Paul Hoffman wrote: > On Sep 26, 2013, at 5:54 PM, R S wrote: > > > On Thu, Sep 26, 2013 at 5:20 PM, Paul Hoffman > wrote: > > On Sep 26, 2013, at 4:23 PM, R S wrote: > > > > > Are you saying the concerns you list below warrant a recharter? If so, > I disagree. > > > > No, I was suggesting we ignore the charter and beg for forgiveness. > > > > Bad suggestion--the charter means what it says. If it doesn't, integrity > would compel us to consider all of the suggestions that fall outside of the > charter. > > Sorry if you don't feel that we are acting in "integrity". > Maybe you should explain why you think it's OK to suddenly ignore the charter? Don't you think it's inconsistent with telling people to go away because their suggestions don't fit the charter? > > > There is no JSON definition in ECMAScript 3. > Whatever you want to call the third edition: I'm sorry--are you nitpicking my term for what you called "3"? Hopefully we can raise the level of discourse. > > We are free to cite the current version of ECMAScript, as Tim points out. > > Only if we can agree on what that version is. And if we can agree that > doing so actually brings value to the document. The latter is more > important to me than the coin we use for the former. > We do agree on the latter--we already have the charter that says so. > > > Again, we won't be citing a future version with hypothetical changes. > > > > > But you seem keen on us having such a section. Please provide the full > wording for what you > > > think would be valuable to include. > > > > I already have--feel free to reuse it. > > It was: > No. > > The ECMAScript specification allows primitives at the root level, > specifies exactly how to interpret numbers, and can handle "bit sequences > which cannot encode Unicode characters" just fine. > > Do others here agree with all three parts? Or is there different suggested > wording? > That text is not what I was referring to. > > Also: You did not include the second bullet from ECMAScript 5.1, Section > 15.12. Is there a reason for that? > That bullet point is misleadingly worded. I can tell you this because I wrote a widely-used JSON implementation for RFC4267 that had to be adjusted for ECMAScript 5. The two biggest changes were to ban trailing commas in objects and accept primitive values at the root. - Rob --047d7bdc7ffa99812904e7536bcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 26, 2013 at 6:18 PM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:
On Sep 26, 2013, at 5:54 P= M, R S <sayrer@gmail.com> wro= te:

> On Thu, Sep 26, 2013 at 5:20 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> On Sep 26, 2013, at 4:23 PM, R S <sayrer@gmail.com> wrote:
>
> > Are you saying the concerns you list below warrant a recharter? I= f so, I disagree.
>
> No, I was suggesting we ignore the charter and beg for forgiveness. >
> Bad suggestion--the charter means what it says. If it doesn't, int= egrity would compel us to consider all of the suggestions that fall outside= of the charter.

Sorry if you don't feel that we are acting in "integrity&quo= t;.

Maybe you should explain why you th= ink it's OK to suddenly ignore the charter? Don't you think it'= s inconsistent with telling people to go away because their suggestions don= 't fit the charter?

=A0

> There is no JSON definition in ECMAScript 3.
Whatever you want to call the third edition:

I'm sorry--are you nitpicking my term for what you called "= ;3"? Hopefully we can raise the level of discourse.

=A0
> We are free to cite the current version of ECMAScript, as Tim points o= ut.

Only if we can agree on what that version is. And if we can agree tha= t doing so actually brings value to the document. The latter is more import= ant to me than the coin we use for the former.

We do agree on the latter--we already have the charter that says= so.

=A0

> Again, we won't be citing a future version with hypothetical chang= es.
>
> > But you seem keen on us having such a section. Please provide the= full wording for what you
> > think would be valuable to include.
>
> I already have--feel free to reuse it.

It was:

No.
=A0

The ECMAScript specification allows primitives at the root level, specifies= exactly how to interpret numbers, and can handle "bit sequences which= cannot encode Unicode characters" just fine.

Do others here agree with all three parts? Or is there different sugg= ested wording?

That text is not what I = was referring to.
=A0

Also: You did not include the second bullet from ECMAScript 5.1, Section 15= .12. Is there a reason for that?

That b= ullet point is misleadingly worded. I can tell you this because I wrote a w= idely-used JSON implementation for RFC4267 that had to be adjusted for ECMA= Script 5. The two biggest changes were to ban trailing commas in objects an= d accept primitive values at the root.

- Rob

--047d7bdc7ffa99812904e7536bcf-- From cowan@ccil.org Thu Sep 26 19:46:02 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B489821F9E52 for ; Thu, 26 Sep 2013 19:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.244 X-Spam-Level: X-Spam-Status: No, score=-3.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deOlyIf-a9cu for ; Thu, 26 Sep 2013 19:45:58 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 56F7021F9D62 for ; Thu, 26 Sep 2013 19:45:57 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VPO42-000713-Vf; Thu, 26 Sep 2013 22:45:55 -0400 Date: Thu, 26 Sep 2013 22:45:54 -0400 From: John Cowan To: R S Message-ID: <20130927024554.GA27195@mercury.ccil.org> References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <0FA0EFFF-2109-4D78-8723-2ECD990C0F82@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Differences between RFC 4627 or the current ECMAScript specification X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 02:46:03 -0000 R S scripsit: > > No, I was suggesting we ignore the charter and beg for forgiveness. > > Bad suggestion--the charter means what it says. If it doesn't, integrity > would compel us to consider all of the suggestions that fall outside of the > charter. There is a big difference between not doing what the charter says we should, and doing what the charter says we should not. Paul is proposing that we ask forgiveness for a sin of omission; you are saying that that is equivalent to arbitrary sins of commission. It isn't. -- John Cowan http://www.ccil.org/~cowan Awk!" sed Grep. "A fscking python is perloining my Ruby; let me bash him with a Cshell! Vi didn't I mount it on a troff?" --Francis Turner From stpeter@stpeter.im Thu Sep 26 19:49:57 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BABF11E80ED for ; Thu, 26 Sep 2013 19:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.27 X-Spam-Level: X-Spam-Status: No, score=-102.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52-inBbXI7HR for ; Thu, 26 Sep 2013 19:49:52 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F2E2E21F9611 for ; Thu, 26 Sep 2013 19:49:51 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2DB1D41509; Thu, 26 Sep 2013 20:55:09 -0600 (MDT) Message-ID: <5244F24E.7090903@stpeter.im> Date: Thu, 26 Sep 2013 20:49:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: R S References: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Authorship X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 02:49:57 -0000 On 9/26/13 7:05 PM, R S wrote: > On Thu, Sep 26, 2013 at 5:29 PM, Paul Hoffman > wrote: > > > - He agrees with everything in the document that has his name on it. > We cannot tell if that is true, and we suspect it might not be. > > > Maybe that should make us question the value of the current draft. It strikes me that we question the value of a document based on its objective content, not based on the unknowable intentions of a given participant (or, now, non-participant) in the WG -- no matter how important that person has been to the work so far. Peter -- Peter Saint-Andre https://stpeter.im/ From cowan@ccil.org Thu Sep 26 20:17:39 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987A421E80E5 for ; Thu, 26 Sep 2013 20:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.258 X-Spam-Level: X-Spam-Status: No, score=-3.258 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDb1UznesRbm for ; Thu, 26 Sep 2013 20:17:34 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id E9C6421E80DF for ; Thu, 26 Sep 2013 20:17:33 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VPOYe-0001qA-2E; Thu, 26 Sep 2013 23:17:32 -0400 Date: Thu, 26 Sep 2013 23:17:32 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130927031731.GD27195@mercury.ccil.org> References: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: JSON WG Subject: Re: [Json] Authorship X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 03:17:39 -0000 Paul Hoffman scripsit: > If Douglas himself asks to be the lead editor again under normal IETF > rules, the co-chairs would be happy to have him back and happier to > have his name where it should be on the eventual RFC. Without any such > agreement, or even acknowledgement that we have tried to reach him, > we were forced to move on. I think section 14 satisfies all authorship concerns. -- Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! --Joyce, Ulysses, "Oxen of the Sun" cowan@ccil.org From duerst@it.aoyama.ac.jp Thu Sep 26 21:03:57 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156B621F9DC7 for ; Thu, 26 Sep 2013 21:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.569 X-Spam-Level: X-Spam-Status: No, score=-101.569 tagged_above=-999 required=5 tests=[AWL=-1.779, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfS577tTUIVL for ; Thu, 26 Sep 2013 21:03:51 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9B15921F9A65 for ; Thu, 26 Sep 2013 21:03:48 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8R43epi015462; Fri, 27 Sep 2013 13:03:43 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 24c4_efd3_cb07bb3c_2729_11e3_b910_001e6722eec2; Fri, 27 Sep 2013 13:03:39 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id DC29CBFB14; Fri, 27 Sep 2013 13:03:39 +0900 (JST) Message-ID: <5245038F.4060206@it.aoyama.ac.jp> Date: Fri, 27 Sep 2013 13:03:27 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: <95AA0989-6473-4E83-861B-E84140EC083F@vpnc.org> In-Reply-To: <95AA0989-6473-4E83-861B-E84140EC083F@vpnc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: JSON WG Subject: Re: [Json] Obsoletes RFC 4627 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 04:03:57 -0000 On 2013/09/27 9:30, Paul Hoffman wrote: > > > On Sep 26, 2013, at 4:24 PM, Mark Nottingham wrote: > >> * Shouldn't this document obsolete 4627? > > Er, yes, it probably should. Does anyone have any objection to this? None at all here. If it doesn't obsolete RFC 4627, why would we have done all the work? Regards, Martin. > --Paul Hoffman > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From tbray@textuality.com Thu Sep 26 23:02:58 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C01411E8121 for ; Thu, 26 Sep 2013 23:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.662 X-Spam-Level: X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMCgVC3fegvw for ; Thu, 26 Sep 2013 23:02:53 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 73FB311E8124 for ; Thu, 26 Sep 2013 23:02:53 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hz10so1530348vcb.40 for ; Thu, 26 Sep 2013 23:02:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8Hsg8zsVX5RC5vNyvJ3x8EPKzKQ1PgxyqI+J4J1kDHs=; b=iuuuW9g1UKQ6C5t0AThLq0YN/W0DaQm5YBjdrDHO8qSij3bOIvNS1PBUiAEyBKUoAB xEKjD2pCWfpCqTIAX67ryEGnVzRI3Uq5wgjxLW56bMTgkwLqjB+dhs3zHAQZrxGR76HB elGVz+6rV7LiWlPU20f+/yXu1G35+SdGlT/CGdHSd5gO0YuT6s8SAa2qqPosfh7yJsjS rQ1aFRuJn6Fif7QK/jE3Ua6U6HuSjSGfZXMmZLS+xsLOqv3RzeeiU7a83OMsgkVBi/fp vNjhmtgZWV/mrp1vPmchwoSfM6MEl7fB1Uaq+Fs2j4A1vDZa4axLCoBYMSr2O1Q+PMCn bb9Q== X-Gm-Message-State: ALoCoQntw/ZLr7AgtRqw7t16bVKXwV18voGYGtt0Kx/OP7RwRtAoMz62QuyH742KIsv01P3B1MRi MIME-Version: 1.0 X-Received: by 10.52.173.165 with SMTP id bl5mr3995936vdc.18.1380261772455; Thu, 26 Sep 2013 23:02:52 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 26 Sep 2013 23:02:52 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <5245038F.4060206@it.aoyama.ac.jp> References: <95AA0989-6473-4E83-861B-E84140EC083F@vpnc.org> <5245038F.4060206@it.aoyama.ac.jp> Date: Thu, 26 Sep 2013 23:02:52 -0700 Message-ID: From: Tim Bray To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=bcaec51b9cfda5032d04e7573ce3 Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Obsoletes RFC 4627 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 06:02:58 -0000 --bcaec51b9cfda5032d04e7573ce3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable where do =E2=80=9Cobsoletes=E2=80=9D assertions go in t= he draft? On Thu, Sep 26, 2013 at 9:03 PM, "Martin J. D=C3=BCrst" wrote: > On 2013/09/27 9:30, Paul Hoffman wrote: > >> >> >> On Sep 26, 2013, at 4:24 PM, Mark Nottingham wrote: >> >> * Shouldn't this document obsolete 4627? >>> >> >> Er, yes, it probably should. Does anyone have any objection to this? >> > > None at all here. If it doesn't obsolete RFC 4627, why would we have done > all the work? > > Regards, Martin. > > > --Paul Hoffman >> >> ______________________________**_________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/**listinfo/json >> >> ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --bcaec51b9cfda5032d04e7573ce3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<wearing-editor-hat>where do =E2=80=9Cobsoletes=E2= =80=9D assertions go in the draft?</wearing-editor-hat>


On Thu, Sep 26, 2= 013 at 9:03 PM, "Martin J. D=C3=BCrst" <duerst@it.aoyama.ac= .jp> wrote:
On 2013/09/27 9:30, Paul H= offman wrote:
<no hat>

On Sep 26, 2013, at 4:24 PM, Mark Nottingham<mnot@mnot.net> =C2=A0wrote:

* Shouldn't this document obsolete 4627?

Er, yes, it probably should. Does anyone have any objection to this?

None at all here. If it doesn't obsolete RFC 4627, why would we have do= ne all the work?

Regards, =C2=A0 Martin.


--Paul Hoffman

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

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

--bcaec51b9cfda5032d04e7573ce3-- From lear@cisco.com Thu Sep 26 23:08:06 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456CB11E812B for ; Thu, 26 Sep 2013 23:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.508 X-Spam-Level: X-Spam-Status: No, score=-110.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYNAiZ+teXta for ; Thu, 26 Sep 2013 23:08:01 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8716D11E812A for ; Thu, 26 Sep 2013 23:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1565; q=dns/txt; s=iport; t=1380262075; x=1381471675; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=tV6yOA4ycWtLM2oNrgHJZuGPe8H0/OsONZ4gYQ2IeCw=; b=blreybl0nlg/P+2decFDhVRqd0GgcQsPeuNWs3ZLjC9TtgWYp5UtvJH3 PJz+mNqV4GKGZlM79yFtpIEx5qUq9jkhH8zvEZXxXpbDCPCZqKg01lnm8 oVrCotw7akQOm/t+q+MxxhwSvCyFNoT1t4zAdTXVnBcvRjoYuP+6rQ4G4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFABkgRVKQ/khM/2dsb2JhbABagweEM4Vdt0OBHBZ0ghwJAQEBBCNVARALAwEKCgkWCwICCQMCAQIBRQYNAQcBAYgCqCaSLI9RB4JogTYDl32ReIMmOg X-IronPort-AV: E=Sophos;i="4.90,991,1371081600"; d="scan'208,217";a="86968512" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 27 Sep 2013 06:07:53 +0000 Received: from ams3-vpn-dhcp5967.cisco.com (ams3-vpn-dhcp5967.cisco.com [10.61.87.78]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8R67ooK005667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Sep 2013 06:07:51 GMT Message-ID: <524520B6.2000609@cisco.com> Date: Fri, 27 Sep 2013 08:07:50 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tim Bray References: <95AA0989-6473-4E83-861B-E84140EC083F@vpnc.org> <5245038F.4060206@it.aoyama.ac.jp> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------030803050009040304060109" Cc: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Paul Hoffman , JSON WG Subject: Re: [Json] Obsoletes RFC 4627 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 06:08:06 -0000 This is a multi-part message in MIME format. --------------030803050009040304060109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 9/27/13 8:02 AM, Tim Bray wrote: > where do “obsoletes†assertions go in the > draft? > In the header of the document. If you're using xml2rfc, in the element as an attribute (but you would add it to the existing . Eliot --------------030803050009040304060109 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 9/27/13 8:02 AM, Tim Bray wrote:
<wearing-editor-hat>where do “obsoletes†assertions go in the draft?</wearing-editor-hat>


In the header of the document.  If you're using xml2rfc, in the <rfc> element as an attribute <rfc obsoletes="4627"> (but you would add it to the existing <rfc>.

Eliot

--------------030803050009040304060109-- From lear@cisco.com Thu Sep 26 23:18:17 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F337511E811A for ; Thu, 26 Sep 2013 23:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u+X29L30Dew for ; Thu, 26 Sep 2013 23:18:12 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 08B1611E8121 for ; Thu, 26 Sep 2013 23:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=600; q=dns/txt; s=iport; t=1380262691; x=1381472291; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wkm0OXqh3y1O+snzNMUnIlgvLDHx0U/S62Gfn8TjHJ8=; b=JhTtCxL/E5mqZscB1v7D3CN4ySxVJibUVR8tPzPHtX3avOjqZs9/uKcw 933BHJLMEYMiXoJZhoa8qsjLhoauoKayGu0oZZygNH4CjRkujRIr0HR7j VqtFVAA1tZi0ArXdruMeahMVDWwDq1VPHOYpGZFsrtWZcJxN8Vzq7c5pP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAK0iRVKQ/khL/2dsb2JhbABagweEM70ggRwWdIIlAQEBBCNVARALGAICBRYLAgIJAwIBAgFFBg0BBwEBiAKoPZItgSmOKAeCaIE2A5NfhB6ReIMmOg X-IronPort-AV: E=Sophos;i="4.90,872,1371081600"; d="scan'208";a="17842815" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 27 Sep 2013 06:18:10 +0000 Received: from ams3-vpn-dhcp5967.cisco.com (ams3-vpn-dhcp5967.cisco.com [10.61.87.78]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8R6I7ga023344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Sep 2013 06:18:08 GMT Message-ID: <5245231F.6050708@cisco.com> Date: Fri, 27 Sep 2013 08:18:07 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Cowan References: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> <20130927031731.GD27195@mercury.ccil.org> In-Reply-To: <20130927031731.GD27195@mercury.ccil.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Authorship X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 06:18:17 -0000 On 9/27/13 5:17 AM, John Cowan wrote: > I think section 14 satisfies all authorship concerns. > I don't agree. Although he should not be editing now, Mr. Crockford wrote the bulk of the text and it would be wrong to remove him from the front. Section 14 already indicates that only a small number of revisions have occurred. Our practice is to leave him in the author field. We have mechanisms to deal with getting documents out the door. It is important to indicate that he has not actively contributed to this draft, and thus may not agree with the revision. Eliot From duerst@it.aoyama.ac.jp Fri Sep 27 00:00:56 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B9C11E812A for ; Fri, 27 Sep 2013 00:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.451 X-Spam-Level: X-Spam-Status: No, score=-103.451 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0HTNssdvaRR for ; Fri, 27 Sep 2013 00:00:50 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 215D311E8128 for ; Fri, 27 Sep 2013 00:00:49 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8R70e6L026021; Fri, 27 Sep 2013 16:00:40 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 24c0_1407_85250fde_2742_11e3_bd67_001e6722eec2; Fri, 27 Sep 2013 16:00:40 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id EA464BFB14; Fri, 27 Sep 2013 16:00:39 +0900 (JST) Message-ID: <52452D0B.9040601@it.aoyama.ac.jp> Date: Fri, 27 Sep 2013 16:00:27 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: <5244C2C5.9010608@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , JSON WG , Peter Saint-Andre , "Matt Miller \(mamille2\)" Subject: Re: [Json] [authorship] (was: Working Group Last Call of draft-ietf-json-rfc4627bis-04) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 07:00:56 -0000 I agree too that Douglas should continue to be listed as an author. Paul wrote: > As we said not long ago, we have not heard back from Douglas, even after multiple attempts to reach him. Leaving his name as a co-author means a few things: > > - He agrees with everything in the document that has his name on it. We cannot tell if that is true, and we suspect it might not be. He doesn't have to agree with every comma in the draft. He just has to agree that he is okay with being listed as an author, even if there are details he might have done differently. > - He can cause the eventual RFC to never be published by never responding during AUTH48, the last step in the RFC publication process. That would mean that the hard work that many people have done here would be a waste of time and energy. Peter mentioned how to deal with this below. > If Douglas himself asks to be the lead editor again under normal IETF rules, the co-chairs would be happy to have him back and happier to have his name where it should be on the eventual RFC. Without any such agreement, or even acknowledgement that we have tried to reach him, we were forced to move on. There is absolutely no need to have him as a lead editor. Tim is doing just fine in that role. Once the text in the document from Douglas drops below a certain percentage (e.g. 10% or 20% or so, which I don't expect to happen anyway), it may make sense to ask him to hang in there a bit more to earn his authorship, but at the moment, he has already 'prepaid' for this a long time ago. So I would definitely prefer to keep Douglas as an editor, and would want to make sure that when he's contacted, it's not by saying "we can keep you as an editor if you are going to be a lead editor again and are going to agree with every single bit of the document" but "we'd like to keep you listed as an editor because of what you have done up to now (and we are reusing)". Regards, Martin. On 2013/09/27 8:36, Tim Bray wrote: > +1, I think the only sane thing is to list Douglas as an author since a > large majority of the text is his. I was told to put it this way for now. > -T > > > On Thu, Sep 26, 2013 at 4:27 PM, Peter Saint-Andrewrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 9/26/13 5:24 PM, Mark Nottingham wrote: >> >>> * Since this document is so similar to 4627, have you considered >>> leaving Crockford on the author list? >> >> IMHO that is the right thing to do, unless he objects. The Area >> Director might need to perform an AD-override on AUTH48 approvals if >> Mr. Crockford has in fact disappeared or is uncommunicative. >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJSRMLFAAoJEOoGpJErxa2p1HAQAJNQpOnjgHJJ/Vvn/4Rw4a3T >> AuF3MFRN1c1rXa4a3vvAv/H64tXjgVZXbBzNQScB3P0F1jOdL1DGzeyCYQlSci30 >> Nl1Kn3GF9aLFSaD7JkgnSOkTjkptQuZS9tj5ybm0ub9M8rQBXMPFRSCuzMczJOiV >> ZuQyXbx2maSX/Nm1UIZo+wpFw34NnmE2+pTnBeIvclIY+LVJTmPkXoUvDW8Nq3WQ >> Ng2klJ8f7Qyd6OFOitsdmci7xNuxqQgu8taZn1fHWJa9KsQ20xg41UoHKpI5+C6a >> 4/xzBicLTKGLdJY6Fp+paXfxk6EL2P3EV0IFHI8E66B8cPi3x+y1/lfxDSH5Gl8z >> M9uXbDj7s8FzKBFUc8trlyFk5cXbHcBv/yqJOQAK07UuWo95VGKbsVL8Z9VxnbPe >> 2gQn83HRa04RfZUzEqUCGqoSIOQBIV0YqzLbRfowR7mI2sKCvo6v2fasGDLw19Ik >> D4HH3uCaBbmPr04lGH+XdfOmAeSJdqsA9tVnmAL4/XmvyX7vzca6o5g2tzjqA2m6 >> E3vWk9MEFBmx29tNU/etg1sLVQsKqIQmbyHLaQDmwl6Q2JZuNnI/0ugt+QARqngs >> oXJNWtvXOsztaeS6HR1sqWWU+vHWRdV04wk3R24QnS/DrcYwg43m0TDIojBCQdCq >> 9xElSZ6E1K7fhUHZNCKJ >> =dz4j >> -----END PGP SIGNATURE----- >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From duerst@it.aoyama.ac.jp Fri Sep 27 00:09:34 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC9221F9D38 for ; Fri, 27 Sep 2013 00:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.472 X-Spam-Level: X-Spam-Status: No, score=-103.472 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzWcuk8IulzW for ; Fri, 27 Sep 2013 00:09:29 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 38B9411E812B for ; Fri, 27 Sep 2013 00:09:25 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8R79LP7032652; Fri, 27 Sep 2013 16:09:21 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 24c4_53cd_bbda911a_2743_11e3_b910_001e6722eec2; Fri, 27 Sep 2013 16:09:21 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 38EEBBFB14; Fri, 27 Sep 2013 16:09:21 +0900 (JST) Message-ID: <52452F14.1070803@it.aoyama.ac.jp> Date: Fri, 27 Sep 2013 16:09:08 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: R S References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 07:09:35 -0000 On 2013/09/27 3:52, R S wrote: > On Thu, Sep 26, 2013 at 11:50 AM, Tim Bray wrote: > >> Well, except for the very first thing I tried, a modern Ruby with the >> default "require 'json'", did not preserve the sign. >> > > I bet they would take a patch, though. Please send one, or at least file a bug report on http://bugs.ruby-lang.org. > I was wondering whether we were > enshrining a bug in the spec or catering to other floating point > implementations. I think the later, mostly. Regards, Martin. > - Rob > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From duerst@it.aoyama.ac.jp Fri Sep 27 00:12:44 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AEF11E8131 for ; Fri, 27 Sep 2013 00:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.491 X-Spam-Level: X-Spam-Status: No, score=-101.491 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAeqQT7lujKq for ; Fri, 27 Sep 2013 00:12:39 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id F046911E812B for ; Fri, 27 Sep 2013 00:12:37 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8R7CaGv017048; Fri, 27 Sep 2013 16:12:36 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 24c0_19e6_300a3086_2744_11e3_bd67_001e6722eec2; Fri, 27 Sep 2013 16:12:36 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 2AE62BFB14; Fri, 27 Sep 2013 16:12:36 +0900 (JST) Message-ID: <52452FD7.5090801@it.aoyama.ac.jp> Date: Fri, 27 Sep 2013 16:12:23 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: JSON WG Subject: Re: [Json] Section 1.3, "Changes from RFC 4627" X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 07:12:44 -0000 On 2013/09/27 9:33, Paul Hoffman wrote: > > > On Sep 26, 2013, at 4:24 PM, Mark Nottingham wrote: > >> * Is section 1.3 intended to be in the final, published document? > > Yes. > >> If so, it contains a needless amount of detail (e.g., a link to a consensus call, a note that the 'changes' section has been added, WG attribution, adding Tim as editor) > > The link to the consensus call is probably worth removing. The rest should stay because they are, pedantically, changes from RFC 4627. One way to deal with this is to separate this into two: - Major changes from RFC 4627 (this stays in the final version) - Changelog (this gets removed by the RFC editor) That has worked quite well in other instances. Regards, Martin. >> * Appendix.A is supposed to be removed by the RFC Editor, right? > > Yes. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From duerst@it.aoyama.ac.jp Fri Sep 27 00:20:21 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D53421F9D9C for ; Fri, 27 Sep 2013 00:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.096 X-Spam-Level: X-Spam-Status: No, score=-103.096 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujmr2uhxs3oh for ; Fri, 27 Sep 2013 00:20:14 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 02C0221F9D95 for ; Fri, 27 Sep 2013 00:20:12 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8R7K8qH009048; Fri, 27 Sep 2013 16:20:08 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 24c4_59d1_3d804844_2745_11e3_b910_001e6722eec2; Fri, 27 Sep 2013 16:20:08 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 3C4F9BFB14; Fri, 27 Sep 2013 16:20:08 +0900 (JST) Message-ID: <5245319A.5080004@it.aoyama.ac.jp> Date: Fri, 27 Sep 2013 16:19:54 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Eliot Lear References: <95AA0989-6473-4E83-861B-E84140EC083F@vpnc.org> <5245038F.4060206@it.aoyama.ac.jp> <524520B6.2000609@cisco.com> In-Reply-To: <524520B6.2000609@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Obsoletes RFC 4627 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 07:20:21 -0000 On 2013/09/27 15:07, Eliot Lear wrote: > > On 9/27/13 8:02 AM, Tim Bray wrote: >> where do =E2=80=9Cobsoletes=E2=80=9D assertions go= in the >> draft? >> > > In the header of the document. If you're using xml2rfc, in the > element as an attribute (but you would add it = to > the existing. Or directly from the DTD: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBF211E8137 for ; Fri, 27 Sep 2013 02:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.401 X-Spam-Level: X-Spam-Status: No, score=-103.401 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKPcOds+RBCa for ; Fri, 27 Sep 2013 02:02:35 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7B00D21E80E8 for ; Fri, 27 Sep 2013 02:02:32 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8R92OXT025506; Fri, 27 Sep 2013 18:02:24 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 24c4_91ff_8686486e_2753_11e3_b910_001e6722eec2; Fri, 27 Sep 2013 18:02:23 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 92460BFB14; Fri, 27 Sep 2013 18:02:23 +0900 (JST) Message-ID: <52454988.5030706@it.aoyama.ac.jp> Date: Fri, 27 Sep 2013 18:02:00 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: JSON WG , Paul Hoffman , R S Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 09:02:41 -0000 On 2013/09/27 3:50, Tim Bray wrote: > Well, except for the very first thing I tried, a modern Ruby with the > default "require 'json'", did not preserve the sign. > > I think Rob=E2=80=99s right that a large majority of modern implementat= ions do... I have pretty little experience in this area, but that may indeed be the=20 case. And it's probably fair, as Rob says in another mail, that the=20 burden of proof is on those who claim there are implementations that=20 don't respect the difference between -0 and 0. On the other hand, the=20 occurrence of something (i.e. such implementations) is way easier to=20 prove than their absence. > is that enough reason to take out the caution? What I'd propose is to leave it in, but turn it down a bit. E.g. what=20 about changing >>> but >>> implementations which read JSON texts cannot be relied upon to >>> preserve that distinction. to something like but not all implementations which read JSON texts preserve that distinction. or but a small number of implementations which read JSON texts do no preserve that distinction. or something like this. Regards, Martin. > On Thu, Sep 26, 2013 at 11:48 AM, R S wrote: > >> On Thu, Sep 26, 2013 at 11:41 AM, Paul Hoffmanw= rote: >> >>> Numbers which represent zero without a sign, for example as 0 or = 0.0 >>> not -0 or -0.0, are interoperable in the sense that software >>> implementations will agree on the zero value. Signed zeros are >>> significant in some numerically-intensive applications, but >>> implementations which read JSON texts cannot be relied upon to >>> preserve that distinction. >>> >>> On Sep 26, 2013, at 10:31 AM, R S wrote: >>> >>>> I don't think there is a rationale for the text on -0.0. Is it for >>> non-IEE754 implementations? >>> >>> Do we need to state a rationale here, or does the text stand on its o= wn? >>> >>> >> I meant that I don't see why it's in the draft at all. I propose delet= ing >> this paragraph, since I don't believe it is correct. Most implementati= ons >> can be relied upon to preserve signed zeros. >> >> - Rob >> >> >> _______________________________________________ >> 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 cabo@tzi.org Fri Sep 27 02:38:11 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A219821E8056 for ; Fri, 27 Sep 2013 02:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.867 X-Spam-Level: X-Spam-Status: No, score=-105.867 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjJ2CISIdnpQ for ; Fri, 27 Sep 2013 02:37:58 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id BF67521E808D for ; Fri, 27 Sep 2013 02:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8R9bdHc027484; Fri, 27 Sep 2013 11:37:39 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7D452E10; Fri, 27 Sep 2013 11:37:39 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <52454988.5030706@it.aoyama.ac.jp> Date: Fri, 27 Sep 2013 11:37:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52454988.5030706@it.aoyama.ac.jp> To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= X-Mailer: Apple Mail (2.1510) Cc: JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 09:38:12 -0000 > burden of proof http://www.ietf.org/mail-archive/web/json/current/msg01523.html I didn't reply to Rob's email because that already had been done. > a small number of implementations Since one's complement fell out of favor some 40 years ago, no platform = representation of integers has had a distinct negative zero. A large number of JSON implementations map a subset JSON numbers to = platform integers. (Mostly those on platforms that do not have integers don't.) (There is less commonality on the exact subset than one would like.) I would venture the guess that *all* of these implementations lose the = distinction of negative zeros for that subset they do map to integers. *All* of a large subset is not a small number. Gr=FC=DFe, Carsten From derhoermi@gmx.net Fri Sep 27 07:38:18 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCCD21F9E00 for ; Fri, 27 Sep 2013 07:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUxfGaN+OYum for ; Fri, 27 Sep 2013 07:38:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 5E16821E808A for ; Fri, 27 Sep 2013 07:38:06 -0700 (PDT) Received: from netb.Speedport_W_700V ([91.35.17.151]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0LoaCE-1W5kl40arq-00gUHR for ; Fri, 27 Sep 2013 16:38:05 +0200 From: Bjoern Hoehrmann To: R S Date: Fri, 27 Sep 2013 16:38:03 +0200 Message-ID: <795b4997e5opmtdjil1vivhi40nbh0n63d@hive.bjoern.hoehrmann.de> References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:7vWgFIGuggdx2gTU46SR/q3XxNhERoBA3JZp4CnKWKjqFUkQ6Xs rjL+E2D4TSf19rnOg3IfWEXnheemb/rrt+0zCTMIXNJiM/dr97SkHbXm9U5zi8kanAEettO Z1IcNLc8NRQTJVuGGZaY3ifFNdLwQ97VSGJJIvy3HVIW3vabP0sEsxkoT131xISQl6swNaK nx5LW3Z/jCnjmvDXnHyRQ== Cc: JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 14:38:18 -0000 * R S wrote: >On Thu, Sep 26, 2013 at 11:41 AM, Paul Hoffman wrote: > >> Numbers which represent zero without a sign, for example as 0 or 0.0 >> not -0 or -0.0, are interoperable in the sense that software >> implementations will agree on the zero value. Signed zeros are >> significant in some numerically-intensive applications, but >> implementations which read JSON texts cannot be relied upon to >> preserve that distinction. >> >> On Sep 26, 2013, at 10:31 AM, R S wrote: >> >> > I don't think there is a rationale for the text on -0.0. Is it for >> non-IEE754 implementations? >> >> Do we need to state a rationale here, or does the text stand on its own? >> >> >I meant that I don't see why it's in the draft at all. I propose deleting >this paragraph, since I don't believe it is correct. Most implementations >can be relied upon to preserve signed zeros. The primary problem with negative zero is that it is very common for number-to-string algorithms to render `-0` as `0`, and accordingly it is common that negative zero vanishes accidentally, say when you have process_json_string(json_string) and turn that into process_json_string(sanatise(json_string)) where sanatise parses, modifies, and re-serialises the json_string. As I have mentioned, ecmascript's JSON.stringify is an example of a JSON serialisation function that does not preserve negative zero. The secondary problem is that many deployed implementations treat a value like `-0` as integer value and do not preserve the sign. As an example, % perl -MJSON -e "printf '%g', JSON->new->decode('[-0]')->[0]" 0 Also in case of Perl, `-0` is not the same as `-0.0`, % perl -MJSON -e "printf '%g', JSON->new->decode('[-0.0]')->[0]" -0 -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From presnick@qti.qualcomm.com Fri Sep 27 08:21:27 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AFE21F9F5B for ; Fri, 27 Sep 2013 08:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9Z8TsP21sMU for ; Fri, 27 Sep 2013 08:21:23 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 24A7D21F9E88 for ; Fri, 27 Sep 2013 08:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1380295279; x=1411831279; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1CHkQl4vLNnYK1W86Oope2mHT/yK5hbHhR/DXlv9Enk=; b=R2aRbDjCutLmTein/5bOuO/vuTfdqYbf3GJAtCdYLbYcUZPOqQISnMav giStHOnIOxqCifsRIINayGNWErqALoMQmaSLLcxk4sOtQo9crzbD7qJeq cX6lnL9o9G06cBKym/U/xfqz3UDNvE2Ohk6Nutofh3LjHA3ydElcRQALW I=; X-IronPort-AV: E=McAfee;i="5400,1158,7210"; a="52353334" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 27 Sep 2013 08:21:18 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7210"; a="518409090" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 27 Sep 2013 08:21:18 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 27 Sep 2013 08:21:18 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 27 Sep 2013 08:21:17 -0700 Message-ID: <5245A26B.4010903@qti.qualcomm.com> Date: Fri, 27 Sep 2013 10:21:15 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Eliot Lear References: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> <20130927031731.GD27195@mercury.ccil.org> <5245231F.6050708@cisco.com> In-Reply-To: <5245231F.6050708@cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: John Cowan , Paul Hoffman , JSON WG Subject: Re: [Json] Authorship X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 15:21:27 -0000 As responsible AD for this WG: On 9/27/13 1:18 AM, Eliot Lear wrote: > > > On 9/27/13 5:17 AM, John Cowan wrote: > >> I think section 14 satisfies all authorship concerns. >> > I don't agree. Although he should not be editing now, Mr. Crockford > wrote the bulk of the text and it would be wrong to remove him from the > front. Section 14 already indicates that only a small number of > revisions have occurred. Our practice is to leave him in the author > field. We have mechanisms to deal with getting documents out the door. > It is important to indicate that he has not actively contributed to this > draft, and thus may not agree with the revision. > The chairs and I talked about this prior to the change. Yes, we do have ways to override the procedural aspects if Douglas is unresponsive, but that involves me as AD intervening and saying, "Yes, let's publish anyway." When we currently have no indication on the list that Douglas is participating, and he is not responding to repeated attempts by the chairs to contact him, I think it is unreasonable to *plan* to make an exception. If he returns to working on this, that would be great and I think he should be put back on the front page. But until then, it is clear that he can not fulfill the responsibilities of an author as described in http://www.rfc-editor.org/policy.html and that he is a contributor and not an author. We have made exceptions to this in special circumstances (an author having passed away and we wanted to give him credit posthumously), but I do not think this is one of those special circumstances. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From tony@att.com Fri Sep 27 08:35:02 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C9E11E8167 for ; Fri, 27 Sep 2013 08:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6uYAYqf+bLe for ; Fri, 27 Sep 2013 08:34:49 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3895221F9E7C for ; Fri, 27 Sep 2013 08:34:43 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 295a5425.0.2742584.00-225.7412169.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 27 Sep 2013 15:34:43 +0000 (UTC) X-MXL-Hash: 5245a5935f4517ea-308550139fe5a64258e98a025ec6f22c2ce91692 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8RFYges016957 for ; Fri, 27 Sep 2013 11:34:42 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8RFYT69016738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Sep 2013 11:34:38 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Fri, 27 Sep 2013 15:34:13 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8RFYDIY032331 for ; Fri, 27 Sep 2013 11:34:13 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8RFY8Md032177 for ; Fri, 27 Sep 2013 11:34:08 -0400 Received: from [135.70.51.8] (vpn-135-70-51-8.vpn.west.att.com[135.70.51.8]) by maillennium.att.com (mailgw1) with ESMTP id <20130927153407gw1004nhphe> (Authid: tony); Fri, 27 Sep 2013 15:34:08 +0000 X-Originating-IP: [135.70.51.8] Message-ID: <5245A56D.4080205@att.com> Date: Fri, 27 Sep 2013 11:34:05 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: R S References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <0FA0EFFF-2109-4D78-8723-2ECD990C0F82@vpnc.org> <7058DBBD-9DCE-4A5C-B11D-5FC41A839407@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------020608050404080506030400" X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=Rv1y2laK c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=W6gWnrSLzfwA:10 a=sCfsyOEanakA:10 a=CiJi1AohYQ8A:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=vx_-YKXh] X-AnalysisOut: [WkMA:10 a=m9rGlshOAAAA:8 a=2AwhE-fXiuCx13cl9bYA:9 a=wPNLvf] X-AnalysisOut: [GTeEIA:10 a=3tVY_Mm33XkA:10 a=pGLkceISAAAA:8 a=y4X5NDBnLSa] X-AnalysisOut: [4pq0av7sA:9 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 a=AGMeX00E] X-AnalysisOut: [npwQDAqR:21] Cc: JSON WG Subject: Re: [Json] Differences between RFC 4627 or the current ECMAScript specification X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 15:35:02 -0000 This is a multi-part message in MIME format. --------------020608050404080506030400 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/26/2013 9:29 PM, R S wrote: > On Thu, Sep 26, 2013 at 6:18 PM, Paul Hoffman > wrote: > ... > > > > Again, we won't be citing a future version with hypothetical > changes. > > > > > But you seem keen on us having such a section. Please provide > the full wording for what you > > > think would be valuable to include. > > > > I already have--feel free to reuse it. > > It was: > > > No. > > > > The ECMAScript specification allows primitives at the root level, > specifies exactly how to interpret numbers, and can handle "bit > sequences which cannot encode Unicode characters" just fine. > > Do others here agree with all three parts? Or is there different > suggested wording? > > > That text is not what I was referring to. Sometimes things bear repeating. Would you please provide again the exact text you were referring to so that we can discuss the correct text? Thank you. > > > > Also: You did not include the second bullet from ECMAScript 5.1, > Section 15.12. Is there a reason for that? > > > That bullet point is misleadingly worded. I can tell you this because > I wrote a widely-used JSON implementation for RFC4267 that had to be > adjusted for ECMAScript 5. The two biggest changes were to ban > trailing commas in objects and accept primitive values at the root. RFC 4627 does not allow trailing commas in objects. Nor does 4627-bis. I don't see a difference there from ECMAScript's definition. Tony Hansen --------------020608050404080506030400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/26/2013 9:29 PM, R S wrote:
On Thu, Sep 26, 2013 at 6:18 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
...

> Again, we won't be citing a future version with hypothetical changes.
>
> > But you seem keen on us having such a section. Please provide the full wording for what you
> > think would be valuable to include.
>
> I already have--feel free to reuse it.

It was:

No.
 

The ECMAScript specification allows primitives at the root level, specifies exactly how to interpret numbers, and can handle "bit sequences which cannot encode Unicode characters" just fine.

Do others here agree with all three parts? Or is there different suggested wording?

That text is not what I was referring to.

Sometimes things bear repeating. Would you please provide again the exact text you were referring to so that we can discuss the correct text? Thank you.

 

Also: You did not include the second bullet from ECMAScript 5.1, Section 15.12. Is there a reason for that?

That bullet point is misleadingly worded. I can tell you this because I wrote a widely-used JSON implementation for RFC4267 that had to be adjusted for ECMAScript 5. The two biggest changes were to ban trailing commas in objects and accept primitive values at the root.

RFC 4627 does not allow trailing commas in objects. Nor does 4627-bis. I don't see a difference there from ECMAScript's definition.

    Tony Hansen

--------------020608050404080506030400-- From sayrer@gmail.com Fri Sep 27 09:34:17 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B4321F9611 for ; Fri, 27 Sep 2013 09:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpNDkJzFq+2G for ; Fri, 27 Sep 2013 09:34:16 -0700 (PDT) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF5621F99DD for ; Fri, 27 Sep 2013 09:34:09 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id a11so1993285qen.9 for ; Fri, 27 Sep 2013 09:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YEjZJ9UEbU4lEduJJPagoFtgdyrBPcr2mvzNGVSgcnY=; b=nYzzfW+Kc4hYdYVVCc9+Zo8am+fTIivIZu/RGS2IYFK9bd7vEqKaYYaRRwiZpGuwUf TRGI0eBjOzm0fgWb6ReHvQr6VhIOcYTEdgrVdwC8Ov6nb6v/T6owvTBzJkPPDFZ9nRbB YmXGdylB19bC/81V5z6258PiOQx30hc10qosPmoxJlQBW7YLTyf7OqXKanjITcfYMg3L lxFDfuME1ddIQCq2kB7jHs+RSq8dptefXi+bNq5pOmX0mGcgOY2AVR2ru0JS8AiKkeL5 6b1Q5IBuc83FM/27PFaihVr2bomQJNbWpMl1H2AVPCpEcQCiWZmHDmehgtc/Y6u3zSFU 3LQg== MIME-Version: 1.0 X-Received: by 10.49.132.233 with SMTP id ox9mr10476133qeb.36.1380299641544; Fri, 27 Sep 2013 09:34:01 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Fri, 27 Sep 2013 09:34:01 -0700 (PDT) In-Reply-To: <5245A56D.4080205@att.com> References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <0FA0EFFF-2109-4D78-8723-2ECD990C0F82@vpnc.org> <7058DBBD-9DCE-4A5C-B11D-5FC41A839407@vpnc.org> <5245A56D.4080205@att.com> Date: Fri, 27 Sep 2013 09:34:01 -0700 Message-ID: From: R S To: Tony Hansen Content-Type: multipart/alternative; boundary=047d7bdc7ffad1652404e7600d11 Cc: JSON WG Subject: Re: [Json] Differences between RFC 4627 or the current ECMAScript specification X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 16:34:17 -0000 --047d7bdc7ffad1652404e7600d11 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 27, 2013 at 8:34 AM, Tony Hansen wrote: > RFC 4627 does not allow trailing commas in objects. Nor does 4627-bis. > RFC 4627 allows parsers to accept non-JSON if they wish, while ECMAScript does not allow this. - Rob --047d7bdc7ffad1652404e7600d11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 27, 2013 at 8:34 AM, Tony Hansen <tony@att.com= > wrote:
RFC 4627 does not allow trailing commas in objects. Nor does 4627-bis.=A0

RFC 4627 allows pars= ers to accept non-JSON if they wish, while ECMAScript does not allow this.<= /div>

- Rob=A0
--047d7bdc7ffad1652404e7600d11-- From cabo@tzi.org Fri Sep 27 09:51:22 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F8411E8103 for ; Fri, 27 Sep 2013 09:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.176 X-Spam-Level: X-Spam-Status: No, score=-106.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzOOaFjGY1Hj for ; Fri, 27 Sep 2013 09:51:16 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DA09F21F9D52 for ; Fri, 27 Sep 2013 09:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8RGp8BT002016; Fri, 27 Sep 2013 18:51:08 +0200 (CEST) Received: from [192.168.217.105] (p54894B0C.dip0.t-ipconnect.de [84.137.75.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3416FC3; Fri, 27 Sep 2013 18:51:08 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 27 Sep 2013 18:51:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <557737B3-DE5D-49C8-9CE4-AAE4B9B0529B@tzi.org> References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <0FA0EFFF-2109-4D78-8723-2ECD990C0F82@vpnc.org> <7058DBBD-9DCE-4A5C-B11D-5FC41A839407@vpnc.org> <5245A56D.4080205@att.com> To: R S X-Mailer: Apple Mail (2.1510) Cc: Tony Hansen , JSON WG Subject: Re: [Json] Differences between RFC 4627 or the current ECMAScript specification X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 16:51:22 -0000 > RFC 4627 allows parsers to accept non-JSON if they wish, while = ECMAScript does not allow this. That is not really the difference. ECMA-262 defines one implementation of JSON (and its API). Of course, = ECMA-262 can go ahead and define all the desired the characteristics of = the implementation, including not accepting extensions. RFC 4627 defines JSON the format. It could go ahead and put down a = "MUST NOT extend". At best, the result would be for a subset of the = implementations to offer a "conforming mode". All the rest, and the = default setting of most implementations, will still accept trailing = punctuation, comments in various forms, random variant interpretations = of string content depending on whether a character is escaped or not, = etc. The definition of soup. But that fact of life doesn't have = anything to do with the definition of JSON. Gr=FC=DFe, Carsten From derhoermi@gmx.net Fri Sep 27 11:13:24 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9B911E8166 for ; Fri, 27 Sep 2013 11:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D36QcH63jSAY for ; Fri, 27 Sep 2013 11:13:20 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD4D11E8164 for ; Fri, 27 Sep 2013 11:13:17 -0700 (PDT) Received: from netb.Speedport_W_700V ([91.35.17.151]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MarAM-1VAgz83GwM-00KO4b for ; Fri, 27 Sep 2013 20:13:17 +0200 From: Bjoern Hoehrmann To: Paul Hoffman Date: Fri, 27 Sep 2013 20:13:16 +0200 Message-ID: References: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> In-Reply-To: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:AkwP5e7LSbh/FClbswll+HlSzOd67cwBjzu7CCEquifL/d+/6Rl lyqa2gI4ysPW7i7CBxIXrBiQyKCusQtlwI8pCV3jCP2iOuAKzSjdMusm1l+5VgsokBiUVWX 2HC0in3J2mzrOP7I53uzwcefVpzbiLGyMA/v3MSl4gtskqIp3w80Z9NTwLRISruULIr5Xfm U8jfuRkYwB105NeagYUFg== Cc: JSON WG Subject: Re: [Json] Authorship X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 18:13:24 -0000 * Paul Hoffman wrote: >- He can cause the eventual RFC to never be published by never >responding during AUTH48, the last step in the RFC publication process. >That would mean that the hard work that many people have done here would >be a waste of time and energy. I note that RFC 4627 awards him change control over application/json... -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From jorge@jorgechamorro.com Fri Sep 27 12:31:14 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB3A21F9F96 for ; Fri, 27 Sep 2013 12:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuWxz6m-jiiI for ; Fri, 27 Sep 2013 12:31:08 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id AB01511E80E8 for ; Fri, 27 Sep 2013 12:31:07 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hm2so1331602wib.0 for ; Fri, 27 Sep 2013 12:31:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=kLYXI1xSUX+kXMQqF6+LZ23IGWrnk986xcTk3yCFH3I=; b=dYUgDnbi/xbZ36XbxD7/GemzGFHleWdkj7B1thKVAl9II6gvaDQ+wM5y9VAeYFMpTB vnHrWYi7qkMb64xkVhNRxubVRGI1iMyR1mZSdfKNGrELFGhuKB2HXSFKRxcZ/5Q7FDSt kIiFqxSu5sGte+i08EGL8gHplS3Hzhwo5skt72Q0slULcI3+1OqW/X5N69Ou83/d8o/u xppsaGH/1uNdVbLzryHt1uyckAQnhz7SutHs8OEBH1DOoVYMGFOrgc63hnNrzBIYjOvd t4qEPVeANtHmPsI/j/MaH6M9nqHdSZf17Xe2KMt90KBQ4Ta3adOUSd52prfcbN++fPAT aCQQ== X-Gm-Message-State: ALoCoQmPD8C4pRpSTPM9xO+e9aG1fUXAgszwUVr/OFE9eptYEC2zyys59u/lcNs9me5bu4kOiNHm X-Received: by 10.194.174.36 with SMTP id bp4mr6934125wjc.7.1380310266431; Fri, 27 Sep 2013 12:31:06 -0700 (PDT) Received: from [192.168.10.50] (160.Red-88-0-222.dynamicIP.rima-tde.net. [88.0.222.160]) by mx.google.com with ESMTPSA id e1sm41483052wij.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 12:31:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Jorge Chamorro In-Reply-To: Date: Fri, 27 Sep 2013 21:31:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130926165817.29653.83100.idtracker@ietfa.amsl.com> To: Tim Bray , "json@ietf.org WG" X-Mailer: Apple Mail (2.1085) Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-04.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 19:31:14 -0000 On 26/09/2013, at 18:59, Tim Bray wrote: > I think this catches up with the state of WG discussion. -T "numbers which are integers, are in the range [-(2**53)+1, (2**53)-1], = and are represented without "frac" or "exp" parts (for example as 3 not = 3.0), are interoperable in the sense that implementations will agree = exactly on the numeric values." I don't get what's with the "without 'frac' or 'exp' parts" part. I mean, don't 3, 3.0, 30e-1 or even 0.000000000000000000000000003e27 = produce the same ieee754:double? At least in JavaScript all of them are =3D=3D=3D. Thank you, --=20 ( Jorge )();= From cowan@ccil.org Fri Sep 27 13:24:40 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB4221F9ED4 for ; Fri, 27 Sep 2013 13:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3mOj33Dw2w4 for ; Fri, 27 Sep 2013 13:24:36 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1873F21F92B2 for ; Fri, 27 Sep 2013 13:24:36 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VPeaX-0006hR-JX; Fri, 27 Sep 2013 16:24:33 -0400 Date: Fri, 27 Sep 2013 16:24:33 -0400 From: John Cowan To: Jorge Chamorro Message-ID: <20130927202433.GA24460@mercury.ccil.org> References: <20130926165817.29653.83100.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , "json@ietf.org WG" Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-04.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 20:24:40 -0000 Jorge Chamorro scripsit: > I mean, don't 3, 3.0, 30e-1 or even 0.000000000000000000000000003e27 > produce the same ieee754:double? In languages that don't treat 3 as generating a fixed-point value, yes. > At least in JavaScript all of them are ===. JavaScript is one of those. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Most people are much more ignorant about language than they are about [other subjects], but they reckon that because they can talk and read and write, their opinions about talking and reading and writing are as well informed as anybody's. And since I have DNA, I'm entitled to carry on at length about genetics without bothering to learn anything about it. Not. --Mark Liberman From cowan@ccil.org Fri Sep 27 14:41:51 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A80D21F9F45 for ; Fri, 27 Sep 2013 14:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.133 X-Spam-Level: X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZ+N1vZVmbGL for ; Fri, 27 Sep 2013 14:41:46 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0F221E8053 for ; Fri, 27 Sep 2013 14:41:45 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VPfn7-000635-Sf; Fri, 27 Sep 2013 17:41:37 -0400 Date: Fri, 27 Sep 2013 17:41:37 -0400 From: John Cowan To: =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= Message-ID: <20130927214137.GC24460@mercury.ccil.org> References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52454988.5030706@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52454988.5030706@it.aoyama.ac.jp> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: R S , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 21:41:51 -0000 "Martin J. Dürst" scripsit: > I have pretty little experience in this area, but that may indeed be > the case. And it's probably fair, as Rob says in another mail, that > the burden of proof is on those who claim there are implementations > that don't respect the difference between -0 and 0. $ python Python 2.7.3 (default, Dec 18 2012, 13:50:09) [GCC 4.5.3] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import json >>> json.loads("[-0]") [0] >>> json.loads("[-0.0]") [-0.0] >>> There you go (and ultrajson behaves the same way). Saying "most" involves counting implementations, which is hard. -- John Cowan Yakka foob mog. Grug pubbawup zink wattoom gazork. Chumble spuzz. --Calvin, giving Newton's First Law "in his own words" From mamille2@cisco.com Fri Sep 27 14:48:53 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2132A21F852A for ; Fri, 27 Sep 2013 14:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dETquthDmEGx for ; Fri, 27 Sep 2013 14:48:45 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7068E21F9D4C for ; Fri, 27 Sep 2013 14:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7095; q=dns/txt; s=iport; t=1380318515; x=1381528115; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vxVGqb+B4qizN9kXfEl7/JoPDywcUnbR6840gnrlV0c=; b=TYvDnU2xMw9mnA6hQCAaDgZcJ8RyY73yeG9FzISE7ieX4nPtCMNZQhwP 8ibA7vy8e9SODigKkjOMK7yezgh0kwIjbKuzhbFuoAF/R4glwr8aESx8U KQxh7pXD69HuQV4WdYZx90NkWxTVHSDVpMMYBYjV4mnVneEMkwnwZANOV I=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKP8RVKtJV2d/2dsb2JhbABbgweBCsBTgSEWdIImAQEEeRACAQgiJAIwJQIEDgUIBod4uiaNfRuBCBYbB4MfgQEDkCeBMJgggySBcTk X-IronPort-AV: E=Sophos;i="4.90,996,1371081600"; d="p7s'?scan'208";a="265517861" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 27 Sep 2013 21:48:34 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8RLmYRW010407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Sep 2013 21:48:34 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.253]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 16:48:34 -0500 From: "Matt Miller (mamille2)" To: John Cowan Thread-Topic: [Json] -0.0 Thread-Index: AQHOuugEUSCaY6lTdk6W2AG6IUkDfJnYr/CAgAAAmYCAAO3sAIAA1DyAgAAB8IA= Date: Fri, 27 Sep 2013 21:48:33 +0000 Message-ID: References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52454988.5030706@it.aoyama.ac.jp> <20130927214137.GC24460@mercury.ccil.org> In-Reply-To: <20130927214137.GC24460@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.48] Content-Type: multipart/signed; boundary="Apple-Mail=_68CA2302-3091-47A3-967C-887EBCAD0092"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= , JSON WG , Tim Bray , Paul Hoffman , R S Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 21:48:53 -0000 --Apple-Mail=_68CA2302-3091-47A3-967C-887EBCAD0092 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Sep 27, 2013, at 3:41 PM, John Cowan wrote: > "Martin J. D=FCrst" scripsit: >=20 >> I have pretty little experience in this area, but that may indeed be >> the case. And it's probably fair, as Rob says in another mail, that >> the burden of proof is on those who claim there are implementations >> that don't respect the difference between -0 and 0.=20 >=20 > $ python > Python 2.7.3 (default, Dec 18 2012, 13:50:09) > [GCC 4.5.3] on cygwin > Type "help", "copyright", "credits" or "license" for more information. >>>> import json >>>> json.loads("[-0]") > [0] >>>> json.loads("[-0.0]") > [-0.0] >>>>=20 >=20 > There you go (and ultrajson behaves the same way). Saying "most" > involves counting implementations, which is hard. >=20 /me dons hat It appears to me that we are rehashing arguments made when this text was = first discussed. Are we bringing up any new considerations here? - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_68CA2302-3091-47A3-967C-887EBCAD0092 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5MjcyMTQ4 MzNaMCMGCSqGSIb3DQEJBDEWBBTJA1daiaZt+dTgEYrP9Fz80iAyBDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAI+e xezkvHBV0Ri33R3R/2XhsCkfe51WRN0bLgIRf5QlL3s3y2v112dP7qXgahI0aXIN+R2P4D2/thkg XAIktdq6b9scL3O/lDdRsEPUntiYJzH8RD9cLAa8AIVbG4ZxndjFeul+fmQd+tz0fiz1xX5F96Dr Aad/NSHuNUOGRBbnAciKqUHIKws2VL6Xn70WqjeJQjEHDupB7z/CdFlYcLj8eKDqN1mwpJVr4Zxa UyZW+eJg6Wa3bxXoAX8NxrZXFZU4mMBLZt5L+ltGZn51HUdAHRPHkOUnaKkiqS1Cbffqir3AgZjc 45RoUgO2ym2/STuTkWw0HqanW7nmjex9FM8AAAAAAAA= --Apple-Mail=_68CA2302-3091-47A3-967C-887EBCAD0092-- From sayrer@gmail.com Fri Sep 27 15:12:42 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E21821F9A61 for ; Fri, 27 Sep 2013 15:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE6j7M0BITHx for ; Fri, 27 Sep 2013 15:12:41 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9882A21F8E51 for ; Fri, 27 Sep 2013 15:12:41 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id k15so886248qaq.2 for ; Fri, 27 Sep 2013 15:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l4xERd5VftqgzprYnRBNeHQmnrMIATW8CUj20viFwVc=; b=wf7w9vILCHxs9gruS9xL2KLodPJVS/xto2SnKdMRpi5XA3ykVfB3pIZabcGrwgLT9B e+gdmOiiPcdwEHm7a51ptncJLfG51boN0inqd22J6aIDIsXyvtgz+1dCKNUPDcnmf+Ty SeFsyuW1E4Lb8l54jIgWfcqtU36L+6wVGtHfF0VqDG8lEAthIUKDGrEtx5uFw7/PUN1F +f0vOH+K3FX3t4nM9Wtwm3esZTuOZFT/igLxFjM7rcojfUpJ2AcDu1oCjAdo6J7zabMk NEw4IG7YiEamSnpveXEHplnlVXpN9l2K+kSzkzOAeyKACftPiWUPiPApfr4l/bydoM2a 1vpw== MIME-Version: 1.0 X-Received: by 10.224.167.18 with SMTP id o18mr17043934qay.87.1380319961043; Fri, 27 Sep 2013 15:12:41 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Fri, 27 Sep 2013 15:12:40 -0700 (PDT) In-Reply-To: References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52454988.5030706@it.aoyama.ac.jp> <20130927214137.GC24460@mercury.ccil.org> Date: Fri, 27 Sep 2013 15:12:40 -0700 Message-ID: From: R S To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=089e01294f5af45a3804e764c83a Cc: Tim Bray , =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= , John Cowan , Paul Hoffman , JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 22:12:42 -0000 --089e01294f5af45a3804e764c83a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 27, 2013 at 2:48 PM, Matt Miller (mamille2) wrote: > > It appears to me that we are rehashing arguments made when this text was > first discussed. Are we bringing up any new considerations here? > Yes. The text in the current draft refers to both -0 and -0.0 as though they are interoperable. - Rob --089e01294f5af45a3804e764c83a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 27, 2013 at 2:48 PM, Matt Miller (mamille2) <mamille2@cisco.com> wrote:

It appears to me that we are rehashing arguments made when this text was fi= rst discussed. =A0Are we bringing up any new considerations here?

Yes. The text in the current draft refers to bot= h -0 and -0.0 as though they are interoperable.

- Rob
=A0

--089e01294f5af45a3804e764c83a-- From sayrer@gmail.com Fri Sep 27 15:15:11 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D9621F9D71 for ; Fri, 27 Sep 2013 15:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuaB6j9urixZ for ; Fri, 27 Sep 2013 15:15:10 -0700 (PDT) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E783F21F9DC9 for ; Fri, 27 Sep 2013 15:15:09 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id x7so2268060qeu.5 for ; Fri, 27 Sep 2013 15:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hjMyK116/JlD9SAi/5CqBkEumZXjXchcsj3nxesed4A=; b=KGqRQGBPJ8RCxghSgr3T1GR+zYtrn9jSCwFfqOYE/HtafUaO4U8Ngs9xiTG/5MaIgI UdCw8L2gKMBEGuhaaBWvNnAN1e2gZnTtO7ZxH+C5eaCINUh9IlSPnzbEOhE8WUP4ma8c 0Qc8Q1m9AfQLL13zDmBfEA6vBlt5uzwU11IbDZZ1uYDb+rRlEDqjUT/Ikk/1k/75uvrR 0ISHfD3bA9Wde+Wf7wvV0hcRAFL0KZQqmAUa32mSCYJLbJZKDhlxiBrEhI0vOCijKjZA 5g4AH84wlrMhLCBVXMyV+Y52iCYQviItZwqnwJszYbsqyV5AcAKp87Js6i1uaqPPDrNh A2uA== MIME-Version: 1.0 X-Received: by 10.49.81.237 with SMTP id d13mr12043676qey.44.1380320109272; Fri, 27 Sep 2013 15:15:09 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Fri, 27 Sep 2013 15:15:09 -0700 (PDT) In-Reply-To: References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52454988.5030706@it.aoyama.ac.jp> <20130927214137.GC24460@mercury.ccil.org> Date: Fri, 27 Sep 2013 15:15:09 -0700 Message-ID: From: R S To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=047d7b6d9992ca261c04e764d1bf Cc: Tim Bray , =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= , John Cowan , Paul Hoffman , JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 22:15:11 -0000 --047d7b6d9992ca261c04e764d1bf Content-Type: text/plain; charset=ISO-8859-1 On Friday, September 27, 2013, R S wrote: > On Fri, Sep 27, 2013 at 2:48 PM, Matt Miller (mamille2) < > mamille2@cisco.com >wrote: > >> >> It appears to me that we are rehashing arguments made when this text was >> first discussed. Are we bringing up any new considerations here? >> > > Yes. The text in the current draft refers to both -0 and -0.0 as though > they are interoperable. > Rather, it refers to them both as though they have the same interoperability considerations. - Rob --047d7b6d9992ca261c04e764d1bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Friday, September 27, 2013, R S wrote:
On Fri, Sep 27, 2013 at 2:48 PM, Matt Miller (ma= mille2) <mamille2@cisco.com>= ; wrote:

It appears to me that we are rehashing arguments made when this text was fi= rst discussed. =A0Are we bringing up any new considerations here?

Yes. The text in the current draft refers to bot= h -0 and -0.0 as though they are interoperable.

Rather, it refers to the= m both=A0as though they have the same interoperability conside= rations.

- Rob
--047d7b6d9992ca261c04e764d1bf-- From sayrer@gmail.com Fri Sep 27 15:20:23 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D56A21F9DCB for ; Fri, 27 Sep 2013 15:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn7l7NCTXK8b for ; Fri, 27 Sep 2013 15:20:22 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 68AB521F9DC7 for ; Fri, 27 Sep 2013 15:20:22 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id gh4so2260389qeb.2 for ; Fri, 27 Sep 2013 15:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xMRJLN3PmiBYxY3JeYF7feYZjZ/Dtav1ipSdW4u/CfM=; b=cleh3m7X2tMtHoYD2llqeJ/RSoopsTLy0UCmr8VRxs3nRUIaw61Mq+q5S7BF6gxrkh EY/J9mmxfTTxb/H8+HScwtvJv02puJnqNSDL51g+rQySZQnuwvbG4FJzM+FIyQYrGq0k WwzwPKaXD3xHKE9otx5nruc376W2pBVgNmh39DjOrD3qnctSOrBY5LMEG0Wd7jovsSYH ZAidYI+UOkdl3sufBtJn8nTvhoDi/LHP6zIGkq87rBbprUW75pv7bTfWpif2XwMMbH3E ehNHO9oRGVgwvMZZI1JHhtJ4TQNUBpsBMCzUC4Zgvd0T3SMOFezFt+fffzF/v6+SJU8l N1Dg== MIME-Version: 1.0 X-Received: by 10.224.114.81 with SMTP id d17mr17070481qaq.18.1380320421898; Fri, 27 Sep 2013 15:20:21 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Fri, 27 Sep 2013 15:20:21 -0700 (PDT) In-Reply-To: References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52454988.5030706@it.aoyama.ac.jp> <20130927214137.GC24460@mercury.ccil.org> Date: Fri, 27 Sep 2013 15:20:21 -0700 Message-ID: From: R S To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=047d7bea3a346c73af04e764e424 Cc: Tim Bray , =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= , John Cowan , Paul Hoffman , JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 22:20:23 -0000 --047d7bea3a346c73af04e764e424 Content-Type: text/plain; charset=ISO-8859-1 Further, let me hasten to add that this thread is titled "-0.0" and I wrote: > I don't think there is a rationale for the text on -0.0. I did not write "negative zero" or "-0". I think this thread and the text in the draft shows that the WG didn't fully understand what the chairs took to be consensus. It was nearly a mistake, but it would have been *fine* if the WG let the existing "implementations may place limitations on the range of numbers accepted" text stand. Why not do that? - Rob On Fri, Sep 27, 2013 at 3:15 PM, R S wrote: > > > On Friday, September 27, 2013, R S wrote: > >> On Fri, Sep 27, 2013 at 2:48 PM, Matt Miller (mamille2) < >> mamille2@cisco.com> wrote: >> >>> >>> It appears to me that we are rehashing arguments made when this text was >>> first discussed. Are we bringing up any new considerations here? >>> >> >> Yes. The text in the current draft refers to both -0 and -0.0 as though >> they are interoperable. >> > > Rather, it refers to them both as though they have the same > interoperability considerations. > > - Rob > --047d7bea3a346c73af04e764e424 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Further, let me hasten to add that this thr= ead is titled "-0.0" and I wrote:

> I don't think t= here is a rationale for the text on -0.0.

I did not write &quo= t;negative zero" or "-0".

I think this thread and the text in the draft shows that the WG d= idn't fully understand what the chairs took to be consensus. It was nea= rly a mistake, but it would have been *fine* if the WG let the existing &qu= ot;implementations may place limitations on the range of numbers accepted&q= uot; text stand. Why not do that?

- Rob



On Fri, Sep 27, 2013 at 3:= 15 PM, R S <sayrer@gmail.com> wrote:

=
On Friday, September 27, 2013, R S wrote:
On Fri, Sep 27, 2013 at 2:48 PM, Matt Miller (mamille2) <mamille2@cisco.com> wrote:

It appears to me that we are rehashing arguments made when this text was fi= rst discussed. =A0Are we bringing up any new considerations here?

Yes. The text in the current draft refers to bot= h -0 and -0.0 as though they are interoperable.

Rather, it r= efers to them both=A0as though they have the same interoperabi= lity considerations.

- Rob

--047d7bea3a346c73af04e764e424-- From cowan@ccil.org Fri Sep 27 15:41:57 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A634811E8102 for ; Fri, 27 Sep 2013 15:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYjRusWQkJyg for ; Fri, 27 Sep 2013 15:41:53 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1D00811E8114 for ; Fri, 27 Sep 2013 15:41:52 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VPgjM-0003sh-Lk; Fri, 27 Sep 2013 18:41:48 -0400 Date: Fri, 27 Sep 2013 18:41:48 -0400 From: John Cowan To: R S Message-ID: <20130927224148.GE24460@mercury.ccil.org> References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52454988.5030706@it.aoyama.ac.jp> <20130927214137.GC24460@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Martin =?iso-8859-1?Q?J=2E_D=FCrst?= , JSON WG , Tim Bray , Paul Hoffman , "Matt Miller \(mamille2\)" Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 22:41:57 -0000 R S scripsit: > I think this thread and the text in the draft shows that the WG didn't > fully understand what the chairs took to be consensus. It was nearly > a mistake, but it would have been *fine* if the WG let the existing > "implementations may place limitations on the range of numbers accepted" > text stand. Why not do that? Failure to distinguish between zero and negative zero is not a limitation of range. Limitations of precision are not limitations of range. -- If you have ever wondered if you are in hell, John Cowan it has been said, then you are on a well-traveled http://www.ccil.org/~cowan road of spiritual inquiry. If you are absolutely cowan@ccil.org sure you are in hell, however, then you must be on the Cross Bronx Expressway. --Alan Feuer, NYTimes, 2002-09-20 From sayrer@gmail.com Fri Sep 27 15:43:37 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9692311E80DE for ; Fri, 27 Sep 2013 15:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAmudCTPtQ1w for ; Fri, 27 Sep 2013 15:43:37 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0839E21F9ECE for ; Fri, 27 Sep 2013 15:43:36 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j15so901007qaq.3 for ; Fri, 27 Sep 2013 15:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LoMKVZuCgQzK80Vek0J5zJggiPo4qkyE1/iMVzZeeNI=; b=dNXIj51pQujHD0c1/9GFkzxdRwg6fFiWA9AZTeb0E9N08ovOzqwkIYdNNzDcvohAS+ kYsQbBvYYMWPW9nNx7MULiCE/fKLC9EeXOXc2AEmAKvfuH6U6LjiFA24pJv09hTm7L6k Q9A3490fdNc3IVCl2gncPTlzNzohzDUVDBydN9m3JV4C4J8/JUoR60zBZhCKepbrOAWw tfSpgOmfPOtSJizJeV4/WJVYwOFq0axWEKQdhuhGEJpv/SccTBBsTvTQ7hVGnzkqd66f k/CYUfOZg675maS3NM7ykbEiRpTMWWj51Rt3jddpP/HkZQzumvTy7vvEUoi4bHtNPRjt JQkw== MIME-Version: 1.0 X-Received: by 10.229.204.133 with SMTP id fm5mr12236854qcb.23.1380321816515; Fri, 27 Sep 2013 15:43:36 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Fri, 27 Sep 2013 15:43:36 -0700 (PDT) In-Reply-To: <20130927224148.GE24460@mercury.ccil.org> References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52454988.5030706@it.aoyama.ac.jp> <20130927214137.GC24460@mercury.ccil.org> <20130927224148.GE24460@mercury.ccil.org> Date: Fri, 27 Sep 2013 15:43:36 -0700 Message-ID: From: R S To: John Cowan Content-Type: multipart/alternative; boundary=001a11c2be668c9c7804e765377e Cc: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= , JSON WG , Tim Bray , Paul Hoffman , "Matt Miller \(mamille2\)" Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 22:43:37 -0000 --001a11c2be668c9c7804e765377e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 27, 2013 at 3:41 PM, John Cowan wrote: > R S scripsit: > > > I think this thread and the text in the draft shows that the WG didn't > > fully understand what the chairs took to be consensus. It was nearly > > a mistake, but it would have been *fine* if the WG let the existing > > "implementations may place limitations on the range of numbers accepted" > > text stand. Why not do that? > > Failure to distinguish between zero and negative zero is not a limitation > of range. > > Limitations of precision are not limitations of range. Do you want to change the text to say "implementations may place limitations on the range and precision..." ? That's totally true--I would be in favor. - Rob --001a11c2be668c9c7804e765377e Content-Type: text/html; charset=ISO-8859-1
On Fri, Sep 27, 2013 at 3:41 PM, John Cowan <cowan@mercury.ccil.org> wrote:
R S scripsit:

> I think this thread and the text in the draft shows that the WG didn't
> fully understand what the chairs took to be consensus. It was nearly
> a mistake, but it would have been *fine* if the WG let the existing
> "implementations may place limitations on the range of numbers accepted"
> text stand. Why not do that?

Failure to distinguish between zero and negative zero is not a limitation
of range.

Limitations of precision are not limitations of range.

Do you want to change the text to say "implementations may place limitations on the range and precision..." ?

That's totally true--I would be in favor.

- Rob
--001a11c2be668c9c7804e765377e-- From jorge@jorgechamorro.com Sat Sep 28 07:34:11 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4163521F99F7 for ; Sat, 28 Sep 2013 07:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.312 X-Spam-Level: X-Spam-Status: No, score=-3.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjlAftqBb+OZ for ; Sat, 28 Sep 2013 07:34:05 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1578E21F960E for ; Sat, 28 Sep 2013 07:34:04 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id f12so3902791wgh.29 for ; Sat, 28 Sep 2013 07:34:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ng66iD6xnbpg5kf2fs1MsjvomMhdrVxlnvPrtbBltXU=; b=fApH3Uui8VRD3l9M1OzTnas7YcZ3GLYzQHVlyG5LgiChgoYj6Pg124FM/2hYpbyF/d lBZmYuPQfGmqGGTmeMHXGtrqqI33pv+4IBgTIs4hWvsjeFldyF3OC95viEAJk7FE/DRi Uek/u/SfN3MT84ENAmCniFYgL1WRZxdBdI79RUOIjTivdOhwUU+Paje2t1DagTDvomiF 1l3INerzsCP4osMocomgyEdzS0sorbnmnQUL/disOf06gmdHwayeYCK62f6JBgGqrIX7 aOfma6N0pyE+3LjI+P+K5wonDRv72F9EwpqltKhqOcLuVh27LShpvmHTjcpyQljJWGF8 VqUw== X-Gm-Message-State: ALoCoQl9JJ31ERbcVUDeuuDSRSzrYQCg/2DVY5Fr2V/2Fz75lTqvW9jjVHyWSzZhv0fEEYTZiich X-Received: by 10.180.13.83 with SMTP id f19mr6759734wic.54.1380378841847; Sat, 28 Sep 2013 07:34:01 -0700 (PDT) Received: from [192.168.10.50] (160.Red-88-0-222.dynamicIP.rima-tde.net. [88.0.222.160]) by mx.google.com with ESMTPSA id c4sm6826685wiz.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Sep 2013 07:34:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Jorge Chamorro In-Reply-To: <20130927202433.GA24460@mercury.ccil.org> Date: Sat, 28 Sep 2013 16:33:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <236C32A4-6EA5-4B9D-9265-0447A5A19ECA@jorgechamorro.com> References: <20130926165817.29653.83100.idtracker@ietfa.amsl.com> <20130927202433.GA24460@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1085) Cc: Tim Bray , "json@ietf.org WG" Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-04.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2013 14:34:11 -0000 On 27/09/2013, at 22:24, John Cowan wrote: > Jorge Chamorro scripsit: >=20 >> I mean, don't 3, 3.0, 30e-1 or even 0.000000000000000000000000003e27 >> produce the same ieee754:double? >=20 > In languages that don't treat 3 as generating a fixed-point value, = yes. But that phrase doesn't belong there. Look, the text begins with: " (...) Since software which implements IEEE 754-2008 [IEEE754] is = generally available and widely used, good interoperability can be = achieved by implementations which expect no more precision or range than = provided by an IEEE 754 binary64 (double precision) number (...)" Then says: "Note that when such software is used [ <-- "software which implements = IEEE 754-2008" ] numbers which are integers, are in the range = [-(2**53)+1, (2**53)-1], and are represented without "frac" or "exp" = parts (for example as 3 not 3.0), are interoperable in the sense that = implementations will agree exactly on the numeric values" But when "software which implements IEEE 754-2008" is used, it doesn't = matter whether the integers are represented with or without "frac" or = "exp" parts. If it's meant for the "languages that treat 3 as generating a = fixed-point value", it's misplaced, ISTM. For languages that treat 3 as a fixed-point value the range [-(2**53)+1, = (2**53)-1] may or may not be an adequate range. The 4 bytes 'long' is = quite a common type for integers. And because the most common fp type is the double, in such a language a = 3.0 instead of a 3 might happen to result in perfect interoperability, = but that phrase somehow recommends against it. I would remove the =B4and are represented without "frac" or "exp" parts = (for example as 3 not 3.0)=B4 phrase entirely.=20 >> At least in JavaScript all of them are =3D=3D=3D. >=20 > JavaScript is one of those. Yes. From jorge@jorgechamorro.com Sat Sep 28 07:39:52 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA2821F9FA3 for ; Sat, 28 Sep 2013 07:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtaiUdXg0yRV for ; Sat, 28 Sep 2013 07:39:46 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3682821F9EAD for ; Sat, 28 Sep 2013 07:39:45 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id b13so3791303wgh.11 for ; Sat, 28 Sep 2013 07:39:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=KmUY36Ix7nTajuNxOFBe5xMEh0w0MQg1MpEXXEEpQ4c=; b=Q5wrZ5/g9Ngftz1iFby6+dxxmBu2zpegJfM1smVq/YrcOKv14YqrWdxIb4djseX16s vvrQ9u6kMnOVMbh+uVUPxV67yyJxquS1+eiJpQ5ZeCBOZFgnu5xGbZgifkNaifzdgzaq ivH2DWCsBXHOWNZFvHPaNszA+fGNO0OSU8UCK9c6LZ4Qkh1xmrdRHl4a852+3M1Yo33m QonH2DOnjApGmA+/trHuai5k0y9gZ6XUpgeKGye5AI9EM4+XLexEIekq1TIMmgbShHOx NEwaIJXIucq9aiYzI9/31o3JQJrqnwWTbfrLJRsFhc1hFsrhcggCNz3/GLyh0hvc4vnk +JTQ== X-Gm-Message-State: ALoCoQkhexZhIO3KDZRvGBE887zaJGIFib5F1nuf5kx4tfGHF01l6CEHb5E0zHpdcJi/c1pknds1 X-Received: by 10.180.184.107 with SMTP id et11mr6864749wic.60.1380379184397; Sat, 28 Sep 2013 07:39:44 -0700 (PDT) Received: from [192.168.10.50] (160.Red-88-0-222.dynamicIP.rima-tde.net. [88.0.222.160]) by mx.google.com with ESMTPSA id q5sm6850267wiz.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Sep 2013 07:39:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: <236C32A4-6EA5-4B9D-9265-0447A5A19ECA@jorgechamorro.com> Date: Sat, 28 Sep 2013 16:39:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F983F7C-EF40-4F3A-AC33-D43FE44276FF@jorgechamorro.com> References: <20130926165817.29653.83100.idtracker@ietfa.amsl.com> <20130927202433.GA24460@mercury.ccil.org> <236C32A4-6EA5-4B9D-9265-0447A5A19ECA@jorgechamorro.com> To: "json@ietf.org WG" X-Mailer: Apple Mail (2.1085) Cc: Tim Bray , John Cowan Subject: Re: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-04.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2013 14:39:52 -0000 On 28/09/2013, at 16:33, Jorge Chamorro wrote: >=20 > in such a language a 3.0 instead of a 3 might happen to result in = perfect interoperability, but that phrase somehow recommends against it. A 4294967296.0 instead of a 4294967296, for example. (It's 2**32) --=20 ( Jorge )();= From sayrer@gmail.com Sat Sep 28 14:52:34 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3409021E8115 for ; Sat, 28 Sep 2013 14:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szA1YEpAv8gi for ; Sat, 28 Sep 2013 14:52:33 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AECFA21E811F for ; Sat, 28 Sep 2013 14:52:29 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id v2so2646114qcr.34 for ; Sat, 28 Sep 2013 14:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TKEMLMkRn9n2SlyZzC2aiHyC5Cv6C3Vc/f9a9CEOpvs=; b=c2O+ftaROOB258Bx2ZepJJbXKPgZkzsI0OLkbNXPSUaf7fFmWXmPPS6SXz6Z+ChNTs rANmoF19zZ2jB2iqFKzAYy0RHQP2lC418KiimecUgp8NPwmQW3YR/eMBr0llwjH1vadF gYp5jEsKiJF9NRzRJgfInQIvadyY0bWXzDEEX2nxUK1d2JSIgO6oIHXCQv+NmQfGCn/C 2X0m5+xz9GE4fXkqmK/2U86Z3Fh5B2BpdMrb3ddbbRg1bSYhhEx7/CtFJWbYtG7plph6 JeEENMzCdPjeZXGPegHR3kzXARg0MmqPhiK67CRFb3SwCyN7VM0J6Us965eHE3dQy2yz /J/w== MIME-Version: 1.0 X-Received: by 10.49.51.167 with SMTP id l7mr18452273qeo.52.1380405148232; Sat, 28 Sep 2013 14:52:28 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Sat, 28 Sep 2013 14:52:28 -0700 (PDT) In-Reply-To: <52452F14.1070803@it.aoyama.ac.jp> References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52452F14.1070803@it.aoyama.ac.jp> Date: Sat, 28 Sep 2013 14:52:28 -0700 Message-ID: From: R S To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: multipart/alternative; boundary=047d7bdc134a81b2a804e7789e50 Cc: Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2013 21:52:34 -0000 --047d7bdc134a81b2a804e7789e50 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 27, 2013 at 12:09 AM, "Martin J. D=FCrst" wrote: > On 2013/09/27 3:52, R S wrote: > >> On Thu, Sep 26, 2013 at 11:50 AM, Tim Bray wrote: >> >> Well, except for the very first thing I tried, a modern Ruby with the >>> default "require 'json'", did not preserve the sign. >>> >>> >> I bet they would take a patch, though. >> > > Please send one, or at least file a bug report on > http://bugs.ruby-lang.org. I checked this today. Ruby's standard implementation appears to interpret "-0.0" as -0.0 and "-0" as 0. - Rob --047d7bdc134a81b2a804e7789e50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 27, 2013 at 12:09 AM, "Martin J. D=FCrst&= quot; <duerst@it.aoyama.ac.jp> wrote:
On 2013/09/27 3:52, R S wrote:
On Thu, Sep 26, 2013 at 11:50 AM, Tim Bray<tbray@textuality.com> =A0wrote:

Well, except for the very first thing I tried, a modern Ruby with the
default "require 'json'", did not preserve the sign.


I bet they would take a patch, though.

Please send one, or at least file a bug report on http://bugs.ruby-lang.org.
<= div>
I checked this today. Ruby's standard implementation= appears to interpret "-0.0" as -0.0 and "-0" as 0.

- Rob




=A0
--047d7bdc134a81b2a804e7789e50-- From cabo@tzi.org Sun Sep 29 01:31:55 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F81321F9F31 for ; Sun, 29 Sep 2013 01:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.181 X-Spam-Level: X-Spam-Status: No, score=-106.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL3eKMjrF+Y6 for ; Sun, 29 Sep 2013 01:31:49 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C983821F9EFB for ; Sun, 29 Sep 2013 01:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8T8Vgm3027653; Sun, 29 Sep 2013 10:31:42 +0200 (CEST) Received: from [172.16.42.101] (p54890BA1.dip0.t-ipconnect.de [84.137.11.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 73526286; Sun, 29 Sep 2013 10:31:42 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Sun, 29 Sep 2013 10:31:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9D959999-63A2-46EF-8C14-C48F586D9DA4@tzi.org> References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52454988.5030706@it.aoyama.ac.jp> <20130927214137.GC24460@mercury.ccil.org> To: R S X-Mailer: Apple Mail (2.1510) Cc: JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 29 Sep 2013 08:31:55 -0000 On Sep 28, 2013, at 00:15, R S wrote: >> Yes. The text in the current draft refers to both -0 and -0.0 as = though they are interoperable. >=20 > Rather, it refers to them both as though they have the same = interoperability considerations. Rightly so. While the probability of being hit is lower (more JSON implementations = do seem to implement -0.0 as distinct from 0.0), it would still be = foolish to rely on interoperability of any form of negative zero. (Two minutes of googling: = https://android.googlesource.com/platform/libcore/+/014aa1a70743ae7e6ec0de= 1555f5b43d43844cf4/json/src/main/java/org/json/JSONObject.java I haven't investigated further.) Note also the result on -0e0. More importantly, the JSON specification so far has been mute on = negative zeros (random quote from someone trying to interpret the = specification: "The JSON specification allows that number, but does not = define what it means"*). (Going forward, it would probably be a good thing to recommend that JSON = decoders represent all of -0, -0e0 etc. in a number representation that = keeps negative zeros distinct; that is for most of them, treat -0 as a = floating point value. Examples of implementations that do so: Erlang's, = JSONKit, demjson.) Gr=FC=DFe, Carsten *) http://deron.meranda.us/python/comparing_json_modules/numbers From sayrer@gmail.com Sun Sep 29 13:25:51 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E657B11E80D5 for ; Sun, 29 Sep 2013 13:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dv4Z+cnfV6u6 for ; Sun, 29 Sep 2013 13:25:50 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 95B7921E80BF for ; Sun, 29 Sep 2013 13:25:41 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id k4so1773550qaq.6 for ; Sun, 29 Sep 2013 13:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jbYdinhiI51uLptaDF7H2Hz/esopD+iJQbGQB4xlPbU=; b=qZZRME+UMkGtJXNITV+e/1ESkV/z0pupYXDMc3NqxyX0yeIgBSRlZRmtzL3jwTlY4W 4YircZUXz81Y1rpPKObcrRScvejxRcGwgsvQSLaUQP9/toED6Hwl1xmUGhWhIrLCqx6t XzijfGhZ8b0r572NxMDXUmh8PIvPl2n8D8gNb7NN7ae5EUbJmPKnNGyGXK2CkUBzEjuq 2jdNjEQijDcUGRJVKMzICL0wTEYl3U6eBm4awjFiJPVtOm2r3MXten2jb8SCHVsxd4hv gzNi+fccgXye7zX5ah67zJHpBOHAFsRPqMSJVitpmuISaDvxDeVHqEV9OhSZy6W9scKt Bv1w== MIME-Version: 1.0 X-Received: by 10.224.121.147 with SMTP id h19mr3654114qar.105.1380486340918; Sun, 29 Sep 2013 13:25:40 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Sun, 29 Sep 2013 13:25:40 -0700 (PDT) In-Reply-To: <9D959999-63A2-46EF-8C14-C48F586D9DA4@tzi.org> References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52454988.5030706@it.aoyama.ac.jp> <20130927214137.GC24460@mercury.ccil.org> <9D959999-63A2-46EF-8C14-C48F586D9DA4@tzi.org> Date: Sun, 29 Sep 2013 13:25:40 -0700 Message-ID: From: R S To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e0149c60ef7c8e504e78b852d Cc: JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 29 Sep 2013 20:25:51 -0000 --089e0149c60ef7c8e504e78b852d Content-Type: text/plain; charset=ISO-8859-1 On Sun, Sep 29, 2013 at 1:31 AM, Carsten Bormann wrote: > On Sep 28, 2013, at 00:15, R S wrote: > > >> Yes. The text in the current draft refers to both -0 and -0.0 as though > they are interoperable. > > > > Rather, it refers to them both as though they have the same > interoperability considerations. > > Rightly so. > > While the probability of being hit is lower (more JSON implementations do > seem to implement -0.0 as distinct from 0.0), it would still be foolish to > rely on interoperability of any form of negative zero. > > (Two minutes of googling: > > https://android.googlesource.com/platform/libcore/+/014aa1a70743ae7e6ec0de1555f5b43d43844cf4/json/src/main/java/org/json/JSONObject.java > I haven't investigated further.) > I am not sure that file is relevant--the tokenizer in the same directory looks like it will preserve the sign of -0.0. But please explain further if I'm wrong about that. > > Note also the result on -0e0. > > More importantly, the JSON specification so far has been mute on negative > zeros The spec now cites IEEE754, and states that that it will generally interoperate. I think that's accurate for -0.0 since IEEE754 specifies its handling, and all of these implementations are winding up in a strtod implementation that preserves the sign for -0.0. In other words, the text on -0.0 contradicts "Since software which implements IEEE 754-2008 [IEEE754] is generally available and widely used, good interoperability can be achieved..." Java, POSIX strtod, ECMAScript, and many more all handle negative zero. > (random quote from someone trying to interpret the specification: "The > JSON specification allows that number, but does not define what it means"*). > Interestingly, the link you cite shows a table with -0.0 interoperating perfectly across 5 implementations. > > (Going forward, it would probably be a good thing to recommend that JSON > decoders represent all of -0, -0e0 etc. in a number representation that > keeps negative zeros distinct; that is for most of them, treat -0 as a > floating point value. Examples of implementations that do so: Erlang's, > JSONKit, demjson.) > Oh, that might make some sense, but it's a distinct issue from -0.0 today. > *) http://deron.meranda.us/python/comparing_json_modules/numbers > > - Rob --089e0149c60ef7c8e504e78b852d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Sep 29, 2013 at 1:31 AM, Carsten Bormann = <cabo@tzi.org><= /span> wrote:
On Sep 28, 2013, at 00:15, R S <sayrer@gmail.com> wrote:

>> Yes. The text in the current draft refers to both -0 and -0.0 as t= hough they are interoperable.
>
> Rather, it refers to them both as though they have the same interopera= bility considerations.

Rightly so.

While the probability of being hit is lower (more JSON implementations do s= eem to implement -0.0 as distinct from 0.0), it would still be foolish to r= ely on interoperability of any form of negative zero.

(Two minutes of googling:
https://android.googlesource.com/platform/libcore/+/014aa1= a70743ae7e6ec0de1555f5b43d43844cf4/json/src/main/java/org/json/JSONObject.j= ava
I haven't investigated further.)

I = am not sure that file is relevant--the tokenizer in the same directory look= s like it will preserve the sign of -0.0. But please explain further if I&#= 39;m wrong about that.

=A0

Note also the result on -0e0.

More importantly, the JSON specification so far has been mute on negative z= eros

The spec now cites IEEE754, and state= s that that it will generally interoperate. I think that's accurate for= -0.0 since IEEE754 specifies its handling, and all of these implementation= s are winding up in a strtod implementation that preserves the sign for -0.= 0.

In other words, the text on -0.0 contradicts
=
"Since software which implements IE= EE 754-2008=A0[IEEE754]=A0is generally available and widely used, good interoperability can be = achieved..."

Java, PO= SIX strtod, ECMAScript, and many more all handle negative zero.

=A0
(random quote from someone tr= ying to interpret the specification: "The JSON specification allows th= at number, but does not define what it means"*).

Interestingly, the link you cite shows a t= able with -0.0 interoperating perfectly across 5 implementations.


=A0

(Going forward, it would probably be a good thing to recommend that JSON de= coders represent all of -0, -0e0 etc. in a number representation that keeps= negative zeros distinct; that is for most of them, treat -0 as a floating = point value. =A0Examples of implementations that do so: Erlang's, JSONK= it, demjson.)

Oh, that might make some sense, but it'= ;s a distinct issue from -0.0 today.

=A0
*) http://deron.meranda.us/python/comparing_json_modules/n= umbers


- Rob
--089e0149c60ef7c8e504e78b852d-- From cabo@tzi.org Sun Sep 29 13:33:38 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC60E21F9D96 for ; Sun, 29 Sep 2013 13:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.183 X-Spam-Level: X-Spam-Status: No, score=-106.183 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBuIUatyyVVJ for ; Sun, 29 Sep 2013 13:33:33 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1F57721F9E7E for ; Sun, 29 Sep 2013 13:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8TKXRO7014912; Sun, 29 Sep 2013 22:33:27 +0200 (CEST) Received: from [192.168.217.105] (p54890A66.dip0.t-ipconnect.de [84.137.10.102]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C797F407; Sun, 29 Sep 2013 22:33:26 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Sun, 29 Sep 2013 22:33:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <25C6CA6F-76F0-42DE-8845-850B8B69F1A6@tzi.org> References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52454988.5030706@it.aoyama.ac.jp> <20130927214137.GC24460@mercury.ccil.org> <9D959999-63A2-46EF-8C14-C48F586D9DA4@tzi.org> To: R S X-Mailer: Apple Mail (2.1510) Cc: JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 29 Sep 2013 20:33:39 -0000 On Sep 29, 2013, at 22:25, R S wrote: > I am not sure that file is relevant It is an example of an implementation that encodes a floating point = negative zero as =BB-0=AB, which is then decoded as a plain (integer) = zero by most implementations. Summary: If you want wide interoperability, don't rely on negative zero = (in any form) staying distinct. (And if you don't need wide = interoperability, the encoded form =BB-0.0=AB appears to survive best.) Gr=FC=DFe, Carsten From tbray@textuality.com Sun Sep 29 13:46:28 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCC811E8139 for ; Sun, 29 Sep 2013 13:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niE0CzUOzwC9 for ; Sun, 29 Sep 2013 13:46:23 -0700 (PDT) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id D496121F96CA for ; Sun, 29 Sep 2013 13:46:22 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id x14so3193155vbb.37 for ; Sun, 29 Sep 2013 13:46:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8MiAsFGjOG/nJ4ZNi0XVCmw8z3TUH7pSUEjIMUxj5g0=; b=IaTZgr4c70WIHEDajeE33wscCqaCxFxhhB3rNmH0sEsF+z5Rhv/wFJl7TbHCmnZ9q3 c4uIETz98soFcAAd1/kOWvmTpIcSHlyKSorbp7eigvRY+BrC9Tcrur44oDbjw0hYjC+i g/ke5ffll9eGRHZPBaKxUCwvtq2RdG30gAx2KlM0d1tmjHp8U3kWqkggmouumr6P8PyW ooN/RFIahSHUYFhqRSZl6gn93J/Sz14bm3fIfenjSt9EoFMabNXlJ2CiO2Kcoz8tEKuI RDo0JgcU+FfH+yUHYS/vNiZGr7pwpzvRAO1fs0z3ip/ZxChcqJsAXHMwz+m/JaGONGIO qa2Q== X-Gm-Message-State: ALoCoQk6yFcjGRCNPp6D/4LxkhayxTWCzHoZSnwWQaivbDCuOPZnIohbFnY8hZ4OzBil6w5xKqDf MIME-Version: 1.0 X-Received: by 10.58.118.130 with SMTP id km2mr18523388veb.0.1380487578321; Sun, 29 Sep 2013 13:46:18 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Sun, 29 Sep 2013 13:46:18 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <25C6CA6F-76F0-42DE-8845-850B8B69F1A6@tzi.org> References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52454988.5030706@it.aoyama.ac.jp> <20130927214137.GC24460@mercury.ccil.org> <9D959999-63A2-46EF-8C14-C48F586D9DA4@tzi.org> <25C6CA6F-76F0-42DE-8845-850B8B69F1A6@tzi.org> Date: Sun, 29 Sep 2013 13:46:18 -0700 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e013a05acb914a204e78bcfb4 Cc: JSON WG , R S Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 29 Sep 2013 20:46:28 -0000 --089e013a05acb914a204e78bcfb4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, but my opinion is shifting here... it's starting to feel to me like there's nothing remotely JSON-specific about the problems around -0. Let me see, if I were going to do another draft based on what people have been saying here, I'd, in Section 6 - Remove "are represented without "frac" or "exp" parts (for example as 3 not 3.0)" - Lose the whole paragraph beginning "Numbers which represent zero without a sign... Less is more. Is anyone passionate about keeping either? -T On Sun, Sep 29, 2013 at 1:33 PM, Carsten Bormann wrote: > On Sep 29, 2013, at 22:25, R S wrote: > > > I am not sure that file is relevant > > It is an example of an implementation that encodes a floating point > negative zero as =C2=BB-0=C2=AB, which is then decoded as a plain (intege= r) zero by > most implementations. > > Summary: If you want wide interoperability, don't rely on negative zero > (in any form) staying distinct. (And if you don't need wide > interoperability, the encoded form =C2=BB-0.0=C2=AB appears to survive be= st.) > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e013a05acb914a204e78bcfb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, but my opinion is shifting here... it's starting= to feel to me like there's nothing remotely JSON-specific about the pr= oblems around -0. =C2=A0Let me see, if I were going to do another draft bas= ed on what people have been saying here, I'd, in Section 6

- Remove "are represented without "frac" or &= quot;exp" parts (for example as 3 not 3.0)"
- Lose the = whole paragraph beginning "Numbers which represent zero without a sign= ...

Less is more. Is anyone passionate about keeping either= ?

=C2=A0-T
<= br>
On Sun, Sep 29, 2013 at 1:33 PM, Carsten = Bormann <cabo@tzi.org> wrote:
On Sep 29, 2013, at 22:25,= R S <sayrer@gmail.com> wrote= :

> I am not sure that file is relevant

It is an example of an implementation that encodes a floating point n= egative zero as =C2=BB-0=C2=AB, which is then decoded as a plain (integer) = zero by most implementations.

Summary: If you want wide interoperability, don't rely on negative zero= (in any form) staying distinct. =C2=A0(And if you don't need wide inte= roperability, the encoded form =C2=BB-0.0=C2=AB appears to survive best.)
Gr=C3=BC=C3=9Fe, Carsten

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

--089e013a05acb914a204e78bcfb4-- From pfpschneider@gmail.com Sun Sep 29 15:45:24 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E18E21F894E for ; Sun, 29 Sep 2013 15:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9m-yqGXRd-0m for ; Sun, 29 Sep 2013 15:45:23 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A6FAB11E8149 for ; Sun, 29 Sep 2013 15:45:21 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id x19so3107974qcw.16 for ; Sun, 29 Sep 2013 15:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IZ1m4j0QsVLBdGWaQW4sJrq99Vuo4jOlank2EyeUjUc=; b=HN5omBuMPmPM88bfwHOpV0SketuUgUIytCcxebJysaFOZrD8VK/Q1S+WXthdpm6k8d YlRdWONZOknxGcwb7AyLnK+iET/yqDiwP2NKNIXW59Q0kKiwpOM6cKX0w5RPIjpOhLD/ kmzzXaJOfEgF3HCwNDTeexr2Hb4tZZBpBmfZhrkhaS0kVJbaMLXNbnAPkh4gvQAJkJCT zugJZYt/p8h8c3oqL/OSuK9+a8qShPqP7Y8JbJeTmRE4VEU4pzTQFcmYomWJEnhzlWjC O6JRRzpy1ot3Q4BwzNTMtTbSwhtHLZVc81iGZHh92wmTC0cbkOpPAThSDrVhUDYFv6fo i5Lg== MIME-Version: 1.0 X-Received: by 10.49.58.174 with SMTP id s14mr25073116qeq.73.1380494720842; Sun, 29 Sep 2013 15:45:20 -0700 (PDT) Received: by 10.49.64.202 with HTTP; Sun, 29 Sep 2013 15:45:20 -0700 (PDT) In-Reply-To: References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52454988.5030706@it.aoyama.ac.jp> <20130927214137.GC24460@mercury.ccil.org> <9D959999-63A2-46EF-8C14-C48F586D9DA4@tzi.org> <25C6CA6F-76F0-42DE-8845-850B8B69F1A6@tzi.org> Date: Sun, 29 Sep 2013 15:45:20 -0700 Message-ID: From: Peter Patel-Schneider To: Tim Bray Content-Type: multipart/alternative; boundary=047d7b6d8afc733fe804e78d7987 Cc: Carsten Bormann , R S , JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 29 Sep 2013 22:45:24 -0000 --047d7b6d8afc733fe804e78d7987 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hmm. Many other languages, for example C, are not adequately specific concerning the interpretation of floating point constants, particularly -0.= 0 However, I don't know of any language or formalism that is used in a way that is so cavalier about the interpretation of numeric constants in general, so I would have to say that the breadth of the problems with -0 are specific to JSON. In all the other languages and formalisms that I have used -0 is integer 0, and thus the same as 0, and this has been explicitly or implicitly stated in the definition of the language or formalism. Even C with one's complement integers should get this right, although direct casting to unsigned integers might expose the existence of signed zeros. Peter F. Patel-Schneider Nuance Communications PS: Yes, yes, I expect that there are *many* languages and formalisms that are just as bad as JSON with respect to numbers. I just haven't had the displeasure of needing to work with any of them yet. On Sun, Sep 29, 2013 at 1:46 PM, Tim Bray wrote: > Yeah, but my opinion is shifting here... it's starting to feel to me like > there's nothing remotely JSON-specific about the problems around -0. Let > me see, if I were going to do another draft based on what people have bee= n > saying here, I'd, in Section 6 > > - Remove "are represented without "frac" or "exp" parts (for example as 3 > not 3.0)" > - Lose the whole paragraph beginning "Numbers which represent zero withou= t > a sign... > > Less is more. Is anyone passionate about keeping either? > > -T > > > On Sun, Sep 29, 2013 at 1:33 PM, Carsten Bormann wrote: > >> On Sep 29, 2013, at 22:25, R S wrote: >> >> > I am not sure that file is relevant >> >> It is an example of an implementation that encodes a floating point >> negative zero as =BB-0=AB, which is then decoded as a plain (integer) ze= ro by >> most implementations. >> >> Summary: If you want wide interoperability, don't rely on negative zero >> (in any form) staying distinct. (And if you don't need wide >> interoperability, the encoded form =BB-0.0=AB appears to survive best.) >> >> Gr=FC=DFe, Carsten >> >> _______________________________________________ >> 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 > > --047d7b6d8afc733fe804e78d7987 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hmm.=A0=A0 Many other languages, for exampl= e C, are not adequately specific concerning the interpretation of floating = point constants, particularly -0.0

However, I don't know o= f any language or formalism that is used in a way that is so cavalier about= the interpretation of numeric constants in general, so I would have to say= that the breadth of the problems with -0 are specific to JSON.=A0 In all t= he other languages and formalisms that I have used -0 is integer 0, and thu= s the same as 0, and this has been explicitly or implicitly stated in the d= efinition of the language or formalism.=A0 Even C with one's complement= integers should get this right, although direct casting to unsigned intege= rs might expose the existence of signed zeros.

Peter F. Patel-Schneider
Nuance Communications

PS= :=A0 Yes, yes, I expect that there are *many* languages and formalisms that= are just as bad as JSON with respect to numbers.=A0 I just haven't had= the displeasure of needing to work with any of them yet.



On Sun, Sep 29, 2013 at 1:46 PM, Tim Bray <tbray@textuality.com= > wrote:
Yeah, but my opinion is shi= fting here... it's starting to feel to me like there's nothing remo= tely JSON-specific about the problems around -0. =A0Let me see, if I were g= oing to do another draft based on what people have been saying here, I'= d, in Section 6

- Remove "are represented without "frac" or &= quot;exp" parts (for example as 3 not 3.0)"
- Lose the = whole paragraph beginning "Numbers which represent zero without a sign= ...

Less is more. Is anyone passionate about keeping either= ?

= =A0-T


On Sun, Sep 29, 2013 at 1:33 PM, Carsten= Bormann <cabo@tzi.org> wrote:
On Sep 29, 2013, at 22:25, R S <sayrer@gmail.com> = wrote:

> I am not sure that file is relevant

It is an example of an implementation that encodes a floating point n= egative zero as =BB-0=AB, which is then decoded as a plain (integer) zero b= y most implementations.

Summary: If you want wide interoperability, don't rely on negative zero= (in any form) staying distinct. =A0(And if you don't need wide interop= erability, the encoded form =BB-0.0=AB appears to survive best.)

Gr=FC=DFe, Carsten

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


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


--047d7b6d8afc733fe804e78d7987-- From cowan@ccil.org Sun Sep 29 17:28:47 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29F121F9D94 for ; Sun, 29 Sep 2013 17:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqiPl0sJyC1p for ; Sun, 29 Sep 2013 17:28:42 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4816A21F9D92 for ; Sun, 29 Sep 2013 17:28:35 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VQRLj-0006Ht-Rl; Sun, 29 Sep 2013 20:28:31 -0400 Date: Sun, 29 Sep 2013 20:28:31 -0400 From: John Cowan To: Tim Bray Message-ID: <20130930002831.GJ27126@mercury.ccil.org> References: <52454988.5030706@it.aoyama.ac.jp> <20130927214137.GC24460@mercury.ccil.org> <9D959999-63A2-46EF-8C14-C48F586D9DA4@tzi.org> <25C6CA6F-76F0-42DE-8845-850B8B69F1A6@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Carsten Bormann , R S , JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 00:28:47 -0000 Tim Bray scripsit: > Yeah, but my opinion is shifting here... it's starting to feel to me > like there's nothing remotely JSON-specific about the problems around > -0. There isn't, but JSON is what we are working on today. "It is not incumbent upon you to complete the work, but neither are you at liberty to desist from it." (R. Tarfon, _Pirke Avot_ 2:21, ca. 100 C.E.) > - Remove "are represented without "frac" or "exp" parts (for example > as 3 not 3.0)" +1 > - Lose the whole paragraph beginning "Numbers which represent zero > without a sign... -1 > Less is more. Is anyone passionate about keeping either? I do feel that we should warn about negative zero. Unlike XML, JSON claims to transmit numbers, and we should warn about the limits of that capability. -- Let's face it: software is crap. Feature-laden and bloated, written under tremendous time-pressure, often by incapable coders, using dangerous languages and inadequate tools, trying to connect to heaps of broken or obsolete protocols, implemented equally insufficiently, running on unpredictable hardware -- we are all more than used to brokenness. --Felix Winkelmann From paul.hoffman@vpnc.org Sun Sep 29 17:38:27 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078A421F9E40 for ; Sun, 29 Sep 2013 17:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmB0gXq2aYOd for ; Sun, 29 Sep 2013 17:38:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0CC21F9E37 for ; Sun, 29 Sep 2013 17:38:26 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8U0cP4F066315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 29 Sep 2013 17:38:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: <20130930002831.GJ27126@mercury.ccil.org> Date: Sun, 29 Sep 2013 17:38:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <590DB34F-489F-4FBD-8937-7CA14382F366@vpnc.org> References: <52454988.5030706@it.aoyama.ac.jp> <20130927214137.GC24460@mercury.ccil.org> <9D959999-63A2-46EF-8C14-C48F586D9DA4@tzi.org> <25C6CA6F-76F0-42DE-8845-850B8B69F1A6@tzi.org> <20130930002831.GJ27126@mercury.ccil.org> To: JSON WG X-Mailer: Apple Mail (2.1510) Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 00:38:27 -0000 The additions that we are making about interoperability are about things = that a significant number of JSON users might expect. The = likely-forthcoming "implementation advice" document can take care of = telling implementers of JSON encoders and parsers what they should = consider. On Sep 29, 2013, at 5:28 PM, John Cowan wrote: > Tim Bray scripsit: >=20 >> Yeah, but my opinion is shifting here... it's starting to feel to me >> like there's nothing remotely JSON-specific about the problems around >> -0. >=20 > There isn't, but JSON is what we are working on today. "It is not > incumbent upon you to complete the work, but neither are you at = liberty > to desist from it." (R. Tarfon, _Pirke Avot_ 2:21, ca. 100 C.E.) "Don't boil the ocean." (Lots of people, recently.) >=20 >> - Remove "are represented without "frac" or "exp" parts (for example >> as 3 not 3.0)" >=20 > +1 +1 >> - Lose the whole paragraph beginning "Numbers which represent zero >> without a sign... >=20 > -1 >=20 >> Less is more. Is anyone passionate about keeping either? >=20 > I do feel that we should warn about negative zero. Unlike XML, JSON > claims to transmit numbers, and we should warn about the limits of = that > capability. Number geeks^wspecialsts might expect certain things about -0, but the = vast majority of normal JSON users won't. I think it is fine to remove = the paragraph and assume that a more in-depth discussion will happen in = the companion document. --Paul Hoffman= From sayrer@gmail.com Sun Sep 29 17:47:29 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A46A21F8F9A for ; Sun, 29 Sep 2013 17:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwGsvDDmp2sU for ; Sun, 29 Sep 2013 17:47:29 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C7DB021F99FB for ; Sun, 29 Sep 2013 17:47:28 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id gh4so3281953qeb.2 for ; Sun, 29 Sep 2013 17:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uXbtrnsdCA0/ZkPEEanHqMaJhyp2hvIEF1mhF1E301s=; b=cNyMSLrRKLYHhXkTlz4/lKND7YSOUkzD20ub67LnwXl+aW913CXzuYol56FfU5v+IH 3FLQvv60SmQb9xNKXYi8JEbl4fo4wnUjh748JwgN/w3LyIN+G2Ah/5vXqgMgfoNNdVy9 cGh9dxnTg5K8rtDVhKMcuf7O/CAbavBLhxdxu5x+5aeXeCMsbpRfpIE5xktnAy4uR50Z N0Fsk3UB7AbwKX/GlF27tuxfWExeVytb7es525KJTjotra1KlN/fo2Sfh75KoBobZ60/ AgrV5eHBMGNrqTaIlae55549Q8YfosZ3qHyXZ3uz0hcE7Y0R33F/UVkz06H1nuBaDH+U b2ew== MIME-Version: 1.0 X-Received: by 10.229.204.197 with SMTP id fn5mr25076542qcb.5.1380502046206; Sun, 29 Sep 2013 17:47:26 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Sun, 29 Sep 2013 17:47:26 -0700 (PDT) In-Reply-To: References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52454988.5030706@it.aoyama.ac.jp> <20130927214137.GC24460@mercury.ccil.org> <9D959999-63A2-46EF-8C14-C48F586D9DA4@tzi.org> <25C6CA6F-76F0-42DE-8845-850B8B69F1A6@tzi.org> Date: Sun, 29 Sep 2013 17:47:26 -0700 Message-ID: From: R S To: Tim Bray Content-Type: multipart/alternative; boundary=001a11c1f6421373da04e78f2e41 Cc: Carsten Bormann , JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 00:47:29 -0000 --001a11c1f6421373da04e78f2e41 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Sep 29, 2013 at 1:46 PM, Tim Bray wrote: > Yeah, but my opinion is shifting here... it's starting to feel to me like > there's nothing remotely JSON-specific about the problems around -0. Let > me see, if I were going to do another draft based on what people have been > saying here, I'd, in Section 6 > > - Remove "are represented without "frac" or "exp" parts (for example as 3 > not 3.0)" > - Lose the whole paragraph beginning "Numbers which represent zero without > a sign... > > Less is more. Is anyone passionate about keeping either? > Removing that text is a good idea. Section 9, "Parsers", currently reads: > An implementation may set limits on the range of numbers. That text should be adjusted to allow implementations to set limits on range and precision, since that obviously happens in practice. - Rob --001a11c1f6421373da04e78f2e41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Sep 29, 2013 at 1:46 PM, Tim Bray <tbray@textu= ality.com> wrote:
Yeah, but my opinion is shifting here... = it's starting to feel to me like there's nothing remotely JSON-spec= ific about the problems around -0. =A0Let me see, if I were going to do ano= ther draft based on what people have been saying here, I'd, in Section = 6

- Remove "are represented without "frac" or &= quot;exp" parts (for example as 3 not 3.0)"
- Lose the = whole paragraph beginning "Numbers which represent zero without a sign= ...

Less is more. Is anyone passionate about keeping either= ?

Removing that text is a good = idea.

Section 9, "Parsers", currently re= ads:

> An implementation may set limi= ts on the range of numbers.
=A0
That text sh= ould be adjusted to allow implementations to set limits on range and precis= ion, since that obviously happens in practice.

- Rob
--001a11c1f6421373da04e78f2e41-- From cowan@ccil.org Sun Sep 29 17:58:59 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679DC21F9D3E for ; Sun, 29 Sep 2013 17:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X41F8XFemHGG for ; Sun, 29 Sep 2013 17:58:54 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4377221F9D3B for ; Sun, 29 Sep 2013 17:58:54 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VQRp7-0000gL-6r; Sun, 29 Sep 2013 20:58:53 -0400 Date: Sun, 29 Sep 2013 20:58:53 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130930005853.GM27126@mercury.ccil.org> References: <20130927214137.GC24460@mercury.ccil.org> <9D959999-63A2-46EF-8C14-C48F586D9DA4@tzi.org> <25C6CA6F-76F0-42DE-8845-850B8B69F1A6@tzi.org> <20130930002831.GJ27126@mercury.ccil.org> <590DB34F-489F-4FBD-8937-7CA14382F366@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <590DB34F-489F-4FBD-8937-7CA14382F366@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 00:58:59 -0000 Paul Hoffman scripsit: > The additions that we are making about interoperability are about > things that a significant number of JSON users might expect. I don't actually think so. They are edge cases (unpaired surrogates, too-large or too-precise numbers, duplicate names), but edge cases wind up being important to somebody. Negative zero is just another edge case. > The likely-forthcoming "implementation advice" document can take care > of telling implementers of JSON encoders and parsers what they should > consider. Oh, I agree. But all the things above, including negative zero, are about what users can and cannot expect to survive when transmitted by JSON. > "Don't boil the ocean." (Lots of people, recently.) In the Middle East, that's where the drinking water comes from. What's more, if you have some high-temperature superconductor and need to kill off a field of sunflowers, boiling the ocean may be just the thing. > Number geeks^wspecialsts might expect certain things about -0, but the > vast majority of normal JSON users won't. I think it is fine to remove > the paragraph and assume that a more in-depth discussion will happen > in the companion document. You could make the same argument about Unicode geeks and unpaired surrogates. Are you doing so? If not, why not? -- Si hoc legere scis, nimium eruditionis habes. From cabo@tzi.org Sun Sep 29 23:37:45 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD67011E80DF for ; Sun, 29 Sep 2013 23:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.185 X-Spam-Level: X-Spam-Status: No, score=-106.185 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VR+cm0EEK9Op for ; Sun, 29 Sep 2013 23:37:40 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2859F21F9AE2 for ; Sun, 29 Sep 2013 23:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8U6bVfY008804; Mon, 30 Sep 2013 08:37:31 +0200 (CEST) Received: from [192.168.217.105] (p54890A66.dip0.t-ipconnect.de [84.137.10.102]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C39D8499; Mon, 30 Sep 2013 08:37:30 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 30 Sep 2013 08:37:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6D5CFCAD-5B75-4246-BE42-D42E4D35C344@vpnc.org> <52454988.5030706@it.aoyama.ac.jp> <20130927214137.GC24460@mercury.ccil.org> <9D959999-63A2-46EF-8C14-C48F586D9DA4@tzi.org> <25C6CA6F-76F0-42DE-8845-850B8B69F1A6@tzi.org> To: R S X-Mailer: Apple Mail (2.1510) Cc: Tim Bray , JSON WG Subject: Re: [Json] -0.0 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 06:37:46 -0000 On Sep 30, 2013, at 02:47, R S wrote: > > An implementation may set limits on the range of numbers. > =20 > That text should be adjusted to allow implementations to set limits on = range and precision, since that obviously happens in practice. Yes! Gr=FC=DFe, Carsten From duerst@it.aoyama.ac.jp Mon Sep 30 02:29:48 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C8121F8267 for ; Mon, 30 Sep 2013 02:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.42 X-Spam-Level: X-Spam-Status: No, score=-101.42 tagged_above=-999 required=5 tests=[AWL=-1.630, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oX47gTt1w1so for ; Mon, 30 Sep 2013 02:29:40 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id D3DA921F91B7 for ; Mon, 30 Sep 2013 02:29:36 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8U9TMk9012777; Mon, 30 Sep 2013 18:29:22 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6b4c_4d83_ca2084f2_29b2_11e3_992e_001e6722eec2; Mon, 30 Sep 2013 18:29:22 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 89406BFBBA; Mon, 30 Sep 2013 18:29:21 +0900 (JST) Message-ID: <52494467.2050108@it.aoyama.ac.jp> Date: Mon, 30 Sep 2013 18:29:11 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , JSON WG Subject: [Json] Change Control (was: Re: Authorship) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 09:29:48 -0000 On 2013/09/28 3:13, Bjoern Hoehrmann wrote: > * Paul Hoffman wrote: >> - He can cause the eventual RFC to never be published by never >> responding during AUTH48, the last step in the RFC publication process. >> That would mean that the hard work that many people have done here would >> be a waste of time and energy. > > I note that RFC 4627 awards him change control over application/json... I note that draft-ietf-json-rfc4627bis-04 still awards him change control. I'd really like to have Douglas back as an author (even if he isn't too much involved in day-to-day work), but I think it's not appropriate that an IETF WG produce a Media type definition that doesn't list the IETF as Change Controller. Regards, Martin. From duerst@it.aoyama.ac.jp Mon Sep 30 02:33:40 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D5A21F9C37 for ; Mon, 30 Sep 2013 02:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.343 X-Spam-Level: X-Spam-Status: No, score=-103.343 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KR35L+aGuteM for ; Mon, 30 Sep 2013 02:33:26 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 659D921F91BF for ; Mon, 30 Sep 2013 02:33:26 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8U9XIAq017332; Mon, 30 Sep 2013 18:33:18 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6b4c_4f49_56b3ce24_29b3_11e3_992e_001e6722eec2; Mon, 30 Sep 2013 18:33:17 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 60D3EBFBBA; Mon, 30 Sep 2013 18:33:17 +0900 (JST) Message-ID: <52494553.9020002@it.aoyama.ac.jp> Date: Mon, 30 Sep 2013 18:33:07 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> <52494467.2050108@it.aoyama.ac.jp> In-Reply-To: <52494467.2050108@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , JSON WG Subject: [Json] Indentation (was: Re: Change Control) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 09:33:40 -0000 On 2013/09/30 18:29, "Martin J. D=C3=BCrst" wrote: > I note that draft-ietf-json-rfc4627bis-04 still awards him change > control. I'd really like to have Douglas back as an author (even if he > isn't too much involved in day-to-day work), but I think it's not > appropriate that an IETF WG produce a Media type definition that doesn'= t > list the IETF as Change Controller. I only noticed this because some indentation changes make it show up in=20 http://www.ietf.org/rfcdiff?url1=3Drfc4627&url2=3Ddraft-ietf-json-rfc4627= bis-04=20 (posted by Mark, thanks!). If easily possible, it would be great if the indentation would go back=20 to be the same as in the original; that would make the diff shorter.=20 Maybe this needs an issue to be raised on the xml2rfc list or somewhere.=20 Or is the RFC Editor experimenting with new indents? Regards, Martin. From cabo@tzi.org Mon Sep 30 05:14:37 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC1E21F9C6C for ; Mon, 30 Sep 2013 05:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.037 X-Spam-Level: X-Spam-Status: No, score=-106.037 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oU5ktzvlJiu3 for ; Mon, 30 Sep 2013 05:14:32 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AF32A21F85E0 for ; Mon, 30 Sep 2013 05:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8UCERJ6012583; Mon, 30 Sep 2013 14:14:27 +0200 (CEST) Received: from [192.168.217.105] (p54890DAD.dip0.t-ipconnect.de [84.137.13.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 33D0C781; Mon, 30 Sep 2013 14:14:27 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <52494553.9020002@it.aoyama.ac.jp> Date: Mon, 30 Sep 2013 14:14:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> <52494467.2050108@it.aoyama.ac.jp> <52494553.9020002@it.aoyama.ac.jp> To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= X-Mailer: Apple Mail (2.1510) Cc: JSON WG Subject: Re: [Json] Indentation (was: Re: Change Control) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 12:14:37 -0000 On Sep 30, 2013, at 11:33, "Martin J. D=FCrst" = wrote: > Or is the RFC Editor experimenting with new indents? xml2rfcv2 has changed some of the indentation logic with respect to v1. In the documents I have been working on, these changes generally were = improvements. Looking at = http://www.ietf.org/rfcdiff?url1=3Drfc4627&url2=3Ddraft-ietf-json-rfc4627b= is-04, this generally seems to be the case here as well. There are a couple of lines that would benefit from more indentation;=20 from the XML and the xml2rfcv2 code I cannot see why they look the way = they do (i.e., these may be bugs in xml2rfcv2; there also is a spurious = newline at the end of the one-liners): JSON-text =3D object / array ws =3D *( false null true array =3D begin-array [ value *( value-separator value ) ] end-array Gr=FC=DFe, Carsten From cabo@tzi.org Mon Sep 30 05:23:09 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAC021F9BD3 for ; Mon, 30 Sep 2013 05:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.034 X-Spam-Level: X-Spam-Status: No, score=-106.034 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgKoPK-Od-27 for ; Mon, 30 Sep 2013 05:23:05 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id EB70B21F87BB for ; Mon, 30 Sep 2013 05:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8UCMvs7028412; Mon, 30 Sep 2013 14:22:57 +0200 (CEST) Received: from [192.168.217.105] (p54890DAD.dip0.t-ipconnect.de [84.137.13.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 106BB789; Mon, 30 Sep 2013 14:22:57 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 30 Sep 2013 14:22:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9130E110-AFF8-4D95-8AF4-6D957247788A@tzi.org> References: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> <52494467.2050108@it.aoyama.ac.jp> <52494553.9020002@it.aoyama.ac.jp> To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= X-Mailer: Apple Mail (2.1510) Cc: JSON WG Subject: Re: [Json] Indentation (was: Re: Change Control) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 12:23:10 -0000 On Sep 30, 2013, at 14:14, Carsten Bormann wrote: > bugs in xml2rfcv2 http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/151 Workaround: have at least one empty line in the artwork element. (That then makes two spurious empty lines, but at least the indentation = is consistent.) Gr=FC=DFe, Carsten From jorge@jorgechamorro.com Mon Sep 30 05:46:29 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A509021F9BF7 for ; Mon, 30 Sep 2013 05:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.257 X-Spam-Level: X-Spam-Status: No, score=-3.257 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElfjCwxtyeib for ; Mon, 30 Sep 2013 05:46:23 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id ACA5121F9A90 for ; Mon, 30 Sep 2013 05:46:19 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w62so5463409wes.4 for ; Mon, 30 Sep 2013 05:46:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1ZOqpMcGeLw4yqdxsZSFGae2FtCBinED/TixUv6w84o=; b=NamMMl3ZdmjcJh4lsid6Bivo4v66b4G+LxORSIWYfatUYkBsX++DBI9m91J78RGfzs RgsUCRyj82i6IQ9NOEwpdiAy1PlV9cXDIm/FJLZCzpo9CFumCbtXa8jlQ0JAG71SH1wG XdMiCHY3PDZI8Sj6HF/J1+0txbTO6jltShVKHkJI4vOfeI5JtaILOO0lHED8HL3rIS18 8CrYbJhupudNzbFcVkf3qilIvDWDfYFtmWieXrOQQKCUEVDKwspz6i6DFZn7OECAeYjV XwQYXl3r+IZdRuPru+Nw1yQI+6YOzL0YEqCuhUZsCPvv21HfHv5w/NZEJaRar6I+eJj7 xMoQ== X-Gm-Message-State: ALoCoQn7/umNFsH4+ip+0KiOxYdPCF516kHmfdQ9Ym07zQr0d+gLZZ9pCi1qCPDoXgVSoW+tZavY X-Received: by 10.194.175.133 with SMTP id ca5mr17240935wjc.19.1380545178773; Mon, 30 Sep 2013 05:46:18 -0700 (PDT) Received: from [192.168.10.50] (160.Red-88-0-222.dynamicIP.rima-tde.net. [88.0.222.160]) by mx.google.com with ESMTPSA id ev4sm25651397wib.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Sep 2013 05:46:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Jorge Chamorro In-Reply-To: <52494467.2050108@it.aoyama.ac.jp> Date: Mon, 30 Sep 2013 14:46:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0630FFFF-D2ED-4737-B269-CA9C4C8FF86D@jorgechamorro.com> References: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> <52494467.2050108@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1085) Cc: Bjoern Hoehrmann , Paul Hoffman , JSON WG Subject: Re: [Json] Change Control (was: Re: Authorship) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 12:46:29 -0000 On 30/09/2013, at 11:29, Martin J. D=FCrst wrote: > On 2013/09/28 3:13, Bjoern Hoehrmann wrote: >> * Paul Hoffman wrote: >>> - He can cause the eventual RFC to never be published by never >>> responding during AUTH48, the last step in the RFC publication = process. >>> That would mean that the hard work that many people have done here = would >>> be a waste of time and energy. >>=20 >> I note that RFC 4627 awards him change control over = application/json... >=20 > I note that draft-ietf-json-rfc4627bis-04 still awards him change = control. I'd really like to have Douglas back as an author (even if he = isn't too much involved in day-to-day work), but I think it's not = appropriate that an IETF WG produce a Media type definition that doesn't = list the IETF as Change Controller. And can't there be a contributors section, as well? :-) --=20 ( Jorge )();= From tony@att.com Mon Sep 30 07:09:49 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65B921F8FAC for ; Mon, 30 Sep 2013 07:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.395 X-Spam-Level: X-Spam-Status: No, score=-104.395 tagged_above=-999 required=5 tests=[AWL=-2.016, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3+0UZnFHsaA for ; Mon, 30 Sep 2013 07:09:43 -0700 (PDT) Received: from flpi406.enaf.ffdc.sbc.com (egssmtp03.att.com [144.160.128.152]) by ietfa.amsl.com (Postfix) with ESMTP id 4F68621F8546 for ; Mon, 30 Sep 2013 07:09:42 -0700 (PDT) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com (8.14.4/8.14.4) with ESMTP id r8UE9dYK027326 for ; Mon, 30 Sep 2013 07:09:41 -0700 Received: from [135.70.224.43] (vpn-135-70-224-43.vpn.east.att.com[135.70.224.43]) by maillennium.att.com (mailgw1) with ESMTP id <20130930140937gw1009k100e> (Authid: tony); Mon, 30 Sep 2013 14:09:37 +0000 X-Originating-IP: [135.70.224.43] Message-ID: <524761DD.7080102@att.com> Date: Sat, 28 Sep 2013 19:10:21 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: JSON WG References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <0FA0EFFF-2109-4D78-8723-2ECD990C0F82@vpnc.org> <7058DBBD-9DCE-4A5C-B11D-5FC41A839407@vpnc.org> <5245A56D.4080205@att.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------050104010108010201080301" Subject: Re: [Json] Differences between RFC 4627 or the current ECMAScript specification X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 14:09:50 -0000 This is a multi-part message in MIME format. --------------050104010108010201080301 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/27/2013 12:34 PM, R S wrote: > On Fri, Sep 27, 2013 at 8:34 AM, Tony Hansen > wrote: > > RFC 4627 does not allow trailing commas in objects. Nor does > 4627-bis. > > > RFC 4627 allows parsers to accept non-JSON if they wish, while > ECMAScript does not allow this. Your claim was that you had to change your parser of JSON to no longer allow trailing commas because of converting to parsing ECMAScript. I disagree with that assessment. You had added your own non-standard extension to JSON (accepting trailing commas) to your parser. Note that ECMA's restrictions on parsers are only on implementations of ECMAScript. ECMA does NOT say that *your* parser may not continue to accept trailing commas, except in the specific case of your parser being used in an implementation of ECMAScript's JSON.parse() function. That is, if your function is not used in an implementation of JSON.parse(), ECMA places no restrictions on it; it certainly is not restricted in the same ways that ECMAScript's JSON.parse() is restricted. You chose to remove that non-standard extension, but only because you chose to *follow* the same restrictions as ECMAScript's JSON.parse(). Did the JSON spec say you could add your own extension to your parser? Yes it did. However, if someone wrote JSON using a trailing comma, they're going into non-interoperable territory. ECMA also extends 4627-JSON by accepting additional top-level primitives. ECMA's JSON.parse() is still a 4627-JSON-compliant parser because it properly interprets 4627-JSON. However, someone writing JSON using ECMA's extensions will only safely be interoperable with someone using ECMAScript's JSON.parse() or another parser that's been similarly extended. But they aren't interoperable with the many other JSON libraries that haven't been similarly extended. Tony Hansen --------------050104010108010201080301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/27/2013 12:34 PM, R S wrote:
On Fri, Sep 27, 2013 at 8:34 AM, Tony Hansen <tony@att.com> wrote:
RFC 4627 does not allow trailing commas in objects. Nor does 4627-bis. 

RFC 4627 allows parsers to accept non-JSON if they wish, while ECMAScript does not allow this.

Your claim was that you had to change your parser of JSON to no longer allow trailing commas because of converting to parsing ECMAScript. I disagree with that assessment.

You had added your own non-standard extension to JSON (accepting trailing commas) to your parser. Note that ECMA's restrictions on parsers are only on implementations of ECMAScript. ECMA does NOT say that *your* parser may not continue to accept trailing commas, except in the specific case of your parser being used in an implementation of ECMAScript's JSON.parse() function. That is, if your function is not used in an implementation of JSON.parse(), ECMA places no restrictions on it; it certainly is not restricted in the same ways that ECMAScript's JSON.parse() is restricted. You chose to remove that non-standard extension, but only because you chose to *follow* the same restrictions as ECMAScript's JSON.parse().

Did the JSON spec say you could add your own extension to your parser? Yes it did. However, if someone wrote JSON using a trailing comma, they're going into non-interoperable territory.

ECMA also extends 4627-JSON by accepting additional top-level primitives. ECMA's JSON.parse() is still a 4627-JSON-compliant parser because it properly interprets 4627-JSON. However, someone writing JSON using ECMA's extensions will only safely be interoperable with someone using ECMAScript's JSON.parse() or another parser that's been similarly extended. But they aren't interoperable with the many other JSON libraries that haven't been similarly extended.

    Tony Hansen
--------------050104010108010201080301-- From cabo@tzi.org Mon Sep 30 07:47:57 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CCB21F9D62 for ; Mon, 30 Sep 2013 07:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.182 X-Spam-Level: X-Spam-Status: No, score=-106.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2hUo-2omj0J for ; Mon, 30 Sep 2013 07:47:52 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id EBB2421F9CDF for ; Mon, 30 Sep 2013 07:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8UEliCk024042; Mon, 30 Sep 2013 16:47:44 +0200 (CEST) Received: from [192.168.217.105] (p54890DAD.dip0.t-ipconnect.de [84.137.13.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5EA208B4; Mon, 30 Sep 2013 16:47:44 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <52448254.5090209@cisco.com> Date: Mon, 30 Sep 2013 16:47:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <52448254.5090209@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1510) Cc: Paul Hoffman , JSON WG Subject: [Json] ECMA-262 normative? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 14:47:57 -0000 On Sep 26, 2013, at 20:52, Eliot Lear wrote: > there is the question on whether or not the > document should simply normatively reference ECMA. I'm not sure this aspect was picked up yet. The current draft lists ECMA-262 (1999) as a normative reference. A quick reading of http://www.ietf.org/iesg/statement/normative-informative.html "IESG Statement: Normative and Informative References" shows that this is an erratum that needs to be corrected.*) The reference must be informative. Gr=FC=DFe, Carsten PS.: As people sometimes don't have the ability to use links in a = message, the juicy sentence is: > Normative references specify documents that must be read to understand = or implement the technology in the new RFC, or whose technology must be = present for the technology in the new RFC to work.=20 If we make that true for ECMA-262, we have seriously broken the = document. From cowan@ccil.org Mon Sep 30 08:56:21 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267FC21F979E for ; Mon, 30 Sep 2013 08:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUXe7K8zE+8V for ; Mon, 30 Sep 2013 08:56:05 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id B1F5B21F95D0 for ; Mon, 30 Sep 2013 08:56:02 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VQfpG-0005Jk-95; Mon, 30 Sep 2013 11:55:58 -0400 Date: Mon, 30 Sep 2013 11:55:58 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130930155558.GH14791@mercury.ccil.org> References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <52448254.5090209@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , Eliot Lear , JSON WG Subject: Re: [Json] ECMA-262 normative? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 15:56:21 -0000 Carsten Bormann scripsit: > If we make that true for ECMA-262, we have seriously broken the document. Emphatic +1. Each normative document should be chosen very carefully, because it's as if you had included the whole thing right there in the RFC. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Big as a house, much bigger than a house, it looked to [Sam], a grey-clad moving hill. Fear and wonder, maybe, enlarged him in the hobbit's eyes, but the Mumak of Harad was indeed a beast of vast bulk, and the like of him does not walk now in Middle-earth; his kin that live still in latter days are but memories of his girth and his majesty. --"Of Herbs and Stewed Rabbit" From paul.hoffman@vpnc.org Mon Sep 30 09:17:58 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442C721F995B for ; Mon, 30 Sep 2013 09:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ4iXPqUZmkn for ; Mon, 30 Sep 2013 09:17:57 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AE53221F93BA for ; Mon, 30 Sep 2013 09:17:57 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8UGHuuW017901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 30 Sep 2013 09:17:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Mon, 30 Sep 2013 09:17:56 -0700 Content-Transfer-Encoding: 7bit Message-Id: <573850C7-1B68-43FA-BFA0-CDF92E25D1B3@vpnc.org> References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <52448254.5090209@cisco.com> To: JSON WG X-Mailer: Apple Mail (2.1510) Subject: Re: [Json] ECMA-262 normative? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 16:17:58 -0000 +1 to moving the current reference to the Informative section. --Paul Hoffman From tbray@textuality.com Mon Sep 30 09:34:53 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DF221F915C for ; Mon, 30 Sep 2013 09:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmseYCoFnuQw for ; Mon, 30 Sep 2013 09:34:48 -0700 (PDT) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id DC3CB21F8613 for ; Mon, 30 Sep 2013 09:34:47 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id db12so4424835veb.28 for ; Mon, 30 Sep 2013 09:34:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IuWdUKPe1rOdMJHRPTRigtDozmvFLM5OBCr0xFo3grg=; b=ArmkhHh7IggAJqPflQgsALFS7awPfcOG8l2AqdvcLDUvLTKAvW/ZnM3SybfYsCZyXC rAceCA/aLRtUDuOtFRcLrvy1kvR/daS283yqtWQPtNzb5SyuldVFF5Ly5YD8NhTK9cNZ iTRv0uG2MLkyhYQGS8/BOvkvTJ7eRcoJ4aRwkajz7SE/2tI7JgOp1o42MgcOLoPkq/SI wuUPNaZgs6mhHiYFEdXcBj238f4xcj2GGe8HeQjGFhg2N8N0zXAnpZiXU1r/X6sQwzIA DtnFAZgnC5mSauW+8BtCtJ+PepINjEgD7h6ADN7I+huKXMSHAZw7x9eHdg9hFP1amSLD 79yw== X-Gm-Message-State: ALoCoQncfyEvc6W33gX5UmCLHgJKTiHdpev491dXQchconPOtlhsaKW5AyrHZ9xjBLmbKdirJs0R MIME-Version: 1.0 X-Received: by 10.52.33.44 with SMTP id o12mr19570699vdi.7.1380558886554; Mon, 30 Sep 2013 09:34:46 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Mon, 30 Sep 2013 09:34:46 -0700 (PDT) X-Originating-IP: [209.121.225.228] Received: by 10.221.64.201 with HTTP; Mon, 30 Sep 2013 09:34:46 -0700 (PDT) In-Reply-To: <573850C7-1B68-43FA-BFA0-CDF92E25D1B3@vpnc.org> References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <52448254.5090209@cisco.com> <573850C7-1B68-43FA-BFA0-CDF92E25D1B3@vpnc.org> Date: Mon, 30 Sep 2013 09:34:46 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=20cf3079b5f206642304e79c6a87 Cc: JSON WG Subject: Re: [Json] ECMA-262 normative? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 16:34:53 -0000 --20cf3079b5f206642304e79c6a87 Content-Type: text/plain; charset=UTF-8 Seems like a no-brainer On Sep 30, 2013 9:17 AM, "Paul Hoffman" wrote: > > > +1 to moving the current reference to the Informative section. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --20cf3079b5f206642304e79c6a87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Seems like a no-brainer

On Sep 30, 2013 9:17 AM, "Paul Hoffman"= ; <paul.hoffman@vpnc.org>= ; wrote:
<no hat>

+1 to moving the current reference to the Informative section.

--Paul Hoffman
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json
--20cf3079b5f206642304e79c6a87-- From lear@cisco.com Mon Sep 30 09:47:51 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DFB21F9ADD for ; Mon, 30 Sep 2013 09:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.518 X-Spam-Level: X-Spam-Status: No, score=-110.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLEtruixFFrG for ; Mon, 30 Sep 2013 09:47:46 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9B30021F999C for ; Mon, 30 Sep 2013 09:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2926; q=dns/txt; s=iport; t=1380559666; x=1381769266; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=JI5BVsstvx4cqNx1Mc1Gzw5uDE0WskDs4o+1hlLtiAM=; b=fNTWeAOkjPXtFLlGjJ+iH2LfrYLyR4cSIIug1xoP3hc6NKiC8gKmVzBD YgxWrGMbWHtilwq47juEJufjnY0grKgiIL1/uI3CLZ2dY9L1qELrmeFLo OyLPfR3DtTEHjzSlAcEWRNNcWadyaE0RU80x2tYPMWWzUYjeO20XLfo7/ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFACWqSVKQ/khN/2dsb2JhbABZgwc4g3uFXbd3gS4WdIIlAQEBBAEBASBLCgEQCwQKCgkWCAMCAgkDAgECARUWCREGDQEFAgEBiAIMq0GSLQSPUQeCaoE4A5d/kXmDJjo X-IronPort-AV: E=Sophos;i="4.90,1009,1371081600"; d="scan'208,217";a="87043939" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 30 Sep 2013 16:47:45 +0000 Received: from mctiny.local ([10.61.193.68]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8UGlgI9013363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Sep 2013 16:47:43 GMT Message-ID: <5249AB2E.3040905@cisco.com> Date: Mon, 30 Sep 2013 18:47:42 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tim Bray References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <52448254.5090209@cisco.com> <573850C7-1B68-43FA-BFA0-CDF92E25D1B3@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------020103090202080003010103" Cc: Paul Hoffman , JSON WG Subject: Re: [Json] ECMA-262 normative? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 16:47:51 -0000 This is a multi-part message in MIME format. --------------020103090202080003010103 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit +1, assuming the rest of the draft stays as it is. Eliot On 9/30/13 6:34 PM, Tim Bray wrote: > > Seems like a no-brainer > > On Sep 30, 2013 9:17 AM, "Paul Hoffman" > wrote: > > > > +1 to moving the current reference to the Informative section. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --------------020103090202080003010103 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit +1, assuming the rest of the draft stays as it is.

Eliot

On 9/30/13 6:34 PM, Tim Bray wrote:

Seems like a no-brainer

On Sep 30, 2013 9:17 AM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
<no hat>

+1 to moving the current reference to the Informative section.

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


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

--------------020103090202080003010103-- From paul.hoffman@vpnc.org Mon Sep 30 15:45:44 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C79521F9123 for ; Mon, 30 Sep 2013 15:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQGAf7WLQDmr for ; Mon, 30 Sep 2013 15:45:44 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C606A21F9635 for ; Mon, 30 Sep 2013 15:45:37 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8UMjYO9031853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 30 Sep 2013 15:45:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: <52494467.2050108@it.aoyama.ac.jp> Date: Mon, 30 Sep 2013 15:45:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FE58CDF-859A-4FB3-AE13-D72BDAB35D1A@vpnc.org> <52494467.2050108@it.aoyama.ac.jp> To: JSON WG X-Mailer: Apple Mail (2.1510) Subject: [Json] Change control for the MIME media type X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 22:45:44 -0000 On Sep 30, 2013, at 2:29 AM, Martin J. D=FCrst = wrote: > . . . I think it's not appropriate that an IETF WG produce a Media = type definition that doesn't list the IETF as Change Controller. It is seeming that way. That is, when an RFC is informational, it is = fine for the MIME media type registration to be for the individual who = created the document. When it is an IETF-originated document (as this is = now becoming), the change controller for the MIME type should be "IESG = ". I have checked with our ADs, and they agree on this. --Paul Hoffman= From sayrer@gmail.com Mon Sep 30 18:55:56 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D8D21F9468 for ; Mon, 30 Sep 2013 18:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjjBU1y95-X1 for ; Mon, 30 Sep 2013 18:55:55 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 45C0621F9928 for ; Mon, 30 Sep 2013 18:55:55 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id j7so2901799qaq.2 for ; Mon, 30 Sep 2013 18:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TqDw4Z/YK1WUwlQnPndXrdajMLknNrfr4jjq1aHYp8k=; b=X2+Y5wroTcCSbv28m0t6tlctYuwBxLMfbt1PQ7Ne898lw3M3LYlWliWRLduK5YAQs0 kh5uJ64qlkOtSEAWsAhPlbC7T+6fRQD0JX+Y5+nmfss9BLc2HDnughlKNJArORKDoniQ BYSiBj9bOKuuxTjacMy0sluQAbs/wwZ1uONUNcQ9n3AcfvWE5kw667yfS3GpGPrO0d3o mJ0d4Cr2ZnacPyGDI5yeikD9uxvV0SQRCGn5kp454t0rfGSxYNQsPz3KCoojaA5T0+vP 5XlfvipJy9Tv6D6niX0ftn4fjr+cZZSTxUnrsl8Zip9xEugIkKkPsJ99SUQrP2yVKr2K UQ8Q== MIME-Version: 1.0 X-Received: by 10.49.107.135 with SMTP id hc7mr32049646qeb.43.1380592554711; Mon, 30 Sep 2013 18:55:54 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 30 Sep 2013 18:55:54 -0700 (PDT) In-Reply-To: References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <52448254.5090209@cisco.com> Date: Mon, 30 Sep 2013 18:55:54 -0700 Message-ID: From: R S To: Carsten Bormann Content-Type: multipart/alternative; boundary=047d7bdc13eecda2b904e7a44063 Cc: Paul Hoffman , Eliot Lear , JSON WG Subject: Re: [Json] ECMA-262 normative? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 01:55:56 -0000 --047d7bdc13eecda2b904e7a44063 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 30, 2013 at 7:47 AM, Carsten Bormann wrote: > > > Normative references specify documents that must be read to understand > or implement the technology in the new RFC, or whose technology must be > present for the technology in the new RFC to work. > > If we make that true for ECMA-262, we have seriously broken the document. It is true for RFC 4627. That makes claims that JSON has nothing to do with ECMAScript rather baseless, at least if one plays the part of spec nerd. I think we should have a rationale for changing this, since we're not supposed be changing things without being very careful. - Rob --047d7bdc13eecda2b904e7a44063 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 30, 2013 at 7:47 AM, Carsten Bormann <cabo@tzi.org= > wrote:

> Normative references specify documents that must be read to understand= or implement the technology in the new RFC, or whose technology must be pr= esent for the technology in the new RFC to work.

If we make that true for ECMA-262, we have seriously broken the document.

It is true for RFC 4627. That makes claims t= hat JSON has nothing to do with ECMAScript rather baseless, at least if one= plays the part of spec nerd.

I think we should have a rationale for changing this, s= ince we're not supposed be changing things without being very careful.<= /div>

- Rob
--047d7bdc13eecda2b904e7a44063-- From sayrer@gmail.com Mon Sep 30 18:58:50 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A1621F9926 for ; Mon, 30 Sep 2013 18:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQsIOfolaPEe for ; Mon, 30 Sep 2013 18:58:50 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9E95521F991E for ; Mon, 30 Sep 2013 18:58:46 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id k4so2935300qaq.13 for ; Mon, 30 Sep 2013 18:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8x8JXrDmZiSV1wut+uMAvvMSV0pDpNa86j7wkZkWfPE=; b=DzSGrB3xp/yXQ0uXERQ7t+/+iqG3EhbB+U5xMhQnGunk+EWBpmMT8fqGy9BGzKyZRb 7zAS3BwnrmcNIVn0FcxJcovwgF7SvBrGKFeRJTwjkLeHa6V8bXE3us3kEyxlKdaASgYS e/1jLLEdBTZRR3m5VOfWParzSssJaVTmFURpD+V2c+unzPN5h6xgZKVSJzp3rGvjp7XT iQjCf4d7YXn53vzDt/RwKSPKYnsjzSLUQFbfuNHQotJTKCMdADSUvJVXLsiz3TmLwUsg a4D/zN+y52nejMPsZVTg2iR1Ov5Zit9lM1PXbYiiI7Ir95wZ8NafP/Eur03kfBE/zz+B HlWg== MIME-Version: 1.0 X-Received: by 10.224.61.198 with SMTP id u6mr18126847qah.83.1380592724730; Mon, 30 Sep 2013 18:58:44 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 30 Sep 2013 18:58:44 -0700 (PDT) Date: Mon, 30 Sep 2013 18:58:44 -0700 Message-ID: From: R S To: "json@ietf.org" , Paul Hoffman , Matthew Miller Content-Type: multipart/alternative; boundary=089e015372eeefeafb04e7a44ac6 Subject: [Json] last call timeline X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 01:58:50 -0000 --089e015372eeefeafb04e7a44ac6 Content-Type: text/plain; charset=ISO-8859-1 What is the timeline for the incorporation (or non-incorporation) of proposed changes to Tim's draft? Some of them seem to have a fair chance of reaching consensus. Will there be an additional WG last call round? - Rob --089e015372eeefeafb04e7a44ac6 Content-Type: text/html; charset=ISO-8859-1
What is the timeline for the incorporation (or non-incorporation) of proposed changes to Tim's draft? Some of them seem to have a fair chance of reaching consensus. Will there be an additional WG last call round?

- Rob
--089e015372eeefeafb04e7a44ac6-- From paul.hoffman@vpnc.org Mon Sep 30 19:24:10 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900DA21F8517 for ; Mon, 30 Sep 2013 19:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo8VrFVRSHmj for ; Mon, 30 Sep 2013 19:24:10 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 18E5621F9A05 for ; Mon, 30 Sep 2013 19:24:10 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r912O4VE037782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Sep 2013 19:24:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: Date: Mon, 30 Sep 2013 19:24:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0BDFB657-39DA-42C5-B449-2268D01B0A68@vpnc.org> References: To: R S X-Mailer: Apple Mail (2.1510) Cc: Matthew Miller , "json@ietf.org" Subject: Re: [Json] last call timeline X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 02:24:10 -0000 On Sep 30, 2013, at 6:58 PM, R S wrote: > What is the timeline for the incorporation (or non-incorporation) of = proposed changes to Tim's draft? There is no timeline yet. We're still seeking discussion of any new = technical issues with the current draft. > Some of them seem to have a fair chance of reaching consensus. Certainly seems that way. > Will there be an additional WG last call round? We haven't thought about it. --Paul Hoffman From sayrer@gmail.com Mon Sep 30 21:38:48 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F048621F996A for ; Mon, 30 Sep 2013 21:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQbuu-TBL+ZQ for ; Mon, 30 Sep 2013 21:38:48 -0700 (PDT) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id BD8A021F9948 for ; Mon, 30 Sep 2013 21:38:40 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id a11so4500372qen.23 for ; Mon, 30 Sep 2013 21:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wL4XpSq3+kZMlzGQU3rUINWODwR0YoqaG6vx02uAmOs=; b=zJkIxNw1gPVyjRAas6J8xSrtV4mJu55mkV8bnCJsbAKLOZoe3Y5ELRrG9AOHGX82g1 uEtSKqvI594QqZFcaeuXkGCSuLJovXfBX+1rZgXy+xlmXF6cvwhac5NfHFviNyRzngJK Efr+eNyU9xGt04VMhlhDpeo6yIbpaUR/eF004KkmhUotxp3oZ1QGEM/UO2HKR9Ygg6LI iECcaiETRRdolMxvrWAZYtI36w64ZFk31pd7TC6mUNTgRQ9DHhVG5Nm0u4rzU3LiGBBt zAdb6mgFbMfhNUMBPbOaVLKH8wMXG0Q7Izy+R0Q6UTj3mc+ThJzakjLY/dJ2/qR87oQo Ao8A== MIME-Version: 1.0 X-Received: by 10.49.1.9 with SMTP id 9mr32736146qei.51.1380602319764; Mon, 30 Sep 2013 21:38:39 -0700 (PDT) Received: by 10.140.86.147 with HTTP; Mon, 30 Sep 2013 21:38:39 -0700 (PDT) In-Reply-To: <524761DD.7080102@att.com> References: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <0FA0EFFF-2109-4D78-8723-2ECD990C0F82@vpnc.org> <7058DBBD-9DCE-4A5C-B11D-5FC41A839407@vpnc.org> <5245A56D.4080205@att.com> <524761DD.7080102@att.com> Date: Mon, 30 Sep 2013 21:38:39 -0700 Message-ID: From: R S To: Tony Hansen Content-Type: multipart/alternative; boundary=047d7b5d4e5ed886a604e7a686ed Cc: JSON WG Subject: Re: [Json] Differences between RFC 4627 or the current ECMAScript specification X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 04:38:49 -0000 --047d7b5d4e5ed886a604e7a686ed Content-Type: text/plain; charset=ISO-8859-1 my implementation was used for ECMAScript JSON.parse. - Rob On Saturday, September 28, 2013, Tony Hansen wrote: > On 9/27/2013 12:34 PM, R S wrote: > > On Fri, Sep 27, 2013 at 8:34 AM, Tony Hansen > > wrote: > >> RFC 4627 does not allow trailing commas in objects. Nor does 4627-bis. >> > > RFC 4627 allows parsers to accept non-JSON if they wish, while > ECMAScript does not allow this. > > > Your claim was that you had to change your parser of JSON to no longer > allow trailing commas because of converting to parsing ECMAScript. I > disagree with that assessment. > > You had added your own non-standard extension to JSON (accepting trailing > commas) to your parser. Note that ECMA's restrictions on parsers are only > on implementations of ECMAScript. ECMA does NOT say that *your* parser may > not continue to accept trailing commas, except in the specific case of your > parser being used in an implementation of ECMAScript's JSON.parse() > function. That is, if your function is not used in an implementation of > JSON.parse(), ECMA places no restrictions on it; it certainly is not > restricted in the same ways that ECMAScript's JSON.parse() is restricted. > You chose to remove that non-standard extension, but only because you chose > to *follow* the same restrictions as ECMAScript's JSON.parse(). > > Did the JSON spec say you could add your own extension to your parser? Yes > it did. However, if someone wrote JSON using a trailing comma, they're > going into non-interoperable territory. > > ECMA also extends 4627-JSON by accepting additional top-level primitives. > ECMA's JSON.parse() is still a 4627-JSON-compliant parser because it > properly interprets 4627-JSON. However, someone writing JSON using ECMA's > extensions will only safely be interoperable with someone using > ECMAScript's JSON.parse() or another parser that's been similarly extended. > But they aren't interoperable with the many other JSON libraries that > haven't been similarly extended. > > Tony Hansen > --047d7b5d4e5ed886a604e7a686ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable my implementation was used for ECMAScript JSON.parse.

- = Rob

On Saturday, September 28, 2013, Tony Hansen wrote= :
=20 =20 =20
On 9/27/2013 12:34 PM, R S wrote:
On Fri, Sep 27, 2013 at 8:34 AM, Tony Hansen <tony@att.com> wrote:
RFC 4627 does not allow trailing commas in objects. Nor does 4627-bis.=A0

RFC 4627 allows parsers to accept non-JSON if they wish, while ECMAScript does not allow this.

Your claim was that you had to change your parser of JSON to no longer allow trailing commas because of converting to parsing ECMAScript. I disagree with that assessment.

You had added your own non-standard extension to JSON (accepting trailing commas) to your parser. Note that ECMA's restrictions on parsers are only on implementations of ECMAScript. ECMA does NOT say that *your* parser may not continue to accept trailing commas, except in the specific case of your parser being used in an implementation of ECMAScript's JSON.parse() function. That is, if your function is not used in an implementation of JSON.parse(), ECMA places no restrictions on it; it certainly is not restricted in the same ways that ECMAScript's JSON.parse() is restricted. You chose t= o remove that non-standard extension, but only because you chose to *follow* the same restrictions as ECMAScript's JSON.parse().

Did the JSON spec say you could add your own extension to your parser? Yes it did. However, if someone wrote JSON using a trailing comma, they're going into non-interoperable territory.

ECMA also extends 4627-JSON by accepting additional top-level primitives. ECMA's JSON.parse() is still a 4627-JSON-compliant parser because it properly interprets 4627-JSON. However, someone writing JSON using ECMA's extensions will only safely be interoperable with someone using ECMAScript's JSON.parse() or another parser that's been similarly extended. But they aren't interoperable with the many other JSON libraries that haven't been similarly extended.

=A0=A0=A0 Tony Hansen
--047d7b5d4e5ed886a604e7a686ed--