From nobody Mon Apr 1 02:28:29 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A0A1200D7 for ; Mon, 1 Apr 2019 02:28:28 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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 (1024-bit key) header.d=ericsson.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 SomPtfXHGE4V for ; Mon, 1 Apr 2019 02:28:26 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140079.outbound.protection.outlook.com [40.107.14.79]) (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 600EB1200D5 for ; Mon, 1 Apr 2019 02:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9NTsnJNfOFjrVwPbZ+QSTp45x7cW0CrJYY0ajEcEBh4=; b=eblRv3ve3qt6w7ScDChq6g43kdEliU5U+GXkPUVvyGAacM7t/SJXGy6etT2S9P/E8VvXChU3QhE4RL57ujcgHqvfPzgBZkQQ5VEUw6gvqmXBhkPDX5SJY+ec7w6yRQOGVoPo98Jb+kamCq1h2wHjuDt3dyApP1gV2Mei4fzkrfE= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1SPR00MB102.eurprd07.prod.outlook.com (10.172.127.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.9; Mon, 1 Apr 2019 09:28:23 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2489:87b6:bfd8:727d]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2489:87b6:bfd8:727d%6]) with mapi id 15.20.1771.006; Mon, 1 Apr 2019 09:28:23 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: Minutes IETF104 Thread-Index: AQHU6G1AJCuJS+y2cE2wKIs+Lhtd7Q== Date: Mon, 1 Apr 2019 09:28:22 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e8f5b6ba-d42c-470f-f295-08d6b68462f4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1SPR00MB102; x-ms-traffictypediagnostic: HE1SPR00MB102: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(136003)(346002)(376002)(39860400002)(199004)(189003)(53754006)(82746002)(6506007)(86362001)(33656002)(106356001)(966005)(105586002)(2501003)(2351001)(478600001)(36756003)(606006)(5640700003)(68736007)(8936002)(6486002)(54896002)(6306002)(236005)(6512007)(486006)(476003)(316002)(5660300002)(14454004)(71190400001)(71200400001)(83716004)(6436002)(81166006)(6916009)(8676002)(53936002)(81156014)(1730700003)(2616005)(25786009)(44832011)(256004)(7736002)(66066001)(4744005)(6116002)(102836004)(26005)(7116003)(2906002)(3846002)(186003)(99286004)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1SPR00MB102; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 9XLaMs3LLC80HPBQ00gskBwEa1aeBIJuwb4SbN1hKV4DHCuC5dmPxRATIEJxxKV62KjpI7UOVgv9qIu5Y9y0FV1Cx3pk5nOnK0ezSKKLNUkhzj8z+xydmevNOeUk2ZRUNa6ktsL2mQMJ8ghuuN+SAJT8ABxRCrJwKvSvkRfdyqhNV9lOVmT5Eviat1/d0SdWYqPxPrTN8RB45kmFsY/jgeGEbCjW6ZJ15oHkUZxIGDQjEuKZrxU/LF2o729hddTg+wrOWrKaJvdjYYmnWXQqFIU2ICmXZml506qVeggLojVkw1bHfwr2wEqirxyQgD+ZZnlAZ6Gqs/mgkssXLJxmxPTTE2IApDu7irYeRjV+ITCXnBtn6ozlwWdOcszrEtqn1nY93T+ZkfG7sXQ7wKrW2JaUNPfgjLWSI0DgYuhjh4Q= Content-Type: multipart/alternative; boundary="_000_E988096491D64733A220E1C9FEFF56F4ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e8f5b6ba-d42c-470f-f295-08d6b68462f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 09:28:23.0261 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1SPR00MB102 Archived-At: Subject: [Cbor] Minutes IETF104 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 09:28:29 -0000 --_000_E988096491D64733A220E1C9FEFF56F4ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGp1c3QgcG9zdGVkIHRoZSBtaW51dGVzIGZvciBvdXIgbWVldGluZyBpbiBQ cmFndWUgdG8gdGhlIGRhdGF0cmFja2VyOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21l ZXRpbmcvMTA0L21hdGVyaWFscy9taW51dGVzLTEwNC1jYm9yLTAwDQoNClRoYW5rIHlvdSBzbyBt dWNoIHRvIG91ciBtaW51dGUgdGFrZXJzIENocmlzdGlhbiBhbmQgSmFpbWUhIEF0IHRoZSBib3R0 b20gb2YgdGhlIGRldGFpbGVkIG1pbnV0ZXMgeW91IHdpbGwgZmluZCBhIHN1bW1hcnkgb2YgdGhl IEFQcyB0aGF0IEkgY29sbGVjdGVkLiBBcyBhbHdheXMsIHBsZWFzZSBmZWVsIGZyZWUgdG8gbGV0 IG1lIGtub3cgaWYgYW55dGhpbmcgd2FzIGNhcHR1cmVkIGluY29ycmVjdGx5IG9yIGlmIGFueXRo aW5nIGlzIG1pc3NpbmcuDQoNClRoYW5rcywNCkZyYW5jZXNjYQ0K --_000_E988096491D64733A220E1C9FEFF56F4ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+SSBqdXN0IHBvc3RlZCB0aGUgbWludXRlcyBmb3Igb3VyIG1lZXRpbmcgaW4g UHJhZ3VlIHRvIHRoZSBkYXRhdHJhY2tlcjoNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA0L21hdGVyaWFscy9taW51dGVzLTEwNC1jYm9yLTAw Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA0L21hdGVyaWFscy9taW51 dGVzLTEwNC1jYm9yLTAwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5U aGFuayB5b3Ugc28gbXVjaCB0byBvdXIgbWludXRlIHRha2VycyBDaHJpc3RpYW4gYW5kIEphaW1l ISBBdCB0aGUgYm90dG9tIG9mIHRoZSBkZXRhaWxlZCBtaW51dGVzIHlvdSB3aWxsIGZpbmQgYSBz dW1tYXJ5IG9mIHRoZSBBUHMgdGhhdCBJIGNvbGxlY3RlZC4gQXMgYWx3YXlzLCBwbGVhc2UgZmVl bCBmcmVlIHRvIGxldCBtZSBrbm93IGlmIGFueXRoaW5nDQogd2FzIGNhcHR1cmVkIGluY29ycmVj dGx5IG9yIGlmIGFueXRoaW5nIGlzIG1pc3NpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZyYW5jZXNjYTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E988096491D64733A220E1C9FEFF56F4ericssoncom_-- From nobody Wed Apr 10 01:58:46 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C95E120383; Wed, 10 Apr 2019 01:58:21 -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 b32OkE8fGMlo; Wed, 10 Apr 2019 01:58:18 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331A71202BB; Wed, 10 Apr 2019 01:58:18 -0700 (PDT) Received: from [192.168.217.106] (p54A6CE73.dip0.t-ipconnect.de [84.166.206.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44fJ3C73lRzygC; Wed, 10 Apr 2019 10:58:15 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <1069e920de24c960ca46b3172d99db44802a3b2b.camel@rkf-eng.com> Date: Wed, 10 Apr 2019 10:58:15 +0200 Cc: "Burleigh, Scott C (312B)" , "dtn@ietf.org" , cbor@ietf.org X-Mao-Original-Outgoing-Id: 576579493.5323679-46df80c43ad0966b7ac4fb4acd68f1b1 Content-Transfer-Encoding: quoted-printable Message-Id: <508CCE17-8C7A-4FF1-8A19-992FCA5F5686@tzi.org> References: <6773e0f0e03e6e4ddb935f0f02de7ade2bc606b8.camel@rkf-eng.com> <670af7e65e8c4746947b0833690f4625@jpl.nasa.gov> <1069e920de24c960ca46b3172d99db44802a3b2b.camel@rkf-eng.com> To: Brian Sipos X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] [dtn] BPv7 CDDL and CBOR tagging X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 08:58:23 -0000 (CBOR WG: replying on https://mailarchive.ietf.org/arch/msg/dtn/3qn38t9lYR_e-7IicyARKfimLPk as this is an interesting use case of specialization.) Thanks! This already looks pretty good (once I fix the three cases of = line-wrapping). > On Apr 10, 2019, at 04:17, Brian Sipos wrote: >=20 > The reference program can be tested as in: For me, the tool has the problem that it can=E2=80=99t generate (block-type-specific-data .cbor ext-data-hop-count) With the former being block-type-specific-data =3D bstr / #6.24(bstr) What you are trying to say is that the bstr in there conforms to = =E2=80=9C.cbor ext-data-hop-count=E2=80=9D, but the tool is applying the = .cbor to the choice, and its brain is too small for that. I think some unraveling is required to properly address this. I would probably define a generic for this (sorry for the long names): optionally-tagged=E2=80=94embedded-cbor =3D T / #6.24(T) block-type-specific-data =3D optionally-tagged-embedded-cbor And then, e.g.: $extension-block-structure /=3D [ block-type-code: 7, extension-block-number, block-control-flags, crc-type, optionally-tagged-embedded-cbor<(bstr .cbor ext-data-previous-node)> ? crc-value ] OK, for readability maybe add embedded-cbor-optionally-tagged =3D = optionally-tagged-embedded-cbor and then=20 $extension-block-structure /=3D [ block-type-code: 7, extension-block-number, block-control-flags, crc-type, embedded-cbor-optionally-tagged ? crc-value ] That is not wonderful, as it repeats the fact that the thing is = optionally tagged =E2=80=9Cembedded CBOR=E2=80=9D all over the = individual block type definitions, but it starts enabling focus on the = actual structure again. (I=E2=80=99m still not entirely convinced that the tag 24 here is very = useful, but I=E2=80=99m trying to play along the design.) Gr=C3=BC=C3=9Fe, Carsten PS.: If I were writing this, I=E2=80=99d also add extension-block-of =3D [ block-type-code: N, extension-block-number, block-control-flags, crc-type, embedded-cbor-optionally-tagged ? crc-value ] And then just say $extension-block-structure /=3D extension-block-of<7, = ext-data-previous-node> but how much abstraction to add is a matter of preference; this at least = gets rid of the =E2=80=9Csprinkle the structure all over the place=E2=80=9D= problem. From nobody Wed Apr 10 13:58:29 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41CD120611 for ; Wed, 10 Apr 2019 13:58:27 -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 zoNNpcCUY2Kd for ; Wed, 10 Apr 2019 13:58:26 -0700 (PDT) Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (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 E4889120610 for ; Wed, 10 Apr 2019 13:58:25 -0700 (PDT) Received: by mail-pg1-x542.google.com with SMTP id g8so2278762pgf.2 for ; Wed, 10 Apr 2019 13:58:25 -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=gxgLCyuOEe0x8hJxV2pBug3xa4bdk0AVy+K+u+YLTec=; b=PvxBo1azqEZPbJ0UAy2XvRZAzbg87gaIglGgLV5pU4uQnxPOcz11QaBtU1naekZKxP zPEYZSrlnaksYdYFtwyzy4eEm+E2nXD1BcPmi2PTcHMQfFvOBMyvrTcmkEMxVC4bv/D7 f9MlyiBjea3WHcykj5gPWFhoizzLeOBHUpTZG/wMx8L77PSOcRnphFZrPd1QEtSdjMoS rLrOh9722kbNZ/SwpfGsIdXxNje9JIHdTxLQtPVCCTbwjSgMmsbJeqY3tEOatF6gaQpt KjQtkfGqnpcpx8Djl5esyVmz1w6iS9Eg6IRQYePxcBayN4oS5ylxVJCgVwoJLfXA48fX pvGA== 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=gxgLCyuOEe0x8hJxV2pBug3xa4bdk0AVy+K+u+YLTec=; b=nt2LB/SN0SFnNHfQ21fgmuwhZpMqtEewGDOP2R1rxlSp/4ObA71solR776BDDyQs0W /QjgESO0OTtca8D0GAlp4sYqgPHjdw4Q97ci6iyzkbMHUGy7yqjrpaZ9J24jNKzJd/Y8 l9iBDxW8fh11x2ZtYZfQ2WxGLzdZUxTEC3sx5xX3c10lENS69Xe04woWTPWLWhmAWQWq NJQNpLjdFpPOIWFknQ/lSYtnXO07Gwwh7VqJUuDC8hGNE4xY+9u8lAfa65UbbrCyChmJ 6+2JpHA4f61e7pUoXy6WpYqQ1UICbdRl2pmbCSII58ymjiv8Vu6K6JBPY5QLNp/UTlDt s4rg== X-Gm-Message-State: APjAAAX6NLpM0RQLlFMNbNBIrFWV208H1vMTe3yCJcPBd0U3Ik2N26O5 pDrZF3ZXtL8veyroNucMQjU= X-Google-Smtp-Source: APXvYqwczCDUMfkxwrVuo5OhbCgtQsLsSFOHbv9TXgKyIkYDmkOlVee/ShvN/o/IyjFvoRAt65oWQw== X-Received: by 2002:a65:62d2:: with SMTP id m18mr43303468pgv.122.1554929905141; Wed, 10 Apr 2019 13:58:25 -0700 (PDT) Received: from [192.168.178.30] ([118.148.72.95]) by smtp.gmail.com with ESMTPSA id t82sm98071586pfa.153.2019.04.10.13.58.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 13:58:24 -0700 (PDT) To: Carsten Bormann , Brian Sipos Cc: cbor@ietf.org, "Burleigh, Scott C (312B)" References: <6773e0f0e03e6e4ddb935f0f02de7ade2bc606b8.camel@rkf-eng.com> <670af7e65e8c4746947b0833690f4625@jpl.nasa.gov> <1069e920de24c960ca46b3172d99db44802a3b2b.camel@rkf-eng.com> <508CCE17-8C7A-4FF1-8A19-992FCA5F5686@tzi.org> From: Brian E Carpenter Message-ID: Date: Thu, 11 Apr 2019 08:58:19 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <508CCE17-8C7A-4FF1-8A19-992FCA5F5686@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] [dtn] BPv7 CDDL and CBOR tagging X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 20:58:28 -0000 I've dropped dtn since I doubt if they'd all be interested in my comment. I realised when reading this that I could definitely have used optionally-tagged-embedded-cbor in GRASP. In fact I implemented it in my code, when I realised that in some cases a user of the GRASP API might be tempted to pass in a CBOR value. It's a bit ugly, excuse my Python: if tname(_val) =3D=3D "bytes": #see if user supplied value as CBOR bytes try: _ =3D cbor.loads(x.value) #seems to be valid CBOR, build Tag 24 _tag24 =3D cbor.cbor.Tag(tag=3D24) _length =3D len(_val) #be lazy, don't optimise CBOR encoding if _length<65536: _tag24.value =3D bytes.fromhex('59')+_length.to_bytes(2,b= yteorder=3D'big')+_val _val =3D _tag24 else: #byte string too big, we'll send the raw bytes pass except: #not valid CBOR, we'll send the raw bytes pass (And some more messy code for de-tagging at the other end.) Regards Brian Carpenter On 10-Apr-19 20:58, Carsten Bormann wrote: > (CBOR WG: replying on > https://mailarchive.ietf.org/arch/msg/dtn/3qn38t9lYR_e-7IicyARKfimLPk > as this is an interesting use case of specialization.) >=20 > Thanks! This already looks pretty good (once I fix the three cases of = line-wrapping). >=20 >> On Apr 10, 2019, at 04:17, Brian Sipos wrote: >> >> The reference program can be tested as in: >=20 > For me, the tool has the problem that it can=E2=80=99t generate >=20 > (block-type-specific-data .cbor ext-data-hop-count) >=20 > With the former being >=20 > block-type-specific-data =3D bstr / #6.24(bstr) >=20 > What you are trying to say is that the bstr in there conforms to =E2=80= =9C.cbor ext-data-hop-count=E2=80=9D, but the tool is applying the .cbor = to the choice, and its brain is too small for that. >=20 > I think some unraveling is required to properly address this. >=20 > I would probably define a generic for this (sorry for the long names): >=20 > optionally-tagged=E2=80=94embedded-cbor =3D T / #6.24(T) >=20 > block-type-specific-data =3D optionally-tagged-embedded-cbor >=20 > And then, e.g.: >=20 > $extension-block-structure /=3D [ > block-type-code: 7, > extension-block-number, > block-control-flags, > crc-type, > optionally-tagged-embedded-cbor<(bstr .cbor ext-data-previous-node)> > ? crc-value > ] >=20 > OK, for readability maybe add >=20 > embedded-cbor-optionally-tagged =3D optionally-tagged-embedded-cbor<= bstr .cbor E> >=20 > and then=20 >=20 > $extension-block-structure /=3D [ > block-type-code: 7, > extension-block-number, > block-control-flags, > crc-type, > embedded-cbor-optionally-tagged > ? crc-value > ] >=20 > That is not wonderful, as it repeats the fact that the thing is optiona= lly tagged =E2=80=9Cembedded CBOR=E2=80=9D all over the individual block = type definitions, but it starts enabling focus on the actual structure ag= ain. >=20 > (I=E2=80=99m still not entirely convinced that the tag 24 here is very = useful, but I=E2=80=99m trying to play along the design.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > PS.: If I were writing this, I=E2=80=99d also add >=20 > extension-block-of =3D [ > block-type-code: N, > extension-block-number, > block-control-flags, > crc-type, > embedded-cbor-optionally-tagged > ? crc-value > ] >=20 > And then just say >=20 > $extension-block-structure /=3D extension-block-of<7, ext-data-previous= -node> >=20 > but how much abstraction to add is a matter of preference; this at leas= t gets rid of the =E2=80=9Csprinkle the structure all over the place=E2=80= =9D problem. >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Sat Apr 13 07:46:52 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F51D1201CF; Sat, 13 Apr 2019 07:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 DrFc88bBgp8m; Sat, 13 Apr 2019 07:46:34 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 CD7C11201B8; Sat, 13 Apr 2019 07:46:30 -0700 (PDT) Received: from mail-qt1-f178.google.com ([209.85.160.178]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hFJvG-0007sV-10; Sat, 13 Apr 2019 16:46:26 +0200 Received: by mail-qt1-f178.google.com with SMTP id k2so14595505qtm.1; Sat, 13 Apr 2019 07:46:25 -0700 (PDT) X-Gm-Message-State: APjAAAUDlUxpbMNyCBwVOaCFYwH/vu5s23jFXDvXcPpkYs+hXz5C/GY5 POYVyeG0Qv/0dxCW2OCAuQ0MMJlA+1Xerg5NPaI= X-Google-Smtp-Source: APXvYqxMUQ6S1XdElMSNLcKnMBrCyFyndiaMqrEiVVvuzDqs1JxeyXZdtBTZ0f7h8ipnl0H5mj49heAjoRUIxghOEaI= X-Received: by 2002:ac8:2a54:: with SMTP id l20mr52037829qtl.193.1555166784978; Sat, 13 Apr 2019 07:46:24 -0700 (PDT) MIME-Version: 1.0 From: Klaus Hartke Date: Sat, 13 Apr 2019 16:45:49 +0200 X-Gmail-Original-Message-ID: Message-ID: To: cose@ietf.org, "core@ietf.org WG" , cbor@ietf.org, Ace@ietf.org Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1555166793; 96846234; X-HE-SMSGID: 1hFJvG-0007sV-10 Archived-At: Subject: [Cbor] Doodle poll for virtual interims X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 14:46:36 -0000 We are looking for a new time slot for the CoRE/CBOR/COSE virtual interims until IETF 105. Proposed options: 7am PDT / 10am EDT / 4pm CEST / 11pm JST 8am PDT / 11am EDT / 5pm CEST / 12midn JST 9am PDT / 12noon EDT / 6pm CEST / 1am JST 10am PDT / 1pm EDT / 7pm CEST / 2am JST The interims are scheduled to be weekly, alternating between CoRE and CBOR/COSE (and a dash of ACE). Please use this doodle poll to indicate your preference: https://doodle.com/poll/ve7rnyareri2kqer Klaus From nobody Mon Apr 15 08:44:37 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4D8120382; Mon, 15 Apr 2019 08:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 f-KUr6A-iG4c; Mon, 15 Apr 2019 08:44:18 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40072.outbound.protection.outlook.com [40.107.4.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13D912001B; Mon, 15 Apr 2019 08:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5dK1KGM6ccgp1ccVmzgQVP2jCMTUmZCcbB3n2MKu81Y=; b=Jf/o4uryFz29y+5le8OzhYGfwMgtZf1zccV+fOkddGUXOrv3jDLWajx7+xxh2FO8A5rDJvgQSIbQhq+VTKbWLJ4eNGVs1exkeCSW3lFlPoJyyMDPtNaOo2pu+8Wo1VxN7ba4My8U6iDZNdcT7YV83GZSpIrSiubOBb8IbsaAs3o= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2874.eurprd07.prod.outlook.com (10.168.92.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Mon, 15 Apr 2019 15:44:14 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2489:87b6:bfd8:727d]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2489:87b6:bfd8:727d%6]) with mapi id 15.20.1813.009; Mon, 15 Apr 2019 15:44:14 +0000 From: Francesca Palombini To: "cose@ietf.org" , "core@ietf.org WG" , "cbor@ietf.org" , "Ace@ietf.org" Thread-Topic: [Ace] Doodle poll for virtual interims Thread-Index: AQHU8gfB1xzeYR7XSk63xG16DiVzHaY9YBcv Date: Mon, 15 Apr 2019 15:44:14 +0000 Message-ID: <0A9FF18D-5A9F-483A-B6CB-871CD25626F5@ericsson.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5268253e-9e9b-402f-c4fa-08d6c1b93689 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR0701MB2874; x-ms-traffictypediagnostic: HE1PR0701MB2874: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(376002)(136003)(346002)(396003)(199004)(189003)(5660300002)(26005)(76176011)(97736004)(186003)(25786009)(8676002)(305945005)(102836004)(6246003)(53546011)(6506007)(110136005)(236005)(316002)(6306002)(450100002)(106356001)(6512007)(14454004)(53936002)(33656002)(105586002)(54896002)(2906002)(7736002)(66066001)(229853002)(6486002)(82746002)(2501003)(256004)(86362001)(606006)(966005)(81156014)(476003)(81166006)(11346002)(446003)(2616005)(68736007)(486006)(2201001)(44832011)(8936002)(36756003)(71190400001)(71200400001)(83716004)(478600001)(99286004)(6436002)(6116002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2874; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 07xdM3ITsqNHly274pKCFl3HtDlc0PRK4vMImEiQmDkABrcz5Hmc2dFyIRhSD6YZIUTR8t6WrX2Kr8Y7C/H1VMx2NbhURMwSKeMoF9rVB6Vu+Ao+CZ/3idUFGvu8uCmGmEuHs+B8e7qCa1CBJchdlhwqlMNLReXiXgt4qL//8sMHn1koEa4+VujjoGEtO9vl36o+KFM29wcZrpwqu6DOvGYlbEzYhRVurFQAjVPR2sqrCgG7KJ//Q2fAqZe7vCM5iQ+cMWpUNj4z5PIQcrwcBXRNuC/1RDzTEV3f1gCsF3jvNYcqx17WcJm71oRty6SDxo/RW9+IZVDJKYvno5j5CB7NrhFL1aKgW0PzAY5LLgJOMZQSVzPYee1X/1nHKAw7qWUcNSqh/g+ijAIBLDLKWMVFmGaEwIDDhBnVRouvNvk= Content-Type: multipart/alternative; boundary="_000_0A9FF18D5A9F483AB6CB871CD25626F5ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5268253e-9e9b-402f-c4fa-08d6c1b93689 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 15:44:14.5491 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2874 Archived-At: Subject: Re: [Cbor] [Ace] Doodle poll for virtual interims X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 15:44:21 -0000 --_000_0A9FF18D5A9F483AB6CB871CD25626F5ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClBsZWFzZSBlbnRlciB5b3VyIGF2YWlsYWJpbGl0eSBieSB0aGlzIEZyaWRheSwgQXBy aWwgMTl0aDogaHR0cHM6Ly9kb29kbGUuY29tL3BvbGwvdmU3cm55YXJlcmkya3Flcg0KDQpBcyBL bGF1cyBzYWlkLCB0aGUgdGltZSBzbG90cyBhcmUgdG8gY2hvc2UgZm9yIHdlZWtseSBtZWV0aW5n cywgc28gZGlzcmVnYXJkIHRoZSBleGFjdCBkYXRlcyBpbiB0aGUgZG9vZGxlIHBvbGwsIGJ1dCBv bmx5IGNvbnNpZGVyIHRoZSBkYXkgb2YgdGhlIHdlZWsuDQoNClRoZSBnb2FsIGlzIHRvIHJlc3Rh cnQgdGhlIG1lZXRpbmdzIGJ5IHRoZSAybmQgd2VlayBvZiBNYXksIGFuZCB3ZSBuZWVkIGEgY291 cGxlIG9mIHdlZWtzIHRvIHNldCBpdCB1cCB3aXRoIHRoZSBTZWNyZXRhcmlhdC4NCg0KQWxzbyBu b3RlIHRoYXQgdGhlIHRpbWVzbG90cyBhcmUgOTAgbWludXRlcyBsb25nLCB0byBhbGxvdyBmb3Ig bG9uZ2VyIGludGVyaW0gdGltZSBpZiBuZWVkZWQuDQoNCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoN Cg0KT24gMTMgQXByaWwgMjAxOSBhdCAxNjo0NzowMiBDRVNULCBLbGF1cyBIYXJ0a2UgPGhhcnRr ZUBwcm9qZWN0Y29vbC5kZT4gd3JvdGU6DQpXZSBhcmUgbG9va2luZyBmb3IgYSBuZXcgdGltZSBz bG90IGZvciB0aGUgQ29SRS9DQk9SL0NPU0UgdmlydHVhbA0KaW50ZXJpbXMgdW50aWwgSUVURiAx MDUuDQoNClByb3Bvc2VkIG9wdGlvbnM6DQoNCjdhbSBQRFQgLyAxMGFtIEVEVCAvIDRwbSBDRVNU IC8gMTFwbSBKU1QNCjhhbSBQRFQgLyAxMWFtIEVEVCAvIDVwbSBDRVNUIC8gMTJtaWRuIEpTVA0K OWFtIFBEVCAvIDEybm9vbiBFRFQgLyA2cG0gQ0VTVCAvIDFhbSBKU1QNCjEwYW0gUERUIC8gMXBt IEVEVCAvIDdwbSBDRVNUIC8gMmFtIEpTVA0KDQpUaGUgaW50ZXJpbXMgYXJlIHNjaGVkdWxlZCB0 byBiZSB3ZWVrbHksIGFsdGVybmF0aW5nIGJldHdlZW4gQ29SRSBhbmQNCkNCT1IvQ09TRSAoYW5k IGEgZGFzaCBvZiBBQ0UpLg0KDQpQbGVhc2UgdXNlIHRoaXMgZG9vZGxlIHBvbGwgdG8gaW5kaWNh dGUgeW91ciBwcmVmZXJlbmNlOg0KaHR0cHM6Ly9kb29kbGUuY29tL3BvbGwvdmU3cm55YXJlcmky a3Flcg0KDQpLbGF1cw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KQWNlIG1haWxpbmcgbGlzdA0KQWNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0K --_000_0A9FF18D5A9F483AB6CB871CD25626F5ericssoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9Imx0 ciI+SGksDQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPlBsZWFz ZSBlbnRlciB5b3VyIGF2YWlsYWJpbGl0eSBieSB0aGlzIEZyaWRheSwgQXByaWwgMTl0aDombmJz cDs8c3Bhbj5odHRwczovL2Rvb2RsZS5jb20vcG9sbC92ZTdybnlhcmVyaTJrcWVyJm5ic3A7PC9z cGFuPjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5B cyBLbGF1cyBzYWlkLCB0aGUgdGltZSBzbG90cyBhcmUgdG8gY2hvc2UgZm9yIHdlZWtseSBtZWV0 aW5ncywgc28gZGlzcmVnYXJkIHRoZSBleGFjdCBkYXRlcyBpbiB0aGUgZG9vZGxlIHBvbGwsIGJ1 dCBvbmx5IGNvbnNpZGVyIHRoZSBkYXkgb2YgdGhlIHdlZWsuPC9kaXY+DQo8ZGl2IGRpcj0ibHRy Ij48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPlRoZSBnb2FsIGlzIHRvIHJlc3RhcnQgdGhl IG1lZXRpbmdzIGJ5IHRoZSAybmQgd2VlayBvZiBNYXksIGFuZCB3ZSBuZWVkIGEgY291cGxlIG9m IHdlZWtzIHRvIHNldCBpdCB1cCB3aXRoIHRoZSBTZWNyZXRhcmlhdC48YnI+DQo8L2Rpdj4NCjxk aXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+QWxzbyBub3RlIHRoYXQg dGhlIHRpbWVzbG90cyBhcmUgOTAgbWludXRlcyBsb25nLCB0byBhbGxvdyBmb3IgbG9uZ2VyIGlu dGVyaW0gdGltZSBpZiBuZWVkZWQuPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJkcmFmdC1icmVh ayI+PC9zcGFuPjxicj4NCjxicj4NClRoYW5rcywNCjxkaXYgZGlyPSJsdHIiPkZyYW5jZXNjYTwv ZGl2Pg0KPHNwYW4gaWQ9ImRyYWZ0LWJyZWFrIj48L3NwYW4+PGJyPg0KPGJyPg0KPGRpdj4NCjxk aXYgY2xhc3M9Im51bGwiIGRpcj0iYXV0byI+T24gMTMgQXByaWwgMjAxOSBhdCAxNjo0NzowMiBD RVNULCBLbGF1cyBIYXJ0a2UgJmx0O2hhcnRrZUBwcm9qZWN0Y29vbC5kZSZndDsgd3JvdGU6PGJy IGNsYXNzPSJudWxsIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImJv cmRlci1sZWZ0LXN0eWxlOnNvbGlkO2JvcmRlci13aWR0aDoxcHg7bWFyZ2luLWxlZnQ6MHB4O3Bh ZGRpbmctbGVmdDoxMHB4OyIgY2xhc3M9Im51bGwiPg0KPGRpdiBjbGFzcz0ibnVsbCIgZGlyPSJh dXRvIj4NCjxkaXYgY2xhc3M9Im51bGwiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50 PSJNaWNyb3NvZnQgRXhjaGFuZ2UgU2VydmVyIiBjbGFzcz0ibnVsbCI+DQo8IS0tIGNvbnZlcnRl ZCBmcm9tIHRleHQgLS0+DQo8ZGl2IGNsYXNzPSJudWxsIj48Zm9udCBzaXplPSIyIiBjbGFzcz0i bnVsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyIgY2xhc3M9Im51bGwiPg0KPGRpdiBu b3A9IlBsYWluVGV4dCIgY2xhc3M9Im51bGwiPldlIGFyZSBsb29raW5nIGZvciBhIG5ldyB0aW1l IHNsb3QgZm9yIHRoZSBDb1JFL0NCT1IvQ09TRSB2aXJ0dWFsPGJyIGNsYXNzPSJudWxsIj4NCmlu dGVyaW1zIHVudGlsIElFVEYgMTA1LjxiciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwi Pg0KUHJvcG9zZWQgb3B0aW9uczo8YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4N CjdhbSBQRFQgLyAxMGFtIEVEVCAvIDRwbSBDRVNUIC8gMTFwbSBKU1Q8YnIgY2xhc3M9Im51bGwi Pg0KOGFtIFBEVCAvIDExYW0gRURUIC8gNXBtIENFU1QgLyAxMm1pZG4gSlNUPGJyIGNsYXNzPSJu dWxsIj4NCjlhbSBQRFQgLyAxMm5vb24gRURUIC8gNnBtIENFU1QgLyAxYW0gSlNUPGJyIGNsYXNz PSJudWxsIj4NCjEwYW0gUERUIC8gMXBtIEVEVCAvIDdwbSBDRVNUIC8gMmFtIEpTVDxiciBjbGFz cz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KVGhlIGludGVyaW1zIGFyZSBzY2hlZHVsZWQg dG8gYmUgd2Vla2x5LCBhbHRlcm5hdGluZyBiZXR3ZWVuIENvUkUgYW5kPGJyIGNsYXNzPSJudWxs Ij4NCkNCT1IvQ09TRSAoYW5kIGEgZGFzaCBvZiBBQ0UpLjxiciBjbGFzcz0ibnVsbCI+DQo8YnIg Y2xhc3M9Im51bGwiPg0KUGxlYXNlIHVzZSB0aGlzIGRvb2RsZSBwb2xsIHRvIGluZGljYXRlIHlv dXIgcHJlZmVyZW5jZTo8YnIgY2xhc3M9Im51bGwiPg0KPGEgaHJlZj0iaHR0cHM6Ly9kb29kbGUu Y29tL3BvbGwvdmU3cm55YXJlcmkya3FlciIgdGFyZ2V0PSJfQkxBTksiIGNsYXNzPSJudWxsIj5o dHRwczovL2Rvb2RsZS5jb20vcG9sbC92ZTdybnlhcmVyaTJrcWVyPC9hPjxiciBjbGFzcz0ibnVs bCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KS2xhdXM8YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNz PSJudWxsIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyIGNsYXNzPSJudWxsIj4NCkFjZSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9Im51bGwiPg0KQWNl QGlldGYub3JnPGJyIGNsYXNzPSJudWxsIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYWNlIiB0YXJnZXQ9Il9CTEFOSyIgY2xhc3M9Im51bGwiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPC9hPjxiciBjbGFzcz0ibnVsbCI+ DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0A9FF18D5A9F483AB6CB871CD25626F5ericssoncom_-- From nobody Sat Apr 27 14:14:36 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E55F1200DE for ; Sat, 27 Apr 2019 14:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=felipegasper.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 wqTGC_CUP6iN for ; Sat, 27 Apr 2019 14:14:32 -0700 (PDT) Received: from web1.siteocity.com (web1.siteocity.com [67.227.147.204]) (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 C489C12004B for ; Sat, 27 Apr 2019 14:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=felipegasper.com; s=default; h=To:Date:Message-Id:Subject:Mime-Version: Content-Transfer-Encoding:Content-Type:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Yl2jKJMBwrsNoMOrokzd5npGpl9dZxCF2m52b9TNKzU=; b=mnaPKPPwoDvbWS2rPmlJcctYkG jRs8TyTxh+AGfzOreQV5qPVO4MP6AAqfUw3EVregr5+Tp1RMtmRcHZvn8/51o/fJMcCsw6WZwX1sD oDmytPECyOqkl1w9auo7djGFPzDah2kHkZzYmjQcWvtDv8mzhqtEh28OeZpSuRzSBBCzDifEIXIyQ L4dt6sqyeLN8EwzIl1sroIgFmCtQC/HUAvy/FaFxrW2dAR3Cez0IJq5VsiyM5PlZBHezpXOzPRtPY uiJcNGML3WMEMEzsiVJSgV6r/wf2SixeOYbkjutYgl4ypZOW//olN8kTYA/dhyUHcLWaU0C7o0VxQ 9teYKDsw==; Received: from [149.248.87.38] (port=51674 helo=felipes-mbp.lan) by web1.siteocity.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hKUeV-00A4sW-5K for cbor@ietf.org; Sat, 27 Apr 2019 16:14:31 -0500 From: Felipe Gasper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <7F3512DE-A3E2-41F1-A514-EC3F0BF2E3F3@felipegasper.com> Date: Sat, 27 Apr 2019 17:14:30 -0400 To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web1.siteocity.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - felipegasper.com X-Get-Message-Sender-Via: web1.siteocity.com: authenticated_id: fgasper/from_h X-Authenticated-Sender: web1.siteocity.com: felipe@felipegasper.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cbor] Decoding of 64-bit CBOR ints on 32-bit systems X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2019 21:14:34 -0000 Hello, Is there either a custom or a standard that guides = interpretation of 64-bit CBOR integers on 32-bit systems that don=E2=80=99= t have 64-bit emulation? Thank you! -Felipe Gasper Mississauga, Ontario= From nobody Sat Apr 27 15:06:37 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14D01202B9 for ; Sat, 27 Apr 2019 15:06:35 -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 gzV_4yLej1Ht for ; Sat, 27 Apr 2019 15:06:33 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389A71202B2 for ; Sat, 27 Apr 2019 15:06:33 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44s4kv0xq0zyZD; Sun, 28 Apr 2019 00:06:31 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <7F3512DE-A3E2-41F1-A514-EC3F0BF2E3F3@felipegasper.com> Date: Sun, 28 Apr 2019 00:06:30 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 578095588.3287621-aaa741f7c1d92e76dc97ae73500ea59e Content-Transfer-Encoding: quoted-printable Message-Id: <6A0E6EDA-2337-4682-A753-7ACEBB3AB7BB@tzi.org> References: <7F3512DE-A3E2-41F1-A514-EC3F0BF2E3F3@felipegasper.com> To: Felipe Gasper X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Decoding of 64-bit CBOR ints on 32-bit systems X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2019 22:06:36 -0000 Hi Felipe, > On Apr 27, 2019, at 23:14, Felipe Gasper = wrote: >=20 > Is there either a custom or a standard that guides = interpretation of 64-bit CBOR integers on 32-bit systems that don=E2=80=99= t have 64-bit emulation? How to interpret this question depends a bit on what you are trying to = do. Let me try to list the possibilities: (1) I have an application protocol that makes use of integers that = don=E2=80=99t fit into the 32-bit integers I have on my systems. (2) I have an application protocol that doesn=E2=80=99t make use of such = integers. A CBOR encoder could still use a 64-bit form for such an = integer (non-preferred encoding). Orthogonal to this is the question whether you are employing a generic = CBOR decoder or an application-specific one. I think for (2) with a generic CBOR decoder, my recommendation would be = to handle this in the generic CBOR decoder (e.g., by checking that the = upper 32 bits are zero); similarly for an application specific CBOR = decoder. Alternatively, the application protocol could outright forbid = 64-bit forms, just like it could forbid floating point numbers. For (1), any application-specific CBOR decoder would then have to handle = this case in a way that makes sense for the application. A generic CBOR = decoder could define its own 64-bit integer type (not necessarily with = all the usual operations implemented), e.g. as a struct of two 32-bit = unsigned integers. Such a generic decoder would, of course, also work = for (2); I=E2=80=99d probably still recommend that the decoder deliver = integers where the upper half is zero as simple 32-bit integers. An = application of type (2) would handle any input that has those 64-bit = structures as =E2=80=9Cunexpected=E2=80=9D input. Similar considerations apply for other data types not supported by the = platform, e.g. 64-bit floating point values (or floating point values at = all); it is maybe more obvious how to handle these. After trying to handle your question in a general way, I think you can = see what we would like to know about the specific circumstances to = really answer this question. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Apr 27 16:19:46 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E59E120091 for ; Sat, 27 Apr 2019 16:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=felipegasper.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 0p013ZXu2crb for ; Sat, 27 Apr 2019 16:19:44 -0700 (PDT) Received: from web1.siteocity.com (web1.siteocity.com [67.227.147.204]) (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 D7D7B12004C for ; Sat, 27 Apr 2019 16:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=felipegasper.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=hAyntnNXxFsSl6dL792UEKQ8EgCPEsR3UkJT7YhxMp8=; b=CKTWmFUcKbrUciYZ0RVLrxU92 ITSxMtQy7kefZoufUsLjZs7VtxP7XPMZsoEO97n9Ytod9hOgqTA/uajBBhwLjCsfzpESoQI9fFw00 RtTvLJQnPzfuC9tATY0aX3jGC/EqNqVX/B5amfbUN2xiLBRut83jh3jxVjcCW6qgYprjctuElzetq vuISdwmQOqr06KiX7HuewrkAQ6xB7JZUzMQrxN7cleBybCzVVT8UbSUnHc1ulYpAVo7YOlf1A+lab 8H0IPvZA21zeVG87uAfqTilvWgb6ljMcK3K+CoX7P+Mia4B0qxOkipfba2yZFO5OCamO9MKyVFnrm 9BbU4401g==; Received: from cpef81d0f822683-cmf81d0f822680.cpe.net.cable.rogers.com ([99.245.77.83]:51883 helo=[192.168.0.30]) by web1.siteocity.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hKWbd-00AUCe-Ma; Sat, 27 Apr 2019 18:19:42 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Felipe Gasper In-Reply-To: <6A0E6EDA-2337-4682-A753-7ACEBB3AB7BB@tzi.org> Date: Sat, 27 Apr 2019 19:19:40 -0400 Cc: cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <75A561E9-8633-4B4E-A5D1-F2C845CA3DFE@felipegasper.com> References: <7F3512DE-A3E2-41F1-A514-EC3F0BF2E3F3@felipegasper.com> <6A0E6EDA-2337-4682-A753-7ACEBB3AB7BB@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web1.siteocity.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - felipegasper.com X-Get-Message-Sender-Via: web1.siteocity.com: authenticated_id: fgasper/from_h X-Authenticated-Sender: web1.siteocity.com: felipe@felipegasper.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cbor] Decoding of 64-bit CBOR ints on 32-bit systems X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2019 23:19:46 -0000 > On Apr 27, 2019, at 6:06 PM, Carsten Bormann wrote: >=20 > Hi Felipe, >=20 >> On Apr 27, 2019, at 23:14, Felipe Gasper = wrote: >>=20 >> Is there either a custom or a standard that guides = interpretation of 64-bit CBOR integers on 32-bit systems that don=E2=80=99= t have 64-bit emulation? >=20 > How to interpret this question depends a bit on what you are trying to = do. Let me try to list the possibilities: Hi Carsten, Thank you for your response. Please forgive my vagueness before. I=E2=80=99m writing a general-purpose CBOR library in Perl XS. (The = existing one doesn=E2=80=99t support newer Perl versions and has = licensing problems for my team.) I think what makes the most sense for me will be to consider numbers = that aren=E2=80=99t representable in 32 bits as invalid input. Thank you again! -FG p.s. The project is up at: https://github.com/FGasper/p5-CBOR-Free= From nobody Sun Apr 28 01:12:57 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA75D1200F8 for ; Sun, 28 Apr 2019 01:12:55 -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 nd4A2NkE1kPe for ; Sun, 28 Apr 2019 01:12:54 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEEBD12008A for ; Sun, 28 Apr 2019 01:12:53 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44sLBW0t0tzyvl; Sun, 28 Apr 2019 10:12:51 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <75A561E9-8633-4B4E-A5D1-F2C845CA3DFE@felipegasper.com> Date: Sun, 28 Apr 2019 10:12:49 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 578131967.9331959-6629a933e777312c8db2a84d7cf73252 Content-Transfer-Encoding: quoted-printable Message-Id: <17A06717-869C-49D2-9B71-4B656B8831CC@tzi.org> References: <7F3512DE-A3E2-41F1-A514-EC3F0BF2E3F3@felipegasper.com> <6A0E6EDA-2337-4682-A753-7ACEBB3AB7BB@tzi.org> <75A561E9-8633-4B4E-A5D1-F2C845CA3DFE@felipegasper.com> To: Felipe Gasper X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Decoding of 64-bit CBOR ints on 32-bit systems X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2019 08:12:56 -0000 On Apr 28, 2019, at 01:19, Felipe Gasper = wrote: >=20 > I think what makes the most sense for me will be to consider numbers = that aren=E2=80=99t representable in 32 bits as invalid input. Another alternative would be to represent these numbers using any bignum = facility that may be part of the language (or popular =E2=80=93 I must = admit I=E2=80=99m not using Perl as much today as I did in the 1990s, so = I=E2=80=99m not sure which such facility you would use). This by the = way also could then be used to handle tags 2/3. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 29 06:39:22 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA201120319 for ; Mon, 29 Apr 2019 06:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=felipegasper.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 MbDSYDPjAzbO for ; Mon, 29 Apr 2019 06:39:16 -0700 (PDT) Received: from web1.siteocity.com (web1.siteocity.com [67.227.147.204]) (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 4D114120306 for ; Mon, 29 Apr 2019 06:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=felipegasper.com; s=default; h=To:Message-Id:Subject:Date:Mime-Version: Content-Transfer-Encoding:Content-Type:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=uE+KT6ODSvQaIjjnvPYF83dibhiFsfWkiPG63C0aywY=; b=k/g+b+BbqN9Ab6LQe5pdUlwKzP fIvIF49G4EdLNGlxTMIxAhf7Gf9arYJTyeSfSecD7vyyv+DMXWGxaMKBmea/p4rlma/fQp5M2+t3k vWgerTkHoh6Gg74E41zxsTyR7Yyj3D7bAmruH+uUYBfSLbfMGRMkwmiWbhCT16ty4ZfsnqtKCn8Nv snsZz9VWBdQpGaepvyfUo3W2ssLL2zbPgZw+ZxYFffZZe01eNRKkfEiCeMVSrNj5fJwCysgXNlDZO e60Xm5MmBveHksJ1w46qsKB7ZI41FgoGRcDymuyc4Q5IQ2OY0kgHcSCivqjEAK5ZQgS7eSLcdMvyO 8RS43Azw==; Received: from [208.54.80.144] (port=18225 helo=[22.34.232.198]) by web1.siteocity.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hL6Ux-000aVh-KM for cbor@ietf.org; Mon, 29 Apr 2019 08:39:12 -0500 From: Felipe Gasper Content-Type: multipart/alternative; boundary=Apple-Mail-6145A81E-B445-4328-8AAA-C4469AC229CF Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Mon, 29 Apr 2019 09:39:10 -0400 Message-Id: <8269CD1C-B024-4961-A889-C8543502596A@felipegasper.com> To: cbor@ietf.org X-Mailer: iPhone Mail (16D57) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web1.siteocity.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - felipegasper.com X-Get-Message-Sender-Via: web1.siteocity.com: authenticated_id: fgasper/from_h X-Authenticated-Sender: web1.siteocity.com: felipe@felipegasper.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cbor] Map keys? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 13:39:21 -0000 --Apple-Mail-6145A81E-B445-4328-8AAA-C4469AC229CF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I=E2=80=99m looking at RFC 8392, which says: =E2=80=94=E2=80=94- In JSON, maps are called objects and only have one kind of map key: a string= . CBOR uses strings, negative integers, and unsigned integers as map keys. T= he integers are used for compactness of encoding and easy comparison. The in= clusion of strings allows for an additional range of short encoded values to= be used. =E2=80=94=E2=80=94- While this doesn=E2=80=99t directly say per se that CBOR _only_ uses strings= and integers as map keys, the implication seems strong. I don=E2=80=99t see= any such limitation in the CBOR RFC. Does CBOR intend, then, to restrict map keys to only major types 0, 1, and 3= ? Thank you! -Felipe= --Apple-Mail-6145A81E-B445-4328-8AAA-C4469AC229CF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello,

I=E2=80=99m looking at RFC 8392, which says:

= =E2=80=94=E2=80=94-
In JSON, maps are called objects and only have one kind of map key: a=

   string.  CBOR uses strings, negative integers, and unsigned integers
   as map keys.  The integers are used for compactness of encoding and
   easy comparison.  The inclusion of strings allows for an additional
   range of short encoded values to be used.
=E2=
=80=94=E2=80=94-

While this doesn=E2=80=99t directly say per se that CBOR _only_ uses= strings and integers as map keys, the implication seems strong. I don=E2=80= =99t see any such limitation in the CBOR RFC.
<=
br>
Does CBOR intend, then, to restrict map k=
eys to only major types 0, 1, and 3?

Thank you!

-Felipe
= --Apple-Mail-6145A81E-B445-4328-8AAA-C4469AC229CF-- From nobody Mon Apr 29 06:59:02 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3FF120329 for ; Mon, 29 Apr 2019 06:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 I2h78PcC6yZt for ; Mon, 29 Apr 2019 06:58:59 -0700 (PDT) Received: from p3plsmtpa09-07.prod.phx3.secureserver.net (p3plsmtpa09-07.prod.phx3.secureserver.net [173.201.193.236]) (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 D477D1200C7 for ; Mon, 29 Apr 2019 06:58:58 -0700 (PDT) Received: from [192.168.1.108] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id L6o5hyf9IpwnzL6o6hAoqe; Mon, 29 Apr 2019 06:58:58 -0700 From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8089DBEB-A073-42CC-9C15-DF2FDA0AA766" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 29 Apr 2019 06:58:57 -0700 In-Reply-To: <8269CD1C-B024-4961-A889-C8543502596A@felipegasper.com> Cc: cbor@ietf.org To: Felipe Gasper References: <8269CD1C-B024-4961-A889-C8543502596A@felipegasper.com> X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfHerxK+79T2wpg3e+fsOVvFDVxdd7nBiqe5DB6nmiFijxI9RgvVWlp5JcA2U6/tqd1agpeRFzj/7uSOdZhUnDq2OHWTvpySZEPD0dbohElOyLHhhpcxA QnOIC29YDnMSGx2cLcQc+d1kyfYBKVsyLjAn2sbFKSN2ZFFJN+QB+OPwL/kgr561ibVl3GwBo/iID5sx+4yxmOYLSapZRr8tn5o= Archived-At: Subject: Re: [Cbor] Map keys? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 13:59:01 -0000 --Apple-Mail=_8089DBEB-A073-42CC-9C15-DF2FDA0AA766 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Felipe, There is no restriction on map keys in CBOR. But maybe there should be a CBOR protocol design guideline that strongly = recommends this. Seems to me that the complexity of implementation of a = generic decoder that handles keys that are maps and labels is pretty = high. We already have trouble with equivalence and sorting of map keys = with just the strings and integers, seems like a protocol using arrays = and maps would make that much worse.=20 It also seems like a very unusual thing to do and beyond what other = protocols and languages do. I chose to make my C implementation of CBOR = have built-in support for = keys that are integer or strings, but not arrays or maps. (You can put = it in a mode where it will handle any type of key, but you lose most of = the the built-in support for maps, because they are just treated like = arrays).=20 With such a recommendation we=E2=80=99d probably consider the inclusion = of binary strings and floating point numbers as keys.=20 LL > On Apr 29, 2019, at 6:39 AM, Felipe Gasper = wrote: >=20 > Hello, >=20 > I=E2=80=99m looking at RFC 8392, which says: >=20 > =E2=80=94=E2=80=94- > In JSON, maps are called objects and only have one kind of map key: a = string. CBOR uses strings, negative integers, and unsigned integers as = map keys. The integers are used for compactness of encoding and easy = comparison. The inclusion of strings allows for an additional range of = short encoded values to be used. > =E2=80=94=E2=80=94- >=20 > While this doesn=E2=80=99t directly say per se that CBOR _only_ uses = strings and integers as map keys, the implication seems strong. I = don=E2=80=99t see any such limitation in the CBOR RFC. >=20 > Does CBOR intend, then, to restrict map keys to only major types 0, 1, = and 3? >=20 > Thank you! >=20 > -Felipe > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_8089DBEB-A073-42CC-9C15-DF2FDA0AA766 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Felipe,

There is no = restriction on map keys in CBOR.

But maybe there should be a CBOR = protocol design guideline that strongly recommends this. Seems to me = that the complexity of implementation of a generic decoder that handles = keys that are maps and labels is pretty high. We already have trouble = with equivalence and sorting of map keys with just the strings and = integers, seems like a protocol using arrays and maps would make that = much worse. 

It also seems like a very unusual thing to do and beyond what = other protocols and languages do.

I chose to make my C = implementation of CBOR have built-in support for keys that are = integer or strings, but not arrays or maps. (You can put it in a mode = where it will handle any type of key, but you lose most of the the = built-in support for maps, because they are just treated like = arrays). 

With such a recommendation we=E2=80=99d probably consider the = inclusion of binary strings and floating point numbers as = keys. 

LL


On Apr = 29, 2019, at 6:39 AM, Felipe Gasper <felipe@felipegasper.com> wrote:

Hello,

I=E2=80=99m looking at RFC 8392, which says:

=E2=80=94=E2=80=94-
<= div class=3D"">
In JSON, =
maps are called objects and only have one kind of map key: a
   string.  CBOR uses strings, negative integers, and unsigned integers
   as map keys.  The integers are used for compactness of encoding and
   easy comparison.  The inclusion of strings allows for an additional
   range of short encoded values to be used.
=E2=80=94=E2=80=94-

While this doesn=E2=80=99t directly say per se that =
CBOR _only_ uses strings and integers as map keys, the implication seems =
strong. I don=E2=80=99t see any such limitation in the CBOR =
RFC.

Does CBOR intend, then, to =
restrict map keys to only major types 0, 1, and =
3?

Thank =
you!

-Felipe
________________________= _______________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor

= --Apple-Mail=_8089DBEB-A073-42CC-9C15-DF2FDA0AA766-- From nobody Mon Apr 29 07:02:28 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED831200C7 for ; Mon, 29 Apr 2019 07:02:27 -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 tnzkujUM_4MX for ; Mon, 29 Apr 2019 07:02:23 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123CA120329 for ; Mon, 29 Apr 2019 07:02:23 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44t5vK2XLZzyTV; Mon, 29 Apr 2019 16:02:21 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <8269CD1C-B024-4961-A889-C8543502596A@felipegasper.com> Date: Mon, 29 Apr 2019 16:02:20 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 578239338.536196-d428c5c7a5a7c2eea61f9747bbe6914a Content-Transfer-Encoding: quoted-printable Message-Id: References: <8269CD1C-B024-4961-A889-C8543502596A@felipegasper.com> To: Felipe Gasper X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Map keys? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 14:02:27 -0000 On Apr 29, 2019, at 15:39, Felipe Gasper = wrote: >=20 > Hello, >=20 > I=E2=80=99m looking at RFC 8392, which says: >=20 > =E2=80=94=E2=80=94- > In JSON, maps are called objects and only have one kind of map key: a = string. CBOR uses strings, negative integers, and unsigned integers as = map keys.=20 Well, it doesn=E2=80=99t say =E2=80=9Cand nothing else=E2=80=9D :-) RFC 8392 is not intended to update RFC 7049, anyway. > The integers are used for compactness of encoding and easy comparison. = The inclusion of strings allows for an additional range of short encoded = values to be used. > =E2=80=94=E2=80=94- >=20 > While this doesn=E2=80=99t directly say per se that CBOR _only_ uses = strings and integers as map keys, the implication seems strong. I = don=E2=80=99t see any such limitation in the CBOR RFC. >=20 > Does CBOR intend, then, to restrict map keys to only major types 0, 1, = and 3? There is no such intention. Indeed, major types 0/1 and 3 are the most often used map keys (probably = followed by 2). But there is nothing wrong with 7 (false, true, =E2=80=A6= ), 6 (tagged data), or the containers (4, 5) etc. as map keys. This may be elucidated a bit more by draft-ietf-cbor-cddl-08.txt (in RFC = editor queue), section 2, which distinguishes two kinds of map usage: = =E2=80=9Cstructs=E2=80=9D (where indeed 0/1 and 3 are usually most = convenient), and =E2=80=9Ctables=E2=80=9D, where the ability to use any = CBOR data item as a map key is vital. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 29 08:49:17 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B4D120086 for ; Mon, 29 Apr 2019 08:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 9zah3uS2_0cy for ; Mon, 29 Apr 2019 08:49:13 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC76E12004E for ; Mon, 29 Apr 2019 08:49:12 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Apr 2019 08:49:05 -0700 From: Jim Schaad To: 'Felipe Gasper' , References: <8269CD1C-B024-4961-A889-C8543502596A@felipegasper.com> In-Reply-To: <8269CD1C-B024-4961-A889-C8543502596A@felipegasper.com> Date: Mon, 29 Apr 2019 08:49:04 -0700 Message-ID: <003b01d4fea3$14012250$3c0366f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01D4FE68.67A41F10" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQFGBkt4cHgMpYZBnw/w3mkQotkUJqdxOVYQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Map keys? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 15:49:16 -0000 ------=_NextPart_000_003C_01D4FE68.67A41F10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please file an errata on this. The text should be =E2=80=9CIn = JSON,=E2=80=A6 CWT uses strings,=E2=80=A6=E2=80=9D The document is = talking about what CWT uses for keys and not what CBOR is using for = keys. =20 Jim =20 =20 From: CBOR On Behalf Of Felipe Gasper Sent: Monday, April 29, 2019 6:39 AM To: cbor@ietf.org Subject: [Cbor] Map keys? =20 Hello, =20 I=E2=80=99m looking at RFC 8392, which says: =20 =E2=80=94=E2=80=94- In JSON, maps are called objects and only have one kind of map key: a = string. CBOR uses strings, negative integers, and unsigned integers as = map keys. The integers are used for compactness of encoding and easy = comparison. The inclusion of strings allows for an additional range of = short encoded values to be used. =E2=80=94=E2=80=94- =20 While this doesn=E2=80=99t directly say per se that CBOR _only_ uses = strings and integers as map keys, the implication seems strong. I = don=E2=80=99t see any such limitation in the CBOR RFC. =20 Does CBOR intend, then, to restrict map keys to only major types 0, 1, = and 3? =20 Thank you! =20 -Felipe ------=_NextPart_000_003C_01D4FE68.67A41F10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Please file an errata on this.=C2=A0 The text should = be =E2=80=9CIn JSON,=E2=80=A6=C2=A0 CWT uses = strings,=E2=80=A6=E2=80=9D=C2=A0 The document is talking about what CWT = uses for keys and not what CBOR is using for keys.

 

Jim

 

 

From: CBOR = <cbor-bounces@ietf.org> On Behalf Of Felipe = Gasper
Sent: Monday, April 29, 2019 6:39 AM
To: = cbor@ietf.org
Subject: [Cbor] Map = keys?

 

Hello,

 

I=E2=80=99m looking at RFC 8392, which = says:

 

=E2=80=94=E2=80=94-

In JSON, maps are =
called objects and only have one kind of map key: a string. CBOR uses =
strings, negative integers, and unsigned integers as map keys. The =
integers are used for compactness of encoding and easy comparison. The =
inclusion of strings allows for an additional range of short encoded =
values to be used.
=E2=80=94=E2=80=94-
 
While this =
doesn=E2=80=99t directly say per se that CBOR _only_ uses strings and =
integers as map keys, the implication seems strong. I don=E2=80=99t see =
any such limitation in the CBOR RFC.
 
Does CBOR intend, =
then, to restrict map keys to only major types 0, 1, and =
3?
 
Thank =
you!
 
-Felipe
------=_NextPart_000_003C_01D4FE68.67A41F10-- From nobody Mon Apr 29 08:56:31 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B310C120330 for ; Mon, 29 Apr 2019 08:56: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, 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=felipegasper.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 b5BKWj-C8suL for ; Mon, 29 Apr 2019 08:56:27 -0700 (PDT) Received: from web1.siteocity.com (web1.siteocity.com [67.227.147.204]) (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 78E8A12004E for ; Mon, 29 Apr 2019 08:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=felipegasper.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=MdcyPX8ZPEiic7II1kOfZM4J0YqDGuNGH6MacE6ykdo=; b=Jf4rRHfTExZ14MtIrcUDqWqLU KpY5ieRdPFkH3lxZX6YLWPtUE36WtIIYWjI0aLKZvZhasbaJc+4IuLo2ywvb98DL2dxyDPGpVWLXF x5PhXFU+T1VXLDKi6ulCrhKarsc3/m1UNSsxHg/PfU/3fG9doz3EW4SN28xQmEyHjVKVw131xvzUz aE786LgH7HkQp4JiYkYPwdMgjEsMbAC9rswb5waxHcfQvIbgGLzUlp7DK2iQj75o/ojSTX7ZfXVU/ KMuJkN3xDZJU/HPjX9gd4LAU1A2zT7Q1TBLr92EKwkyrJH57znBmFQlf7qLWEdxmGhwcXTtYySqzT ppU3MDf6w==; Received: from [149.248.87.38] (port=55939 helo=[192.168.86.20]) by web1.siteocity.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hL8dl-0013GS-5y; Mon, 29 Apr 2019 10:56:25 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Felipe Gasper In-Reply-To: <003b01d4fea3$14012250$3c0366f0$@augustcellars.com> Date: Mon, 29 Apr 2019 11:56:24 -0400 Cc: cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8269CD1C-B024-4961-A889-C8543502596A@felipegasper.com> <003b01d4fea3$14012250$3c0366f0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web1.siteocity.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - felipegasper.com X-Get-Message-Sender-Via: web1.siteocity.com: authenticated_id: fgasper/from_h X-Authenticated-Sender: web1.siteocity.com: felipe@felipegasper.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cbor] Map keys? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 15:56:30 -0000 Done. -FG > On Apr 29, 2019, at 11:49 AM, Jim Schaad = wrote: >=20 > Please file an errata on this. The text should be =E2=80=9CIn = JSON,=E2=80=A6 CWT uses strings,=E2=80=A6=E2=80=9D The document is = talking about what CWT uses for keys and not what CBOR is using for = keys. > =20 > Jim > =20 > =20 > From: CBOR On Behalf Of Felipe Gasper > Sent: Monday, April 29, 2019 6:39 AM > To: cbor@ietf.org > Subject: [Cbor] Map keys? > =20 > Hello, > =20 > I=E2=80=99m looking at RFC 8392, which says: > =20 > =E2=80=94=E2=80=94- > In JSON, maps are called objects and only have one kind of map key: a = string. CBOR uses strings, negative integers, and unsigned integers as = map keys. The integers are used for compactness of encoding and easy = comparison. The inclusion of strings allows for an additional range of = short encoded values to be used. > =E2=80=94=E2=80=94- > =20 > While this doesn=E2=80=99t directly say per se that CBOR _only_ uses = strings and integers as map keys, the implication seems strong. I = don=E2=80=99t see any such limitation in the CBOR RFC. > =20 > Does CBOR intend, then, to restrict map keys to only major types 0, 1, = and 3? > =20 > Thank you! > =20 > -Felipe > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor