From nobody Tue May 7 01:24: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 4632612009E; Tue, 7 May 2019 01:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 5ZRK7gdiU8PX; Tue, 7 May 2019 01:24:34 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30082.outbound.protection.outlook.com [40.107.3.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBEE12001E; Tue, 7 May 2019 01:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=teqtRPBWGMnP1rY0Zp55DUP9HsPiOnHRCii2Uel1098=; b=PUNQOvoRTUDL3SA/bVXeVEwM61lJHx5dBJijDU2sxTrsh/SBw3oqWJKU0jK+Tkn2S0t7LR9g6D7s88bpuleBuM+ovyGpbj56qKM+PhHbqFYbdYpZcLsAaFODBUvzDvsKamvQZNzGEpn8Z0Xe0TuGfP6inUeu8ClHIJkopyxI1mE= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2249.eurprd07.prod.outlook.com (10.168.31.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.19; Tue, 7 May 2019 08:24:30 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2130:5ad6:fafb:c4c8]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2130:5ad6:fafb:c4c8%8]) with mapi id 15.20.1878.019; Tue, 7 May 2019 08:24:30 +0000 From: Francesca Palombini To: "cose@ietf.org" , "core@ietf.org WG" , "cbor@ietf.org" , "Ace@ietf.org" CC: Cose Chairs Wg , "core-chairs@ietf.org" , "cbor-chairs@ietf.org" , "ace-chairs@ietf.org" Thread-Topic: [Cbor] [Ace] Doodle poll for virtual interims Thread-Index: AQHVBK5K4v+s+vwmOEaJ9TA4LL9/TA== Date: Tue, 7 May 2019 08:24:30 +0000 Message-ID: <2101B222-960B-4378-9676-5A68BFE4315A@ericsson.com> 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: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0b14bdf2-b34a-4b81-74e2-08d6d2c56da2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2249; x-ms-traffictypediagnostic: HE1PR0701MB2249: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(366004)(136003)(396003)(199004)(189003)(53754006)(54896002)(66066001)(66574012)(236005)(99286004)(5660300002)(2201001)(14454004)(7736002)(256004)(14444005)(102836004)(478600001)(6486002)(6306002)(6512007)(6506007)(8936002)(790700001)(3846002)(6116002)(606006)(53546011)(6246003)(966005)(53936002)(86362001)(68736007)(2501003)(486006)(73956011)(66946007)(66476007)(66556008)(64756008)(66446008)(76116006)(2616005)(476003)(71190400001)(26005)(33656002)(316002)(8676002)(83716004)(81166006)(4326008)(186003)(81156014)(71200400001)(450100002)(54906003)(36756003)(2906002)(110136005)(25786009)(229853002)(44832011)(82746002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2249; 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: UaZAWx2boEcehQOdBjiGdfmIkO8cK96CGXgKkZqS1w911RLJMnED+4OUb08nDe59/tE+EiH3+wg7VJuc+BqrWkDg+C+vVx3jiX/HDLVYhrTenafrtYu5WY/cnrZNojXVHihkdPnINYaDp2IDDjOPXI8nn/Qd9XwBOqpzgzQW059RrsCTzCvO7d+y2l8NO+8kSSWp9DrpKckE3bFHadWWZdjfUr9VHkhXgkU+sUHgGveoKz6agbjQy2ODFa+0BBd3YxHz1RaahQmf6ksHhGmoweXXr0CMX+2sbCqB/F/8XSm0Hn0U6KmiUeNklN6uwhOjETUI4S6KiYemo9BgmpAqdbs4Njh27Fw3rcp8Kf6VnVejMF3s7A938KiPM8LLCczSMfa6jRCzW3+HwXa7YehFfaaGSplOak68kGkNNMeFA/w= Content-Type: multipart/alternative; boundary="_000_2101B222960B437896765A68BFE4315Aericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0b14bdf2-b34a-4b81-74e2-08d6d2c56da2 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 08:24:30.7155 (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: HE1PR0701MB2249 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: Tue, 07 May 2019 08:24:37 -0000 --_000_2101B222960B437896765A68BFE4315Aericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUaGFuayB5b3UgdG8gdGhvc2UgcGFydGljaXBhdGluZyBpbiB0aGUgZG9vZGxl IHBvbGwsIGFuZCB0aGFua3MgdG8gbHB3YW4gV0cgZm9yIGFkanVzdGluZyB0aGVpciBpbnRlcmlt IHRpbWUgYXJvdW5kIG91ciBwcmVmZXJyZWQgdGltZSEgVGhlIHdpbm5pbmcgdGltZXNsb3QgaXMg dGhlIDE1OjAwIOKAkyAxNjozMCBVVEMuDQoNCkFzIGEgcmVzdWx0LCBDQk9SIFdHIHdpbGwgaGF2 ZSBjb25mZXJlbmNlIGNhbGxzIGV2ZXJ5IG90aGVyIFdlZG5lc2RheSBzdGFydGluZyBNYXkgMjJu ZCwgMTU6MDAgdG8gMTY6MDAgVVRDIDogaHR0cHM6Ly93d3cuZXBvY2hjb252ZXJ0ZXIuY29tL3Rp bWV6b25lcz9xPTE1NTg1MzcyMDAmdHo9RXVyb3BlJTJGQmVybGluDQoNClRoZSBTZWNyZXRhcmlh dCB3aWxsIGFubm91bmNlIHRoZSBjYWxscyBzb29uLCBidXQgaGVyZSBpcyBhIHN1bW1hcnk6DQoN CkRheTogZXZlcnkgb3RoZXIgV2VkbmVzZGF5IGJlZ2lubmluZyBvbiBNYXkgMjJuZA0KRGF0ZXM6 ICAyMiBNYXk7IDUsIDE5IEp1bmU7IDMsIDE3LCAzMSBKdWx5OyAxNCwgMjggQXVnOyAxMSwgMjUg U2VwdDsgOSwgMjMgT2N0OyA2IE5vdg0KVGltZTogMTU6MDAgdG8gMTY6MDAgVVRDIGZvciBhbGwg ZGF0ZXMgZXhjZXB0IDYgTm92OyA2IE5vdjogMTY6MDAg4oCTIDE3OjAwIFVUQw0KDQoqKiBOb3Rl IHRoYXQgbG9jYWwgdGltZSBpbiBOQSB3aWxsIGNoYW5nZSBmb3IgdGhlIDYgTm92IG1lZXRpbmcu IExvY2FsIHRpbWUgd2lsbCBub3QgY2hhbmdlIGluIEV1cm9wZS4gKioNCg0KV2Ugd2lsbCB1c2Ug dGhlIHdvcmtpbmcgZ3JvdXAgV2ViRXggZm9yIHRoZSBjYWxscy4gIFRoZSBJRVRGIFdlYkV4DQph Y2NvdW50IGRvZXMgbm90IGFsbG93IEludGVybmF0aW9uYWwgZGlhbGxpbmcgbm9yIFVTIHRvbGwg ZnJlZSAoIjgwMCINCm51bWJlcnMpLCBidXQgeW91IGNhbiB1c2UgdGhlIFdlYkV4IGFwcCB0byBj b25uZWN0IHlvdXIgZGV2aWNlIGF1ZGlvLA0KYW5kIHRoZXJlJ3MgYWxzbyB0aGUgb3B0aW9uIG9m IGNvbm5lY3Rpb24gZGlyZWN0bHkgZnJvbSB5b3VyIGJyb3dzZXINCmlmIHlvdXIgYnJvd3NlciBz dXBwb3J0cyBpdC4NCg0KV2ViRXggZGV0YWlscyB3aWxsIGJlIHNlbnQgdG8gdGhlIG1haWxpbmcg bGlzdCBiZWZvcmUgZWFjaCBjYWxsICh0aGUNCmRldGFpbHMgd2lsbCBiZSB0aGUgc2FtZSBmb3Ig YWxsIGNhbGxzLCBidXQgdGhlIG1lc3NhZ2VzIHdpbGwgc2VydmUgYXMNCnJlbWluZGVycykuDQoN Cg0KVGhhbmtzLA0KRnJhbmNlc2NhIChhcyBDQk9SIGNoYWlyKQ0KDQpGcm9tOiBDQk9SIDxjYm9y LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFu Y2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbT4NCkRhdGU6IE1vbmRheSwgMTUgQXByaWwgMjAx OSBhdCAxNzo0NA0KVG86IENvc2UgV2cgPGNvc2VAaWV0Zi5vcmc+LCAiY29yZUBpZXRmLm9yZyBX RyIgPGNvcmVAaWV0Zi5vcmc+LCAiY2JvckBpZXRmLm9yZyIgPGNib3JAaWV0Zi5vcmc+LCBBY2Ug V2cgPEFjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ2Jvcl0gW0FjZV0gRG9vZGxlIHBvbGwg Zm9yIHZpcnR1YWwgaW50ZXJpbXMNCg0KSGksDQoNClBsZWFzZSBlbnRlciB5b3VyIGF2YWlsYWJp bGl0eSBieSB0aGlzIEZyaWRheSwgQXByaWwgMTl0aDogaHR0cHM6Ly9kb29kbGUuY29tL3BvbGwv dmU3cm55YXJlcmkya3Flcg0KDQpBcyBLbGF1cyBzYWlkLCB0aGUgdGltZSBzbG90cyBhcmUgdG8g Y2hvc2UgZm9yIHdlZWtseSBtZWV0aW5ncywgc28gZGlzcmVnYXJkIHRoZSBleGFjdCBkYXRlcyBp biB0aGUgZG9vZGxlIHBvbGwsIGJ1dCBvbmx5IGNvbnNpZGVyIHRoZSBkYXkgb2YgdGhlIHdlZWsu DQoNClRoZSBnb2FsIGlzIHRvIHJlc3RhcnQgdGhlIG1lZXRpbmdzIGJ5IHRoZSAybmQgd2VlayBv ZiBNYXksIGFuZCB3ZSBuZWVkIGEgY291cGxlIG9mIHdlZWtzIHRvIHNldCBpdCB1cCB3aXRoIHRo ZSBTZWNyZXRhcmlhdC4NCg0KQWxzbyBub3RlIHRoYXQgdGhlIHRpbWVzbG90cyBhcmUgOTAgbWlu dXRlcyBsb25nLCB0byBhbGxvdyBmb3IgbG9uZ2VyIGludGVyaW0gdGltZSBpZiBuZWVkZWQuDQoN Cg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCk9uIDEzIEFwcmlsIDIwMTkgYXQgMTY6NDc6MDIgQ0VT VCwgS2xhdXMgSGFydGtlIDxoYXJ0a2VAcHJvamVjdGNvb2wuZGU+IHdyb3RlOg0KV2UgYXJlIGxv b2tpbmcgZm9yIGEgbmV3IHRpbWUgc2xvdCBmb3IgdGhlIENvUkUvQ0JPUi9DT1NFIHZpcnR1YWwN CmludGVyaW1zIHVudGlsIElFVEYgMTA1Lg0KDQpQcm9wb3NlZCBvcHRpb25zOg0KDQo3YW0gUERU IC8gMTBhbSBFRFQgLyA0cG0gQ0VTVCAvIDExcG0gSlNUDQo4YW0gUERUIC8gMTFhbSBFRFQgLyA1 cG0gQ0VTVCAvIDEybWlkbiBKU1QNCjlhbSBQRFQgLyAxMm5vb24gRURUIC8gNnBtIENFU1QgLyAx YW0gSlNUDQoxMGFtIFBEVCAvIDFwbSBFRFQgLyA3cG0gQ0VTVCAvIDJhbSBKU1QNCg0KVGhlIGlu dGVyaW1zIGFyZSBzY2hlZHVsZWQgdG8gYmUgd2Vla2x5LCBhbHRlcm5hdGluZyBiZXR3ZWVuIENv UkUgYW5kDQpDQk9SL0NPU0UgKGFuZCBhIGRhc2ggb2YgQUNFKS4NCg0KUGxlYXNlIHVzZSB0aGlz IGRvb2RsZSBwb2xsIHRvIGluZGljYXRlIHlvdXIgcHJlZmVyZW5jZToNCmh0dHBzOi8vZG9vZGxl LmNvbS9wb2xsL3ZlN3JueWFyZXJpMmtxZXINCg0KS2xhdXMNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFjZSBtYWlsaW5nIGxpc3QNCkFjZUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg== --_000_2101B222960B437896765A68BFE4315Aericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <0DC4CFE33C912F4A81C22865BB8BA8D3@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4ubnVsbA0KCXttc28tc3R5bGUt bmFtZTpudWxsO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rIHlvdSB0byB0aG9zZSBwYXJ0aWNpcGF0aW5nIGluIHRoZSBkb29kbGUgcG9sbCwgYW5k IHRoYW5rcyB0byBscHdhbiBXRyBmb3IgYWRqdXN0aW5nIHRoZWlyIGludGVyaW0gdGltZSBhcm91 bmQgb3VyIHByZWZlcnJlZCB0aW1lISBUaGUgd2lubmluZyB0aW1lc2xvdCBpcyB0aGUgMTU6MDAg 4oCTIDE2OjMwIFVUQy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgYSByZXN1bHQsIENCT1Ig V0cgd2lsbCBoYXZlIGNvbmZlcmVuY2UgY2FsbHMgZXZlcnkgb3RoZXIgV2VkbmVzZGF5IHN0YXJ0 aW5nIE1heSAyMm5kLCAxNTowMCB0byAxNjowMCBVVEMgOg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu ZXBvY2hjb252ZXJ0ZXIuY29tL3RpbWV6b25lcz9xPTE1NTg1MzcyMDAmYW1wO3R6PUV1cm9wZSUy RkJlcmxpbiI+DQpodHRwczovL3d3dy5lcG9jaGNvbnZlcnRlci5jb20vdGltZXpvbmVzP3E9MTU1 ODUzNzIwMCZhbXA7dHo9RXVyb3BlJTJGQmVybGluPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgU2VjcmV0YXJpYXQgd2lsbCBhbm5vdW5jZSB0aGUgY2FsbHMgc29vbiwgYnV0IGhlcmUg aXMgYSBzdW1tYXJ5OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXk6IGV2ZXJ5IG90aGVyIFdl ZG5lc2RheSBiZWdpbm5pbmcgb24gTWF5IDIybmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRhdGVzOiZuYnNwOyAyMiBNYXk7IDUsIDE5IEp1bmU7IDMsIDE3LCAzMSBKdWx5 OyAxNCwgMjggQXVnOyAxMSwgMjUgU2VwdDsgOSwgMjMgT2N0OyA2IE5vdjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGltZTogMTU6MDAgdG8gMTY6MDAgVVRDIGZvciBhbGwg ZGF0ZXMgZXhjZXB0IDYgTm92OyA2IE5vdjogMTY6MDAg4oCTIDE3OjAwIFVUQzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4qKiBOb3RlIHRoYXQgbG9jYWwgdGltZSBpbiBOQSB3aWxsIGNoYW5nZSBm b3IgdGhlIDYgTm92IG1lZXRpbmcuIExvY2FsIHRpbWUgd2lsbCBub3QgY2hhbmdlIGluIEV1cm9w ZS4gKio8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugd2lsbCB1c2UgdGhlIHdvcmtpbmcgZ3Jv dXAgV2ViRXggZm9yIHRoZSBjYWxscy4mbmJzcDsgVGhlIElFVEYgV2ViRXg8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFjY291bnQgZG9lcyBub3QgYWxsb3cgSW50ZXJuYXRp b25hbCBkaWFsbGluZyBub3IgVVMgdG9sbCBmcmVlICgmcXVvdDs4MDAmcXVvdDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm51bWJlcnMpLCBidXQgeW91IGNhbiB1c2UgdGhl IFdlYkV4IGFwcCB0byBjb25uZWN0IHlvdXIgZGV2aWNlIGF1ZGlvLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIHRoZXJlJ3MgYWxzbyB0aGUgb3B0aW9uIG9mIGNvbm5l Y3Rpb24gZGlyZWN0bHkgZnJvbSB5b3VyIGJyb3dzZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmlmIHlvdXIgYnJvd3NlciBzdXBwb3J0cyBpdC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2ViRXggZGV0YWlscyB3aWxsIGJlIHNlbnQgdG8gdGhlIG1haWxpbmcgbGlzdCBi ZWZvcmUgZWFjaCBjYWxsICh0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmRldGFpbHMgd2lsbCBiZSB0aGUgc2FtZSBmb3IgYWxsIGNhbGxzLCBidXQgdGhlIG1lc3NhZ2Vz IHdpbGwgc2VydmUgYXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlbWlu ZGVycykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+RnJhbmNlc2NhIChhcyBDQk9SIGNoYWlyKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+Q0JPUiAmbHQ7Y2Jvci1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBi ZWhhbGYgb2YgRnJhbmNlc2NhIFBhbG9tYmluaSAmbHQ7ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmlj c3Nvbi5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgMTUgQXByaWwgMjAxOSBhdCAx Nzo0NDxicj4NCjxiPlRvOiA8L2I+Q29zZSBXZyAmbHQ7Y29zZUBpZXRmLm9yZyZndDssICZxdW90 O2NvcmVAaWV0Zi5vcmcgV0cmcXVvdDsgJmx0O2NvcmVAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtjYm9y QGlldGYub3JnJnF1b3Q7ICZsdDtjYm9yQGlldGYub3JnJmd0OywgQWNlIFdnICZsdDtBY2VAaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbQ2Jvcl0gW0FjZV0gRG9vZGxlIHBv bGwgZm9yIHZpcnR1YWwgaW50ZXJpbXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBlbnRlciB5b3VyIGF2YWlsYWJpbGl0eSBieSB0 aGlzIEZyaWRheSwgQXByaWwgMTl0aDombmJzcDtodHRwczovL2Rvb2RsZS5jb20vcG9sbC92ZTdy bnlhcmVyaTJrcWVyJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFzIEtsYXVzIHNhaWQsIHRoZSB0aW1lIHNsb3RzIGFyZSB0byBjaG9z ZSBmb3Igd2Vla2x5IG1lZXRpbmdzLCBzbyBkaXNyZWdhcmQgdGhlIGV4YWN0IGRhdGVzIGluIHRo ZSBkb29kbGUgcG9sbCwgYnV0IG9ubHkgY29uc2lkZXIgdGhlIGRheSBvZiB0aGUgd2Vlay48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGdv YWwgaXMgdG8gcmVzdGFydCB0aGUgbWVldGluZ3MgYnkgdGhlIDJuZCB3ZWVrIG9mIE1heSwgYW5k IHdlIG5lZWQgYSBjb3VwbGUgb2Ygd2Vla3MgdG8gc2V0IGl0IHVwIHdpdGggdGhlIFNlY3JldGFy aWF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BbHNvIG5vdGUgdGhhdCB0aGUgdGltZXNsb3RzIGFyZSA5MCBtaW51dGVzIGxvbmcsIHRvIGFs bG93IGZvciBsb25nZXIgaW50ZXJpbSB0aW1lIGlmIG5lZWRlZC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpUaGFua3MsIDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyYW5jZXNjYTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiAxMyBBcHJpbCAyMDE5IGF0IDE2OjQ3OjAyIENFU1QsIEtsYXVzIEhh cnRrZSAmbHQ7aGFydGtlQHByb2plY3Rjb29sLmRlJmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA4LjBwdDttYXJnaW4tbGVmdDow Y207bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhcmUgbG9va2luZyBmb3IgYSBu ZXcgdGltZSBzbG90IGZvciB0aGUgQ29SRS9DQk9SL0NPU0UgdmlydHVhbDxicj4NCmludGVyaW1z IHVudGlsIElFVEYgMTA1Ljxicj4NCjxicj4NClByb3Bvc2VkIG9wdGlvbnM6PGJyPg0KPGJyPg0K N2FtIFBEVCAvIDEwYW0gRURUIC8gNHBtIENFU1QgLyAxMXBtIEpTVDxicj4NCjhhbSBQRFQgLyAx MWFtIEVEVCAvIDVwbSBDRVNUIC8gMTJtaWRuIEpTVDxicj4NCjlhbSBQRFQgLyAxMm5vb24gRURU IC8gNnBtIENFU1QgLyAxYW0gSlNUPGJyPg0KMTBhbSBQRFQgLyAxcG0gRURUIC8gN3BtIENFU1Qg LyAyYW0gSlNUPGJyPg0KPGJyPg0KVGhlIGludGVyaW1zIGFyZSBzY2hlZHVsZWQgdG8gYmUgd2Vl a2x5LCBhbHRlcm5hdGluZyBiZXR3ZWVuIENvUkUgYW5kPGJyPg0KQ0JPUi9DT1NFIChhbmQgYSBk YXNoIG9mIEFDRSkuPGJyPg0KPGJyPg0KUGxlYXNlIHVzZSB0aGlzIGRvb2RsZSBwb2xsIHRvIGlu ZGljYXRlIHlvdXIgcHJlZmVyZW5jZTo8YnI+DQo8YSBocmVmPSJodHRwczovL2Rvb2RsZS5jb20v cG9sbC92ZTdybnlhcmVyaTJrcWVyIiB0YXJnZXQ9Il9CTEFOSyI+aHR0cHM6Ly9kb29kbGUuY29t L3BvbGwvdmU3cm55YXJlcmkya3FlcjwvYT48YnI+DQo8YnI+DQpLbGF1czxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQWNlIG1h aWxpbmcgbGlzdDxicj4NCkFjZUBpZXRmLm9yZzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlIiB0YXJnZXQ9Il9CTEFOSyI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_2101B222960B437896765A68BFE4315Aericssoncom_-- From nobody Tue May 7 10:17:24 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B337C120004; Tue, 7 May 2019 10:17:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155724943556.21070.13235416586496990339@ietfa.amsl.com> Date: Tue, 07 May 2019 10:17:15 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-05-22 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 17:17:16 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2019-05-22 from 15:00 to 16:00 UTC. Agenda: (No agenda submitted) Information about remote participation: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). The CBOR working group will have conference calls running every two weeks through the beginning of November 2019 (basically, until IETF 106 in Singapore). Day: every other Wednesday beginning on May 22nd Dates: 22 May; 5, 19 June; 3, 17, 31 July; 14, 28 Aug; 11, 25 Sept; 9, 23 Oct; 6 Nov Time: 15:00 to 16:00 UTC for all dates except 6 Nov; 6 Nov: 16:00 – 17:00 UTC Note that local time in NA will change for the 6 Nov meeting, but will not change in Europe. From nobody Tue May 7 10:17:49 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E668112021D; Tue, 7 May 2019 10:17:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155724945388.21189.2206768009715177824@ietfa.amsl.com> Date: Tue, 07 May 2019 10:17:33 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-06-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 17:17:41 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2019-06-05 from 15:00 to 16:00 UTC. Agenda: (No agenda submitted) Information about remote participation: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). The CBOR working group will have conference calls running every two weeks through the beginning of November 2019 (basically, until IETF 106 in Singapore). Day: every other Wednesday beginning on May 22nd Dates: 22 May; 5, 19 June; 3, 17, 31 July; 14, 28 Aug; 11, 25 Sept; 9, 23 Oct; 6 Nov Time: 15:00 to 16:00 UTC for all dates except 6 Nov; 6 Nov: 16:00 – 17:00 UTC Note that local time in NA will change for the 6 Nov meeting, but will not change in Europe. From nobody Tue May 7 10:18:03 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 795BC120252; Tue, 7 May 2019 10:17:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155724947445.21144.18411054597619257520@ietfa.amsl.com> Date: Tue, 07 May 2019 10:17:54 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-06-19 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 17:18:01 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2019-06-19 from 15:00 to 16:00 UTC. Agenda: (No agenda submitted) Information about remote participation: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). The CBOR working group will have conference calls running every two weeks through the beginning of November 2019 (basically, until IETF 106 in Singapore). Day: every other Wednesday beginning on May 22nd Dates: 22 May; 5, 19 June; 3, 17, 31 July; 14, 28 Aug; 11, 25 Sept; 9, 23 Oct; 6 Nov Time: 15:00 to 16:00 UTC for all dates except 6 Nov; 6 Nov: 16:00 – 17:00 UTC Note that local time in NA will change for the 6 Nov meeting, but will not change in Europe. From nobody Tue May 7 10:18:21 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AEE1201E2; Tue, 7 May 2019 10:18:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155724949276.21111.12911196203303298906@ietfa.amsl.com> Date: Tue, 07 May 2019 10:18:12 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-07-03 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 17:18:19 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2019-07-03 from 15:00 to 16:00 UTC. Agenda: (No agenda submitted) Information about remote participation: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). The CBOR working group will have conference calls running every two weeks through the beginning of November 2019 (basically, until IETF 106 in Singapore). Day: every other Wednesday beginning on May 22nd Dates: 22 May; 5, 19 June; 3, 17, 31 July; 14, 28 Aug; 11, 25 Sept; 9, 23 Oct; 6 Nov Time: 15:00 to 16:00 UTC for all dates except 6 Nov; 6 Nov: 16:00 – 17:00 UTC Note that local time in NA will change for the 6 Nov meeting, but will not change in Europe. From nobody Tue May 7 10:18:43 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A63B1202DE; Tue, 7 May 2019 10:18:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155724950705.21221.3729423368895770136@ietfa.amsl.com> Date: Tue, 07 May 2019 10:18:27 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-07-17 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 17:18:33 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2019-07-17 from 15:00 to 16:00 UTC. Agenda: (No agenda submitted) Information about remote participation: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). The CBOR working group will have conference calls running every two weeks through the beginning of November 2019 (basically, until IETF 106 in Singapore). Day: every other Wednesday beginning on May 22nd Dates: 22 May; 5, 19 June; 3, 17, 31 July; 14, 28 Aug; 11, 25 Sept; 9, 23 Oct; 6 Nov Time: 15:00 to 16:00 UTC for all dates except 6 Nov; 6 Nov: 16:00 – 17:00 UTC Note that local time in NA will change for the 6 Nov meeting, but will not change in Europe. From nobody Tue May 7 10:18:55 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3231202DE; Tue, 7 May 2019 10:18:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155724952358.21213.6634341556459171425@ietfa.amsl.com> Date: Tue, 07 May 2019 10:18:43 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-07-31 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 17:18:48 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2019-07-31 from 15:00 to 16:00 UTC. Agenda: (No agenda submitted) Information about remote participation: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). The CBOR working group will have conference calls running every two weeks through the beginning of November 2019 (basically, until IETF 106 in Singapore). Day: every other Wednesday beginning on May 22nd Dates: 22 May; 5, 19 June; 3, 17, 31 July; 14, 28 Aug; 11, 25 Sept; 9, 23 Oct; 6 Nov Time: 15:00 to 16:00 UTC for all dates except 6 Nov; 6 Nov: 16:00 – 17:00 UTC Note that local time in NA will change for the 6 Nov meeting, but will not change in Europe. From nobody Tue May 7 10:19:10 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7124F1202EF; Tue, 7 May 2019 10:18:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155724953643.21074.1111377926967646800@ietfa.amsl.com> Date: Tue, 07 May 2019 10:18:56 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-08-14 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 17:19:02 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2019-08-14 from 15:00 to 16:00 UTC. Agenda: (No agenda submitted) Information about remote participation: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). The CBOR working group will have conference calls running every two weeks through the beginning of November 2019 (basically, until IETF 106 in Singapore). Day: every other Wednesday beginning on May 22nd Dates: 22 May; 5, 19 June; 3, 17, 31 July; 14, 28 Aug; 11, 25 Sept; 9, 23 Oct; 6 Nov Time: 15:00 to 16:00 UTC for all dates except 6 Nov; 6 Nov: 16:00 – 17:00 UTC Note that local time in NA will change for the 6 Nov meeting, but will not change in Europe. From nobody Tue May 7 10:19:31 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00870120281; Tue, 7 May 2019 10:19:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155724955494.21205.13583718592865131275@ietfa.amsl.com> Date: Tue, 07 May 2019 10:19:14 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-08-28 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 17:19:19 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2019-08-28 from 15:00 to 16:00 UTC. Agenda: (No agenda submitted) Information about remote participation: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). The CBOR working group will have conference calls running every two weeks through the beginning of November 2019 (basically, until IETF 106 in Singapore). Day: every other Wednesday beginning on May 22nd Dates: 22 May; 5, 19 June; 3, 17, 31 July; 14, 28 Aug; 11, 25 Sept; 9, 23 Oct; 6 Nov Time: 15:00 to 16:00 UTC for all dates except 6 Nov; 6 Nov: 16:00 – 17:00 UTC Note that local time in NA will change for the 6 Nov meeting, but will not change in Europe. From nobody Tue May 7 10:19:44 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15158120291; Tue, 7 May 2019 10:19:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155724957103.21197.14676457034766590333@ietfa.amsl.com> Date: Tue, 07 May 2019 10:19:31 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-09-11 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 17:19:36 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2019-09-11 from 15:00 to 16:00 UTC. Agenda: (No agenda submitted) Information about remote participation: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). The CBOR working group will have conference calls running every two weeks through the beginning of November 2019 (basically, until IETF 106 in Singapore). Day: every other Wednesday beginning on May 22nd Dates: 22 May; 5, 19 June; 3, 17, 31 July; 14, 28 Aug; 11, 25 Sept; 9, 23 Oct; 6 Nov Time: 15:00 to 16:00 UTC for all dates except 6 Nov; 6 Nov: 16:00 – 17:00 UTC Note that local time in NA will change for the 6 Nov meeting, but will not change in Europe. From nobody Tue May 7 10:20:02 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D79120235; Tue, 7 May 2019 10:19:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155724958628.21140.13173265259109871998@ietfa.amsl.com> Date: Tue, 07 May 2019 10:19:46 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-09-25 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 17:19:53 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2019-09-25 from 15:00 to 16:00 UTC. Agenda: (No agenda submitted) Information about remote participation: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). The CBOR working group will have conference calls running every two weeks through the beginning of November 2019 (basically, until IETF 106 in Singapore). Day: every other Wednesday beginning on May 22nd Dates: 22 May; 5, 19 June; 3, 17, 31 July; 14, 28 Aug; 11, 25 Sept; 9, 23 Oct; 6 Nov Time: 15:00 to 16:00 UTC for all dates except 6 Nov; 6 Nov: 16:00 – 17:00 UTC Note that local time in NA will change for the 6 Nov meeting, but will not change in Europe. From nobody Tue May 7 10:20:11 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1473312029D; Tue, 7 May 2019 10:20:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155724960403.21087.3434197692824395293@ietfa.amsl.com> Date: Tue, 07 May 2019 10:20:04 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-10-09 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 17:20:10 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2019-10-09 from 15:00 to 16:00 UTC. Agenda: (No agenda submitted) Information about remote participation: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). The CBOR working group will have conference calls running every two weeks through the beginning of November 2019 (basically, until IETF 106 in Singapore). Day: every other Wednesday beginning on May 22nd Dates: 22 May; 5, 19 June; 3, 17, 31 July; 14, 28 Aug; 11, 25 Sept; 9, 23 Oct; 6 Nov Time: 15:00 to 16:00 UTC for all dates except 6 Nov; 6 Nov: 16:00 – 17:00 UTC Note that local time in NA will change for the 6 Nov meeting, but will not change in Europe. From nobody Tue May 7 10:20:26 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0CA1202EE; Tue, 7 May 2019 10:20:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155724962126.21082.11041037733940819675@ietfa.amsl.com> Date: Tue, 07 May 2019 10:20:21 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-10-23 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 17:20:25 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2019-10-23 from 15:00 to 16:00 UTC. Agenda: (No agenda submitted) Information about remote participation: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). The CBOR working group will have conference calls running every two weeks through the beginning of November 2019 (basically, until IETF 106 in Singapore). Day: every other Wednesday beginning on May 22nd Dates: 22 May; 5, 19 June; 3, 17, 31 July; 14, 28 Aug; 11, 25 Sept; 9, 23 Oct; 6 Nov Time: 15:00 to 16:00 UTC for all dates except 6 Nov; 6 Nov: 16:00 – 17:00 UTC Note that local time in NA will change for the 6 Nov meeting, but will not change in Europe. From nobody Tue May 7 10:20:45 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89555120224; Tue, 7 May 2019 10:20:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155724963651.21209.6500182663289971990@ietfa.amsl.com> Date: Tue, 07 May 2019 10:20:36 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-11-06 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 17:20:43 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2019-11-06 from 16:00 to 17:00 UTC. Agenda: (No agenda submitted) Information about remote participation: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). The CBOR working group will have conference calls running every two weeks through the beginning of November 2019 (basically, until IETF 106 in Singapore). Day: every other Wednesday beginning on May 22nd Dates: 22 May; 5, 19 June; 3, 17, 31 July; 14, 28 Aug; 11, 25 Sept; 9, 23 Oct; 6 Nov Time: 15:00 to 16:00 UTC for all dates except 6 Nov; 6 Nov: 16:00 – 17:00 UTC Note that local time in NA will change for the 6 Nov meeting, but will not change in Europe. From nobody Tue May 7 10:28:21 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 039AA12022A for ; Tue, 7 May 2019 10:28:13 -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 X9qbgLLr69Mp for ; Tue, 7 May 2019 10:28:09 -0700 (PDT) Received: from p3plsmtpa06-02.prod.phx3.secureserver.net (p3plsmtpa06-02.prod.phx3.secureserver.net [173.201.192.103]) (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 A3CA6120255 for ; Tue, 7 May 2019 10:28:08 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id O3srh6Mtev3PHO3sshBBWs; Tue, 07 May 2019 10:28:06 -0700 From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_58C2AEB8-709C-416B-9118-8C2AB94CE181" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 7 May 2019 10:28:04 -0700 In-Reply-To: Cc: Felipe Gasper , cbor@ietf.org To: Carsten Bormann References: <8269CD1C-B024-4961-A889-C8543502596A@felipegasper.com> X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfIxo6gXfTZzjrn8peuD+sCy/7sbnE8kVtUm6FLZddjWulTaIbi5tzGn7KQZ3AjunIzChzNzrGBqUAN7x3PIv2uBUXML6b0d+y4SBkwZsB4AvDAig3sUb rl56VP7Pcq1JgGPPwdIc/M2iQJHvS5OHruxQrn4T2aUiX7HDp//WCE5YI6cE0qnhwolXp704VkyEvgs1jilzWbn/7exp+Gzx+1C+qxmvqTlBtLfVDHFhiT9h 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: Tue, 07 May 2019 17:28:18 -0000 --Apple-Mail=_58C2AEB8-709C-416B-9118-8C2AB94CE181 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here=E2=80=99s two examples of places where the types of map keys are = restricted. COSE Section 1.4 has this CDDL limiting labels to integers and text strings: label =3D int / tstr JSON JSON =E2=80=9Cnames=E2=80=9D (=E2=80=9Ckeys" in CBOR) can only be = strings so any CBOR that translates has to limit keys. I didn=E2=80=99t see any discussion of this in Appendix E in = draft-ietf-cbor-cddl-08.txt. This seems important, at least to me for = the EAT/RATS work where we want to use CDDL to describe both CBOR and = JSON encodings. In particular we=E2=80=99d like to use integer keys in = the CBOR encoding and need to resolve how that gets expressed in JSON. It would be helpful to me to see more compelling real world examples of = keys as arrays or maps. It seems like a cool thing to do in some ways, = but in others it seems like a jump in complexity that should only be = used if really necessary. LL > On Apr 29, 2019, at 7:02 AM, Carsten Bormann wrote: >=20 > 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 >=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. >=20 >> 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 > There is no such intention. >=20 > 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. >=20 > 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. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_58C2AEB8-709C-416B-9118-8C2AB94CE181 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Here=E2=80=99s two examples of places where the types of map = keys are restricted.

COSE
Section 1.4 has = this CDDL limiting labels to integers and text strings:

   label =3D int / tstr

JSON
JSON =E2=80=9Cnames=E2=80=9D (=E2=80=9Ckeys" in CBOR) can = only be strings so any CBOR that translates has to limit keys.

I didn=E2=80=99t see any = discussion of this in Appendix E in draft-ietf-cbor-cddl-08.txt. This = seems important, at least to me for the EAT/RATS work where we want to = use CDDL to describe both CBOR and JSON encodings. In particular we=E2=80=99= d like to use integer keys in the CBOR encoding and need to resolve how = that gets expressed in JSON.


It = would be helpful to me to see more compelling real world examples of = keys as arrays or maps. It seems like a cool thing to do in some ways, = but in others it seems like a jump in complexity that should only be = used if really necessary.

LL


On Apr 29, 2019, at 7:02 AM, = Carsten Bormann <cabo@tzi.org> wrote:

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

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.

Well, it doesn=E2=80=99= t 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-

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?

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

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

= --Apple-Mail=_58C2AEB8-709C-416B-9118-8C2AB94CE181-- From nobody Tue May 7 22:09: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 5186D120134 for ; Tue, 7 May 2019 22:09:01 -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 m7PDAwIY61Fe for ; Tue, 7 May 2019 22:08:59 -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 1DD55120125 for ; Tue, 7 May 2019 22:08:59 -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 44zPdj1BcVzyZn; Wed, 8 May 2019 07:08:57 +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: Date: Wed, 8 May 2019 07:08:56 +0200 Cc: Felipe Gasper , cbor@ietf.org X-Mao-Original-Outgoing-Id: 578984934.596411-379f47026fad60865654f8e815f8839a Content-Transfer-Encoding: quoted-printable Message-Id: <09F591CD-F472-47B7-A3A7-F3B2D6A50846@tzi.org> References: <8269CD1C-B024-4961-A889-C8543502596A@felipegasper.com> To: Laurence Lundblade 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: Wed, 08 May 2019 05:09:01 -0000 Hi Laurence, > On May 7, 2019, at 19:28, Laurence Lundblade = wrote: >=20 > Here=E2=80=99s two examples of places where the types of map keys are = restricted. >=20 > COSE > Section 1.4 has this CDDL limiting labels to integers and text = strings: >=20 > label =3D int / tstr >=20 > JSON > JSON =E2=80=9Cnames=E2=80=9D (=E2=80=9Ckeys" in CBOR) can only be = strings so any CBOR that translates has to limit keys. >=20 > I didn=E2=80=99t see any discussion of this in Appendix E in = draft-ietf-cbor-cddl-08.txt. This seems important, at least to me for = the EAT/RATS work where we want to use CDDL to describe both CBOR and = JSON encodings. In particular we=E2=80=99d like to use integer keys in = the CBOR encoding and need to resolve how that gets expressed in JSON. Please have a look at RFC 8428 for an example how CDDL can be used for = such a protocol (apart from switching the labels, we also had to solve = encoding SenML byte string data values in base64url text strings for = JSON and byte strings for CBOR). I think CDDL 2.0 should have some common conventions for specifications = that serialize both to JSON and CBOR; in RFC 8428 the =E2=80=9Cswitching = in=E2=80=9D of the relevant part was done in English. Ultimately, tools such as = https://github.com/core-wg/senml-spec/blob/master/senml-json2cbor.rb = should be fully generatable from such a specification (the current tool = does make use of the salient part of the CDDL =E2=80=94 see lines 65 to = 72 =E2=80=94 but still needs manual programming to apply it in the right = places). > It would be helpful to me to see more compelling real world examples = of keys as arrays or maps. It seems like a cool thing to do in some = ways, but in others it seems like a jump in complexity that should only = be used if really necessary. Containers as map keys make sense exactly where the application = semantics call for it. The use of containers as keys in what CDDL calls =E2=80=9Cstruct=E2=80=9D = usage (Section 2) is probably rare, but does exist: I have seen = specifications that use arrays (in =E2=80=9Crecord=E2=80=9D usage) to = represent XML qualified names, which are perfectly usable map keys. For = =E2=80=9Ctable=E2=80=9D usage, containers as keys are quite natural. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 8 09:38:00 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 AEBF812016F for ; Wed, 8 May 2019 09:37:58 -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] 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 OQiGyWI-W9o3 for ; Wed, 8 May 2019 09:37:56 -0700 (PDT) Received: from p3plsmtpa06-06.prod.phx3.secureserver.net (p3plsmtpa06-06.prod.phx3.secureserver.net [173.201.192.107]) (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 B950D12015B for ; Wed, 8 May 2019 09:37:56 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id OPZqh1M4hiuL7OPZrhn6bp; Wed, 08 May 2019 09:37:56 -0700 From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_94BF20D5-BDA4-4AD2-8F11-741810CC2192" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Wed, 8 May 2019 09:37:54 -0700 To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfOITa8dxsbvxzOxdPSv4/m3cJTS4q1FHStyXp5qtiJAwwlvlbfnxMd/+2BVYIQxM2auU1Aa9EFU2zm173VlYRL4p4QflX49Mw8S/PFXphApBgPFcjOCD twcA9+6HDQpNUaIl0vm0+KkK6zYMofVeLjyTS1lxuOi++ZKrV6yCRmwo Archived-At: Subject: [Cbor] Handling Endianness with CBOR Tagged Arrays 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, 08 May 2019 16:37:59 -0000 --Apple-Mail=_94BF20D5-BDA4-4AD2-8F11-741810CC2192 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Was thinking about how to ensure interoperability with tagged arrays = given the divergence from requiring network byte order. I came up with = this text that might go into some document. LL Handling Endianness with CBOR Tagged Arrays Every CBOR protocol using tagged arrays must specify how endianness is = handled or there will be interoperability problems. The following are = five options, that last of which is not recommended. 1) Default to little-endian By not specifying anything, the default of little-endian is taken. This is a pretty good option for many protocols as such a large = proportion of CPUs today are little-endian. 2) Specify the endianness Here the protocol explicitly defines whether big or little endian is to = be used. This is a static definition for every implementation of the = protocol and it is incorrect to use other than what is defined. This is only necessary when big-endian is the only endianness allowed. = Given how few CPUs support big endian, use of this is likely to be rare = as it will force the performance and likely memory penalty on the CPUs = the are little-endian. 3) Asymmetric=20 Here one side of the protocol, typically the constrained side, sends = whatever it wants. It tells the other side what it is going to send and = receive. The other side, typically the server, must be able to receive = and send both big and little-endian. The constrained side can tell the server side by something explicit in = the protocol, or if the flow of the protocol has the constrained side = sending the first message with a tagged array, that can be the = indicator. This is the best option to accommodate constrained devices and keep code = size down. 4) Step-up Both sides are required to implement a base endianness specified by the = particular CBOR protocol. Then, there is a negotiation to step up to a = preferred endianness if both support it and prefer it.=20 This is may not keep code size down, but it can enhance performance as = endian conversion can be avoided. It may also reduce memory use, = especially on CPUs that can performed unaligned access. The arrays can = be read and written directly from memory to the network. 5) Negotiation One side of the protocol can send a list of which endianness it = supports. The other side picks the one in the list it prefers and tells = the first side. Note that this can fail to interop and is not = recommended. Basically, both sides have to agree to implement one specific = endianness, or one side has to agree to implement both. Interop can fail = if both sides just do what they want. --Apple-Mail=_94BF20D5-BDA4-4AD2-8F11-741810CC2192 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Was thinking about how to ensure interoperability with tagged = arrays given the divergence from requiring network byte order. I came up = with this text that might go into some document.

LL


Handling = Endianness with CBOR Tagged Arrays

Every CBOR protocol using tagged arrays = must specify how endianness is handled or there will be interoperability = problems. The following are five options, that last of which is not = recommended.

1) Default to little-endian
By not = specifying anything, the default of little-endian is taken.

This is a pretty good = option for many protocols as such a large proportion of CPUs today are = little-endian.

2) Specify the endianness
Here the = protocol explicitly defines whether big or little endian is to be used. = This is a static definition for every implementation of the protocol and = it is incorrect to use other than what is defined.

This is only necessary = when big-endian is the only endianness allowed. Given how few CPUs = support big endian, use of this is likely to be rare as it will force = the performance and likely memory penalty on the CPUs the are = little-endian.

3) Asymmetric 
Here one side of the = protocol, typically the constrained side, sends whatever it wants. It = tells the other side what it is going to send and receive. The other = side, typically the server, must be able to receive and send both big = and little-endian.

The constrained side can tell the server side by something = explicit in the protocol, or if the flow of the protocol has the = constrained side sending the first message with a tagged array, that can = be the indicator.

This is the best option to accommodate constrained devices = and keep code size down.

4) Step-up
Both sides are required to = implement a base endianness specified by the particular CBOR protocol. = Then, there is a negotiation to step up to a preferred endianness if = both support it and prefer it. 

This is may not keep code size down, = but it can enhance performance as endian conversion can be avoided. It = may also reduce memory use, especially on CPUs that can performed = unaligned access. The arrays can be read and written directly from = memory to the network.

5) Negotiation
One side of the protocol = can send a list of which endianness it supports. The other side picks = the one in the list it prefers and tells the first side. Note that this = can fail to interop and is not recommended.

Basically, both sides = have to agree to implement one specific endianness, or one side has to = agree to implement both. Interop can fail if both sides just do what = they want.

= --Apple-Mail=_94BF20D5-BDA4-4AD2-8F11-741810CC2192-- From nobody Tue May 14 19:57:01 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 17324120232; Tue, 14 May 2019 19:56:59 -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 2sqO1DRbcIkJ; Tue, 14 May 2019 19:56:57 -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 2B22C1201D0; Tue, 14 May 2019 19:56:54 -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; Tue, 14 May 2019 19:56:48 -0700 From: Jim Schaad To: CC: Date: Tue, 14 May 2019 19:56:45 -0700 Message-ID: <01f201d50ac9$d6b1abd0$84150370$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdUKwjido9sWYy7KRCib8Io9670liQ== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Review of draft-bormann-cbor-sequence 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, 15 May 2019 02:57:00 -0000 1. Introduction: I think that I need a little bit more description of what you consider to be a streaming parse/encoder. At a minimum one would potentially need to the ability to run a parser and recover from an error where not enough bytes exist to try again after more bytes show up. To me that is a variant of a streaming parser. 2. Section 2 - Definition of a CBOR Sequence: This took me a couple of times to realize that this was being defined in a recursive manner. I think that making this more explicit would be good. 3. Section 2 - I think that I would remove the parenthesis in the third paragraph. This is almost the entire paragraph. 4. Section 2 - For second decoding bullet. This is describing a single pass decoding, it is probably worth describing a streaming decoding at this point as well. 5. Section 2 - A program, not the decoder, may also be able to recover by decoding individual fields looking for a pattern that matches an expected structure. As an example, looking for a byte which corresponds to an array of 3 items and then test decoding to see if it works and continue from that point. 6. Section 2 - The phrase "truncation of the last" to me reads as the same as the last data item is missing. A better term might be "truncation inside of the last" as that implies it is inside of the last item and not the last item in its entirety. It may also be worth while to note that this is only true with known fixed length inputs and not with streamed input. 7. Section 3 - The first paragraph starting with "It SHOULD" does not scan. Please re-write 8. Section 2 - It may be worthwhile to explicitly state that there is no end of record indicator as well. This is implied but not explicitly said. Jim From nobody Thu May 16 15:33:00 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 DE601120303 for ; Thu, 16 May 2019 15:32:58 -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 pXz8E1Ap2rAh for ; Thu, 16 May 2019 15:32:56 -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 4751B1200C7 for ; Thu, 16 May 2019 15:32:56 -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; Thu, 16 May 2019 15:32:50 -0700 From: Jim Schaad To: Date: Thu, 16 May 2019 15:32:48 -0700 Message-ID: <032801d50c37$4b8a3120$e29e9360$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdUMNvx+utiu9f6DTDG4DK5fEMrymQ== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Charter update 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: Thu, 16 May 2019 22:32:59 -0000 Francesca and I have gotten together and cobbled together a revised charter for the working group. I have created a github project https://github.com/cbor-wg/charter for editing of the charter. We will monitor the mailing list as well and create pull requests from that, but feel free to create your own. Here is a copy Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 7159) data interchange format to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., CORE, ANIMA GRASP) as a message format. The CBOR working group will update RFC 7049 to fix verified errata. Security issues and clarifications may be addressed, but changes to the document will ensure backward compatibility for popular deployed codebases. The resulting document will be targeted at becoming a Full Internet Standard. After that, the CBOR working group will monitor issues found with the CBOR specification and, if needed, will produce an updated document. Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of valid messages in a text representation, it is useful for protocol specifications to use a description format for the data in CBOR-encoded messages. The Concise Data Definition Language (CDDL) is such a description technique that has already been used in CORE, ANIMA, CDNI, and efforts outside the IETF. The first version of CDDL has been published as RFC XXXX. While this version has been completed, several new features were raised during the update process that were not included in this version, in order not to delay publication, and to allow publication in the Standards Track. One example of such a feature is the ability to combine multiple CDDL files together using a mechanism other that manually concatenating them together for processing. The working group will collect these features as well as other features that are raised by users of CDDL, evaluate their utility and add to a second version of the specification if warranted. The working group will evaluate the necessity of providing advice and guidance for developers using CBOR and CDDL. It is currently expected that this would be done using a Wiki of some type. This work would not be expected to be published by the IETF. There are a number of extensions to CBOR types that are either currently adopted by the working group, other working groups, or individual submissions. Additionally, there are expected to be other such documents that will come to the attention of the working group. In some cases the working group expects to adopt and publish these proposals. The working group will evaluate and place proposals in one of the following categories using a dispatch like process: * General purpose extensions that are expected to have broad usage: The working group will normally adopt and publish such proposals. Examples of proposals in this category are CBOR Sequence (draft-bormann-cbor-sequence) and Error Indications (draft-richter-cbor-error-tag). * Internet wide specific purpose extensions: The working group may decide to adopt these proposals, but typically it would just provide input and recommend that they be published either as an Independent Submission or by a different working group. * Narrow purpose extensions: The working group may provide evaluation of such proposals, but typically would not support Working Group adoption, and could recommend publication in a different forum. An example of this might be portions of draft-bormann-cbor-tags-oid dealing with some of the more esoteric types such as regular expressions From nobody Thu May 16 16:20:35 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 6CF9A12036D for ; Thu, 16 May 2019 16:20: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 0qgiJFXcrjqh for ; Thu, 16 May 2019 16:20:09 -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 7C217120353 for ; Thu, 16 May 2019 16:20:09 -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 454nT24NDNzyQp; Fri, 17 May 2019 01:20:06 +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: <032801d50c37$4b8a3120$e29e9360$@augustcellars.com> Date: Fri, 17 May 2019 01:20:06 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 579741603.71223-af9989bccd29b71dc6a58f4f9a250edc Content-Transfer-Encoding: quoted-printable Message-Id: <9DD06B37-5EF4-40A1-B14D-C44D5F0C995A@tzi.org> References: <032801d50c37$4b8a3120$e29e9360$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Charter update 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: Thu, 16 May 2019 23:20:17 -0000 Hi Jim, thank you (the chairs) for taking this initiative. I still have to read the whole thing, but I already experience one heavy = knee jerk: > On May 17, 2019, at 00:32, Jim Schaad wrote: >=20 > extensions to CBOR types I don=E2=80=99t think we should say that we are =E2=80=9Cextending=E2=80=9D= CBOR=E2=80=A6 Yes, we are exercising its extensibility points, but the result are new = (or updated) CBOR Tags, not really extensions to CBOR itself. (I=E2=80=99m trying separate CBOR the standard from the greater CBOR = ecosystem, which includes the Tag definitions.) (We *are* extending CDDL. I hope.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri May 17 04:21:29 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D06DD12006F; Fri, 17 May 2019 04:21:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: cbor@ietf.org, cbor-chairs@ietf.org, francesca.palombini@ericsson.com, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155809208681.14846.7261717832739170876.idtracker@ietfa.amsl.com> Date: Fri, 17 May 2019 04:21:26 -0700 Archived-At: Subject: [Cbor] cbor - New Meeting Session Request for IETF 105 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 11:21:27 -0000 A new meeting session request has just been submitted by Francesca Palombini, a Chair of the cbor working group. --------------------------------------------------------- Working Group Name: Concise Binary Object Representation Maintenance and Extensions Area Name: Applications and Real-Time Area Session Requester: Francesca Palombini Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: saag ace core lamps cose Second Priority: emu cfrg secdispatch tls t2trg suit oauth rats Third Priority: anima teep 6tisch curdle httpbis dtn dots People who must be present: Carsten Bormann Alexey Melnikov Jim Schaad Francesca Palombini Resources Requested: Special Requests: Please avoid collision with any Sec and IoT-related BoFs Please avoid collision with lake (Lightweight AKE) --------------------------------------------------------- From nobody Fri May 17 04:26:14 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 D0FEA120092; Fri, 17 May 2019 04:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_DKIMWL_WL_HIGH=-0.01] 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 BGCbZynq2M52; Fri, 17 May 2019 04:26:10 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80077.outbound.protection.outlook.com [40.107.8.77]) (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 6986A120048; Fri, 17 May 2019 04:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NVl1RHB+qvB1JaM4u83iu+Kkla9LHyw6GWmiH8xWA+0=; b=jKR116FIB6iFuSSh6GdDVuRjDILHTNJr508i8qf+5yKS8n8HFXb5afV6uKxJkG/SThIetU1GT0Fse27pwle/MEwOZblvMrsaUeq/K5oG0LyQ2LkwjdG+zoIfplvre16SShPPEZdxp6pjD2hCxX3LzQc+yrapipLDsLl1n3V7Ei0= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2411.eurprd07.prod.outlook.com (10.168.129.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.11; Fri, 17 May 2019 11:26:07 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2130:5ad6:fafb:c4c8]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2130:5ad6:fafb:c4c8%8]) with mapi id 15.20.1900.010; Fri, 17 May 2019 11:26:07 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: cbor - New Meeting Session Request for IETF 105 Thread-Index: AQHVDKKu1R+G8CpsyEGuLx2FdH22waZvTuQA Date: Fri, 17 May 2019 11:26:07 +0000 Message-ID: References: <155809208681.14846.7261717832739170876.idtracker@ietfa.amsl.com> In-Reply-To: <155809208681.14846.7261717832739170876.idtracker@ietfa.amsl.com> 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: 86354e55-003e-4743-529a-08d6daba7499 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2411; x-ms-traffictypediagnostic: HE1PR0701MB2411: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0040126723 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(136003)(366004)(376002)(53754006)(189003)(199004)(229853002)(6116002)(6486002)(2616005)(7736002)(3846002)(26005)(476003)(4326008)(5640700003)(486006)(86362001)(6436002)(6512007)(450100002)(2501003)(25786009)(305945005)(11346002)(446003)(186003)(6916009)(316002)(66476007)(66556008)(8676002)(36756003)(99286004)(81156014)(1730700003)(81166006)(8936002)(14454004)(71190400001)(82746002)(66446008)(64756008)(71200400001)(508600001)(68736007)(33656002)(5660300002)(76176011)(14444005)(6506007)(66066001)(44832011)(102836004)(6246003)(83716004)(53936002)(76116006)(2351001)(73956011)(2906002)(66946007)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2411; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 59YcYjvlY+UknnrAY21i+jZk/g19S4vkSrGBVOahY+EDoEb0CfEqEraxdXuAxUDZB9lU1Hp4OYk+XlBL+PYApxx2b+Z9Yp6Z3pCLhVxRym4rUdHVSPBeFn7X2NiDtDzynJwrFommB/fPCYvJaAchdeHnWrfTMTl9mf5JROWHlk85E9q2VAKe8tYaswWBBmVMPUd/1PYEi5FmCqRhP5pkuNA7q02ViXeDkhdXBzZdG2qPaBfGd4N720RcCGkaHopCaL/S1xDfhpMbXsHgmOb0qyS1TjDoZPVlo93s5HUcCfRbeePLurQEPvViCrZY4HTQh3CdO54neUnHDZyc55CST8dKXFf7jb+tJJhiI1NKVSXtXhK/jMWMAeHRTkFM2Xpf7IeexEq6KNGG7h9SOkOlFmy1Uq1GBB+F+MRahUiH2EA= Content-Type: text/plain; charset="utf-8" Content-ID: <90F4DFB95B6CBF47A23B1287DCBBE10F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 86354e55-003e-4743-529a-08d6daba7499 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2019 11:26:07.2619 (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: HE1PR0701MB2411 Archived-At: Subject: Re: [Cbor] cbor - New Meeting Session Request for IETF 105 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: Fri, 17 May 2019 11:26:13 -0000 SGkgYWxsLA0KDQpUaGUgc2Vzc2lvbiBmb3IgSUVURjEwNSBoYXMgYmVlbiByZXF1ZXN0ZWQuIElm IHlvdSBoYXZlIGFueSBpbnB1dCBhYm91dCB3ZyBjb2xsaXNpb25zIHRoYXQgd2UgbWlnaHQgaGF2 ZSBtaXNzZWQsIHBsZWFzZSBzZW5kIHVzIGNoYWlycyBhIG1lc3NhZ2UgYnkgdGhlIGVuZCBvZiBN YXkuDQoNClRoYW5rcywNCkZyYW5jZXNjYQ0KDQrvu79PbiAxNy8wNS8yMDE5LCAxMzoyMSwgIklF VEYgTWVldGluZyBTZXNzaW9uIFJlcXVlc3QgVG9vbCIgPHNlc3Npb24tcmVxdWVzdEBpZXRmLm9y Zz4gd3JvdGU6DQoNCiAgICANCiAgICANCiAgICBBIG5ldyBtZWV0aW5nIHNlc3Npb24gcmVxdWVz dCBoYXMganVzdCBiZWVuIHN1Ym1pdHRlZCBieSBGcmFuY2VzY2EgUGFsb21iaW5pLCBhIENoYWly IG9mIHRoZSBjYm9yIHdvcmtpbmcgZ3JvdXAuDQogICAgDQogICAgDQogICAgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgV29ya2lu ZyBHcm91cCBOYW1lOiBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gTWFpbnRl bmFuY2UgYW5kIEV4dGVuc2lvbnMNCiAgICBBcmVhIE5hbWU6IEFwcGxpY2F0aW9ucyBhbmQgUmVh bC1UaW1lIEFyZWENCiAgICBTZXNzaW9uIFJlcXVlc3RlcjogRnJhbmNlc2NhIFBhbG9tYmluaQ0K ICAgIA0KICAgIE51bWJlciBvZiBTZXNzaW9uczogMQ0KICAgIExlbmd0aCBvZiBTZXNzaW9uKHMp OiAgMS41IEhvdXJzDQogICAgTnVtYmVyIG9mIEF0dGVuZGVlczogNTANCiAgICBDb25mbGljdHMg dG8gQXZvaWQ6IA0KICAgICBGaXJzdCBQcmlvcml0eTogc2FhZyBhY2UgY29yZSBsYW1wcyBjb3Nl IA0KICAgICBTZWNvbmQgUHJpb3JpdHk6IGVtdSBjZnJnIHNlY2Rpc3BhdGNoIHRscyB0MnRyZyBz dWl0IG9hdXRoIHJhdHMNCiAgICAgVGhpcmQgUHJpb3JpdHk6IGFuaW1hIHRlZXAgNnRpc2NoIGN1 cmRsZSBodHRwYmlzIGR0biBkb3RzDQogICAgDQogICAgDQogICAgUGVvcGxlIHdobyBtdXN0IGJl IHByZXNlbnQ6DQogICAgICBDYXJzdGVuIEJvcm1hbm4NCiAgICAgIEFsZXhleSBNZWxuaWtvdg0K ICAgICAgSmltIFNjaGFhZA0KICAgICAgRnJhbmNlc2NhIFBhbG9tYmluaQ0KICAgIA0KICAgIFJl c291cmNlcyBSZXF1ZXN0ZWQ6DQogICAgDQogICAgU3BlY2lhbCBSZXF1ZXN0czoNCiAgICAgIFBs ZWFzZSBhdm9pZCBjb2xsaXNpb24gd2l0aCBhbnkgU2VjIGFuZCBJb1QtcmVsYXRlZCBCb0ZzDQog ICAgDQogICAgUGxlYXNlIGF2b2lkIGNvbGxpc2lvbiB3aXRoIGxha2UgKExpZ2h0d2VpZ2h0IEFL RSkNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiAgICANCiAgICANCg0K From nobody Fri May 17 05:24:39 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 F40A21201BB for ; Fri, 17 May 2019 05:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 F0_hdy4ao9Rb for ; Fri, 17 May 2019 05:24:35 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20083.outbound.protection.outlook.com [40.107.2.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232A412004A for ; Fri, 17 May 2019 05:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=llfQxBLUEOhAyYAHTLCreFh43Xoy7AmPxzuyL2oSRzg=; b=SyT1jKqimwuh2x3BoSJGqDJ7E0hkUXw72oBMyb+EF+ahVAiLkp8DJsOazA0uwFbeU0Jr3vC5+F+bLeXq0GMpZkU0Chr1VKtjA0MzA7ac08CDme9Z08AzNBjiB8WJA/B+yj/IAZd0/AsyVvV2kh9Gta4SXBubi09p09zSDIs8Q6g= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2556.eurprd07.prod.outlook.com (10.168.186.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.13; Fri, 17 May 2019 12:24:32 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2130:5ad6:fafb:c4c8]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2130:5ad6:fafb:c4c8%8]) with mapi id 15.20.1900.010; Fri, 17 May 2019 12:24:32 +0000 From: Francesca Palombini To: "cbor@ietf.org" , Jeffrey Yasskin , Laurence Lundblade Thread-Topic: Appendix C of CBORBis Thread-Index: AQHVDKt7HS0htbK23kO4cdP8Umy6BA== Date: Fri, 17 May 2019 12:24:32 +0000 Message-ID: <90262C4A-1A64-4658-BD9B-B1847190D6A6@ericsson.com> 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: 8947065e-34e1-4b4d-7285-08d6dac29dc9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2556; x-ms-traffictypediagnostic: HE1PR0701MB2556: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0040126723 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(136003)(366004)(376002)(396003)(199004)(189003)(53754006)(68736007)(256004)(81156014)(102836004)(5660300002)(6116002)(4744005)(110136005)(508600001)(3846002)(8676002)(86362001)(8936002)(81166006)(66946007)(66066001)(316002)(7736002)(44832011)(53936002)(186003)(966005)(2501003)(71200400001)(71190400001)(99286004)(66556008)(66476007)(36756003)(486006)(25786009)(73956011)(91956017)(6486002)(83716004)(54896002)(6512007)(26005)(2906002)(606006)(236005)(6506007)(14454004)(76116006)(3480700005)(66446008)(33656002)(6306002)(2616005)(64756008)(6436002)(82746002)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2556; 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: 3BJ56gT3dduUQSO/Ca5oF9kk/bYg79OYl1C7O0/5Zz4B9cD/JZaNphwkfd0Rr118gZdrQw/eTQfqVY95TL1Vy883oFD3ABrZGU2k5+wrDVNVqFk5UK7mcha78yP7wR8vm0PuSyXOpUe4m9rfn+O9f4vqDK368PONytUyz9QrTONIckRDU0gv1BnQPJIPpbMW9QTnG12n/6dDbP9ADD5PtoOvMkswL1GBgvIQgYUEBKmYYyGW/5iApRvwFFrTnXV84+AxZDLI5ETXi8sUV7utLJM3GuJf5kEo2RjVW0LHb2lmVvrDM2inLDhOgr0rfe91Wpg9Bb3cpSAcKSgcirAJXAr40yywGSirT7+10zTTWB2eoZcRy0rvpJIlr76d5RyCPL8qLMalN2kFi4SdmKbmyu8e1psmszei99q+gbGCPfQ= Content-Type: multipart/alternative; boundary="_000_90262C4A1A644658BD9BB1847190D6A6ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8947065e-34e1-4b4d-7285-08d6dac29dc9 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2019 12:24:32.4308 (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: HE1PR0701MB2556 Archived-At: Subject: [Cbor] Appendix C of CBORBis 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: Fri, 17 May 2019 12:24:38 -0000 --_000_90262C4A1A644658BD9BB1847190D6A6ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpBcyBhbiBvdXRwdXQgb2YgdGhlIGRpc2N1c3Npb24gYXQgSUVURjEwNCwgQ2Fy c3RlbiByZXF1ZXN0ZWQgdGhhdCBBcHBlbmRpeCBDIGJlIHJldmlld2VkIGJ5IHRoZSB3ZywgcmUg 4oCcZGVmZW5zaXZlIGVub3VnaOKAnS4gSW4gcGFydGljdWxhciwgSmVmZnJleSBhbmQgTGF1cmVu Y2UsIHdobyBoYXZlIGhlYXZpbHkgcGFydGljaXBhdGVkIGluIHRoZSBkaXNjdXNzaW9uLCBpZiB5 b3UgY291bGQgcmVhZCB0aGF0IHVwIGJlZm9yZSBuZXh0IGludGVyaW0gKDIybmQgb2YgTWF5KSB0 aGF0IHdvdWxkIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuDQoNCmh0dHBzOi8vY2Jvci13Zy5naXRo dWIuaW8vQ0JPUmJpcy9kcmFmdC1pZXRmLWNib3ItNzA0OWJpcy5odG1sI3JmYy5hcHBlbmRpeC5D DQoNCihJZiB5b3UgbmVlZCBtb3JlIGNvbnRleHQsIElFVEYxMDQgbWludXRlczogaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwNC9tYXRlcmlhbHMvbWludXRlcy0xMDQtY2Jv ci0wMS50eHQgKQ0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg== --_000_90262C4A1A644658BD9BB1847190D6A6ericssoncom_ 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+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJT ViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BcyBhbiBvdXRwdXQgb2YgdGhlIGRpc2N1 c3Npb24gYXQgSUVURjEwNCwgQ2Fyc3RlbiByZXF1ZXN0ZWQgdGhhdCBBcHBlbmRpeCBDIGJlIHJl dmlld2VkIGJ5IHRoZSB3ZywgcmUg4oCcZGVmZW5zaXZlIGVub3VnaOKAnS4gSW4gcGFydGljdWxh ciwgSmVmZnJleSBhbmQgTGF1cmVuY2UsIHdobyBoYXZlIGhlYXZpbHkgcGFydGljaXBhdGVkIGlu IHRoZSBkaXNjdXNzaW9uLA0KIGlmIHlvdSBjb3VsZCByZWFkIHRoYXQgdXAgYmVmb3JlIG5leHQg aW50ZXJpbSAoMjI8c3VwPm5kPC9zdXA+IG9mIE1heSkgdGhhdCB3b3VsZCBiZSBncmVhdGx5IGFw cHJlY2lhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2Nib3Itd2cuZ2l0aHViLmlv L0NCT1JiaXMvZHJhZnQtaWV0Zi1jYm9yLTcwNDliaXMuaHRtbCNyZmMuYXBwZW5kaXguQyI+aHR0 cHM6Ly9jYm9yLXdnLmdpdGh1Yi5pby9DQk9SYmlzL2RyYWZ0LWlldGYtY2Jvci03MDQ5YmlzLmh0 bWwjcmZjLmFwcGVuZGl4LkM8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PihJZiB5b3UgbmVlZCBtb3JlIGNvbnRleHQsIElFVEYxMDQgbWludXRlczoNCjwvc3Bhbj48YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA0L21hdGVyaWFscy9t aW51dGVzLTEwNC1jYm9yLTAxLnR4dCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0 aW5nLzEwNC9tYXRlcmlhbHMvbWludXRlcy0xMDQtY2Jvci0wMS50eHQ8L2E+ICk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxicj4NCkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_90262C4A1A644658BD9BB1847190D6A6ericssoncom_-- From nobody Fri May 17 05:27:05 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 B8F3A1201BB for ; Fri, 17 May 2019 05:27:01 -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, T_DKIMWL_WL_HIGH=-0.01, T_SPF_HELO_TEMPERROR=0.01] 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 8_4X6a48oPq4 for ; Fri, 17 May 2019 05:27:00 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150070.outbound.protection.outlook.com [40.107.15.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13C112004A for ; Fri, 17 May 2019 05:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ujzLWrSONpIgAJMldhmO6l9nZ8izap5BrjaTqCUvz1k=; b=dlg7zwyhkiFokd3SaLmGqVov+ySiDA7UQp8HMkiUPdnm0WtVVFsnB2tmWqMWkvQ4NhG5Sy3tSB6k1UoObpqM7o/xkIApeZtFL03PEKYRqhf1jDXOF7XkUMhIWEjf8I/ztTqLxaJQXDNRETbl8p7Bew/eX0aI78h4pWPF/VLuSPk= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2617.eurprd07.prod.outlook.com (10.168.184.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.15; Fri, 17 May 2019 12:26:57 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2130:5ad6:fafb:c4c8]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2130:5ad6:fafb:c4c8%8]) with mapi id 15.20.1900.010; Fri, 17 May 2019 12:26:57 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-05-22 Thread-Index: AQHVBPjFs1KN6ry6m0e7jJzLWv9npqZvbzcA Date: Fri, 17 May 2019 12:26:57 +0000 Message-ID: <6E73F0BD-1028-40E2-8315-EA7FA884D9C3@ericsson.com> References: <155724943556.21070.13235416586496990339@ietfa.amsl.com> In-Reply-To: <155724943556.21070.13235416586496990339@ietfa.amsl.com> 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: b4377daa-98a4-4ab0-480e-08d6dac2f426 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2617; x-ms-traffictypediagnostic: HE1PR0701MB2617: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0040126723 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(346002)(366004)(39860400002)(376002)(497574002)(189003)(199004)(53754006)(6246003)(6116002)(3846002)(36756003)(305945005)(86362001)(53936002)(5660300002)(7736002)(6916009)(66574012)(2501003)(486006)(44832011)(73956011)(76116006)(2616005)(476003)(11346002)(66556008)(66946007)(66476007)(446003)(64756008)(66446008)(1730700003)(81156014)(14454004)(81166006)(8936002)(26005)(66066001)(186003)(256004)(76176011)(6506007)(102836004)(14444005)(8676002)(83716004)(6306002)(6512007)(5640700003)(82746002)(99286004)(71200400001)(71190400001)(229853002)(316002)(6436002)(508600001)(33656002)(25786009)(966005)(2906002)(2351001)(68736007)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2617; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: ilJS5KBx2636QBi6Fst1t3QbyvaGmeorR2YpJ+eA2o6W4NiIBgGVhPLrWjnKVvk3eSClumiTI9OtJNv6TLl1ZjBtyClPzfUxuABD0PrxNhiwjw3qpEVVZryLa2QvH3y2h9MUJXH5LAXIBs/3WI5x8BhXBVv8nZL06x1wJ7gOiaVNLjwepZOhXzcWZE1Eowj0w+FQfZtG6Fvt91ztZwtRnrLCwHdN298UblwGJadJl27wzp56+LU7gafgqv4d7/JLbKfixZNTaJE0JRZXrcvuitH27A2FX3QYSfD9imai6hJN9zR527cdPrT2RJxFrsVCxaNFLuJvnUJs+EC7F8o3fJ8S7X/NojiYew9WL9C5WNh6M5XrN+7Cm9tnIQde/s7cJH/pjbi7BTD4gBvlkwRYwraVoYDvbnppntqD1D8jlbE= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b4377daa-98a4-4ab0-480e-08d6dac2f426 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2019 12:26:57.2672 (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: HE1PR0701MB2617 Archived-At: Subject: Re: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-05-22 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: Fri, 17 May 2019 12:27:02 -0000 SGkgYWxsLA0KDQpBIGRyYWZ0IGFnZW5kYSBoYXMgYmVlbiBzdWJtaXR0ZWQ6IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMTktY2Jvci0wNy9tYXRlcmlhbHMv YWdlbmRhLWludGVyaW0tMjAxOS1jYm9yLTA3LXNlc3NhDQoNClBsZWFzZSBsZXQgdXMga25vdyBp ZiB5b3UgaGF2ZSBhbnkgaW5wdXQuDQoNCkZyYW5jZXNjYQ0KDQrvu79PbiAwNy8wNS8yMDE5LCAx OToxNywgIkNCT1Igb24gYmVoYWxmIG9mIElFU0cgU2VjcmV0YXJ5IiA8Y2Jvci1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBpZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4gd3JvdGU6DQoNCiAg ICBUaGUgQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIE1haW50ZW5hbmNlIGFu ZCBFeHRlbnNpb25zIChjYm9yKSBXb3JraW5nIEdyb3VwIHdpbGwgaG9sZA0KICAgIGEgdmlydHVh bCBpbnRlcmltIG1lZXRpbmcgb24gMjAxOS0wNS0yMiBmcm9tIDE1OjAwIHRvIDE2OjAwIFVUQy4N CiAgICANCiAgICBBZ2VuZGE6DQogICAgKE5vIGFnZW5kYSBzdWJtaXR0ZWQpDQogICAgDQogICAg SW5mb3JtYXRpb24gYWJvdXQgcmVtb3RlIHBhcnRpY2lwYXRpb246DQogICAgV2Ugd2lsbCB1c2Ug dGhlIHdvcmtpbmcgZ3JvdXAgV2ViRXggZm9yIHRoZSBjYWxscy4gIFRoZSBJRVRGIFdlYkV4IGFj Y291bnQgZG9lcyBub3QgYWxsb3cgSW50ZXJuYXRpb25hbCBkaWFsbGluZyBub3IgVVMgdG9sbCBm cmVlICgiODAwIiBudW1iZXJzKSwgYnV0IHlvdSBjYW4gdXNlIHRoZSBXZWJFeCBhcHAgdG8gY29u bmVjdCB5b3VyIGRldmljZSBhdWRpbywgYW5kIHRoZXJlJ3MgYWxzbyB0aGUgb3B0aW9uIG9mIGNv bm5lY3Rpb24gZGlyZWN0bHkgZnJvbSB5b3VyIGJyb3dzZXIgaWYgeW91ciBicm93c2VyIHN1cHBv cnRzIGl0LiAgV2ViRXggZGV0YWlscyB3aWxsIGJlIHNlbnQgdG8gdGhlIG1haWxpbmcgbGlzdCBi ZWZvcmUgZWFjaCBjYWxsICh0aGUgZGV0YWlscyB3aWxsIGJlIHRoZSBzYW1lIGZvciBhbGwgY2Fs bHMsIGJ1dCB0aGUgbWVzc2FnZXMgd2lsbCBzZXJ2ZSBhcyByZW1pbmRlcnMpLg0KICAgIA0KICAg IFRoZSBDQk9SIHdvcmtpbmcgZ3JvdXAgd2lsbCBoYXZlIGNvbmZlcmVuY2UgY2FsbHMgcnVubmlu ZyBldmVyeSB0d28gd2Vla3MgdGhyb3VnaCB0aGUgYmVnaW5uaW5nIG9mIE5vdmVtYmVyIDIwMTkg KGJhc2ljYWxseSwgdW50aWwgSUVURiAxMDYgaW4gU2luZ2Fwb3JlKS4NCiAgICANCiAgICBEYXk6 IGV2ZXJ5IG90aGVyIFdlZG5lc2RheSBiZWdpbm5pbmcgb24gTWF5IDIybmQNCiAgICBEYXRlczog IDIyIE1heTsgNSwgMTkgSnVuZTsgMywgMTcsIDMxIEp1bHk7IDE0LCAyOCBBdWc7IDExLCAyNSBT ZXB0OyA5LCAyMyBPY3Q7IDYgTm92DQogICAgVGltZTogMTU6MDAgdG8gMTY6MDAgVVRDIGZvciBh bGwgZGF0ZXMgZXhjZXB0IDYgTm92OyA2IE5vdjogMTY6MDAg4oCTIDE3OjAwIFVUQw0KICAgIA0K ICAgIE5vdGUgdGhhdCBsb2NhbCB0aW1lIGluIE5BIHdpbGwgY2hhbmdlIGZvciB0aGUgNiBOb3Yg bWVldGluZywgYnV0IHdpbGwgbm90IGNoYW5nZSBpbiBFdXJvcGUuDQogICAgDQogICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBDQk9SIG1haWxp bmcgbGlzdA0KICAgIENCT1JAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Nib3INCiAgICANCg0K From nobody Fri May 17 13:37: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 5B2BF1200E5; Fri, 17 May 2019 13:37: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, 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 MlOhQOUOAWo1; Fri, 17 May 2019 13:37:42 -0700 (PDT) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (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 A2275120046; Fri, 17 May 2019 13:37:42 -0700 (PDT) Received: by mail-vk1-xa31.google.com with SMTP id v69so2372866vke.0; Fri, 17 May 2019 13:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=gOfYpTcXrR1diGgkv7J3tmT+GFaGWikl3BNWZgNkOeQ=; b=iE46kba9ggTlJaGdAUAKsNVCChqWevLs7SjfUe+UjsSwMJjrjJPMG1CVWRX6en2vUX JKIrR3q/7Db3b0WssYh8IQd/FW9D1qfKZ6r+TbL2+MhdaHlQi5EN0Ow4ryq/Xoh3vpUC N+6/gFBxDR8bmA1f6487bxb5pOiszX+MGgUy31/pgtzCqZcsQly8xmKpEPAY6Gg2VrU1 osJMSy7tU/2l7v6h7OwRVAIhBPEnw5LC+EA7wXmDBr9zomZMzA3sRjetEYxu+fHOrp5i 16u7KyS18T4F/lcqSAHDs5rqoeKHHPYE4FVUU5V1oTvJn5QOLfssE8iWND52mBHgt/9b FMag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gOfYpTcXrR1diGgkv7J3tmT+GFaGWikl3BNWZgNkOeQ=; b=mxGevfFrXA3joQmGhH8jTA2PIYny2SSjhyRqwCbr2ljvPf5IiDPT6nbQlwIxUD/9Ga 6T2UxRWZ9/yIkAhvjVS0pOpIwgotqJqRa0S3+hKY8NRxdGMW71+/Fd+udyuCyjwGpTwW IiHabzO7qsjK1rzeOnOYop3ylM6fH9SqeY6aI/g2Lz8PhDAFzLoIIaCDf4HVBp/rmpoT Q7PmiUYQWClh7hblJ5zOO1Ku07qqO9i1T2j+OlG7Y48TFR6d5VQZAYofE3Z+rFZdxqFl oBUGYxDbcD8vFJaTQl9mlMIS70YYkVslqnJFgEkNXDSR+ilsEHAZeLBeY8KokLrvsU+W IKWQ== X-Gm-Message-State: APjAAAXRHTFtio5jPB2bDruKkotPSytbTL3dRaECHlvrwX842W9msnzR vZIYrsG4tmd3yW2ObrLtQgqu3QvynKqz7Lsakc/NlFCu X-Google-Smtp-Source: APXvYqx8RhpSlEj76VJzLC6JQYRZQs4Kc4DbAv10B3ZHXm4TsRgYi0bL88aX6eAu/SndE3CNG+AvaHOrtrjAe9y/Kkk= X-Received: by 2002:a1f:30d4:: with SMTP id w203mr544048vkw.0.1558125461467; Fri, 17 May 2019 13:37:41 -0700 (PDT) MIME-Version: 1.0 From: Daniel P Date: Fri, 17 May 2019 16:37:28 -0400 Message-ID: To: draft-ietf-cbor-cddl@ietf.org, cbor@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cbor] Question about draft-ietf-cbor-cddl-08 abnf 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: Fri, 17 May 2019 20:37:44 -0000 Regarding hexfloat = "0x" 1*HEXDIG ["." 1*HEXDIG] "p" exponent should hexfloat allow an optional leading minus sign? C/C++ allows that. Thanks, Daniel From nobody Fri May 17 14:11:15 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 478281200B1; Fri, 17 May 2019 14:11:15 -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 snIoHZLXSmHn; Fri, 17 May 2019 14:11:13 -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 4D11F12008A; Fri, 17 May 2019 14:11:13 -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 455LYq0p5BzyVc; Fri, 17 May 2019 23:11:11 +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: Date: Fri, 17 May 2019 23:11:10 +0200 Cc: draft-ietf-cbor-cddl@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 579820242.0121959-5b872118aff3f054963a4b3f02168873 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Daniel P X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Question about draft-ietf-cbor-cddl-08 abnf 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: Fri, 17 May 2019 21:11:15 -0000 On May 17, 2019, at 22:37, Daniel P wrote: >=20 > Regarding >=20 > hexfloat =3D "0x" 1*HEXDIG ["." 1*HEXDIG] "p" exponent >=20 > should hexfloat allow an optional leading minus sign? Yes. =20 I believe you found a bug. Would=20 hexfloat =3D [=E2=80=9C-"] "0x" 1*HEXDIG ["." 1*HEXDIG] =E2=80=9Cp" = exponent work for you? > C/C++ allows that. Actually, it doesn=E2=80=99t. =20 https://en.cppreference.com/w/c/language/integer_constant has this note: There are no negative integer constants. Expressions such as -1 apply = the unary minus operator to the value represented by the constant, which = may involve implicit type conversions. The same is true for floating point constants. Both only work if you have a unary minus operator in the language. =20 In CDDL, we don=E2=80=99t. =20 Copying the C productions is what made us create this bug=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Fri May 17 16:13:14 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 1A21E1201F3 for ; Fri, 17 May 2019 16:13:12 -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] 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 IfqRqh6wHwEZ for ; Fri, 17 May 2019 16:13:10 -0700 (PDT) Received: from p3plsmtpa09-09.prod.phx3.secureserver.net (p3plsmtpa09-09.prod.phx3.secureserver.net [173.201.193.238]) (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 068D2120152 for ; Fri, 17 May 2019 16:13:09 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id Rm2GhqMC91w3PRm2GhAeRN; Fri, 17 May 2019 16:13:08 -0700 From: Laurence Lundblade Message-Id: <802456D2-279B-40FD-93BC-98046243E6A3@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0D2AC7B5-4F58-4CFD-99D3-B5BEF5051019" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 17 May 2019 16:13:07 -0700 In-Reply-To: <90262C4A-1A64-4658-BD9B-B1847190D6A6@ericsson.com> Cc: "cbor@ietf.org" , Jeffrey Yasskin To: Francesca Palombini References: <90262C4A-1A64-4658-BD9B-B1847190D6A6@ericsson.com> X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfP1Ba60mVKagv2zQrC1vp0NmsUL04uUAd74AXpYxy5Vj2AzNn2bfx0lwtDoRu1YBVKrLNNu6XXSFTGyx0+9yEtNDqK3wHIvk49CiY+RtSHEwuVVMAtf5 vccVWzc321v/0OjRHGWhsx1PYPEtxJrFPppSwxew/1ECuxDLSSDNKKjFtee2c4BzFo47M6Z8+4BGNzoXkL1BNtljvKZK6gAj0MBtsQO4sWu+2dPd4odoVfhu yPo6LE/HjGoJgwE4OQ9hXw== Archived-At: Subject: Re: [Cbor] Appendix C of CBORBis 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: Fri, 17 May 2019 23:13:12 -0000 --Apple-Mail=_0D2AC7B5-4F58-4CFD-99D3-B5BEF5051019 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Looks right to me. LL > On May 17, 2019, at 5:24 AM, Francesca Palombini = wrote: >=20 > Hi all, > =20 > As an output of the discussion at IETF104, Carsten requested that = Appendix C be reviewed by the wg, re =E2=80=9Cdefensive enough=E2=80=9D. = In particular, Jeffrey and Laurence, who have heavily participated in = the discussion, if you could read that up before next interim (22nd of = May) that would be greatly appreciated. > =20 > = https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#rfc.appendi= x.C = > =20 > (If you need more context, IETF104 minutes: = https://datatracker.ietf.org/meeting/104/materials/minutes-104-cbor-01.txt= = ) > =20 > Thanks, > Francesca > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor = --Apple-Mail=_0D2AC7B5-4F58-4CFD-99D3-B5BEF5051019 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Looks= right to me.

LL


On May = 17, 2019, at 5:24 AM, Francesca Palombini <francesca.palombini@ericsson.com> wrote:

Hi all,
 
As an output of = the discussion at IETF104, Carsten requested that Appendix C be reviewed = by the wg, re =E2=80=9Cdefensive enough=E2=80=9D. In particular, Jeffrey = and Laurence, who have heavily participated in the discussion, if you = could read that up before next interim (22nd of May) that would be = greatly appreciated.
 
 
 
Thanks,
Francesca
_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor

= --Apple-Mail=_0D2AC7B5-4F58-4CFD-99D3-B5BEF5051019-- From nobody Sat May 18 16:02:49 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 5925212004F for ; Sat, 18 May 2019 16:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 v0rLmvhLgCW8 for ; Sat, 18 May 2019 16:02:45 -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 60BE3120019 for ; Sat, 18 May 2019 16:02:45 -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; Sat, 18 May 2019 16:02:17 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: References: <032801d50c37$4b8a3120$e29e9360$@augustcellars.com> <9DD06B37-5EF4-40A1-B14D-C44D5F0C995A@tzi.org> In-Reply-To: <9DD06B37-5EF4-40A1-B14D-C44D5F0C995A@tzi.org> Date: Sat, 18 May 2019 16:02:13 -0700 Message-ID: <000a01d50dcd$bd0d2630$37277290$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHDadG055gE6jt6NF5RGd9M/3eUWgG4VcshpocE7qA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Charter update 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, 18 May 2019 23:02:47 -0000 While the following work better? There are a number of additional CBOR tagged types that are ... Jim > -----Original Message----- > From: Carsten Bormann > Sent: Thursday, May 16, 2019 4:20 PM > To: Jim Schaad > Cc: cbor@ietf.org > Subject: Re: [Cbor] Charter update >=20 > Hi Jim, >=20 > thank you (the chairs) for taking this initiative. > I still have to read the whole thing, but I already experience one = heavy knee > jerk: >=20 > > On May 17, 2019, at 00:32, Jim Schaad = wrote: > > > > extensions to CBOR types >=20 > I don=E2=80=99t think we should say that we are = =E2=80=9Cextending=E2=80=9D CBOR=E2=80=A6 Yes, we are > exercising its extensibility points, but the result are new (or = updated) CBOR > Tags, not really extensions to CBOR itself. > (I=E2=80=99m trying separate CBOR the standard from the greater CBOR = ecosystem, > which includes the Tag definitions.) >=20 > (We *are* extending CDDL. I hope.) >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Sun May 19 15:51:54 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 C794612008D for ; Sun, 19 May 2019 15:51:53 -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 J0tNdh0LyaRY for ; Sun, 19 May 2019 15:51:52 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 2FE0412003E for ; Sun, 19 May 2019 15:51:52 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id g9so6232999pfo.11 for ; Sun, 19 May 2019 15:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:reply-to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=2B1xaU+rQ4L7ZugQ8DwyVDdnC8EJzuXgRO8JDSCor3g=; b=SRFB+1YwwH+l6qFlj6WrrGvIiSlpldWqy6Z6s6JQ4CCrpa2YU0qK7AqlRwf8S2RGer lE5gZlxQtwEmOHdtja+ba/GM4gc0mJugv4CLSxui/I6I5RLeHzhI2YONe5tTvg4VevUo oOLOM1z4LsD/hiw9i3ett+FdMruONuMixpZPSTMjhJqylAmPb1yi+NYgx7AqqlPaiDCk MDWljNznbqVA0PYy1x7ms/ljkK/YFV6HAqTJjblKLcR7MB8DI4qjBFnZvsAnMAIJemgo pF3bnCkJ7UmwJaAVxA/XFkw1yIYzSHhoolFQRNKI3FV91VpB3O7mg7nZiQAkJmSUzUwL 14Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:reply-to:from:subject:organization:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=2B1xaU+rQ4L7ZugQ8DwyVDdnC8EJzuXgRO8JDSCor3g=; b=rEWWkLnhat8g137UpPbu21rYfeaPVeOKflV2Vj6lwipnYA3HIhdaJWq65XH4vJLuUe EPGu85PvsQfoxDtuBI7mGhUbEKBy1xFch48627Bz0JSGS/VRS5aNRBWlpRrz3mB2vO0y KUQDTyH1GXp13XbpHh9UOfyCxNlznWEtL1t6jnCewEF39ui3FCx3Q1xtTAiQXgNFRo98 GIpVMIfKa/o0FHUPxhKvL6e2nAln35SBPCqza0eqQxdmTwWiGdt3+P3KAjbraPzQ0VLy 0YKeZq22YqABZj550+QPsD/KzIoAo0A3BT0J7lk3OhdrUg6hvpnnysGZAL8+i/uRCBub qYYg== X-Gm-Message-State: APjAAAXXuIGgXg2vNqh55kGjlM8ReIDnZMvPN71b1EoNW8CBOHH0256h S8KAZoEHm15vhBVkiOtxWsfKZK3H X-Google-Smtp-Source: APXvYqyOJJA0UOcxTQk/BaMSW0HXjJN44JWlX0cRgvbQRQOyv9FLXPz/VuQ3YNPdnmydKBaPvYgf2g== X-Received: by 2002:a63:1706:: with SMTP id x6mr71505857pgl.280.1558306311376; Sun, 19 May 2019 15:51:51 -0700 (PDT) Received: from [192.168.178.30] (229.129.69.111.dynamic.snap.net.nz. [111.69.129.229]) by smtp.gmail.com with ESMTPSA id u6sm24352791pfa.1.2019.05.19.15.51.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 May 2019 15:51:50 -0700 (PDT) To: cbor@ietf.org Reply-To: Brian E Carpenter From: Brian E Carpenter Organization: University of Auckland Message-ID: <35791dd6-9492-0334-c8ac-76057eb7ae93@gmail.com> Date: Mon, 20 May 2019 10:51:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cbor] Off topic: tlv.dumps() and tlv.loads() 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, 19 May 2019 22:51:54 -0000 Hi, This is off-topic so please reply privately if at all. I thought it might interest some people here. For a recent small project, I wanted to directly compare CBOR and traditional TLV versions of the same protocol. To simplify this, I wrote a small Python3 module that provides tlv.dumps() and tlv.loads(). They handle pattern-driven encoding and decoding of Python objects as a TLV byte string. If interested, see https://github.com/becarpenter/tlv (code plus issue tracker), and contact me by email. Regards Brian Carpenter From nobody Tue May 21 02:52:09 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 EE6CC12012D for ; Tue, 21 May 2019 02:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 oivoYqSG5Gq0 for ; Tue, 21 May 2019 02:52:03 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140040.outbound.protection.outlook.com [40.107.14.40]) (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 257E712012E for ; Tue, 21 May 2019 02:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XJ6kJCVqj9xlVMrOZFbjcXk50Mx4AZLZIBBkv15ieLM=; b=U7T4y+E+YS1/dFK9DXhAaA62zaVo0zT/yfFTw+aCAoR2kWwpAfD/vk800meXEcQmd8E//JKpFf53FXrJe7z8gxNEp09kzfN2gQGyO1nozuEekdEbLMyC8G2hiuMwpk0in/XFMTxNn0+z9HTmVbKebzVyg1ljAej3g31T470X5Qs= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2668.eurprd07.prod.outlook.com (10.168.190.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.6; Tue, 21 May 2019 09:51:59 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::8a9:a4d6:303b:45f0]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::8a9:a4d6:303b:45f0%5]) with mapi id 15.20.1922.016; Tue, 21 May 2019 09:51:59 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: Reminder: CBOR Interim: 2019-05-22 Thread-Index: AQHVD7rV764BDEFn4U2YFAnoSnqYUA== Date: Tue, 21 May 2019 09:51:59 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 52c47d10-34eb-460c-de85-08d6ddd1f7c2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:HE1PR0701MB2668; x-ms-traffictypediagnostic: HE1PR0701MB2668: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(39860400002)(366004)(346002)(376002)(12213003)(199004)(53754006)(189003)(497574002)(66066001)(2501003)(606006)(76116006)(66446008)(64756008)(66556008)(66476007)(66616009)(186003)(26005)(2906002)(66946007)(73956011)(4001150100001)(99286004)(2351001)(6116002)(86362001)(6916009)(316002)(3846002)(508600001)(19627405001)(6506007)(966005)(102836004)(14454004)(83716004)(71190400001)(71200400001)(5640700003)(6436002)(25786009)(6512007)(54896002)(6306002)(6486002)(16799955002)(236005)(14444005)(1730700003)(256004)(8676002)(81156014)(7736002)(8936002)(68736007)(81166006)(5660300002)(82746002)(53936002)(44832011)(36756003)(486006)(99936001)(2616005)(33656002)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2668; 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: AFWl22k2AfAIjZmw78G0R/DIuGiSpNJD1vf1bbK5puU+cmnffn5XaXFIbn85sT2FBexheCIU5JurlZ6Gy/uvk4M+KGGusIbWCVrcJ4LiSCq/IvLjOgG19ndqkidISQkVxT3yiR+Wmq8/5k9KFJw6G5y2r7VOThypJXV7QdPPdI8ywCyGTaUUdIl2v9436sL8oj1TBo9WFmUp3zFS4PjK2xatb9iz8fOCnRZ5wl6xM0iZDpfDPA8Dw/nxY2NJENHbxTVFSVccvLhONTYhQYqZ0RBRRsfnniGf2H5PbjfeRSjzf30L/a+8C+wkpR37x9M7g03Yeu+9hr4oc2eznmKSs2gdkL+FmrxVsfiAc7wnBug2xQRMi1/FdgQohWtb+3J+cnkMhKv59qm8SpThfF5wXPkxTuG2cA6/N/tOt1HENgU= Content-Type: multipart/mixed; boundary="_004_DB11DF949502424C8D1901A038BF086Dericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52c47d10-34eb-460c-de85-08d6ddd1f7c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2019 09:51:59.0847 (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-CrossTenant-userprincipalname: francesca.palombini@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2668 Archived-At: Subject: [Cbor] Reminder: CBOR Interim: 2019-05-22 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: Tue, 21 May 2019 09:52:07 -0000 --_004_DB11DF949502424C8D1901A038BF086Dericssoncom_ Content-Type: multipart/alternative; boundary="_000_DB11DF949502424C8D1901A038BF086Dericssoncom_" --_000_DB11DF949502424C8D1901A038BF086Dericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpIZXJlIGFyZSB0aGUgZGV0YWlscyBmb3IgdG9tb3Jyb3cncyBpbnRlcmltOg0K DQpXZWJleDogaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTEyMzdhOTgx MjQxMTFkZTNhNGM0ZTYxZGZhY2EwNWQ1DQpBZ2VuZGE6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMTktY2Jvci0wNy9tYXRlcmlhbHMvYWdlbmRhLWludGVy aW0tMjAxOS1jYm9yLTA3LXNlc3NhDQpUaW1lOiBodHRwczovL3d3dy53b3JsZHRpbWVidWRkeS5j b20vP3FtPTEmbGlkPTI2NzM3MzAsMTAwLDUsMzA4Jmg9MjY3MzczMCZkYXRlPTIwMTktNS0yMSZz bG49MTctMTgNCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCg0KSGVsbG8sDQpDQk9SIFdvcmtpbmcg R3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYmV4IG1lZXRpbmcuDQoNCg0KDQpDQk9S IFdHIENvbmZlcmVuY2UgQ2FsbA0KT2NjdXJzIGV2ZXJ5IDIgd2VlayhzKSBvbiBXZWRuZXNkYXkg ZWZmZWN0aXZlIFdlZG5lc2RheSwgTWF5IDIyLCAyMDE5IHVudGlsIFdlZG5lc2RheSwgTm92ZW1i ZXIgNiwgMjAxOSBmcm9tIDU6MDAgUE0gdG8gNjowMCBQTSwgKFVUQyswMTowMCkgQW1zdGVyZGFt LCBCZXJsaW4sIEJlcm4sIFJvbWUsIFN0b2NraG9sbSwgVmllbm5hDQo1OjAwIHBtICB8ICBFdXJv cGUgU3VtbWVyIFRpbWUgKEFtc3RlcmRhbSwgR01UKzAyOjAwKSAgfCAgMSBocg0KDQpNZWV0aW5n IG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDEgNzYwIDE1Nw0KDQpNZWV0aW5nIHBhc3N3b3JkOiBV UEF0OXJCbg0KDQoNCg0KQWRkIHRvIENhbGVuZGFyPGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9qLnBocD9NVElEPW0xZDA2MzYwNjlhMjhiZDdjOGNjMDkwZTc0MTU2NWM4Yz4NCldoZW4gaXQn cyB0aW1lLCBqb2luIHRoZSBtZWV0aW5nPGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW0xMjM3YTk4MTI0MTExZGUzYTRjNGU2MWRmYWNhMDVkNT4uDQoNCg0KDQpKb2luIGJ5 IHBob25lDQoxLTY1MC00NzktMzIwODx0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDE3NjAx NTclMjMlMjMqMDEqPiBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpDQoNCg0KDQpDYW4n dCBqb2luIHRoZSBtZWV0aW5nPyA8aHR0cHM6Ly9jb2xsYWJvcmF0aW9uaGVscC5jaXNjby5jb20v YXJ0aWNsZS9XQlgwMDAwMjkwNTU+DQoNCg0KDQpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90 ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0 aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUg ZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwg eW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBu b3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGgg dGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uDQoNCg== --_000_DB11DF949502424C8D1901A038BF086Dericssoncom_ 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 b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgljb2xvcjojNjY2 NjY2Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToi QXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzY2NjY2NjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLUdCIiBsaW5rPSIjNjY2NjY2IiB2bGluaz0iIzY2NjY2NiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IZXJlIGFyZSB0aGUgZGV0YWlscyBmb3IgdG9tb3Jyb3cncyBpbnRlcmltOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZWJleDogPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmL2oucGhwP01USUQ9bTEyMzdhOTgxMjQxMTFkZTNhNGM0ZTYxZGZhY2EwNWQ1Ij4N CjxzcGFuIHN0eWxlPSJjb2xvcjojMDU2M0MxIj5odHRwczovL2lldGYud2ViZXguY29tL2lldGYv ai5waHA/TVRJRD1tMTIzN2E5ODEyNDExMWRlM2E0YzRlNjFkZmFjYTA1ZDU8L3NwYW4+PC9hPg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViI+QWdl bmRhOiA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5n L2ludGVyaW0tMjAxOS1jYm9yLTA3L21hdGVyaWFscy9hZ2VuZGEtaW50ZXJpbS0yMDE5LWNib3It MDctc2Vzc2EiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAxOS1jYm9yLTA3L21hdGVyaWFs cy9hZ2VuZGEtaW50ZXJpbS0yMDE5LWNib3ItMDctc2Vzc2E8L3NwYW4+PC9hPjxzcGFuIGxhbmc9 IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaW1lOiA8 YSBocmVmPSJodHRwczovL3d3dy53b3JsZHRpbWVidWRkeS5jb20vP3FtPTEmYW1wO2xpZD0yNjcz NzMwLDEwMCw1LDMwOCZhbXA7aD0yNjczNzMwJmFtcDtkYXRlPTIwMTktNS0yMSZhbXA7c2xuPTE3 LTE4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMDU2M0MxIj5odHRwczovL3d3dy53b3JsZHRpbWVi dWRkeS5jb20vP3FtPTEmYW1wO2xpZD0yNjczNzMwLDEwMCw1LDMwOCZhbXA7aD0yNjczNzMwJmFt cDtkYXRlPTIwMTktNS0yMSZhbXA7c2xuPTE3LTE4PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJh bmNlc2NhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBh ZGRpbmc9IjAiIGFsaWduPSJsZWZ0IiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+ DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6My43NXB0IDBjbSAwY20gMGNtIj4N Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi IGFsaWduPSJsZWZ0IiB3aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQ7bWFyZ2luLWxl ZnQ6My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp bmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIu MjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0i MCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8 dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3Vu ZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hv ci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM0RDRENEQiPkhlbGxvLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N CjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ny41cHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpm cmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJv dW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5j aG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzRENEQ0RCI+Q0JPUiBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpv aW4gdGhpcyBXZWJleCBtZWV0aW5nLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwv dHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNl OjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGlj YWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRl cj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+ DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJh bWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNo b3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVt bjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv dGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21z by1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1l bnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28t ZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHki Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5n PSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8 dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQt ZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1h bmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNv bHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0 RDRENEQiPkNCT1IgV0cgQ29uZmVyZW5jZSBDYWxsPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM0RDRENEQiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+ DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1l bnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVu dC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFs OmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2 NjY2NjYiPk9jY3VycyBldmVyeSAyIHdlZWsocykgb24gV2VkbmVzZGF5IGVmZmVjdGl2ZSBXZWRu ZXNkYXksIE1heSAyMiwgMjAxOSB1bnRpbCBXZWRuZXNkYXksIE5vdmVtYmVyIDYsIDIwMTkgZnJv bSA1OjAwIFBNIHRvIDY6MDAgUE0sIChVVEMmIzQzOzAxOjAwKSBBbXN0ZXJkYW0sIEJlcmxpbiwg QmVybiwgUm9tZSwgU3RvY2tob2xtLA0KIFZpZW5uYSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVu dDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+NTowMCBwbSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDtF dXJvcGUgU3VtbWVyIFRpbWUgKEFtc3RlcmRhbSwgR01UJiM0MzswMjowMCkmbmJzcDsmbmJzcDt8 Jm5ic3A7Jm5ic3A7MSBocg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVw dDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFy YWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1 bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MGNtO3dpZHRoOmF1dG8haW1w b3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50 LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVs ZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2Rl KTogNjQxIDc2MCAxNTcNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNl bGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbTt3aWR0aDphdXRvIWltcG9y dGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVs ZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13 cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVt ZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPk1lZXRpbmcgcGFzc3dvcmQ6IFVQQXQ5ckJuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtsaW5lLWhlaWdo dDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVw dDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFy YWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1 bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJv ZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAw Y20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVt ZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3Jh cDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVu dC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbTt3aWR0aDphdXRvIWltcG9ydGFudCI+DQo8dGJvZHk+ DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO3dpZHRoOmF1dG8haW1w b3J0YW50Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMSIgY2VsbHNw YWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbTtiYWNr Z3JvdW5kOiMwNDhDQkY7Ym9yZGVyOnNvbGlkICMwNDhDQkYgMS41cHQ7d2lkdGg6YXV0byFpbXBv cnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5nOjEw LjVwdCAxNS4wcHQgMTAuNXB0IDE1LjBwdDt3aWR0aDphdXRvIWltcG9ydGFudDttaW4td2lkdGg6 IDE4NnB4IWltcG9ydGFudCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz dHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZy YW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91 bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNo b3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNjY2NjY2Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYv ai5waHA/TVRJRD1tMWQwNjM2MDY5YTI4YmQ3YzhjYzA5MGU3NDE1NjVjOGMiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTUuMHB0O2NvbG9yOndoaXRlO3RleHQtZGVjb3JhdGlvbjpub25lIj5BZGQg dG8gQ2FsZW5kYXI8L3NwYW4+PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwv dHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBj bSAwY20gMGNtO3dpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFs VGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0i MCIgc3R5bGU9IndpZHRoOjBjbTt3aWR0aDphdXRvIWltcG9ydGFudDttaW4td2lkdGg6MTg2cHgh aW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBj bSAxMi4wcHQ7d2lkdGg6YXV0byFpbXBvcnRhbnQ7bWluLXdpZHRoOjE4NnB4IWltcG9ydGFudCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVt ZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3Jh cDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVu dC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5XaGVuIGl0J3MgdGltZSwNCjxhIGhyZWY9Imh0dHBz Oi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xMjM3YTk4MTI0MTExZGUzYTRjNGU2 MWRmYWNhMDVkNSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRlY29yYXRpb246 bm9uZSI+am9pbiB0aGUgbWVldGluZzwvc3Bhbj48L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+ DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1l bGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7 bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFj dGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRl cj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+ DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJh bWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNo b3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVt bjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv dGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21z by1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1l bnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28t ZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHki Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIw IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0 Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFt ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzY2NjY2NiI+Sm9pbiBieSBwaG9uZTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojNjY2NjY2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzY2NjY2NiI+PGEgaHJlZj0idGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQxNzYwMTU3 JTIzJTIzKjAxKiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFGRjk7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPjEtNjUwLTQ3OS0zMjA4PC9zcGFuPjwvYT48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzY2NjY2NiI+DQogQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAw Y20gMGNtIDBjbSI+PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJo ZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0 OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVs ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0 bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRo PSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxhIGhy ZWY9Imh0dHBzOi8vY29sbGFib3JhdGlvbmhlbHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5 MDU1Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRlY29yYXRpb246bm9uZSI+Q2Fu J3Qgam9pbiB0aGUgbWVldGluZz8NCjwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJh bWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNo b3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVt bjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7 ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9 Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNTI1IiBz dHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6Ny41cHQi Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6Ny41cHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saW5lLWhlaWdodC1hbHQ6Ny41cHQ7bXNvLWVs ZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13 cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVt ZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZy YW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5j aG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1 bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2 O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNz PSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIg c3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGlu ZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4y NXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojQTBBMEEwIj5JTVBPUlRBTlQgTk9U SUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5k IG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVk LCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5n DQogdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3Jk aW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlv dXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90 ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv dGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DB11DF949502424C8D1901A038BF086Dericssoncom_-- --_004_DB11DF949502424C8D1901A038BF086Dericssoncom_ Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Description: Webex_Meeting.ics Content-Disposition: attachment; filename="Webex_Meeting.ics"; size=6673; creation-date="Tue, 21 May 2019 09:51:58 GMT"; modification-date="Tue, 21 May 2019 09:51:58 GMT" Content-ID: <1341544B0B56E64FBAC12EF0A9914F92@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkV1cm9wZS9BbXN0ZXJkYW0NClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8vRXVyb3BlL0Ftc3RlcmRhbQ0KWC1MSUMtTE9DQVRJT046RXVyb3BlL0Ftc3RlcmRhbQ0K QkVHSU46REFZTElHSFQNClRaT0ZGU0VURlJPTTorMDEwMA0KVFpPRkZTRVRUTzorMDIwMA0KVFpO QU1FOkNFU1QNCkRUU1RBUlQ6MTk4MTAzMjlUMDIwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1P TlRIPTM7QllEQVk9LTFTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpPRkZTRVRG Uk9NOiswMjAwDQpUWk9GRlNFVFRPOiswMTAwDQpUWk5BTUU6Q0VUDQpEVFNUQVJUOjE5OTYxMDI3 VDAzMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMDtCWURBWT0tMVNVDQpFTkQ6U1RB TkRBUkQNCkJFR0lOOlNUQU5EQVJEDQpUWk9GRlNFVEZST006KzAwMTkzMg0KVFpPRkZTRVRUTzor MDAxOTMyDQpUWk5BTUU6QU1UDQpEVFNUQVJUOjE4MzUwMTAxVDAwMDAwMA0KUkRBVEU6MTgzNTAx MDFUMDAwMDAwDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRBWUxJR0hUDQpUWk9GRlNFVEZST006KzAw MTkzMg0KVFpPRkZTRVRUTzorMDExOTMyDQpUWk5BTUU6TlNUDQpEVFNUQVJUOjE5MTYwNTAxVDAw MDAwMA0KUkRBVEU6MTkxNjA1MDFUMDAwMDAwDQpSREFURToxOTE3MDQxNlQwMjAwMDANClJEQVRF OjE5MTgwNDAxVDAyMDAwMA0KUkRBVEU6MTkxOTA0MDdUMDIwMDAwDQpSREFURToxOTIwMDQwNVQw MjAwMDANClJEQVRFOjE5MjEwNDA0VDAyMDAwMA0KUkRBVEU6MTkyMjAzMjZUMDIwMDAwDQpSREFU RToxOTIzMDYwMVQwMjAwMDANClJEQVRFOjE5MjQwMzMwVDAyMDAwMA0KUkRBVEU6MTkyNTA2MDVU MDIwMDAwDQpSREFURToxOTI2MDUxNVQwMjAwMDANClJEQVRFOjE5MjcwNTE1VDAyMDAwMA0KUkRB VEU6MTkyODA1MTVUMDIwMDAwDQpSREFURToxOTI5MDUxNVQwMjAwMDANClJEQVRFOjE5MzAwNTE1 VDAyMDAwMA0KUkRBVEU6MTkzMTA1MTVUMDIwMDAwDQpSREFURToxOTMyMDUyMlQwMjAwMDANClJE QVRFOjE5MzMwNTE1VDAyMDAwMA0KUkRBVEU6MTkzNDA1MTVUMDIwMDAwDQpSREFURToxOTM1MDUx NVQwMjAwMDANClJEQVRFOjE5MzYwNTE1VDAyMDAwMA0KUkRBVEU6MTkzNzA1MjJUMDIwMDAwDQpF TkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpUWk9GRlNFVEZST006KzAxMTkzMg0KVFpPRkZT RVRUTzorMDAxOTMyDQpUWk5BTUU6QU1UDQpEVFNUQVJUOjE5MTYxMDAxVDAwMDAwMA0KUkRBVEU6 MTkxNjEwMDFUMDAwMDAwDQpSREFURToxOTE3MDkxN1QwMzAwMDANClJEQVRFOjE5MTgwOTMwVDAz MDAwMA0KUkRBVEU6MTkxOTA5MjlUMDMwMDAwDQpSREFURToxOTIwMDkyN1QwMzAwMDANClJEQVRF OjE5MjEwOTI2VDAzMDAwMA0KUkRBVEU6MTkyMjEwMDhUMDMwMDAwDQpSREFURToxOTIzMTAwN1Qw MzAwMDANClJEQVRFOjE5MjQxMDA1VDAzMDAwMA0KUkRBVEU6MTkyNTEwMDRUMDMwMDAwDQpSREFU RToxOTI2MTAwM1QwMzAwMDANClJEQVRFOjE5MjcxMDAyVDAzMDAwMA0KUkRBVEU6MTkyODEwMDdU MDMwMDAwDQpSREFURToxOTI5MTAwNlQwMzAwMDANClJEQVRFOjE5MzAxMDA1VDAzMDAwMA0KUkRB VEU6MTkzMTEwMDRUMDMwMDAwDQpSREFURToxOTMyMTAwMlQwMzAwMDANClJEQVRFOjE5MzMxMDA4 VDAzMDAwMA0KUkRBVEU6MTkzNDEwMDdUMDMwMDAwDQpSREFURToxOTM1MTAwNlQwMzAwMDANClJE QVRFOjE5MzYxMDA0VDAzMDAwMA0KRU5EOlNUQU5EQVJEDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZT RVRGUk9NOiswMTE5MzINClRaT0ZGU0VUVE86KzAxMjANClRaTkFNRTorMDEyMA0KRFRTVEFSVDox OTM3MDcwMVQwMDAwMDANClJEQVRFOjE5MzcwNzAxVDAwMDAwMA0KRU5EOkRBWUxJR0hUDQpCRUdJ TjpTVEFOREFSRA0KVFpPRkZTRVRGUk9NOiswMTIwDQpUWk9GRlNFVFRPOiswMDIwDQpUWk5BTUU6 KzAwMjANCkRUU1RBUlQ6MTkzNzEwMDNUMDMwMDAwDQpSREFURToxOTM3MTAwM1QwMzAwMDANClJE QVRFOjE5MzgxMDAyVDAzMDAwMA0KUkRBVEU6MTkzOTEwMDhUMDMwMDAwDQpFTkQ6U1RBTkRBUkQN CkJFR0lOOkRBWUxJR0hUDQpUWk9GRlNFVEZST006KzAwMjANClRaT0ZGU0VUVE86KzAxMjANClRa TkFNRTorMDEyMA0KRFRTVEFSVDoxOTM4MDUxNVQwMjAwMDANClJEQVRFOjE5MzgwNTE1VDAyMDAw MA0KUkRBVEU6MTkzOTA1MTVUMDIwMDAwDQpFTkQ6REFZTElHSFQNCkJFR0lOOkRBWUxJR0hUDQpU Wk9GRlNFVEZST006KzAwMjANClRaT0ZGU0VUVE86KzAyMDANClRaTkFNRTpDRVNUDQpEVFNUQVJU OjE5NDAwNTE2VDAwMDAwMA0KUkRBVEU6MTk0MDA1MTZUMDAwMDAwDQpFTkQ6REFZTElHSFQNCkJF R0lOOlNUQU5EQVJEDQpUWk9GRlNFVEZST006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClRaTkFN RTpDRVQNCkRUU1RBUlQ6MTk0MjExMDJUMDMwMDAwDQpSREFURToxOTQyMTEwMlQwMzAwMDANClJE QVRFOjE5NDMxMDA0VDAzMDAwMA0KUkRBVEU6MTk0NDEwMDJUMDMwMDAwDQpSREFURToxOTQ1MDkx NlQwMzAwMDANClJEQVRFOjE5NzcwOTI1VDAzMDAwMA0KUkRBVEU6MTk3ODEwMDFUMDMwMDAwDQpS REFURToxOTc5MDkzMFQwMzAwMDANClJEQVRFOjE5ODAwOTI4VDAzMDAwMA0KUkRBVEU6MTk4MTA5 MjdUMDMwMDAwDQpSREFURToxOTgyMDkyNlQwMzAwMDANClJEQVRFOjE5ODMwOTI1VDAzMDAwMA0K UkRBVEU6MTk4NDA5MzBUMDMwMDAwDQpSREFURToxOTg1MDkyOVQwMzAwMDANClJEQVRFOjE5ODYw OTI4VDAzMDAwMA0KUkRBVEU6MTk4NzA5MjdUMDMwMDAwDQpSREFURToxOTg4MDkyNVQwMzAwMDAN ClJEQVRFOjE5ODkwOTI0VDAzMDAwMA0KUkRBVEU6MTk5MDA5MzBUMDMwMDAwDQpSREFURToxOTkx MDkyOVQwMzAwMDANClJEQVRFOjE5OTIwOTI3VDAzMDAwMA0KUkRBVEU6MTk5MzA5MjZUMDMwMDAw DQpSREFURToxOTk0MDkyNVQwMzAwMDANClJEQVRFOjE5OTUwOTI0VDAzMDAwMA0KRU5EOlNUQU5E QVJEDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9GRlNFVFRPOiswMjAw DQpUWk5BTUU6Q0VTVA0KRFRTVEFSVDoxOTQzMDMyOVQwMjAwMDANClJEQVRFOjE5NDMwMzI5VDAy MDAwMA0KUkRBVEU6MTk0NDA0MDNUMDIwMDAwDQpSREFURToxOTQ1MDQwMlQwMjAwMDANClJEQVRF OjE5NzcwNDAzVDAyMDAwMA0KUkRBVEU6MTk3ODA0MDJUMDIwMDAwDQpSREFURToxOTc5MDQwMVQw MjAwMDANClJEQVRFOjE5ODAwNDA2VDAyMDAwMA0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFS RA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9GRlNFVFRPOiswMTAwDQpUWk5BTUU6Q0VUDQpEVFNU QVJUOjE5NzcwMTAxVDAwMDAwMA0KUkRBVEU6MTk3NzAxMDFUMDAwMDAwDQpFTkQ6U1RBTkRBUkQN CkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KRFRTVEFNUDoyMDE5MDUyMVQwOTQyNTFaDQpB VFRFTkRFRTtDTj0iQ0JPUiBXb3JraW5nIEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQ PVRSVUU6TUFJTFRPOmNib3ItY2hhaXJzQGlldGYub3JnDQpPUkdBTklaRVI7Q049IkNCT1IgV29y a2luZyBHcm91cCI6TUFJTFRPOmNib3ItY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9RXVy b3BlL0Ftc3RlcmRhbToyMDE5MDUyMlQxNzAwMDANCkRURU5EO1RaSUQ9RXVyb3BlL0Ftc3RlcmRh bToyMDE5MDUyMlQxODAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zg0K VFJBTlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU1ODQzMTc3MQ0KVUlEOjAyNmY1ZDFmLTRhYTUtNDA2 OS1hNWI3LWJlY2I5ZmVjZmRlOQ0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJ Tkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xMjM3YTk4MTI0MTEx ZGUzYTRjNGU2MWRmYWNhMDVkNVxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQxIDc2 MCAxNTdcbk1lZXRpbmcgcGFzc3dvcmQ6IFVQQXQ5ckJuXG5cblxuXG5KT0lOIEJZIFBIT05FXG4x LTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0 byBjYWxsIChtb2JpbGUgcGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJC MS02NTAtNDc5LTMyMDgsLCowMSo2NDE3NjAxNTclMjMlMjMqMDEqXG5cblxuXG5cbkNhbid0IGpv aW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNvbS9hcnRp Y2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQg dGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2Vu dCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3Zl cmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0 b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25z ZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9z dCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQtREVTQztGTVRUWVBFPXRleHQv aHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNF PSJBUklBTCI+XG4JCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9N VElEPW0xMjM3YTk4MTI0MTExZGUzYTRjNGU2MWRmYWNhMDVkNSI+PEZPTlQgU0laRT0iMyIgQ09M T1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYmV4IG1lZXRpbmc8L0ZPTlQ+PC9hPlxu CQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMiIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2 NDEgNzYwIDE1NzwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT5cbgkJ CVxuCQkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9 ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAg Q09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5VUEF0OXJCbjwvRk9OVD48L3RkPjwvdHI+PC90 YWJsZT5cbgkJPC9GT05UPlxuPGJyPjxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIj48L0ZP TlQ+PGJyPlxuPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+ PC9GT05UPlxuXG5cbiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05U IFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9O VD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PjxiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjY0MTc2MDE1NyUyMyUyMyow MSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Jz4xLTY1MC00 NzktMzIwODwvYT48L2I+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZu YnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48L0ZP TlQ+Jm5ic3A7IDxCUj48QlI+PEJSPlxuXG5cblxuCSZuYnNwOzxCUj5cbgk8YSBocmVmPSJodHRw czovL2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NSI+XG4J PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5DYW4ndCBqb2luIHRo ZSBtZWV0aW5nPzwvRk9OVD48L2E+XG4JJm5ic3A7PEJSPiZuYnNwOzxCUj5cblxuPEZPTlQgQ09M T1I9IiNBMEEwQTAiIHNpemU9IjEiIEZBQ0U9ImFyaWFsIj5JTVBPUlRBTlQgTk9USUNFOiBQbGVh c2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGlu Zm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBt YXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vz c2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlv dSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5z IHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uPC9GT05UPlxuPC9GT05U PlxuDQpTVU1NQVJZOkNCT1IgV0cgQ29uZmVyZW5jZSBDYWxsDQpQUklPUklUWTo1DQpDTEFTUzpQ VUJMSUMNClJSVUxFOkZSRVE9V0VFS0xZO1dLU1Q9U1U7VU5USUw9MjAxOTExMDY7SU5URVJWQUw9 MjtCWURBWT1XRQ0KQkVHSU46VkFMQVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElTUExBWQ0K REVTQ1JJUFRJT046UmVtaW5kZXINCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5E QVINCg== --_004_DB11DF949502424C8D1901A038BF086Dericssoncom_-- From nobody Wed May 22 07:34:34 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 465D512013E; Wed, 22 May 2019 07:34:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <155853566619.11385.15062703999098868761@ietfa.amsl.com> Date: Wed, 22 May 2019 07:34:26 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-array-tags-04.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 14:34:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF. Title : Concise Binary Object Representation (CBOR) Tags for Typed Arrays Author : Carsten Bormann Filename : draft-ietf-cbor-array-tags-04.txt Pages : 15 Date : 2019-05-22 Abstract: The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. The present document makes use of this extensibility to define a number of CBOR tags for typed arrays of numeric data, as well as two additional tags for multi-dimensional and homogeneous arrays. It is intended as the reference document for the IANA registration of the CBOR tags defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-array-tags-04 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-array-tags-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-array-tags-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 22 07:38:48 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 52552120133 for ; Wed, 22 May 2019 07:38:46 -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 JQEI_2v8NA1M for ; Wed, 22 May 2019 07:38:43 -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 7641E12013F for ; Wed, 22 May 2019 07:38:40 -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 458FcZ3tpHzybH; Wed, 22 May 2019 16:38:38 +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: <155853566619.11385.15062703999098868761@ietfa.amsl.com> Date: Wed, 22 May 2019 16:38:37 +0200 X-Mao-Original-Outgoing-Id: 580228716.0908509-b12932892623f402ed11ebe5721317fe Content-Transfer-Encoding: quoted-printable Message-Id: <5CFCEA51-91EB-4FD3-9837-A712DAF7AADD@tzi.org> References: <155853566619.11385.15062703999098868761@ietfa.amsl.com> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-array-tags-04.txt 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, 22 May 2019 14:38:46 -0000 This is the version that should be addressing all WGLC comments. Please check whether yours are properly handled. I had a bit of a problem with issue 7, = https://github.com/cbor-wg/array-tags/issues/7 because I believe the current text already says what needs to be said. Jeffrey: I would welcome some hints how that can be improved. See (hear) you all in 22 minutes=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten > On May 22, 2019, at 16:34, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Concise Binary Object Representation = Maintenance and Extensions WG of the IETF. >=20 > Title : Concise Binary Object Representation (CBOR) = Tags for Typed Arrays > Author : Carsten Bormann > Filename : draft-ietf-cbor-array-tags-04.txt > Pages : 15 > Date : 2019-05-22 >=20 > Abstract: > The Concise Binary Object Representation (CBOR, RFC 7049) is a data > format whose design goals include the possibility of extremely small > code size, fairly small message size, and extensibility without the > need for version negotiation. >=20 > The present document makes use of this extensibility to define a > number of CBOR tags for typed arrays of numeric data, as well as two > additional tags for multi-dimensional and homogeneous arrays. It is > intended as the reference document for the IANA registration of the > CBOR tags defined. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-cbor-array-tags-04 > https://datatracker.ietf.org/doc/html/draft-ietf-cbor-array-tags-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-array-tags-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Wed May 22 07:40:58 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 67E52120133; Wed, 22 May 2019 07:40:57 -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 jHQ0YBiXMiC6; Wed, 22 May 2019 07:40:56 -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 12B7912006A; Wed, 22 May 2019 07:40: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 458Fg72hBczyVM; Wed, 22 May 2019 16:40: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: Date: Wed, 22 May 2019 16:40:50 +0200 Cc: draft-ietf-cbor-cddl@ietf.org, Daniel P X-Mao-Original-Outgoing-Id: 580228849.442553-ff3fa15a6f67ae208aba681c477e130c Content-Transfer-Encoding: quoted-printable Message-Id: <9F4CA526-496B-4B5F-861C-EA755A822ADA@tzi.org> References: To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Question about draft-ietf-cbor-cddl-08 abnf 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, 22 May 2019 14:40:57 -0000 On May 17, 2019, at 23:11, Carsten Bormann wrote: >=20 > hexfloat =3D [=E2=80=9C-"] "0x" 1*HEXDIG ["." 1*HEXDIG] =E2=80=9Cp" = exponent Daniel already confirmed off-list that he also thinks this fixes the = bug. I would like to bring this up briefly at the interim in 19 minutes so we = can agree this should be fixed in AUTH48. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 22 11:29:35 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 DE88C1200FF for ; Wed, 22 May 2019 11:29:33 -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 8HJl_Bngoy8A for ; Wed, 22 May 2019 11:29:31 -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 1CE271200D8 for ; Wed, 22 May 2019 11:29:31 -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; Wed, 22 May 2019 11:29:25 -0700 From: Jim Schaad To: Date: Wed, 22 May 2019 11:29:21 -0700 Message-ID: <008d01d510cc$47b932f0$d72b98d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdUQy69DHR/Seo6ISD+rHc0+KoR0sw== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Rechartering Process 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, 22 May 2019 18:29:34 -0000 During the virtual meeting today, one of the items on the agenda was to bash the proposed charter update. Below is the output of that process. The intention is to review the charter again at the next meeting in two weeks and if there are no issues then to send it to the IESG for approval. You can send messages to the mailing list, setup a pull request at https://github.com/cbor-wg/charter/ or come onto the next call if you want to suggest changes. Jim Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 7159) data interchange format to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., CORE, ANIMA GRASP) as a message format. The CBOR working group will update RFC 7049 to fix verified errata. Security issues and clarifications may be addressed, but changes to the document will ensure backward compatibility for popular deployed codebases. The resulting document will be targeted at becoming a Full Internet Standard. After that, the CBOR working group will monitor issues found with the CBOR specification and, if needed, will produce an updated document. Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of valid messages in a text representation, it is useful for protocol specifications to use a description format for the data in CBOR-encoded messages. The Concise Data Definition Language (CDDL) is such a description technique that has already been used in CORE, ANIMA, CDNI, and efforts outside the IETF. CDDL has been published as RFC XXXX. While this specification has been completed, several new features were raised during the update process that were not included, in order not to delay publication, and to allow publication in the Standards Track. One example of such a feature is the ability to combine multiple CDDL files together using a mechanism other that manually concatenating them together for processing. The working group will collect these features as well as other features that are raised by users of CDDL, evaluate their utility and add to a second edition of the specification if warranted. The working group will define the approach to further evolving CDDL as a sequence of editions, which might also add further extension points, probably as part of the introduction of the next edition of the CDDL base specification. The body of existing specifications that make use of CDDL is considered precious, and the WG will set out not to damage their value. The working group will evaluate the necessity of providing advice and guidance for developers using CBOR and CDDL. It is currently expected that this would be done using a Wiki of some type. This work would not be expected to be published by the IETF. There are a number of additional CBOR tagged types that are either currently adopted by the working group, by other working groups, or as individual submissions. Additionally, there are expected to be other such documents that will come to the attention of the working group. In some cases, the working group expects to adopt and publish these proposals. The working group will evaluate and place proposals in one of the following categories using a dispatch like process: * General purpose tagged types that are expected to have broad usage: The working group will normally adopt and publish such proposals. Examples of proposals in this category are CBOR Sequence (draft-bormann-cbor-sequence) and Error Indications (draft-richter-cbor-error-tag). * Internet wide specific purpose tagged types: The working group may decide to adopt these proposals, but typically it would just provide input and recommend that they be published either as an Independent Submission or by a different working group. * Narrow purpose tagged types: The working group may provide evaluation of such proposals, but typically would not support Working Group adoption, and could recommend publication in a different forum. An example of this might be portions of draft-bormann-cbor-tags-oid dealing with some of the more esoteric types such as regular expressions From nobody Thu May 23 01:36:01 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 3E86612002F for ; Thu, 23 May 2019 01:36:00 -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, HTML_MESSAGE=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 559Z2azdAn8u for ; Thu, 23 May 2019 01:35:56 -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 30B8112016B for ; Thu, 23 May 2019 01:35:55 -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 458jWX2XZbz100P; Thu, 23 May 2019 10:35:52 +0200 (CEST) From: Carsten Bormann Content-Type: multipart/alternative; boundary="Apple-Mail=_91F119A0-2946-44EC-9205-6E4E5C0951E2" X-Mao-Original-Outgoing-Id: 580293349.927292-0e96c3c820d9b5dc44d360b0f8e408a0 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 23 May 2019 10:35:51 +0200 Message-Id: References: <00df01d5113d$49183c60$4001a8c0@gateway.2wire.net> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] Fwd: [Ext] Re: [rfc-i] Evolving document sources over a long time (Re: Comments on draft-roach-bis-documents-00) 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: Thu, 23 May 2019 08:36:00 -0000 --Apple-Mail=_91F119A0-2946-44EC-9205-6E4E5C0951E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Re our yesterday=E2=80=99s discussion on updating the IANA = considerations section for CBORbis: I think we should have all IANA procedures/policies laid out completely = in CBORbis (I think we have said there will be some small updates). There is no need to repeat the assignments from RFC 7049, except where = the rest of the document might depend on them (need to check; e.g., in = Section 8.2, we could just state that the assignments include those from = Table 3). I don=E2=80=99t think there will be new assignments. =20 But we probably want to ask IANA to update the existing assignments to = the new RFC number. See below for another place where the issue of updating IANA = considerations in evolved documents came up and not everybody was happy = with the solution used. (Please note that Tom Petch doesn=E2=80=99t use conventional mail = quoting style, so his text is interspersed with Andy=E2=80=99s. Please follow the archive link below for more context on the rfc-i = discussion.) Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: tom petch > > Subject: Re: [Ext] Re: [rfc-i] Evolving document sources over a long = time (Re: Comments on draft-roach-bis-documents-00) > Date: May 23, 2019 at 10:02:16 GMT+2 > To: "Andrew G. Malis" >, = David Noveck > > Cc: Michelle Cotton >, IETF Discussion Mailing List = > > Archived-At: = > >=20 > ----- Original Message ----- > From: "Andrew G. Malis" > > Sent: Tuesday, May 21, 2019 7:13 PM >=20 > David, >=20 > A good suggestion, but it might be easier for IANA to just have two > subsections in the IANA Considerations section: >=20 > - What IANA Now Needs to Do (this could be nothing, but should be > explicit) >=20 > - What IANA Already Did in RFC XXXX >=20 > and keep this section identical to the original RFC. >=20 > Of course, we should ask Michelle what she would like to see! :-) >=20 > >=20 > Why? >=20 > The purpose of an RFC is to provide information for the community so = my > starting point is what is it that the community wants to see. Once = that > is determined, then then is the time to ask Michele and company what > they want to see to ensure that the section meets those requirements. >=20 > I make frequent reference to the IANA Considerations section of RFC > going back decades, because they constrain what can and cannot be done > now, and it is a pain when the information is scattered across = multiple > RFC, or when the key RFC is badly worded, ambiguous. Examples of the > latter keep cropping up. >=20 > So, I would say that an IANA Considerations should be complete and > should never say this is what we did last time and here is a delta for > you to (mis-)apply. >=20 > A minor example of this is RFC7950 which many cite in the IANA > Considerations of an I-D containing a YANG module in order that the = YANG > modules is registered with IANA. Wrong! All that RFC7950 says is = that > the procedure is described in RFC6020 so you have to get out RFC6020 = to > know what to do and the sort-of-obsolete RFC6020 then has to be a > Normative Reference of the new I-D. Far better if the authors of > RFC7950 had included the procedure for registering a YANG module; > instead, RFC6020 remains a Normative Reference unless and until a YANG > 1.2 or YANG 2.0 appears and addresses the problem. >=20 > Tom Petch. >=20 > Cheers, > Andy >=20 >=20 > On Tue, May 21, 2019 at 1:51 PM David Noveck > > wrote: >=20 >> Good point. >>=20 >> The IANA Considerations section in non-update RFC's primarily serves > as a >> means if requesting IANA actions. When you consider how this maps to > bis >> documents and bis-like updates, there is a conflict between IANA's >> expectations and Adam's desire to have the updated document be = current > as a >> whole, with discussion of changes put in an appendix, It might be > possible >> to point out the actions required in the appendix but I have been > thinking >> of the following as an alternative: >>=20 >> - Create, at the start of the IANA Considerations section, a new >> subsection entitled "What IANA now needs to do". >> - For the rest of the section, organize as it would be with updates >> included in appropriate places, but distinguish, using > tense/auxiliaries >> between things that IANA has already done and those that it has yet > to do. >>=20 >>=20 >>=20 >> On Tue, May 21, 2019 at 10:03 AM Michelle Cotton > > >> wrote: >>=20 >>> Additional comments related to IANA Considerations for bis = documents: >>> What is most important is that the document clearly states what > should be >>> updated and what should not. We have seen varying instructions in > bis >>> documents where some replace all references and some replace just > some. If >>> authors can give clear and accurate instructions on what IANA is > being >>> requested to do, that is appreciated. >>>=20 >>>=20 >>>=20 >>> Hope this is helpful. >>>=20 >>>=20 >>>=20 >>> Thanks, >>>=20 >>> Michelle >>>=20 >>>=20 >>>=20 >>> *From: *ietf > = on behalf of Adam Roach < >>> adam@nostrum.com > >>> *Date: *Sunday, May 19, 2019 at 2:00 PM >>> *To: *David Noveck >, Magnus Westerlund < >>> magnus.westerlund@ericsson.com = > >>> *Cc: *Julian Reschke >, Carsten Bormann < >>> cabo@tzi.org >, IETF Discussion Mailing List = > >>> *Subject: *[Ext] Re: [rfc-i] Evolving document sources over a long > time >>> (Re: Comments on draft-roach-bis-documents-00) >>>=20 >>>=20 >>>=20 >>> Thanks for the feedback! These seem like reasonable changes for the > next >>> version. >>>=20 >>>=20 >>>=20 >>> /a >>>=20 >>>=20 >>>=20 >>> On 5/19/19 9:54 AM, David Noveck wrote: >>>=20 >>> Thanks to everyone for their suggestions. Now that I've followed = up > on >>> many of them, I'd like to tell everybody what I've found so that > people can >>> consider the implicationss for Adam's document and for the = processing > of >>> upcoming updates to RFC5661. In particular, use of the existing v1 > tools >>> has proved quite helpful although it is not a panacea. >>>=20 >>>=20 >>>=20 >>> So what I've found is that: >>>=20 >>> - Even with the v1 xml2rfc, the .xml that I have gotten for > RFC5661 >>> from the RFC editor cannot be successfully processed. Whether > you use the >>> existing v2 xml2rfc or the v1 xml2rfc available on the web, > considerable >>> effort is required to get to an xml that can be processed > successfully. >>> The xml file I received from the RFC editor is attached as > rfc5661Base.xml >>> while the one I arrived at is attached as rfc5661Ready.xml. >>> - Processing of the best xml that I have been able to arrive at > for >>> rfc5661 using the current v2 xml2rfc results in a document which, > when >>> compared with rfc5661 using rfcdiff, has a large number of > differences >>> which might be considered spurious. Although I don't feel any of > these are >>> in fact spurious, they are numerous enough that it might be hard > to make >>> this determination quickly. The largest part of these differences > concern >>> text tables which rfcdiff flags as different even in cases in > which the >>> tables seem identical. Also, there re small formtting > differences that >>> resul from the use of the v2 xml2rfc as well as issues arsing from >>> different handling policies for hyphenated words. I've attached > the >>> resulting .txt file as rfc5661Ready.txt so that people can rfcdiff > it >>> against rfc5661. >>> - Processing of the best xml that I have been able to arrive at > for >>> rfc5661 using the v1 xml2rfc available on the web results in a > document >>> which, when compared with rfc5661 using rfcdiff, shows a small > number of >>> differences but is not identical to rfc5661. Besides the small > set of >>> difference mentioned below, common to both v1 and v2 xml2rfc, the > main >>> issue concerns a number of cases in which the xml (and rfc5661) > has two >>> spaces following a period while the v1 xml2rfc has only a single > space. >>> This is a formatting change but if it is considered "spurious", > then that >>> spurious change is unavoidable when using the v1 xml2rfc. It can > be >>> avoided using the v2 xml2rfc but that causes many more differences > with >>> rfc5661, as discusssed above. I've attached the resulting .txt > file as >>> rfc5661ReadyV1.txt so that people can rfcdiff it against rfc5661. >>> - In addition there are a few differences that appear whether the > v1 >>> or v2 xml2rfc is used. >>>=20 >>>=20 >>> - One source of these concerrns the capitalization (or not) of the >>> words "profile" and "type" in the titles of many > stringprep-related >>> sections. Since RFC5661 uses different forms in the section > itself and in >>> the table-of-contents, it is impossible to avoid one of those > being >>> different from RFC5661. >>> - Other problems arise from the different lengths of >>> xml2rfc-generated introductory material before the table of > contents. The >>> page count is different for v1 and v2 but both differ from > rfc5661.. >>> - References to ancohor are handled differently in v1 and v2 > but >>> neither can be made to match the results in rfc5661. >>> - Another problem is that rfcdiff appears to have a bug > resulting >>> in it showing that a significant piece of the definition of > CB_COMPOUND is >>> missing, even though the .txt file shows no such difference :-( >>>=20 >>> Based on my experences, I'd like to suggest: >>>=20 >>> - That the following addition be made to item 3 in section 3.1 of >>> Adam's document. >>>=20 >>> In evaluating whether such disqualifying changes have occurred, it = is >>> intended that changes due solely to changes in the tools used to > generate >>> RFC .txt files be allowed. In addition, issues resulting from > changes made >>> by the RFC editor but not reflected in the xml file for the RFC not >>> interfere with IESG consideration of the document and can be made, = if >>> necessary, by the RFC editor after the revised documment is approved > for >>> publication. >>>=20 >>>=20 >>> - That the following addition be made to item 6 in section 3.1 of >>> Adam's document. >>>=20 >>> This will include the AD's determination that the requirements of > item 3 >>> above have been met. >>>=20 >>>=20 >>> - That, if possible, somebody should fix the bug in rfcdiff noted >>> above. >>>=20 >>>=20 >>>=20 >>> On Mon, May 13, 2019 at 5:22 AM David Noveck >>> > wrote: >>>=20 >>>>> For RFC5661 and documents derived from it using Adam=E2=80=99s = procedure, > that >>> ship has already sailed :-(.. >>>=20 >>>> As the references section needs to be updated anyway (for the > DOIs), >>> I=E2=80=99m not sure this is really true. Or, if it is, >>>=20 >>>> RFC 5661 maybe isn=E2=80=99t really a candidate for this process, = because > it >>> may be impractical to re-generate the exact >>>=20 >>>> numbering that RFC 5661 used. >>>=20 >>> I had been assuming that you could turn off sortrefs and construct a >>> reference section in the exact order that the >>>=20 >>> v1 tool. I'll try some experientsto validate that approach. >>>=20 >>>=20 >>> .> > > Since RFC 5661, we also got DOIs on RFCs, so it is inevitable >>> there are a lot of diffs. >>>>>=20 >>>>> It is not inevitable as shown by the fact that I didn't run into > that >>> issue. It's kind of nice to know that there was an issue out there > that I >>> didn't run into :-) >>>>>=20 >>>>> For reasons I really don't understand, the xml for rfc5661 does > not >>> include rfc reference from external libraries. It includes them > inline, >>> so a new rfc derived from that xml file will not include DOIs. >>>=20 >>>> Yes. All these RFC references would be updated by the RFC editor > into >>> current references. >>>=20 >>>=20 >>>=20 >>> That's not a problem for Adam's procedure :-). The RFC candidate >>> considred by the IESG would still match >>>=20 >>> rfc5661. Then, during RFC editing, the reference section could be >>> revised to include the DOI's. >>>=20 >>>>> That is not a problem for Adam's procedure, but it may be for the > IESG >>> or the RFC editor. I hope that, in processing RFC=E2=80=99s using = Adam's >>> procedure, people will overlook the lack of DOIs in the same way = that > they >>> overlook other aspects of the document that would prevent a new > document of >>> that form from being published. >>>=20 >>>> AFAICT, they can=E2=80=99t, as the RFC editor has committed to = providing > DOIs. >>>=20 >>>=20 >>>=20 >>> Please see above: >>>=20 >>> - The IESG doesn't have to deal with the DOI diffs, since it won't >>> see them. >>> - The RFC editor would create DOI diffs but not be bound by Adam's >>> procedure in doing so. >>>=20 >>> Where this might be a problem is in document where the existing xml > uses >>> external reference libraries. That avoids the need for the RFC to > do >>> anything to provide the DOI's other that updating the libraries. > However >>> the IESG will see the diffs resulting from the inclusion of DOI's so > I >>> would hope that Adam's document is clear thar they should not be > considered >>> "spurous". >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Sun, May 12, 2019 at 12:57 PM Carsten Bormann > > wrote: >>>=20 >>> Hi Julian, >>>=20 >>>> FWIW, I disagree (but I realize that I'm probably in a minority). > The >>>> problem with Markdown is that the simple things are easy, but > everything >>>> else gets messy. I'm looking forward to see how you kram (pun > intended) >>>> the V3 features into your tool=E2=80=A6 >>>=20 >>> Do I have to? >>>=20 >>> If an author wants to use a V3 feature that does not lend itself to >>> authoring in markdown, they can always put the XML tags right into > their >>> markdown source. >>>=20 >>>>>>> but that was the way things were done in 2010. >>>>>>=20 >>>>>> I=E2=80=99m prepared to stick with that, unless there is = something better >>> about the alternatives. >>>>>=20 >>>>> Right, for a minor update, digging out the v1 tools and finding a >>> platform where they can still run may actually be the best way to > proceed. >>>>=20 >>>> All you need is a TCL processor. Works fine over here on a newly >>>> installed notebook with Windows 10 and Cygwin. >>>=20 >>> Haven=E2=80=99t tried that in a while=E2=80=A6 >>> Works for me, too (macOS 10.13.6, on a small document, with the = usual >>> formatting differences from v2=E2=80=A6). >>> Good to know. >>> (Although I have heard people have had problems on other platforms >>> recently.) >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten --Apple-Mail=_91F119A0-2946-44EC-9205-6E4E5C0951E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Re = our yesterday=E2=80=99s discussion on updating the IANA considerations = section for CBORbis:

I= think we should have all IANA procedures/policies laid out completely = in CBORbis (I think we have said there will be some small = updates).
There is no need to repeat the = assignments from RFC 7049, except where the rest of the document might = depend on them (need to check; e.g., in Section 8.2, we could just state = that the assignments include those from Table 3).
I = don=E2=80=99t think there will be new assignments.  
But we probably want to ask IANA to update the existing = assignments to the new RFC number.

See below for another place where the = issue of updating IANA considerations in evolved documents came up and = not everybody was happy with the solution used.
(Please note that Tom Petch doesn=E2=80=99t use conventional = mail quoting style, so his text is interspersed with Andy=E2=80=99s.
=
Please follow the archive link below for more context on = the rfc-i discussion.)

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


Begin = forwarded message:

From: = tom petch <daedulus@btconnect.com>
Subject: = Re: [Ext] Re: = [rfc-i] Evolving document sources over a long time (Re: Comments on = draft-roach-bis-documents-00)
Date: = May 23, 2019 at 10:02:16 = GMT+2
To: = "Andrew G. Malis" <agmalis@gmail.com>, = David Noveck <davenoveck@gmail.com>
Cc: Michelle Cotton <michelle.cotton@iana.org>, IETF Discussion Mailing = List <ietf@ietf.org>
Archived-At: = <https://mailarchive.ietf.org/arch/msg/ietf/SdIsd9kzpTre33niG1Rw= zT9IwA0>

----- = Original Message -----
From: "Andrew G. Malis" <agmalis@gmail.com>
Sent: = Tuesday, May 21, 2019 7:13 PM

David,

A good suggestion, but it might be easier for IANA to just = have two
subsections = in the IANA Considerations section:

- What IANA Now Needs to Do (this could be nothing, but = should be
explicit)

- What IANA Already Did in RFC XXXX

and keep this = section identical to the original RFC.

Of course, we should ask Michelle what she would like to see! = :-)

<tp>

Why?

The purpose of an RFC is to provide information for the = community so my
starting point is what is it that the community wants to see. =  Once that
is determined, then then is the time to ask Michele and = company what
they want to = see to ensure that the section meets those requirements.

I make = frequent reference to the IANA Considerations section of RFC
going back = decades, because they constrain what can and cannot be done
now, and it = is a pain when the information is scattered across multiple
RFC, or when = the key RFC is badly worded, ambiguous.  Examples of =  the
latter keep = cropping up.

So, I would = say that an IANA Considerations should be complete and
should never = say this is what we did last time and here is a delta for
you to = (mis-)apply.

A minor = example of this is RFC7950 which many cite in the IANA
Considerations = of an I-D containing a YANG module in order that the YANG
modules is = registered with IANA.  Wrong!  All that RFC7950 says is = that
the procedure = is described in RFC6020 so you have to get out RFC6020 to
know what to = do and the sort-of-obsolete RFC6020 then has to be a
Normative = Reference of the new I-D.  Far better if the authors of
RFC7950 had = included the procedure for registering a YANG module;
instead, = RFC6020 remains a Normative Reference unless and until a YANG
1.2 or YANG = 2.0 appears and addresses the problem.

Tom Petch.

Cheers,
Andy


On Tue, May 21, 2019 at 1:51 PM David Noveck <davenoveck@gmail.com>
wrote:

Good point.

The IANA Considerations section in non-update RFC's primarily = serves
as a
means if requesting IANA actions. =  When you consider how this maps to
bis
documents and bis-like updates, there is a conflict between = IANA's
expectations and Adam's desire to have the updated = document be current
as a
whole, with discussion of changes put = in an appendix,  It might be
possible
to point out the actions required in = the appendix but I have been
thinking
of the following as an = alternative:

  - Create, at the = start of the IANA Considerations section, a new
  subsection entitled "What IANA now needs to = do".
  - For the rest of the section, organize = as it would be with updates
  included in = appropriate places, but distinguish, using
tense/auxiliaries
  between things that IANA = has already done and those that it has yet
to do.



On Tue, May 21, 2019 at 10:03 AM Michelle Cotton
<michelle.cotton@iana.org>
wrote:

Additional comments related to IANA Considerations for bis = documents:
What is most important is that the document = clearly states what
should = be
updated and what should = not.  We have seen varying instructions in
bis
documents where some replace all references and some replace = just
some.  If
authors can give clear and accurate instructions on what IANA = is
being
requested to do, that is appreciated.



Hope this is helpful.



Thanks,

Michelle



*From: *ietf <ietf-bounces@ietf.org> on behalf of Adam Roach <
adam@nostrum.com>
*Date: *Sunday, May = 19, 2019 at 2:00 PM
*To: *David Noveck <davenoveck@gmail.com>, Magnus Westerlund <
magnus.westerlund@ericsson.com>
*Cc: = *Julian Reschke <julian.reschke@gmx.de>, Carsten Bormann <
cabo@tzi.org>, IETF Discussion Mailing List <ietf@ietf.org>
*Subject: *[Ext] Re: [rfc-i] Evolving document sources over a = long
time
(Re: Comments on draft-roach-bis-documents-00)



Thanks for the = feedback! These seem like reasonable changes for the
next
version.



/a



On 5/19/19 9:54 AM, David Noveck wrote:

Thanks to everyone for their suggestions.   Now = that I've followed up
on
many of them, I'd like = to tell everybody what I've found so that
people can
consider the implicationss for Adam's document and for the = processing
of
upcoming updates to = RFC5661.   In particular, use of the existing v1
tools
has proved quite helpful although it is not a panacea.



So what I've = found is that:

  - Even with the = v1 xml2rfc, the .xml that I have gotten for
RFC5661
  from the RFC editor cannot be successfully = processed.   Whether
you use the
  existing v2 xml2rfc  or the v1 xml2rfc = available on the web,
considerable
  effort is required to get to an xml that can be = processed
successfully.
   The xml file I received from the RFC editor = is attached as
rfc5661Base.xml
  while the one I arrived at is attached as = rfc5661Ready.xml.
  - Processing of the best xml = that I have been able to arrive at
for
  rfc5661 using the current v2 xml2rfc results in a = document which,
when
  compared = with rfc5661 using rfcdiff,  has a large number of
differences
  which might be considered spurious. =  Although I don't feel any of
these are
  in fact spurious, they are numerous enough that = it might be hard
to = make
  this = determination quickly.  The largest part of these differences
concern
  text tables which rfcdiff flags as different even = in cases in
which = the
  tables seem = identical.   Also, there re small formtting
differences that
  resul from the use of the v2 xml2rfc as well as = issues arsing from
  different handling policies = for hyphenated words.  I've attached
the
  resulting .txt file as rfc5661Ready.txt so that = people can rfcdiff
it
  against = rfc5661.
  - Processing of the best xml that I = have been able to arrive at
for
  rfc5661 = using the v1 xml2rfc available on the web results in a
document
  which, when compared with rfc5661 using rfcdiff, = shows a small
number = of
  differences = but is not identical to rfc5661.   Besides the small
set of
  difference mentioned below, common to both v1 and = v2 xml2rfc, the
main
  issue = concerns a number of cases in which the xml (and rfc5661)
has two
  spaces following a period while the v1 xml2rfc = has only a single
space.
   This is a formatting change but if it is = considered "spurious",
then = that
  spurious = change is unavoidable when using the v1 xml2rfc.  It can
be
  avoided = using the v2 xml2rfc but that causes many more differences
with
  rfc5661, as discusssed above.   I've = attached the resulting .txt
file = as
  rfc5661ReadyV1.txt so that people can rfcdiff it = against rfc5661.
  - In addition there are a few = differences that appear whether the
v1
  or v2 = xml2rfc is used.


  -= One source of these concerrns the capitalization (or not) of the
     words "profile" and "type" in = the titles of many
stringprep-related
     sections.  Since RFC5661 = uses different forms in the section
itself and in
     the table-of-contents, it is = impossible to avoid one of those
being
     different from RFC5661.
     - Other problems arise from the = different lengths of
     xml2rfc-generated introductory = material before the table of
contents. =   The
     page count is different for v1 = and v2 but both differ from
rfc5661..
     - References to ancohor are = handled differently in v1 and v2
but
     neither can be made to match = the results in rfc5661.
     - = Another problem is that rfcdiff appears to have a bug
resulting
     in it showing that a = significant piece of the definition of
CB_COMPOUND is
     missing, even though the .txt = file shows no such difference :-(

Based on = my experences, I'd like to suggest:

  - That the following addition be made to item 3 = in section 3.1 of
  Adam's document.

In evaluating whether such disqualifying = changes have occurred, it is
intended that changes due = solely to changes in the tools used to
generate
RFC .txt files be allowed.  In addition, issues = resulting from
changes = made
by the RFC editor but = not reflected in the xml file for the RFC not
interfere = with IESG consideration of the document and can be made, if
necessary, by the RFC editor after the revised documment is = approved
for
publication.


  - That the = following addition be made to item 6 in section 3.1 of
  Adam's document.

This = will include the AD's determination that the requirements of
item 3
above have been met.


  - That, if possible, somebody should fix the bug = in rfcdiff noted
  above.



On Mon, May 13, 2019 at 5:22 AM = David Noveck <davenoveck@gmail.com
<davenoveck@gmail..com>> wrote:

For RFC5661 and documents derived from it using Adam=E2=80=99s = procedure,
that
ship has already sailed = :-(..

As= the references section needs to be updated anyway (for the
DOIs),
I=E2=80=99m not sure this is really true.  Or, if it = is,

RFC = 5661 maybe isn=E2=80=99t really a candidate for this process, because
it
may be impractical to = re-generate the exact

numbering that RFC 5661 used.

I had been assuming that you = could turn off sortrefs and construct a
reference section = in the exact order that the

v1 tool. =   I'll try some experientsto validate that approach.


.> > > Since RFC 5661, = we also got DOIs on RFCs, so it is inevitable
there are a = lot of diffs.

It is not = inevitable as shown by the fact that I didn't run into
that
issue.   It's = kind of nice to know that there was an issue out there
that I
didn't run into :-)

For = reasons I  really don't understand, the xml for rfc5661 does
not
include rfc reference = from external libraries.   It includes them
inline,
so= a new rfc derived from that xml  file will not include DOIs.

Yes. =  All these RFC references would be updated by the RFC editor
into
current references.



That's not a = problem for Adam's procedure :-).   The RFC candidate
considred by the IESG would still match

rfc5661.   Then, during RFC editing, the reference = section could be
revised to include the DOI's.

That is not a problem for Adam's procedure, = but it may be for the
IESG
or the RFC editor. =   I hope that, in processing RFC=E2=80=99s using Adam's
procedure, people will overlook the lack of DOIs in the same = way that
they
overlook other aspects = of the document that would prevent a new
document of
that form from being published.

AFAICT, they can=E2=80=99t= , as the RFC editor has committed to providing
DOIs.



Please see above:

  - The IESG doesn't have to deal with the DOI = diffs, since it won't
  see them.
  - The RFC editor would create DOI diffs but not = be bound by Adam's
  procedure in doing so.

Where this might be a problem is in document = where the existing xml
uses
external reference = libraries.   That avoids the need for the RFC to
do
anything to provide the = DOI's other that updating the libraries.
However
the IESG will see the diffs resulting from the inclusion of = DOI's so
I
would hope that Adam's = document is clear thar they should not be
considered
"spurous".





On Sun, May 12, 2019 at 12:57 = PM Carsten Bormann <cabo@tzi.org>
wrote:

Hi Julian,

FWIW, I disagree (but I = realize that I'm probably in a minority).
The
problem with Markdown is that the simple things are easy, = but
everything
else gets messy. I'm = looking forward to see how you kram (pun
intended)
the V3 features into = your tool=E2=80=A6

Do I have = to?

If an author wants to use a V3 feature = that does not lend itself to
authoring in markdown, they = can always put the XML tags right into
their
markdown source.

but that = was the way things were done in 2010.

I=E2=80=99m prepared to stick with that, unless there is = something better
about the = alternatives.

Right, = for a minor update, digging out the v1 tools and finding a
platform where they can still run = may actually be the best way to
proceed.

All you = need is a TCL processor. Works fine over here on a newly
installed notebook with Windows 10 and Cygwin.

Haven=E2=80=99t tried that in a = while=E2=80=A6
Works for me, too (macOS 10.13.6, on a = small document, with the usual
formatting differences from = v2=E2=80=A6).
Good to know.
(Although I have = heard people have had problems on other platforms
recently.)

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

= --Apple-Mail=_91F119A0-2946-44EC-9205-6E4E5C0951E2-- From nobody Thu May 23 13:57:43 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 1620A1200C1; Thu, 23 May 2019 13:57:42 -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 YhFcR1xBiXtf; Thu, 23 May 2019 13:57:40 -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 F3ECD120020; Thu, 23 May 2019 13:57:36 -0700 (PDT) Received: from [192.168.217.113] (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 4591zL3bnmzys4; Thu, 23 May 2019 22:57:34 +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 Date: Thu, 23 May 2019 22:57:33 +0200 Cc: draft-ietf-cbor-cddl.all@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 580337852.186537-9b5f7291b1c2a2116e220d98bb67e782 Content-Transfer-Encoding: quoted-printable Message-Id: <4852CAFD-E986-4576-8C90-C03B54F39DCF@tzi.org> To: RFC Editor X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] Correcting an error in draft-ietf-cbor-cddl-08 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: Thu, 23 May 2019 20:57:42 -0000 Dear RFC editor, a technical error was caught in draft-ietf-cbor-cddl-08, which is = currently at RFC-EDITOR stage. Please see the thread starting with https://mailarchive.ietf.org/arch/msg/cbor/sg5dpdCjaPw7mtohdAWCWgnQdMk for reference. We also discussed this at the last virtual interim meeting of the CBOR = working group, and we believe the following change to Appendix B is a = correct and complete fix: OLD: hexfloat =3D "0x" 1*HEXDIG ["." 1*HEXDIG] "p" exponent NEW: hexfloat =3D ["-"] "0x" 1*HEXDIG ["." 1*HEXDIG] "p" exponent At the meeting, we thought we should make you aware now, instead of = waiting for AUTH48. (The meeting minutes of the virtual interim have not yet been posted to = the proceedings at https://datatracker.ietf.org/doc/agenda-interim-2019-cbor-07-sessa/ but are captured in https://etherpad.tools.ietf.org/p/notes-interim-220519-cbor for reference.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 23 14:23:56 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 54810120127 for ; Thu, 23 May 2019 14:23:54 -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 PbYJpuMUfxhP for ; Thu, 23 May 2019 14:23:52 -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 1697F120108 for ; Thu, 23 May 2019 14:23:51 -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; Thu, 23 May 2019 14:23:45 -0700 From: Jim Schaad To: 'Carsten Bormann' , References: <155853566619.11385.15062703999098868761@ietfa.amsl.com> <5CFCEA51-91EB-4FD3-9837-A712DAF7AADD@tzi.org> In-Reply-To: <5CFCEA51-91EB-4FD3-9837-A712DAF7AADD@tzi.org> Date: Thu, 23 May 2019 14:23:43 -0700 Message-ID: <003101d511ad$ce1ba3f0$6a52ebd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHr7swzg0ZjOn9uzsF0MFdjF7mPNgHA1dkWpj0+ajA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-array-tags-04.txt 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: Thu, 23 May 2019 21:23:54 -0000 Carsten, I am not sure why the URL for the [TypedArray] reference got lost. It = was there in the previous version. I am happy with the way all of my issues have been addressed. Jim > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Wednesday, May 22, 2019 7:39 AM > To: cbor@ietf.org > Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-array-tags-04.txt >=20 > This is the version that should be addressing all WGLC comments. > Please check whether yours are properly handled. >=20 > I had a bit of a problem with issue 7, = https://github.com/cbor-wg/array- > tags/issues/7 > because I believe the current text already says what needs to be said. > Jeffrey: I would welcome some hints how that can be improved. >=20 > See (hear) you all in 22 minutes=E2=80=A6 >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 > > On May 22, 2019, at 16:34, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Concise Binary Object = Representation > Maintenance and Extensions WG of the IETF. > > > > Title : Concise Binary Object Representation (CBOR) = Tags for Typed > Arrays > > Author : Carsten Bormann > > Filename : draft-ietf-cbor-array-tags-04.txt > > Pages : 15 > > Date : 2019-05-22 > > > > Abstract: > > The Concise Binary Object Representation (CBOR, RFC 7049) is a = data > > format whose design goals include the possibility of extremely = small > > code size, fairly small message size, and extensibility without = the > > need for version negotiation. > > > > The present document makes use of this extensibility to define a > > number of CBOR tags for typed arrays of numeric data, as well as = two > > additional tags for multi-dimensional and homogeneous arrays. It = is > > intended as the reference document for the IANA registration of = the > > CBOR tags defined. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-cbor-array-tags-04 > > https://datatracker.ietf.org/doc/html/draft-ietf-cbor-array-tags-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-array-tags-04 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at = tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > CBOR mailing list > > CBOR@ietf.org > > https://www.ietf.org/mailman/listinfo/cbor > > >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Thu May 23 14:32:06 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 B7225120105 for ; Thu, 23 May 2019 14:32:04 -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 xEnWaKH_Tdnc for ; Thu, 23 May 2019 14:32:03 -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 116131200BA for ; Thu, 23 May 2019 14:32:03 -0700 (PDT) Received: from [192.168.217.113] (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 4592l53Zj2z1039; Thu, 23 May 2019 23:32:01 +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: <003101d511ad$ce1ba3f0$6a52ebd0$@augustcellars.com> Date: Thu, 23 May 2019 23:32:00 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 580339917.048799-d64feb031c8e885dc1f5dc1cf650070d Content-Transfer-Encoding: quoted-printable Message-Id: <50EF193E-642C-4391-92BF-083C5A1C0E16@tzi.org> References: <155853566619.11385.15062703999098868761@ietfa.amsl.com> <5CFCEA51-91EB-4FD3-9837-A712DAF7AADD@tzi.org> <003101d511ad$ce1ba3f0$6a52ebd0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-array-tags-04.txt 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: Thu, 23 May 2019 21:32:05 -0000 Hi Jim, On May 23, 2019, at 23:23, Jim Schaad wrote: >=20 > I am not sure why the URL for the [TypedArray] reference got lost. =20 That URL is now a dead link (actually redirects to ES6 spec, which we = already reference under a different anchor). This is one of the references that should be in a third section of the = References chapter (after =E2=80=9Cnormative=E2=80=9D and = =E2=80=9Cinformative=E2=80=9D), which should best be called = =E2=80=9Chistoric=E2=80=9D =E2=80=94 you don=E2=80=99t need to read it, = but it properly identifies the origin of some work. (I didn=E2=80=99t check archive.org, BTW, but I=E2=80=99m not sure that = we want to use that here.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 23 14:49:44 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 D533B120114 for ; Thu, 23 May 2019 14:49:42 -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 IcFVoWdJeFXr for ; Thu, 23 May 2019 14:49:41 -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 D0D45120043 for ; Thu, 23 May 2019 14:49:40 -0700 (PDT) Received: from [192.168.217.113] (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 45937R1FDNzyNr; Thu, 23 May 2019 23:49:39 +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: <50EF193E-642C-4391-92BF-083C5A1C0E16@tzi.org> Date: Thu, 23 May 2019 23:49:38 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 580340976.362482-61cb192b558934b664e17ee93b71a9c6 Content-Transfer-Encoding: quoted-printable Message-Id: References: <155853566619.11385.15062703999098868761@ietfa.amsl.com> <5CFCEA51-91EB-4FD3-9837-A712DAF7AADD@tzi.org> <003101d511ad$ce1ba3f0$6a52ebd0$@augustcellars.com> <50EF193E-642C-4391-92BF-083C5A1C0E16@tzi.org> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-array-tags-04.txt 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: Thu, 23 May 2019 21:49:43 -0000 On May 23, 2019, at 23:32, Carsten Bormann wrote: >=20 > (I didn=E2=80=99t check archive.org, BTW, but I=E2=80=99m not sure = that we want to use that here.) = https://web.archive.org/web/20160329172607/https://www.khronos.org/registr= y/typedarray/specs/1.0/ Should we put that in? Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 23 15:20:51 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 9E117120075; Thu, 23 May 2019 15:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 F2uxQdzCe2DV; Thu, 23 May 2019 15:20:46 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAADF120141; Thu, 23 May 2019 15:20:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id A5D551C3DB4; Thu, 23 May 2019 15:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2nDqthNya2i; Thu, 23 May 2019 15:20:17 -0700 (PDT) Received: from [IPv6:2601:646:8b00:23d0:613f:aaf5:95b2:7447] (unknown [IPv6:2601:646:8b00:23d0:613f:aaf5:95b2:7447]) by c8a.amsl.com (Postfix) with ESMTPSA id 67CC61C3DB1; Thu, 23 May 2019 15:20:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Lynne Bartholomew In-Reply-To: <4852CAFD-E986-4576-8C90-C03B54F39DCF@tzi.org> Date: Thu, 23 May 2019 15:20:45 -0700 Cc: RFC Editor , draft-ietf-cbor-cddl.all@ietf.org, cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2E55539B-63B3-4344-9676-E030D335B642@amsl.com> References: <4852CAFD-E986-4576-8C90-C03B54F39DCF@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] Correcting an error in draft-ietf-cbor-cddl-08 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: Thu, 23 May 2019 22:20:50 -0000 Dear Carsten, Thank you for sending us this update. We have corrected the "hexfloat = =3D" line in this document (added the "["-"]" item). We appreciate your letting us know now, rather than waiting for AUTH48. Thanks for the pointers to the discussions as well! RFC Editor/lb > On May 23, 2019, at 1:57 PM, Carsten Bormann wrote: >=20 > Dear RFC editor, >=20 > a technical error was caught in draft-ietf-cbor-cddl-08, which is = currently at RFC-EDITOR stage. >=20 > Please see the thread starting with > = https://mailarchive.ietf.org/arch/msg/cbor/sg5dpdCjaPw7mtohdAWCWgnQdMk > for reference. >=20 > We also discussed this at the last virtual interim meeting of the CBOR = working group, and we believe the following change to Appendix B is a = correct and complete fix: >=20 > OLD: > hexfloat =3D "0x" 1*HEXDIG ["." 1*HEXDIG] "p" exponent > NEW: > hexfloat =3D ["-"] "0x" 1*HEXDIG ["." 1*HEXDIG] "p" exponent >=20 > At the meeting, we thought we should make you aware now, instead of = waiting for AUTH48. >=20 > (The meeting minutes of the virtual interim have not yet been posted = to the proceedings at > https://datatracker.ietf.org/doc/agenda-interim-2019-cbor-07-sessa/ > but are captured in > https://etherpad.tools.ietf.org/p/notes-interim-220519-cbor > for reference.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Thu May 23 15:36:26 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 CCAF61200B9 for ; Thu, 23 May 2019 15:36:23 -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 vzzQIqwGEL-G for ; Thu, 23 May 2019 15:36:21 -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 5E182120075 for ; Thu, 23 May 2019 15:36:21 -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; Thu, 23 May 2019 15:36:15 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: References: <155853566619.11385.15062703999098868761@ietfa.amsl.com> <5CFCEA51-91EB-4FD3-9837-A712DAF7AADD@tzi.org> <003101d511ad$ce1ba3f0$6a52ebd0$@augustcellars.com> <50EF193E-642C-4391-92BF-083C5A1C0E16@tzi.org> In-Reply-To: Date: Thu, 23 May 2019 15:36:13 -0700 Message-ID: <003701d511b7$ef362c90$cda285b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHr7swzg0ZjOn9uzsF0MFdjF7mPNgHA1dkWAaO7pi0B2TUliQEyxPSCphgNuQA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-array-tags-04.txt 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: Thu, 23 May 2019 22:36:24 -0000 No I don't see any reason to reference that. If it is gone it is gone. = It was just an oddity. You might stick a note into the comments section = for the RFC Editor though. Jim > -----Original Message----- > From: Carsten Bormann > Sent: Thursday, May 23, 2019 2:50 PM > To: Jim Schaad > Cc: cbor@ietf.org > Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-array-tags-04.txt >=20 > On May 23, 2019, at 23:32, Carsten Bormann wrote: > > > > (I didn=E2=80=99t check archive.org, BTW, but I=E2=80=99m not sure = that we want to use that > here.) >=20 > https://web.archive.org/web/20160329172607/https://www.khronos.org/re > gistry/typedarray/specs/1.0/ >=20 > Should we put that in? >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Fri May 24 00:22:14 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 69005120105 for ; Fri, 24 May 2019 00:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 edlkPc6dG4dz for ; Fri, 24 May 2019 00:22:10 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80081.outbound.protection.outlook.com [40.107.8.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937D5120075 for ; Fri, 24 May 2019 00:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vZM7JAE3tUE6g81qkB0uvCWnJhrrw86rKku3BtRkCzY=; b=TNLtio8hYdN14oq5VBOtE4dP080n+5xZgvkvAJxA0/zeIQgy8HQxstAl0vTROFl1iJvM2LNzv8qV8+AN8oZkXo/J9gcYatpcGtgsJwgANL6i+1EcTY1NdwdDj6r1r9KL9LE47V6PFrLFbE2RHzGvIfYjQOu69RsWo14zW2tkCCI= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2953.eurprd07.prod.outlook.com (10.168.95.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.9; Fri, 24 May 2019 07:22:07 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::8a9:a4d6:303b:45f0]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::8a9:a4d6:303b:45f0%5]) with mapi id 15.20.1922.019; Fri, 24 May 2019 07:22:06 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: Minutes interim 22-05-2019 Thread-Index: AQHVEgFkHMf7x0nhv06IlhWTkXKelQ== Date: Fri, 24 May 2019 07:22:06 +0000 Message-ID: <09C1A25C-7E93-46A6-BBEF-D380FE0784A8@ericsson.com> 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: [192.176.1.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8845a324-cfe6-40ae-e875-08d6e0188718 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2953; x-ms-traffictypediagnostic: HE1PR0701MB2953: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 0047BC5ADE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(136003)(366004)(376002)(396003)(189003)(199004)(53754006)(476003)(486006)(6916009)(4270600006)(2906002)(14454004)(44832011)(68736007)(256004)(478600001)(2616005)(316002)(6512007)(186003)(82746002)(36756003)(102836004)(6116002)(3846002)(2501003)(26005)(54896002)(6306002)(7736002)(66946007)(64756008)(53936002)(76116006)(6506007)(66556008)(73956011)(66446008)(66476007)(5640700003)(25786009)(86362001)(6486002)(8676002)(2351001)(8936002)(5660300002)(71190400001)(71200400001)(99286004)(83716004)(81156014)(81166006)(1730700003)(66066001)(558084003)(33656002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2953; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: Ytpjzs9rIZZhghSRMJCS1rdxiHZqF4C1XomqM1ypZNqo5/yliwDZC1RPGCQox5ZgxOsXz+hcOvkkeI3L9ps2+TjzwyEXrSOcSGI53wX8qh85hwgsW8bwrvIv8ks/FYUfZ0mgdZcgyB/BGo/PdzF/C9iMZ7KdHQLRr+KyeUIFGzZmaezSeT2Y4CxGbqjJoFZ3e7kwW89wCUlyJuvswE5rWSneQPRNQFJwOTqxzdNFUn2v+8toSInpRjdvI79ENo/XbMG70NPSwT9yEOs+8S9wSAqxryuc5TMUTJ4s9QeXkQlnU9BccGDyGg7GvJP+y5vHwNE+pygZ3px95YA5rRzhHzjEcl1Ii/Oic7b9oijrGPycRxlwLOFbND3zdpZQIA0HcWj3f+CPLEb5cdIpCnXA8XCh6LKDGetsaRpYCaPKjAU= Content-Type: multipart/alternative; boundary="_000_09C1A25C7E9346A6BBEFD380FE0784A8ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8845a324-cfe6-40ae-e875-08d6e0188718 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2019 07:22:06.8866 (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-CrossTenant-userprincipalname: francesca.palombini@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2953 Archived-At: Subject: [Cbor] Minutes interim 22-05-2019 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: Fri, 24 May 2019 07:22:13 -0000 --_000_09C1A25C7E9346A6BBEFD380FE0784A8ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUaGFua3MgZm9yIGEgcHJvZHVjdGl2ZSBtZWV0aW5nLiBUaGUgbWludXRlcyBo YXZlIGJlZW4gcG9zdGVkIGluIHRoZSBkYXRhdHJhY2tlcjoNCg0K --_000_09C1A25C7E9346A6BBEFD380FE0784A8ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <769DAFF2865EE6438D0B18B0274174A6@eurprd07.prod.outlook.com> 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+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJT ViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MgZm9yIGEgcHJvZHVjdGl2ZSBt ZWV0aW5nLiBUaGUgbWludXRlcyBoYXZlIGJlZW4gcG9zdGVkIGluIHRoZSBkYXRhdHJhY2tlcjo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_09C1A25C7E9346A6BBEFD380FE0784A8ericssoncom_-- From nobody Fri May 24 00:25:33 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 16E50120284 for ; Fri, 24 May 2019 00:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 HyIKW9ikVIhF for ; Fri, 24 May 2019 00:25:20 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80072.outbound.protection.outlook.com [40.107.8.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 9F47B12025B for ; Fri, 24 May 2019 00:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4VNaQat9za15vwnfYxgn8brW+mLMXFbgKNBjKvj0KDw=; b=eAWmaMN2IxwA6hYE5PTVy6iZnhW9lMcS0QttahPv5ins5rPyyFzazujMYITmubU4BjqvNL/asW2SM9NfChbGhKQ2GSDppRrww8/KCoBHzHec2PA0tVmepCswCbdpyypKfE3P0HBIacN/cfUo5VBmoSVVAm77FQaMkf3y9f+8S5w= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2953.eurprd07.prod.outlook.com (10.168.95.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.9; Fri, 24 May 2019 07:24:52 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::8a9:a4d6:303b:45f0]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::8a9:a4d6:303b:45f0%5]) with mapi id 15.20.1922.019; Fri, 24 May 2019 07:24:52 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: [Cbor] Minutes interim 22-05-2019 Thread-Index: AQHVEgHH5ViGMgr1aECYIJVXulQD9Q== Date: Fri, 24 May 2019 07:24:52 +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: [192.176.1.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f67b6fd9-e082-495a-e67a-08d6e018ea03 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2953; x-ms-traffictypediagnostic: HE1PR0701MB2953: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0047BC5ADE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(136003)(366004)(376002)(396003)(189003)(199004)(53754006)(476003)(486006)(6916009)(606006)(2906002)(14454004)(236005)(44832011)(68736007)(256004)(478600001)(2616005)(316002)(6512007)(186003)(82746002)(36756003)(6246003)(102836004)(966005)(6116002)(3846002)(2501003)(26005)(54896002)(6306002)(7736002)(66946007)(64756008)(53936002)(76116006)(6506007)(66556008)(73956011)(66446008)(66476007)(5640700003)(25786009)(53546011)(86362001)(6486002)(8676002)(2351001)(8936002)(5660300002)(229853002)(71190400001)(71200400001)(99286004)(83716004)(81156014)(81166006)(1730700003)(66066001)(33656002)(6436002)(4744005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2953; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: jScq0TQ/KeFKAGHTtMvM2Og1X0QBscgqoF/YcsYrtHU0Cr0o91JPRj2LzlGf7Nn8MhXWVpAO8yspHKwJRLDn8BR3JXxQEi9xEb//MxN9mm7C5U+EbFmDVc/v/hvOvmMS9Mq4oGkASX2NNMaPsmpDGM5JkSCWQOJKZpaiczscsIcXFz8Mzrujyed12plerjZIBayNnSVtgLzFdgONYIXWs1WyesyvLqpi6y68yv18GzlXBWZpqjnsmkbzPMaYeVWPxJ4KNc8vLlTuTjeqZVt8ej5foaMRCm9NpY5Z2WBFU54itl28usWVW6VlxQuDS/rnIeLSafufbNHGDTHF6cHsWsTuAER8yIN4xI5lRs5qVDXWMo3p+1Tw9Sbx3DB0KRnYQwqLG7Wh9bHqaTvb2ElTKgpvafmRoPUDLPg0O9HG+8Q= Content-Type: multipart/alternative; boundary="_000_BBA834E9DD0A47F499DEDCB9EB8ECA1Eericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f67b6fd9-e082-495a-e67a-08d6e018ea03 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2019 07:24:52.8243 (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-CrossTenant-userprincipalname: francesca.palombini@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2953 Archived-At: Subject: Re: [Cbor] Minutes interim 22-05-2019 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: Fri, 24 May 2019 07:25:25 -0000 --_000_BBA834E9DD0A47F499DEDCB9EB8ECA1Eericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnksIG1pc3MtdHlwZWQgYW5kIHNlbnQgZWFybHkuIExpbmsgdG8gdGhlIG1pbnV0ZXM6DQoN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMTktY2Jvci0w Ny9tYXRlcmlhbHMvbWludXRlcy1pbnRlcmltLTIwMTktY2Jvci0wNy0yMDE5MDUyMjE1MDAudHh0 DQoNClRvIHRoZSBwcmVzZW50czogcGxlYXNlIGxldCB1cyBrbm93IGlmIHlvdSB0aGluayBhbnl0 aGluZyB3YXNu4oCZdCBjYXB0dXJlZCBjb3JyZWN0bHkuDQoNClRoYW5rcywNCkZyYW5jZXNjYQ0K DQpGcm9tOiBDQk9SIDxjYm9yLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBGcmFuY2Vz Y2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbT4NCkRhdGU6IEZy aWRheSwgMjQgTWF5IDIwMTkgYXQgMDk6MjINClRvOiAiY2JvckBpZXRmLm9yZyIgPGNib3JAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBbQ2Jvcl0gTWludXRlcyBpbnRlcmltIDIyLTA1LTIwMTkNCg0KSGkg YWxsLA0KDQpUaGFua3MgZm9yIGEgcHJvZHVjdGl2ZSBtZWV0aW5nLiBUaGUgbWludXRlcyBoYXZl IGJlZW4gcG9zdGVkIGluIHRoZSBkYXRhdHJhY2tlcjoNCg0K --_000_BBA834E9DD0A47F499DEDCB9EB8ECA1Eericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <94AC40AD10FF024C9AE62389CF7CD9D5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2 M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNvcnJ5LCBtaXNz LXR5cGVkIGFuZCBzZW50IGVhcmx5LiBMaW5rIHRvIHRoZSBtaW51dGVzOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvaW50ZXJpbS0yMDE5 LWNib3ItMDcvbWF0ZXJpYWxzL21pbnV0ZXMtaW50ZXJpbS0yMDE5LWNib3ItMDctMjAxOTA1MjIx NTAwLnR4dCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAx OS1jYm9yLTA3L21hdGVyaWFscy9taW51dGVzLWludGVyaW0tMjAxOS1jYm9yLTA3LTIwMTkwNTIy MTUwMC50eHQ8L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VG8gdGhlIHByZXNlbnRzOiBwbGVhc2UgbGV0 IHVzIGtub3cgaWYgeW91IHRoaW5rIGFueXRoaW5nIHdhc27igJl0IGNhcHR1cmVkIGNvcnJlY3Rs eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyw8YnI+ DQpGcmFuY2VzY2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Q0JPUiAmbHQ7Y2Jvci1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2Yg RnJhbmNlc2NhIFBhbG9tYmluaSAmbHQ7ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20m Z3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgMjQgTWF5IDIwMTkgYXQgMDk6MjI8YnI+DQo8 Yj5UbzogPC9iPiZxdW90O2Nib3JAaWV0Zi5vcmcmcXVvdDsgJmx0O2Nib3JAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPltDYm9yXSBNaW51dGVzIGludGVyaW0gMjItMDUtMjAxOTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SGkgYWxsLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyBmb3IgYSBwcm9kdWN0aXZlIG1lZXRpbmcuIFRo ZSBtaW51dGVzIGhhdmUgYmVlbiBwb3N0ZWQgaW4gdGhlIGRhdGF0cmFja2VyOjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_BBA834E9DD0A47F499DEDCB9EB8ECA1Eericssoncom_--