From nobody Wed May 2 02:22:30 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B7E1270A7 for ; Wed, 2 May 2018 02:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 lTCvMVFq8UOD for ; Wed, 2 May 2018 02:22:26 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 0439D12D94B for ; Wed, 2 May 2018 02:22:26 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id o78so23094589wmg.0 for ; Wed, 02 May 2018 02:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=/1b89IAyBLzc76dOv5hfjWnsUPi6uYnfA2RhfKKcQB0=; b=LotZhRCQsqSB3tJPOPDFOdL+KVBqpBMXu1kPAfwt6hSob4tCO6csT37931WbvbttQq A4tAFTohuaQn52CAO9yCR2wCOdOSFAksZKV3sv+8TlXv18xo04WjbOdk5xZLwiv4A/oS GcC63SxQ2DggyvglFXgbGEN58m4xEwAtKFMnCFr93zzP+3CFVS0ekbhA4tQUrqkxtO3K tClJj/OkmNymZQuT/tusq+swuAKom1g1pufLE+R125s6oYNzpTlJzvVZXP24ClW0yR8X 3r/Fz/jvbK5T792EQs9IU1ke6z9P9NQCwPu6s1baaD7ZI0VXpEqjWF+DP5B1u9olAFrt Cupg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/1b89IAyBLzc76dOv5hfjWnsUPi6uYnfA2RhfKKcQB0=; b=gYWqBqc2cT4AyLUCOa8T0B6dJvpkS0GeoLq9VuAiEyZ1Jhc1/aPGQ3Bso7HtWI3MQ7 3aOCfi0+C1Bcs0tBLxSeuafm5iaaDFLbGWW9CPyj1W2qURp+bi1bv8gzmBS+j3uW9xJW 6qn92XZ3+Entf72Lvd+9dz3oAwtHBOqy2rjPOI7EP6GnXa12rSUONXJEzB6YFw6rKs+4 HcSq4muJylWbXRPfFvrE4MD5Qo85TpvFaVEQaFTBuFfgeaSvq2eA+2bnc3pIRzgiDyp8 puA/EzDtUM8Y/84Hn44vuPJ9Y4ajnPZ8cVTvHFipAtODf9zMnoL9/NO7M6XYvZ7Bz+NA yupw== X-Gm-Message-State: ALQs6tDUjcQsp1ZjA27GhoO0EBC4gQiW+VpUGFW8eR/Chk2l06vIKd0L DR7+o47QsuTV3gm9KTsXDgRbIw== X-Google-Smtp-Source: AB8JxZrOYy5m3Y4tTQAwzGcG0wkNyUZ0k7FSSTbt4RiewF/I8wJ65o6cEPLHmRg5of6ik2LbCOPhjA== X-Received: by 10.28.213.198 with SMTP id m189mr11861867wmg.28.1525252944011; Wed, 02 May 2018 02:22:24 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id p10-v6sm11208715wre.77.2018.05.02.02.22.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 May 2018 02:22:23 -0700 (PDT) From: Anders Rundgren To: "json@ietf.org" References: <65d998cb-8aed-205b-98bd-ac1297310a50@gmail.com> Message-ID: <45af54a1-89a3-0128-0ad7-59f8f1907d92@gmail.com> Date: Wed, 2 May 2018 11:22:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <65d998cb-8aed-205b-98bd-ac1297310a50@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] I-D: draft-rundgren-json-canonicalization-scheme-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 02 May 2018 09:22:28 -0000 Ping? JSON canonicalization is impossible or at least very hard. JSON canonicalization is stupid, just dress everything in Base64Url (like JOSE), and the problem is solved. JSON canonicalization is unnecessary, JSON is "as is", now we turn to CBOR and ProtoBuf which were designed with canonicalization in mind. On 2018-03-16 06:46, Anders Rundgren wrote: > No, this I-D has not yet been submitted to the IETF but it is available anyway :-) > > Abstract > > Cryptographic operations like hashing and signing depend on that the target > data does not change during serialization, transport, or parsing. By applying > the rules defined by JCS (JSON Canonicalization Scheme), data provided in the > JSON [RFC8259] format can be exchanged "as is", while still being subject to > secure cryptographic operations. JCS achieves this by combining the strict > serialization of JSON data defined in ECMAScript [ES6] with a platform > independent sorting scheme. > > The intended audiences of this document are JSON tool vendors, as well as > designers of JSON based cryptographic solutions. > > > Current draft: > https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html > > Workspace: > https://github.com/cyberphone/json-canonicalization > > I would be VERY happy to get some feedback on this! > If you have any interest in co-authoring, I'm open to suggestions. > > Thanx, > Anders > > // ES6 based JSON canonicalizer > 'use strict'; > var canonicalize = function(object) { > >     var buffer = ''; >     serialize(object); >     return buffer; > >     function serialize(object) { >         if (object !== null && typeof object === 'object') { >             if (Array.isArray(object)) { >                 buffer += '['; >                 let next = false; > // Array - Maintain element order >                 object.forEach((element) => { >                     if (next) { >                         buffer += ','; >                     } >                     next = true; > // Recursive call >                     serialize(element); >                 }); >                 buffer += ']'; >             } else { >                 buffer += '{'; >                 let next = false; > // Object - Sort properties before serializing > Object.keys(object).sort().forEach((property) => { >                     if (next) { >                         buffer += ','; >                     } >                     next = true; > // Properties are just strings - Use ES6 >                     buffer += JSON.stringify(property); >                     buffer += ':'; > // Recursive call >                     serialize(object[property]); >                 }); >                 buffer += '}'; >             } >         } else { > // Primitive data type - Use ES6 >             buffer += JSON.stringify(object); >         } >     } > }; From nobody Sat May 5 23:21:11 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C098A126C25 for ; Sat, 5 May 2018 23:21:08 -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 FlET2ywujnIL for ; Sat, 5 May 2018 23:21:07 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 A3846126B6D for ; Sat, 5 May 2018 23:21:06 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id g21-v6so24743157wrb.8 for ; Sat, 05 May 2018 23:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=p/hMqf8ZguY+kgZWqi9Fz4QsbEmiUFQVeqm1ycEV4oM=; b=mItd4SExma2LSN0zyCwRonXpD6JNbJtq/HjXfNtEx0GAUdl1jFwKfy8q+iqexZBg30 Vqw9Z1urRzdysZkzdnQbYudtOXixp+bNQyS8gWXw3H6+VeM8AMmRu7GtzAxlhoYBXLAZ JDdyzM9CbE1s0kk1+wG2JMcpbgyLnHxNdifuGKNAWZUp7/3gBtvjBBsSO9nA3Mg+X9/b oheM6PCB6qM3duuAVDURs31KuKKdtbroYzrdYKeV8Vj2tQp7zF2X2PS6R4EmR3yPoyKx 2VmTCLnNXCpvznAdkIWlLUCBPSnwLLwQBqiNyjw0f9GJtt0oRbe+jxB6D0ilUzkt/dlT Uz7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=p/hMqf8ZguY+kgZWqi9Fz4QsbEmiUFQVeqm1ycEV4oM=; b=meGp12kBRju9Izq5KUW6qPmu3KaKglRTySuPDoTtDoYVy9dpkqYh9Qy1hipL2sqobk PPbxQ4TRQzscca2Aw+LbSFjh/uVbzV0qvsphUqQOih3Tk2wXR3kuMrpKUbJQ0jZrwbVj q0QDYc7e/cYmzuNXIF7Qu6H9+TlvdJsAfZB/0s2Z3NIi3u/oIwMoVH17tkxrPpOenYT+ FFIfRV7BcXRduLVIZ2MLuFFTr2asdyyMS/SvIWA58kU3J2JYZtmGZbdc6tgVAS2Mciej lntBc3RyS1s8kqgW9gO77T6kh1OjAHqnttB11rF6/m9N4yuK20WQ7hzCkrQGf93TIrOZ Kt4w== X-Gm-Message-State: ALQs6tBWya5Fxf2VqeZqwwAdbs5UVAbfiOLcdfnkNnHhoyVM/uJngft9 HqrKJQMD/izNx17fisecHe13YQ== X-Google-Smtp-Source: AB8JxZr6gfeKH6yc2NjZzmUhomXCKUhwwacBX1wOxNg99yyf1LObJKmW5qG66khuTu17FHlj51BR9Q== X-Received: by 2002:adf:bbce:: with SMTP id z14-v6mr27016458wrg.183.1525587664795; Sat, 05 May 2018 23:21:04 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id u20-v6sm29924531wru.33.2018.05.05.23.21.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 May 2018 23:21:04 -0700 (PDT) From: Anders Rundgren To: "json@ietf.org" Message-ID: Date: Sun, 6 May 2018 08:21:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Json] Bug in RFC7493 (I-JSON)? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 06 May 2018 06:21:09 -0000 During testing of the JSON canonicalizer [1,2] I tried with an integer just above the specified limit (2**53) + 1 and to my surprise it didn't fail. A short run with an IEEE-754/ES6 debugger seemed to confirm that +-2**53 is the actual limit for integers. Input floating point: 9007199254740991 Output floating point: 9007199254740991 Hex value: 433fffffffffffff Binary value: 0 10000110011 1111111111111111111111111111111111111111111111111111 Input floating point: 9007199254740992 Output floating point: 9007199254740992 Hex value: 4340000000000000 Binary value: 0 10000110100 0000000000000000000000000000000000000000000000000000 Anders 1] https://github.com/cyberphone/json-canonicalization#json-canonicalization 2] https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html From nobody Sat May 5 23:34:31 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE709126C25 for ; Sat, 5 May 2018 23:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.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 RSJ0NRjzj0ZY for ; Sat, 5 May 2018 23:34:27 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 4E036126B6D for ; Sat, 5 May 2018 23:34:27 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id j5-v6so10934154wme.5 for ; Sat, 05 May 2018 23:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LtWYz60P9j0UK873RAytr52hW1MsYgdPYULZCjYQXWY=; b=sr1EDbu1IWR0k9j3+WUiiVJz8484jWIATkKRWBosXNXI/SSRJpdmtDaLTzEqRHAbat 2y/3HJBxRahvtcgc5aOKrMiYnp04lcuzRmCAqGnTMCK3xV+x2hQj9quS1w1f7fhwwSqI aItJVd2v7LCrr+WTq8aF9Dsy7sJVHPCP8sPDh3KKIA8wrTkR66FzSycyGhwePotch5H7 QzTeXOMWOH/ClXILMwvhcp2KV2F3AXACLL8kRKU4jICKEGL9ROpZWyVBDNW0XpevxLwB OF/ul5kGJ33sydKuvIIRdKXxFB/KhSyVpbYiEEBnG0oKoUMHNuE64tDHNN79d/iaN9aK W8Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LtWYz60P9j0UK873RAytr52hW1MsYgdPYULZCjYQXWY=; b=tMBiuEdTD4Q+hRvdV/gkhp15pY+zoIhGwcXfj9bfSXUvPELFWPWnuELRy9hHp5MJnv hBA95A5SPDy8D6R3RavH4qHkP/jG5rd7sh6k8i4bAse3b5XhsOTWU2FHfudOOuA6J7AD NUNZI/iuPHvxPTH24X0xsoMcLL0e42fHUsX26Wsr765/QN2xN8+8/UH7jMsbMDJXL2tz PQj/KpiFg++JoEgn6IyVZpiTJPYNUPWfro4uHADe8VB6qg4X5wdDioF8sbWcGQHEnDES AB9mSfJZEfhkZgV7i6k/FbbF17mj7CzJkngg2e7N9gNx9b1AMQeP22yYviI7kv+yaBLa S47g== X-Gm-Message-State: ALQs6tCkvcbJeHP4ndcpOwlIjNPurTwuy2czrsRd3NWG4QcOrPKaZsc/ uZ6eBbYqyUEGfQWjx9aQ0eDY2oWbskCvTAt5G/8B6g== X-Google-Smtp-Source: AB8JxZo0/MDBiFBCQmhMar8k1x3Tyiqd0exADdTTpEwDdbjuBDrBekzOe6QyHB0QivGds271ui97kpOEZLdUscU5Aa4= X-Received: by 2002:a50:bd84:: with SMTP id y4-v6mr31325139edh.18.1525588465726; Sat, 05 May 2018 23:34:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.188.6 with HTTP; Sat, 5 May 2018 23:34:05 -0700 (PDT) X-Originating-IP: [24.86.156.110] In-Reply-To: References: From: Tim Bray Date: Sat, 5 May 2018 23:34:05 -0700 Message-ID: To: Anders Rundgren Cc: "json@ietf.org" Content-Type: multipart/alternative; boundary="00000000000092c701056b83bedf" Archived-At: Subject: Re: [Json] Bug in RFC7493 (I-JSON)? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 06 May 2018 06:34:30 -0000 --00000000000092c701056b83bedf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So=E2=80=A6 the spec underpromises and overdelivers :) Seriously, I wonder if this behavior is portable across IEEE 754 implementations. On Sat, May 5, 2018 at 11:21 PM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > During testing of the JSON canonicalizer [1,2] I tried with an integer > just above the specified limit (2**53) + 1 and to my surprise it didn't > fail. > A short run with an IEEE-754/ES6 debugger seemed to confirm that +-2**53 > is the actual limit for integers. > > Input floating point: 9007199254740991 > Output floating point: 9007199254740991 > Hex value: 433fffffffffffff > Binary value: 0 10000110011 111111111111111111111111111111 > 1111111111111111111111 > > Input floating point: 9007199254740992 > Output floating point: 9007199254740992 > Hex value: 4340000000000000 > Binary value: 0 10000110100 000000000000000000000000000000 > 0000000000000000000000 > > Anders > > 1] https://github.com/cyberphone/json-canonicalization#json-can > onicalization > 2] https://cyberphone.github.io/doc/security/draft-rundgren-jso > n-canonicalization-scheme.html > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --00000000000092c701056b83bedf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So= =E2=80=A6 the spec underpromises and overdelivers :)

Seriously, I wonder if this behavior is portabl= e across IEEE 754 implementations.
On Sat, May 5, 2018 at 11:21 PM, Anders Rundgr= en <anders.rundgren.net@gmail.com> wrote:
During testing of the JSON canonicalizer [1,2] = I tried with an integer just above the specified limit (2**53) + 1 and to m= y surprise it didn't fail.
A short run with an IEEE-754/ES6 debugger seemed to confirm that +-2**53 is= the actual limit for integers.

Input floating point: 9007199254740991
Output floating point: 9007199254740991
Hex value: 433fffffffffffff
Binary value: 0 10000110011 111111111111111111111111111111111111111111= 1111111111

Input floating point: 9007199254740992
Output floating point: 9007199254740992
Hex value: 4340000000000000
Binary value: 0 10000110100 000000000000000000000000000000000000000000= 0000000000

Anders

1] https://github.com/cyber= phone/json-canonicalization#json-canonicalization
2] https:/= /cyberphone.github.io/doc/security/draft-rundgren-json-canonicali= zation-scheme.html


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



--
- Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/tim= bray)
--00000000000092c701056b83bedf-- From nobody Sat May 5 23:52:15 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD36124BAC for ; Sat, 5 May 2018 23:52:14 -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 wJLeqGgGMzIr for ; Sat, 5 May 2018 23:52:12 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 516201200C1 for ; Sat, 5 May 2018 23:52:12 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id f2-v6so12980728wrm.3 for ; Sat, 05 May 2018 23:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GiHp1jbyQwa4ZxYWcZ9ZRjW9dv9zjZszu8YnV6kL3w0=; b=JHthtNg6jIFm4qeWrUR4gcL6WiQCHujHtstgvWCuaz9LWfGA3F4R980v8Xex7NRYhL CfjfgNf9a7sy4x3aer4cMfs/XyE6bvv0HDGaqtsvGIgAT3hEM3q6D4UBgyP9EcRhB1Ae jRwqGhTTeUqurPyFcYZi/VXiJwXnTa+w9GopXn31Fnt+urvueETHWSKn5RQ9MzvscqtM yta43U7v1piF5SguaId/vFLFmHQcNXEB9WnLO9h6YwUqIRwT2UQyiEUH3Mh0MaWjHTWu nEoU2ADjkEHEytRRyjJIJwZ9Ynqer25yny15JEPkDz/fCBOp6NOgKccWHKuPFVrqgM4Z FqFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GiHp1jbyQwa4ZxYWcZ9ZRjW9dv9zjZszu8YnV6kL3w0=; b=iE3IJQ2lGlfQhC/l4QbGZOwV4HchUh7MpkDVEOik7invhNkkzacRaj1hLgXr2mM6ur TGXFgUxvpUvKskgLeBAyo7l5c1kvDwSMouwrFFyiBpnAkpCvXbcQs7HEmHXRl3se14nI FbnBH6SrjM/xojtUFSXmzNNK9Zvaw0ohqPEt9bYk0cLR+K6uMYNw37jQ21O+gkPm7bnX eaRWSShjTsQk0qo0hqMW9SiyBIn1eKUhD96+gt/WngGOXbwvomlkNhdrfBZfPDrQaK+w H8FMTsL7+xaO8Zfafrcl/q+OdTVvy+XGVj88+rLsaK3Rog+h4iMSaMi4mF9xPvFjnm+h Y+Fw== X-Gm-Message-State: ALQs6tDLotunVG0zFqjDZANEaQEzdZv0EM8qjGPaQyr2nebq19YywcEF tTOeKv4Q0BBFDAbLLRZvlPridg== X-Google-Smtp-Source: AB8JxZo5AP8oRcGqb3Diq0uOY3/Zq4YFH1qTyI6djdul+eaoNdwBzY3oYyvVbOrAZ6hdWlgnAW91Qg== X-Received: by 2002:adf:8212:: with SMTP id 18-v6mr25257364wrb.144.1525589530163; Sat, 05 May 2018 23:52:10 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id q34-v6sm28663325wrb.27.2018.05.05.23.52.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 May 2018 23:52:09 -0700 (PDT) To: Tim Bray Cc: "json@ietf.org" References: From: Anders Rundgren Message-ID: <543556f0-660b-7396-2528-2f0b382f3c05@gmail.com> Date: Sun, 6 May 2018 08:52:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] Bug in RFC7493 (I-JSON)? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 06 May 2018 06:52:14 -0000 On 2018-05-06 08:34, Tim Bray wrote: > So… the spec underpromises and overdelivers :) Indeed :-) > > Seriously, I wonder if this behavior is portable across IEEE 754 implementations. It seems so. At least Browsers, Node.js, .NET, and Java are identical on this particular point. Anyway, it is prerequisite for the JSON canonicalization scheme that JSON Numbers are treated identical. I just ported 2000 lines of Java code to C# to achieve this. It passed 100 million random and special numbers including de-normalized edge-cases like Hex: 0000000000000001 ES6: 5e-324 Anders > > On Sat, May 5, 2018 at 11:21 PM, Anders Rundgren > wrote: > > During testing of the JSON canonicalizer [1,2] I tried with an integer just above the specified limit (2**53) + 1 and to my surprise it didn't fail. > A short run with an IEEE-754/ES6 debugger seemed to confirm that +-2**53 is the actual limit for integers. > > Input floating point: 9007199254740991 > Output floating point: 9007199254740991 > Hex value: 433fffffffffffff > Binary value: 0 10000110011 1111111111111111111111111111111111111111111111111111 > > Input floating point: 9007199254740992 > Output floating point: 9007199254740992 > Hex value: 4340000000000000 > Binary value: 0 10000110100 0000000000000000000000000000000000000000000000000000 > > Anders > > 1] https://github.com/cyberphone/json-canonicalization#json-canonicalization > 2] https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > > > -- > - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray) From nobody Sun May 6 01:13:27 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5582C126CF6 for ; Sun, 6 May 2018 01:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 R5muHxjEiT2z for ; Sun, 6 May 2018 01:13:23 -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 B40EA124BAC for ; Sun, 6 May 2018 01:13:22 -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 w468DI3m014723; Sun, 6 May 2018 10:13:18 +0200 (CEST) Received: from [100.117.235.67] (ip-109-40-67-195.web.vodafone.de [109.40.67.195]) (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 40dz5n5pdlzDXQ0; Sun, 6 May 2018 10:13:17 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-E8457CE4-9F5B-4609-A46B-CC7FF7D73B58 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (15E302) In-Reply-To: Date: Sun, 6 May 2018 10:13:16 +0200 Cc: "json@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <287181EC-8CFD-4C3D-A543-9E6324BAB64E@tzi.org> References: To: Anders Rundgren Archived-At: Subject: Re: [Json] Bug in RFC7493 (I-JSON)? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 06 May 2018 08:13:25 -0000 --Apple-Mail-E8457CE4-9F5B-4609-A46B-CC7FF7D73B58 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The question is not whether a number makes it through a round-trip (lots mor= e do so) but whether the result of deciding is unambiguous. If you get 2**53= , you don't know whether the sender sent 2**53 or 2**53+1, so you shouldn't b= e accepting either number as if it were unambiguous.=20 Sent from mobile > On 6. May 2018, at 08:21, Anders Rundgren w= rote: >=20 > During testing of the JSON canonicalizer [1,2] I tried with an integer jus= t above the specified limit (2**53) + 1 and to my surprise it didn't fail. > A short run with an IEEE-754/ES6 debugger seemed to confirm that +-2**53 i= s the actual limit for integers. >=20 > Input floating point: 9007199254740991 > Output floating point: 9007199254740991 > Hex value: 433fffffffffffff > Binary value: 0 10000110011 1111111111111111111111111111111111111111111111= 111111 >=20 > Input floating point: 9007199254740992 > Output floating point: 9007199254740992 > Hex value: 4340000000000000 > Binary value: 0 10000110100 0000000000000000000000000000000000000000000000= 000000 >=20 > Anders >=20 > 1] https://github.com/cyberphone/json-canonicalization#json-canonicalizati= on > 2] https://cyberphone.github.io/doc/security/draft-rundgren-json-canonical= ization-scheme.html >=20 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 --Apple-Mail-E8457CE4-9F5B-4609-A46B-CC7FF7D73B58 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable The question is not whether a number makes i= t through a round-trip (lots more do so) but whether the result of deciding i= s unambiguous. If you get 2**53, you don't know whether the sender sent 2**5= 3 or 2**53+1, so you shouldn't be accepting either number as if it were unam= biguous. 

Sent from mobile

On 6. May 2018, at 08:2= 1, Anders Rundgren <ande= rs.rundgren.net@gmail.com> wrote:

During testing of the JSON canonicalizer [1,2] I tried with a= n integer just above the specified limit (2**53) + 1 and to my surprise it d= idn't fail.
A short run with an IEEE-754/ES6 debugger seemed= to confirm that +-2**53 is the actual limit for integers.
<= /span>
Input floating point: 9007199254740991
Outpu= t floating point: 9007199254740991
Hex value: 433fffffffffff= ff
Binary value: 0 10000110011 11111111111111111111111111111= 11111111111111111111111

Input floating poin= t: 9007199254740992
Output floating point: 9007199254740992<= /span>
Hex value: 4340000000000000
Binary value: 0 1= 0000110100 0000000000000000000000000000000000000000000000000000

Anders

1] ht= tps://github.com/cyberphone/json-canonicalization#json-canonicalization<= /span>
2] https://cyberphone.github.io/d= oc/security/draft-rundgren-json-canonicalization-scheme.html
<= span>

_____________________________________= __________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json

= --Apple-Mail-E8457CE4-9F5B-4609-A46B-CC7FF7D73B58-- From nobody Mon May 7 22:37:11 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513DA12D965 for ; Mon, 7 May 2018 22:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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=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 ArAdisARyavc for ; Mon, 7 May 2018 22:37:07 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 EBB1A1200E5 for ; Mon, 7 May 2018 22:37:06 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id y189-v6so934646wmc.3 for ; Mon, 07 May 2018 22:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=RnXEwZ5yosOCacAZanuZEpq4G+3EuNVHBODNxjYYiGk=; b=Z5SnsWuV5xtOSllzjCAbTqH/HOl12ukvKtwhxdtOQRvPbsKfX0VUryaX+py7EIBnwx JXqK886BXqkiGeMJ8C/yHZxKFlbN6gqhJYoYQj5DqFg2zX8pac3tw9fsH/i07KsY34oG T2M+wmLcWgBYX2KCcxt2lefVEQoRzoVNqrCD1tfcieusCRW8FgOzCVwc2OhbWPa2B0ER /2Ae/7HcGqokqbUYbbosUvEBKRbczoAgi4Fn7cypaJXZoqmaBspfT141HY+6kW9l5Qjq +9vFnWftV9aS5KiRm4K1sJ7JhuIDFr0HVAlY2ML/JSIXNiXWBeuBPDXcA1SlvsMp7zm4 IwQg== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RnXEwZ5yosOCacAZanuZEpq4G+3EuNVHBODNxjYYiGk=; b=fTRz2wXdxeVpk9rx4tBA1Q+5WzuBaljduoD2bGjmSyek8PTijpcRpFG6R19a1wfEOf icIkIzK15hDTxPbo8TTX3NgYuKn2uEQpJwCdnO5/thUzZjHMlYYEoOSJ+qMTx71+welI XIP6HjjzfL2Y48bfuACgbC699J1iyG3By5zY/F2OeTe5ueIWvVQQ7GJc5pk5XEzltbSW Qf9aXzocBirYtb52fzqiwblAtCX0AxIH5JBjxar4uh3xyIOgaDXEOzLwD456/3apCR26 zRCg8LcvdMtS+c2NvbKdmunxeIdhb8G+RgMsHJAxIq2HUT7VMvnjufm5CbPHGChDI4Uw YjaQ== X-Gm-Message-State: ALQs6tC5aYmp6YldTWh5WDkRQqF87PyAA/Rnp4VE4se69Zcnk+5NP8yD BjzRiMRiUbh7VZ4G0sj8XKN7JQ== X-Google-Smtp-Source: AB8JxZqC2JJKsHF+EJPA8xdaH0xFK2QcxRkrgjFQqdH9m+DQhnhtKc+TTGoO27h5sSqcbuD0eCOBvg== X-Received: by 2002:a50:a4f6:: with SMTP id x51-v6mr52282822edb.247.1525757825169; Mon, 07 May 2018 22:37:05 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id x20-v6sm13242500edr.24.2018.05.07.22.37.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 May 2018 22:37:04 -0700 (PDT) To: "json@ietf.org" References: From: Anders Rundgren Message-ID: Date: Tue, 8 May 2018 07:37:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] Bug in RFC7493 (I-JSON)? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 May 2018 05:37:09 -0000 The source of the limit probably comes from the ECMAScript which states: "The value of Number.MAX_SAFE_INTEGER is the largest integer n such that n and n + 1 are both exactly representable as a Number value" This definition departs from other languages' way of defining MAX values for numeric data types. That is, for storage and transmission Number.MAX_SAFE_INTEGER + 1 (2**53) is a fully valid integer. I have updated my documents and software accordingly. Microsoft is taking on the Number serialization issue: https://github.com/Microsoft/ChakraCore/issues/149#issuecomment-387232702 which is great since it is a prerequisite for compliance with: https://tools.ietf.org/id/draft-erdtman-jose-cleartext-jws-00.html Anders https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html#json.ieee754.test From nobody Wed May 9 22:02:19 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A04C12EA53 for ; Wed, 9 May 2018 22:02:17 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 oH7TDZ67jOyH for ; Wed, 9 May 2018 22:02:15 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E1012EA42 for ; Wed, 9 May 2018 22:02:15 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 916C4B81EA7; Wed, 9 May 2018 22:02:05 -0700 (PDT) To: tbray@textuality.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, mamille2@cisco.com, paul.hoffman@vpnc.org X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: anders.rundgren.net@gmail.com, json@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180510050214.916C4B81EA7@rfc-editor.org> Date: Wed, 9 May 2018 22:02:06 -0700 (PDT) Archived-At: Subject: [Json] [Technical Errata Reported] RFC7493 (5354) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 May 2018 05:02:17 -0000 The following errata report has been submitted for RFC7493, "The I-JSON Message Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5354 -------------------------------------- Type: Technical Reported by: Anders Rundgren Section: 2.2 Original Text ------------- An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. Corrected Text -------------- An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740992 (i.e., that is outside the range [-(2**53), (2**53)]) as an exact value. Notes ----- The limit is presumably derived from ECMAScript which says: "The value of Number.MAX_SAFE_INTEGER is the largest integer n such that n and n + 1 are both exactly representable as a Number value" However, Number.MAX_SAFE_INTEGER is 9007199254740991. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7493 (draft-ietf-json-i-json-06) -------------------------------------- Title : The I-JSON Message Format Publication Date : March 2015 Author(s) : T. Bray, Ed. Category : PROPOSED STANDARD Source : JavaScript Object Notation Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed May 9 23:46:23 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15C9127078 for ; Wed, 9 May 2018 23:46:21 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 NS2eMpHm5JRO for ; Wed, 9 May 2018 23:46:20 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62340126CE8 for ; Wed, 9 May 2018 23:46:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8B438B8163A; Wed, 9 May 2018 23:46:19 -0700 (PDT) To: tbray@textuality.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, linuxwolf+ietf@outer-planes.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: anders.rundgren.net@gmail.com, json@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180510064619.8B438B8163A@rfc-editor.org> Date: Wed, 9 May 2018 23:46:19 -0700 (PDT) Archived-At: Subject: [Json] [Technical Errata Reported] RFC8259 (5355) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 May 2018 06:46:22 -0000 The following errata report has been submitted for RFC8259, "The JavaScript Object Notation (JSON) Data Interchange Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5355 -------------------------------------- Type: Technical Reported by: Anders Rundgren Section: 6 Original Text ------------- Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values. Corrected Text -------------- Note that when such software is used, numbers that are integers and are in the range [-(2**53), (2**53)] are interoperable in the sense that implementations will agree exactly on their numeric values. Notes ----- The limit is presumably derived from ECMAScript which says: "The value of Number.MAX_SAFE_INTEGER is the largest integer n such that n and n + 1 are both exactly representable as a Number value" However, Number.MAX_SAFE_INTEGER is 9007199254740991 ((2*53)-1) making n+1 (2**53) the largest exactly representable Number value Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8259 (draft-ietf-jsonbis-rfc7159bis-04) -------------------------------------- Title : The JavaScript Object Notation (JSON) Data Interchange Format Publication Date : December 2017 Author(s) : T. Bray, Ed. Category : INTERNET STANDARD Source : Javascript Object Notation Update Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Thu May 10 12:49:55 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44517120724 for ; Thu, 10 May 2018 12:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=cursive.net 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 gS7ufQr8N3qM for ; Thu, 10 May 2018 12:49:51 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 4E4E4127136 for ; Thu, 10 May 2018 12:49:51 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id 11-v6so2812045ois.8 for ; Thu, 10 May 2018 12:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cursive.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SZQ5Pr6gwRsl3IQFxP7pEP740KPeh3tM2gWQjqrT5jI=; b=LfcLoa9bddDaNEs+iHXcBZG8y+iVeUnc946VNk9ASaAZukUkDinb5eFKA1bd2ta4EH RfUPo6bL1d5ECi/jdh6DNJT2QL95rM//uJM2RMSpO+g/GFD/tgJeXiWCquW/yY3abiDv ExUrrUCllox7t6jAILPrLJqi0TD7aQSYWh25s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SZQ5Pr6gwRsl3IQFxP7pEP740KPeh3tM2gWQjqrT5jI=; b=AggzM/7e7Zqq3EDqUaYsP+D3pbhAlGw3A7STYslozVPwFGhIv9ck3Tc+MIsvVJhzEA KlYFz0CGoEqTYmJDwG1J4a1PZTQc7g8QJvSCkPFwp8KhGp8PlV/fsh/wbs0U61GCcH4+ k/pdkPA9YCafwTBGbcusPlPMhOCOxIoA83QhdQisxt2VbpP7YJEIVV55+mvF0v8JZy9F 80shKi4FQ3a/KSZW1tuGEc7VrEQfNHL0PK+RIWQfg+8c64z5C3X4sJNx3c7xQKawk07y 1jER5mITLW9X09OTczR2ovvqlbQn1sKyUdOAAAdvZfhs6oa+QTAE2zJGzr8vTQ7mbrid FFlQ== X-Gm-Message-State: ALKqPweu5GKYuKg8pnmmRzrhCKj8rTbf4HBxvPqrPRP1/v4hALLGy9G5 SaGa+tr18u493a+8zCVyZcBTNgmlHuo= X-Google-Smtp-Source: AB8JxZq5pddDOQFdkk0wNRH1p0+Lm7jKVOQP89sfnRPjqnqzFfGBOm3wxoupK/O/5gDi90qbo4ECLA== X-Received: by 2002:aca:2813:: with SMTP id 19-v6mr1696508oix.281.1525981790245; Thu, 10 May 2018 12:49:50 -0700 (PDT) Received: from [10.6.16.209] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id c21-v6sm749268oih.27.2018.05.10.12.49.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 May 2018 12:49:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Joe Hildebrand In-Reply-To: <20180510050214.916C4B81EA7@rfc-editor.org> Date: Thu, 10 May 2018 13:49:48 -0600 Cc: anders.rundgren.net@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: <4EB0B6DE-2416-4909-9EDA-975439055F33@cursive.net> References: <20180510050214.916C4B81EA7@rfc-editor.org> To: json@ietf.org X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (5354) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 May 2018 19:49:53 -0000 I disagree with this pretty thoroughly. Here is some example NodeJS = code to illustrate why: ```js const START =3D Number.MAX_SAFE_INTEGER - 2 const buf =3D Buffer.alloc(8) for (let i =3D 0; i < 5; i++) { const x =3D START + i buf.writeDoubleBE(x) const y =3D buf.readDoubleBE() console.log(`${x} 0x${buf.toString('hex')} ${y} ${x =3D=3D=3D y}`) } ``` And its output: 9007199254740989 0x433ffffffffffffd 9007199254740989 true 9007199254740990 0x433ffffffffffffe 9007199254740990 true 9007199254740991 0x433fffffffffffff 9007199254740991 true 9007199254740992 0x4340000000000000 9007199254740992 true 9007199254740992 0x4340000000000000 9007199254740992 true The point is that Number.MAX_SAFE_INTEGER is that last =E2=80=9Cinteger" = that has an unambiguous bit pattern, such that it round trips without = the possibility of something else having been intended. > On May 9, 2018, at 11:02 PM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7493, > "The I-JSON Message Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5354 >=20 > -------------------------------------- > Type: Technical > Reported by: Anders Rundgren >=20 > Section: 2.2 >=20 > Original Text > ------------- > An I-JSON sender cannot expect a receiver to treat an integer whose > absolute value is greater than 9007199254740991 (i.e., that is > outside the range [-(2**53)+1, (2**53)-1]) as an exact value. >=20 > Corrected Text > -------------- > An I-JSON sender cannot expect a receiver to treat an integer whose > absolute value is greater than 9007199254740992 (i.e., that is > outside the range [-(2**53), (2**53)]) as an exact value. >=20 > Notes > ----- > The limit is presumably derived from ECMAScript which says: >=20 > "The value of Number.MAX_SAFE_INTEGER is the largest integer n such = that n and n + 1 are both exactly representable as a Number value" >=20 > However, Number.MAX_SAFE_INTEGER is 9007199254740991. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7493 (draft-ietf-json-i-json-06) > -------------------------------------- > Title : The I-JSON Message Format > Publication Date : March 2015 > Author(s) : T. Bray, Ed. > Category : PROPOSED STANDARD > Source : JavaScript Object Notation > Area : Applications > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Thu May 10 22:01:31 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD5412D875 for ; Thu, 10 May 2018 22:01:29 -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 D83rdvuO3OuX for ; Thu, 10 May 2018 22:01:28 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 44D3B12D874 for ; Thu, 10 May 2018 22:01:27 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id m129-v6so833588wmb.3 for ; Thu, 10 May 2018 22:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=95E/piv0e/EUss6GW3G789R0Yc1FpqSeOMkgBJz940o=; b=H25g7ufTc8l9T2ZDlFPAjs4HnchxDmOgEjWm9GuGZfxI91J6BaQ/574k4eRbULPI9y fOWQ7eIuLEbxX5lBsiZPtqwXupIRp06Kb2+Aee0F266GdxWAmtDq1eT57CZJbPfGdNHv g/JIisZnprIb6e3oE25WZ6DuvNJGhlwFx+DKdEsQCf+KZbqlx2ELCK87aEAEwGpykWOg hJxjqUQ9OnSSBW+CJAGMPYBHwStaXE18u4ci3bBE6yS6+kpXfu3EDM6uJwMz7NQzwtl0 t9pWAZpkKUMOEr0ozf5lu1rU1XpuySKkkiI/VOAvlDl9KqOWg9nsKxQdgDe03uVKiE80 VC2w== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=95E/piv0e/EUss6GW3G789R0Yc1FpqSeOMkgBJz940o=; b=dofWUSHFKlqsim+DgSWHJl2DZW+MeaGn0bjwCvjA1ntnsiDgVjSAWRJrz9kGvAFC+b GpaqvMCvGL7Ke6RCsy0BlHlt4F0WPcy2paxWQT/Agi4fuu5EIKnLx0wQ/NMcToct0Ck8 SbktiAr6RNBzZgdjixYWGwx6JAdbx6Mf9HlEorKOKgurNYRu4HTPuhy7DHq7eNRqtMQh vcxBZvMzsfbU3amSkvWOthET82CZ3it95Y7/wZSU3e4AmfFGLtCC3d3g/Ul0wTcjeSoF bqC+Dj0GkSn3HjaqNblLp40EebVwJh/4uQR/HQ9N6h2Cwj9LoLN7f0i8SikI8GatIzk6 rlsQ== X-Gm-Message-State: ALKqPwfw/VMOfWoxnAmZVq2SqdZymvrWBWHEKaXgxxVFQ+sO56IYcdm/ 0/gCWqTUkrvfENEsPuSGDb9r0w== X-Google-Smtp-Source: AB8JxZrxqRg0rbBXdtq/VP/w1YkT1KNgTmLOdxCDphyq5h+rZVRujzsI0ivkHFKEH/PdKfWLu4GWmA== X-Received: by 2002:a1c:b656:: with SMTP id g83-v6mr797859wmf.143.1526014885379; Thu, 10 May 2018 22:01:25 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id 19-v6sm788440wmv.18.2018.05.10.22.01.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 May 2018 22:01:24 -0700 (PDT) To: Joe Hildebrand , json@ietf.org References: <20180510050214.916C4B81EA7@rfc-editor.org> <4EB0B6DE-2416-4909-9EDA-975439055F33@cursive.net> From: Anders Rundgren Message-ID: Date: Fri, 11 May 2018 07:01:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <4EB0B6DE-2416-4909-9EDA-975439055F33@cursive.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (5354) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 May 2018 05:01:30 -0000 Right, if you violate the 2**53 limit all bets are off. I don't find that particularly surprising. Using Chrome: > var t = 9007199254740993 > console.log(t) 9007199254740992 In a Java-based tool of mine: setInt53(long value) { if (value < MAX_INT || value > MAX_INT) { throw new IOException("Value out of range:" + value); } Anders On 2018-05-10 21:49, Joe Hildebrand wrote: > I disagree with this pretty thoroughly. Here is some example NodeJS code to illustrate why: > > ```js > const START = Number.MAX_SAFE_INTEGER - 2 > > const buf = Buffer.alloc(8) > for (let i = 0; i < 5; i++) { > const x = START + i > buf.writeDoubleBE(x) > const y = buf.readDoubleBE() > console.log(`${x} 0x${buf.toString('hex')} ${y} ${x === y}`) > } > ``` > > And its output: > > 9007199254740989 0x433ffffffffffffd 9007199254740989 true > 9007199254740990 0x433ffffffffffffe 9007199254740990 true > 9007199254740991 0x433fffffffffffff 9007199254740991 true > 9007199254740992 0x4340000000000000 9007199254740992 true > 9007199254740992 0x4340000000000000 9007199254740992 true > > The point is that Number.MAX_SAFE_INTEGER is that last “integer" that has an unambiguous bit pattern, such that it round trips without the possibility of something else having been intended. > > >> On May 9, 2018, at 11:02 PM, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC7493, >> "The I-JSON Message Format". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5354 >> >> -------------------------------------- >> Type: Technical >> Reported by: Anders Rundgren >> >> Section: 2.2 >> >> Original Text >> ------------- >> An I-JSON sender cannot expect a receiver to treat an integer whose >> absolute value is greater than 9007199254740991 (i.e., that is >> outside the range [-(2**53)+1, (2**53)-1]) as an exact value. >> >> Corrected Text >> -------------- >> An I-JSON sender cannot expect a receiver to treat an integer whose >> absolute value is greater than 9007199254740992 (i.e., that is >> outside the range [-(2**53), (2**53)]) as an exact value. >> >> Notes >> ----- >> The limit is presumably derived from ECMAScript which says: >> >> "The value of Number.MAX_SAFE_INTEGER is the largest integer n such that n and n + 1 are both exactly representable as a Number value" >> >> However, Number.MAX_SAFE_INTEGER is 9007199254740991. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC7493 (draft-ietf-json-i-json-06) >> -------------------------------------- >> Title : The I-JSON Message Format >> Publication Date : March 2015 >> Author(s) : T. Bray, Ed. >> Category : PROPOSED STANDARD >> Source : JavaScript Object Notation >> Area : Applications >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json > From nobody Fri May 11 01:21:47 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B497112E87B for ; Fri, 11 May 2018 01:21:45 -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 xzXTVLmZX321 for ; Fri, 11 May 2018 01:21:43 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 1317812E874 for ; Fri, 11 May 2018 01:21:43 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id l1-v6so1627671wmb.2 for ; Fri, 11 May 2018 01:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=SmtiRwchdxIb1l4OBSwqJEEk33BIYlkBZwmLus48bLw=; b=ZAYaYdKib6L2gQmat8mgCQJBjyYxCRNZGmHagb8SfTkkzstCE/96Z3nslER/kQNpPY IsIihHeSpXZTcdUYY1vSFRmWLKN5rtGKWsnKnFL0azO7QFK5cOva1QSE/ar+MNStdxc6 1deEnpxSZemyn5KXe1KZKvwTy1UFZMSAemc6QSilXvXSMswL0vyerNqwjnelgBoMoZ3b RUXDLWwQbshn4/TCBrQ2krJzoVfFiNJtk0uVWUALPZXIEVrB3roXbXhdoZaToJZGXWNF KyWfsa+x6IKo2htKMIaVS5/JAqJmxSLVN8WHKmIRcSAV/oQSOBNGuevsStxKIcmJixH3 HHqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SmtiRwchdxIb1l4OBSwqJEEk33BIYlkBZwmLus48bLw=; b=af6UsDlysuFpWJLUk1cV+8Cuv8SZqFSC1hcNo8rAkyaddlSq2/UiRM+9/sbng6iMYr Ma6ThgjFm0BlX1+IoAKFMnzU2AHAX/twI8DxOMrw7kA8ZsrbnkQbswWL6aSBA6HuJDlN U3IJy+Qho/bTAiuipYaxTXl8efxBQkhB+U1nxcvrqeQhFH1RM7I0VGxRuGZUk3UPYR3p PE3mz5RvIuDLIVg2m717syH0I4kZvJsyS0aYjJAoX99ZQvnMZyhd7QF2E3ld/rhyOiif Clw0y/S5/yLPTKp8bvuyaEcDnQpc16fIjnBpPfZPQBe89IIzIb9gYS2NYx+OhCHIZl+T ZYzQ== X-Gm-Message-State: ALKqPwcmcL2/egtDTM6eWTfbjrEPJTZtqZnhAt49qXOZdWXY6c+6f62S Van1inLwIjCrh8tLOJg1yNM0lg== X-Google-Smtp-Source: AB8JxZqB6RKMN01KQwp4N636uFTYxLoNAyVi4shDfMtTbVRc3FDaDsf3zLuExdNSzFtQPitkXk2QDA== X-Received: by 2002:a1c:c1c9:: with SMTP id r192-v6mr1195966wmf.120.1526026901158; Fri, 11 May 2018 01:21:41 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id m134-v6sm615634wmg.4.2018.05.11.01.21.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 May 2018 01:21:40 -0700 (PDT) From: Anders Rundgren To: Joe Hildebrand , json@ietf.org References: <20180510050214.916C4B81EA7@rfc-editor.org> <4EB0B6DE-2416-4909-9EDA-975439055F33@cursive.net> Message-ID: Date: Fri, 11 May 2018 10:21:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (5354) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 May 2018 08:21:46 -0000 Since we presumably agree on that integers represented as JSON Numbers can (in a scheme constrained by IEEE-754 double precision), cover exactly the range -(2**53) to 2**53, the issue boils down to the ability validating that you actually are sending or receiving integers within that range. Validation is (at least on paper), only a problem on the ECMAScript side and essentially only concerns the values -9007199254740993 and 9007199254740993. In practice however, the problem is *way* bigger since almost no other JSON tools bother about integer limits at all; 64-bit integers are pretty much the de-facto standard. Feel free rejecting this errata report. Personally, I stick to "int53". Anders On 2018-05-11 07:01, Anders Rundgren wrote: > Right, if you violate the 2**53 limit all bets are off. I don't find that particularly surprising. > > Using Chrome: > > var t = 9007199254740993 > > console.log(t) > 9007199254740992 > > In a Java-based tool of mine: > setInt53(long value) { > if (value < MAX_INT || value > MAX_INT) { > throw new IOException("Value out of range:" + value); > } > > Anders > > > On 2018-05-10 21:49, Joe Hildebrand wrote: >> I disagree with this pretty thoroughly. Here is some example NodeJS code to illustrate why: >> >> ```js >> const START = Number.MAX_SAFE_INTEGER - 2 >> >> const buf = Buffer.alloc(8) >> for (let i = 0; i < 5; i++) { >> const x = START + i >> buf.writeDoubleBE(x) >> const y = buf.readDoubleBE() >> console.log(`${x} 0x${buf.toString('hex')} ${y} ${x === y}`) >> } >> ``` >> >> And its output: >> >> 9007199254740989 0x433ffffffffffffd 9007199254740989 true >> 9007199254740990 0x433ffffffffffffe 9007199254740990 true >> 9007199254740991 0x433fffffffffffff 9007199254740991 true >> 9007199254740992 0x4340000000000000 9007199254740992 true >> 9007199254740992 0x4340000000000000 9007199254740992 true >> >> The point is that Number.MAX_SAFE_INTEGER is that last “integer" that has an unambiguous bit pattern, such that it round trips without the possibility of something else having been intended. >> >> >>> On May 9, 2018, at 11:02 PM, RFC Errata System wrote: >>> >>> The following errata report has been submitted for RFC7493, >>> "The I-JSON Message Format". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata/eid5354 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Anders Rundgren >>> >>> Section: 2.2 >>> >>> Original Text >>> ------------- >>> An I-JSON sender cannot expect a receiver to treat an integer whose >>> absolute value is greater than 9007199254740991 (i.e., that is >>> outside the range [-(2**53)+1, (2**53)-1]) as an exact value. >>> >>> Corrected Text >>> -------------- >>> An I-JSON sender cannot expect a receiver to treat an integer whose >>> absolute value is greater than 9007199254740992 (i.e., that is >>> outside the range [-(2**53), (2**53)]) as an exact value. >>> >>> Notes >>> ----- >>> The limit is presumably derived from ECMAScript which says: >>> >>> "The value of Number.MAX_SAFE_INTEGER is the largest integer n such that n and n + 1 are both exactly representable as a Number value" >>> >>> However, Number.MAX_SAFE_INTEGER is 9007199254740991. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC7493 (draft-ietf-json-i-json-06) >>> -------------------------------------- >>> Title : The I-JSON Message Format >>> Publication Date : March 2015 >>> Author(s) : T. Bray, Ed. >>> Category : PROPOSED STANDARD >>> Source : JavaScript Object Notation >>> Area : Applications >>> Stream : IETF >>> Verifying Party : IESG >>> >>> _______________________________________________ >>> json mailing list >>> json@ietf.org >>> https://www.ietf.org/mailman/listinfo/json >> > From nobody Fri May 11 06:24:20 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C2C1243F6 for ; Fri, 11 May 2018 06:24:19 -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 YbUCpBMlWN41 for ; Fri, 11 May 2018 06:24:17 -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 324F01201F2 for ; Fri, 11 May 2018 06:24:17 -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 w4BDOC8V016759; Fri, 11 May 2018 15:24:12 +0200 (CEST) Received: from [192.168.217.114] (p5DC7F793.dip0.t-ipconnect.de [93.199.247.147]) (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 40j9mD4ZQlzDWtY; Fri, 11 May 2018 15:24:12 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Fri, 11 May 2018 15:24:11 +0200 Cc: Joe Hildebrand , json@ietf.org X-Mao-Original-Outgoing-Id: 547737850.3057539-c4024a45630a2ccf662a22e74c62dbdb Content-Transfer-Encoding: quoted-printable Message-Id: <595C4165-6AED-4D0B-A286-A53BC605E631@tzi.org> References: <20180510050214.916C4B81EA7@rfc-editor.org> <4EB0B6DE-2416-4909-9EDA-975439055F33@cursive.net> To: Anders Rundgren X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (5354) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 May 2018 13:24:19 -0000 On May 11, 2018, at 10:21, Anders Rundgren = wrote: >=20 > Since we presumably agree on that integers represented as JSON Numbers = can (in a scheme constrained by IEEE-754 double precision), cover = exactly the range -(2**53) to 2**53, the issue boils down to the ability = validating that you actually are sending or receiving integers within = that range. As I mentioned, you can=E2=80=99t validate that you are receiving = -2**53, with a stock, fully interoperable I-JSON decoder implementation. Both ECMAScript and I-JSON are right in taking out 2**53 out of the safe = space. (And, of course, lots more integers can be represented in binary64, e.g. = all numbers 2**53+2*n where n is an unsigned integer < 2**52. This is = just not very useful for interoperable exchange of integers via JSON; = neither for n=3D0 nor for other values of n.) > Feel free rejecting this errata report. =20 Yes, that is what should be done. > Personally, I stick to =E2=80=9Cint53". (int54, if such a thing existed, is still not I-JSON safe at MININT54 =3D = -2**53.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri May 11 11:38:56 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A008912D7E5 for ; Fri, 11 May 2018 11:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.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 QIR8jz7ATgPk for ; Fri, 11 May 2018 11:38:52 -0700 (PDT) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAD3F126E01 for ; Fri, 11 May 2018 11:38:52 -0700 (PDT) Received: by mail-ot0-x22b.google.com with SMTP id h8-v6so7317069otb.2 for ; Fri, 11 May 2018 11:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:cc:references:to:from:openpgp:autocrypt:message-id :date:user-agent:mime-version:in-reply-to; bh=TqZnBJ5ZbqnxC1wAR7PlVeXo8PnSHc6jF29siWpXKGg=; b=mWS7+pI84C2ykI5hYAnnDLD7PS1HCQsCxSnjU86aNgVTcxU25SaA7P7My3KXt+YHR+ V9LAaKH1ABqhlDwFdXlr2lywZ+WqNpkIyzIS32QMaVZ7s5r89fQbW9ses3DRbnu/6tSs c43d6B+r0R/SZOfxbj09zjjNDjYTAtHHT4UCU1DQLcVC7+lytE3sKAkP1TJo7RdUyabA aFhViaV4E7ZWJK32fALI2YoqqeQt7rwEdqFvHD/fD363lLmVFmkyuVt27C69g+EXwEgN u8Qmue1dFk61jMTXFeVgjluaQA8AiLBWNM7rJqIBhAtPN07Lwwn6kdvrk2hmKZoTViyJ jzEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:cc:references:to:from:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to; bh=TqZnBJ5ZbqnxC1wAR7PlVeXo8PnSHc6jF29siWpXKGg=; b=RBINa5G+KbKMwo/udXhgtqKpSv/69Nv+vj/Z/8/3R1y0QlNBWpkrUaNkSjavgW2YAH jRkujC5jMh4w+2ksEIAFmhX6VJOiebRsHeS/hDQC0PyysqD+5ykN8w4fKSUOV87cmIHy 16Ci9kftMCRDjkzsCp+dghGQixZe3DZyzTzRs1jBWS9obuc0BS/Ou54dvREXOctoG5+1 GFlT6cfHKJcxYNmNcbLJHweYQoXIwFWUPsYnyXBP/7mr+/cGIFyudhlllGNENjjcIkmx cmr+miZ7EjVX+BMUi3UKC/qO8Ze4TXHcMlDgYKWnlSDU+Y1oPI0Vl1xLHiQfTc4EHZS+ UhWg== X-Gm-Message-State: ALKqPweAzcZf1aq0LiFOX+zmLCQDlF0+XmCoyuMFL7iEOvQP549JL3g3 ob5pKldZVn56WVWpTZ0ogWyOHuUGGwaVrw== X-Google-Smtp-Source: AB8JxZpETBlZosXehAumcjz6GDyp3hrTk9GqrPfZi6J+cdik0/xPqa6JZ9k67k9JgRDwwlBN1Q7uWg== X-Received: by 2002:a9d:2e0f:: with SMTP id q15-v6mr4492112otb.302.1526063931656; Fri, 11 May 2018 11:38:51 -0700 (PDT) Received: from [10.6.21.160] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id r37-v6sm2196197ota.10.2018.05.11.11.38.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 May 2018 11:38:51 -0700 (PDT) Sender: Matthew Miller Cc: Carsten Bormann , Anders Rundgren , Joe Hildebrand , json@ietf.org References: <20180510050214.916C4B81EA7@rfc-editor.org> <4EB0B6DE-2416-4909-9EDA-975439055F33@cursive.net> <595C4165-6AED-4D0B-A286-A53BC605E631@tzi.org> To: RFC Errata System , Ben Campbell , Alexey Melnikov , Adam Roach From: "Matthew A. Miller" Openpgp: preference=signencrypt Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= xsBNBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAHNLk1hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGZAb3V0ZXItcGxhbmVzLm5ldD7CwIAE EwEKACoCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFCQvHJDEFAlirCeQCGQEACgkQ7PRy ThCeBbt+sAgAzUQokr+f+ArieIrv2JkiQLqiBaZX29Aph9YwG3OPLWSdESEKkFOSJT0LWbsC cAKHLrVfgl2+6iPhf4OOacTdqK7wS6vruPZC1ChdO7NZTgbVa0hP/Q/QKEoaMGNdfc1/lgxY 5kwh+bvGIF1+HyadytgCBBHxdVEhYI7G3ejKqA8iVwri1VW0Wjp8iWdjpF74swIHhid5GcAu 6VJgVNJw3P+WkTkNrkd2tx5yUfNXQuGyFhxwlpiuaOpIk3p74P6e8h/riMpkJ5mIH/ryGTH7 qxpEIuep2bLQZmGwBen8kf3MO/VbiA/NMY6OHdc93EBKr0g7n2BA5uFLdy79FqAA3M7ATQRS aAKKAQgAwP67h8GJUO6XYyWOrcJGXDJnnZEDS+q+bTQXkJMFa74rVIx0yioqY8QdpBJFGaMT 4DCNYe/3pw61ZTDDKqukSCfOh/ssdd8zSGTQZSX5lR4B4+00/LKWugP6iHHHYiETbBVb5bxc aR/LE41Wx3z2HsW3TkeZB6WVk82MTclS1zCuY3p9AeCvr424BSQL7KC38y2eQc95G+nabsVD c6oQ8oZOf1D2giBb2VgbYkSppKj8BKvBtmjCauWeEq/AkZKaDAdua8Qj0vEfgcoh8aavlPJi rqj1YNSyc3AO4R5prPGgTepcUpW8ip8xIPAFoJXfuvsZSV7uVP36gwApU4+ZnwARAQABwsB8 BBgBCgAmAhsMFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAlpvpIsFCQvLWoEACgkQ7PRyThCe BbuNHAf/cchJ7kHoIr5i+jgVRuR71AGlxlMbVolnS5tza3bi9Ie63LRdOtMUE3pDUQo25cWd cP7pzwwRBCDD2GxfIuyMCWaES0xtQdTIyNOAFFOtBtCFOrsNEk+iLAu6GBr4QzSQKW1QW4/b vcfpM2pLQn7Zd6naUioEYfTHCMmYHr7hQXaPNEQ7V/J4pLVAN8bHyVgQ9ciQN91DUs6jnueM BUW7DNvuHq0RDzA+ufYdpQAjwl4z1v+rnJ79P3HTxfFdiTTAk9MjyVQklHxS067cmLYkSOku dnCOHhDmSFwkKd9EwOBNuztpjCzmM5SgOT+U/iHH+IM/Hv6bjVCiAQ5WOihe6Q== Message-ID: <1f8fc49a-3411-1d83-e4e6-e7907fcdd741@outer-planes.net> Date: Fri, 11 May 2018 12:38:49 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <595C4165-6AED-4D0B-A286-A53BC605E631@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IV651HgFBNj6bhgHVD2Rlk4xVIbXBMiWP" Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (5354) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 May 2018 18:38:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IV651HgFBNj6bhgHVD2Rlk4xVIbXBMiWP Content-Type: multipart/mixed; boundary="Zjw0wlmaiN3jwe1oFa0qTHD0JKpzSsHBk"; protected-headers="v1" From: "Matthew A. Miller" To: RFC Errata System , Ben Campbell , Alexey Melnikov , Adam Roach Cc: Carsten Bormann , Anders Rundgren , Joe Hildebrand , json@ietf.org Message-ID: <1f8fc49a-3411-1d83-e4e6-e7907fcdd741@outer-planes.net> Subject: Re: [Json] [Technical Errata Reported] RFC7493 (5354) References: <20180510050214.916C4B81EA7@rfc-editor.org> <4EB0B6DE-2416-4909-9EDA-975439055F33@cursive.net> <595C4165-6AED-4D0B-A286-A53BC605E631@tzi.org> In-Reply-To: <595C4165-6AED-4D0B-A286-A53BC605E631@tzi.org> --Zjw0wlmaiN3jwe1oFa0qTHD0JKpzSsHBk Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable RFC Editor and AD, please reject errata 5354 of RFC 7493. Thank you to all in evaluating. - m&m Matthew A. Miller On 18/05/11 07:24, Carsten Bormann wrote: > On May 11, 2018, at 10:21, Anders Rundgren wrote: >> >> Since we presumably agree on that integers represented as JSON Numbers= can (in a scheme constrained by IEEE-754 double precision), cover exactl= y the range -(2**53) to 2**53, the issue boils down to the ability valida= ting that you actually are sending or receiving integers within that rang= e. >=20 > As I mentioned, you can=E2=80=99t validate that you are receiving -2**5= 3, with a stock, fully interoperable I-JSON decoder implementation. >=20 > Both ECMAScript and I-JSON are right in taking out 2**53 out of the saf= e space. >=20 > (And, of course, lots more integers can be represented in binary64, e.g= =2E all numbers 2**53+2*n where n is an unsigned integer < 2**52. This i= s just not very useful for interoperable exchange of integers via JSON; n= either for n=3D0 nor for other values of n.) >=20 >> Feel free rejecting this errata report. =20 >=20 > Yes, that is what should be done. >=20 >> Personally, I stick to =E2=80=9Cint53". >=20 > (int54, if such a thing existed, is still not I-JSON safe at MININT54 =3D= -2**53.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 --Zjw0wlmaiN3jwe1oFa0qTHD0JKpzSsHBk-- --IV651HgFBNj6bhgHVD2Rlk4xVIbXBMiWP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAlr14zoACgkQ7PRyThCe BbsGUAgAsXtO81cyc6NH0M2jJOa2Ltck/nwyc+vJl9vWkjZAJI8tsQxTEUKvu2cO QUORDyHb+NO1CPu5MnzSzk1UkHmsjeqDnAVQLrUm4ZiZZceWgTHo7k5RPgRy8bUF 9VWxGEs2Ilkv2xBMpcgDXcnpc+fWHHgERSxGurj4VTgd3IxjRRtbyuwOvqz4uBmj Kgd3r36YNkvHmiwXn0Jpxq+CZr9Py6aqv2I63bVEZFgAif9hjgYK3tgsxuPXdGKf i6ZbxCt4IbZWnOHyTHr3OJXkWDuHWX+/daPrUPjKb/l05LMY3OmBKoIcMBTK2Skt GksnD3Z9/KCzH3zZVwG90iEthANVKA== =9iHt -----END PGP SIGNATURE----- --IV651HgFBNj6bhgHVD2Rlk4xVIbXBMiWP-- From nobody Fri May 11 11:42:28 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CF2126E01 for ; Fri, 11 May 2018 11:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.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 fq_4oTGahfvY for ; Fri, 11 May 2018 11:42:25 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 C5A18126C2F for ; Fri, 11 May 2018 11:42:24 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id e80-v6so5529604oig.11 for ; Fri, 11 May 2018 11:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:openpgp:autocrypt:message-id :date:user-agent:mime-version:in-reply-to; bh=l7Zhv67z8T8zbJH3uRbTOWjR8RDh2OUwYbgriRkjFmg=; b=SMYRdOV9sBUsUeLsevuqx0puEWXH5ZmF5dWr4mlOWaS6GTnbIHnqyPSCTWNwt5XRjU 5DSWqgtShhLj6MqhUr48acthOKVmD1IxDERB+DRyZHoLiibLyEqlh6m92wxhDMi6l4HM zsy1NmYnTSYRtCO0/gVfIjPQ01LV3Or8dqez+kcrYqmU+Ay+qRim4FnkOsLgD6Zkz7fo ceNrplpEHKweeNZMOv/eQrrschjKYLycxVedGm0UIAMHd2OGwJWW/yOJGPAOulvmQYIr LKkv8vYafQS51hvo58NDFo8qoqzbIkCnGmRcyxpDnpIVEHZM+SRyRSiD8S/cMD7qGPaY rGDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to; bh=l7Zhv67z8T8zbJH3uRbTOWjR8RDh2OUwYbgriRkjFmg=; b=Nxs/qKtbrcjCN3AJXsws5ICcqu93aKj/tDr9Rq8K1TMYrvuLhebykewqIPMfuf6C7A 6Fp4JFAwFtcKjvyt01MjN1rhpu+wsT207BCJEKpanFAuDsJ2Ph3i+Iq0vt53s7OKSEbf HO5iLVLULqMi36W7vI5anNzbGp74ku0N/802fvJLHoy64a6PLEezquDOUBpnMkl8ZMRW dxnx3v3Na2nqhhVvYnV53rYcgPXZr5XXiMgj/8vuGPrwq5aUAONKWoY8YA5VFnCbyCdZ 6pUDuNFVZpkrCRc3o7AEEdAlWDTaMGvQhha1EuuXnX8RZPEgn9GBpZcmty8BSg6TyzAz +HVw== X-Gm-Message-State: ALKqPwdDJlfThkD1tMIYMn+XjI2o45ooHWkimfI55esCeOT5oVtVEHOG MDg+xysHCIQKs2glxshnx9Cy9js0+mXS7g== X-Google-Smtp-Source: AB8JxZqisq/RiXKrGX/iC3oWOEyoG6IpMtxVkI0DOcOkFukcr/voII+JwVrbvxrHR3dDjN3exQcx6w== X-Received: by 2002:aca:ec17:: with SMTP id k23-v6mr4118529oih.81.1526064143860; Fri, 11 May 2018 11:42:23 -0700 (PDT) Received: from [10.6.21.160] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id d7-v6sm2108690oti.12.2018.05.11.11.42.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 May 2018 11:42:23 -0700 (PDT) Sender: Matthew Miller To: RFC Errata System , tbray@textuality.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com Cc: anders.rundgren.net@gmail.com, json@ietf.org References: <20180510064619.8B438B8163A@rfc-editor.org> From: "Matthew A. Miller" Openpgp: preference=signencrypt Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= xsBNBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAHNLk1hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGZAb3V0ZXItcGxhbmVzLm5ldD7CwIAE EwEKACoCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFCQvHJDEFAlirCeQCGQEACgkQ7PRy ThCeBbt+sAgAzUQokr+f+ArieIrv2JkiQLqiBaZX29Aph9YwG3OPLWSdESEKkFOSJT0LWbsC cAKHLrVfgl2+6iPhf4OOacTdqK7wS6vruPZC1ChdO7NZTgbVa0hP/Q/QKEoaMGNdfc1/lgxY 5kwh+bvGIF1+HyadytgCBBHxdVEhYI7G3ejKqA8iVwri1VW0Wjp8iWdjpF74swIHhid5GcAu 6VJgVNJw3P+WkTkNrkd2tx5yUfNXQuGyFhxwlpiuaOpIk3p74P6e8h/riMpkJ5mIH/ryGTH7 qxpEIuep2bLQZmGwBen8kf3MO/VbiA/NMY6OHdc93EBKr0g7n2BA5uFLdy79FqAA3M7ATQRS aAKKAQgAwP67h8GJUO6XYyWOrcJGXDJnnZEDS+q+bTQXkJMFa74rVIx0yioqY8QdpBJFGaMT 4DCNYe/3pw61ZTDDKqukSCfOh/ssdd8zSGTQZSX5lR4B4+00/LKWugP6iHHHYiETbBVb5bxc aR/LE41Wx3z2HsW3TkeZB6WVk82MTclS1zCuY3p9AeCvr424BSQL7KC38y2eQc95G+nabsVD c6oQ8oZOf1D2giBb2VgbYkSppKj8BKvBtmjCauWeEq/AkZKaDAdua8Qj0vEfgcoh8aavlPJi rqj1YNSyc3AO4R5prPGgTepcUpW8ip8xIPAFoJXfuvsZSV7uVP36gwApU4+ZnwARAQABwsB8 BBgBCgAmAhsMFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAlpvpIsFCQvLWoEACgkQ7PRyThCe BbuNHAf/cchJ7kHoIr5i+jgVRuR71AGlxlMbVolnS5tza3bi9Ie63LRdOtMUE3pDUQo25cWd cP7pzwwRBCDD2GxfIuyMCWaES0xtQdTIyNOAFFOtBtCFOrsNEk+iLAu6GBr4QzSQKW1QW4/b vcfpM2pLQn7Zd6naUioEYfTHCMmYHr7hQXaPNEQ7V/J4pLVAN8bHyVgQ9ciQN91DUs6jnueM BUW7DNvuHq0RDzA+ufYdpQAjwl4z1v+rnJ79P3HTxfFdiTTAk9MjyVQklHxS067cmLYkSOku dnCOHhDmSFwkKd9EwOBNuztpjCzmM5SgOT+U/iHH+IM/Hv6bjVCiAQ5WOihe6Q== Message-ID: Date: Fri, 11 May 2018 12:42:21 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180510064619.8B438B8163A@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="H1Ow0yGRAZTKSrJyjOVoQs4VCFV9QAySE" Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC8259 (5355) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 May 2018 18:42:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H1Ow0yGRAZTKSrJyjOVoQs4VCFV9QAySE Content-Type: multipart/mixed; boundary="DVQKP7alYsCKSbTCHcwi97SSYzxlQXpwn"; protected-headers="v1" From: "Matthew A. Miller" To: RFC Errata System , tbray@textuality.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com Cc: anders.rundgren.net@gmail.com, json@ietf.org Message-ID: Subject: Re: [Technical Errata Reported] RFC8259 (5355) References: <20180510064619.8B438B8163A@rfc-editor.org> In-Reply-To: <20180510064619.8B438B8163A@rfc-editor.org> --DVQKP7alYsCKSbTCHcwi97SSYzxlQXpwn Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Similarly to errata 5354[1], I think this also ought to be rejected. - m&m Matthew A. Miller [1] Thread starting with < https://mailarchive.ietf.org/arch/msg/json/ldojFA4eUi78AyON5L8QjzG2-vU > On 18/05/10 00:46, RFC Errata System wrote: > The following errata report has been submitted for RFC8259, > "The JavaScript Object Notation (JSON) Data Interchange Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5355 >=20 > -------------------------------------- > Type: Technical > Reported by: Anders Rundgren >=20 > Section: 6 >=20 > Original Text > ------------- > Note that when such software is used, numbers that are integers and > are in the range [-(2**53)+1, (2**53)-1] are interoperable in the > sense that implementations will agree exactly on their numeric > values. >=20 > Corrected Text > -------------- > Note that when such software is used, numbers that are integers and > are in the range [-(2**53), (2**53)] are interoperable in the > sense that implementations will agree exactly on their numeric > values. >=20 > Notes > ----- > The limit is presumably derived from ECMAScript which says: >=20 > "The value of Number.MAX_SAFE_INTEGER is the largest integer n such tha= t n and n + 1 are both exactly representable as a Number value" >=20 > However, Number.MAX_SAFE_INTEGER is 9007199254740991 ((2*53)-1) making = n+1 (2**53) the largest exactly representable Number value >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8259 (draft-ietf-jsonbis-rfc7159bis-04) > -------------------------------------- > Title : The JavaScript Object Notation (JSON) Data Interc= hange Format > Publication Date : December 2017 > Author(s) : T. Bray, Ed. > Category : INTERNET STANDARD > Source : Javascript Object Notation Update > Area : Applications and Real-Time > Stream : IETF > Verifying Party : IESG >=20 --DVQKP7alYsCKSbTCHcwi97SSYzxlQXpwn-- --H1Ow0yGRAZTKSrJyjOVoQs4VCFV9QAySE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAlr15A0ACgkQ7PRyThCe BbsgOQgAtDoaDF1uHZJ2DdAPh+rm1s8/r/zkyg6VrfTbQTY56Q76l+LuFGYoJvHO H98JF/h7TpQiFiZkD85CJ23oxe1OLtqPoT0Kl9JGFd/poTJ2Xc1LhEKRCpWy+t0F kEeW556k/TMUYukB9swmRZOTGNlWDD3gOLosaj/ybFtyKalcysrkuQ2mgx62Ce3d bTjsXthpGBdcz15++e4PaJb9eLOzrpZUB3DiBXdfxva3VacmG9P6sYlxhItftHuU AHFlQXvqGG8gyXEJvLTXQcOXeRyq0DLw+g3LhITHHHHz/8hvhl7gkt/Z4Ccutl8Z efcP/zzyXTLslxVVYxev5uWB2L7/xw== =Pg5g -----END PGP SIGNATURE----- --H1Ow0yGRAZTKSrJyjOVoQs4VCFV9QAySE-- From nobody Tue May 15 22:38:44 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84105127867 for ; Tue, 15 May 2018 22:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1oEz2RezyRGe for ; Tue, 15 May 2018 22:38:39 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55DC8124234 for ; Tue, 15 May 2018 22:38:39 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id l1-v6so5082617wmb.2 for ; Tue, 15 May 2018 22:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=5N8LiThEjHsl2ItU5jYgCZ1GgWfq9t0UsC4J4w5VIRo=; b=c1tq3kymg1zMUXQbQ5Q+h8IPGlAfyC74mYDco2BRBsmhoWkTy7nvDvHY3ICBTbqTqQ huDteYnSWrGYftDlzSchkMKYV1AXqbJ3xZOFZoe+UXEn/0dvvikQqIdK6DpMzxDH/vUy k2p7SKUxLRZTPDj6rKBF1jVoDHEtrQuHYyZcrS93H41rPbdK3L21FBwY6wHaT+gDoTmD ZuCqp0ADm7rGil2Mzx3e+46iwHljUyHGuONQqPLHKA1HAHZIjCTcJ8uTQR94pXbu4BD6 983oS2SH3sYJvE53/PxhV8RTlcF5WZ+33jgWhQX/h4QA0Mm2MZhiW7fEJkadhjYsuQga tmlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=5N8LiThEjHsl2ItU5jYgCZ1GgWfq9t0UsC4J4w5VIRo=; b=e8RNd9jAnYpa3gDRmkVZiMWpSo43qRfR1oYzcKhRgivtagAwXG6FNZOQ3K6WQ8OY1u IK63ExPT0jI2jbFLmVm90cZ74/aaECJOp+eMnizuuBibDZ+lssLiuiGMEnJ/icf+dlyd YNIgW+j6TZycHj3kTYizibq02wCRltxgD1kYKntOnqSRZFq3JJONdFNmfHXfsC6AFQAN qpiBaCuIwIt5WI3S1zYmFK6s4B5wbQ4cRRkI+6e+5ywRHwOltwkwbhQOHbK5cH0+7s0T 2A/B/YRSxh97nngnjLNA0OkVvmNaNojOi4SmPEirm4sB0DN4ifNwMaGN7ALYFLQAVAs+ X7Hg== X-Gm-Message-State: ALKqPwcXDiG19uPC3ow/tc/aa3GlBdCmaDGwqpzufvvj074r1/d2afQm HQxBbXV921zyue3kP4niJjgYbQ== X-Google-Smtp-Source: AB8JxZoAzZHL9+MJHZ7qdtuv/IRuI3eqfyUETbFfxXv2UZs4NkrC1nIT21eoGhHADbgNPlBOwH5nIw== X-Received: by 2002:a1c:d546:: with SMTP id m67-v6mr541579wmg.117.1526449117175; Tue, 15 May 2018 22:38:37 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id l69-v6sm3174440wmb.30.2018.05.15.22.38.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 May 2018 22:38:36 -0700 (PDT) To: "json@ietf.org" From: Anders Rundgren Message-ID: Date: Wed, 16 May 2018 07:38:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Json] Extended I-JSON Numeric Data Types X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 16 May 2018 05:38:41 -0000 Since the dormant JSON WG has expressed no interest in numeric data types outside of the universe constrained by IEEE-754 double precision, various (entirely uncoordinated) vendor initiatives are currently in the works. Twitter's "solution" to message IDs {"id": 10765432100123456789, "id_str": "10765432100123456789", ...} pretty well illustrates the JSON number enigma  :-) Here is my personal take on this matter: https://github.com/cyberphone/I-JSON-Number-System#extended-numeric-data-types-compliant-with-i-json Cheers, Anders https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html From nobody Fri May 18 01:06:03 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BD51274D2 for ; Fri, 18 May 2018 01:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 0fvRdlc-W1FB for ; Fri, 18 May 2018 01:05:59 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B5A127275 for ; Fri, 18 May 2018 01:05:59 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id o78-v6so13493764wmg.0 for ; Fri, 18 May 2018 01:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=pBalgNULh43VPzzA+0WVawwEcWaq7MwK1PgkLneCbYM=; b=ZIJoYYlDftMvN65S//GocAPq/6OAdreYpy207nRazC3mBba8xqvR9zXpTCShPhms2l ZlnupBDxASJITnRMjMJPqSyZN5nSoCrs3yOMCnLHul0pwHIdkGYwdSIPR1biS5Vkliy7 Wa6Wmr1EwC0JsAoIFvmXqrbXnmOha0Y1srlRdHUsRJPIwDFL36OAGz6euBwkQJjrCW6x Z3GFPO9myG5Ugj2s0WgUoE8nwLT9NNdr7uvd6qWluvueV2/Xg4jfVh43+ocM18SN5H5g jzIHc9aUPSI+WXTZDF52bq7hwjClNqAqgYqn1NxgFf0yFvReOhz27YEPal5fBd5R4Mop uPHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=pBalgNULh43VPzzA+0WVawwEcWaq7MwK1PgkLneCbYM=; b=t3Tg0HxUEHZPRG3rtRs7+UOjTeSXHHH0RK8KUUCjn1i8lmRZtywqRabiOWxZw85jFM srYwUPVgtKr0fOJ1M0PxKCRxbF4SvYPp9SFUadES+v5LNE3zbwzRc2PD8DOKPRyx9NYZ gkHWx3TIjUQVeOQrvMN0S/Wc7TFWZ1j/HUkzql+xOGHWCms4ZgMzj0W1dYYiTq5Ivgeh d+nHLwjRgd+giSJN7/9aj/elNDvw/QEEizjFfZOatrTqT8oy4BtBH76MkWtbYLFucmUM WdDgZe45cMEX3nQMjkPV+XNXCkgHdgCvF5jGei7APJ01aurkhhagtyYTKIuDSlUrSa1k un6g== X-Gm-Message-State: ALKqPwfMPPSL17NUwxuaaEvs0aZLmqtkZZOA68SzfAvt7zmmRig7M2r+ XsEVnmuGsewjzKFBSYpQwhgYmQ== X-Google-Smtp-Source: AB8JxZqCa3fVYAi123SjjyNGJ3Zt9CN2WBF94+5ZvdoHSZxS73WPuCnZeQ+yZ5W4I0lfaL9RtDI3cQ== X-Received: by 2002:a1c:700d:: with SMTP id l13-v6mr3517885wmc.81.1526630757705; Fri, 18 May 2018 01:05:57 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id d54-v6sm11614267wrd.94.2018.05.18.01.05.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 01:05:56 -0700 (PDT) To: "json@ietf.org" From: Anders Rundgren Message-ID: Date: Fri, 18 May 2018 10:05:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Json] Implementation report for JSON Extended Numeric Data X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 18 May 2018 08:06:02 -0000 https://github.com/cyberphone/I-JSON-Number-System#existing-solutions Adaptive Notation was a novelty to me although RFC 7493 may indeed be interpreted as RECOMMENDING this scheme. Anders From nobody Fri May 18 22:58:44 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4570E12E8C3 for ; Fri, 18 May 2018 22:58:43 -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 YDLYuEsP9Yi3 for ; Fri, 18 May 2018 22:58:41 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719BA12DFE0 for ; Fri, 18 May 2018 22:58:41 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id w18-v6so7361528wrn.6 for ; Fri, 18 May 2018 22:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=GQtPE15uO5BDtpgIdQaCKhkI4t1r0SIsd2y+GaXKZ/4=; b=B1z7nToN+d2rs8zJ1TCMDlV3Mx5+YXbViYj9M/hbpsB2JdqYVH99XonWLqnkyGieGo 56+4V8Iwjbg5tMgEnk1PcC4RYcijtwxAd7JcLVqMHbwkWpYlJBcie7/wVxHKD8R6SEp8 GNO1B5sx+upRIty9TSyxzglZLhdLMdCGlsgEKrWdQdLBSHmE7PYR1T8BOr4Nz7QJE+OD pzgKQ4k9JS5P7G6Vlwj26tJp42w3xfnNmVtfYqIlucrSxRCbyE6Dv0HfYMlUxnQTErgt EByVTm7A0Acksq1qtrTEfYAp4/A1+pIcXmVPxYjih787cy1CoRx0baBUQdUN/jLwtuQ4 Lz8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=GQtPE15uO5BDtpgIdQaCKhkI4t1r0SIsd2y+GaXKZ/4=; b=AX6wbWlOLImbysFVJSUvAq268dz1Euly1hiIDQDYVNcxhMyML696uZMTJ1+FH95spM 9vpwaUol7INEZpAq7mj5NJDDISXjxA+v18v3Kdo01lqWLnGSggdb5hWy75p1tN2Sb1Iy yFcjFWKpcnqQYpj+gunup2qh+RuS2JJCt4bYVQSy2t4tII3vcWALAzCU1bkBANP6rgQu bITm1xL4LhzauYRFnZHWpxCGD2g93hBWEp02r+6tI9xU1pAOR+29nRmee/m+Ede3a7bK x82YUWHMOY8NL4R27/1X/QMTta49cwicJT1/Jdvdat9CA7D98mEwVVLbG2bezle1NGv5 uz6A== X-Gm-Message-State: ALKqPwcJJMwS0YAbzSt0KZ2m7hQHMG/LQ2ExMuIP3+r2Qfc7Qfq6iPdN fnMGcb6nn5Yu3a3RMJNPrmxMOw== X-Google-Smtp-Source: AB8JxZrcgazRulBsbey9N/P2iKlZnoTJsIdoD0Rb3YQbizzYvUsWAfHPNZKCy0bO3ueROEiWkSRnxg== X-Received: by 2002:adf:891a:: with SMTP id s26-v6mr9100266wrs.276.1526709519630; Fri, 18 May 2018 22:58:39 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id 137-v6sm15028821wmk.38.2018.05.18.22.58.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 22:58:38 -0700 (PDT) To: "json@ietf.org" From: Anders Rundgren Message-ID: <7eb9a9dd-4cfa-d3b0-79e0-af083e272e3a@gmail.com> Date: Sat, 19 May 2018 07:58:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Json] Adaptive Notation for JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 May 2018 05:58:43 -0000 It turned out that the Oracle/Java JSON API actually is I-JSON compatible by default through a method which I have coined Adaptive Notation: {   "BigDecimal.large": "1E+999",   "BigDecimal.small": 1,   "BigInteger.large": "240777489003222785532321",   "BigInteger.small": 1,   "Long.large": "9223372036854775807",   "Long.small": 1 } Personally I prefer schemes where you either use JSON Number or JSON String, rather than mixing these depending on the actual value. However, the most important is finding a common solution. WDYT? Anders From nobody Sat May 19 18:29:54 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113B6120721 for ; Sat, 19 May 2018 18:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=cursive.net 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 31lBf7W_qO0V for ; Sat, 19 May 2018 18:29:51 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 2008212025C for ; Sat, 19 May 2018 18:29:51 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id e78-v6so10537128iod.0 for ; Sat, 19 May 2018 18:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cursive.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jfdbn/Z9COkcO80M9EOOC9xPGXgdggLsz73UKSLSBno=; b=Tg5Z2vGUHe8xsuDU+AAPhp4QtIiJmG/j2TTeHHi+TEO5DXio82rJQJrpJLX8172mCK rHGwmu/RDRf9bSq3z8pctfyEjwgTOka2xMriEtdOVvWmZOs1/tMKKKNZF8AlMWT0RvXe dJRS0t9LuL1DuQYq63+UVXfPuvoZealU7gNOE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jfdbn/Z9COkcO80M9EOOC9xPGXgdggLsz73UKSLSBno=; b=jL13JV3Q4ABX5Qp4ODZsF2bID+MKab9tr2OPJ11x1YgDZHYVVznJK185X5iHEAcZqZ QEIZz53n/xFJmQkgvJ0+Vv3N/H/JBQT7vngcpjdJSgcEOOA5r/Fit3ZO8BUe6g+/7/1S InIM3pkUmkKdmjjjyr3PDa72ESHLDCMLByzJT55BLVeLDPEZrNspFkWXy+Tw8VLXI7XB fEtdb4QY8uQAtjXh106biRXpRkmSTZx00j1ralwAn7qY7P1MSWgG72IQIe1B+q/RiGHN +1lMvYKdJLgXwCjtsfYqgNjyTImsSQwXoVvp3786XPFZxYRf/BsAZ7VfZtFvughmNeKf /Tng== X-Gm-Message-State: ALKqPwfD5x1Gy5iPM/zrBIp1vzAjPCgdcrTLgFKg6zjfeSwkSO3wPpOh EultafIjMeXPiAsObGeGeWusuA== X-Google-Smtp-Source: AB8JxZr9xAdaWUAwloMt7uifFXosrimX+mgUPGDpL66sAjuSlm8vvLYuQyG2Ru8WbMPjKBF3sdVqqg== X-Received: by 2002:a6b:acb:: with SMTP id 72-v6mr17177253iok.24.1526779790241; Sat, 19 May 2018 18:29:50 -0700 (PDT) Received: from ?IPv6:2601:282:201:8955:f921:1d15:c163:3b55? ([2601:282:201:8955:f921:1d15:c163:3b55]) by smtp.gmail.com with ESMTPSA id l186-v6sm6704082itl.3.2018.05.19.18.29.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 May 2018 18:29:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Joe Hildebrand In-Reply-To: Date: Sat, 19 May 2018 19:29:48 -0600 Cc: "json@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3EBBBF90-5757-41C6-ACF3-359A2D30E738@cursive.net> References: To: Anders Rundgren X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Json] Implementation report for JSON Extended Numeric Data X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 May 2018 01:29:53 -0000 I think I see where you=E2=80=99re going. If you take the idea of tags = from CBOR, choose a funny separator, and add an IANA = first-come-first-serve registry, you=E2=80=99d have: [=E2=80=9Cdecimal###3.22", =E2=80=9CbigNumber###1e999=E2=80=9D, = =E2=80=9Cdate###2018-05-20T01:27:03.028Z=E2=80=9D] > On May 18, 2018, at 2:05 AM, Anders Rundgren = wrote: >=20 > https://github.com/cyberphone/I-JSON-Number-System#existing-solutions >=20 > Adaptive Notation was a novelty to me although RFC 7493 may indeed be = interpreted as RECOMMENDING this scheme. >=20 > Anders >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Sat May 19 18:42:28 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F90A12025C for ; Sat, 19 May 2018 18:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 B4Xi36eTsIsp for ; Sat, 19 May 2018 18:42:24 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8517D1200C5 for ; Sat, 19 May 2018 18:42:24 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id j4-v6so19875688wme.1 for ; Sat, 19 May 2018 18:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=s9Ppp7vPFOT17Sav9stPTGwprVIhh8LWrwMGoSbzTms=; b=Eix6Gm+T0prp9QtqjJJBouapUEaocActQsLyHU1TuoGJxn+MzeY5vhep9NwPffC9Jx QDOXkFytCb++Kqw+lqH9/RTPf+4G1WMeEJYx+TSisMknDa0YEAfT2Ts8mse59VdxG9k0 hbrNNL4Q8IJ0na5BkB7NVJEIrTZRerXNgBlbLsR4UOYfz5DDwlmhZh6/r4umTzz0kSsb /qwehWM2J0et1+haswQP+HpZNsKY6ge+DhkYkl8SLhdqqCewEDAEN5NPXIHC7SRsivpr bnedzfMtHhh/QqsrDq/BEHzJriYBMZt/Y6vIRcGhNBA4QbTeCo5Lif3jhKSqhHE9Vdu/ 5ovA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=s9Ppp7vPFOT17Sav9stPTGwprVIhh8LWrwMGoSbzTms=; b=nly/NLE7cEb/SuNDWQnEo0ITCDBxdIAAJKciLJvxDKgqiJdIalM0o+SAc6FJRr+3JD 59lUSyLCYAtJ8nS0olKmI6SK/HSD88JK1Pd3/skV8YPQPpCAWxz7AQGIUlaVIKPXuW77 +Xlv+k+oZSYevtY59OnlCFIQSIsHipfJc4Utn+JXWdRCeKaTpvQ9DxfeQaqkAv1hzQhD FVazVo/+Q73xf6FScjBZxwyOadP1oZPHK5WLs+3ZmeQmY/1eLry9cFgL347UbEftPUZs 7nOt2+pvFdEtGS7s2FZGo/PNxy+1J9OwJs/op8Mm/e+KFy8NW78nDerb3FStdVOJidnb Cong== X-Gm-Message-State: ALKqPwfSQ/Y93APGtEIw+sJ5F3o4hnqM2+yrtRZo/Buw24aX0fiI189f mBPuSSFvWePxc8TdfZh6cDFgTw== X-Google-Smtp-Source: AB8JxZpv8UVCWRjhZevUwWYfpZ7OxCfV2j9qImrwXfB9SzA1Pxyoob8uj/fLUqvP3b30AT/UhrXBSA== X-Received: by 2002:a1c:1442:: with SMTP id 63-v6mr7349102wmu.100.1526780542598; Sat, 19 May 2018 18:42:22 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id x70-v6sm14406426wma.9.2018.05.19.18.42.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 May 2018 18:42:21 -0700 (PDT) To: Joe Hildebrand Cc: "json@ietf.org" References: <3EBBBF90-5757-41C6-ACF3-359A2D30E738@cursive.net> From: Anders Rundgren Message-ID: <4b28cf86-a32a-c7a6-60f0-d68c1676381e@gmail.com> Date: Sun, 20 May 2018 03:42:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <3EBBBF90-5757-41C6-ACF3-359A2D30E738@cursive.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] Implementation report for JSON Extended Numeric Data X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 May 2018 01:42:27 -0000 On 2018-05-20 03:29, Joe Hildebrand wrote: > I think I see where you’re going. If you take the idea of > tags from CBOR, choose a funny separator, and add an IANA > first-come-first-serve registry, you’d have: > > [“decimal###3.22", “bigNumber###1e999”, “date###2018-05-20T01:27:03.028Z”] The intention was only to describe the current situation regarding representation of numbers in JSON that does not fit into IEEE-754 double precision. This posting is maybe clearer: https://www.ietf.org/mail-archive/web/json/current/msg04318.html I'm not advocating some kind additional type system; name mapping have proved to be fully sufficient in practice. Anders > > >> On May 18, 2018, at 2:05 AM, Anders Rundgren wrote: >> >> https://github.com/cyberphone/I-JSON-Number-System#existing-solutions >> >> Adaptive Notation was a novelty to me although RFC 7493 may indeed be interpreted as RECOMMENDING this scheme. >> >> Anders >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json > From nobody Thu May 24 06:53:29 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FA0126D74 for ; Thu, 24 May 2018 06:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 VUY_A-JQn0RS for ; Thu, 24 May 2018 06:53:21 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (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 408F4127AD4 for ; Thu, 24 May 2018 06:53:17 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id 77-v6so2010771otd.4 for ; Thu, 24 May 2018 06:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=KVmvD+MifCN7WNV2vBSZeh4D6bpuVndH71+bMyGfxBs=; b=fIsnQ787XdBTpAIxkaV+dzJ2DmbSVmMYFwsBEhPCaUALh4uGupL5CmKaLbUPkcdbVP D/sFpXMyTLNtLzyOmevVBJjXD3mtLYOjr0jM2gTEgW5f6c/zmSofvZhcqZlyoUHdcOR+ cIIt+BLZ2nK1ZJ7w0iKsk9KRWGOpRCs69k4UkyGcy/2neU99KhEnqZK+rwN9cAwCs9dl okgK7SnCbsfRGg74soYQzXeXwT6m/7pfGFrzpJuoQDKf2+bCd1fyrek9PxnDAfrHT7Qa uMHlYH0+dCGARQPgGWjg1bU7Sk1X9ShqmXp3Ue/Up2vcLBM9MrDj0n1eXeT2eHgl3t0c O7FA== 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:from:date:message-id:subject :to; bh=KVmvD+MifCN7WNV2vBSZeh4D6bpuVndH71+bMyGfxBs=; b=ZD8uWXDb3XIxoGkGrw2ZCpEz/nzD19Msl6BIcgDrfgiq58K0iaxY1IjK4/xoTauAiJ OLW0sxphKp3fAeMwlDgjnpS4s5e49cUhDvD6hGmFQksS417SE0JAdahkq4xFAVQXxQcT IiZiIAv7V3Xya3eU587kpCFImsa4KfG+6cMLraYPsiFeUYQxIIrv5z0uNcmByBFtPvm4 r3ngd23qlUjVyR1mRr0e8sS1sqZQCeQPrSkz+np5HVnsufC10wnOjIS21r+RarMKY0Cl l33DThYmzP2nMYi92aogsHXrPyeYeOC8b8p62RTjEBkqAJuEC5Yrsk72KOFjqoKgb9f8 MdLA== X-Gm-Message-State: ALKqPweZFVP0IIqRu6jHs3Q+CoTHfd226jpsvpYXkZay5x8GTGCWz0Ev LQl/ZsKAnvhzXcUCws6Cb4PUpEz3Mr8H2CgpamdPvw== X-Google-Smtp-Source: AB8JxZqU89ZyCVJ4QozxEe6nOnqfQkUHbqTSAgN1oS6kvLHDEZTjJrYQyv6ivsLD0Hxuw5Gu+RWm6TIkYCbr4QD246Q= X-Received: by 2002:a9d:30a1:: with SMTP id s33-v6mr4897752otc.360.1527169996312; Thu, 24 May 2018 06:53:16 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Thu, 24 May 2018 06:53:15 -0700 (PDT) From: Phillip Hallam-Baker Date: Thu, 24 May 2018 09:53:15 -0400 X-Google-Sender-Auth: VdbOoA8nyyWqEekGySIWyKw3Krk Message-ID: To: JSON WG Content-Type: multipart/alternative; boundary="000000000000245649056cf3f961" Archived-At: Subject: [Json] Bridging the gap between ASN.1 and JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 May 2018 13:53:23 -0000 --000000000000245649056cf3f961 Content-Type: text/plain; charset="UTF-8" JSON is a really good encoding for many applications. For some it is not optional and neither are the existing alternatives on offer. * Base 64 encoding binary data increases data size by 33% per pass. * Encoding of floating point binary in decimal notation entails a loss of precision. * Tags are large * Tags are required * Cannot direct the order in which elements are presented. What I want is an encoding that preserves the JSON data model as closely as possible while providing support for these features. I do not want to switch from JSON to ASN.1/CBOR/XML because they require me to change my data model. I have addressed all but the last two in the following: http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html It recently occurred to me that the JSON approach could be extended to allow tags to be omitted when the sender and receiver share a schema definition. Consider the following template: { "A": "One", B: 2, C: { D: 4 } } The template provides an implicit (partial) specification of the data types for the object fields. A is a string, B a number and so on. Since it is JSON, the order of the tags does not matter which means that we are required to provide them to allow the object to be decoded: { C: { D: 4 } , "A": "One", B: 2 } { "A": "One", C: { D: 4 }, B: 2,} Now let us imagine that the first template is known to both sides and that if a tag is omitted, it is implied. We can now encode the above as follows. { "One", 2, { D: 4 } } Or if we wanted (thanks Steve Prior) we could distinguish this production by use of different braces: < "One", 2, < 4 > > For large data sets, this approach leads to a significant decrease in size, a decrease that is not achieved by compression unless the underlying data is also repetitive. This approach is already used in many modern computing languages. C# classes used to be a mess with often a dozen constructors for essentially the same purposes. These days the constructors and methods can look like this: public static byte[] Enhance ( byte[] MasterSecret, byte[] Plaintext, byte[] Salt = null, CryptoProviderEncryption ProviderEncrypt = null ) { Default parameters are optional and will take the specified default value. Tags are only required when a parameter is omitted entirely. --000000000000245649056cf3f961 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
JSO= N is a really good encoding for many applications. For some it is not optio= nal and neither are the existing alternatives on offer.

* Base 64 encoding binary data increases dat= a size by 33% per pass.

*= Encoding of floating point binary in decimal notation entails a loss of pr= ecision.

* Tags are large=

* Tags are required

* Cannot direct the order in = which elements are presented.

What I want is an encoding that preserves the JSON data model as close= ly as possible while providing support for these features. I do not want to= switch from JSON to ASN.1/CBOR/XML because they require me to change my da= ta model.

<= /div>

I have addressed all but = the last two in the following:

http://mathmesh.com/Do= cuments/draft-hallambaker-jsonbcd.html


It recently occurred to me that the JSON approach could be extende= d to allow tags to be omitted when the sender and receiver share a schema d= efinition.

Consider the following template:

{ "A": "One", B= : 2, C: { D: 4 } }

The template provides an implicit (partial) specificatio= n of the data types for the object fields. A is a string, B a number and so= on. Since it is JSON, the order of the tags does not matter which means th= at we are required to provide them to allow the object to be decoded:
=

{=20 =C2=A0C: { D: 4 }=C2=A0, &quo= t;A": "One", B: 2 }
{ "A": "One", C: { D: 4 }, B: 2,}

Now let us imagine that the first template is known to both sides and th= at if a tag is omitted, it is implied. We can now encode the above as follo= ws.

{ "One", 2, { D: 4 } }

Or if we wanted (thanks Steve Prior) we could distinguish this productio= n by use of different braces:=C2=A0

<= /div>
< "One&= quot;, 2, < 4 > >

For large data sets, this approach leads to a significa= nt decrease in size, a decrease that is not achieved by compression unless = the underlying data is also repetitive.

This approach is already used in many modern c= omputing languages. C# classes used to be a mess with often a dozen constru= ctors for essentially the same purposes. These days the constructors and me= thods can look like this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 pub= lic static byte[] Enhance (
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 byte[] MasterSecre= t,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 byte[] Plaintext,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 byte[] Salt =3D null,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CryptoProviderEncry= ption ProviderEncrypt =3D null
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ) {

Default paramete= rs are optional and will take the specified default value. Tags are only re= quired when a parameter is omitted entirely.


--000000000000245649056cf3f961-- From nobody Thu May 24 09:24:45 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB9812DB70 for ; Thu, 24 May 2018 09:24:44 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 D58fHEYg855q for ; Thu, 24 May 2018 09:24:43 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA96127419 for ; Thu, 24 May 2018 09:24:43 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 3E04358000936; Thu, 24 May 2018 09:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=s9YCIGcO2lFwxD 5JGJXUVmVPJqA=; b=QISW30BoYEwk5LLqdxrVmQ493H2ARjASf+dRVBEbC1tGyx a2VS8pgkDDdzysyJiO7o1I6QJGW7maw6qndBd2bOZCKJppFdas93n0gG7d69x5LD XegB49C6IS9IeSiOKe78M/OR55ZOLbmok2qXiWKHkS2SaUXMc0RUIe6jbFhLU= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id DF07058000934; Thu, 24 May 2018 09:24:41 -0700 (PDT) Date: Thu, 24 May 2018 11:24:40 -0500 From: Nico Williams To: Phillip Hallam-Baker Cc: JSON WG Message-ID: <20180524162438.GA14446@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Json] Bridging the gap between ASN.1 and JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 May 2018 16:24:45 -0000 On Thu, May 24, 2018 at 09:53:15AM -0400, Phillip Hallam-Baker wrote: > JSON is a really good encoding for many applications. For some it is not > optional and neither are the existing alternatives on offer. Sounds a lot like you want something like FastInfoSet, which is basically PER (Packed Encoding Rules) applied to XML. > * Base 64 encoding binary data increases data size by 33% per pass. Yep. > * Encoding of floating point binary in decimal notation entails a loss of > precision. Yep. > * Tags are large > > * Tags are required You can always use arrays... Then missing "fields" only take up four or five bytes ('null', ',null', or 'null,'). See below. > * Cannot direct the order in which elements are presented. I'd add: * Requires escaping strings (ugh) Escaping/unescaping sucks. > What I want is an encoding that preserves the JSON data model as closely as > possible while providing support for these features. I do not want to > switch from JSON to ASN.1/CBOR/XML because they require me to change my > data model. I thought JSON round-trips through CBOR. What's wrong with that? > It recently occurred to me that the JSON approach could be extended to > allow tags to be omitted when the sender and receiver share a schema > definition. This is the *same* idea as in ASN.1's PER and OER, which use no tags, and minimize the use of lengths, so there's no TLV in PER/OER. (There are some lengths in PER/OER, especially for fields added after extensibility markers.) The encoding of an object here is a lot like an array of field value encodings (see above comment about arrays). There's nothing new in this field, it seems :) > For large data sets, this approach leads to a significant decrease in size, > a decrease that is not achieved by compression unless the underlying data > is also repetitive. Yes. That's why PER/OER exists. It's also why FastInfoSet exists. Now, I suspect that for JSON starting from scratch -- but using PER/OER as inspiration -- will be better than the FastInfoSet approach. Cheers, Nico -- From nobody Thu May 24 09:58:23 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96607127241 for ; Thu, 24 May 2018 09:58:07 -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 WWsak9lQxJL7 for ; Thu, 24 May 2018 09:58:04 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9613812DA2C for ; Thu, 24 May 2018 09:58:03 -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 w4OGvv6H027956; Thu, 24 May 2018 18:57:57 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (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 40sFts2gfZzDXqq; Thu, 24 May 2018 18:57:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <20180524162438.GA14446@localhost> Date: Thu, 24 May 2018 18:57:56 +0200 Cc: JSON WG X-Mao-Original-Outgoing-Id: 548873874.973386-f2358e881ab27cd59df885e67010ff27 Content-Transfer-Encoding: quoted-printable Message-Id: <8C791109-6A20-4DE0-A1C8-9D5344B5C567@tzi.org> References: <20180524162438.GA14446@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Json] Bridging the gap between ASN.1 and JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 May 2018 16:58:08 -0000 >=20 >> * Tags are large >>=20 >> * Tags are required (I think this is about what is called =E2=80=9Cnames=E2=80=9D in RFC = 8259.) >=20 > You can always use arrays... Then missing "fields" only take up four = or > five bytes ('null', ',null', or 'null,'). See below. >=20 >> * Cannot direct the order in which elements are presented. >=20 > I'd add: >=20 > * Requires escaping strings (ugh) >=20 > Escaping/unescaping sucks. Yep. >=20 >> What I want is an encoding that preserves the JSON data model as = closely as >> possible while providing support for these features. I do not want to >> switch from JSON to ASN.1/CBOR/XML because they require me to change = my >> data model. >=20 > I thought JSON round-trips through CBOR. What=E2=80=99s wrong with = that? Absolutely nothing. That is the approach that, e.g., OCF is using. While they sometimes seem to wish they had all of CBOR available to = them, their tools tie them to the JSON subset, and CBOR is just fine = with that (no I-JSON jitters, either). (And they can always liberate themselves once the tools catch up.) >=20 >> It recently occurred to me that the JSON approach could be extended = to >> allow tags to be omitted when the sender and receiver share a schema >> definition. >=20 > This is the *same* idea as in ASN.1's PER and OER, which use no tags, > and minimize the use of lengths, so there=E2=80=99s no TLV in PER/OER. >=20 > (There are some lengths in PER/OER, especially for fields added after > extensibility markers.) Exactly: the evolving parts of protocols don=E2=80=99t get to use this = feature. So after a while of living with a protocol, the utility of coding = optimizations that only know about the ancient base spec diminishes. >=20 > The encoding of an object here is a lot like an array of field value > encodings (see above comment about arrays). Well, you can deserialize (decode) CBOR/JSON arrays without a schema, = which you can=E2=80=99t with PER. (You may not know what the array elements *mean*, but you don=E2=80=99t = know that with just a member name, either.) XML(*) and JSON got this one right: The deserializer is = schema-independent. I don=E2=80=99t think we want to regress behind that for most = applications =E2=80=94 it turns out that plain data compression tends to = work much better than what you can cook up in complex schema-dependent = encoding rules. Gr=C3=BC=C3=9Fe, Carsten (*) The original, character-based XML =E2=80=94 binary XML a.k.a. EXI = has a schema-dependent mode that is reminiscent of PER in this aspect. From nobody Thu May 24 10:58:26 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D5712E86A for ; Thu, 24 May 2018 10:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.net 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 qUPjt5AXP_KT for ; Thu, 24 May 2018 10:58:23 -0700 (PDT) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 0AB9C1274D2 for ; Thu, 24 May 2018 10:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=knjPoRawaGhfvllviLrVzaIYvaZj0+84FM1x+jJ4yhQ=; b=xU74ZhcSLpfjVon4msIW+5/us/ aj/c28fMRuqY0iMjQGmTZHKlRIXBnDkDpuK8FG0QORE6HtQoKDJ7mDiIJSurCun85bsPGk4IbkPN4 Nj6eKW/5gyTRJtfYfBixZILzpspmxHyZ9+yy9CMKLBeNyjEcSgckiBw6rZsIqjQRDrJ9AvHiSZZK/ 1Mu7PVLY16y507RFQxiIYHGa6TAfCLn+2j37fW08elWtKMhJLx82wk2xyTrEJt2kIzriuZMWGgzs+ 0mxxTpWpUOdk4llx4To4uUnuu1wXnAB84AOGtr0kxtwv+kBjmxMYuGi+WDpJIXSwsUwkWV0AEz3vS KF+O3itA==; Received: from [109.130.153.64] (port=54324 helo=dretbook.lan) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1fLuVJ-0005sI-Kk; Thu, 24 May 2018 13:58:21 -0400 To: Phillip Hallam-Baker , JSON WG References: From: Erik Wilde Message-ID: <3e0e4811-b2be-2239-ce94-ee8b25c92b99@dret.net> Date: Thu, 24 May 2018 19:58:15 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Json] Bridging the gap between ASN.1 and JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 May 2018 17:58:25 -0000 maybe have a brief look at http://bsonspec.org/ ? cheers, dret. On 2018-05-24 15:53, Phillip Hallam-Baker wrote: > JSON is a really good encoding for many applications. For some it is not > optional and neither are the existing alternatives on offer. > > * Base 64 encoding binary data increases data size by 33% per pass. > > * Encoding of floating point binary in decimal notation entails a loss > of precision. > > * Tags are large > > * Tags are required > > * Cannot direct the order in which elements are presented. > > What I want is an encoding that preserves the JSON data model as closely > as possible while providing support for these features. I do not want to > switch from JSON to ASN.1/CBOR/XML because they require me to change my > data model. > > > I have addressed all but the last two in the following: > > http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html > > > It recently occurred to me that the JSON approach could be extended to > allow tags to be omitted when the sender and receiver share a schema > definition. > > Consider the following template: > > { "A": "One", B: 2, C: { D: 4 } } > > The template provides an implicit (partial) specification of the data > types for the object fields. A is a string, B a number and so on. Since > it is JSON, the order of the tags does not matter which means that we > are required to provide them to allow the object to be decoded: > > { C: { D: 4 } , "A": "One", B: 2 } > { "A": "One", C: { D: 4 }, B: 2,} > > Now let us imagine that the first template is known to both sides and > that if a tag is omitted, it is implied. We can now encode the above as > follows. > > { "One", 2, { D: 4 } } > > Or if we wanted (thanks Steve Prior) we could distinguish this > production by use of different braces: > > < "One", 2, < 4 > > > > For large data sets, this approach leads to a significant decrease in > size, a decrease that is not achieved by compression unless the > underlying data is also repetitive. > > This approach is already used in many modern computing languages. C# > classes used to be a mess with often a dozen constructors for > essentially the same purposes. These days the constructors and methods > can look like this: > >         public static byte[] Enhance ( >                     byte[] MasterSecret, >                     byte[] Plaintext, >                     byte[] Salt = null, >                     CryptoProviderEncryption ProviderEncrypt = null >                     ) { > > Default parameters are optional and will take the specified default > value. Tags are only required when a parameter is omitted entirely. > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Thu May 24 11:24:56 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC1212E872 for ; Thu, 24 May 2018 11:24:55 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 urPa4slpQPl5 for ; Thu, 24 May 2018 11:24:53 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB75E127867 for ; Thu, 24 May 2018 11:24:53 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 6139358000938; Thu, 24 May 2018 11:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=EsgB5BBSpi+Bp3/3P4ICEFbchSY=; b=FVFO9hDTBg1 80CQtPsWH2jGSMwuYpMW4E+qGTjTPymwxoRlBnUXhR72dVWjjjSdHFk47F0FOCo6 bSv8ST86NurM8u4GxrjAqXfXuqMim076ptq1yV6GV1x93havVHwrKBMQkEYYeKfM b7hSemkYW3JvZ7Yh3cumkLue8CDs6JbU= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 1004F58000936; Thu, 24 May 2018 11:24:50 -0700 (PDT) Date: Thu, 24 May 2018 13:24:49 -0500 From: Nico Williams To: Carsten Bormann Cc: JSON WG Message-ID: <20180524182448.GB14446@localhost> References: <20180524162438.GA14446@localhost> <8C791109-6A20-4DE0-A1C8-9D5344B5C567@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8C791109-6A20-4DE0-A1C8-9D5344B5C567@tzi.org> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] Bridging the gap between ASN.1 and JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 May 2018 18:24:56 -0000 On Thu, May 24, 2018 at 06:57:56PM +0200, Carsten Bormann wrote: > > I thought JSON round-trips through CBOR. What=E2=80=99s wrong with t= hat? >=20 > Absolutely nothing. I thought so. Thanks. > >> It recently occurred to me that the JSON approach could be extended > >> to allow tags to be omitted when the sender and receiver share a > >> schema definition. > >=20 > > This is the *same* idea as in ASN.1's PER and OER, which use no > > tags, and minimize the use of lengths, so there=E2=80=99s no TLV in P= ER/OER. > >=20 > > (There are some lengths in PER/OER, especially for fields added > > after extensibility markers.) >=20 > Exactly: the evolving parts of protocols don=E2=80=99t get to use this > feature. So after a while of living with a protocol, the utility of > coding optimizations that only know about the ancient base spec > diminishes. Eh? You don't end up with TLV all the way down for extensions. E.g., if you add a field of some SEQUENCE type to another, the encoding of the new field will not be BER/DER/CER or in any way TLV-ish. The length of the new value will be included in the containing SEQUENCE, but that's it. So you still get the benfit of PER/OER. Also, you can always use IOS or OCTET STRINGs to embed extensions without having to resort to extensibility markers. The net effect is similar: each extension will have to include a TL, but not the inside of the extension. > > The encoding of an object here is a lot like an array of field value > > encodings (see above comment about arrays). >=20 > Well, you can deserialize (decode) CBOR/JSON arrays without a schema, > which you can=E2=80=99t with PER. (You may not know what the array ele= ments > *mean*, but you don=E2=80=99t know that with just a member name, either= .) Well, sure, but that's not a win. The whole point is that you have a schema because you kinda have to have a schema, so just use the schema. Yes, asn1dump-type programs can be useful without a schema for data encoded in BER/DER/CER, but so what, you almost always want to dump data of a known type (schema). > XML(*) and JSON got this one right: The deserializer is > schema-independent. I don=E2=80=99t think we want to regress behind th= at for This is good for text-based encodings because half the value of such encodings is that humans can read them. > most applications =E2=80=94 it turns out that plain data compression te= nds to > work much better than what you can cook up in complex schema-dependent > encoding rules. Well, if you've got lots of base64-encoded binary data in JSON, does it still compress as well as just using a PER-like encoding? Text-based encodings tend to end up getting used in contexts where the ability to read them by naked eye is not that useful (e.g., cryptographic protocols), and then all the associated pain (verbosity, escaping, ...) becomes a net negative. This is not the first time this has happened. XML has FastInfoSet precisely because of this. I'm sure XML/FastInfoSet was not the first instance either, though I don't know of any others -- I'm sure just because it seems like everything in this space is a reinvention of something else. Plus =C3=A7a change... I don't think Phillip is barking up the wrong tree, but using CBOR seems like the right answer -- just stick to a subset that is semantically compatible with JSON so your JSON round-trips. If need be, extend your CBOR tools so they know when to base64-decode binary data from input JSON and when to base64-encode it for output. Nico --=20 From nobody Thu May 24 12:56:21 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE28212EB30 for ; Thu, 24 May 2018 12:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 SC44AnknglXr for ; Thu, 24 May 2018 12:56:07 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003: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 E36C312EB2F for ; Thu, 24 May 2018 12:56:06 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id y15-v6so2566288oia.13 for ; Thu, 24 May 2018 12:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yhVU9DCDjNYBCdSBE52d3rrApMNGy/E8Rxv9BzeBgjQ=; b=nCr9UZKjZXPig0hDnmqEccoN5ZguPj6LJDGhUE+45+hL0l/YNzqwJBz+Y09c2qkfdn +h/h8vQyM/cZVMjz23oiJqhFWCZG6Syb/AAT2e6vR3i+5kBkswccLlbsti8R7biqV+70 yTgg6yYoVyhXpuSE/ozpB2Y+0EV5I5GRR+d5NQpAkU0a0OifiKKqUieKa/utnzAihG3p O7tQnDcGHxlcb15wRIArbLs9yZ3gmmeh8jVGrIxM4N1YEb2kgVuCB3mB1Wmb01aXNtYr Q9OCtUMGRBRLXhvZxAZAqCHF0jgTQm4NImkKmjZayH9nTstmnjS4Ibg/orYCq/fzEb2z 7HBA== 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=yhVU9DCDjNYBCdSBE52d3rrApMNGy/E8Rxv9BzeBgjQ=; b=ECQo2gM71u3j50AC3UfZr9AQ+dpNclMzDBmN3beCJlEAjoJ/jQr1aL8VoHpeVuYzkf 1IbXdQ+R+qfMc8wuFLQDl9cSLUZSkU7PuzKhp9pgesVxOpPteebxgQvymlSmMEGiT29Q 2y/8j4cAwtNILhX6ApKLkR8UCSJF+t0JdZDvdy7wwhvHJzKXqGlSd3mEzXqluxwLAg+y FSDp1KK+vBA6pLlBhP2Rd7rYQ3h2jc+OEQmEiJ7yk1kHYjlt/VveGRY0oA5GjSU77gJL aEEnpoRuUrG2rrxY2owWzBsI2xRM8o8v15u66i0gjlLSmqz19BAx314S7dbEzp5TM3q4 L/bg== X-Gm-Message-State: ALKqPwdwKm8NOM32cimrBHnQbz9yRovfUNM7NjmzVgl9IZKXRYey1MkI cUe15pE+P32cyjQHZMyV8uOuoq7FTt4Q6BllzWsa9Q== X-Google-Smtp-Source: AB8JxZrKy8lxjAaXsDiJIsA3Lh5sGH/4UwmUpOby5L0BKTuakKl0BZzJQ1imo7CfEi4b23szELjABmJ2tde3Gzls7iw= X-Received: by 2002:aca:3b0b:: with SMTP id i11-v6mr4560759oia.271.1527191766126; Thu, 24 May 2018 12:56:06 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Thu, 24 May 2018 12:56:05 -0700 (PDT) In-Reply-To: <3e0e4811-b2be-2239-ce94-ee8b25c92b99@dret.net> References: <3e0e4811-b2be-2239-ce94-ee8b25c92b99@dret.net> From: Phillip Hallam-Baker Date: Thu, 24 May 2018 15:56:05 -0400 X-Google-Sender-Auth: HWRSEU1xSEiYG_qGB8pWmSkNzZg Message-ID: To: Erik Wilde Cc: JSON WG Content-Type: multipart/alternative; boundary="000000000000b956de056cf90a61" Archived-At: Subject: Re: [Json] Bridging the gap between ASN.1 and JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 May 2018 19:56:17 -0000 --000000000000b956de056cf90a61 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 24, 2018 at 1:58 PM, Erik Wilde wrote: > maybe have a brief look at http://bsonspec.org/ ? cheers, dret. =E2=80=8BYes, I have seen it. As with CBOR, my objection is that I do not w= ant a new encoding, I want an =E2=80=8Bencoding that has JSON as a subset. That a= llows me to have one decoder that is capable of decoding any message regardless of whether it is in basic JSON or an extension. That in turn greatly simplifies content negotiation because we are only negotiating the version of the encoding system, not the type. If a receiver says it is capable of accepting JSON, JSON-B and JSON-C, the sender can send any one of those encodings without having to specify which one because there is only a JSON-C decoder. I am also unhappy with binary encodings that extend the JSON data model. Not only is every valid JSON sequence a valid JSON-B sequence (so round tripping is supported trivially), it is possible to round trip JSON-B to JSON and back without any changes other than the inevitable loss of precision on floating point numbers. =E2=80=8B On Thu, May 24, 2018 at 12:57 PM, Carsten Bormann wrote: > =E2=80=8B > >> allow tags to be omitted when the sender and receiver share a schema > >> definition. > > > =E2=80=8B=E2=80=8B > > and minimize the use of lengths, so there=E2=80=99s no TLV in PER/OER. > > > > (There are some lengths in PER/OER, especially for fields added after > > extensibility markers.) > Exactly: the evolving parts of protocols don=E2=80=99t get to use this fe= ature. > So after a while of living with a protocol, the utility of coding > optimizations that only know about the ancient base spec diminishes. > This is the *same* idea as in ASN.1's PER and OER, which use no tags, =E2=80=8BNot quite. ASN.1 is a mess because there is a half-baked version o= f the same idea in BER which means that there is an excruciating version in DER. We agree that it should be possible to decode data without a separate schema. But if we are talking about really repetitive data such as log files, =E2=80=8Bhaving to specify every tag every time is a real drag. W3C-Log file format has something of this idea, the first line of the log specifies which identifiers are being logged. We could adopt the same sort of thing to add implicit tagging to JSON without moving away from text based encoding. < "a", "b", "c" : < "d", "e"> > { 1, 2, { 3, 4}} { 5, 6, { 7, 8}, "f": 9} =E2=80=8BCan be expanded to:=E2=80=8B { "a" :1, "b":2, "c":{ "d":3, "e":4}} { "a" :5, "b":6, "c":{ "d":7, "e":8} , "f": 9 } =E2=80=8B =E2=80=8B=E2=80=8BHaving been playing about with the idea of encrypting log= files for GDPR purposes, I am convinced that even an encrypted log needs to be essentially a plaintext construct underneath. --000000000000b956de056cf90a61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On = Thu, May 24, 2018 at 1:58 PM, Erik Wilde <erik.wilde@dret.net> wrote:
=
maybe have a brief look at http://bsonspec.org/ ? cheers, dret.


I= am also unhappy with binary encodings that extend the JSON data model. Not= only is every valid JSON sequence a valid JSON-B sequence (so round trippi= ng is supported trivially), it is possible to round trip JSON-B to JSON and= back without any changes other than the inevitable loss of precision on fl= oating point numbers.

=E2=80=8B
On Thu, May 24, 2018 at 12:57 PM, Carsten Bormann=C2=A0<cabo@tzi.org>=C2=A0wrote:
=E2=80=8B
>> allow tags to be omitted when the sender and receiv= er share a schema
>> definition.>=C2=A0
=E2=80=8B=E2=80=8B
<= span class=3D"gmail-" style=3D"color:rgb(34,34,34);font-family:arial,sans-s= erif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-v= ariant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;t= ext-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;back= ground-color:rgb(255,255,255);text-decoration-style:initial;text-decoration= -color:initial">> and minimize the use of lengths, so there=E2=80=99s no= TLV in PER/OER.
>=C2=A0<= br>> (There are some lengths in PER/OER, especially for= fields added after
> extensibility markers.)=
Exactly: the e= volving parts of protocols don=E2=80=99t get to use this feature.So after a while of living with a protocol, the = utility of coding optimizations that only know about the ancient base spec = diminishes.
> This is the *same* idea as in ASN.1's PER and OER, wh= ich use no tags,

=E2=80=8B= Not quite. ASN.1 is a mess because there is a half-baked version of the sam= e idea in BER which means that there is an excruciating version in DER.=C2= =A0

<= div class=3D"gmail_default" style=3D"font-size:small">We agree that it shou= ld be possible to decode data without a separate schema. But if we are talk= ing about really repetitive data such as log files, =E2=80=8Bhaving to spec= ify every tag every time is a real drag.

W3C-Log file format has something of this idea, the first l= ine of the log specifies which identifiers are being logged. We could adopt= the same sort of thing to add implicit tagging to JSON without moving away= from text based encoding.

< "a", "b", "c" : < "d", &q= uot;e"> >
{ 1, 2, { 3, 4}}
{ 5, 6, { 7, 8}, "f": 9}

=E2=80=8BCan be expanded to:=E2=80=8B

{=20 "a"=C2=A0:1, "b":2, &q= uot;c":{ "d":3, "e":4}}
{=C2=A0"a"=C2=A0:5, "b":6, "c":{ "d":7, "e= ":8} , "f": 9 }=C2=A0
=E2=80=8B
=E2= =80=8B=E2=80=8BHaving been playing about with the idea of encrypting log fi= les for GDPR purposes, I am convinced that even an encrypted log needs to b= e essentially a plaintext construct underneath.

--000000000000b956de056cf90a61-- From nobody Thu May 24 14:31:14 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED310127873 for ; Thu, 24 May 2018 14:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] 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 rmx2DmMHLtWB for ; Thu, 24 May 2018 14:31:10 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51FC312D7E4 for ; Thu, 24 May 2018 14:31:10 -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 w4OLUBvS005276; Thu, 24 May 2018 23:30:11 +0200 (CEST) Received: from [192.168.217.102] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (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 40sMwz047czDXsD; Thu, 24 May 2018 23:30:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Thu, 24 May 2018 23:30:10 +0200 Cc: Erik Wilde , JSON WG X-Mao-Original-Outgoing-Id: 548890208.658572-b09174e7b6d471e5bd991924b6dcb3aa Content-Transfer-Encoding: quoted-printable Message-Id: <40A5EAF8-816C-42FE-AA17-AC0523741978@tzi.org> References: <3e0e4811-b2be-2239-ce94-ee8b25c92b99@dret.net> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Json] Bridging the gap between ASN.1 and JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 May 2018 21:31:13 -0000 On May 24, 2018, at 21:56, Phillip Hallam-Baker = wrote: >=20 > As with CBOR, my objection is that I do not want a new encoding, I = want an =E2=80=8Bencoding that has JSON as a subset. That allows me to = have one decoder that is capable of decoding any message regardless of = whether it is in basic JSON or an extension. I know that this was a design goal of your various proposals; I just = think it is not a particularly useful one. But anyway, if it is important to you, it is easy to achieve with CBOR. = It=E2=80=99s easiest if your data model can get by with top-level = containers (the way JSON was up to RFC 4627, before RFC 7159 embraced = top-level atoms). If your data model is limited to this at least for the CBOR case, then = just send either JSON or CBOR. The receiver can look at the first byte: = If the high bit is set, decode as CBOR, else decode as JSON. Mission accomplished: the JSON=E2=88=AACBOR format I just described is a = superset of JSON. If you need the complete JSON data model on the CBOR side as well, too = just add the =E2=80=9Cthis is CBOR=E2=80=9D tag 55799 =E2=80=94 encoded = as 0xd9d9f7 =E2=80=94 to indicate the non-container CBOR case; see = section 2.4.5 of RFC 7049. This allows the high-bit discriminator to = work for top-level integers and strings, too. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 24 15:23:03 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3B012E8CC for ; Thu, 24 May 2018 15:23:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 jrf3vKj99rwb for ; Thu, 24 May 2018 15:22:59 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6FE212E8A7 for ; Thu, 24 May 2018 15:22:59 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id C483758000934; Thu, 24 May 2018 15:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=VfcHNelppVxFxY cfwVeGcEWulVw=; b=BwmqFXW1Tos3u5Grvu8+3xcZbjW0LwmFt8REtb37T1XD+3 xcSgDRoH5NqmLx9TZ4/uAZKVfQqsQXVRtrWUhvL8HVAVF1SZAw+8peD9FGOeFD4N oKSddlhgc0Gx+LAdeAf3y4istQY5sRbRD9MdN3DB3kq+rpUEPOvk+ov89daWA= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 66A3D58000931; Thu, 24 May 2018 15:22:58 -0700 (PDT) Date: Thu, 24 May 2018 17:22:56 -0500 From: Nico Williams To: Phillip Hallam-Baker Cc: Erik Wilde , JSON WG Message-ID: <20180524222254.GD14446@localhost> References: <3e0e4811-b2be-2239-ce94-ee8b25c92b99@dret.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Json] Bridging the gap between ASN.1 and JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 May 2018 22:23:01 -0000 On Thu, May 24, 2018 at 03:56:05PM -0400, Phillip Hallam-Baker wrote: > On Thu, May 24, 2018 at 1:58 PM, Erik Wilde wrote: > > > maybe have a brief look at http://bsonspec.org/ ? cheers, dret. > > Yes, I have seen it. As with CBOR, my objection is that I do not want a > new encoding, I want an encoding that has JSON as a subset. That allows me > to have one decoder that is capable of decoding any message regardless of > whether it is in basic JSON or an extension. I don't see the value of JSON as a subset of this new thing. You can always write two decoders, or one decoder that does both, provided you can unambiguously tell which encoding the input is in. > That in turn greatly simplifies content negotiation because we are only > negotiating the version of the encoding system, not the type. If a receiver > says it is capable of accepting JSON, JSON-B and JSON-C, the sender can > send any one of those encodings without having to specify which one because > there is only a JSON-C decoder. Sure, I see that. But I don't see how this follows: > I am also unhappy with binary encodings that extend the JSON data model. If it ain't a binary extension of JSON then you'll still have to use base64 and you'll still have to escape string. I thought you wanted to avoid base64. What gives. From nobody Wed May 30 01:12:26 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F50F12EBB5 for ; Wed, 30 May 2018 01:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 QGJJK-VRFtU4 for ; Wed, 30 May 2018 01:12:22 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F1412D868 for ; Wed, 30 May 2018 01:12:21 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id q4-v6so787907wmq.1 for ; Wed, 30 May 2018 01:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=p5sC8gekSDG3fbslO8nGcJIagrKNjDXsnKvnfh74gMY=; b=b+4DBPE2w7aNQDKm0HSTtBVo85l+EVozLygNTV6TYVFnIwBKzBFHvKsW1Jyi50Zas6 +pBih0gmr7AyhUSrhgbAQPZgkKSm6HwkodqlK4yXhQr2caPLno55sWbhM8VOqT4gFZfx 4rBZ81krt6ijmw5+VnfF8sa/enhxGTLLOdccnXevWQs/bHBOXkPn0STP3BYv4gFeIfEf gmpIwYY9WYkTAA1GaRJ6Qm37loxRhWP9ePt8EXCfPfUIi5/LP6zK1Ws3li8R4N4cmhwc OVn4hj1cdK1CokgstEKHm/6Uaih5AJluWc+Gyv5bdUEk54/45T1ev0832qLgWxjRh/Cn 5j9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=p5sC8gekSDG3fbslO8nGcJIagrKNjDXsnKvnfh74gMY=; b=h+eS1YF/w5PIK6kyuKuq5PAJOt566FhpCSqnN2l3bE2KMM3mS1s35VHYjjPfHzeSz1 jDaBhSNFw5D9aTxTkoUjGg5tclsnbRl6aK2eLcG7EguoEWMO5StpE45+9PKHSTNLM35T on8blmGCmrXEmUbEDL7e70xX4D90oyn+4pw6V81ZNAYc5IQOmwIssBv3SWgqGpA3GIc3 Xwk4j+jcGuQMZGqVjY233flYi8wP+pyKEeJ0C3ZvSmCh8b32naUfqj3rcXc6WwF+D8V5 MQTgkR1fiJ0yExREr+TB00wVNzpEucbyXcLcyYltNmWW+f+Mvv0KAvPFzJbXA+AWT/6w trfQ== X-Gm-Message-State: ALKqPwf/U9nlOIyca3VAqhit0nVe4OfhASKXqD8agwDqfrU2pWWjw6AR M+6/Qh2KtkIK+LJ297/g/xxQ1A== X-Google-Smtp-Source: ADUXVKITA8D15l59V1SV3OJAokRCd9pfOYzopWaD6SXjx4ZAv6BsQvQK3eRCvj9aBS2FKecvJNaaPw== X-Received: by 2002:a1c:ef0c:: with SMTP id n12-v6mr754744wmh.123.1527667939819; Wed, 30 May 2018 01:12:19 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id f81-v6sm8530084wmh.32.2018.05.30.01.12.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 May 2018 01:12:18 -0700 (PDT) From: Anders Rundgren To: "json@ietf.org" Message-ID: <884d40c8-d2ac-e562-0b46-e88bbef2d5d0@gmail.com> Date: Wed, 30 May 2018 10:12:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Json] Another take on "Signed JSON" X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 30 May 2018 08:12:24 -0000 Since JWS [RFC7515] in standard mode transforms JSON Objects into something entirely different as well as encoding data in Base64Url, various approaches have been suggested to create a more "JSON-friendly" signature solution. Using JWS in detached mode (https://tools.ietf.org/html/rfc7515#appendix-F) is an established way of achieving this objective, usually with an HTTP header holding the actual JWS object. However, it turns out that by applying a not particularly complex canonicalization scheme (https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-00#section-3.2), you can create a transport-independent, in-object (enveloped) JSON signature solution, without touching the JWS standard or associated libraries. Documentation: https://github.com/cyberphone/jws-jcs#combining-detached-jws-with-jcs-json-canonicalization-scheme On-line demo: https://mobilepki.org/jws-jcs/home // Anders From nobody Wed May 30 21:07:25 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DE512EB16; Wed, 30 May 2018 21:07:18 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 ILWHH9zCsTFQ; Wed, 30 May 2018 21:07:16 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA89E126C25; Wed, 30 May 2018 21:07:15 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id t11-v6so51380380wmt.0; Wed, 30 May 2018 21:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=ZLP/6/vEXJov7kIgj2K+WhC1KudXFo48HAb8xhbVem0=; b=rhHEuXcSKU4KZajBCOFcJQ7ftpWptQ5NGjY8y2DOzkj7Nar2zbp1ydG/WJzcu1EVex wgg9eqrnJ5zQ1UPqa/Yvl3BU8HQIp4SEEfMTwk/3VGeYtRWEIZf/lNJUX32X28q4b+gO Lcw8jGITV0ulFwhFf3waeRLh4wvc9xQtDALduRl2t/Xpd1O4x1ot6ioddUm3ebLKuzwm DlcLjIacUCLEe8M1Lia4nRuIIQGYVWLpch5TnaGa2hsasaXgp2vtD1p/ZdW88BhpBCP7 AGD7Pbwx7HwCWHIty7dHCHPDtPhHV+XC7VshqMpsSwQnyF0+5pFxkoU7a7Rl7Sh0Pl46 HYpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=ZLP/6/vEXJov7kIgj2K+WhC1KudXFo48HAb8xhbVem0=; b=KLBT4K/AhllkkyLdMqalQJxYPmSB1Z6IGzN4EjcObNhtgP6i6KiggAKp/MXF5FmDcU xVz4LK/75v+iBk6FLCsmGH+y9tSadZP48r/RvrjlItZaURWCtEs/vQ1unm+hiZ3F7qEJ c6jE53k1NW4NAcDyz7iHN+R8q73XmbiYWZOEvgbbfMkBsvwZo+ME/3AQcnHUuBeUgtTe tq22PXA/pqPPD8DP03ot6U6yzQ9gWx6koVFUmqPBNzmjgivNpxyPwsLOvKhyvvM5eNz8 YK25XwilCYvTFZrDmUjPgnQCGVg9H0FaW6xQx53jFqQRhv8104RSeJACHul892sJiELZ 0oYA== X-Gm-Message-State: ALKqPweo95oHMNyIE8XRt5057Bedac5tIwUr7KlwYsA0NuAnDgwCGQkE DsHTQexun42dzw3hGYMuH60= X-Google-Smtp-Source: ADUXVKJu2w/qJeu01TJMeGIPTjD84l/8v6E52m+4c7vq/Sn7loAHkyxz3XBPClV1A6vOXmPOfsCqVA== X-Received: by 2002:a1c:69d7:: with SMTP id z84-v6mr2876260wmh.147.1527739634488; Wed, 30 May 2018 21:07:14 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id u3-v6sm14171513wrm.60.2018.05.30.21.07.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 May 2018 21:07:13 -0700 (PDT) To: "json@ietf.org" , "jose@ietf.org" From: Anders Rundgren Message-ID: <3c5077dc-9fba-2a60-51e5-44bc154f7073@gmail.com> Date: Thu, 31 May 2018 06:07:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Json] JSON Canonicalization BoF Session @ IETF-102 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 31 May 2018 04:07:19 -0000 Dear lists; As you may have seen, the concept for "SIgned JSON" outlined in https://github.com/cyberphone/jws-jcs#combining-detached-jws-with-jcs-json-canonicalization-scheme and testable at https://mobilepki.org/jws-jcs/home, depends on a JSON canonicalization scheme currently described in https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-00. Would it be possible indicating if you have any interest in a possible standard for JSON canonicalization and if you will attend IETF-102? BTW, it appears to be a number of other JSON-related things that are on the verge becoming de-facto standards such as comments and support for numbers outside of IEEE-754 double precision.  Should JSON canonicalization follow the same path? Cheers, Anders Rundgren