From nobody Wed Oct 3 06:37:56 2018 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 396AE131288 for ; Wed, 3 Oct 2018 06:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.754 X-Spam-Level: X-Spam-Status: No, score=-4.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Q3TLjEW+; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ctiEzsGe 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 wiPbgs_ISaIP for ; Wed, 3 Oct 2018 06:37:52 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 0E76F131270 for ; Wed, 3 Oct 2018 06:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1538573870; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JUOMbAK1diej8b51OvndVIZ4tZ4Ii8OKlGvJ6eKW3rw=; b=Q3TLjEW+n2Kb6ypSiBb7fqGU8JHPpF/5K6ySetuOlo8N3B0AS5UyJvK496tS2Fit mSvQDFnteA4nbdxk8+YevWq3YTWtUlKQtsbp/W6BtEGvQvY3vzm876ET21dFt8K0 Afkc5an3hU4wvd1C/b72MdfXJtEaV0kQe2hyzel6YbA=; X-AuditID: c1b4fb3a-75d969c000003197-51-5bb4c62e2ea1 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E1.33.12695.E26C4BB5; Wed, 3 Oct 2018 15:37:50 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 3 Oct 2018 15:37:07 +0200 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 3 Oct 2018 15:37:06 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+YUesYUJrg8PyyiikTk+sq8hQR1n9vn3GQCNZZm1PVI=; b=ctiEzsGeonaGhvZdg0eB1CXYwcun3MNTnjDPc5XhkxXDPftbCc/J7bn7nyfX/FjacSI1hZcYc4f+u/tgE17NfpbcST+ovF55VI67FFZfvb2VLy4MwqsIlRu0C/tOXRoVaQp0gHUNa5RBZ2vwSBBMolO2kgvpSMfw1WCUy4uoY5M= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2492.eurprd07.prod.outlook.com (10.168.128.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.16; Wed, 3 Oct 2018 13:37:05 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5%6]) with mapi id 15.20.1207.018; Wed, 3 Oct 2018 13:37:05 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: CBOR call today - call for agenda Thread-Index: AdRbHbQR/QEj2A/WTraMY2SFuJXKmg== Date: Wed, 3 Oct 2018 13:37:05 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.95] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2492; 6:4xEL21N8iVTPe1U2E3y8UE+Id7/VyjvBORVNyBxZ9kWzSiRmv9gRMY1RmsEFHhsAwlkaUxXM0+0g9KyOWBnbpInX41CXasOcG0++VGTUdVaGM9H5RtglzdPoHV7NCTkbgOnMJ8dikHHKEdADr4Q0vOLsy+SWmnB+W/QwPVX1y4oZ9CqJCDI6qP5OZLBqg10Bk0vas1vzYb6GchU70Qtv35tBlFMDxxjsUzU2MNa8za+6rfreQRCpgtca5djtV5w9l5iIiE7VUT0FbLy3De+KsdhtRnrk9T0YoI4n//XGzPE2eavvypGTPPcFXNiTlS8YeMqBZFTdDj9RYNE3b2cBevuruDEliDI2p65Ouk+aDmdc+bZ+NieWLBInfrRW80WlkSZIUn49G2pFKP5/OZcbHeybOzImA28onz6uYdafVvAfVufRL316j/fLXKY/SvEiFdgi4HV4Ix1sMFamkDU4kg==; 5:/3OPVd3LsB6ggopewZ514h8TNqQRquHDb/KNNQWLoi6R0cHLaXfgba2O/+I7YOrFWxxejdZiiRfsTwp3lLfuKWj9xq6+zo2KxSIl5CNvic+XxN+BqrhjT4JTc1in2WPTQuYj/IuRiiRe+jWI5UHP3c2cffoJ3T87O/262R4CmGk=; 7:Q1EITQay4LCWefxGDfx4TVo08WzQFuMiMcTrIMCONZendkv0Xdl2BEeSfuE3R3KzmgqLxha+sVC1/895uPkwWpOmH06Dk2PppUJiBvCibXakVGWh3O19tbxfijCE2iyNq0L9qXDJKRgCGeN8nM6RdYiIO0OjxRVA5PpgrCjnehXJJAziWSK9QR5bJz7xGluOsiq/Z8n0Bwb2QP52WNk0hS7qtz/6J7B7S9c0PKHEadEQ9I05ZL9NvETFv8mLhYC8 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 805efa1d-d97b-4342-2f9d-08d629354f29 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:HE1PR0701MB2492; x-ms-traffictypediagnostic: HE1PR0701MB2492: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510)(94707916325470)(95692535739014); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(4983020)(52105095)(10201501046)(3002001)(93006095)(93001095)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991048); SRVR:HE1PR0701MB2492; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2492; x-forefront-prvs: 0814A2C7A3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(39860400002)(396003)(366004)(53754006)(199004)(189003)(33656002)(2501003)(54896002)(6306002)(26005)(81166006)(19627405001)(2906002)(790700001)(81156014)(68736007)(6116002)(3846002)(186003)(102836004)(5640700003)(8936002)(25786009)(99936001)(2900100001)(5250100002)(478600001)(6436002)(16799955002)(316002)(2351001)(105586002)(106356001)(5660300001)(66066001)(6506007)(53546011)(14444005)(5024004)(551544002)(256004)(7696005)(4326008)(8676002)(55016002)(71190400001)(19609705001)(14454004)(71200400001)(966005)(53936002)(99286004)(236005)(6916009)(97736004)(1730700003)(450100002)(74316002)(5630700001)(9686003)(476003)(606006)(44832011)(486006)(86362001)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2492; 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-microsoft-antispam-message-info: KcZGiC0ojAwxKYBwwcl0FOnHrttmHjuXcpkdHuTkAUTE6ztkLI9EV3T0/wOv5SiPzYSEsKKdx3PmK9URnjQjrNrEYvOBJpFZweetK4IRS4jAapvAmeRzuBBjwS9lYVFGqGeFtcZ7P1vtSeANDdwTAGRQH6dJ5XXz1Oo1RDJQYStJjawYPbJM1qbR4XUHiQfIKSZ14wHdI7sufRQZuVJ8FX1sKQYCkx7j5x73H4TUSYtueqrjZcQezLNd71h68OQFMCemGCznkr8yJFYx2PKuFCS0lSO5yqEpB+w5K2h3k5b1BVBRTdK2YNMX2KyByykH3BdWo/vl45OG4NCOcv3fHRIG2BkawR6fElB8IBbsmVc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_005_HE1PR0701MB2746E9D4CE0DBA70E070040998E90HE1PR0701MB2746_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 805efa1d-d97b-4342-2f9d-08d629354f29 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2018 13:37:05.6487 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2492 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSWUwTURSGuTPDdKhWxwLhiEC0EhcCZYkLIiIuDwZjIm8KD9DACETaYgdR G0NYArKLSkEQggZCSCtatAHCEhZBWUzYqkaMIFuIwYUENyIQ295iSHj7zj3//997zgxDihto ZyZOkcipFLJ4CS2kSi80XvOSvjSE++gf2/s/WDEg/9KsEiqYOFNdvUScR2HCwGguPi6JU3kH RQpjjelTZIJuBl1ffOOWgt5/RDnIjgH2ACynvTWxkBGzPQjKV+cEuPiJIHuowFpUETBU9pk0 FxRbSMKgJsXquU/Au7RCAhezCGq6PxHmZJoNhKHJ77ZmdmB3g6boBZ2DGIZkfWGp9Yr52J71 gIyRGgGWeENfRbdVLoX22du0mSnWHVoqX1kiRWwkaHLNr7BjEOsKP1J1FiZZJxibqSTwQA4w OTxAY3aEz9Ortph3QnbHF6vGFUYqcy0DANshgCLjoHUbXrCg0ZCYz8HUxLIA8ygC7QM5Zk+4 l/ED4UdEgfFDgVWjhJ7MrzQOzUPQNF5C4YYbaPMnKdx4R0Jtaxth3gSwLlChSyxE0rJ1Q2CO g/55PVlmGXob9JXOUGWW3SnB+Honxv3wtNkbq3dBUe6kAPM+yCivEGw8D4H8pgka81HIK04z 3SQ0sembry5mWUVnIKv3F7HR7AXdgy//h2Y2ptPYXItA/6jOds38y3gXrTc/RGItcuQ5npfH +PlJOVVcFM8rFVIFl/gMmf7gTsPfgCbUOXeiC7EMkmwWzbQbwsW2siT+hrwLuZtypvS6IeRM KZQKTuIgYvWmtihadkPNqZQRqqvxHN+FdjCUxEl08pJ/mJiNkSVylzkugVOtdQnGzjkF1U07 GavRrT8L29VQ8vuJ9gpTfWS841WyOvRt+95u6eHahvBT8wa52sY4kvP8z/DBGhtlo3/q2Ysu pZ5Epa48qXGs+fdK0HEuvsVH6ViS8C2i/lhxRHLoloujY4duNj8l5zM86uhIzzvq5CmbIHnw poG2rf0Fp3tDVFXaPR819QESio+V+XqQKl72D08TImnJAwAA Archived-At: Subject: [Cbor] CBOR call today - call for agenda 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, 03 Oct 2018 13:37:55 -0000 --_005_HE1PR0701MB2746E9D4CE0DBA70E070040998E90HE1PR0701MB2746_ Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2746E9D4CE0DBA70E070040998E90HE1PR0701MB2746_" --_000_HE1PR0701MB2746E9D4CE0DBA70E070040998E90HE1PR0701MB2746_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUb2RheSB3ZSBoYXZlIG91ciA0dGggbWVldGluZyBzY2hlZHVsZWQuIFNpbmNl IENhcnN0ZW4gaGFzIG5vIHVwZGF0ZXMsICppZiBubyBvbmUgZWxzZSBoYXMgYW55dGhpbmcgdGhl eSB3YW50IHRvIGRpc2N1c3MgdG9kYXksIHRoZSBtZWV0aW5nIHdpbGwgYmUgY2FuY2VsbGVkKi4g SWYgeW91IGhhdmUgc29tZXRoaW5nIHlvdSB3YW50IHRvIGJyaW5nIHVwIGluIHRoZSBjYWxsLCBw bGVhc2UgcmVwbHkgdG8gdGhpcyB0aHJlYWQgbm93IQ0KDQooTm90ZSB0aGF0IGNhbm9uaWNhbGl6 YXRpb24sIHByZWZlcnJlZCBzZXJpYWxpemF0aW9uIC8gZW5jb2RpbmcgYW5kIGRlY29kaW5nIHdp bGwgYmUgZGlzY3Vzc2VkIGluIGEgZnV0dXJlIGNhbGwuKQ0KDQpUaGFua3MsDQpGcmFuY2VzY2EN Cg0KRnJvbTogQ0JPUiA8Y2Jvci1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQmFycnkg TGVpYmENClNlbnQ6IGRlbiAyMSBhdWd1c3RpIDIwMTggMTk6MDcNClRvOiBjYm9yQGlldGYub3Jn DQpTdWJqZWN0OiBbQ2Jvcl0gV2ViZXggbWVldGluZyBpbnZpdGF0aW9uOiBDQk9SIHdvcmtpbmcg Z3JvdXAgY29uZmVyZW5jZSBjYWxsDQoNClJFTUlOREVSOiBUaGUgc2Vjb25kIGNhbGwgaXMgb24g V2VkbmVzZGF5LCAyMiBBdWd1c3QsIGF0IDE1OjAwIFVUQy4NClRoYXQncyAidG9tb3Jyb3ciIGFz IEkgd3JpdGUgdGhpcy4gIChOb3RlIHRoYXQgdGhlcmUgaXMgYSBtZWV0aW5nIHBhc3N3b3JkLCAi Y29uc3RyYWluZWQiOyB5b3UncmUgbGlrZWx5IG5vdCB0byBuZWVkIGl0LCBidXQgdGhlcmUgaXQg aXMgaW4gY2FzZSB5b3UgZG8uKQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpIZXJlIGlzIHRoZSBXZWJFeCBpbmZvcm1hdGlvbiBmb3IgdGhlIENCT1IgY29uZmVyZW5jZSBj YWxscy4gIFRoZXJlJ3MgYW4gSUNTIGF0dGFjaG1lbnQgaGVyZSwgb3IgeW91IGNhbiBjbGljayB0 aGUgIkFkZCB0byBDYWxlbmRhciIgYnV0dG9uIHRvIGdldCB0aGUgc3RhbmRhcmQgV2ViRXggb25l Lg0KDQpUaGUgY2FsbHMgd2lsbCByZXBlYXQgZXZlcnkgdHdvIHdlZWtzLCBhbmQgdGhlIHB1cnBv c2Ugb2YgdGhlIGNhbGxzIGlzIHRvIGNoZWNrIHRoZSBwcm9ncmVzcyBvZiB0aGUgd29yayBvbiB0 aGUgQ0RETCBhbmQgQ0JPUi1iaXMgZG9jdW1lbnRzLCBhbmQgdG8ga2VlcCBpdCBtb3ZpbmcgZm9y d2FyZC4NCg0KQ0JPUiB3b3JraW5nIGdyb3VwIGNvbmZlcmVuY2UgY2FsbA0KDQpFdmVyeSAyIHdl ZWtzIG9uIFdlZG5lc2RheSwgZnJvbSBXZWRuZXNkYXksIEF1Z3VzdCA4LCAyMDE4LCB0byBXZWRu ZXNkYXksIE9jdG9iZXIgMzEsIDIwMTgNCg0KMTE6MDAgYW0gIHwgIEVhc3Rlcm4gRGF5bGlnaHQg VGltZSAoTmV3IFlvcmssIEdNVC0wNDowMCkgIHwgIDEgaHINCg0KDQpNZWV0aW5nIG51bWJlciAo YWNjZXNzIGNvZGUpOiAzMTEgNzE0IDY5Mw0KDQoNCk1lZXRpbmcgcGFzc3dvcmQ6IGNvbnN0cmFp bmVkDQoNCg0KDQoNCg0KQWRkIHRvIENhbGVuZGFyPGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9qLnBocD9NVElEPW0xZmUxNjlmOGI4NGM4NzQ0MjE4MDFjMDBkMjcxOWY2Nj4NCg0KDQpXaGVu IGl0J3MgdGltZSwgam9pbiB0aGUgbWVldGluZzxodHRwczovL2lldGYud2ViZXguY29tL2lldGYv ai5waHA/TVRJRD1tZmQxNzdiNGRmYmM1ZGY1N2QxZDM3MjllYzI2MjhlODQ+Lg0KDQoNCg0KDQoN Cg0KSm9pbiBieSBwaG9uZQ0KDQoxLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChV Uy9DYW5hZGEpDQoNCg0KDQoNCg0KQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gPGh0dHBzOi8vY29s bGFib3JhdGlvbmhlbHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1Pg0KDQoNCg0KDQoN CklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFs bG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24g dG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0 ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRv IHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVk LCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUg c2Vzc2lvbi4NCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkNCT1IgbWFpbGluZyBsaXN0DQpDQk9SQGlldGYub3JnPG1haWx0bzpD Qk9SQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYm9y DQoNCg== --_000_HE1PR0701MB2746E9D4CE0DBA70E070040998E90HE1PR0701MB2746_ Content-Type: text/html; charset="utf-8" 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 bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44 NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSBhbGwsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvZGF5IHdlIGhhdmUgb3VyIDQ8c3Vw PnRoPC9zdXA+IG1lZXRpbmcgc2NoZWR1bGVkLiBTaW5jZSBDYXJzdGVuIGhhcyBubyB1cGRhdGVz LCAqPGI+aWYgbm8gb25lIGVsc2UgaGFzIGFueXRoaW5nIHRoZXkgd2FudCB0byBkaXNjdXNzIHRv ZGF5LCB0aGUgbWVldGluZyB3aWxsIGJlIGNhbmNlbGxlZDwvYj4qLiBJZiB5b3UgaGF2ZSBzb21l dGhpbmcgeW91IHdhbnQgdG8gYnJpbmcgdXAgaW4gdGhlIGNhbGwsIHBsZWFzZQ0KIHJlcGx5IHRv IHRoaXMgdGhyZWFkIG5vdyE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KE5vdGUgdGhhdCBjYW5v bmljYWxpemF0aW9uLCBwcmVmZXJyZWQgc2VyaWFsaXphdGlvbiAvIGVuY29kaW5nIGFuZCBkZWNv ZGluZyB3aWxsIGJlIGRpc2N1c3NlZCBpbiBhIGZ1dHVyZSBjYWxsLik8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJh bmNlc2NhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IENCT1IgJmx0O2Ni b3ItYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkJhcnJ5IExlaWJh PGJyPg0KPGI+U2VudDo8L2I+IGRlbiAyMSBhdWd1c3RpIDIwMTggMTk6MDc8YnI+DQo8Yj5Ubzo8 L2I+IGNib3JAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0Nib3JdIFdlYmV4IG1lZXRp bmcgaW52aXRhdGlvbjogQ0JPUiB3b3JraW5nIGdyb3VwIGNvbmZlcmVuY2UgY2FsbDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPlJFTUlOREVSOiBUaGUgc2Vjb25kIGNhbGwgaXMgb24gV2VkbmVzZGF5LCAyMiBB dWd1c3QsIGF0IDE1OjAwIFVUQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoYXQncyAmcXVvdDt0b21vcnJvdyZxdW90OyBhcyBJIHdy aXRlIHRoaXMuJm5ic3A7IChOb3RlIHRoYXQgdGhlcmUgaXMgYSBtZWV0aW5nIHBhc3N3b3JkLCAm cXVvdDtjb25zdHJhaW5lZCZxdW90OzsgeW91J3JlIGxpa2VseSBub3QgdG8gbmVlZCBpdCwgYnV0 IHRoZXJlIGl0IGlzIGluIGNhc2UgeW91IGRvLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGVyZSBpcyB0aGUgV2ViRXggaW5mb3JtYXRpb24gZm9yIHRoZSBDQk9SIGNvbmZlcmVuY2UgY2Fs bHMuJm5ic3A7IFRoZXJlJ3MgYW4gSUNTIGF0dGFjaG1lbnQgaGVyZSwgb3IgeW91IGNhbiBjbGlj ayB0aGUgJnF1b3Q7QWRkIHRvIENhbGVuZGFyJnF1b3Q7IGJ1dHRvbiB0byBnZXQgdGhlIHN0YW5k YXJkIFdlYkV4IG9uZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIGNhbGxzIHdpbGwgcmVwZWF0IGV2ZXJ5IHR3byB3ZWVrcywgYW5kIHRo ZSBwdXJwb3NlIG9mIHRoZSBjYWxscyBpcyB0byBjaGVjayB0aGUgcHJvZ3Jlc3Mgb2YgdGhlIHdv cmsgb24gdGhlIENEREwgYW5kIENCT1ItYmlzIGRvY3VtZW50cywgYW5kIHRvIGtlZXAgaXQgbW92 aW5nIGZvcndhcmQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx0YWJsZSBjbGFz cz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjMiIGNlbGxwYWRkaW5n PSIwIiBhbGlnbj0ibGVmdCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRi b2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjMuNzVwdCAwY20gMGNtIDBjbSI+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIzIiBjZWxs cGFkZGluZz0iMCIgYWxpZ249ImxlZnQiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVw dDttYXJnaW4tbGVmdDozLjc1cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBz dHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8dGFibGUgY2xhc3M9Ik1z b05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIzIiBjZWxscGFkZGluZz0iMCIg d2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4y NXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiM0 RDRENEQiPkNCT1Igd29ya2luZyBncm91cCBjb25mZXJlbmNlIGNhbGw8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiM0RDRENEQiPg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1 cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDph cm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1h bmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KRXZlcnkg MiB3ZWVrcyBvbiBXZWRuZXNkYXksIGZyb20gV2VkbmVzZGF5LCBBdWd1c3QgOCwgMjAxOCwgdG8g V2VkbmVzZGF5LCBPY3RvYmVyIDMxLCAyMDE4DQo8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3Ry Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1m cmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFu Y2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29s dW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjExOjAwIGFtJm5ic3A7Jm5ic3A7fCZuYnNw OyZuYnNwO0Vhc3Rlcm4gRGF5bGlnaHQgVGltZSAoTmV3IFlvcmssIEdNVC0wNDowMCkmbmJzcDsm bmJzcDt8Jm5ic3A7Jm5ic3A7MSBociA8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6 ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFy b3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFu Y2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBz dHlsZT0iZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUg Y2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIzIiBjZWxscGFk ZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY207d2lkdGg6YXV0byFpbXBvcnRhbnQi Pg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43 NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28t ZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1l bGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6 b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCk1lZXRpbmcgbnVtYmVyIChh Y2Nlc3MgY29kZSk6IDMxMSA3MTQgNjkzIDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVu dDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu IHN0eWxlPSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjMiIGNlbGxw YWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbTt3aWR0aDphdXRvIWltcG9ydGFu dCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQg Ljc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21z by1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNv LWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9y aXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KTWVldGluZyBwYXNzd29y ZDogY29uc3RyYWluZWQ8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv dGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNp bmc9IjMiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBw dCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7aGVpZ2h0OjE1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21z by1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1l bnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28t ZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHki Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVt ZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1l bnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRh bDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPG86cD4mbmJzcDs8L286cD48L3A+ DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIz IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY207d2lkdGg6YXV0byFp bXBvcnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0 IC43NXB0IC43NXB0O3dpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9y bWFsVGFibGUiIGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iMCIgc3R5bGU9IndpZHRoOjBjbTtiYWNrZ3JvdW5kOiMwNDhDQkY7Ym9yZGVyOnNvbGlkICMw NDhDQkYgMS41cHQ7d2lkdGg6YXV0byFpbXBvcnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0 eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5nOjEwLjVwdCAxNS4wcHQgMTAuNXB0IDE1LjBwdDt3aWR0 aDphdXRvIWltcG9ydGFudDttaW4td2lkdGg6MTg2cHghaW1wb3J0YW50Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjttc28tZWxl bWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdy YXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1l bnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxh IGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xZmUxNjlmOGI4 NGM4NzQ0MjE4MDFjMDBkMjcxOWY2NiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTUuMHB0O2NvbG9yOndoaXRlO3RleHQtZGVjb3JhdGlvbjpub25lIj5BZGQgdG8gQ2Fs ZW5kYXI8L3NwYW4+PC9hPg0KPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+ DQo8L3RhYmxlPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAu NzVwdDt3aWR0aDphdXRvIWltcG9ydGFudCI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxl IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0 eWxlPSJ3aWR0aDowY207d2lkdGg6YXV0byFpbXBvcnRhbnQ7bWluLXdpZHRoOjE4NnB4IWltcG9y dGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMTIu MHB0O3dpZHRoOmF1dG8haW1wb3J0YW50O21pbi13aWR0aDoxODZweCFpbXBvcnRhbnQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZy YW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5j aG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1 bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KV2hlbiBpdCdzIHRpbWUsIDxhIGhyZWY9Imh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1mZDE3N2I0ZGZiYzVkZjU3ZDFk MzcyOWVjMjYyOGU4NCIgdGFyZ2V0PSJfYmxhbmsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFG Rjk7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmpvaW4gdGhlIG1lZXRpbmc8L3NwYW4+PC9hPi48bzpw PjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90 cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1l bGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQt d3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxl bWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0K PHNwYW4gc3R5bGU9ImRpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMyIg Y2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0 ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdDtoZWlnaHQ6MTUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1l bnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFw OmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50 LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQombmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJh bWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNo b3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVt bjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZGlzcGxheTpub25lIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxl IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIzIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1l LWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9y LXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47 bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPkpvaW4gYnkgcGhvbmU8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0i cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDtt c28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdy YXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6 ZXhhY3RseSI+DQo8Yj4xLTY1MC00NzktMzIwODwvYj4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVy IChVUy9DYW5hZGEpPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3Rh YmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1l bGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVs ZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpv bnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImRpc3Bs YXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29O b3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMyIgY2VsbHBhZGRpbmc9IjAiPg0K PHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzou NzVwdCAuNzVwdCAuNzVwdCAuNzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1l bnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVu dC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFs OmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDtt c28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdy YXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6 ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxz cGFjaW5nPSIzIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBh ZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNv LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4 YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48YSBocmVmPSJodHRwczovL2Nv bGxhYm9yYXRpb25oZWxwLmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBBRkY5O3RleHQtZGVjb3JhdGlvbjpub25lIj5D YW4ndCBqb2luIHRoZSBtZWV0aW5nPw0KPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImRpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs c3BhY2luZz0iMyIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6 Ny41cHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0O2hlaWdo dDo3LjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFs dDo3LjVwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0 O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs ZTpleGFjdGx5Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5 Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFt ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxl PSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFz cz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjMiIGNlbGxwYWRkaW5n PSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVw dCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7 bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDtt c28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1o b3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2NvbG9yOiNBMEEwQTAiPklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBu b3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3Jt YXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBi ZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9u LCB5b3UgYXV0b21hdGljYWxseQ0KIGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3Ug ZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3 aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwv dGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KQ0JPUiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86Q0JPUkBpZXRmLm9yZyI+Q0JPUkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3IiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3I8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_HE1PR0701MB2746E9D4CE0DBA70E070040998E90HE1PR0701MB2746_-- --_005_HE1PR0701MB2746E9D4CE0DBA70E070040998E90HE1PR0701MB2746_ Content-Type: text/calendar; name="CBOR working group conference call.ics" Content-Description: CBOR working group conference call.ics Content-Disposition: attachment; filename="CBOR working group conference call.ics"; size=1525; creation-date="Tue, 21 Aug 2018 17:07:52 GMT"; modification-date="Tue, 21 Aug 2018 17:07:52 GMT" Content-ID: Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UFVCTElTSApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDE2MTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE2MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkNMQVNTOlBVQkxJQwpERVNDUklQVElPTjpc blxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/ TVRJRD1tMmE4ODIxZjg0YmQ4YzU2MTg5YmU4MWYwMTIyN2U1OWZcbk1lZXRpbmcgbnVtYmVyIChh Y2Nlc3MgY29kZSk6IDMxMSA3MTQgNjkzXG5Ib3N0IGtleTogMjA1Mjc2XG5NZWV0aW5nIHBhc3N3 b3JkOiBjb25zdHJhaW5lZFxuXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAtNDc5LTMyMDggQ2Fs bC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGlu Zz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWNc blxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2Vydmlj ZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNz aW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwg bWF0dGVyLiBZb3Ugc2hvdWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMgcHJpb3IgdG8g cmVjb3JkaW5nIGlmIHlvdSBpbnRlbmQgdG8gcmVjb3JkIHRoZSBtZWV0aW5nLlxuCkRUU1RBTVA6 MjAxODA4MDhUMTUwMDAwWgpVSUQ6OTY4YmEwNTItMDIzMy00Njk2LWI1OTUtNDY5YmY0YmU2OWNh ClBSSU9SSVRZOjUKRFRTVEFSVDtUWklEPSJFYXN0ZXJuIFRpbWUiOjIwMTgwODA4VDExMDAwMApE VEVORDtUWklEPSJFYXN0ZXJuIFRpbWUiOjIwMTgwODA4VDEyMDAwMApSUlVMRTpGUkVRPVdFRUtM WTtJTlRFUlZBTD0yO0JZREFZPVdFO0NPVU5UPTcKU0VRVUVOQ0U6MTUzMzY2MzM5NgpTVU1NQVJZ OkNCT1Igd29ya2luZyBncm91cCBjb25mZXJlbmNlIGNhbGwKVFJBTlNQOk9QQVFVRQpMT0NBVElP TjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMmE4ODIxZjg0YmQ4YzU2 MTg5YmU4MWYwMTIyN2U1OWYKRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg== --_005_HE1PR0701MB2746E9D4CE0DBA70E070040998E90HE1PR0701MB2746_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Tue, 21 Aug 2018 17:07:52 GMT"; modification-date="Tue, 21 Aug 2018 17:07:52 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNCT1IgbWFp bGluZyBsaXN0DQpDQk9SQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Nib3INCg== --_005_HE1PR0701MB2746E9D4CE0DBA70E070040998E90HE1PR0701MB2746_-- From nobody Wed Oct 3 07:32:26 2018 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 6A266131280 for ; Wed, 3 Oct 2018 07:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.754 X-Spam-Level: X-Spam-Status: No, score=-4.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Hq6i0XYW; dkim=pass (1024-bit key) header.d=ericsson.com header.b=JZlY9ksd 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 8YER27Y3ckFn for ; Wed, 3 Oct 2018 07:32:22 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 2299713129E for ; Wed, 3 Oct 2018 07:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1538577139; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1RdX4B+GcUXKHu9PLNnsgsR8FbA00Xc4gJvbr411Vxg=; b=Hq6i0XYWR5yTyWzCGp2dVOey9Cg+i5hzTxB35soW0cMKRK3/p2uysrNz9bwaTFD9 VZKMTMIyoY9fjTUFtMF1cya05ei7Wy2NZUDtCnVOERNi3sNRJmLjpWgOt+81Kbad JKjz927Zqw8zLdXR5sCzdW5bCYwcENShjJzb44VvQMU=; X-AuditID: c1b4fb25-cd2929c0000013ad-21-5bb4d2f36e00 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5D.73.05037.3F2D4BB5; Wed, 3 Oct 2018 16:32:19 +0200 (CEST) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 3 Oct 2018 16:32:18 +0200 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 3 Oct 2018 16:32:18 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1RdX4B+GcUXKHu9PLNnsgsR8FbA00Xc4gJvbr411Vxg=; b=JZlY9ksdg6n8mNTCANc5O3qUjAjhBnQHQN4wd4old2H7TE//KVnp7bLKwjYcYnKu8magdzl3oRl/ONOF0fQ8tKM1ZTjArmNN07fcnMiJEstBiXxmSP5SN9tSgLV3JlmWZv2vBO+/0bmT+9eMBOXZQ/3puhJ++4Ta5aScWDkbhGQ= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.92.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.15; Wed, 3 Oct 2018 14:32:17 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5%6]) with mapi id 15.20.1207.018; Wed, 3 Oct 2018 14:32:17 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: CBOR call today - call for agenda Thread-Index: AdRbHbQR/QEj2A/WTraMY2SFuJXKmgAB+j2A Date: Wed, 3 Oct 2018 14:32:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.95] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2905; 6:GfX70lUauPySLrrrg+pCD+q+z3z6uKlSVpaDZHqO1yyGQR3mbiygcxmoXpkxcSySXaICz+n2fWQyTkKeN171rNn8k5xcbU05XUmVGQBApjDlzGy0B4tdco0/IyFPo72hneYFHdeUuV3OBswQhyyLDkZ35Lv240NcTaBiCPlbWZrE+kRvRuaonOOcPv++/uCSaHkLYxvgq7Vzi8PPUCzKt0a+1ghFvLWzInv1R1kl5H2rOfHKYham8Sj+FIzy1Y1yjNXysvF+bWMVKmuFXLYI7x3QO/YfOxJEE7P9THyolbjF55BjXmQhiaYPNZC1fYERElPYIMNtZbdn7RAAEqWkr9Q8oR0p+Z+8nJHTsB9EiPoGvo65RqrQPiS0PF209M5bipJnH+6VQ4yNfwPeIOnTIwgu25tqkDiBylRwNqEawEJPX8no31606qfnCalyTSwvEz+67tUP4QwgMswjzW6sQA==; 5:R0wzKRkPHnWzWdiEpfH3CFuTt6mXf+4pN2zfvBm8dqUSzyp+xjQCmAMuZi9DcCwyagBsQku9LCQwgNXbDf8BwW07byAWO8c+q1E4Y+hqKCft5quoNfJ64PSz4mpWHl5mkD8uATzd8wLkY7g5RnknFJLYLstiElVTyPLQk8qNL9c=; 7:9thd++DmOgbzLwc6j3SEWmAdHG5KBcZ3DXaSJju5z1+/3HuDe/S6LbzxqDQECiDQxQrTEoES2kn+3yrAp3sEaCjdr3SSyIHMfBN19HxM+fVjQ1mJ2bcqXh73W22QIjW7MlxWHDvq3FSh7PcfF8u6U1JcTnzYtKWEeoAyPD9kP4Nxctllplh4+qFxOXKHvJwvXksC25EZJtAyXGtGmh4XaUfHYYd6xcc27Nh7Ust0wK1qE+lGzB33HLf1xEK2ID8k x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e6e31893-487a-403e-1381-08d6293d0500 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2905; x-ms-traffictypediagnostic: HE1PR0701MB2905: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(248295561703944)(21748063052155)(28532068793085)(190501279198761)(227612066756510)(94707916325470)(95692535739014); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231355)(944501410)(52105095)(3002001)(10201501046)(149066)(150057)(6041310)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991048); SRVR:HE1PR0701MB2905; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2905; x-forefront-prvs: 0814A2C7A3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(376002)(366004)(136003)(189003)(199004)(53754006)(7696005)(102836004)(93156006)(5250100002)(2501003)(14454004)(53546011)(6506007)(2940100002)(186003)(606006)(1730700003)(478600001)(81156014)(81166006)(8676002)(256004)(86362001)(966005)(19627405001)(9326002)(16799955002)(2906002)(26005)(316002)(76176011)(99286004)(5630700001)(8936002)(14444005)(5024004)(97736004)(790700001)(3846002)(33656002)(2900100001)(19609705001)(7736002)(6116002)(229853002)(66066001)(551544002)(2351001)(68736007)(74316002)(446003)(5660300001)(105586002)(11346002)(71200400001)(71190400001)(53936002)(476003)(106356001)(236005)(54896002)(6916009)(486006)(44832011)(4326008)(25786009)(6306002)(9686003)(55016002)(6246003)(450100002)(6436002)(5640700003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2905; 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-microsoft-antispam-message-info: KezrtMrQIS9TMV2mxs1HRjt+hKfBihuWnXwUH0F6NrBgXcxlEfViyQbyHhFRZsYsV6xLH3z6u0A8KPysM8ZENhcUpvQlBgOWir8j6HzJomhmLPxfZW1P1eKK8QRgaReap/VHdrBTDJ8q/hSpyvb1hkbY2P5+A07QCseVBmYMrtNu3XRZ6TGMmZ35kkg80i55S7DlVLjdIMN2JjfzkydGdvfF4G/HuaM0xlTaCXWNnx7CnYn7SiZidQUFsUOic4MPOg8+WLzKLBtNeuJQpkTxg5hys/30YqmtrwAEaJpWhfoDXtRsvjJz36Emf/dw+CnVkaVMPxATAhQ9ShRBXG8ApUREKqhqKdijq47V7moNVj8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB27465AF549F3866E517FFBA998E90HE1PR0701MB2746_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e6e31893-487a-403e-1381-08d6293d0500 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2018 14:32:17.1207 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2905 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGOffeuas2OC3Nt8WklmFKfsyUhCxKgiIKKvoj9A9detOhbrqp y6DSonKzhoZiLj+mLYpJZW5mxShbWc2+/OrDTYuliYpkMctMtNzuAv97zvP8Dud9Xg5N8ps4 Aloqy2cUMkm2yMePqjncropw9ZqTo2ddOP7KvBnF15RWU9uJ3QbDLLEfJfklpDPZ0kJGEbUt 1S+zf35Lrm4AHfuhMZLFyNKHNMiXBhwLkzY1V4P8aD7uRFCv01Ls4ScCR7WOdFN8fJWAIddW d0DhchL+juq9QTUBcxoVe+MrggGNkXIHPjgBup1THLcOwOugqvKJjwbRNInFMGvJc9srcCS4 xscJFokCW91TLx4DFbNqwo1TOATGOmPdNg+nguHXK++zqfBiwunBfbEEtH+GPRphIUyXNHsY EgeBfaSBYFtiMFjekqwOhPHhBQ6r14C6Y9LLCKG3oQy5qwDu4EKFxU6xQQR8r6ryXt4HQ/p5 goVsCO4+H/P0ArwRbF8E7BBp0O/QclleDg8HRzksfxPBs/Ml3r0Hg/GikypH0bolw7JaDpba OqTzlF4OtpoRSudZXRjcfhDFImuhsszJZfUGOFtbx13q6xHXiAKVjPJITkbMpkhGIU1TKuWy SBmT34oWf85j89z6e6hvcocVYRqJlvF6XpuT+RxJobIox4qAJkUBPNyyaPHSJUXHGYU8RVGQ zSitaDVNiYJ4zs2mJD7OkOQzWQyTyyj+pwTtKyhG4kOfBT0hlwNjW95MzKVferfwSNBWZ3IE lx4Qyq2Nt8SOlf4nfh/tUt1var+zJ6/rwzAv2x62AP7XhM3LpVmW3hsmY5z2dGPcSWZ61S4r fzD0/UdTfUGo+tNM+N6Zcyp7q+pgrhW6T+l3ppTJpmTyZlsHzryQ2PntzPXwl6WJbSJKmSkR h5MKpeQf2NShOzUDAAA= Archived-At: Subject: Re: [Cbor] CBOR call today - call for agenda 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, 03 Oct 2018 14:32:25 -0000 --_000_HE1PR0701MB27465AF549F3866E517FFBA998E90HE1PR0701MB2746_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClNpbmNlIHdlIGRpZG7igJl0IGdldCBhbnkgYW5zd2VyLCAqdG9kYXnigJlzIGNhbGwg aXMgY2FuY2VsbGVkKi4NCg0KVGFsayB0byB5b3UgYWxsIGluIDIgd2Vla3MsDQpGcmFuY2VzY2EN Cg0KRnJvbTogRnJhbmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nv bi5jb20+DQpTZW50OiBkZW4gMyBva3RvYmVyIDIwMTggMTU6MzcNClRvOiBjYm9yQGlldGYub3Jn DQpDYzogY2Jvci1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IENCT1IgY2FsbCB0b2RheSAtIGNh bGwgZm9yIGFnZW5kYQ0KDQpIaSBhbGwsDQoNClRvZGF5IHdlIGhhdmUgb3VyIDR0aCBtZWV0aW5n IHNjaGVkdWxlZC4gU2luY2UgQ2Fyc3RlbiBoYXMgbm8gdXBkYXRlcywgKmlmIG5vIG9uZSBlbHNl IGhhcyBhbnl0aGluZyB0aGV5IHdhbnQgdG8gZGlzY3VzcyB0b2RheSwgdGhlIG1lZXRpbmcgd2ls bCBiZSBjYW5jZWxsZWQqLiBJZiB5b3UgaGF2ZSBzb21ldGhpbmcgeW91IHdhbnQgdG8gYnJpbmcg dXAgaW4gdGhlIGNhbGwsIHBsZWFzZSByZXBseSB0byB0aGlzIHRocmVhZCBub3chDQoNCihOb3Rl IHRoYXQgY2Fub25pY2FsaXphdGlvbiwgcHJlZmVycmVkIHNlcmlhbGl6YXRpb24gLyBlbmNvZGlu ZyBhbmQgZGVjb2Rpbmcgd2lsbCBiZSBkaXNjdXNzZWQgaW4gYSBmdXR1cmUgY2FsbC4pDQoNClRo YW5rcywNCkZyYW5jZXNjYQ0KDQpGcm9tOiBDQk9SIDxjYm9yLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOmNib3ItYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBCYXJyeSBMZWliYQ0KU2Vu dDogZGVuIDIxIGF1Z3VzdGkgMjAxOCAxOTowNw0KVG86IGNib3JAaWV0Zi5vcmc8bWFpbHRvOmNi b3JAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbQ2Jvcl0gV2ViZXggbWVldGluZyBpbnZpdGF0aW9uOiBD Qk9SIHdvcmtpbmcgZ3JvdXAgY29uZmVyZW5jZSBjYWxsDQoNClJFTUlOREVSOiBUaGUgc2Vjb25k IGNhbGwgaXMgb24gV2VkbmVzZGF5LCAyMiBBdWd1c3QsIGF0IDE1OjAwIFVUQy4NClRoYXQncyAi dG9tb3Jyb3ciIGFzIEkgd3JpdGUgdGhpcy4gIChOb3RlIHRoYXQgdGhlcmUgaXMgYSBtZWV0aW5n IHBhc3N3b3JkLCAiY29uc3RyYWluZWQiOyB5b3UncmUgbGlrZWx5IG5vdCB0byBuZWVkIGl0LCBi dXQgdGhlcmUgaXQgaXMgaW4gY2FzZSB5b3UgZG8uKQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpIZXJlIGlzIHRoZSBXZWJFeCBpbmZvcm1hdGlvbiBmb3IgdGhlIENCT1Ig Y29uZmVyZW5jZSBjYWxscy4gIFRoZXJlJ3MgYW4gSUNTIGF0dGFjaG1lbnQgaGVyZSwgb3IgeW91 IGNhbiBjbGljayB0aGUgIkFkZCB0byBDYWxlbmRhciIgYnV0dG9uIHRvIGdldCB0aGUgc3RhbmRh cmQgV2ViRXggb25lLg0KDQpUaGUgY2FsbHMgd2lsbCByZXBlYXQgZXZlcnkgdHdvIHdlZWtzLCBh bmQgdGhlIHB1cnBvc2Ugb2YgdGhlIGNhbGxzIGlzIHRvIGNoZWNrIHRoZSBwcm9ncmVzcyBvZiB0 aGUgd29yayBvbiB0aGUgQ0RETCBhbmQgQ0JPUi1iaXMgZG9jdW1lbnRzLCBhbmQgdG8ga2VlcCBp dCBtb3ZpbmcgZm9yd2FyZC4NCg0KQ0JPUiB3b3JraW5nIGdyb3VwIGNvbmZlcmVuY2UgY2FsbA0K DQpFdmVyeSAyIHdlZWtzIG9uIFdlZG5lc2RheSwgZnJvbSBXZWRuZXNkYXksIEF1Z3VzdCA4LCAy MDE4LCB0byBXZWRuZXNkYXksIE9jdG9iZXIgMzEsIDIwMTgNCg0KMTE6MDAgYW0gIHwgIEVhc3Rl cm4gRGF5bGlnaHQgVGltZSAoTmV3IFlvcmssIEdNVC0wNDowMCkgIHwgIDEgaHINCg0KDQpNZWV0 aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiAzMTEgNzE0IDY5Mw0KDQoNCk1lZXRpbmcgcGFzc3dv cmQ6IGNvbnN0cmFpbmVkDQoNCg0KDQoNCg0KQWRkIHRvIENhbGVuZGFyPGh0dHBzOi8vaWV0Zi53 ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xZmUxNjlmOGI4NGM4NzQ0MjE4MDFjMDBkMjcxOWY2 Nj4NCg0KDQpXaGVuIGl0J3MgdGltZSwgam9pbiB0aGUgbWVldGluZzxodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tZmQxNzdiNGRmYmM1ZGY1N2QxZDM3MjllYzI2MjhlODQ+ Lg0KDQoNCg0KDQoNCg0KSm9pbiBieSBwaG9uZQ0KDQoxLTY1MC00NzktMzIwOCBDYWxsLWluIHRv bGwgbnVtYmVyIChVUy9DYW5hZGEpDQoNCg0KDQoNCg0KQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8g PGh0dHBzOi8vY29sbGFib3JhdGlvbmhlbHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1 Pg0KDQoNCg0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJF eCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcg dGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4g YSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxs eSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJl aW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBu b3Qgam9pbiB0aGUgc2Vzc2lvbi4NCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkNCT1IgbWFpbGluZyBsaXN0DQpDQk9SQGlldGYu b3JnPG1haWx0bzpDQk9SQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jYm9yDQoNCg== --_000_HE1PR0701MB27465AF549F3866E517FFBA998E90HE1PR0701MB2746_ Content-Type: text/html; charset="utf-8" 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 bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIj5IaSw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2Ugd2Ug ZGlkbuKAmXQgZ2V0IGFueSBhbnN3ZXIsICo8Yj50b2RheeKAmXMgY2FsbCBpcyBjYW5jZWxsZWQ8 L2I+Ki48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFsayB0byB5b3UgYWxsIGluIDIgd2Vla3Ms PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GcmFuY2VzY2E8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gRnJhbmNlc2NhIFBhbG9tYmluaSAmbHQ7ZnJh bmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVu IDMgb2t0b2JlciAyMDE4IDE1OjM3PGJyPg0KPGI+VG86PC9iPiBjYm9yQGlldGYub3JnPGJyPg0K PGI+Q2M6PC9iPiBjYm9yLWNoYWlyc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBDQk9S IGNhbGwgdG9kYXkgLSBjYWxsIGZvciBhZ2VuZGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9kYXkgd2UgaGF2 ZSBvdXIgNDxzdXA+dGg8L3N1cD4gbWVldGluZyBzY2hlZHVsZWQuIFNpbmNlIENhcnN0ZW4gaGFz IG5vIHVwZGF0ZXMsICo8Yj5pZiBubyBvbmUgZWxzZSBoYXMgYW55dGhpbmcgdGhleSB3YW50IHRv IGRpc2N1c3MgdG9kYXksIHRoZSBtZWV0aW5nIHdpbGwgYmUgY2FuY2VsbGVkPC9iPiouIElmIHlv dSBoYXZlIHNvbWV0aGluZyB5b3Ugd2FudCB0byBicmluZyB1cCBpbiB0aGUgY2FsbCwgcGxlYXNl DQogcmVwbHkgdG8gdGhpcyB0aHJlYWQgbm93ITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oTm90 ZSB0aGF0IGNhbm9uaWNhbGl6YXRpb24sIHByZWZlcnJlZCBzZXJpYWxpemF0aW9uIC8gZW5jb2Rp bmcgYW5kIGRlY29kaW5nIHdpbGwgYmUgZGlzY3Vzc2VkIGluIGEgZnV0dXJlIGNhbGwuKTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5GcmFuY2VzY2E8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4g Q0JPUiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNib3ItYm91bmNlc0BpZXRmLm9yZyI+Y2Jvci1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmFycnkgTGVpYmE8YnI+ DQo8Yj5TZW50OjwvYj4gZGVuIDIxIGF1Z3VzdGkgMjAxOCAxOTowNzxicj4NCjxiPlRvOjwvYj4g PGEgaHJlZj0ibWFpbHRvOmNib3JAaWV0Zi5vcmciPmNib3JAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFtDYm9yXSBXZWJleCBtZWV0aW5nIGludml0YXRpb246IENCT1Igd29ya2lu ZyBncm91cCBjb25mZXJlbmNlIGNhbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5SRU1JTkRFUjogVGhlIHNl Y29uZCBjYWxsIGlzIG9uIFdlZG5lc2RheSwgMjIgQXVndXN0LCBhdCAxNTowMCBVVEMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5UaGF0 J3MgJnF1b3Q7dG9tb3Jyb3cmcXVvdDsgYXMgSSB3cml0ZSB0aGlzLiZuYnNwOyAoTm90ZSB0aGF0 IHRoZXJlIGlzIGEgbWVldGluZyBwYXNzd29yZCwgJnF1b3Q7Y29uc3RyYWluZWQmcXVvdDs7IHlv dSdyZSBsaWtlbHkgbm90IHRvIG5lZWQgaXQsIGJ1dCB0aGVyZSBpdCBpcyBpbiBjYXNlIHlvdSBk by4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUgaXMgdGhlIFdlYkV4IGluZm9ybWF0 aW9uIGZvciB0aGUgQ0JPUiBjb25mZXJlbmNlIGNhbGxzLiZuYnNwOyBUaGVyZSdzIGFuIElDUyBh dHRhY2htZW50IGhlcmUsIG9yIHlvdSBjYW4gY2xpY2sgdGhlICZxdW90O0FkZCB0byBDYWxlbmRh ciZxdW90OyBidXR0b24gdG8gZ2V0IHRoZSBzdGFuZGFyZCBXZWJFeCBvbmUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjYWxscyB3aWxs IHJlcGVhdCBldmVyeSB0d28gd2Vla3MsIGFuZCB0aGUgcHVycG9zZSBvZiB0aGUgY2FsbHMgaXMg dG8gY2hlY2sgdGhlIHByb2dyZXNzIG9mIHRoZSB3b3JrIG9uIHRoZSBDRERMIGFuZCBDQk9SLWJp cyBkb2N1bWVudHMsIGFuZCB0byBrZWVwIGl0IG1vdmluZyBmb3J3YXJkLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9 IjAiIGNlbGxzcGFjaW5nPSIzIiBjZWxscGFkZGluZz0iMCIgYWxpZ249ImxlZnQiIHdpZHRoPSIx MDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFk ZGluZzozLjc1cHQgMGNtIDBjbSAwY20iPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIg Ym9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMyIgY2VsbHBhZGRpbmc9IjAiIGFsaWduPSJsZWZ0IiB3 aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQ7bWFyZ2luLWxlZnQ6My43NXB0Ij4NCjx0 Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQg Ljc1cHQgLjc1cHQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBj ZWxsc3BhY2luZz0iMyIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6 MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAu NzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3Vu ZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hv ci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojNEQ0RDREIj5DQk9SIHdvcmtpbmcgZ3JvdXAg Y29uZmVyZW5jZSBjYWxsPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjojNEQ0RDREIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRy Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1o c3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12 ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21z by1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCkV2ZXJ5IDIgd2Vla3Mgb24gV2VkbmVzZGF5LCBmcm9t IFdlZG5lc2RheSwgQXVndXN0IDgsIDIwMTgsIHRvIFdlZG5lc2RheSwgT2N0b2JlciAzMSwgMjAx OA0KPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGlu ZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxl bWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21z by1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3Rs eSI+DQoxMTowMCBhbSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDtFYXN0ZXJuIERheWxpZ2h0IFRp bWUgKE5ldyBZb3JrLCBHTVQtMDQ6MDApJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzEgaHIgPG86 cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhz cGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZl cnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNv LWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImRpc3BsYXk6bm9uZSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9y ZGVyPSIwIiBjZWxsc3BhY2luZz0iMyIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0i d2lkdGg6MGNtO3dpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHls ZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVw dDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFy YWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1 bGU6ZXhhY3RseSI+DQpNZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiAzMTEgNzE0IDY5MyA8 bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZGlzcGxheTpub25lIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBi b3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIzIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxl PSJ3aWR0aDowY207d2lkdGg6YXV0byFpbXBvcnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4y NXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCk1lZXRpbmcgcGFzc3dvcmQ6IGNvbnN0cmFpbmVkPG86cD48L286cD48 L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1 cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBh cmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1y dWxlOmV4YWN0bHkiPg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05v cm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIzIiBjZWxscGFkZGluZz0iMCI+DQo8 dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43 NXB0IC43NXB0IC43NXB0IC43NXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVu dC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50 LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6 Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21z by1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3Jh cGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpl eGFjdGx5Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxU YWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMyIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIw IiBzdHlsZT0id2lkdGg6MGNtO3dpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4N Cjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdDt3aWR0aDphdXRvIWlt cG9ydGFudCI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjEiIGNlbGxz cGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY207YmFj a2dyb3VuZDojMDQ4Q0JGO2JvcmRlcjpzb2xpZCAjMDQ4Q0JGIDEuNXB0O3dpZHRoOmF1dG8haW1w b3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzox MC41cHQgMTUuMHB0IDEwLjVwdCAxNS4wcHQ7d2lkdGg6YXV0byFpbXBvcnRhbnQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO21z by1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1l bnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28t ZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHki Pg0KPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTFmZTE2 OWY4Yjg0Yzg3NDQyMTgwMWMwMGQyNzE5ZjY2IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxNS4wcHQ7Y29sb3I6d2hpdGU7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPkFkZCB0 byBDYWxlbmRhcjwvc3Bhbj48L2E+DQo8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43 NXB0IC43NXB0O3dpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFs VGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0i MCIgc3R5bGU9IndpZHRoOjBjbTt3aWR0aDphdXRvIWltcG9ydGFudDttaW4td2lkdGg6MTg2cHgh aW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBj bSAxMi4wcHQ7d2lkdGg6YXV0byFpbXBvcnRhbnQ7bWluLXdpZHRoOjE4NnB4IWltcG9ydGFudCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1l bnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVu dC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFs OmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQpXaGVuIGl0J3MgdGltZSwgPGEgaHJl Zj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWZkMTc3YjRkZmJjNWRm NTdkMWQzNzI5ZWMyNjI4ZTg0IiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 IzAwQUZGOTt0ZXh0LWRlY29yYXRpb246bm9uZSI+am9pbiB0aGUgbWVldGluZzwvc3Bhbj48L2E+ LjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+ DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxl bWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21z by1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3Rs eSI+DQo8c3BhbiBzdHlsZT0iZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5n PSIzIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQi Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0O2hlaWdodDoxNS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50 LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVs ZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4N CiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVu dC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50 LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6 Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJkaXNwbGF5Om5v bmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFs VGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjMiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9k eT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQt ZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1h bmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNv bHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+Sm9pbiBieSBwaG9uZTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4y NXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCjxiPjEtNjUwLTQ3OS0zMjA4PC9iPiZuYnNwO0NhbGwtaW4gdG9sbCBu dW1iZXIgKFVTL0NhbmFkYSk8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N CjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7 bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDtt c28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1o b3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0i ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9 Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIzIiBjZWxscGFkZGluZz0i MCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRk aW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28t ZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1l bGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6 b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4y NXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHNwYWNpbmc9IjMiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHls ZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVw dDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFy YWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1 bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxhIGhyZWY9Imh0dHBz Oi8vY29sbGFib3JhdGlvbmhlbHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1IiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFGRjk7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/DQo8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIu MjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAi IGNlbGxzcGFjaW5nPSIzIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9Imhl aWdodDo3LjVwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7 aGVpZ2h0OjcuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGluZS1oZWln aHQtYWx0OjcuNXB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToy LjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwv dGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDph cm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1h bmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4g c3R5bGU9ImRpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxl IGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMyIgY2VsbHBh ZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0 IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpm cmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJv dW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5j aG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6I0EwQTBBMCI+SU1QT1JUQU5UIE5PVElDRTogUGxl YXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBp bmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2gg bWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNl c3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5DQogY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElm IHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNl cm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJs ZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCkNCT1IgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkNCT1JAaWV0Zi5v cmciPkNCT1JAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jYm9yIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jYm9yPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_HE1PR0701MB27465AF549F3866E517FFBA998E90HE1PR0701MB2746_-- From nobody Fri Oct 5 15:57:36 2018 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 3971412872C; Fri, 5 Oct 2018 15:57:22 -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 JXlUVuQ1jvGz; Fri, 5 Oct 2018 15:57:19 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBF91277D2; Fri, 5 Oct 2018 15:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w95MvFKx023069; Sat, 6 Oct 2018 00:57:15 +0200 (CEST) Received: from [192.168.217.102] (p54A6C3C7.dip0.t-ipconnect.de [84.166.195.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42RlWb2wrXzDXqV; Sat, 6 Oct 2018 00:57:15 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 560473033.187742-8e755096de363303ad93055d3a5b5842 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 6 Oct 2018 00:57:14 +0200 Message-Id: <17A2ED9E-8BDA-4686-A322-D952F36B1464@tzi.org> To: ace@ietf.org, core@ietf.org, cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] Constrained Node/Network Cluster @ IETF103: DRAFT AGENDA 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, 05 Oct 2018 22:57:23 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF103. Remember that there is still quite some potential for changes. cbor/teep and 6tisch/suit are annoying but probably livable. No qirg for core goers... All times are ICT (Indochina Time) =3D=3D UTC +7 hours. There is no daylight saving time in effect in Thailand. DST will have ended in Europe by then (e.g., CET =3D UTC+0100) and will end in the US during the initial weekend (On Sun, Nov 4; e.g. EST =3D UTC-0500). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Please note that the Friday schedule is still evolving; plan to stick around until 13:20 or you may miss interesting conversations. Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY, November 3/4. 2018 -- Hackathon (including various interops) (Centre Ville) -- Sun 1700-1900 Welcome Reception - Garden at Queen's Park -- Sun 1800-2000 Hot RFC Lightning Talks - Thai Chitlada 3 MONDAY, November 5, 2018 0900-1100 Morning Session I Thai Chitlada 3 IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Meeting 1 OPS v6ops IPv6 Operations WG Boromph. 1/2 RTG *** roll Routing Over Low power and Lossy = networks WG Thai Chitlada 1 SEC secdispatch Security Dispatch WG Thai Chitlada 2 TSV taps Transport Services WG 1120-1220 Morning Session II Thai Chitlada 1 IRTF cfrg Crypto Forum Thai Chitlada 2 TSV tsvarea Transport Area Open Meeting 1350-1550 Afternoon Session I Boromph. 1/2 ART *** core Constrained RESTful Environments WG Meeting 2 OPS anima Autonomic Networking Integrated Model = and Approach WG Thai Chitlada 2 SEC tls Transport Layer Security WG Thai Chitlada 3 TSV tsvwg Transport Area Working Group WG 1610-1810 Afternoon Session II Meeting 1 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Thai Chitlada 1 IRTF irtfopen IRTF Open Meeting Thai Chitlada 2 SEC mls Messaging Layer Security WG TUESDAY, November 6, 2018 0900-1100 Morning Session I Thai Chitlada 2 ART httpbis Hypertext Transfer Protocol WG Meeting 1 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Boromph. 1/2 SEC oauth Web Authorization Protocol WG 1120-1220 Morning Session II Thai Chitlada 3 INT ipwave IP Wireless Access in Vehicular = Environments WG Meeting 2 SEC oauth Web Authorization Protocol WG 1350-1550 Afternoon Session I Thai Chitlada 3 INT 6man IPv6 Maintenance WG Thai Chitlada 2 SEC rats Remote ATtestation ProcedureS BOF Thai Chitlada 1 TSV quic QUIC WG 1610-1810 Afternoon Session II Thai Chitlada 1 IRTF maprg Measurement and Analysis for Protocols Meeting 2 IRTF*** t2trg Thing-to-Thing WEDNESDAY, November 7, 2018 0900-1100 Morning Session ! Thai Chitlada 3 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Boromph. 3 RTG bier Bit Indexed Explicit Replication WG Meeting 1 SEC *** teep Trusted Execution Environment = Provisioning WG Boromph. 1/2 SEC tokbind Token Binding WG Thai Chitlada 1 TSV quic QUIC WG 1120-1220 Morning Session II Boromph. 1/2 INT *** lwig Light-Weight Implementation Guidance WG Thai Chitlada 1 SEC tls Transport Layer Security WG Thai Chitlada 2 TSV tsvwg Transport Area Working Group WG 1350-1520 Afternoon Session I Meeting 1 GEN wugh WGs Using GitHub BOF Thai Chitlada 3 INT homenet Home Networking WG Meeting 2 IRTF panrg Path Aware Networking RG 1540-1710 Afternoon Session II Meeting 1 ART dispatch Dispatch WG - Joint with ARTAREA Thai Chitlada 3 INT intarea Internet Area Working Group WG Meeting 2 IRTF pearg Privacy Enhancements and Assessments = Proposed Research Group Boromph. 3 RTG babel Babel routing protocol WG Boromph. 1/2 RTG rift Routing In Fat Trees WG THURSDAY, November 8, 2018 0900-1100 Morning Session I Thai Chitlada 1 ART httpbis Hypertext Transfer Protocol WG Boromph. 4 INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Meeting 1 IRTF icnrg Information-Centric Networking Thai Chitlada 2 SEC *** suit Software Updates for Internet of Things = WG 1120-1220 Morning Session II Thai Chitlada 2 ART *** core Constrained RESTful Environments WG Thai Chitlada 3 IRTF qirg Quantum Internet Proposed Research Group Boromph. 4 RTG bier Bit Indexed Explicit Replication WG Thai Chitlada 1 SEC mls Messaging Layer Security WG Meeting 2 TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1350-1550 Afternoon Session I Meeting 1 INT dnssd Extensions for Scalable DNS Service = Discovery WG Thai Chitlada 2 RTG detnet Deterministic Networking WG Thai Chitlada 1 SEC saag Security Area Open Meeting 1610-1810 Afternoon Session II Thai Chitlada 3 RTG rtgarea Routing Area Open Meeting Thai Chitlada 1 SEC *** ace Authentication and Authorization for = Constrained Environments WG Boromph. 1/2 SEC acme Automated Certificate Management = Environment WG FRIDAY, November 9, 2018 Various ad-hoc meetings, please see https://trac.ietf.org/trac/ietf/meeting/wiki/103sidemeetings#FRIDAY -- 0900..1320 T2TRG work meeting -- 1000..??? COIN (Computing in the Network) From nobody Wed Oct 17 06:15:37 2018 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 771D112D4E8 for ; Wed, 17 Oct 2018 06:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 3TbsAtdR-S3k for ; Wed, 17 Oct 2018 06:15:34 -0700 (PDT) Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) (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 9FB8912D4F2 for ; Wed, 17 Oct 2018 06:15:33 -0700 (PDT) Received: by mail-ed1-f47.google.com with SMTP id y19-v6so24819919edd.2 for ; Wed, 17 Oct 2018 06:15:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=2QhQh6e7NwTuoxGUdfm+l1T+l+mnOBB1AbB3lmKfYSk=; b=bmS/dShgpqGJ683KSM55Jd6f3lzu0KX1vGbWrev/Aj3WwLhr43tVyqs0AXF46uixCo EbIm4M3PXFlc3V8did4z1sgIyT6vGYUIl0d/sxvSpZ4a3SR10aSRTBjiCQkj2KccRtNy Yix7MqTp4D17WP3Sfn+xJjEY1BN+/Hlj+dxuFFivPQenP3r5EzUicuAgmo1R/uniSd0u nfEQh0c/B/cP16QHVrMrfsNj2dV7aPytylL2Ylzk1/KzV5aOjxWbkSKJRLGE1KFsBroc AUjpD2MFacpa0kacQqRIcCH66qAhK+wdBITs2rBe2PKgNhjcErNgCk0Eo7BnSzg+uzTj HqBg== X-Gm-Message-State: ABuFfohJ9MdH4tUbzqA7e3iYS5xy8aWwXyqoRFeR9veyg0grCKq9r2Uz cKs6ncR8t5kvJIzpP7Spym8YuoRnlRd0OJX+kcfbS1Qi X-Google-Smtp-Source: ACcGV63KyeQIvEbtwDbalkkTbsAX5daqhPLHkzXi2/5Uuv9TOqjHCh8VC2SMA/KW8u7MbMvQ4QdldRBEOu8vUSvJJDU= X-Received: by 2002:a17:906:2d4a:: with SMTP id e10-v6mr27078072eji.105.1539782131680; Wed, 17 Oct 2018 06:15:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Wed, 17 Oct 2018 09:15:19 -0400 Message-ID: To: cbor@ietf.org Content-Type: multipart/mixed; boundary="000000000000fda97205786c76fd" Archived-At: Subject: [Cbor] Today's CBOR call, 17 Oct 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, 17 Oct 2018 13:15:35 -0000 --000000000000fda97205786c76fd Content-Type: multipart/alternative; boundary="000000000000fda96f05786c76fb" --000000000000fda96f05786c76fb Content-Type: text/plain; charset="UTF-8" A reminder of today's CBOR call. On the agenda is: - discussion of canonicalization, preferred serialization / encoding and decoding -- issues raised by Laurence Lundblade - IETF 103 Hackathon and possible CBOR interop testing - Anything else we should discuss before IETF 103, as this might be the last call we do before the meeting We do have one more call scheduled, two weeks from now on 31 Oct. I think we're likely to cancel that because people may have begun their IETF travel. We can discuss that on this call also. Barry ---------- Forwarded message --------- From: Barry Leiba Date: Tue, Aug 7, 2018 at 1:45 PM Subject: [Cbor] Webex meeting invitation: CBOR working group conference call To: Here is the WebEx information for the CBOR conference calls. There's an ICS attachment here, or you can click the "Add to Calendar" button to get the standard WebEx one. The calls will repeat every two weeks, and the purpose of the calls is to check the progress of the work on the CDDL and CBOR-bis documents, and to keep it moving forward. REMINDER: The first call is on Wednesday, 8 August, at 15:00 UTC. That's "tomorrow" as I write this. (Note that there is a meeting password, "constrained"; you're likely not to need it, but there it is in case you do. I wanted to just make it "ietf", but the WebEx system wouldn't let me.) *CBOR working group conference call* Every 2 weeks on Wednesday, from Wednesday, August 8, 2018, to Wednesday, October 31, 2018 11:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr Meeting number (access code): 311 714 693 Meeting password: constrained Add to Calendar When it's time, join the meeting . *Join by phone* *1-650-479-3208* Call-in toll number (US/Canada) Can't join the meeting? IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. _______________________________________________ CBOR mailing list CBOR@ietf.org https://www.ietf.org/mailman/listinfo/cbor --000000000000fda96f05786c76fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A reminder of t= oday's CBOR call.=C2=A0 On the agenda is:
- discu= ssion of canonicalization, preferred serialization / encoding and decoding = -- issues raised by Laurence Lundblade
- IETF 103 Hack= athon and possible CBOR interop testing
- Anything els= e we should discuss before IETF 103, as this might be the last call we do b= efore the meeting

We do have= one more call scheduled, two weeks from now on 31 Oct.=C2=A0 I think we= 9;re likely to cancel that because people may have begun their IETF travel.= =C2=A0 We can discuss that on this call also.

Barry

---------- Forwarded message ---------
From: Barry Leiba <barryleiba@computer.org><= br>Date: Tue, Aug 7, 2018 at 1:45 PM
Subject: [Cbor] Webex meeting invit= ation: CBOR working group conference call
To: <cbor@ietf.org>


He= re is the WebEx information for the CBOR conference calls.=C2=A0 There'= s an ICS attachment here, or you can click the "Add to Calendar" = button to get the standard WebEx one.

The calls wi= ll repeat every two weeks, and the purpose of the calls is to check the pro= gress of the work on the CDDL and CBOR-bis documents, and to keep it moving= forward.

REMINDER: The first call is on Wednesday= , 8 August, at 15:00 UTC.
That's "tomorrow" as I wr= ite this.=C2=A0 (Note that there is a meeting password, "constrained&q= uot;; you're likely not to need it, but there it is in case you do.=C2= =A0 I wanted to just make it "ietf", but the WebEx system wouldn&= #39;t let me.)

CBOR working group conference c= all
Every 2 weeks on Wednesday, from Wednesday, August 8, 2018, to = Wednesday, October 31, 2018
11:00 am=C2=A0=C2=A0|=C2=A0=C2=A0Eastern Daylight Time (New Yor= k, GMT-04:00)=C2=A0=C2=A0|=C2=A0=C2=A01 hr
Meeting number (access code): 311 714 693
=09
Meeting password: constrained

=09
= =C2=A0
Add to Calendar
When it's time, join the meeting.
= =C2=A0
=09
Join by phone
1-650-479-3208=C2=A0Call-in toll num= ber (US/Canada)
=C2= =A0
Can't join the meeting?
=C2= =A0
IMPORTANT NOTICE: Please note that this WebEx service allows audio= and other information sent during the session to be recorded, which may be= discoverable in a legal matter. By joining this session, you automatically= consent to such recordings. If you do not consent to being recorded, discu= ss your concerns with the host or do not join the session.



_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
--000000000000fda96f05786c76fb-- --000000000000fda97205786c76fd Content-Type: application/ics; name="CBOR working group conference call.ics" Content-Disposition: attachment; filename="CBOR working group conference call.ics" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jkjzvcr80 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UFVCTElTSApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDE2MTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE2MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkNMQVNTOlBVQkxJQwpERVNDUklQVElPTjpc blxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/ TVRJRD1tMmE4ODIxZjg0YmQ4YzU2MTg5YmU4MWYwMTIyN2U1OWZcbk1lZXRpbmcgbnVtYmVyIChh Y2Nlc3MgY29kZSk6IDMxMSA3MTQgNjkzXG5Ib3N0IGtleTogMjA1Mjc2XG5NZWV0aW5nIHBhc3N3 b3JkOiBjb25zdHJhaW5lZFxuXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAtNDc5LTMyMDggQ2Fs bC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGlu Zz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWNc blxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2Vydmlj ZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNz aW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwg bWF0dGVyLiBZb3Ugc2hvdWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMgcHJpb3IgdG8g cmVjb3JkaW5nIGlmIHlvdSBpbnRlbmQgdG8gcmVjb3JkIHRoZSBtZWV0aW5nLlxuCkRUU1RBTVA6 MjAxODA4MDhUMTUwMDAwWgpVSUQ6OTY4YmEwNTItMDIzMy00Njk2LWI1OTUtNDY5YmY0YmU2OWNh ClBSSU9SSVRZOjUKRFRTVEFSVDtUWklEPSJFYXN0ZXJuIFRpbWUiOjIwMTgwODA4VDExMDAwMApE VEVORDtUWklEPSJFYXN0ZXJuIFRpbWUiOjIwMTgwODA4VDEyMDAwMApSUlVMRTpGUkVRPVdFRUtM WTtJTlRFUlZBTD0yO0JZREFZPVdFO0NPVU5UPTcKU0VRVUVOQ0U6MTUzMzY2MzM5NgpTVU1NQVJZ OkNCT1Igd29ya2luZyBncm91cCBjb25mZXJlbmNlIGNhbGwKVFJBTlNQOk9QQVFVRQpMT0NBVElP TjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMmE4ODIxZjg0YmQ4YzU2 MTg5YmU4MWYwMTIyN2U1OWYKRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg== --000000000000fda97205786c76fd-- From nobody Wed Oct 17 07:38:28 2018 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 B93E6130DE0; Wed, 17 Oct 2018 07:38:10 -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 TDmTa8ynpbKc; Wed, 17 Oct 2018 07:38:07 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52AC130DDE; Wed, 17 Oct 2018 07:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9HEbvei026196; Wed, 17 Oct 2018 16:38:02 +0200 (CEST) Received: from [192.168.217.114] (p54A6CA9F.dip0.t-ipconnect.de [84.166.202.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42Zvsw4klHz1Bql; Wed, 17 Oct 2018 16:37:56 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 561479874.377188-fedd7e99c522a9762603e0f7657e5add Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 17 Oct 2018 16:37:55 +0200 Message-Id: To: ace , "core@ietf.org WG" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] Constrained Node/Network Cluster @ IETF103: "FINAL" AGENDA 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, 17 Oct 2018 14:38:11 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF103. A few changes from the DRAFT AGENDA. I waited a bit with sending this as a few more side meetings have become known, as well. Of course, "FINAL" doesn't mean final. cbor/teep and 6tisch/ace (was suit) are annoying but probably livable. qirg no longer conflicts with core :-). dinrg is now on top of lpwan. secdispatch on top of t2trg will all but make sure no security people attend t2trg. All times are ICT (Indochina Time) =3D=3D UTC +7 hours. There is no daylight saving time in effect in Thailand. DST will have ended in Europe by then (e.g., CET =3D UTC+0100) and will end in the US during the initial weekend (On Sun, Nov 4; e.g. EST =3D UTC-0500). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Please note that the Friday schedule is still evolving; plan to stick around until 13:20 or you may miss interesting conversations. Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY, November 3/4. 2018 -- Hackathon (including various interops) (Centre Ville), e.g.: T2TRG WISHI, possibly some CBOR, LPWAN, TLS 1.3, EST-COAPS, TEEP Please see https://trac.ietf.org/trac/ietf/meeting/wiki/103hackathon -- Sun 1700-1900 Welcome Reception - Garden at Queen's Park -- Sun 1800-2000 Hot RFC Lightning Talks - Chitlada 3 MONDAY, November 5, 2018 0900-1100 Morning Session I Chitlada 2 ART dispatch Dispatch WG - Joint with ARTAREA Meeting 1 OPS v6ops IPv6 Operations WG Boromph. 1/2 RTG *** roll Routing Over Low power and Lossy = networks WG Meeting 2 SEC oauth Web Authorization Protocol WG 1120-1220 Morning Session II Chitlada 1 IRTF cfrg Crypto Forum Chitlada 2 TSV tsvarea Transport Area Open Meeting 1350-1550 Afternoon Session I Boromph. 1/2 ART *** core Constrained RESTful Environments WG Meeting 1 OPS anima Autonomic Networking Integrated Model = and Approach WG Chitlada 2 SEC tls Transport Layer Security WG Chitlada 3 TSV tsvwg Transport Area Working Group WG 1610-1810 Afternoon Session II Meeting 2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Chitlada 1 IRTF irtfopen IRTF Open Meeting Chitlada 2 SEC mls Messaging Layer Security WG TUESDAY, November 6, 2018 0900-1100 Morning Session I Chitlada 1 ART httpbis Hypertext Transfer Protocol WG Meeting 1 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Meeting 2 IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Boromph. 4 SEC tokbind Token Binding WG 1120-1220 Morning Session II Chitlada 3 INT ipwave IP Wireless Access in Vehicular = Environments WG Chitlada 2 IRTF qirg Quantum Internet Proposed Research Group Meeting 1 SEC oauth Web Authorization Protocol WG 1350-1550 Afternoon Session I Chitlada 3 INT 6man IPv6 Maintenance WG Chitlada 2 SEC rats Remote ATtestation ProcedureS BOF Chitlada 1 TSV quic QUIC WG 1610-1810 Afternoon Session II Chitlada 1 IRTF maprg Measurement and Analysis for Protocols Meeting 1 IRTF*** t2trg Thing-to-Thing Meeting 2 SEC secdispatch Security Dispatch WG Pagoda -- 1700..1800 CACAO side meeting Apartment 3 -- 1800..2000 IoT Onboarding side meeting (lear/mcr) WEDNESDAY, November 7, 2018 0900-1100 Morning Session I Chitlada 3 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Boromph. 3 RTG bier Bit Indexed Explicit Replication WG Meeting 2 SEC *** teep Trusted Execution Environment = Provisioning WG Chitlada 1 TSV quic QUIC WG 1120-1220 Morning Session II Meeting 2 INT *** lwig Light-Weight Implementation Guidance WG Chitlada 1 SEC tls Transport Layer Security WG Chitlada 2 TSV tsvwg Transport Area Working Group WG 1350-1520 Afternoon Session I Meeting 2 GEN wugh WGs Using GitHub BOF Chitlada 3 INT homenet Home Networking WG Meeting 1 IRTF panrg Path Aware Networking RG -- 1400..1500 IoT Onboarding Mechanisms side meeting 1540-1710 Afternoon Session II Chitlada 3 INT intarea Internet Area Working Group WG Meeting 1 IRTF pearg Privacy Enhancements and Assessments = Proposed Research Group Boromph. 3 RTG babel Babel routing protocol WG Boromph. 1/2 RTG rift Routing In Fat Trees WG Meeting 2 TSV taps Transport Services WG THURSDAY, November 8, 2018 0900-1100 Morning Session I Chitlada 1 ART httpbis Hypertext Transfer Protocol WG Meeting 2 IRTF icnrg Information-Centric Networking Chitlada 2 SEC *** suit Software Updates for Internet of Things = WG 1120-1220 Morning Session II Chitlada 2 ART *** core Constrained RESTful Environments WG Boromph. 1/2 RTG bier Bit Indexed Explicit Replication WG Chitlada 1 SEC mls Messaging Layer Security WG Meeting 1 TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1350-1550 Afternoon Session I Meeting 2 INT dnssd Extensions for Scalable DNS Service = Discovery WG Chitlada 2 RTG detnet Deterministic Networking WG Chitlada 1 SEC saag Security Area Open Meeting 1610-1810 Afternoon Session II Boromph. 3 INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Chitlada 3 RTG rtgarea Routing Area Open Meeting Chitlada 1 SEC *** ace Authentication and Authorization for = Constrained Environments WG Boromph. 1/2 SEC acme Automated Certificate Management = Environment WG FRIDAY, November 9, 2018 Various ad-hoc meetings, please see https://trac.ietf.org/trac/ietf/meeting/wiki/103sidemeetings#FRIDAY Boromph. 4 -- 0900..1320 T2TRG work meeting Boromph. 3 -- 1000..1200 COIN (Computing in the Network) From nobody Wed Oct 17 09:12:16 2018 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 58752130E14 for ; Wed, 17 Oct 2018 09:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.363 X-Spam-Level: X-Spam-Status: No, score=-4.363 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=PgQshBlf; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Ey+A7Kbb 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 G3f8oPffaLjA for ; Wed, 17 Oct 2018 09:12:12 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 B305D130E34 for ; Wed, 17 Oct 2018 09:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539792727; x=1542384727; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3ARU5rsMJ73NdFfPcwwapxdeC5td1OKsNk0xffIEUMc=; b=PgQshBlf8N4lF7jHIOrIWY/8Sz97zJx7mRHJlPc/NluNH0FdJM28FFzcwhyIkmty zAbrXuD83CBXUDHU7SRcLwcARs+r2e0RiVZPgGGLX2jlIJt500+hJpFWNIc97v4V flXMUqj0jyeiK0xsW+cWF2vevGOwcWQHzdw7ltw6FXY=; X-AuditID: c1b4fb30-2bbff700000047d2-37-5bc75f578274 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2C.06.18386.75F57CB5; Wed, 17 Oct 2018 18:12:07 +0200 (CEST) Received: from ESESBMR502.ericsson.se (153.88.183.134) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 17 Oct 2018 18:12:07 +0200 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMR502.ericsson.se (153.88.183.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 17 Oct 2018 18:12:06 +0200 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 17 Oct 2018 18:12:07 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3ARU5rsMJ73NdFfPcwwapxdeC5td1OKsNk0xffIEUMc=; b=Ey+A7KbbfjvunzG+5B89XQZcHKpeIjuX+7hrO3UVdAl4Aa97ouvp5lL/KCyY3vt8PSba8SieEvFplIo7s0a3IlLebV9au9sFuxQ6qLa7g9F4wn3gvm4Wxq4R+M7mpWyHENOiQGdYxNWrFQVDlzdfhwse6jlsL8NoI5/Ek8jMTXk= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2972.eurprd07.prod.outlook.com (10.168.93.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.18; Wed, 17 Oct 2018 16:12:05 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5%6]) with mapi id 15.20.1250.020; Wed, 17 Oct 2018 16:12:05 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: Minutes from 4th webex call Thread-Index: AQHUZjQlYFe//Bg/zEmdC1cyL244bA== Date: Wed, 17 Oct 2018 16:12:05 +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: [217.31.165.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2972; 6:naX3XYpvpc8qbbERTFkZZ5CBJ/1j4yLT3vrtTGo+ucrPbxux63PCRqWPePGr/qznSiD7H+6YrY5+734H2Bwol2eKkvaZZ8INLexPMMgBtv+W8zDskFHdVqum52b0EmVbeYIKbGqzH/SJTdOK5AyK+iB9EmawZfwh0EeJu5xUGBj331TKrV0aOnc2Y9Bu40RHvxKcXIIIv30J4TSukcrD25/+uimzQm5HbV1PlBWtgv0SxLBaKd9YpA3JW120YBz70UIIF0lvnMpqtGiXMUZvMZfwkZEcGbojs/udd1a6KfLwgn79n/fB4FPWcuJ1pCAYB8EBOgCc8T9rNfIEA4PmpRKqUDWHDs8SjvpMp+r2d4cp/fHRtmTAYZH798jCrISxhAWgHFu3wbDwuzyrGzwCTZbUkprpyakxVEOTU3OTxgEIyRgfPpoGOlFAW7eG5BDjuoqThrXhc3BfGdJNtBHD1g==; 5:lt6VWNJM3GXBl8J8dDwYBesRcYvqR7jE3yNo520/nbugzwGWTEFRve8oU35EK8mpytO969b9KqmkRh36SiDL6zUb7f4cU1hOpTELFnhfVEMbciLc7tMRhE4Sr4UU8s5Va5vNb7pjZjZ1kxPbOkRbz3Q956FhYAt27jc/IKd8m34=; 7:DkbA5vYTEayM/mtEs/+i+sE2WrpFWViZe/hPwFvpSBy++H2pFBKs8dquF0ncVzdBiARd3uGCxTutuIyqWb9JSrkI9EcO/VRY/1Yn6FFsI8UdaQ9lvLOIDP27QRhMGp80mevAJZ52FdJMZ5zEoRo0G7FosGHrM8hipVjIIrVFuBFDOI2orzl+Sfy3fyqDzTyTOcpU2c4yIXbmQzDDfP2crODNNoAlmnDmPKnDI47BpsxcdZpRv+Iinct4lSLvH68s x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 9e965c62-2fe9-4bac-9c46-08d6344b4806 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2972; x-ms-traffictypediagnostic: HE1PR0701MB2972: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820)(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(52105095)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1PR0701MB2972; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2972; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(366004)(39860400002)(346002)(136003)(189003)(53754006)(199004)(105586002)(44832011)(6506007)(106356001)(25786009)(2616005)(316002)(5640700003)(6436002)(2351001)(966005)(33656002)(486006)(476003)(8936002)(7736002)(14454004)(2900100001)(6916009)(450100002)(5250100002)(36756003)(53936002)(99286004)(8676002)(2501003)(102836004)(82746002)(256004)(186003)(4326008)(3846002)(6116002)(68736007)(26005)(14444005)(54896002)(81156014)(2906002)(71200400001)(6486002)(97736004)(6512007)(5660300001)(83716004)(236005)(66066001)(81166006)(606006)(478600001)(71190400001)(86362001)(6306002)(1730700003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2972; 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-microsoft-antispam-message-info: y9bLv1h8VRbdcT4qNxyptYsSRkmY/PyZPULeYK71cnvujt8cKic/ZiC0GazJBpo9m807430Qs9RVwk6Y0ZmEAYTOFZJCCP3/ExmqGsG/yha1877EqV/DzROgpEllW9iPHDGLE/e2tu7Mk7ughcL7n3opQVcZcMGQZDb6p+cfVKc5r/0W7HLJfluK9YXuYbX7mAFATI7+EGkN+/uyOzF1ROeEY/9S3J/qL3GhjyI/1WG17cbO9XcqZHSEtmkfb8KAMzRdiM2MCfNHfgVxI8Jfg/5vMeG9HC9/c28RSWrx1hR7dieU4NA/qV9xJ6y2+LYLw7yRDUoVOt3hfMqBClshsbwpbNJSWIoKVD3x7QLj1gA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BFA1069461BF4EA284ADA3259B4C2937ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9e965c62-2fe9-4bac-9c46-08d6344b4806 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2018 16:12:05.3907 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2972 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHOffebdfV4jgnPpimzgIV3yvzg2QRqFmJRFDpB5vzOiV1tmuS UqCBII6Z0Yb5hqmDalLmC2k18l3TCkNNMCEZmmKEDpWBL1m7uyv89jv/53cenudwaFLaLvCk s/MKGE2eIkcuFFM117qLQ66mjaaGP3gfFF33uwtF15RXU2eIBKNxi0hGKeKYDCYnu5DRhJ2+ Ic663zlM5P9cR3emfjSJSlD3L1SBXGjAJ8BUriU5luJhBM3LwTzbEJS1hv3nhbb4CiS2s5EA 68aQgDtQuIqENfNzEV+pJmDE+EfAH5YQmNo7hNx9IY6BL5Y1Accy7A8G/aA9p2kSR8CW+RYX u+GjMLfJjyTDgfBxaYzgFBkOhdKROC6m8DEYf6F3KBIcCy93OhwdEfaGzdJWxwYk9oBvi40E vxkGo3mC5NkdVhb2nL4SpucqRXwuh8ndJqfjDZONWsSND7hPBNvvJpyNQsBqMDilS2Dq+kTy 0hiCV5uPnJ2CoWWpV8CzGkqMOyJeqkRg0/UK+cIRMOksFF8YJKHH1CKoQmG1+0bnWQkztnmq 1rGqK4zVLNqZe7BAaHvr1P1Ar7WIeA6AsvoGJyfA041V0X7nCaJNyJ1l2PRcVWRkKKPJVrKs Oi80jynoQPaP1N+1E96DVpbPDiBMI/lBSXPiaKpUoChki3IHENCkXCYp9rNHkgxFUTGjUadp bucw7AA6TFNyD0l0UmeKFKsUBcxNhslnNP+qBO3iWYICm1V1Q1c63/T5CH31z3SG5ICY6/Vd rl/veXlKZk2J09QhpaHUsnKywef17KkPUb5eXgkzK16Rm+nfz/Vf1Jt1sdalmanV2JTZ0vjH d/3XR89PWY9LVP6iEO24rcZ1nbDOJ+9tCzIfqlXeiVX6A5bdzDg2LHgj6XNUc+VltwtzcorN UkQEkRpW8RfzNg7WRAMAAA== Archived-At: Subject: [Cbor] Minutes from 4th webex call 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, 17 Oct 2018 16:12:16 -0000 --_000_BFA1069461BF4EA284ADA3259B4C2937ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpIZXJlIGFyZSB0aGUgbm90ZXMgZnJvbSB0b2RheeKAmXMgaW50ZXJpbSBtZWV0 aW5nLCBhbHNvIHVwbG9hZGVkIG9uIHRoZSBkYXRhdHJhY2tlcjogaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9ncm91cC9jYm9yL21lZXRpbmdzLw0KUGFydGljaXBhbnRzLCBhcyBhbHdheXMs IHBsZWFzZSBsZXQgbWUga25vdyBpZiBhbnl0aGluZyB3YXMgbm90IGNhcHR1cmVkIGNvcnJlY3Rs eS4NCg0KUGxlYXNlIG5vdGUgdGhhdCB0aGUgbmV4dCBjYWxsIChpbiB0d28gd2Vla3MpIGlzIGNh bmNlbGxlZCwgYW5kIHdlIHdpbGwgbWVldCBkaXJlY3RseSBpbiBCYW5na29rLg0KDQpUaGFua3Ms DQpGcmFuY2VzY2ENCg0KLS0NCg0KQ0JPUiBXRyBDb25mZXJlbmNlIENhbGwNCldlZG5lc2RheSwg T2N0IDE3IDIwMTgsIDE1OjAwIC0gMTY6MDAgVVRDDQpDaGFpcnM6IEJhcnJ5IExlaWJhLCBGcmFu Y2VzY2EgUGFsb21iaW5pDQoNCk1pbnV0ZSB0YWtlcnM6IEZyYW5jZXNjYQ0KDQpQYXJ0aWNpcGFu dHM6DQoqIEJhcnJ5DQoqIENhcnN0ZW4gQm9ybWFubg0KKiBNaWNoYWVsIFJpY2hhcmRzb24NCiog UGF1bCBIb2ZmbWFuDQoqIEZyYW5jZXNjYQ0KKiBMYXVyZW5jZSBMdW5kYmxhZGUNCg0KSGFja2F0 aG9uIDEwMzoNCiAgICBCYXJyeTogYXJlIHdlIGdvaW5nIHRvIGhhdmUgYW4gaW50ZXJvcD8NCiAg ICBDYXJzdGVuOiBpZiB3ZSBoYXZlIGlzc3VlcyB3aGVyZSBhbiBpbnRlcm9wIHdvdWxkIGhlbHAN CiAgICBCYXJyeTogTm90IG5lY2Vzc2FyaWx5LCBidXQgcmF0aGVyIGZvciB2aXNpYmlsaXR5DQog ICAgQVAgQmFycnk6IHByZXNlbmNlIGF0IHRoZSBIYWNrYXRob24sIGF0IHRoZSB3aXNoaSB0YWJs ZSwgY29tZSBhbmQgam9pbiB1cw0KDQpDRERMIHN0YXR1czoNCiAgICBDYXJzdGVuOiBJQU5BIHF1 ZXN0aW9ucw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqIENEREwgY29udHJvbCBv cGVyYXRvcnMgYXJlIG5ldyByZWdpc3RyeQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAqIHNob3VsZCB0aGUgZW50cmllcyBiZSBhbHBoZWJhdGl6ZWQNCiAgICAgICAgICAgICAgICBC YXJyeTogd2h5IG5vdCwgYnV0IGl0IGRvZXMgbm90IHJlYWxseSBtYXR0ZXINCiAgICAgICAgICAg ICAgICBDYXJzdGVuOiBpZiBpdCBtYWtlcyBtb3JlIGxvZ2ljIHNlbnNlLCBoYXZpbmcgdGhlbSBp biBhbm90aGVyIG9yZGVyDQogICAgICAgICAgICAgICAgMiByZXZpZXdzIHRvIGZpeCBiZWZvcmUg SUVURjEwMw0KICAgICAgICAgICAgICAgIFdhaXRpbmcgZm9yIHdyaXRldXAgZnJvbSBBbGV4ZXkN CiAgICAgICAgICAgICAgICBBUCBCYXJyeTogcGluZyBBbGV4ZXkNCiAgICAgICAgICAgICAgICBU ZWxlY2hhdCBpbiBkZWNlbWJlciBob3BlZnVsbHkNCiAgICAgICAgICAgICAgICBGb3IgQmFuZ2tv ayB3ZSBjYW4gc3VtbWFyaXplIHRoZSBjaGFuZ2VzIGZyb20gcmV2aWV3cw0KDQpDQk9SIEJpcw0K ICAgICAgICAgICAgICAgIENhcnN0ZW46IGFueSBzdWJzdGVudGlhbCBmZWVkYmFjayBmcm9tIEpl ZmZyZXkgd2UgbmVlZCB0byBkaXNjdXNzIGluIEJhbmdrb2sNCiAgICAgICAgICAgICAgICBQYXVs OiBvbmUgbWFqb3IgaXNzdWUgaXMga2V5IGVxdWl2YWxlbmNlLCBhIG51bWJlciBvZiBtaW5vciBp c3N1ZXMuIFB1bGwgcmVxdWVzdHMgd2FpdGluZyB0byBiZSBmaXhlZCB0byBiZSBtZXJnZWFibGUu DQogICAgICAgICAgICAgICAgQ2Fyc3RlbjogZmlyc3QgY29tbWl0IG9uIHRoZSBpc3N1ZSBmcm9t IExhdXJlbmNlIDYgZGF5cyBhZ28uIE1vc3Qgb2YgdGhlIHdvcmsgaXMgZG9uZSBidXQgd2UgaGF2 ZSB0byBhZ3JlZSB0aGF0IHdlIGFncmVlLg0KDQogICAgICAgICAgICAgICAgbWFwIGtleSBlcXVp dmFsZW5jZSBjb21taXQNCiAgICAgICAgICAgICAgICBDYXJzdGVuIGdvaW5nIHRocm91Z2ggaHR0 cHM6Ly9naXRodWIuY29tL2Nib3Itd2cvQ0JPUmJpcy9jb21taXQvZDJiYTc3N2Q1NGZhYTY0OWM4 ZTZiMzBjMDllMTlhYzg5ODQyNmJlOA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt IGdlbmVyaWMgZGVmaW5pdGlvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtIHBy ZWZlcnJlZCBlbmNvZGluZyBmb3IgZmxvYXRpbmcgcG9pbnQgdmFsdWVzIChhbGwgdGhlIHRpbWUg bm90IGp1c3QgZm9yIHdoZW4gdGhleSBhcmUga2V5cykNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLSBkYXRhIG1vZGVsIHVzZSBpbiBlcXVpdmFsZW5jZSBvZiBrZXlzIHNlY3Rpb24N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLSBuZXcgdGV4dCBhYm91dCBwcmVmZXJy ZWQgc2VyaWFsaXphdGlvbjogc3RhcnRlZCBmcm9tIExhdXJlbmNlIHRleHQgYnV0IGVkaXRvcmlh bGx5IGRpZmZlcmVudA0KICAgICAgICAgICAgICAgIE1pY2hhZWw6IGRvZXNuJ3QgbGlrZSB0aGlz IG5vbi1iaW5hcnkgaW50ZXJvcGVyYWJpbGl0eS4NCiAgICAgICAgICAgICAgICBMYXVyZW5jZTog bG9va2luZyBmb3IgY2xlYXIgcnVsZSB0aGF0IGlmIHlvdSBmb2xsb3cgeW91IGFsd2F5cyBhcmUg Z29pbmcgdG8gYmUgaW50ZXJvcGVyYWJsZQ0KICAgICAgICAgICAgICAgIENhcnN0ZW46IG1heWJl IGNhbiBiZSByZXBocmFzZWQgaW4gInNvbWUgcHJvdG9jb2wgY3JlYXRlIHRoZSBvcHBvcnR1bml0 eSB0byBoYXZlIHRoYXQiDQogICAgICAgICAgICAgICAgTWljaGFlbDogdGhpcyBpcyBub3QgdW5k ZXIgaW1wbGVtZW50YXRpb24gc2VjdGlvbi4gInByb3RvY29sIGRlc2lnbmVycyBtYXkgd2FudCB0 byB1c2UgY29uc3RyYWluZWQgZGVjb2RlcnMsIHRoZXkgbmVlZCB0byBjYWxsIHRoYXQgb3V0LCB3 aGVuZXZlciB0aGV5IG1ha2UgdXNlIG9mIHNob3J0Y3V0IHRoYXQgZG9lcyBub3QgbWFrZSB1c2Ug b2YgcHJlZmVycmVkIHNlcmlhbGl6YXRpb24iDQogICAgICAgICAgICAgICAgTGF1cmVuY2U6IG1v c3QgaW50ZXJlc3RlZCBpbiBpbmRlZmluaXRlIGxlbmd0aC4NCiAgICAgICAgICAgICAgICBDYXJz dGVuOiBtYWtlIHRoZSByb2xlIG9mIHRoZSBwcm90b2NvbCBtb3JlIGNsZWFyLg0KICAgICAgICAg ICAgICAgIExhdXJlbmNlLCBNaWNoYWVsOiB5ZXMNCiAgICAgICAgICAgICAgICBNaWNoYWVsOiBp ZiB3ZSBkb24ndCwgcGVvcGxlIHdpbGwgbWFrZSBiYWQgYXNzdW1wdGlvbnMNCiAgICAgICAgICAg ICAgICBDYXJzdGVuOiBPaywgdGhhbmtzDQoNCiAgICAgICAgICAgICAgICBMYXVyZW5jZTogUFIg Zm9yIGRhdGVzIGFuZCBmb3Igc2hvcnRlc3QgZmxvYXRpbmcgcG9pbnQNCiAgICAgICAgICAgICAg ICBDYXJzdGVuOiBmbG9hdGluZyBwb2ludCBpcyB0aGUgY29tbWl0IGFib3ZlLCB0aGUgb3RoZXIg c3RpbGwgb24gdGhlIHRvZG8gbGlzdA0KICAgICAgICAgICAgICAgIExhdXJlbmNlOiByZWZlcmVu Y2UgSUVFRTc1NA0KICAgICAgICAgICAgICAgIENhcnN0ZW46IHllcyB3ZSBzaG91bGQNCg0KICAg ICAgICAgICAgICAgIExhdXJlbmNlOiBwcmVjaXNpb24gZm9yIGZsb2F0aW5nIHBvaW50DQogICAg ICAgICAgICAgICAgQ2Fyc3RlbiBwb2ludHMgdG8gbC4gMTI3MC0xMjc4IGluIGNvbW1pdCBhYm92 ZQ0KICAgICAgICAgICAgICAgIENhcnN0ZW46IEkgdGhpbmsgcHV0dGluZyBpbmZvcm1hdGlvbiBp biBoZXJlIHdvdWxkIGJlIHdyb25nLiBJbXBvcnRhbnQgcGFydCBpcyB0aGF0IGlmIHlvdSBjaG9v c2UgYW4gZW5jb2RpbmcgdGhhdCBsb3NlcyBwcmVjaXNpb24sIHRoYXQgc2hvdWxkIGJlIHNvbWV0 aGluZyB0aGF0IGlzIGV4cGxpY2l0LCBkZXNpcmVkIGJ1eSB0aGUgYXBwbGljYXRpb24sIGJ1dCB0 aGUgb3RoZXIgZGlyZWN0aW9uIGlzIG5vdCB2ZXJ5IHVzZWZ1bA0KICAgICAgICAgICAgICAgIExh dXJlbmNlOiBob3cgZG8geW91IGRlY2lkZSBpZiBzb21ldGhpbmcgY2FuIG1ha2UgYmVlbiBzaG9y dGVyIG9yIG5vdD8NCiAgICAgICAgICAgICAgICBDYXJzdGVuOiBsaW5lIDEyNzENCiAgICAgICAg ICAgICAgICBMYXVyZW5jZTogd2Ugc2hvdWxkIGludGVyb3AgdGVzdA0KICAgICAgICAgICAgICAg IENhcnN0ZW46IEhhY2thdGhvbiAxMDMNCg0KICAgICAgICAgICAgICAgIE1pY2hhZWw6IHN1Z2dl c3Rpb246IHdlIHNob3VsZCBoYXZlIHNvbWUgdGV4dCBhYm91dCAiY2JvciBiYXNlZCBwcm90b2Nv bCBpcyBzdXBwb3NlZC9leHBlY3RlZCB0byB1c2UgYWxsIHByZWZlcnJlZCBzZXJpYWxpemF0aW9u Ig0KICAgICAgICAgICAgICAgIENhcnN0ZW46IHllcyB3ZSBjYW4gYWRkIHRoYXQNCg0KICAgICAg ICAgICAgICAgIENhcnN0ZW46IG5leHQgc3RlcHM6IHdhaXQgb24gSmVmZnJleSdzIGZlZWRiYWNr IGJlZm9yZSBpbmNsdWRpbmcgaGlzIHJlcXVlc3RzLiBUcnkgdG8gZ2V0IExhdXJlbmNlJ3MgaW4g YmVmb3JlIGRyYWZ0cyBjdXRvZmYuDQoNCiAgICAgICAgICAgICAgICBBUCBjaGFpcnM6IEFnZW5k YSBmb3IgQmFuZ2tvayBtZWV0aW5nIHRvIGJlIHJlcXVlc3RlZCBpbiB0aGUgbWFpbGluZyBsaXN0 DQoNCiAgICAgICAgICAgICAgICBBcnJheSB0YWc6IENhcnN0ZW4gdG8gY2hlY2sgdGhhdCB0aGUg ZHJhZnQgd2FzIHVwZGF0ZWQgYW5kIHRoZW4gYWRvcHQNCg0KICAgICAgICAgICAgICAgIE5leHQg Y29uZmVyZW5jZSBjYWxsIGlzIGNhbmNlbGxlZCBhbmQgd2UgbWVldCBpbiBCYW5na29rDQo= --_000_BFA1069461BF4EA284ADA3259B4C2937ericssoncom_ 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 bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJTViIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5I aSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+SGVyZSBhcmUgdGhlIG5vdGVzIGZyb20gdG9kYXnigJlzIGludGVyaW0gbWVldGluZywg YWxzbyB1cGxvYWRlZCBvbiB0aGUgZGF0YXRyYWNrZXI6DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ncm91cC9jYm9yL21lZXRpbmdzLyI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv Z3JvdXAvY2Jvci9tZWV0aW5ncy88L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBhcnRpY2lwYW50cywgYXMgYWx3YXlzLCBwbGVhc2Ug bGV0IG1lIGtub3cgaWYgYW55dGhpbmcgd2FzIG5vdCBjYXB0dXJlZCBjb3JyZWN0bHkuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPlBsZWFzZSBub3RlIHRoYXQgdGhlIG5leHQgY2FsbCAoaW4gdHdvIHdlZWtzKSBpcyBj YW5jZWxsZWQsIGFuZCB3ZSB3aWxsIG1lZXQgZGlyZWN0bHkgaW4gQmFuZ2tvay48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJhbmNlc2NhPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkNCT1IgV0cgQ29uZmVyZW5jZSBDYWxsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5XZWRuZXNkYXksIE9jdCAxNyAyMDE4LCAxNTowMCAtIDE2OjAw IFVUQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q2hhaXJzOiBCYXJyeSBMZWliYSwg RnJhbmNlc2NhIFBhbG9tYmluaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NaW51dGUgdGFrZXJzOiBGcmFuY2VzY2E8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+UGFydGljaXBhbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ KiBCYXJyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+KiBDYXJzdGVuIEJvcm1hbm48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiogTWljaGFlbCBSaWNoYXJkc29uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPiogUGF1bCBIb2ZmbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiogRnJhbmNlc2Nh PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiogTGF1cmVuY2UgTHVuZGJsYWRlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IYWNrYXRob24gMTAzOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+QmFycnk6IGFyZSB3ZSBnb2luZyB0byBoYXZlIGFuIGludGVyb3A/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgQ2Fyc3Rlbjog aWYgd2UgaGF2ZSBpc3N1ZXMgd2hlcmUgYW4gaW50ZXJvcCB3b3VsZCBoZWxwPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgQmFycnk6IE5vdCBuZWNlc3Nh cmlseSwgYnV0IHJhdGhlciBmb3IgdmlzaWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFQIEJhcnJ5OiBwcmVzZW5jZSBhdCB0aGUgSGFja2F0 aG9uLCBhdCB0aGUgd2lzaGkgdGFibGUsIGNvbWUgYW5kIGpvaW4gdXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q0RE TCBzdGF0dXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsgQ2Fyc3RlbjogSUFOQSBxdWVzdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAqIENEREwgY29udHJvbCBvcGVyYXRvcnMgYXJlIG5ldyByZWdpc3Ry eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICogc2hvdWxk IHRoZSBlbnRyaWVzIGJlIGFscGhlYmF0aXplZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJhcnJ5OiB3aHkgbm90LCBidXQg aXQgZG9lcyBub3QgcmVhbGx5IG1hdHRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENhcnN0ZW46IGlmIGl0IG1ha2VzIG1v cmUgbG9naWMgc2Vuc2UsIGhhdmluZyB0aGVtIGluIGFub3RoZXIgb3JkZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyIHJl dmlld3MgdG8gZml4IGJlZm9yZSBJRVRGMTAzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2FpdGluZyBmb3Igd3JpdGV1cCBm cm9tIEFsZXhleTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFQIEJhcnJ5OiBwaW5nIEFsZXhleTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRlbGVjaGF0 IGluIGRlY2VtYmVyIGhvcGVmdWxseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZvciBCYW5na29rIHdlIGNhbiBzdW1tYXJp emUgdGhlIGNoYW5nZXMgZnJvbSByZXZpZXdzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkNCT1IgQmlzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Q2Fyc3RlbjogYW55IHN1YnN0ZW50aWFsIGZlZWRiYWNrIGZyb20gSmVmZnJleSB3ZSBuZWVkIHRv IGRpc2N1c3MgaW4gQmFuZ2tvazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhdWw6IG9uZSBtYWpvciBpc3N1ZSBpcyBrZXkg ZXF1aXZhbGVuY2UsIGEgbnVtYmVyIG9mIG1pbm9yIGlzc3Vlcy4gUHVsbCByZXF1ZXN0cyB3YWl0 aW5nIHRvIGJlIGZpeGVkIHRvIGJlIG1lcmdlYWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDYXJzdGVuOiBmaXJzdCBj b21taXQgb24gdGhlIGlzc3VlIGZyb20gTGF1cmVuY2UgNiBkYXlzIGFnby4gTW9zdCBvZiB0aGUg d29yayBpcyBkb25lIGJ1dCB3ZSBoYXZlIHRvIGFncmVlIHRoYXQgd2UgYWdyZWUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYXAga2V5IGVxdWl2YWxlbmNl IGNvbW1pdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IENhcnN0ZW4gZ29pbmcgdGhyb3VnaCBodHRwczovL2dpdGh1Yi5jb20v Y2Jvci13Zy9DQk9SYmlzL2NvbW1pdC9kMmJhNzc3ZDU0ZmFhNjQ5YzhlNmIzMGMwOWUxOWFjODk4 NDI2YmU4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBn ZW5lcmljIGRlZmluaXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAtIHByZWZlcnJlZCBlbmNvZGluZyBmb3IgZmxvYXRpbmcgcG9pbnQgdmFsdWVzIChh bGwgdGhlIHRpbWUgbm90IGp1c3QgZm9yIHdoZW4gdGhleSBhcmUga2V5cyk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIGRhdGEgbW9kZWwgdXNlIGluIGVx dWl2YWxlbmNlIG9mIGtleXMgc2VjdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0gbmV3IHRleHQgYWJvdXQgcHJlZmVycmVkIHNlcmlhbGl6YXRpb246 IHN0YXJ0ZWQgZnJvbSBMYXVyZW5jZSB0ZXh0IGJ1dCBlZGl0b3JpYWxseSBkaWZmZXJlbnQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBNaWNoYWVsOiBkb2Vzbid0IGxpa2UgdGhpcyBub24tYmluYXJ5IGludGVyb3BlcmFiaWxp dHkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBMYXVyZW5jZTogbG9va2luZyBmb3IgY2xlYXIgcnVsZSB0aGF0IGlmIHlv dSBmb2xsb3cgeW91IGFsd2F5cyBhcmUgZ29pbmcgdG8gYmUgaW50ZXJvcGVyYWJsZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IENhcnN0ZW46IG1heWJlIGNhbiBiZSByZXBocmFzZWQgaW4gJnF1b3Q7c29tZSBwcm90b2NvbCBj cmVhdGUgdGhlIG9wcG9ydHVuaXR5IHRvIGhhdmUgdGhhdCZxdW90OzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1pY2hhZWw6 IHRoaXMgaXMgbm90IHVuZGVyIGltcGxlbWVudGF0aW9uIHNlY3Rpb24uICZxdW90O3Byb3RvY29s IGRlc2lnbmVycyBtYXkgd2FudCB0byB1c2UgY29uc3RyYWluZWQgZGVjb2RlcnMsIHRoZXkgbmVl ZCB0byBjYWxsIHRoYXQgb3V0LCB3aGVuZXZlciB0aGV5IG1ha2UgdXNlIG9mIHNob3J0Y3V0IHRo YXQNCiBkb2VzIG5vdCBtYWtlIHVzZSBvZiBwcmVmZXJyZWQgc2VyaWFsaXphdGlvbiZxdW90Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IExhdXJlbmNlOiBtb3N0IGludGVyZXN0ZWQgaW4gaW5kZWZpbml0ZSBsZW5ndGguPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQ2Fyc3RlbjogbWFrZSB0aGUgcm9sZSBvZiB0aGUgcHJvdG9jb2wgbW9yZSBjbGVhci48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBMYXVyZW5jZSwgTWljaGFlbDogeWVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTWljaGFlbDogaWYgd2UgZG9u J3QsIHBlb3BsZSB3aWxsIG1ha2UgYmFkIGFzc3VtcHRpb25zPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2Fyc3RlbjogT2ss IHRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTGF1 cmVuY2U6IFBSIGZvciBkYXRlcyBhbmQgZm9yIHNob3J0ZXN0IGZsb2F0aW5nIHBvaW50PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgQ2Fyc3RlbjogZmxvYXRpbmcgcG9pbnQgaXMgdGhlIGNvbW1pdCBhYm92ZSwgdGhlIG90aGVy IHN0aWxsIG9uIHRoZSB0b2RvIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMYXVyZW5jZTogcmVmZXJlbmNlIElFRUU3 NTQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBDYXJzdGVuOiB5ZXMgd2Ugc2hvdWxkPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMYXVyZW5jZTogcHJlY2lzaW9uIGZvciBmbG9hdGluZyBw b2ludDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IENhcnN0ZW4gcG9pbnRzIHRvIGwuIDEyNzAtMTI3OCBpbiBjb21taXQgYWJv dmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBDYXJzdGVuOiBJIHRoaW5rIHB1dHRpbmcgaW5mb3JtYXRpb24gaW4gaGVyZSB3 b3VsZCBiZSB3cm9uZy4gSW1wb3J0YW50IHBhcnQgaXMgdGhhdCBpZiB5b3UgY2hvb3NlIGFuIGVu Y29kaW5nIHRoYXQgbG9zZXMgcHJlY2lzaW9uLCB0aGF0IHNob3VsZCBiZSBzb21ldGhpbmcgdGhh dCBpcyBleHBsaWNpdCwgZGVzaXJlZA0KIGJ1eSB0aGUgYXBwbGljYXRpb24sIGJ1dCB0aGUgb3Ro ZXIgZGlyZWN0aW9uIGlzIG5vdCB2ZXJ5IHVzZWZ1bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExhdXJlbmNlOiBob3cgZG8g eW91IGRlY2lkZSBpZiBzb21ldGhpbmcgY2FuIG1ha2UgYmVlbiBzaG9ydGVyIG9yIG5vdD88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBDYXJzdGVuOiBsaW5lIDEyNzE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMYXVyZW5jZTogd2Ugc2hvdWxkIGludGVy b3AgdGVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IENhcnN0ZW46IEhhY2thdGhvbiAxMDM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1pY2hhZWw6IHN1Z2dlc3Rpb246IHdlIHNob3Vs ZCBoYXZlIHNvbWUgdGV4dCBhYm91dCAmcXVvdDtjYm9yIGJhc2VkIHByb3RvY29sIGlzIHN1cHBv c2VkL2V4cGVjdGVkIHRvIHVzZSBhbGwgcHJlZmVycmVkIHNlcmlhbGl6YXRpb24mcXVvdDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBDYXJzdGVuOiB5ZXMgd2UgY2FuIGFkZCB0aGF0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDYXJzdGVuOiBuZXh0IHN0ZXBzOiB3YWl0IG9uIEplZmZy ZXkncyBmZWVkYmFjayBiZWZvcmUgaW5jbHVkaW5nIGhpcyByZXF1ZXN0cy4gVHJ5IHRvIGdldCBM YXVyZW5jZSdzIGluIGJlZm9yZSBkcmFmdHMgY3V0b2ZmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQVAgY2hhaXJzOiBBZ2VuZGEgZm9yIEJhbmdrb2sgbWVl dGluZyB0byBiZSByZXF1ZXN0ZWQgaW4gdGhlIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXJyYXkgdGFnOiBDYXJzdGVuIHRvIGNoZWNr IHRoYXQgdGhlIGRyYWZ0IHdhcyB1cGRhdGVkIGFuZCB0aGVuIGFkb3B0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOZXh0IGNvbmZlcmVuY2UgY2FsbCBpcyBj YW5jZWxsZWQgYW5kIHdlIG1lZXQgaW4gQmFuZ2tvazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BFA1069461BF4EA284ADA3259B4C2937ericssoncom_-- From nobody Fri Oct 19 11:59:04 2018 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 6FA11131078; Fri, 19 Oct 2018 11:56:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: cbor@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997538944.6592.15369644839654234005.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:29 -0700 Archived-At: Subject: [Cbor] cbor - Requested session has been scheduled for IETF 103 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, 19 Oct 2018 18:56:36 -0000 Dear Barry Leiba, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. cbor Session 1 (2:00 requested) Wednesday, 7 November 2018, Morning Session I 0900-1100 Room Name: Chitlada 3 size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/cbor.ics Request Information: --------------------------------------------------------- Working Group Name: Concise Binary Object Representation Maintenance and Extensions Area Name: Applications and Real-Time Area Session Requester: Barry Leiba Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: artarea dispatch secdispatch saag extra jmap uta dmarc dcrup iasa2 core ace t2trg Second Priority: suit lwig anima 6tisch Third Priority: acme roll detnet sacm lpwan dots People who must be present: Carsten Bormann Barry Leiba Alexey Melnikov Francesca Palombini Resources Requested: Special Requests: Please avoid conflict with ART and IoT-related BoFs Please avoid Friday: one chair has to leave on Thursday night --------------------------------------------------------- From nobody Sat Oct 20 22:10:32 2018 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 E28A4130E23 for ; Sat, 20 Oct 2018 22:10:30 -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 Aezk_0rNRQhb for ; Sat, 20 Oct 2018 22:10:27 -0700 (PDT) Received: from p3plsmtpa08-02.prod.phx3.secureserver.net (p3plsmtpa08-02.prod.phx3.secureserver.net [173.201.193.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 778DB126DBF for ; Sat, 20 Oct 2018 22:10:27 -0700 (PDT) Received: from [192.168.0.101] ([121.46.87.45]) by :SMTPAUTH: with ESMTPSA id E60MgrrhrwCTmE60OgJWaH; Sat, 20 Oct 2018 22:10:25 -0700 From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0CE406F8-C049-4F18-9F8B-E53525B79461" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sun, 21 Oct 2018 10:40:22 +0530 In-Reply-To: <07152864-D276-451E-B001-DE429705B76B@island-resort.com> Cc: Sean Solberg To: cbor@ietf.org References: <2B5BDE55-EE9E-4CAD-A2BF-8435C46103AE@island-resort.com> <07152864-D276-451E-B001-DE429705B76B@island-resort.com> X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfKNQBWtQoCFY12shntTj/GiZPAMP0yHQHj9mdXpcdgKtf/+I1PP9eRPZ6CFXhzmu+qhYPUH74ut3Hse9A/yN/9hxQrClGePVd6pa7IMx4cvttPkEuqIe mWGf6nQfS7Zc4jCJl6v/UrVVOeSlrXVO5ejSYyI64RQWSh8rt2wZrN3WVg1+c4dlH1/kooHsZRrx7Q== Archived-At: Subject: Re: [Cbor] New pull request proposal for shortest float encoding 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, 21 Oct 2018 05:10:31 -0000 --Apple-Mail=_0CE406F8-C049-4F18-9F8B-E53525B79461 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So here=E2=80=99s Carsten=E2=80=99s latest text of float encoding from = GitHub. The preferred encoding for a floating point value is the shortest = floating point encoding that preserves its value, e.g., 0xf94580 for the = number 5.5, and 0xfa45ad9c00 for the number 5555.5, unless the = CBOR-based protocol specifically excludes the use of the shorter = floating point encodings. For NaN values, a shorter encoding is = preferred if zero-padding the significand at the right reconstitutes the = original NaN value (for many applications, the single NaN encoding = 0xf97e00 will suffice). After thinking about it some, I think this creates a decoding problem.=20= If a decoder library receives a half-precision or single-precision = float, the decoder does not know if it should promote that to a double = or not when handing it up to the app using it. If the sender is using = preferred encoding as described above, then the answer is yes. If not = then it should not. The decoder however has no way of knowing whether = the encoder is using half-precision as part of preferred serialization = or because the sender really wanted it to be half-precision. I was OK with some ambiguity for a special option for shortest float = that I proposed here , but I = do not think it is good for the front-and-center preferred encoding for = floats. One solution is the original pull request. A tag could be added to make = it clear. The tag could be on an enclosing map/array. It doesn=E2=80=99t = need to be on every float. Another similar is to have a tag indicating the sender is using = preferred serialization. Another is to make preferred serialization the base and have a tag that = indicates otherwise.=20 LL > On Aug 28, 2018, at 2:28 AM, Laurence Lundblade = wrote: >=20 > Sean, really glad you brought all this up and wrote it down. I was = thinking some of it myself and it needs to be addressed. >=20 > Seems like we have a few options for indicating precision for shortest = float encoding > - Each CBOR protocol specification explicitly states that shortest = float encoding is used for particular values. There is nothing explicit = in the protocol messages > - We use a tag like Thiago suggested > - Both of the above are allowed >=20 > Since the tag takes up space, maybe the tag could be applied to maps = and arrays to indicate all float data items in them are of a particular = type. This would complicate the decoder as it has to keep track of some = context at each nesting level. >=20 >=20 > I don=E2=80=99t think the preference for shortest form that we apply = to integers should apply to floats. Floats are fundamentally different = from integers. Floats are only approximations of the actual value. = Precision tells you how good the approximation is which matters in some = use cases. If you encode 3 as 0x00000003 instead of 0x03 you don=E2=80=99= t really get any more information, but there is a difference between = 3.000 and 3.000000. That is why I propose that float and double are not = subject to any shortest-form rule in the preferred serialization pull = request . >=20 >=20 > I thought about leaving shortest float encoding entirely out of the = RFC for most simplicity. If we leave it out, any CBOR protocol could = still define it and use it.=20 >=20 > However, shortest float encoding does seems truly useful in reducing = message sizes a lot for a lot of use cases. It also isn=E2=80=99t easy = to figure out (at least it took me a while=E2=80=A6), so I=E2=80=99m = inclined to put it in. Note that I believe the only purpose of shortest = float encoding is to reduce message size. I see no value in it for = canonicalization or for interop. In fact it is extra complexity so it = will hurt interop. >=20 > LL >=20 >=20 >=20 >=20 >> On Aug 26, 2018, at 8:34 PM, Sean Solberg > wrote: >>=20 >> Follow up question: the proposal states: Generally the decoder = should promote half- and single-precision values to double-precision = when they are received as it is implied that all half- and = single-precision values transmitted are actually double precision.=20 >>=20 >> Why is it implied that a transmitted single precision value is = actually a double precision value? That makes no sense. A single = precision value is implied to be a single precision value in my mind. = If there was a "please treat as a double" flag sent along with a single = precision value, then the transmitted data explicitly defines that the = transmitted single precision value should be treated as a double = precision value by the receiver. without the flag, the single precision = value transmitted should be treated by the receiver as a single = precision value. Explicit behavior is great. Implicitly expecting a = receiver to treat all floats (half, single & double) as doubles when = received is implicitly a wrong choice. =20 >>=20 >> In general, any time things are done "implicitly", we end up with = compatibility problems because people make different implicit = choices/assumptions. I believe keeping things explicit is a much better = way to go. =20 >> ..Sean >>=20 >> On Sun, Aug 26, 2018 at 10:25 PM, Sean Solberg > wrote: >> Question on this: Even though the actual value transmitted has not = lost any precision for that particular value, how does the receiver then = know that the intended data type actually does have higher precision = than what was transmitted? Are there some flags somewhere that notify = the receiver that it's actually a double instead of a single or its = actually a single instead of a half? >>=20 >> ..Sean >>=20 >> On Sat, Aug 25, 2018 at 3:38 PM, Laurence Lundblade = > wrote: >> https://github.com/cbor-wg/CBORbis/pull/32 = >>=20 >> This is a proposal to reduce CBOR message size without losing = floating point precision by encoding the larger floating point values as = smaller ones when it can be done without dropping any significant bits. >>=20 >> I personally don't think this should be part of canonicalization, or = part of preferred encoding. It's just a very useful way of encoding = floating points that seems worth including in the RFC. >>=20 >> LL >>=20 >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor = >>=20 >>=20 >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_0CE406F8-C049-4F18-9F8B-E53525B79461 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
So here=E2=80=99s Carsten=E2=80=99s latest text of float = encoding from GitHub.

The preferred encoding = for a floating point value is the shortest floating point encoding that = preserves its value, e.g., 0xf94580 for the number 5.5, and 0xfa45ad9c00 = for the number 5555.5, unless the CBOR-based protocol specifically = excludes the use of the shorter floating point encodings. For NaN = values, a shorter encoding is preferred if zero-padding the significand = at the right reconstitutes the original NaN value (for many = applications, the single NaN encoding 0xf97e00 will = suffice).

After thinking about it some, I think = this creates a decoding problem. 

If a decoder library receives a = half-precision or single-precision float, the decoder does not know if = it should promote that to a double or not when handing it up to the app = using it. If the sender is using preferred encoding as described above, = then the answer is yes. If not then it should not.  The decoder = however has no way of knowing whether the encoder is using = half-precision as part of preferred serialization or because the sender = really wanted it to be half-precision.

I was OK with some ambiguity for a = special option for shortest float that I proposed here, = but I do not think it is good for the front-and-center preferred = encoding for floats.

One solution is the original pull request.  A tag could = be added to make it clear. The tag could be on an enclosing map/array. = It doesn=E2=80=99t need to be on every float.

Another similar is to have a tag = indicating the sender is using preferred serialization.

Another is to make = preferred serialization the base and have a tag that indicates = otherwise. 

LL





On Aug 28, 2018, at 2:28 AM, Laurence Lundblade <lgl@island-resort.com> wrote:

Sean, really glad you = brought all this up and wrote it down. I was thinking some of it myself = and it needs to be addressed.

Seems like we have a few options for indicating precision for = shortest float encoding
- Each CBOR protocol = specification explicitly states that shortest float encoding is used for = particular values. There is nothing explicit in the protocol = messages
- We use a tag like Thiago = suggested
- Both of the above are allowed

Since the tag takes up = space, maybe the tag could be applied to maps and arrays to indicate all = float data items in them are of a particular type. This would complicate = the decoder as it has to keep track of some context at each nesting = level.


I don=E2=80=99t think the preference = for shortest form that we apply to integers should apply to floats. = Floats are fundamentally different from integers.  Floats are only = approximations of the actual value. Precision tells you how good the = approximation is which matters in some use cases.  If you encode 3 = as 0x00000003 instead of 0x03 you don=E2=80=99t really get any more = information, but there is a difference between 3.000 and 3.000000. That = is why I propose that float and double are not subject to any = shortest-form rule in the preferred = serialization pull request.


I = thought about leaving shortest float encoding entirely out of the RFC = for most simplicity. If we leave it out, any CBOR protocol could still = define it and use it. 

However, shortest float encoding does seems truly useful in = reducing message sizes a lot for a lot of use cases. It also isn=E2=80=99t= easy to figure out (at least it took me a while=E2=80=A6), so I=E2=80=99m= inclined to put it in.  Note that I believe the only purpose of = shortest float encoding is to reduce message size. I see no value in it = for canonicalization or for interop.  In fact it is extra = complexity so it will hurt interop.

LL




On Aug 26, 2018, at 8:34 PM, Sean Solberg = <ssolbs99@gmail.com> wrote:

Follow up question:  the proposal states:   Generally the decoder should promote half- and single-precision values to = double-precision when they are = received as it is implied that all half- and single-precision values transmitted are = actually double precision. Why is it = implied that a transmitted single precision value is actually a double = precision value?   That makes no sense.  A single = precision value is implied to be a single precision value in my = mind.   If there was a "please treat as a double" = flag sent along with a single precision value, then the transmitted data = explicitly defines that the transmitted single precision value should be = treated as a double precision value by the receiver.  without the = flag, the single precision value transmitted should be treated by the = receiver as a single precision value.  Explicit behavior is = great.  Implicitly expecting a receiver to treat all floats (half, = single & double) as doubles when received is implicitly a wrong = choice.    

In general, any time things are done = "implicitly", we end up with compatibility problems because people make = different implicit choices/assumptions.  I believe keeping things = explicit is a much better way to go.  
..Sean

On Sun, = Aug 26, 2018 at 10:25 PM, Sean Solberg <ssolbs99@gmail.com> wrote:
Question on this:  Even though the actual value = transmitted has not lost any precision for that particular value, how = does the receiver then know that the intended data type actually does = have higher precision than what was transmitted?  Are there some = flags somewhere that notify the receiver that it's actually a double = instead of a single or its actually a single instead of a half?

..Sean

On Sat, Aug 25, 2018 at 3:38 PM, Laurence = Lundblade <lgl@island-resort.com> wrote:
https://github.com/cbor-wg/CBORbis/pull/32

This is a proposal to reduce CBOR message size without losing = floating point precision by encoding the larger floating point values as = smaller ones when it can be done without dropping any significant = bits.

I personally don't think this should be part of = canonicalization, or part of preferred encoding. It's just a very useful = way of encoding floating points that seems worth including in the = RFC.

LL


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



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

_______________________________________= ________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor

= --Apple-Mail=_0CE406F8-C049-4F18-9F8B-E53525B79461-- From nobody Sun Oct 21 16:00:43 2018 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 63851130DCD for ; Sun, 21 Oct 2018 16:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8SE2xmwCa0v for ; Sun, 21 Oct 2018 16:00:39 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 28651130DDB for ; Sun, 21 Oct 2018 16:00:39 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id q7-v6so15011206wrr.8 for ; Sun, 21 Oct 2018 16:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hWB6ICixobOOUb/KCotC2nsJuRMvjVWNgf09Na4MKyM=; b=PYzpGqy83n2k0hnTMRy0hzJLQut3S1RGZs8ErixE3PLJ7fgYyEo8lDs2dq7L4BW8z7 kYnRIz0FUSD9mJnWzEZ8TzD6AMnAmpjdYHud3IDg7P0nNydiXpCleeqC1fySRSdtjY2V C5eboDdE5jmu4jDUGo5uymieJbcJuX5bcrUCe900ZHNWb9+WQ4rGtM07DQOY8adc6L5r bC/z/OoEpwG5zvTvZqoqglXfH/6w41nMEeno02Y/YYjdd5FBVTpIEnh+0gnWbfM63f3l YrHENPs5GfjK1Yrfep+NY2A1RVcxBi+dPC481K7/Qwb1/e3ANnivUhu4UwWzRqWCrt3O Vy6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hWB6ICixobOOUb/KCotC2nsJuRMvjVWNgf09Na4MKyM=; b=EdGK9Uv0DuPvmxJEe/YfNmM7+lQgXnfQeL73ZL3xgQfgn1WoB7S8lGVc1odw5sCkVs bgf6P+uGlYwyNaQ8lsR6kRvqsAzHIkxw0ieWymtwru3P2PCQCduwEKvA8FqL9qXXJoAS MZTItsG6HAfyovjChZTUOnb6Y4tsCSv78A0kwp2ro4WgAah5zBsKTmzwErMPFr3HlmEV /0ZcXgt57NMyAT5T5f+YzUzP0bWTD4LG8TodlxNPER9pEp/rathhjW7HJbXYT34LmOgQ YaYcMrVguqdxvQapgUrA6rYsjGAgmzgTQXur1T8GHA6p1dcs5osRjyUai8WSfggTDHQH 8sJg== X-Gm-Message-State: ABuFfogQeqkw31K65LOyhAdLBuHnoj5cmEQYXQWQEeRUpQ+YQAmrwtMC kMQHkZFX/pLEDLqNAdXxGEzUT6zGVdsKnxtfVNhwyw== X-Google-Smtp-Source: ACcGV62XVPfKX0akbfm7gD64Lq4CdccOxIlAPMRM6+/ZS76c+fD697GazRX9wHBMT8TRsoE1KSCcJ0LONkJdRuzscqk= X-Received: by 2002:adf:f88d:: with SMTP id u13-v6mr41210162wrp.311.1540162837363; Sun, 21 Oct 2018 16:00:37 -0700 (PDT) MIME-Version: 1.0 References: <2B5BDE55-EE9E-4CAD-A2BF-8435C46103AE@island-resort.com> <07152864-D276-451E-B001-DE429705B76B@island-resort.com> In-Reply-To: From: Sean Solberg Date: Sun, 21 Oct 2018 18:00:26 -0500 Message-ID: To: Laurence Lundblade Cc: cbor@ietf.org Content-Type: multipart/alternative; boundary="000000000000d142a20578c51a31" Archived-At: Subject: Re: [Cbor] New pull request proposal for shortest float encoding 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, 21 Oct 2018 23:00:42 -0000 --000000000000d142a20578c51a31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IMHO, I believe it's much more important to preserve explicit data types than it is to try and squeak out every byte possible from the payload. It's already compact enough as it is without having to employ trickery to make the payload as small as possible for a very small set set of rare values. Keep It Simple: serialize a single as a single and serialize a double as a double and leave it at that. No extra processing needed, no extra tags needed, no ambiguity between the sender and receiver. Explicit. Done. Reliable. Just my opinion here... Sean Solberg On Sun, Oct 21, 2018 at 12:10 AM Laurence Lundblade wrote: > So here=E2=80=99s Carsten=E2=80=99s latest text of float encoding from Gi= tHub. > > The preferred encoding for a floating point value is the shortest floatin= g > point encoding that preserves its value, e.g., 0xf94580 for the number 5.= 5, > and 0xfa45ad9c00 for the number 5555.5, unless the CBOR-based protocol > specifically excludes the use of the shorter floating point encodings. Fo= r > NaN values, a shorter encoding is preferred if zero-padding the significa= nd > at the right reconstitutes the original NaN value (for many applications, > the single NaN encoding 0xf97e00 will suffice). > > > After thinking about it some, I think this creates a decoding problem. > > If a decoder library receives a half-precision or single-precision float, > the decoder does not know if it should promote that to a double or not wh= en > handing it up to the app using it. If the sender is using preferred > encoding as described above, then the answer is yes. If not then it shoul= d > not. The decoder however has no way of knowing whether the encoder is > using half-precision as part of preferred serialization or because the > sender really wanted it to be half-precision. > > I was OK with some ambiguity for a special option for shortest float that > I proposed here , but I do > not think it is good for the front-and-center preferred encoding for floa= ts. > > One solution is the original pull request. A tag could be added to make > it clear. The tag could be on an enclosing map/array. It doesn=E2=80=99t = need to be > on every float. > > Another similar is to have a tag indicating the sender is using preferred > serialization. > > Another is to make preferred serialization the base and have a tag that > indicates otherwise. > > LL > > > > > > On Aug 28, 2018, at 2:28 AM, Laurence Lundblade > wrote: > > Sean, really glad you brought all this up and wrote it down. I was > thinking some of it myself and it needs to be addressed. > > Seems like we have a few options for indicating precision for shortest > float encoding > - Each CBOR protocol specification explicitly states that shortest float > encoding is used for particular values. There is nothing explicit in the > protocol messages > - We use a tag like Thiago suggested > - Both of the above are allowed > > Since the tag takes up space, maybe the tag could be applied to maps and > arrays to indicate all float data items in them are of a particular type. > This would complicate the decoder as it has to keep track of some context > at each nesting level. > > > I don=E2=80=99t think the preference for shortest form that we apply to i= ntegers > should apply to floats. Floats are fundamentally different from integers. > Floats are only approximations of the actual value. Precision tells you h= ow > good the approximation is which matters in some use cases. If you encode= 3 > as 0x00000003 instead of 0x03 you don=E2=80=99t really get any more infor= mation, > but there is a difference between 3.000 and 3.000000. That is why I propo= se > that float and double are not subject to any shortest-form rule in the pr= eferred > serialization pull request . > > > I thought about leaving shortest float encoding entirely out of the RFC > for most simplicity. If we leave it out, any CBOR protocol could still > define it and use it. > > However, shortest float encoding does seems truly useful in reducing > message sizes a lot for a lot of use cases. It also isn=E2=80=99t easy to= figure > out (at least it took me a while=E2=80=A6), so I=E2=80=99m inclined to pu= t it in. Note > that I believe the only purpose of shortest float encoding is to reduce > message size. I see no value in it for canonicalization or for interop. = In > fact it is extra complexity so it will hurt interop. > > LL > > > > > On Aug 26, 2018, at 8:34 PM, Sean Solberg wrote: > > Follow up question: the proposal states: Generally the decoder should > promote half- and single-precision values to double-precision when they > are received as it is implied that all half- and single-precision values > transmitted are actually double precision. Why is it implied that a > transmitted single precision value is actually a double precision value? > That makes no sense. A single precision value is implied to be a single > precision value in my mind. If there was a "please treat as a double" > flag sent along with a single precision value, then the transmitted data > explicitly defines that the transmitted single precision value should be > treated as a double precision value by the receiver. without the flag, t= he > single precision value transmitted should be treated by the receiver as a > single precision value. Explicit behavior is great. Implicitly expectin= g > a receiver to treat all floats (half, single & double) as doubles when > received is implicitly a wrong choice. > > In general, any time things are done "implicitly", we end up with > compatibility problems because people make different implicit > choices/assumptions. I believe keeping things explicit is a much better > way to go. > ..Sean > > On Sun, Aug 26, 2018 at 10:25 PM, Sean Solberg wrote= : > >> Question on this: Even though the actual value transmitted has not lost >> any precision for that particular value, how does the receiver then know >> that the intended data type actually does have higher precision than wha= t >> was transmitted? Are there some flags somewhere that notify the receive= r >> that it's actually a double instead of a single or its actually a single >> instead of a half? >> >> ..Sean >> >> On Sat, Aug 25, 2018 at 3:38 PM, Laurence Lundblade < >> lgl@island-resort.com> wrote: >> >>> https://github.com/cbor-wg/CBORbis/pull/32 >>> >>> This is a proposal to reduce CBOR message size without losing floating >>> point precision by encoding the larger floating point values as smaller >>> ones when it can be done without dropping any significant bits. >>> I personally don't think this should be part of canonicalization, or >>> part of preferred encoding. It's just a very useful way of encoding >>> floating points that seems worth including in the RFC. >>> >>> LL >>> >>> >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>> >>> >> > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > > > --000000000000d142a20578c51a31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IMHO,

I believe it's much more impo= rtant to preserve explicit data types than it is to try and squeak out ever= y byte possible from the payload.=C2=A0 It's already compact enough as = it is without having to employ trickery to make the payload as small as pos= sible for a very small set set of rare values.=C2=A0 Keep It Simple:=C2=A0 = serialize a single as a single and serialize a double as a double and leave= it at that.=C2=A0 No extra processing needed, no extra tags needed, no amb= iguity between the sender and receiver.=C2=A0 Explicit.=C2=A0 Done.=C2=A0 R= eliable.=C2=A0

Just my opinion here...=C2=A0 Sean = Solberg

On Sun, = Oct 21, 2018 at 12:10 AM Laurence Lundblade <lgl@island-resort.com> wrote:
So here=E2=80=99s Carsten=E2=80=99s latest text of float encodin= g from GitHub.

The preferred encoding for a f= loating point value is the shortest floating point encoding that preserves = its value, e.g., 0xf94580 for the number 5.5, and 0xfa45ad9c00 for the numb= er 5555.5, unless the CBOR-based protocol specifically excludes the use of = the shorter floating point encodings. For NaN values, a shorter encoding is= preferred if zero-padding the significand at the right reconstitutes the o= riginal NaN value (for many applications, the single NaN encoding 0xf97e00 = will suffice).

After th= inking about it some, I think this creates a decoding problem.=C2=A0
<= div>
If a decoder library receives a half-precision or single= -precision float, the decoder does not know if it should promote that to a = double or not when handing it up to the app using it. If the sender is usin= g preferred encoding as described above, then the answer is yes. If not the= n it should not.=C2=A0 The decoder however has no way of knowing whether th= e encoder is using half-precision as part of preferred serialization or bec= ause the sender really wanted it to be half-precision.

=
I was OK with some ambiguity for a special option for shortest float t= hat I proposed=C2=A0here, but I do not think it is good for the front-and= -center preferred encoding for floats.

One solutio= n is the original pull request.=C2=A0 A tag could be added to make it clear= . The tag could be on an enclosing map/array. It doesn=E2=80=99t need to be= on every float.

Another similar is to have a tag = indicating the sender is using preferred serialization.

Another is to make preferred serialization the base and have a tag th= at indicates otherwise.=C2=A0

LL





On Aug 28, 2018, at 2:28 AM, Laurence Lundblade <lgl@island-resort.com> wrote:<= /div>
Sean, really g= lad you brought all this up and wrote it down. I was thinking some of it my= self and it needs to be addressed.

Seems like we have a = few options for indicating precision for shortest float encoding
= - Each CBOR protocol specification explicitly states that shortest float en= coding is used for particular values. There is nothing explicit in the prot= ocol messages
- We use a tag like Thiago suggested
- Bo= th of the above are allowed

Since the tag takes up= space, maybe the tag could be applied to maps and arrays to indicate all f= loat data items in them are of a particular type. This would complicate the= decoder as it has to keep track of some context at each nesting level.


I don=E2=80=99t think the preference f= or shortest form that we apply to integers should apply to floats. Floats a= re fundamentally different from integers.=C2=A0 Floats are only approximati= ons of the actual value. Precision tells you how good the approximation is = which matters in some use cases.=C2=A0 If you encode 3 as 0x00000003 instea= d of 0x03 you don=E2=80=99t really get any more information, but there is a= difference between 3.000 and 3.000000. That is why I propose that float an= d double are not subject to any shortest-form rule in the=C2=A0preferred seri= alization pull request.


I thought= about leaving shortest float encoding entirely out of the RFC for most sim= plicity. If we leave it out, any CBOR protocol could still define it and us= e it.=C2=A0

However, shortest float encoding does = seems truly useful in reducing message sizes a lot for a lot of use cases. = It also isn=E2=80=99t easy to figure out (at least it took me a while=E2=80= =A6), so I=E2=80=99m inclined to put it in.=C2=A0 Note that I believe the o= nly purpose of shortest float encoding is to reduce message size. I see no = value in it for canonicalization or for interop.=C2=A0 In fact it is extra = complexity so it will hurt interop.

LL
<= br>



On Aug 2= 6, 2018, at 8:34 PM, Sean Solberg <ssolbs99@gmail.com> wrote:

Follow up= question:=C2=A0 the proposal states:=C2=A0=C2=A0 Generally = the decoder should promote half- and single-precision values to double-= precision when they are received as it is implied that all half- and single-precision values transmitted are actually double pre= cision. Why is it implied that a = transmitted single precision value is actually a double precision value?=C2= =A0 =C2=A0That makes no sense.=C2=A0 A single precision value is implied to= be a single precision value in my mind.=C2=A0=C2=A0=C2=A0If there w= as a "please treat as a double" flag sent along with a single pre= cision value, then the transmitted data explicitly defines that the transmi= tted single precision value should be treated as a double precision value b= y the receiver.=C2=A0 without the flag, the single precision value transmit= ted should be treated by the receiver as a single precision value.=C2=A0 Ex= plicit behavior is great.=C2=A0 Implicitly expecting a receiver to treat al= l floats (half, single & double) as doubles when received is implicitly= a wrong choice.=C2=A0 =C2=A0=C2=A0

In gener= al, any time things are done "implicitly", we end up with compati= bility problems because people make different implicit choices/assumptions.= =C2=A0 I believe keeping things explicit is a much better way to go.=C2=A0= =C2=A0
..Sean

On Sun, Aug 26, 2018 at 10:25 PM, Sean Solberg <= ssolbs99@gmail.com> wrote:
Question on this:=C2=A0 Even though the actual value tr= ansmitted has not lost any precision for that particular value, how does th= e receiver then know that the intended data type actually does have higher = precision than what was transmitted?=C2=A0 Are there some flags somewhere t= hat notify the receiver that it's actually a double instead of a single= or its actually a single instead of a half?

..Sean

On Sat, Aug 25, 2018 at 3:38 PM, Laurence= Lundblade <lgl@island-resort.com> wrote:
https://g= ithub.com/cbor-wg/CBORbis/pull/32

This is a = proposal to reduce CBOR message size without losing floating point precisio= n by encoding the larger floating point values as smaller ones when it can = be done without dropping any significant bits.

I personally don= 't think this should be part of canonicalization, or part of preferred = encoding. It's just a very useful way of encoding floating points that = seems worth including in the RFC.

LL


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



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

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

--000000000000d142a20578c51a31-- From nobody Sun Oct 21 23:26:55 2018 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 B0CD1130E06 for ; Sun, 21 Oct 2018 23:26:53 -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 7KvtXKljKlVG for ; Sun, 21 Oct 2018 23:26:51 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9DA130E05 for ; Sun, 21 Oct 2018 23:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9M6QfCV015824; Mon, 22 Oct 2018 08:26:46 +0200 (CEST) Received: from [192.168.217.102] (p54A6CA9F.dip0.t-ipconnect.de [84.166.202.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42dmkn1hz2z1Bqf; Mon, 22 Oct 2018 08:26:41 +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: Mon, 22 Oct 2018 08:26:40 +0200 Cc: Laurence Lundblade , cbor@ietf.org X-Mao-Original-Outgoing-Id: 561882398.989009-7aac05f34f383d462411a209b8a147c5 Content-Transfer-Encoding: quoted-printable Message-Id: <3986E9F4-1DFA-4D7F-A878-52FE18A73265@tzi.org> References: <2B5BDE55-EE9E-4CAD-A2BF-8435C46103AE@island-resort.com> <07152864-D276-451E-B001-DE429705B76B@island-resort.com> To: Sean Solberg X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] New pull request proposal for shortest float encoding X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 06:26:54 -0000 The operative question here is whether the three IEEE 754 floating point = representations represent different types at the generic data model = level or not. So far, we have had the position that they don=E2=80=99t. = You seem to be suggesting that they do. Please also note that the introduction says: 4. The serialization must be reasonably compact, but data compactness is secondary to code compactness for the encoder and decoder. * "Reasonable" here is bounded by JSON as an upper bound in size, and by implementation complexity maintaining a lower bound. Using either general compression schemes or extensive bit-fiddling violates the complexity goals. 5.5 in JSON is three bytes; 0xf94580 is, too. 0xfb4016000000000000 = isn=E2=80=99t, but that would be the equivalent in CBOR to what 5.5 is = in I-JSON if binary64 were a different type than binary16. More = generally, most power-affluent implementations will naturally take an = incoming 0xf94580 from a sensor into further processing as binary64 (or = possibly binary32), so any distinction at the data model level would put = an additional burden on the processing. If precision does need to be indicated for a value, this should be done = via a tag. And that shouldn=E2=80=99t just allow for the resolution = afforded by 11-bit, 24-bit, or 53-bit mantissae. (We don=E2=80=99t have = to specify this tag in CBORbis =E2=80=94 actually, we shouldn=E2=80=99t, = as this would be a new invention.) Gr=C3=BC=C3=9Fe, Carsten > On Oct 22, 2018, at 01:00, Sean Solberg wrote: >=20 > IMHO, >=20 > I believe it's much more important to preserve explicit data types = than it is to try and squeak out every byte possible from the payload. = It's already compact enough as it is without having to employ trickery = to make the payload as small as possible for a very small set set of = rare values. Keep It Simple: serialize a single as a single and = serialize a double as a double and leave it at that. No extra = processing needed, no extra tags needed, no ambiguity between the sender = and receiver. Explicit. Done. Reliable.=20 >=20 > Just my opinion here... Sean Solberg >=20 > On Sun, Oct 21, 2018 at 12:10 AM Laurence Lundblade = wrote: > So here=E2=80=99s Carsten=E2=80=99s latest text of float encoding from = GitHub. >=20 > The preferred encoding for a floating point value is the shortest = floating point encoding that preserves its value, e.g., 0xf94580 for the = number 5.5, and 0xfa45ad9c00 for the number 5555.5, unless the = CBOR-based protocol specifically excludes the use of the shorter = floating point encodings. For NaN values, a shorter encoding is = preferred if zero-padding the significand at the right reconstitutes the = original NaN value (for many applications, the single NaN encoding = 0xf97e00 will suffice). >=20 > After thinking about it some, I think this creates a decoding problem.=20= >=20 > If a decoder library receives a half-precision or single-precision = float, the decoder does not know if it should promote that to a double = or not when handing it up to the app using it. If the sender is using = preferred encoding as described above, then the answer is yes. If not = then it should not. The decoder however has no way of knowing whether = the encoder is using half-precision as part of preferred serialization = or because the sender really wanted it to be half-precision. >=20 > I was OK with some ambiguity for a special option for shortest float = that I proposed here, but I do not think it is good for the = front-and-center preferred encoding for floats. >=20 > One solution is the original pull request. A tag could be added to = make it clear.. The tag could be on an enclosing map/array. It doesn=E2=80= =99t need to be on every float. >=20 > Another similar is to have a tag indicating the sender is using = preferred serialization. >=20 > Another is to make preferred serialization the base and have a tag = that indicates otherwise.=20 >=20 > LL >=20 >=20 >=20 >=20 >=20 >> On Aug 28, 2018, at 2:28 AM, Laurence Lundblade = wrote: >>=20 >> Sean, really glad you brought all this up and wrote it down. I was = thinking some of it myself and it needs to be addressed. >>=20 >> Seems like we have a few options for indicating precision for = shortest float encoding >> - Each CBOR protocol specification explicitly states that shortest = float encoding is used for particular values. There is nothing explicit = in the protocol messages >> - We use a tag like Thiago suggested >> - Both of the above are allowed >>=20 >> Since the tag takes up space, maybe the tag could be applied to maps = and arrays to indicate all float data items in them are of a particular = type. This would complicate the decoder as it has to keep track of some = context at each nesting level. >>=20 >>=20 >> I don=E2=80=99t think the preference for shortest form that we apply = to integers should apply to floats. Floats are fundamentally different = from integers. Floats are only approximations of the actual value. = Precision tells you how good the approximation is which matters in some = use cases. If you encode 3 as 0x00000003 instead of 0x03 you don=E2=80=99= t really get any more information, but there is a difference between = 3.000 and 3.000000. That is why I propose that float and double are not = subject to any shortest-form rule in the preferred serialization pull = request. >>=20 >>=20 >> I thought about leaving shortest float encoding entirely out of the = RFC for most simplicity. If we leave it out, any CBOR protocol could = still define it and use it.=20 >>=20 >> However, shortest float encoding does seems truly useful in reducing = message sizes a lot for a lot of use cases. It also isn=E2=80=99t easy = to figure out (at least it took me a while=E2=80=A6), so I=E2=80=99m = inclined to put it in. Note that I believe the only purpose of shortest = float encoding is to reduce message size. I see no value in it for = canonicalization or for interop. In fact it is extra complexity so it = will hurt interop. >>=20 >> LL >>=20 >>=20 >>=20 >>=20 >>> On Aug 26, 2018, at 8:34 PM, Sean Solberg = wrote: >>>=20 >>> Follow up question: the proposal states: Generally the decoder = should promote half- and single-precision values to double-precision = when they are received as it is implied that all half- and = single-precision values transmitted are actually double precision.=20 >>>=20 >>>=20 >>>=20 >>> Why is it implied that a transmitted single precision value is = actually a double precision value? That makes no sense. A single = precision value is implied to be a single precision value in my mind. = If there was a "please treat as a double" flag sent along with a single = precision value, then the transmitted data explicitly defines that the = transmitted single precision value should be treated as a double = precision value by the receiver. without the flag, the single precision = value transmitted should be treated by the receiver as a single = precision value. Explicit behavior is great. Implicitly expecting a = receiver to treat all floats (half, single & double) as doubles when = received is implicitly a wrong choice. =20 >>>=20 >>> In general, any time things are done "implicitly", we end up with = compatibility problems because people make different implicit = choices/assumptions. I believe keeping things explicit is a much better = way to go. =20 >>> ..Sean >>>=20 >>> On Sun, Aug 26, 2018 at 10:25 PM, Sean Solberg = wrote: >>> Question on this: Even though the actual value transmitted has not = lost any precision for that particular value, how does the receiver then = know that the intended data type actually does have higher precision = than what was transmitted? Are there some flags somewhere that notify = the receiver that it's actually a double instead of a single or its = actually a single instead of a half? >>>=20 >>> ..Sean >>>=20 >>> On Sat, Aug 25, 2018 at 3:38 PM, Laurence Lundblade = wrote: >>> https://github.com/cbor-wg/CBORbis/pull/32 >>>=20 >>> This is a proposal to reduce CBOR message size without losing = floating point precision by encoding the larger floating point values as = smaller ones when it can be done without dropping any significant bits. >>>=20 >>> I personally don't think this should be part of canonicalization, or = part of preferred encoding. It's just a very useful way of encoding = floating points that seems worth including in the RFC. >>>=20 >>> LL >>>=20 >>>=20 >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>=20 >> _______________________________________________ >> 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 Sun Oct 21 23:41:35 2018 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 126D6120072 for ; Sun, 21 Oct 2018 23:41:33 -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] 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 dW0FWIsSEHvq for ; Sun, 21 Oct 2018 23:41:30 -0700 (PDT) Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) (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 51955130DDB for ; Sun, 21 Oct 2018 23:41:30 -0700 (PDT) Received: from [192.168.0.101] ([121.46.87.45]) by :SMTPAUTH: with ESMTPSA id ETu2gXFnUrYknETu3gFdP5; Sun, 21 Oct 2018 23:41:29 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Laurence Lundblade In-Reply-To: <3986E9F4-1DFA-4D7F-A878-52FE18A73265@tzi.org> Date: Mon, 22 Oct 2018 12:11:25 +0530 Cc: Sean Solberg , cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7AD0711C-0819-44F7-8DFD-A2A9FDA51E5D@island-resort.com> References: <2B5BDE55-EE9E-4CAD-A2BF-8435C46103AE@island-resort.com> <07152864-D276-451E-B001-DE429705B76B@island-resort.com> <3986E9F4-1DFA-4D7F-A878-52FE18A73265@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfAjkJg5BAZGXrHUB1EXQIE5ScPWDYXdU0jhtG0CX5kIY8Dj1FnO06XFXp61Vs5MN3vjJeaDAmocZ/xo/sGNhLD86U94wzj8N4mvfnkzqqjVcFyxCxPGn t4H7JPtAWcv1gUKsXsREASWGIFO8YVOh3/0xDynnG5ptYPdnNTke4nnIyEOdr7F044NqWqvYVMHeTUWBdsfYom+xJIerE5CLDBU= Archived-At: Subject: Re: [Cbor] New pull request proposal for shortest float encoding X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 06:41:33 -0000 Yes, I think we are suggesting they are different types. This is because conversation between them is not straightforward like it = is with integers. It is harder to implement, but more importantly the = semantics for interoperability of the current text is not (yet) clear = (to me).=20 For doubles and singles with equal distribution of values, the saving = will be small and inconsequential. But for some use cases, the saving = will be very large.=20 My proposal was to treat them as different types for preferred encoding, = but also provide an optional specification for doing shortest encoding = if a CBOR-based protocol decided it wanted that.=20 LL > On Oct 22, 2018, at 11:56 AM, Carsten Bormann wrote: >=20 > The operative question here is whether the three IEEE 754 floating = point representations represent different types at the generic data = model level or not. So far, we have had the position that they don=E2=80=99= t. You seem to be suggesting that they do. >=20 > Please also note that the introduction says: >=20 > 4. The serialization must be reasonably compact, but data > compactness is secondary to code compactness for the encoder and > decoder. >=20 > * "Reasonable" here is bounded by JSON as an upper bound in > size, and by implementation complexity maintaining a lower > bound. Using either general compression schemes or extensive > bit-fiddling violates the complexity goals. >=20 > 5.5 in JSON is three bytes; 0xf94580 is, too. 0xfb4016000000000000 = isn=E2=80=99t, but that would be the equivalent in CBOR to what 5.5 is = in I-JSON if binary64 were a different type than binary16. More = generally, most power-affluent implementations will naturally take an = incoming 0xf94580 from a sensor into further processing as binary64 (or = possibly binary32), so any distinction at the data model level would put = an additional burden on the processing. >=20 > If precision does need to be indicated for a value, this should be = done via a tag. And that shouldn=E2=80=99t just allow for the = resolution afforded by 11-bit, 24-bit, or 53-bit mantissae. (We don=E2=80= =99t have to specify this tag in CBORbis =E2=80=94 actually, we = shouldn=E2=80=99t, as this would be a new invention.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 >> On Oct 22, 2018, at 01:00, Sean Solberg wrote: >>=20 >> IMHO, >>=20 >> I believe it's much more important to preserve explicit data types = than it is to try and squeak out every byte possible from the payload. = It's already compact enough as it is without having to employ trickery = to make the payload as small as possible for a very small set set of = rare values. Keep It Simple: serialize a single as a single and = serialize a double as a double and leave it at that. No extra = processing needed, no extra tags needed, no ambiguity between the sender = and receiver. Explicit. Done. Reliable.=20 >>=20 >> Just my opinion here... Sean Solberg >>=20 >> On Sun, Oct 21, 2018 at 12:10 AM Laurence Lundblade = wrote: >> So here=E2=80=99s Carsten=E2=80=99s latest text of float encoding = from GitHub. >>=20 >> The preferred encoding for a floating point value is the shortest = floating point encoding that preserves its value, e.g., 0xf94580 for the = number 5.5, and 0xfa45ad9c00 for the number 5555.5, unless the = CBOR-based protocol specifically excludes the use of the shorter = floating point encodings. For NaN values, a shorter encoding is = preferred if zero-padding the significand at the right reconstitutes the = original NaN value (for many applications, the single NaN encoding = 0xf97e00 will suffice). >>=20 >> After thinking about it some, I think this creates a decoding = problem.=20 >>=20 >> If a decoder library receives a half-precision or single-precision = float, the decoder does not know if it should promote that to a double = or not when handing it up to the app using it. If the sender is using = preferred encoding as described above, then the answer is yes. If not = then it should not. The decoder however has no way of knowing whether = the encoder is using half-precision as part of preferred serialization = or because the sender really wanted it to be half-precision. >>=20 >> I was OK with some ambiguity for a special option for shortest float = that I proposed here, but I do not think it is good for the = front-and-center preferred encoding for floats. >>=20 >> One solution is the original pull request. A tag could be added to = make it clear.. The tag could be on an enclosing map/array. It doesn=E2=80= =99t need to be on every float. >>=20 >> Another similar is to have a tag indicating the sender is using = preferred serialization. >>=20 >> Another is to make preferred serialization the base and have a tag = that indicates otherwise.=20 >>=20 >> LL >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Aug 28, 2018, at 2:28 AM, Laurence Lundblade = wrote: >>>=20 >>> Sean, really glad you brought all this up and wrote it down. I was = thinking some of it myself and it needs to be addressed. >>>=20 >>> Seems like we have a few options for indicating precision for = shortest float encoding >>> - Each CBOR protocol specification explicitly states that shortest = float encoding is used for particular values. There is nothing explicit = in the protocol messages >>> - We use a tag like Thiago suggested >>> - Both of the above are allowed >>>=20 >>> Since the tag takes up space, maybe the tag could be applied to maps = and arrays to indicate all float data items in them are of a particular = type. This would complicate the decoder as it has to keep track of some = context at each nesting level. >>>=20 >>>=20 >>> I don=E2=80=99t think the preference for shortest form that we apply = to integers should apply to floats. Floats are fundamentally different = from integers. Floats are only approximations of the actual value. = Precision tells you how good the approximation is which matters in some = use cases. If you encode 3 as 0x00000003 instead of 0x03 you don=E2=80=99= t really get any more information, but there is a difference between = 3.000 and 3.000000. That is why I propose that float and double are not = subject to any shortest-form rule in the preferred serialization pull = request. >>>=20 >>>=20 >>> I thought about leaving shortest float encoding entirely out of the = RFC for most simplicity. If we leave it out, any CBOR protocol could = still define it and use it.=20 >>>=20 >>> However, shortest float encoding does seems truly useful in reducing = message sizes a lot for a lot of use cases. It also isn=E2=80=99t easy = to figure out (at least it took me a while=E2=80=A6), so I=E2=80=99m = inclined to put it in. Note that I believe the only purpose of shortest = float encoding is to reduce message size. I see no value in it for = canonicalization or for interop. In fact it is extra complexity so it = will hurt interop. >>>=20 >>> LL >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Aug 26, 2018, at 8:34 PM, Sean Solberg = wrote: >>>>=20 >>>> Follow up question: the proposal states: Generally the decoder = should promote half- and single-precision values to double-precision = when they are received as it is implied that all half- and = single-precision values transmitted are actually double precision.=20 >>>>=20 >>>>=20 >>>>=20 >>>> Why is it implied that a transmitted single precision value is = actually a double precision value? That makes no sense. A single = precision value is implied to be a single precision value in my mind. = If there was a "please treat as a double" flag sent along with a single = precision value, then the transmitted data explicitly defines that the = transmitted single precision value should be treated as a double = precision value by the receiver. without the flag, the single precision = value transmitted should be treated by the receiver as a single = precision value. Explicit behavior is great. Implicitly expecting a = receiver to treat all floats (half, single & double) as doubles when = received is implicitly a wrong choice. =20 >>>>=20 >>>> In general, any time things are done "implicitly", we end up with = compatibility problems because people make different implicit = choices/assumptions. I believe keeping things explicit is a much better = way to go. =20 >>>> ..Sean >>>>=20 >>>> On Sun, Aug 26, 2018 at 10:25 PM, Sean Solberg = wrote: >>>> Question on this: Even though the actual value transmitted has not = lost any precision for that particular value, how does the receiver then = know that the intended data type actually does have higher precision = than what was transmitted? Are there some flags somewhere that notify = the receiver that it's actually a double instead of a single or its = actually a single instead of a half? >>>>=20 >>>> ..Sean >>>>=20 >>>> On Sat, Aug 25, 2018 at 3:38 PM, Laurence Lundblade = wrote: >>>> https://github.com/cbor-wg/CBORbis/pull/32 >>>>=20 >>>> This is a proposal to reduce CBOR message size without losing = floating point precision by encoding the larger floating point values as = smaller ones when it can be done without dropping any significant bits. >>>>=20 >>>> I personally don't think this should be part of canonicalization, = or part of preferred encoding. It's just a very useful way of encoding = floating points that seems worth including in the RFC. >>>>=20 >>>> LL >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> CBOR mailing list >>>> CBOR@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cbor >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> CBOR mailing list >>>> CBOR@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cbor >>>=20 >>> _______________________________________________ >>> 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 >=20 >=20 From nobody Mon Oct 22 11:19:29 2018 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 DB480130E98; Mon, 22 Oct 2018 11:19:17 -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.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <154023235782.7034.16478257801021539825@ietfa.amsl.com> Date: Mon, 22 Oct 2018 11:19:17 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-array-tags-00.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: Mon, 22 Oct 2018 18:19:23 -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 Authors : Johnathan Roatch Carsten Bormann Filename : draft-ietf-cbor-array-tags-00.txt Pages : 12 Date : 2018-10-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-00 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-array-tags-00 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 Mon Oct 22 11:24:19 2018 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 0E823128766 for ; Mon, 22 Oct 2018 11:24:19 -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 gdeoIutU-dQm for ; Mon, 22 Oct 2018 11:24:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D86E124BE5 for ; Mon, 22 Oct 2018 11:24:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E474E20008 for ; Mon, 22 Oct 2018 14:24:13 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 398B72363; Mon, 22 Oct 2018 14:24:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 37C03235A for ; Mon, 22 Oct 2018 14:24:16 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org In-Reply-To: References: <2B5BDE55-EE9E-4CAD-A2BF-8435C46103AE@island-resort.com> <07152864-D276-451E-B001-DE429705B76B@island-resort.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] New pull request proposal for shortest float encoding X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 18:24:19 -0000 --=-=-= Content-Type: text/plain Laurence Lundblade wrote: > After thinking about it some, I think this creates a decoding problem. > If a decoder library receives a half-precision or single-precision > float, the decoder does not know if it should promote that to a double > or not when handing it up to the app using it. If the sender is using > preferred encoding > as described above, then the answer is yes. If not then it should > not. The decoder however has no way of knowing whether the encoder is > using > half-precision as part of preferred serialization or because the sender > really wanted it to be half-precision. This seems like a protocol problem to me, not a decoder problem. If the protocol makes a meaningful difference between: 0.5 and 0.500 (i.e. between 5.0e-1 +- 0.1, and 5.0e-1 +- 0.001) {and there are a lots of situations where these are different} then the protocol should include error bars rather than trying cheet with encoding tricks. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlvOFc8ACgkQgItw+93Q 3WXhVQf/SM1Gi/m9Nl9YhRLXG6wAmOnvXC1qdrZx6BYThaYfnWfcBkPa/PGXHqcF Huj+Em3POEhKGm74Mijlf2Q8VlZaj5LJE/dzrZCsuxT5tO5b+7y3Zj6jCLNxvY44 Sub5xgB9DUiM1u3zPW5np1BM2RX6At2CTDx5378aGrdGnXlGF/KN0L2JVWV82ZX9 02fz0/oiqVqRCqszhuH1aozhuJZvJiIUMkv5AfW5dEJdscexG6GU6dxp3mDgg64w kIT36n9mr9oZxrTn/BPJAUqVS018UbssuZ9xHPpSERvD/1kX7n3sy19+HEWjGqPT hvbnH96YHLeyOZUweyZHXp32H9fJdA== =eTMA -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 22 11:26:55 2018 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 0B696130E13 for ; Mon, 22 Oct 2018 11:26:45 -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 ZYJFlaxlgALu for ; Mon, 22 Oct 2018 11:26:43 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28ED912D4EB for ; Mon, 22 Oct 2018 11:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9MIQZO4011719; Mon, 22 Oct 2018 20:26:40 +0200 (CEST) Received: from [192.168.217.114] (p54A6CA9F.dip0.t-ipconnect.de [84.166.202.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42f4jQ6Vhwz1Bqk; Mon, 22 Oct 2018 20:26:34 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_F44A3D4F-FC5D-41D6-AF34-E86BB22D256A"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <32765.1540232656@localhost> Date: Mon, 22 Oct 2018 20:26:34 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 561925592.479766-ac7252a02769471bbf717572133d1aab Message-Id: References: <2B5BDE55-EE9E-4CAD-A2BF-8435C46103AE@island-resort.com> <07152864-D276-451E-B001-DE429705B76B@island-resort.com> <32765.1540232656@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] New pull request proposal for shortest float encoding X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 18:26:54 -0000 --Apple-Mail=_F44A3D4F-FC5D-41D6-AF34-E86BB22D256A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 22, 2018, at 20:24, Michael Richardson = wrote: >=20 > then the protocol should include error bars rather than trying cheet = with > encoding tricks. +1e3(=C2=B1100) Gr=C3=BC=C3=9Fe, Carsten --Apple-Mail=_F44A3D4F-FC5D-41D6-AF34-E86BB22D256A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEcr05t4NZlx5Xee/8VkscnDT509sFAlvOFlgACgkQVkscnDT5 09venRAApMIRv7iXhcXRC5qoi0R7VNy1Q5IIQJUxvuCJpcXkDqf9tsMw5wB4z95j KSlnrR+0Pus4BRqfoQz7sqTnTwauxWEoMNvz5NKb1AYmvqdfNSzqKtMk1CiXlA3r 3oGX743cyf5aXoW9poSlqx21X6wY7kv9bGzZZzjDu85ZBvKHa/amwOs6u1c3mqdS OpjDpwl4fqyGUNla1i7ZmfdaDjxB8EFj8ZawLaWZDWQDJ6qrV4vYGT/GY0uoSW+Z Z6iCy+1uCXJG0i/9Y3NQDUL0In3TYsX5qtYCsSRD3q2IiTM+cIEoVrLBxY0s0nXm /67+5W+XrPPLbf91PDHPIhAlIfoglM3sOACA5UmHl2pKaPfrS6IJ3QKcIkfIGXm8 AVCewacvqRmcOEXva3z16lOIE+TWcsxWqoLeKr7bRz/Kjt27+RKkpmRpyt8dLy/i ctZfg1EUPOfA1S9JHjOt2Ufmrf15FACt3VMIZtzPj4MW82Qno/L5CXGBJphof48D hd8of2VfAHV8FL0w87tSOzJ42iKBqMz8oRiDbjnNbYQV4wz0ScfRFW5yY/Jok1dj ykI8U8IxEl3N9uBnB2e7UaVrMtUuNQHXOIsrkeTGJuOWQrdn91MPjWEqrRne5pNf O5x3isBGcbwuP521/znk4873r5dIOzNGjF5XkjcfK3K4IXxmjaI= =1UzN -----END PGP SIGNATURE----- --Apple-Mail=_F44A3D4F-FC5D-41D6-AF34-E86BB22D256A-- From nobody Mon Oct 22 12:25:16 2018 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 50F04130E6E for ; Mon, 22 Oct 2018 12:25:09 -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 GdwlbrJ7ZTVu for ; Mon, 22 Oct 2018 12:25:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2092130DC5 for ; Mon, 22 Oct 2018 12:25:03 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C4C4620008 for ; Mon, 22 Oct 2018 15:24:58 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1C0122363; Mon, 22 Oct 2018 15:25:01 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1A31D235A for ; Mon, 22 Oct 2018 15:25:01 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org In-Reply-To: References: <2B5BDE55-EE9E-4CAD-A2BF-8435C46103AE@island-resort.com> <07152864-D276-451E-B001-DE429705B76B@island-resort.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cbor] being explicit when shortcuts are allowed or not X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 19:25:15 -0000 --=-=-= Content-Type: text/plain We had some discussion last Wednesday about the question of how CBOR specification was neutral as to whether encoders or decoders would bear the burden being "correct". There are two situations which I think that Carsten has spoken of several times, but I'll recap: 1) a protocol in which it is known that no integer will be bigger than X (maybe X=1_000_000_000), and so larger encodings and decodings are not needed. This can have a code space affect on the encoder, as it must use shorter (or shortest) encodings. On the decoder, the guarantee means that it can depend upon never seeing the number 10 encoded using a 64-bit integer, and save code. (which is legal!) If such a thing occurs, then things break. 2) a protocol in which, despite knowing that there might be limits in practice, all representations are available. The encoder can then do things like just lay out CBOR into memory, assuming largest integer sizes possible, and then just fill in the actual numbers once they are known, even though there could be encoded using shorter encodings. While I am happy that CBOR remain neutral, I am suggesting that these two cases should get names, and that the CBOR document should explain these. This will let people annotate their CBOR libraries as to their capabilities, possibly making compile flags more meaningful across implementations. In particular a case for (1) is where it is known that floats are never used should probably be stated. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlvOJAwACgkQgItw+93Q 3WWvYQf/Zn2xSeYi7CYInN+O4ItkSmocKGamSwrbBxEhyDg3vYQaHx0M/QThcaVh r7ZaUCXbMBZ4yxw11rhzujgWTxXfmLMnTa+FTqe4d47Rzst7wYP+JbleHAbJLCsP hRqxhkXUTYvg7Bjb6CZnSsQ3hESFptl7hzE8iMpX+2SIEEUSnqNLEKLxwumJQvVq yNknaHBSGUIWJCUkyyjIwF/DN0KY+Cuchc7Pbgi3gmmVVS/xcomePm9CVBMFEXhY BBPR1ylg8I6mR5/uTk95xKLLT11j9Nwa+mmix9JchKRPbHDfmiKwCKqgV2fzsqxA KD8AS+mPTTfjmd+T9oRsa3+IaJuGuA== =d313 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 22 16:06:21 2018 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 3FFAB130F11; Mon, 22 Oct 2018 16:06:13 -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.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <154024957324.13552.7706243137179287729@ietfa.amsl.com> Date: Mon, 22 Oct 2018 16:06:13 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-7049bis-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: Mon, 22 Oct 2018 23:06:19 -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) Authors : Carsten Bormann Paul Hoffman Filename : draft-ietf-cbor-7049bis-04.txt Pages : 62 Date : 2018-10-22 Abstract: The Concise Binary Object Representation (CBOR) 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. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-7049bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-7049bis-04 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-7049bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-7049bis-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 Mon Oct 22 16:07:36 2018 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 DE362130F34 for ; Mon, 22 Oct 2018 16:07:28 -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 JSaNssbsf_cI for ; Mon, 22 Oct 2018 16:07:27 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC160130F36 for ; Mon, 22 Oct 2018 16:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9MN7IC8022470; Tue, 23 Oct 2018 01:07:23 +0200 (CEST) Received: from [192.168.217.114] (p54A6CA9F.dip0.t-ipconnect.de [84.166.202.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42fBxL1wn1z1Bqf; Tue, 23 Oct 2018 01:07:18 +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: <15687.1540236301@localhost> Date: Tue, 23 Oct 2018 01:07:17 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 561942435.540875-354e3816e9957615fefc0af23c881cd6 Content-Transfer-Encoding: quoted-printable Message-Id: <582CE785-FF69-41C6-A0AC-F412EF8A2931@tzi.org> References: <2B5BDE55-EE9E-4CAD-A2BF-8435C46103AE@island-resort.com> <07152864-D276-451E-B001-DE429705B76B@island-resort.com> <15687.1540236301@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] being explicit when shortcuts are allowed or not X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 23:07:35 -0000 Hi Michael, Great input. I tried to invent some words; please have a look at = https://github.com/cbor-wg/CBORbis/commit/54d7a5292a389405436fe97deeaae466= 630b9e68 Gr=C3=BC=C3=9Fe, Carsten > On Oct 22, 2018, at 21:25, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > We had some discussion last Wednesday about the question of how > CBOR specification was neutral as to whether encoders or decoders > would bear the burden being "correct". >=20 > There are two situations which I think that Carsten has spoken of > several times, but I'll recap: >=20 > 1) a protocol in which it is known that no integer will be bigger > than X (maybe X=3D1_000_000_000), and so larger encodings and > decodings are not needed. This can have a code space affect on the > encoder, as it must use shorter (or shortest) encodings. > On the decoder, the guarantee means that it can depend upon never > seeing the number 10 encoded using a 64-bit integer, and save code. > (which is legal!) > If such a thing occurs, then things break. >=20 > 2) a protocol in which, despite knowing that there might be limits in > practice, all representations are available. > The encoder can then do things like just lay out CBOR into memory, > assuming largest integer sizes possible, and then just fill in the > actual numbers once they are known, even though there could be > encoded using shorter encodings. >=20 > While I am happy that CBOR remain neutral, I am suggesting that these = two > cases should get names, and that the CBOR document should explain = these. > This will let people annotate their CBOR libraries as to their = capabilities, > possibly making compile flags more meaningful across implementations. >=20 > In particular a case for (1) is where it is known that floats are = never > used should probably be stated. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 From nobody Mon Oct 22 16:13:50 2018 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 1681712D4EA for ; Mon, 22 Oct 2018 16:13:49 -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 W5AJdTrec5QB for ; Mon, 22 Oct 2018 16:13:47 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725571292AD for ; Mon, 22 Oct 2018 16:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9MNDduf028275 for ; Tue, 23 Oct 2018 01:13:44 +0200 (CEST) Received: from [192.168.217.114] (p54A6CA9F.dip0.t-ipconnect.de [84.166.202.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42fC4g25qYz1Bqf; Tue, 23 Oct 2018 01:13: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: <154024957324.13552.7706243137179287729@ietfa.amsl.com> Date: Tue, 23 Oct 2018 01:13:38 +0200 X-Mao-Original-Outgoing-Id: 561942817.032486-f6714678108635044adcb6e7f544a15d Content-Transfer-Encoding: quoted-printable Message-Id: <37D95BBB-9B80-4210-AA69-78747938A482@tzi.org> References: <154024957324.13552.7706243137179287729@ietfa.amsl.com> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] New version of CBORbis -- Re: I-D Action: draft-ietf-cbor-7049bis-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: Mon, 22 Oct 2018 23:13:49 -0000 > Title : Concise Binary Object Representation (CBOR) > Authors : Carsten Bormann > Paul Hoffman > Filename : draft-ietf-cbor-7049bis-04.txt > Pages : 62 > Date : 2018-10-22 >=20 Htmlized: https://tools.ietf.org/html/draft-ietf-cbor-7049bis-04 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-7049bis-0 Most of the open issues are addressed; I hope that we can use the = remaining days until we all fly off to Bangkok to address the rest and = prepare -05. Please excuse some clumsiness in the wording; my esteemed co-author = hasn=E2=80=99t had sufficient time to fix my German-inspired prose. Editorial input (preferably directly to the authors) is as welcome as is = technical input. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Oct 22 16:47:31 2018 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 C2A85130E7B for ; Mon, 22 Oct 2018 16:47:19 -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 GPjWJ22328oh for ; Mon, 22 Oct 2018 16:47:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7EC130EEA for ; Mon, 22 Oct 2018 16:47:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0127E20008; Mon, 22 Oct 2018 19:47:13 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 512B72363; Mon, 22 Oct 2018 19:47:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4F533235A; Mon, 22 Oct 2018 19:47:15 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: cbor@ietf.org In-Reply-To: <582CE785-FF69-41C6-A0AC-F412EF8A2931@tzi.org> References: <2B5BDE55-EE9E-4CAD-A2BF-8435C46103AE@island-resort.com> <07152864-D276-451E-B001-DE429705B76B@island-resort.com> <15687.1540236301@localhost> <582CE785-FF69-41C6-A0AC-F412EF8A2931@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] being explicit when shortcuts are allowed or not X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 23:47:29 -0000 --=-=-= Content-Type: text/plain Thanks for that patch. So: - preferred encoder - variant encoder - variation-tolerant decoder are the new terms? I can't say that they are wrong, as they are perfectly reasonable descriptions of what you are defining. I'm not sure if I can use this when describing my (hypothetical) CBOR library code. -DINTEGER_VARIANT_ENCODER vs -DINTEGER_PREFERRED_ENCODER -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlvOYYIACgkQgItw+93Q 3WWvpAf+Ky38p0vSmOTbB9zwRlSnV0LVgaOPD3h8Shu/W/nujmt76OX57APw/rNG i6Uafl/ZoZHtf+0xa71K17zWZRzypIbPXx0xBwb0Rm3ZBEd+n/MNCTnJMTs7LMna 1C+AOFJYnBgYPquPy4izpkqm9CJxd/N4WlLn1Pg8HVr2DhxKR9aYRzRhCUCc3ynY /8XdBeQ3WKlWT1nOhf+6KsDPxilpN2D0sbG3gR9YunoNoVDlOB2j+0F2AUa+jErj rLJpOH9j4zRCMzAC5jpt7Qe1I2nelz+po/etDRhxvWcEplM0I7H7aiwbBTyGR4I+ upl5Tr+Rsd8aUO+LOCIxQCacZkrgUg== =WdOH -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 22 16:53:14 2018 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 102F9130DC5 for ; Mon, 22 Oct 2018 16:53: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 znk7L6KQKw5h for ; Mon, 22 Oct 2018 16:53:02 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A245130F28 for ; Mon, 22 Oct 2018 16:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9MNqsOK028704; Tue, 23 Oct 2018 01:52:59 +0200 (CEST) Received: from [192.168.217.102] (p54A6CA9F.dip0.t-ipconnect.de [84.166.202.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42fCxy1XCBz1Bqf; Tue, 23 Oct 2018 01:52:54 +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: <15375.1540252035@localhost> Date: Tue, 23 Oct 2018 01:52:53 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 561945171.238206-fad7daf36162442d4ada4abc618d6f4c Content-Transfer-Encoding: quoted-printable Message-Id: <2DE054B2-055E-447D-A31B-6FB790F1CF41@tzi.org> References: <2B5BDE55-EE9E-4CAD-A2BF-8435C46103AE@island-resort.com> <07152864-D276-451E-B001-DE429705B76B@island-resort.com> <15687.1540236301@localhost> <582CE785-FF69-41C6-A0AC-F412EF8A2931@tzi.org> <15375.1540252035@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] being explicit when shortcuts are allowed or not X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 23:53:13 -0000 On Oct 23, 2018, at 01:47, Michael Richardson = wrote: >=20 >=20 > Thanks for that patch. So: > - preferred encoder > - variant encoder > - variation-tolerant decoder >=20 > are the new terms? =20 Those are the ones I came up with. > I can't say that they are wrong, as they are perfectly > reasonable descriptions of what you are defining. >=20 > I'm not sure if I can use this when describing my (hypothetical) CBOR = library > code. >=20 > -DINTEGER_VARIANT_ENCODER That indeed makes little sense, because the code would need to know what = representation variants to leave out. -DINTEGER_VARIANT_ENCODER_32BIT_ONLY is closer. > vs > -DINTEGER_PREFERRED_ENCODER While this would make sense (except that it should be the default=E2=80=A6= ). Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Oct 23 06:18:55 2018 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 E0057130E00 for ; Tue, 23 Oct 2018 06:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFS4X-H8klq4 for ; Tue, 23 Oct 2018 06:18:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8DF130E11 for ; Tue, 23 Oct 2018 06:18:50 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2BDED20008; Tue, 23 Oct 2018 09:18:47 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 86359233E; Tue, 23 Oct 2018 09:18:49 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 859F2AE8; Tue, 23 Oct 2018 09:18:49 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: cbor@ietf.org In-Reply-To: <2DE054B2-055E-447D-A31B-6FB790F1CF41@tzi.org> References: <2B5BDE55-EE9E-4CAD-A2BF-8435C46103AE@island-resort.com> <07152864-D276-451E-B001-DE429705B76B@island-resort.com> <15687.1540236301@localhost> <582CE785-FF69-41C6-A0AC-F412EF8A2931@tzi.org> <15375.1540252035@localhost> <2DE054B2-055E-447D-A31B-6FB790F1CF41@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] being explicit when shortcuts are allowed or not 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, 23 Oct 2018 13:18:53 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >> I can't say that they are wrong, as they are perfectly >> reasonable descriptions of what you are defining. >> >> I'm not sure if I can use this when describing my (hypothetical) CBO= R library >> code. >> >> -DINTEGER_VARIANT_ENCODER > That indeed makes little sense, because the code would need to know > what representation variants to leave out. > -DINTEGER_VARIANT_ENCODER_32BIT_ONLY > is closer. Agreed. >> vs >> -DINTEGER_PREFERRED_ENCODER > While this would make sense (except that it should be the default=E2= =80=A6). Also agreed. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlvPH7kACgkQgItw+93Q 3WUW4wf/ZdMSLBZ/n9zJSAlb3Q0hPj6rKHtojmwwPnxgjL+AFjqaxTarn2gAprkR 20uMJPX8DdzK9nY5nLp4lDQqup9t/VcwNRwyuHHGm1TtwwFQFl0OKca5h6Wg1mSO TCWJ/lIGsHJdbIfQg8lYjAquRfM7tllgUbpJUD48ihSxItRF04FZJRDcqEOkKoLV rpoGh2a9+PDf8/sgV5A/lLFJNnyRiSif5jXMkWqohnzncWTk7JReKzSvCvwDURu5 5xnM/sIrPTVCZp+Oqi/uj6saIdb1ZPZOS9W5xVCArw2wDGjgsQ7TU/G1gnkAqlCj CKIKAt9ApQN26mxLtEa3I0P46CbAaA== =zk7t -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 23 09:51:50 2018 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 9B21E130E3D for ; Tue, 23 Oct 2018 09:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no 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 Z38NeUTVNMzn for ; Tue, 23 Oct 2018 09:51:46 -0700 (PDT) Received: from p3plsmtpa07-10.prod.phx3.secureserver.net (p3plsmtpa07-10.prod.phx3.secureserver.net [173.201.192.239]) (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 A08161277D2 for ; Tue, 23 Oct 2018 09:51:46 -0700 (PDT) Received: from [192.168.0.102] ([121.46.87.45]) by :SMTPAUTH: with ESMTPSA id Ezu9gspM5BPIGEzuBg999n; Tue, 23 Oct 2018 09:51:45 -0700 From: Laurence Lundblade Message-Id: <022E55F3-9AE0-4A29-AF80-CA4EA47D4E06@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8110A0BC-931A-4413-BA0E-FBAA4081F53C" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 23 Oct 2018 18:43:38 +0530 In-Reply-To: <32765.1540232656@localhost> Cc: cbor@ietf.org To: Michael Richardson References: <2B5BDE55-EE9E-4CAD-A2BF-8435C46103AE@island-resort.com> <07152864-D276-451E-B001-DE429705B76B@island-resort.com> <32765.1540232656@localhost> X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfHinUs3bh+j1mIzQZTFv5nKuzWarH3ESK18huOhMUfRpK0dSFV3JYf4snY6P0037PWav8xCzg2HKMKsLDFY6WvjtffFpbimUF6hYYfkt1oAlK9zrXJC4 sYmz7oWQYqFZqzyH4i34kIgFmeJZMEPzbPfyikS1TODgWx0m+gnC9SYsqpBJut8eZI+w7MQjMVwzlb3sST/xhKpXBShGSaNlbM8= Archived-At: Subject: Re: [Cbor] New pull request proposal for shortest float encoding 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, 23 Oct 2018 16:51:48 -0000 --Apple-Mail=_8110A0BC-931A-4413-BA0E-FBAA4081F53C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK. Agree with you on this now. Thanks for listening. (I realized my = encoding API for integers always takes an Int64 and decoding always = gives an Int64 even though it does preferred encoding of ints. If I=E2=80=99= m happy with that I have to be happy with the same with a double.) On to another thing=E2=80=A6. There=E2=80=99s new text on NaNs: For NaN values, a shorter encoding is preferred if zero-padding the = shorter significand towards the right reconstitutes the original NaN = value (for many applications, the single NaN encoding 0xf97e00 will = suffice). I read this is the same idea for NaN payloads. If you can make it small = without losing NaN payload bits, it is OK to do it. Seems like the right = thing to do. I did an experiment and on the x86 in my MacPro laptop. Every NaN is a = qNaN. The CVTSD2SS instruction ignores the NaN payload and even converts = an sNaN to a qNaN. The new text also won=E2=80=99t preserve the typical = sNaN which is just the LSB set.=20 Since NaN payloads are really obscure, I=E2=80=99m not sure how much = this really matters, but here=E2=80=99s a suggestion: For NaN values, a shorter encoding is preferred if zero-padding the = shorter significand towards the right reconstitutes the original NaN = value. An implementation may also choose not to support NaN payloads and = sNaN (signaling NaN), in which case NaN can always be encoded as = 0xf97e00. LL > On Oct 22, 2018, at 11:54 PM, Michael Richardson = wrote: >=20 >=20 > Laurence Lundblade wrote: >> After thinking about it some, I think this creates a decoding = problem. >=20 >> If a decoder library receives a half-precision or single-precision >> float, the decoder does not know if it should promote that to a = double >> or not when handing it up to the app using it. If the sender is using >> preferred encoding >> as described above, then the answer is yes. If not then it should >> not. The decoder however has no way of knowing whether the encoder is >> using >> half-precision as part of preferred serialization or because the = sender >> really wanted it to be half-precision. >=20 > This seems like a protocol problem to me, not a decoder problem. >=20 > If the protocol makes a meaningful difference between: > 0.5 > and 0.500 > (i.e. between 5.0e-1 +- 0.1, and 5.0e-1 +- 0.001) > {and there are a lots of situations where these are different} >=20 > then the protocol should include error bars rather than trying cheet = with > encoding tricks. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_8110A0BC-931A-4413-BA0E-FBAA4081F53C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OK. Agree with you on this = now. Thanks for listening.  (I realized my encoding API for = integers always takes an Int64 and decoding always gives an Int64 = even though it does preferred encoding of ints. If I=E2=80=99m happy = with that I have to be happy with the same with a double.)


On to another thing=E2=80=A6. = There=E2=80=99s new text on NaNs:
For NaN values, a shorter encoding = is preferred if zero-padding the shorter significand towards the = right reconstitutes the original NaN value (for many applications, = the single NaN encoding 0xf97e00 will = suffice).

I read this is the same idea = for NaN payloads. If you can make it small without losing NaN payload = bits, it is OK to do it. Seems like the right thing to do.

I did an experiment and on the x86 in my = MacPro laptop.  Every NaN is a qNaN. The CVTSD2SS instruction = ignores the NaN payload and even converts an sNaN to a qNaN. The = new text also won=E2=80=99t preserve the typical sNaN which is just the = LSB set. 

Since NaN payloads are = really obscure, I=E2=80=99m not sure how much this really matters, but = here=E2=80=99s a suggestion:
For NaN values, a shorter encoding is preferred if = zero-padding the shorter significand towards the = right reconstitutes the original NaN value. An implementation may = also choose not to support NaN payloads and sNaN (signaling NaN), in = which case NaN can always be encoded = as 0xf97e00.

LL



On Oct 22, 2018, at 11:54 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Laurence Lundblade <lgl@island-resort.com> wrote:
After thinking about it some, I think this = creates a decoding problem.

If a decoder library = receives a half-precision or single-precision
float, the = decoder does not know if it should promote that to a double
or not when handing it up to the app using it. If the sender = is using
preferred encoding
as described = above, then the answer is yes. If not then it should
not. = The decoder however has no way of knowing whether the encoder is
using
half-precision as part of preferred = serialization or because the sender
really wanted it to be = half-precision.

This seems = like a protocol problem to me, not a decoder problem.

If the protocol makes a meaningful difference between:
   0.5
and 0.500
(i.e. = between 5.0e-1 +- 0.1, and 5.0e-1 +- 0.001)
{and there are = a lots of situations where these are different}

then the protocol should include error bars rather than = trying cheet with
encoding tricks.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-=3D IPv6 IoT consulting =3D-



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

= --Apple-Mail=_8110A0BC-931A-4413-BA0E-FBAA4081F53C-- From nobody Tue Oct 23 12:12:12 2018 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 D5B01130F06 for ; Tue, 23 Oct 2018 12:12:10 -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 BNo8WNHBNoVK for ; Tue, 23 Oct 2018 12:12:09 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7A2130EEC for ; Tue, 23 Oct 2018 12:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9NJC0Kh027454; Tue, 23 Oct 2018 21:12:05 +0200 (CEST) Received: from [192.168.217.114] (p54A6CA9F.dip0.t-ipconnect.de [84.166.202.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42fjgM5ptCz1Bqk; Tue, 23 Oct 2018 21:11:59 +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: <022E55F3-9AE0-4A29-AF80-CA4EA47D4E06@island-resort.com> Date: Tue, 23 Oct 2018 21:11:59 +0200 Cc: Michael Richardson , cbor@ietf.org X-Mao-Original-Outgoing-Id: 562014717.541278-15c96a30547a5fdf11f68c729c57cc26 Content-Transfer-Encoding: quoted-printable Message-Id: <3BA0C933-CFCD-4C57-ADDA-CAD44487EB4E@tzi.org> References: <2B5BDE55-EE9E-4CAD-A2BF-8435C46103AE@island-resort.com> <07152864-D276-451E-B001-DE429705B76B@island-resort.com> <32765.1540232656@localhost> <022E55F3-9AE0-4A29-AF80-CA4EA47D4E06@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] New pull request proposal for shortest float encoding 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, 23 Oct 2018 19:12:11 -0000 On Oct 23, 2018, at 15:13, Laurence Lundblade = wrote: >=20 > For NaN values, a shorter encoding is preferred if zero-padding the = shorter significand towards the right reconstitutes the original NaN = value. An implementation may also choose not to support NaN payloads and = sNaN (signaling NaN), in which case NaN can always be encoded as = 0xf97e00. Thanks! When you say =E2=80=9Cimplementation=E2=80=9D, you mean the encoder, = right? I wonder what a decoder should do with an incoming sNaN or NaN payload. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Oct 23 20:19:25 2018 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 DC9D3130F14 for ; Tue, 23 Oct 2018 20:19:23 -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] 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 kuOGUaWcG6bB for ; Tue, 23 Oct 2018 20:19:21 -0700 (PDT) Received: from p3plsmtpa12-06.prod.phx3.secureserver.net (p3plsmtpa12-06.prod.phx3.secureserver.net [68.178.252.235]) (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 82064130DD8 for ; Tue, 23 Oct 2018 20:19:18 -0700 (PDT) Received: from [192.168.0.102] ([121.46.87.45]) by :SMTPAUTH: with ESMTPSA id F9hRgpyEu605TF9hTgO5S4; Tue, 23 Oct 2018 20:19:16 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Laurence Lundblade In-Reply-To: <3BA0C933-CFCD-4C57-ADDA-CAD44487EB4E@tzi.org> Date: Wed, 24 Oct 2018 08:49:13 +0530 Cc: Michael Richardson , cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B5BDE55-EE9E-4CAD-A2BF-8435C46103AE@island-resort.com> <07152864-D276-451E-B001-DE429705B76B@island-resort.com> <32765.1540232656@localhost> <022E55F3-9AE0-4A29-AF80-CA4EA47D4E06@island-resort.com> <3BA0C933-CFCD-4C57-ADDA-CAD44487EB4E@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfH7+oVfEhGqTonD7mYf3fVC6TfDjWPYIBdfDryvdt8aB1uVF5yQf8EX1XYVXYoXFcS27XD6KL8HQ25AsQNuoCKwpL5jNv4IjLmfRA/mmF/EJ0VurUpUv L+09WQBfooz/gI5oK4JrAD8LEMqSpV3fVqImGnfCYWCzoovrgOrj/zRB75jQSZL6VR4FiA0WCL2zjshKrvsfjPBQ5TajY121EBZdliFiT0wQiSWHF/czZ9Me Archived-At: Subject: Re: [Cbor] New pull request proposal for shortest float encoding 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, 24 Oct 2018 03:19:25 -0000 > On Oct 24, 2018, at 12:41 AM, Carsten Bormann wrote: >=20 > On Oct 23, 2018, at 15:13, Laurence Lundblade = wrote: >>=20 >> For NaN values, a shorter encoding is preferred if zero-padding the = shorter significand towards the right reconstitutes the original NaN = value. An implementation may also choose not to support NaN payloads and = sNaN (signaling NaN), in which case NaN can always be encoded as = 0xf97e00. >=20 > Thanks! >=20 > When you say =E2=80=9Cimplementation=E2=80=9D, you mean the encoder, = right? Yes > I wonder what a decoder should do with an incoming sNaN or NaN = payload. If the decoder just passes the float along in the size it received it, = then the payload will come along. If the decoder widens it to double = then it will depend on what the implementation of the widening does. On = x86, it will strip it.=20 So change =E2=80=9Cimplementation=E2=80=9D to =E2=80=9Cencoder / = decoder=E2=80=9D? LL >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Thu Oct 25 01:35:01 2018 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 A204A130DE0 for ; Thu, 25 Oct 2018 01:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.769 X-Spam-Level: X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=H6GutyiS; dkim=pass (1024-bit key) header.d=ericsson.com header.b=HB74wOI9 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 5Nuc0x5gji1P for ; Thu, 25 Oct 2018 01:34:57 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 00F3A12F1A2 for ; Thu, 25 Oct 2018 01:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540456494; x=1543048494; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PcBFMNINdV2XthVR3Oy48nJymajpJctb22AdVKOvJLs=; b=H6GutyiS/S+xYIwX/M1rs7DPze2dSalVVeIed8IrVLx51JR4W/ScMIjSoLQC9Yt5 +FkiUYuyznQTkhASUd68qyIqSfGQCtcNG11wru8DUAKwasqrMSLYWNKP5fEfbQkl 8F6MD3DMCemOIdpDa1FF4GQ/sC8HqbKG+9aKUxvWMwk=; X-AuditID: c1b4fb2d-887c49e00000434d-ba-5bd1802e742c Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EF.4F.17229.E2081DB5; Thu, 25 Oct 2018 10:34:54 +0200 (CEST) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 25 Oct 2018 10:33:57 +0200 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 25 Oct 2018 10:33:57 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PcBFMNINdV2XthVR3Oy48nJymajpJctb22AdVKOvJLs=; b=HB74wOI9IEyfVxkfDDT+QXsRZ+bqLteZxSjnbu2cxHCczbbQNbTDd7vQDqfIx2liHqDKDwEcYvGaYCKK1/yiemXNOC3ybANMOHPm+nGbwvjqm5EGugakkw7Fe/wDUH3TWlWJxaVYUA4XbYdO4N/Dpr09dzgaUtD1H8GOTyvpxTQ= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2858.eurprd07.prod.outlook.com (10.168.91.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.14; Thu, 25 Oct 2018 08:33:55 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5%6]) with mapi id 15.20.1273.019; Thu, 25 Oct 2018 08:33:55 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: Agenda IETF103 Thread-Index: AQHUbD138YDTdIFBtUSxWfQISXU2lA== Date: Thu, 25 Oct 2018 08:33:55 +0000 Message-ID: <9AFDC6C9-B4C3-41AA-B76D-C46ACB780977@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.31.165.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2858; 6:a9TabdCWrlS9ZH6vEPQt8yZ1SmzY+H0yMl6m/g3fK+rrPzi9atb7lwwDi3JMpHJY77X3hMyaQvLqmBmfLwm9ZaYGCiN11qox02LPHU7+DRgnJtdrEo6Vi2QWtEu7fqdsORqp6EmWm89X8A2szUuE5JaTDKRRaoCGqDpr8cg3tlIhL4maLsC4sGAySukG5iOUiCbd/jwoOb9nuWnHYyAP1ztLkI5wdgoD8ij0pitbnBzM5aDvjL6RxYXDSIMGqvmjlV/2a1ilUkzQe9V5Y4Ox1/mtk+JeDYYo0gUHKVfZvIjumh9i9gOJMITGcpT1R1LoubArVs6TPmD2kndGKX/XaxgY0wNnBVgWiLjxlqnrPw+OEf0b9dpb5sWHOSkR34OvZB6A7QXjNArFYkEFSuVroZ2Ut8jDzANglfxhnOEPe+DMRislFa8iZOAzPXOrxW3w7U8PtBrks09tg9uxmKpibw==; 5:HyZJjU8duHtkx1qoHW7J/HdgBNZ4W4ATz04nzAiUIv7F4LFjFdFMXXVaS5qRLk4lqrlo0ZLa1gxbL0MvYKoud99HbSSIIsep5yHIy0F79v8TerS1EAeOfWZm+LHrgWo7v7VxO7zIl+HfEKsEZMkE/vpMYKXdhueG0eNkIP8+2zU=; 7:o76K3s1//mSDgaPo2G/Tf4Ar8tmt2M1/cPl8TjggHEjTRh8VHHBWc9NymiTT5iwBzONPl2tnTPopFH+IDkgGN1R1jfVHY2tnn5vE+TyUvVUpqnWyy9lp4o8mPcq3jO+qLlWZBKRgCjeAUot0zdk8sg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: db299cae-4268-4e33-3f8f-08d63a549a2f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2858; x-ms-traffictypediagnostic: HE1PR0701MB2858: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(52105095)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1PR0701MB2858; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2858; x-forefront-prvs: 083691450C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(346002)(39860400002)(136003)(376002)(53754006)(189003)(199004)(66544003)(558084003)(2501003)(7736002)(71190400001)(71200400001)(83716004)(256004)(966005)(606006)(14454004)(5660300001)(2616005)(6506007)(8936002)(7116003)(6346003)(82746002)(1730700003)(6916009)(81166006)(81156014)(2900100001)(36756003)(26005)(8676002)(102836004)(186003)(450100002)(53936002)(33656002)(6116002)(6486002)(3846002)(86362001)(68736007)(476003)(5250100002)(105586002)(66066001)(97736004)(106356001)(478600001)(2906002)(5640700003)(25786009)(99286004)(486006)(2351001)(4326008)(6436002)(54896002)(6306002)(236005)(6512007)(316002)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2858; 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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-microsoft-antispam-message-info: XfZgFPaEuI/TsphVLpu2jo3IfXoAIVWqtyvsxka9egKqpKiPIoVL4A+aZ/Z/iRqALWqy4wAxya/FhdpoZJYUVjsLUSLthkVl1dlnvdFH1ueqknOmiC9a/0ASQwlEu7cCAJO8w+IxPyB2rpCjqUKlp5hcANpezULBRzUObCzM/OeBEam8/3AkWV5DaY76lTwnEVrqyu/UHyYkGE8k7i7kQcn8L8lWaoozfGAgM2yFz1oPMQmZnEsHGyo4CRCfNoFptvpN9oL4Wid1HEZh7raUkhQAgu0cqLcuENeyJ6KGmNjlk4VWAWxp400AE+nDCcU7oyaSJedEAdzhLwDdv5duoX0WV4AibtrMF/Gib80o+LA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_9AFDC6C9B4C341AAB76DC46ACB780977ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: db299cae-4268-4e33-3f8f-08d63a549a2f X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2018 08:33:55.5993 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2858 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURzGObt323U4OC7FPzaVJmaWzpf6YCWaWOEHBZFI0SiXu76Uurm7 RIVkQfnKykDRmaKS78osGWY1AyemommaoEhvY2KEZVJmyNTadhf47Xee5zn/c57DoQjRE64X lZOvplX5slwJT0DqUp6pgqWa+bTQmU5xxKM9A4rQVdST5zhx7e07nESUKoiU07k5hbQqJCpd kN3bvIWUZb5FNQvdhAZV+1QhFwrwKeh+84FbhQSUCI8j+Gj5w7cbIryNYOBbAGu0c6D87oQj ReIaAh7Wa/ms08AB62Anj12sIbA2/XLs5+FIeGv+wbWzO/aDutoxW4iiCBwGO8YCu3wIe8LC 0yHERsSgf/CFw7IU2n7/dYwhsT9U71kcY4Q4GsxdFtLOCHvD1p0+ws6Ebc7KaguH7YOh3ThH sOwBXy37XJYlsLDb5tS9YaGlGtnvDHiZB6PLn3isEQybdXXOUAL87N93hqYQdBmanScEwdjo pHOqAt6t7PJZvg3lhs+IZR/o1ZpJdvM0AXM9s05DDKaxBh5rDPNge2ORrEHSxgM1Gh2vlGGr cbTR0doNpnSrJCsHwsCLEDZ9BGqrzXyWj8G9pmYnx8HrpVl0MNOKqF7kwdAMk5cVflJKq3Iy GEaRL82n1YPI9o9GDdbgYdS3HmNCmEISV6FGPp8m4soKmeI8EwKKkLgLY6/aJKFcVlxCqxTX VLdyacaEDlOkxFMo7TWminCWTE3fpGklrfrvcigXLw1KiBnf9JFcCFcucVrneKEdAfrUs0EC /0z+6f5E/UimfiT28m6KW/Il48p1t/HOVxXTgXFHDSbxxa73zxfXwvfSryS9TN6Y99MFzVcu ZqWsx8t99Y97lJNlHfKSYbyzfb505obfULQrLphepc8oTkSrK4u0E6b7Udr42u+l2iSrhGSy ZWHHCRUj+wfGFXKUQwMAAA== Archived-At: Subject: [Cbor] Agenda IETF103 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, 25 Oct 2018 08:34:59 -0000 --_000_9AFDC6C9B4C341AAB76DC46ACB780977ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGp1c3QgdXBsb2FkZWQgYSBkcmFmdCBhZ2VuZGEgZm9yIElFVEYxMDM6IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDMvbWF0ZXJpYWxzL2FnZW5kYS0x MDMtY2Jvci0wMA0KDQpQbGVhc2UgbGV0IHRoZSBjaGFpcnMga25vdyBpZiB5b3XigJlkIGxpa2Ug dG8gYWRkIGFueXRoaW5nIHRvIHRoZSBhZ2VuZGEsIG9yIGlmIHlvdSBoYXZlIGFueSBvdGhlciBj b21tZW50cy4NCg0KU2VlIHlvdSBzb29uIGluIEJhbmdrb2ssDQpGcmFuY2VzY2ENCg== --_000_9AFDC6C9B4C341AAB76DC46ACB780977ericssoncom_ 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 bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+SSBqdXN0IHVwbG9hZGVkIGEgZHJhZnQgYWdlbmRhIGZvciBJRVRGMTAzOg0K PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlh bHMvYWdlbmRhLTEwMy1jYm9yLTAwIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRp bmcvMTAzL21hdGVyaWFscy9hZ2VuZGEtMTAzLWNib3ItMDA8L2E+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBsZWFzZSBsZXQgdGhlIGNoYWlycyBrbm93IGlm IHlvdeKAmWQgbGlrZSB0byBhZGQgYW55dGhpbmcgdG8gdGhlIGFnZW5kYSwgb3IgaWYgeW91IGhh dmUgYW55IG90aGVyIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+U2VlIHlvdSBzb29uIGluIEJhbmdrb2ssPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZyYW5j ZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9AFDC6C9B4C341AAB76DC46ACB780977ericssoncom_-- From nobody Tue Oct 30 08:16:43 2018 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 9F4BA130DF5 for ; Tue, 30 Oct 2018 08:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no 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 tjqYo8iIUJpb for ; Tue, 30 Oct 2018 08:16:28 -0700 (PDT) Received: from mail-it1-f177.google.com (mail-it1-f177.google.com [209.85.166.177]) (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 53175130DE6 for ; Tue, 30 Oct 2018 08:16:28 -0700 (PDT) Received: by mail-it1-f177.google.com with SMTP id k206-v6so14142890ite.0 for ; Tue, 30 Oct 2018 08:16:28 -0700 (PDT) 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=cQGCfEUZcGQCP98sWqcXgH2+gvTGACxWAvAFrQ539mM=; b=cK2HZRZqOda3LBDVCAqjztLpJr+gIa9YtMpuT35f1EpjycT6eJVy8K3F01qD+4GWQt nAXdO5NMZ+xMfD0p7S/NED+ViwSGEsEBZff3GJ46OVQadJSpjpEZ8GNO57n6yHsr9xwY 75V6mudqfZnnaH/SSLzX/oFD8YM8Xuhiy5QSyt3MqWnPLrPAWZhbNyavZn7n0ezoPO7P vpRXwmCnh1caejiNLUwvpTBA8KuOb4gS9MwAbbODbvcqm39U3h5MezsXWoDZVEr5VdGe rC4+Luvgrp/36RcfvAi6jMe8mxdztHQYvVKZ8oDmT3e++PxI0ZgtF5y2ygX4Hy8av1Bf yw7g== X-Gm-Message-State: AGRZ1gJgSncX2shcjUDMh+y5TP2+kjlMi58IovaybE5MpHM+gh0o3h01 Dr+E8H+uxB5D0ZzWStDwZSZkhKMz4UZ6KP5UivZvmw== X-Google-Smtp-Source: AJdET5dkjB247oo4rLFt2itiJebiTVqkr0GO3f7Du0QEeFNY+8urQEMuOIm66DuWFR+L9kGkpju+mF7RHgXrl7Q/x/U= X-Received: by 2002:a24:a49:: with SMTP id 70-v6mr1660112itw.122.1540912587002; Tue, 30 Oct 2018 08:16:27 -0700 (PDT) MIME-Version: 1.0 From: Barry Leiba Date: Tue, 30 Oct 2018 11:16:15 -0400 Message-ID: To: cbor@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cbor] No more WebEx calls scheduled; we meet next in Bangkok 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, 30 Oct 2018 15:16:42 -0000 A reminder, as decided on the last WebEx call and reported in the notes: because the Bangkok meeting is imminent and people are beginning their travel, there is no WebEx call this week. And, as this was the end of the scheduled calls, there are no more planned at this time. We'll discuss at the Bangkok meeting whether we would like to schedule some between Bangkok and Prague. Barry From nobody Tue Oct 30 09:31:08 2018 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 2BBAB130DC5 for ; Tue, 30 Oct 2018 09:31:06 -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] 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 jSuwv3sH1pLc for ; Tue, 30 Oct 2018 09:31:04 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 BA24F12D4EA for ; Tue, 30 Oct 2018 09:31:04 -0700 (PDT) Received: from [10.32.60.70] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w9UGUDoD010408 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 30 Oct 2018 09:30:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.70] From: "Paul Hoffman" To: cbor@ietf.org Date: Tue, 30 Oct 2018 09:31:01 -0700 X-Mailer: MailMate (1.12r5523) Message-ID: References: <154090500315.15318.18122686732433685149.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: [Cbor] Fwd: Last Call: (C-DNS: A DNS Packet Capture Format) to Proposed Standard 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, 30 Oct 2018 16:31:06 -0000 Of possible interest to folks here: IETF Last Call for a non-IoT protocol that uses CBOR. --Paul Hoffman Forwarded message: > From: The IESG > To: IETF-Announce > Cc: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, > draft-ietf-dnsop-dns-capture-format@ietf.org, dnsop@ietf.org, Tim > Wicinski , warren@kumari.net > Subject: Last Call: > (C-DNS: A DNS Packet Capture Format) to Proposed Standard > Date: Tue, 30 Oct 2018 06:10:03 -0700 > > The IESG has received a request from the Domain Name System Operations > WG > (dnsop) to consider the following document: - 'C-DNS: A DNS Packet > Capture > Format' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2018-11-13. Exceptionally, comments may > be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of > the Subject line to allow automated sorting. > > Abstract > > > This document describes a data representation for collections of > DNS > messages. The format is designed for efficient storage and > transmission of large packet captures of DNS traffic; it attempts > to > minimize the size of such packet capture files but retain the full > DNS message contents along with the most useful transport metadata. > It is intended to assist with the development of DNS traffic > monitoring applications. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ballot/ > > The following IPR Declarations may be related to this I-D: > > https://datatracker.ietf.org/ipr/2909/