From nobody Sat Sep 16 21:00:50 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18549127517 for ; Sat, 16 Sep 2017 21:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haKQ1Nb0C18W for ; Sat, 16 Sep 2017 21:00:47 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF581200F3 for ; Sat, 16 Sep 2017 21:00:47 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1505620805; h=from:subject:to:date:message-id; bh=z1Fi+y/8hxI9N7DcqeKPVM/6Lahr1fv6kcHaq2AJqds=; b=gpO1OdZ2NRjuQmUQZmtOVNRPv4udSXCfwM81jgRPJFKJkhpwbRD9X/heUA8ZNfWaVVhp7diYi7i jzVN+4OECEKhEHYUmDPIu1WtMDiiFJ/EeVKaYiqrbj6mXOaYa8ZzM3usTzxbOfGfsU1gfN/xklEsm xnTYKrdY1D9BVDs/S+2pSCPR5YHxssOWVQ/TvhRKCXGtsD9S4vzQioQzHWw8wZv8VPtEBU001ocUo tAqL90CwWBMADHLXJN1HCYHR49NqNkVHBYkce8HBcqyCkDDiMtbaCAnNGqQJw9wyTVYj9B8GmLqyP Oy9NjoRQuTVi8Z9IJDeLbpW07DbFLiqsunAA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 16 Sep 2017 21:00:03 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 16 Sep 2017 20:59:19 -0700 From: Jim Schaad To: References: <012801d32f2e$a95aaf10$fc100d30$@augustcellars.com> <7C19E4CE-32E2-44B2-BD44-1BAA48190674@tzi.org> In-Reply-To: <7C19E4CE-32E2-44B2-BD44-1BAA48190674@tzi.org> Date: Sat, 16 Sep 2017 20:59:57 -0700 Message-ID: <012d01d32f69$6ecd3490$4c679db0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLkcV5/cuYwYNvq7zdAWu7g9fdkoQDl1w1UoI7BRKA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] FW: draft-ietf-cbor-7049bis - Change suggested Canonicalization X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 04:00:49 -0000 I meant to send the original to this list and missed doing so. Jim -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Saturday, September 16, 2017 2:08 PM To: Jim Schaad Cc: draft-ietf-cbor-7049bis@ietf.org Subject: Re: draft-ietf-cbor-7049bis - Change suggested Canonicalization = Hi Jim, On Sep 16, 2017, at 22:59, Jim Schaad wrote: >=20 > I have never been happy with the suggested canonicalization steps for=20 > dealing with maps in this document. I would like to suggest that the=20 > following algorithm be used in its stead. >=20 >=20 > * Key/value pairs are sorted from lowest value to highest. Sorting is = > performed on the bytes of the representation of the key and value data = > items. The sorting algorithm is: >=20 > 1. For every key value pair, encode the key and encode the value and=20 > form a single byte stream by concatenating the key and value encoded = values. Why do you think the values need to be in there, too? Map keys must be different, so the value never can have an effect, > 2. Sort the resulting byte arrays in (byte-wise) lexical order. This = > is the standard memcmp sorting order. (The reference to memcmp works because one key cannot be a prefix of = another key.) > This has the following benefits. >=20 > 1. The algorithm used to sort the byte streams is the expected one=20 > for most people. Right. > 2. In the event that a key occurs multiple times, there is still a=20 > canonical ordering for the map which is reproducible. I don=E2=80=99t think there is a need for a canonical encoding of things = that aren=E2=80=99t canonicalizable data in the first place. Now, if it were mid-2013, I would just agree with you, change the draft, = and ask the WG (at the time appsawg) whether there are any further = comments. Unfortunately, CBOR has been out there, we are on the way to an Internet = STD, and the current canonicalization is what=E2=80=99s implemented (at = least in a couple of places). If we change this, we have to take = canonicalization out from the STD and put it into a separate = specification. We could decide to do this, but I=E2=80=99m not sure that this helps. = (We=E2=80=99ll also have the CER vs. DER situation again.) Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Sep 17 11:08:07 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1E01332D7; Sun, 17 Sep 2017 11:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmGtg12X-LDj; Sun, 17 Sep 2017 11:08:03 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F171330AE; Sun, 17 Sep 2017 11:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v8HI7lDh008553; Sun, 17 Sep 2017 20:07:47 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xwHDM0dbxzDKxp; Sun, 17 Sep 2017 20:07:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <013a01d32fcb$ac8cede0$05a6c9a0$@augustcellars.com> Date: Sun, 17 Sep 2017 20:07:44 +0200 Cc: "core@ietf.org WG" , cbor@ietf.org X-Mao-Original-Outgoing-Id: 527364464.771584-3e05479fb7064d689c23e5b2f8940562 Content-Transfer-Encoding: quoted-printable Message-Id: References: <012801d32f2e$a95aaf10$fc100d30$@augustcellars.com> <7C19E4CE-32E2-44B2-BD44-1BAA48190674@tzi.org> <013a01d32fcb$ac8cede0$05a6c9a0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-7049bis - Change suggested Canonicalization X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 18:08:05 -0000 Hi Jim, I do share your frustration a bit, because I do believe the canonical = map key sorting order is one of the very few things we didn=E2=80=99t = quite get right about RFC 7049. The question about fixing this really = is procedurally, can we fix it, and what is the impact on people who are = now using the old order. > I complained that this was not a good sorting order before RFC 7049 = was published, so this is not a new issue. I wish that I could find the = mails from the time as my memory was that you said we could discuss it = on the next version which is what I am trying to do. I must admit I don=E2=80=99t remember that discussion (it would have = been more than four years in the past) and my mail program apparently = doesn=E2=80=99t either. (My mail program does remember errata report 4409 from July 2015, where = you did propose another sorting order.) >> Why do you think the values need to be in there, too? >> Map keys must be different, so the value never can have an effect, >=20 > That is from below - where you could have multiple duplicate keys. It = is very possible people will do this even if it is not a valid encoding. The reason why 7049 does not outright make emitting duplicate keys a = conformance issue is that, in a streaming implementation, it is hard to = check for duplicate keys. That argument does not apply to an = implementation that has to sort map member keys to achieve a canonical = encoding. So, while creating canonical encoding, the implementation can = also check for key duplication and raise an error if that happens. >> Now, if it were mid-2013, I would just agree with you, change the = draft, and >> ask the WG (at the time appsawg) whether there are any further = comments. >=20 > Given that you did not agree with me at the time when I raised this = issue, I would disagree with this statement. Well, I probably should have said =E2=80=9Cknowing what I know now=E2=80=9D= (i.e., the degree of POLS violation that the current rules pose) I = would agree with you. (At the time, the definition we now have in RFC = 7049 appeared to be expedient.) >> Unfortunately, CBOR has been out there, we are on the way to an = Internet >> STD, and the current canonicalization is what=E2=80=99s implemented = (at least in a >> couple of places). If we change this, we have to take = canonicalization out from >> the STD and put it into a separate specification. >> We could decide to do this, but I=E2=80=99m not sure that this helps. = (We=E2=80=99ll also have >> the CER vs. DER situation again.) >=20 > I do not believe that changing this would in any way stop the = advancement to STD. =20 Now that (i.e., just going ahead and changing things here) is an = interesting thought. One problem with that is that in the IETF, the IESG is the gating = function, and it is sufficient for a single member of the IESG to = disagree with this thought to hold up the process. > This section is completely non-normative there is not a single = normative statement in the entire section. Nor is the set of rules = complete given that there are two paragraphs at the end which have = additional rules that "might" need to be added. Making this one change = would not alter the fact that it is non-normative and incomplete. Filling in those blanks might be another argument for going ahead and = writing a separate document about canonicalized CBOR instead. > There is a possible multiple encoding issue that may come, but that is = already implicit in the text of this section. The current text reads = "Those protocols are free to define what they mean by a canonical format = and what encoders and decoders are expected to do." Which means that = multiple encodings are already not only possible but probably. I think = that we can get this fixed now and go forward with an obsoleted = suggested canonicalization and be fine. >=20 > The suggested algorithm is far easier to understand, easier to get = right and also has some advantages where one can do the canonicalization = without having to do the encoding first. >=20 > int CompareNodes(node1, node2) > if node1.majorMode !=3D node2.majorMode then return node1.majorMode = - node2.majorMode; > if node1.majorMode has a length field and node1.length !=3D = node2.length then return node1.length - node2.length; > return compare node1 and node2 values - this is major mode = dependent. >=20 > With the current method, you need to do a lot more work to try and get = things in the correct order if you have any mixing of major modes, which = is now very common place despite the statement that this is probably a = bad practice. =20 Indeed, this is one thing we have learned since 2013: There are quite = good reasons for mixing major types in the keys of a single map. > If you have to emit all of the keys, sort them and then remember the = original order to emit the values, it is harder than concatenating the = entire thing and then emitting the values after doing the sort. You are = going to need to keep some type of more complex structure - and thus = more code- to do the emission in the generic case. Yes for a small = fixed set of keys this is not necessary but I do not believe that is = where a good canonicalization routine is going to be needed. Here is my implementation of a pre-canonicalizer for maps from the = cbor-canonical gem (the type =E2=80=9CHash=E2=80=9D in Ruby is an = order-preserving map, so we can do all this entirely at the data model = level): def cbor_pre_canonicalize Hash[collect {|k, v|=20 k =3D k.cbor_pre_canonicalize v =3D v.cbor_pre_canonicalize cc =3D k.to_cbor # already canonical [cc.size, cc, k, v]}.sort.collect{|s, cc, k, v| = [k, v]}] end A sorting rule that is entirely based on (byte-wise) lexical ordering = would enable pre-sorting on types =E2=80=94 there often would be no need = to generate the entire key encoding for sorting. But then, you have to = generate them anyway, so the additional overhead is mostly a matter of = memory allocation/copying. Here is an (untested) implementation of what I think you are proposing: def cbor_pre_canonicalize Hash[collect {|k, v|=20 k =3D k.cbor_pre_canonicalize v =3D v.cbor_pre_canonicalize cc =3D k.to_cbor # already canonical [cc, k, v]}.sort.collect{|cc, k, v| [k, v]}] end I.e., the size of the key encoding is removed from the list of things to = sort for. > I strongly urge that this change be done even if it might hurt = backwards compatibility and the sooner we make the decision to do it the = better as it reduces the number of people who will do it wrong. Now whether we should do this or not is a good question for the CBOR WG = to look at. (I=E2=80=99ve added the WG back to the recipient list.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Sep 21 04:11:59 2017 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A95931348FB; Thu, 21 Sep 2017 04:11:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: cbor@ietf.org, cbor-chairs@ietf.org, francesca.palombini@ericsson.com, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150599231766.24983.2541537510982901726.idtracker@ietfa.amsl.com> Date: Thu, 21 Sep 2017 04:11:57 -0700 Archived-At: Subject: [Cbor] cbor - New Meeting Session Request for IETF 100 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 11:11:58 -0000 A new meeting session request has just been submitted by Francesca Palombini, a Chair of the cbor working group. --------------------------------------------------------- Working Group Name: Concise Binary Object Representation Maintenance and Extensions Area Name: Applications and Real-Time Area Session Requester: Francesca Palombini Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: artarea dispatch core ace anima t2trg 6tisch dtn Second Priority: saag webpush sacm lpwan httpbis dots lwig roll Third Priority: detnet dnsop People who must be present: Alexey Melnikov Joe Hildebrand Francesca Palombini Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Sep 27 07:47:20 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C63134C7A for ; Wed, 27 Sep 2017 07:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.853 X-Spam-Level: X-Spam-Status: No, score=-2.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PskvcZW-2k9G for ; Wed, 27 Sep 2017 07:47:14 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06AD134C23 for ; Wed, 27 Sep 2017 07:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v8REdWSQ008090 for ; Wed, 27 Sep 2017 16:39:32 +0200 (CEST) Received: from [172.17.115.123] (unknown [46.183.103.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3y2L7Q2c9fzDLm5; Wed, 27 Sep 2017 16:39:27 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 528215960.244335-326f3bc1111f1732bcbf09f5b860b35e Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 27 Sep 2017 16:39:20 +0200 Message-Id: To: cbor@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Cbor] Explicitly define the CBOR data model X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 14:47:19 -0000 Jeffrey Yasskin has proposed to write some text for CBORbis that = explicitly defines CBOR's data model: https://github.com/cbor-wg/CBORbis/issues/2 I have now written a draft for such a section, available at: https://github.com/cbor-wg/CBORbis/blob/master/datamodels.md * Do we want to have such a section? * Is the proposed text the right one? Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Sep 27 09:59:21 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02599134E50 for ; Wed, 27 Sep 2017 09:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=vKJporYT; dkim=pass (1024-bit key) header.d=chromium.org header.b=J2Ks0W0V Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsqr-ElyXUNl for ; Wed, 27 Sep 2017 09:59:18 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8141134E61 for ; Wed, 27 Sep 2017 09:59:17 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id d16so16245166ioj.3 for ; Wed, 27 Sep 2017 09:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/B9NuWPZ8KptxRkeW6yV/f1ZT2kNBra/eNYMZvqxVDc=; b=vKJporYTvk1S/xzFhwhAceAgRRNToog1uULKmcqc732RuIuhmypjhyfcwsjQt9BjO1 UJ6Cp4rJZ7EJpFo6hKvZ+0kfa+4Ky+UpdTjbowHQyVpioAdhLACfPaBc1nUZHf53DfKa 4xBSjZ25MhYLPARFivusBHNVbFUzzRwr1l6IYjEwTr/5q3NGlTP59LSlSXhVgKCvVV5y 7Y3IG0zWFdMVzVmAo6dj2WawnPSJ65SYhi1t/7sw1EqTKPt5F3tPxEU/h35j8LvRDYrT 5VJLLL4aJN0NRWapTnbd8el0kp8nTRZDKk3wAhgOUQHxSLuiOH7HV2NnLnLxfYa/FKJo YdHw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/B9NuWPZ8KptxRkeW6yV/f1ZT2kNBra/eNYMZvqxVDc=; b=J2Ks0W0VqJLgxbEDt1F7Hj7TNxjYpyGZ0zAsH1cHbrSgKKoSDgBrJBDW95OSOx255M 1L/6V3eSpQvC7eN00V9tMU2SU6S1GBIB/KbKS1n1Jq+jhiEmvnYqgwpAulr2CGhsTpqS TBazLYVoIL29DkaqIy+5h6zIFHubeD9zVvxfw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/B9NuWPZ8KptxRkeW6yV/f1ZT2kNBra/eNYMZvqxVDc=; b=qIv03cX2NIh7R29yC3mmglXW3MIG5rN9KSvRCvPrMq7pGdZN6rELnrbLRXUxxqsVqX 3vLeY/GF6Lfy8kKnD5u5uq8AiA6GNFwtXoRflGsEN8st+j3hVp+QGndvRJBuDX3bplxB fNIPJpd9lJHqWsLamzeFSs8K/0/TfrJk0fbNFjpg0PKcBjHH1mJBjNjUR3OH5zCXXO3P uFwFvL4dIpBmrf488BC5eZfpqn6RLvatngywLbYHta2ww/fcoFr6VcFq/+a9CpO4svtw 3mt/jvj/z4LHPlIx4m8MgOv7WaaI3t2YdgYbzoeGAhIJgjKY1aL3EfICX2euoJTBGT+z HcMQ== X-Gm-Message-State: AMCzsaUJnD04wRRn8mhXdFhJOQTSA9apk1GtlEVR0lahE5kAhDgg4q5r G4L6+RU/5Px2LKQjFagNJtInzDK7naIa6i0IYADnvZldWjc= X-Google-Smtp-Source: AOwi7QBHtfEBpX+mwHorPu02K9kw5vlpdyakWBgMUaEZC+uVKF+KOXqja+4LRh3za8egN9kKK3PRsKo52403As6NTkk= X-Received: by 10.107.190.7 with SMTP id o7mr3143591iof.18.1506531556832; Wed, 27 Sep 2017 09:59:16 -0700 (PDT) MIME-Version: 1.0 Sender: jyasskin@google.com Received: by 10.107.133.219 with HTTP; Wed, 27 Sep 2017 09:58:55 -0700 (PDT) In-Reply-To: References: From: Jeffrey Yasskin Date: Wed, 27 Sep 2017 09:58:55 -0700 X-Google-Sender-Auth: Z_BHDZAuf34YiMTdnqdaPOn_Jhc Message-ID: To: Carsten Bormann Cc: cbor@ietf.org Content-Type: multipart/alternative; boundary="001a114f03944a4d06055a2eb653" Archived-At: Subject: Re: [Cbor] Explicitly define the CBOR data model X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 16:59:20 -0000 --001a114f03944a4d06055a2eb653 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks! Your text looks good except for one inconsistency: "Note that integer and floating-point values are distinct in this model, even if they have the same numeric value." is inconsistent with "For the purposes of this specification, all number representations for the same numeric value are equivalent." in https://cbor-wg.github.io/CBORbis/#rfc.section.3.6. This will interact with canonicalization: If 0 is equivalent to 0.0, then canonicalization has to map integral floating point values to their integer representations, to preserve the fact that canonicalization makes duplicate map keys easy to identify. This also leads to a question of whether small BigInt, BigDecimal, and BigFloat values are equivalent to integer and floating values. Jeffrey On Wed, Sep 27, 2017 at 7:39 AM, Carsten Bormann wrote: > Jeffrey Yasskin has proposed to write some text for CBORbis that > explicitly defines CBOR's data model: > > https://github.com/cbor-wg/CBORbis/issues/2 > > I have now written a draft for such a section, available at: > > https://github.com/cbor-wg/CBORbis/blob/master/datamodels.md > > * Do we want to have such a section? > * Is the proposed text the right one? > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > --001a114f03944a4d06055a2eb653 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks! Your text looks good except for one inconsistency:=

"Note that integer and floating-point values are d= istinct in this model, even if they have the same numeric value." is i= nconsistent with "For the purposes of this specification, all number r= epresentations for the same numeric value are equivalent." in https://cbor-wg.git= hub.io/CBORbis/#rfc.section.3.6. This will interact with canonicalizati= on: If 0 is equivalent to 0.0, then canonicalization has to map integral fl= oating point values to their integer representations, to preserve the fact = that canonicalization makes duplicate map keys easy to identify. This also = leads to a question of whether small BigInt, BigDecimal, and BigFloat value= s are equivalent to integer and floating values.

J= effrey

On Wed, Sep 27, 2017 at 7:39 AM, Carsten Bormann <cabo@tzi.org> = wrote:
Jeffrey Yasskin has proposed to wr= ite some text for CBORbis that explicitly defines CBOR's data model:
https://github.com/cbor-wg/CBORbis/issues/2

I have now written a draft for such a section, available at:

https://github.com/cbor-wg/CBORbis/= blob/master/datamodels.md

* Do we want to have such a section?
* Is the proposed text the right one?

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

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

--001a114f03944a4d06055a2eb653-- From nobody Wed Sep 27 12:13:20 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AEF134EFD for ; Wed, 27 Sep 2017 12:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOZtuf7tdCGA for ; Wed, 27 Sep 2017 12:13:15 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F34134EF8 for ; Wed, 27 Sep 2017 12:13:15 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id u12so7732731pfl.4 for ; Wed, 27 Sep 2017 12:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GISQtZsRayg8Kf50zUkBLgdBhh3EwbxiwnTCCbLRmvQ=; b=VFh53/NFxBHLRT44rQ7fQZzPyUF6jDPKMzFenw6duJU2jmvruHhsBbnsCYBxeztv/3 QcUBqNmWu6QgWzmBOS106fldr66NkrJvDAczt9xNfF5xYJ31VMjSJuHgSyk2lgtbnnTQ DZYEvir7cVR5ONovkwEiIeIHJjpeG4seITVOmjqBImjNEgVAui/5NM0JGFb+cq0mwgPt wqLlfz5uf4x81wJjvRAv6OmNRxjp8fFfE0vxduFwYsiFF55Wqe4l+Uppm0eXXXrMoS9+ bYBICtuDJhEy84zvgLIQVOyX3szj+AR5G17V7UocOnuTmpE7rBS2RNqx00mCHdFa6Xj/ QvvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=GISQtZsRayg8Kf50zUkBLgdBhh3EwbxiwnTCCbLRmvQ=; b=r+HHSuaDEnT3Ypfai7l6PluriUprzkBFyoy6X2ca/icQQLf+SXdWUhqUrr1Mq1QJT8 PqYHgj05G4gjlfitg9dosV/qolQKDvlsOQFoJkJzKLSP9zdPJyQQkPH0ABQ5PsiC+pdi bPjNOKGP3l0q+Ow7s0n0dg+TuC52F7cjcwzJZy+DrsfAHd547l3hgj5vNVdjUQReBFFH jM0k0x/z1uFNLAWi9szlbBVXd+GSyzSxCm5CavfV9OhDArsmWW5eTLd0juV8dereNEwW cRDCdDahkeeiGp7bfcxoVKxdS9ArlvUyCaL6QkDGcoRVzZN5Ut8sDCWU3TMIdemAOGJN qfag== X-Gm-Message-State: AHPjjUg2szfVUZSSkPIZ84hZQE9MXgg+xMwBrXiqIecfO1jB2DGhjfCd 1NocUX7iIprw+4HuCY2iJnI2UoMM X-Google-Smtp-Source: AOwi7QAnh3I3zX/b3bSfgFXK1oJi8Bi2nGSNB4pxP+Ex31z9IVz9Qx+NE1+Oe6O4CO8/NuxyzeJ+rg== X-Received: by 10.98.67.209 with SMTP id l78mr2215519pfi.3.1506539594407; Wed, 27 Sep 2017 12:13:14 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z89sm21763448pff.13.2017.09.27.12.13.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Sep 2017 12:13:13 -0700 (PDT) To: cbor@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <1494b4c1-e889-9eef-1f2b-9a3ca566de25@gmail.com> Date: Thu, 28 Sep 2017 08:13:17 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] Explicitly define the CBOR data model X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 19:13:19 -0000 On 28/09/2017 05:58, Jeffrey Yasskin wrote: > Thanks! Your text looks good except for one inconsistency: >=20 > "Note that integer and floating-point values are distinct in this model= , > even if they have the same numeric value." is inconsistent with "For th= e > purposes of this specification, all number representations for the same= > numeric value are equivalent." in > https://cbor-wg.github.io/CBORbis/#rfc.section.3.6. This will interact = with > canonicalization: If 0 is equivalent to 0.0,=20 It seems wrong to implicitly cast floats into ints. I think the fix is to= delete "even if they have the same numeric value" and to state that a FP number = is *never* canonically mapped to an integer representation. Being picky, I think some mathematicians would tell you that a FP number represents a real number, which is always an approximation whereas an int= eger is exact. But in any case, even in a sloppy typing language like Python, 0 and 0.0 have distinct types. 0=3D=3D0.0 is True, but I believe that's because it's evaluated as 0=3D=3Dint(0.0) . Brian > then canonicalization has to > map integral floating point values to their integer representations, to= > preserve the fact that canonicalization makes duplicate map keys easy t= o > identify. This also leads to a question of whether small BigInt, > BigDecimal, and BigFloat values are equivalent to integer and floating > values. >=20 > Jeffrey >=20 > On Wed, Sep 27, 2017 at 7:39 AM, Carsten Bormann wrote: >=20 >> Jeffrey Yasskin has proposed to write some text for CBORbis that >> explicitly defines CBOR's data model: >> >> https://github.com/cbor-wg/CBORbis/issues/2 >> >> I have now written a draft for such a section, available at: >> >> https://github.com/cbor-wg/CBORbis/blob/master/datamodels.md >> >> * Do we want to have such a section? >> * Is the proposed text the right one? >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >> >=20 >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Wed Sep 27 13:11:55 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088FF134FF5 for ; Wed, 27 Sep 2017 13:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qS1T2q0opjEw for ; Wed, 27 Sep 2017 13:11:51 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B11E134EC3 for ; Wed, 27 Sep 2017 13:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v8RKBlGR026085; Wed, 27 Sep 2017 22:11:47 +0200 (CEST) Received: from client-0163.vpn.uni-bremen.de (client-0163.vpn.uni-bremen.de [134.102.107.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3y2TVq3SJJzDLr5; Wed, 27 Sep 2017 22:11:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <1494b4c1-e889-9eef-1f2b-9a3ca566de25@gmail.com> Date: Wed, 27 Sep 2017 22:11:46 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 528235906.603608-807a55b55f00dbb9a5c80f24e6d234be Content-Transfer-Encoding: quoted-printable Message-Id: <89C5948B-D7D0-4DD7-87B4-227B4DB6DC7E@tzi.org> References: <1494b4c1-e889-9eef-1f2b-9a3ca566de25@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] Explicitly define the CBOR data model X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 20:11:54 -0000 > On Sep 27, 2017, at 21:13, Brian E Carpenter = wrote: >=20 > On 28/09/2017 05:58, Jeffrey Yasskin wrote: >> Thanks! Your text looks good except for one inconsistency: >>=20 >> "Note that integer and floating-point values are distinct in this = model, >> even if they have the same numeric value." is inconsistent with "For = the >> purposes of this specification, all number representations for the = same >> numeric value are equivalent." in >> https://cbor-wg.github.io/CBORbis/#rfc.section.3.6. This will = interact with >> canonicalization: If 0 is equivalent to 0.0,=20 >=20 > It seems wrong to implicitly cast floats into ints. I think the fix is = to delete > "even if they have the same numeric value=E2=80=9D I think you are arguing for keeping =E2=80=9Ceven if they have the same = numeric value=E2=80=9D =E2=80=94 the sentence is trying to say that at = the data model level, integers and floating point values are distinct, = as they are in most programming languages (JavaScript being a notable = exception). > and to state that a FP number is > *never* canonically mapped to an integer representation. Right, this is what will happen in an environment (language + libraries) = that already distinguishes them. You cannot keep integers and integral floating point values separate in = JavaScript, as it *only* has floating point values. So something here = has to go, and I think after four years of CBOR we have pretty good = evidence that people want floating point to be separate from integer, = JavaScript notwithstanding. > Being picky, I think some mathematicians would tell you that a FP = number > represents a real number, Yes. Actually a number from the subset of the rational numbers, or a = non-finite (=C2=B1 Infinity, NaNs). > which is always an approximation You cannot represent =CF=80 in a floating point value except for an = approximation, but all finite floating point numbers are exact = representations of their actual (rational) values. Binary64 has an = exact representation of 0.5, but needs to approximate 0.1 (binary = numbers need to approximate 1/10 just as decimal numbers need to = approximate 1/3). (Programming languages like Scheme actually make a difference between = exact and inexact numbers; that is an innovation that is unfortunately = rarely found elsewhere.) > whereas an integer > is exact. But in any case, even in a sloppy typing language like = Python, > 0 and 0.0 have distinct types. 0=3D=3D0.0 is True, but I believe = that's > because it's evaluated as 0=3D=3Dint(0.0) . (Actually, the 0 is coerced into a 0.0, not the other way around, or 0 = =3D=3D 0.1 would hold.) Gr=C3=BC=C3=9Fe, Carsten >=20 > Brian >=20 >> then canonicalization has to >> map integral floating point values to their integer representations, = to >> preserve the fact that canonicalization makes duplicate map keys easy = to >> identify. This also leads to a question of whether small BigInt, >> BigDecimal, and BigFloat values are equivalent to integer and = floating >> values. >>=20 >> Jeffrey >>=20 >> On Wed, Sep 27, 2017 at 7:39 AM, Carsten Bormann = wrote: >>=20 >>> Jeffrey Yasskin has proposed to write some text for CBORbis that >>> explicitly defines CBOR's data model: >>>=20 >>> https://github.com/cbor-wg/CBORbis/issues/2 >>>=20 >>> I have now written a draft for such a section, available at: >>>=20 >>> https://github.com/cbor-wg/CBORbis/blob/master/datamodels.md >>>=20 >>> * Do we want to have such a section? >>> * Is the proposed text the right one? >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >>=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Sep 27 13:30:04 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D7E13432A for ; Wed, 27 Sep 2017 13:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f933qAh3BGSC for ; Wed, 27 Sep 2017 13:30:00 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16580134F03 for ; Wed, 27 Sep 2017 13:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v8RKTtd2009722; Wed, 27 Sep 2017 22:29:55 +0200 (CEST) Received: from client-0163.vpn.uni-bremen.de (client-0163.vpn.uni-bremen.de [134.102.107.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3y2Tvl5SSlzDLrC; Wed, 27 Sep 2017 22:29:55 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Wed, 27 Sep 2017 22:29:55 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 528236994.821353-0052b973f5cd6aee5e6fbb0bec455176 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] Explicitly define the CBOR data model X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 20:30:03 -0000 > On Sep 27, 2017, at 18:58, Jeffrey Yasskin = wrote: >=20 > Thanks! Your text looks good except for one inconsistency: >=20 > "Note that integer and floating-point values are distinct in this = model, even if they have the same numeric value." is inconsistent with = "For the purposes of this specification, all number representations for = the same numeric value are equivalent." in = https://cbor-wg.github.io/CBORbis/#rfc.section.3.6. This will interact = with canonicalization: If 0 is equivalent to 0.0, then canonicalization = has to map integral floating point values to their integer = representations, to preserve the fact that canonicalization makes = duplicate map keys easy to identify. This also leads to a question of = whether small BigInt, BigDecimal, and BigFloat values are equivalent to = integer and floating values. Good point. These are not easy questions, and I think we have collected = some implementation experience that argues for a cleaner separation of = integer and floating point values. We may want to separate = implementation from data model questions here. E.g., -2**64 is a bignum = on most platforms, but should be represented as a basic =E2=80=9Cnegative = integer=E2=80=9D canonically; this is the kind of consideration that 3.6 = was trying to address. Representing a floating point 0.0 by integer 0 = may still make sense in a specific data model, but it should not be part = of the generic data model. At this point, I=E2=80=99m quite happy about the new "data models" text, = because it already has helped clarify some issues (if not their = desirable resolutions). Numeric systems are freakily hard, and we = couldn=E2=80=99t expect to get all nooks and crannies right in the = initial RFC. It may be worthwhile to collect some more information about = implementation considerations posed by specific environments (int vs. = float in JavaScript, =E2=80=9Cobject" vs. map in JavaScript, map vs. = array in Lua, etc.) in a document that helps designers of specific data = models to make them as widely applicable as possible. Gr=C3=BC=C3=9Fe, Carsten