From nobody Thu Jan 9 02:21:01 2020 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 8EC9E120113; Thu, 9 Jan 2020 02:20:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: cbor@ietf.org, cbor-chairs@ietf.org, francesca.palombini@ericsson.com, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157856525854.11845.10011651335413533060.idtracker@ietfa.amsl.com> Date: Thu, 09 Jan 2020 02:20:58 -0800 Archived-At: Subject: [Cbor] cbor - New Meeting Session Request for IETF 107 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: Thu, 09 Jan 2020 10:20:59 -0000 A new meeting session request has just been submitted by Francesca Palombini, a Chair of the cbor working group. --------------------------------------------------------- Working Group Name: Concise Binary Object Representation Maintenance and Extensions Area Name: Applications and Real-Time Area Session Requester: Francesca Palombini Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 40 Conflicts to Avoid: Chair Conflict: saag ace core lamps cose lake gendispatch secdispatch Technology Overlap: rats suit teep lwig 6tisch 6lo anima t2trg lpwan Key Participant Conflict: cfrg emu tls oauth artarea roll sacm dots dnsop wpack People who must be present: Carsten Bormann Alexey Melnikov Jim Schaad Francesca Palombini Resources Requested: Special Requests: Please avoid collision with any Sec and IoT-related BoFs. --------------------------------------------------------- From nobody Tue Jan 14 13:52:48 2020 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 6D938120113; Tue, 14 Jan 2020 13:52:46 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 hqR4A2cU0aIE; Tue, 14 Jan 2020 13:52:42 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84DFB120639; Tue, 14 Jan 2020 13:52:42 -0800 (PST) Received: from [192.168.217.119] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47y4204N0hzyVd; Tue, 14 Jan 2020 22:52:40 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: Date: Tue, 14 Jan 2020 22:52:40 +0100 Cc: Francesca Palombini , "cbor@ietf.org" , "draft-ietf-cbor-7049bis@ietf.org" , "cbor-chairs@ietf.org" X-Mao-Original-Outgoing-Id: 600731560.097301-b80188abe631f99c0e7c30ed24367e1f Content-Transfer-Encoding: quoted-printable Message-Id: References: <293AFF31-D0EF-45D6-9B9D-E8136481C404@ericsson.com> To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: [Cbor] =?utf-8?q?Bignums_and_the_generic_data_models_=28Re=3A__?= =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-7049bis-09=29?= 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, 14 Jan 2020 21:52:47 -0000 On 2019-11-24, at 12:23, Jeffrey Yasskin wrote: >=20 > 3.4.4. Bignums > [=E2=80=A6] > =E2=80=A2 "and preferred encoding never makes use of bignums = that also can be expressed as basic integers (see below)." <- This seems = inconsistent with "In the generic data model, bignum values are not = equal to integers from the basic data model". If they're not the same = value at the data model level, they can't be alternate encodings of each = other. Hi Jeffrey, of your many useful comments in that message, let me pick this one = because answering it is a prerequisite to getting the map validity text = right. Indeed, in the basic (unextended) generic data model, bignums are = different from (mt0/1) integers. The extended generic data model for tag 2/3 changes this. It has to. = Consider: 2(h'00112233445566778899') and 2(h'112233445566778899') These are different in the basic generic data model, but both mean = 316059037807746189465 in the extended generic data model, so that has to = be different from the basic one. =20 So given that we already had to extend the generic data model with the = values (types) specific to the tag semantics, we also can (and should!) = say that 2(h'12') means 18 in the extended generic data model, the preferred encoding of = which is 0x12 and not 0xc24112. For a generic codec, both options are available for a specific tag = number: - offer the basic generic data model. This leaves it to the application = to build the tag content in the way that fits to the tag definition and = to interpret it this way. It is then also up to the application to take = care of map validity (e.g., by not using both = 2(h'00112233445566778899=E2=80=99) and 2(h'112233445566778899=E2=80=99) = as keys in the same map), and to issue preferred serialization if = desired. =E2=80=94 process the tag, i.e., offer the extended generic data model. = Now the generic codec can do all that work; for the example at hand, at = the codec API you only see integers. This is the direction in which I think we need to go if we want to = enable tag processing in generic codecs. (The cognitive dissonance here is maybe with ECMAscript bigints, which = are a separate type from numbers. But sending a bignum is not on its = own a good way to distinguish a number as a ES bigint; probably a = language-specific tag is a better way to make that language-specific = distinction.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 15 06:32:34 2020 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 AB28E120025 for ; Wed, 15 Jan 2020 06:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86dQyWQQ40FS for ; Wed, 15 Jan 2020 06:31:52 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30061.outbound.protection.outlook.com [40.107.3.61]) (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 3269412003E for ; Wed, 15 Jan 2020 06:31:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aLkzp5J65ctWLzNnYWiUEljauxmZorGDbRBbUnYeY2IAe3t2Rc8vLFBmnqaIQHpSnJmhycRelauYo2HX1Yx9IkqvZqk4+42r8+hV1cLNkHlCiw8Zv0GOq5f4T0up5nAIHIBMFc1FH5MRqmZF8+acg7ciw+F6TJrDAbj4t/cwkycOCi0f6u5VaI8rRwnzODPYF1UcSw1gYO4/+5wn2kBeIkfevF8O2uVVV9ef9gCzoAaUY3L75/HgbBrx8vYWDfVXzQu/OObnq3FNaAqUInT+LCFTJGHRkXPhnz2OS9jlFLpoOWXCOSqebz88I/IR0EpOQRgqX5RD2VxzO2FmMdncgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pcy0jgubn6+4wiYkNJsMw85CBlhE1dn3QuMWi/lKJpY=; b=Ck87rw6BxGKQ4q5rJrlVUnvZI4THxksn06j8MV+fN1otXLJG9WnONxnawwdgnUMQODq+gaJvHBLsur3xoZGU35MqBRsFhOAg75ELnRQYmwVpF2yUu4xybnTQonL07/X8rSUtlHYW7VsR+Z4zDHciq2SpwPbU8YJRT/eZXbCKtN7HYTtPyySEiR0VCWpEELOKPdMh5MjAPZMmRGSdcSAJJyp1Yu3EBEIlbXK6vUwFh7AGZvw42oXKYLN/7VwbnZY47TUqfXKM6AwBTzvauCLM0E31u6pZeJUpWHiHBJfEYaWE0y7kIyA0OXbN/Hg8JG+0oOwwnlHKhxadTchPvsddZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ietf.org; dkim=pass header.d=ietf.org; arc=none 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=Pcy0jgubn6+4wiYkNJsMw85CBlhE1dn3QuMWi/lKJpY=; b=CjpkdXhouC85GebZw3UR8pkM+UivkJXTh7R7bfkbNoFUrLKS0n/F+5K0GH8SS02qxziXRa+NPw1qrRWSd0ITb9ev/fBmsmVLlpvtXtUWOALKkFB8h6pm1YYgQPUTCfaQRYA53Lz7lu/NzeqHJb1d89J+jIVb3WuekUBKzUK8TwU= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB5640.eurprd07.prod.outlook.com (20.178.91.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.6; Wed, 15 Jan 2020 14:31:50 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7%5]) with mapi id 15.20.2644.015; Wed, 15 Jan 2020 14:31:49 +0000 From: CBOR Working Group To: "cbor@ietf.org" Thread-Topic: CBOR Interim today 01-15-2020 Thread-Index: AQHVy7CE3Un4cpWmg0eME6yL7rTZxg== Sender: Francesca Palombini Date: Wed, 15 Jan 2020 14:31:49 +0000 Message-ID: References: <674399519.2357911574776641537.JavaMail.nobody@rva2rmd101.webex.com> In-Reply-To: <674399519.2357911574776641537.JavaMail.nobody@rva2rmd101.webex.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-publictraffictype: Email authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 2 x-ms-exchange-meetingforward-message: Forward x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAAAAAAAAAAAAAAAAAAAAAAAAAAAMQAAAHZDYWwtVWlkAQAAADQ4NzFjODk2LWRiMTMtNGFkNC04MmUzLWMzZDVlMzcxNzVmOQA= x-originating-ip: [192.176.1.84] x-ms-office365-filtering-correlation-id: b09bf5d9-b2e0-4f8a-bcc0-08d799c7a849 x-ms-traffictypediagnostic: AM6PR07MB5640:MeetingMessage x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(346002)(39860400002)(366004)(136003)(189003)(199004)(81166006)(52536014)(6636002)(76116006)(26005)(91956017)(42882007)(186003)(4744005)(5660300002)(33656002)(66476007)(66616009)(6506007)(66556008)(66446008)(66946007)(64756008)(7696005)(81156014)(19627405001)(71200400001)(478600001)(16799955002)(966005)(55016002)(9686003)(7846003)(316002)(6916009)(8676002)(2906002)(8936002)(574754004)(24704002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5640; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 2 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ilDkRzynW61Oho2i8KyUichdHvG+XuSp+LOtjqRQfOxr7oEumXx5vqKPwBvw2ncI4KFCAPptv1pW1/mtGa4SoY2BJc1Lzp7dfmvnsLcbxzNZ6y3cL9wxKHPcGzIrd2KRaSNnOSonhbm1eEmd/T8hINWXwYOJA+d+mTL+HRIsyOvOkCpS0l8rqi9dkLu3tufV6nCLhB7/6vr/GWesF2EznI17QqGAaV7suWx0wcNmqP76WxmZdvJWyg6EyOBLVbo6AAhRgI7fAPjJugSzxsJYOvEjYfvaZuQ3nOh6FZMEnFWdb83tDfSvMRuRL3ahVc00r/fOh6QAL8LxVHo2JDaCKIGWR1gJEmWvBjcWVFWNAbXYMhUn2IMcVmt2CQIQSS+yyLqEe4nE6rvZsKJrZ49pO69JmXIzpCqOEQynD5yfg1jXRpWTmfS0SvFc2v/f9rt0rrr7gERCl9LnUimrgMXW4b0FKYtQ9az73/LIdKV99wqeTcu06vGL30Ti4XxCZiFsAFCDqvH9+TWYMjt365HWUqPznvSvAhcnWlifLg6PAO7hg1e9MitoDCcY8hVi5G9q x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_005_AM6PR07MB405314BD1C4F21708FFC47CE98370AM6PR07MB4053eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b09bf5d9-b2e0-4f8a-bcc0-08d799c7a849 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 14:31:49.6781 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WfNZinN7xu7F/cORJx8SAvJ6y429aWZVoCNGE+aaQLnHN9aImzBx4ZAT0WcPviNcIEx0HIQ8i4VwesX8MOh23y/PYAJCdRvKchKY9NLIndHKcKTlxx1SqZOCG7vTqUr2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5640 Archived-At: Subject: [Cbor] CBOR Interim today 01-15-2020 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 14:31:57 -0000 --_005_AM6PR07MB405314BD1C4F21708FFC47CE98370AM6PR07MB4053eurp_ Content-Type: multipart/alternative; boundary="_000_AM6PR07MB405314BD1C4F21708FFC47CE98370AM6PR07MB4053eurp_" --_000_AM6PR07MB405314BD1C4F21708FFC47CE98370AM6PR07MB4053eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, A reminder that we have an interim today (in around 90 minutes), call detai= ls below. The agenda for today is to continue working on CBOR bis. Talk to you soon, Francesca From: CBOR Working Group Reply to: Date: Tuesday, 26 November 2019 at 14:57 To: Subject: Webex meeting invitation: CBOR virtual interim meeting Resent from: Resent to: Jim Schaad , Francesca Palombini Resent date: Tue, 26 Nov 2019 05:57:23 -0800 (PST) CBOR Working Group invites you to join this Webex meeting. Meeting number (access code): 646 424 349 Meeting password: 7PFpsPMt Wednesday, January 15, 2020 4:00 pm | (UTC+00:00) Monrovia, Reykjavik | 1 hr Join meeting Join by phone Tap to call in from a mobile device (attendees only) 1-650-479-3208 Call-in toll= number (US/Canada) Need help? Go to http://help.webex.com --_000_AM6PR07MB405314BD1C4F21708FFC47CE98370AM6PR07MB4053eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 =

A reminder that we have = an interim today (in around 90 minutes), call details below.

 =

The agenda for today is = to continue working on CBOR bis.

 =

Talk to you soon, <= o:p>

Francesca

&nbs= p;

&nbs= p;

From= : CBOR Working Grou= p <messenger@webex.com>
Reply to: <cbor-chairs@ietf.org>
Date: Tuesday, 26 November 2019 at 14:57
To: <cbor-chairs@ietf.org>
Subject: Webex meeting invitation: CBOR virtual interim meeting
Resent from: <alias-bounces@ietf.org>
Resent to: Jim Schaad <ietf@augustcellars.com>, Francesca Palo= mbini <francesca.palombini@ericsson.com>
Resent date: Tue, 26 Nov 2019 05:57:23 -0800 (PST)=

 

 

CBOR Working Group invites you to join this Webex meeting.

 

 

 

Meeting number (access code): 646 424 349

 

Meeting password: 7PFpsPMt

 

 

 

Wednesday, January 15, 2020

4:00 pm  |  (UTC+00:00) Monrovia, Reyk= javik  |  1 hr

 

 

 

Join meeting

 

 

 

Join by phone

Tap to call in from a mobile device (attendees only)=

1-650-479-3208&n= bsp;Call-in toll number (US/Canada)

 

 

 

Need help? Go to http://help.webex.com

 

 

--_000_AM6PR07MB405314BD1C4F21708FFC47CE98370AM6PR07MB4053eurp_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpBdGxhbnRp Yy9SZXlramF2aWsNCkJFR0lOOlNUQU5EQVJEDQpEVFNUQVJUOjE2MDEwMTAxVDAwMDAwMA0KVFpP RkZTRVRGUk9NOiswMDAwDQpUWk9GRlNFVFRPOiswMDAwDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRB WUxJR0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAwMDAwMA0KVFpPRkZTRVRGUk9NOiswMDAwDQpUWk9G RlNFVFRPOiswMDAwDQpFTkQ6REFZTElHSFQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0K T1JHQU5JWkVSO0NOPUNCT1IgV29ya2luZyBHcm91cDtTRU5ULUJZPSJtYWlsdG86ZnJhbmNlc2Nh LnBhbG9tYmluaUBlcmljc3Nvbg0KIC5jb20iOm1haWx0bzpjYm9yLWNoYWlyc0BpZXRmLm9yZw0K QVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9 RkFMU0U7Q049Y2JvckBpZXRmDQogLm9yZzptYWlsdG86Y2JvckBpZXRmLm9yZw0KQVRUQUNIOkNJ RDo0Qzc5OENBRjcyRDYwQjQwOEFDMDA2NzQxMzFDNzg1MUBldXJwcmQwNy5wcm9kLm91dGxvb2su Y29tDQpERVNDUklQVElPTjtMQU5HVUFHRT1lbi1HQjpIaSBhbGxcLFxuXG5BIHJlbWluZGVyIHRo YXQgd2UgaGF2ZSBhbiBpbnRlcmltIHQNCiBvZGF5IChpbiBhcm91bmQgOTAgbWludXRlcylcLCBj YWxsIGRldGFpbHMgYmVsb3cuXG5cblRoZSBhZ2VuZGEgZm9yIHRvZGF5IA0KIGlzIHRvIGNvbnRp bnVlIHdvcmtpbmcgb24gQ0JPUiBiaXMuXG5cblRhbGsgdG8geW91IHNvb25cLFxuRnJhbmNlc2Nh XG5cblxuDQogRnJvbTogQ0JPUiBXb3JraW5nIEdyb3VwIDxtZXNzZW5nZXJAd2ViZXguY29tPlxu UmVwbHkgdG86IDxjYm9yLWNoYWlyc0BpZXQNCiBmLm9yZz5cbkRhdGU6IFR1ZXNkYXlcLCAyNiBO b3ZlbWJlciAyMDE5IGF0IDE0OjU3XG5UbzogPGNib3ItY2hhaXJzQGlldGYubw0KIHJnPlxuU3Vi amVjdDogV2ViZXggbWVldGluZyBpbnZpdGF0aW9uOiBDQk9SIHZpcnR1YWwgaW50ZXJpbSBtZWV0 aW5nXG5SZXNlDQogbnQgZnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+XG5SZXNlbnQgdG86 IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGENCiBycy5jb20+XCwgRnJhbmNlc2NhIFBhbG9t YmluaSA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20+XG5SZXNlbnQgZA0KIGF0ZTog VHVlXCwgMjYgTm92IDIwMTkgMDU6NTc6MjMgLTA4MDAgKFBTVClcblxuXG5DQk9SIFdvcmtpbmcg R3JvdXAgaW52aXRlDQogcyB5b3UgdG8gam9pbiB0aGlzIFdlYmV4IG1lZXRpbmcuXG5cblxuXG5N ZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDYNCiAgNDI0IDM0OVxuXG5NZWV0aW5nIHBh c3N3b3JkOiA3UEZwc1BNdFxuXG5cblxuV2VkbmVzZGF5XCwgSmFudWFyeSAxNVwsIDIwMg0KIDBc bjQ6MDAgcG0gIHwgIChVVEMrMDA6MDApIE1vbnJvdmlhXCwgUmV5a2phdmlrICB8ICAxIGhyXG5c blxuXG5Kb2luIG1lZXRpDQogbmc8aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01U SUQ9bTFmOTcwYjcwMzkwMWVlYzM3ZTE5MDc3MGNjMzUwYTgNCiBkPlxuXG5cblxuSm9pbiBieSBw aG9uZVxuVGFwIHRvIGNhbGwgaW4gZnJvbSBhIG1vYmlsZSBkZXZpY2UgKGF0dGVuZGVlcyBvbg0K IGx5KVxuMS02NTAtNDc5LTMyMDg8dGVsOiUyQjEtNjUwLTQ3OS0zMjA4XCxcLCowMSo2NDY0MjQz NDklMjMlMjMqMDEqPiBDYWxsDQogLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5cblxuXG5O ZWVkIGhlbHA/IEdvIHRvIGh0dHA6Ly9oZWxwLndlYmV4LmNvbVwNCiBuXG5cbg0KVUlEOjQ4NzFj ODk2LWRiMTMtNGFkNC04MmUzLWMzZDVlMzcxNzVmOQ0KU1VNTUFSWTtMQU5HVUFHRT1lbi1HQjpD Qk9SIEludGVyaW0gdG9kYXkgMDEtMTUtMjAyMA0KRFRTVEFSVDtUWklEPUF0bGFudGljL1JleWtq YXZpazoyMDIwMDExNVQxNjAwMDANCkRURU5EO1RaSUQ9QXRsYW50aWMvUmV5a2phdmlrOjIwMjAw MTE1VDE3MDAwMA0KQ0xBU1M6UFVCTElDDQpQUklPUklUWTo1DQpEVFNUQU1QOjIwMTkxMTI2VDEz NTcyMVoNClRSQU5TUDpPUEFRVUUNClNUQVRVUzpDT05GSVJNRUQNClNFUVVFTkNFOjE1NzQ3NzY2 NDENCkxPQ0FUSU9OO0xBTkdVQUdFPWVuLUdCOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zg0K WC1NSUNST1NPRlQtQ0RPLUFQUFQtU0VRVUVOQ0U6MTU3NDc3NjY0MQ0KWC1NSUNST1NPRlQtQ0RP LUJVU1lTVEFUVVM6VEVOVEFUSVZFDQpYLU1JQ1JPU09GVC1DRE8tSU5URU5ERURTVEFUVVM6QlVT WQ0KWC1NSUNST1NPRlQtQ0RPLUFMTERBWUVWRU5UOkZBTFNFDQpYLU1JQ1JPU09GVC1DRE8tSU1Q T1JUQU5DRToxDQpYLU1JQ1JPU09GVC1DRE8tSU5TVFRZUEU6MA0KWC1NSUNST1NPRlQtRE9OT1RG T1JXQVJETUVFVElORzpGQUxTRQ0KWC1NSUNST1NPRlQtRElTQUxMT1ctQ09VTlRFUjpGQUxTRQ0K WC1NSUNST1NPRlQtTE9DQVRJT05TOlt7IkRpc3BsYXlOYW1lIjoiaHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmIlwsIkxvY2F0DQogaW9uQW5ub3RhdGlvbiI6IiJcLCJMb2NhdGlvblVyaSI6IiJc LCJMb2NhdGlvblN0cmVldCI6IiJcLCJMb2NhdGlvbkNpdHkiOiINCiAiXCwiTG9jYXRpb25TdGF0 ZSI6IiJcLCJMb2NhdGlvbkNvdW50cnkiOiIiXCwiTG9jYXRpb25Qb3N0YWxDb2RlIjoiIlwsIkxv Yw0KIGF0aW9uRnVsbEFkZHJlc3MiOiIifV0NCkJFR0lOOlZBTEFSTQ0KREVTQ1JJUFRJT046UkVN SU5ERVINClRSSUdHRVI7UkVMQVRFRD1TVEFSVDotUFQ1TQ0KQUNUSU9OOkRJU1BMQVkNCkVORDpW QUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== --_000_AM6PR07MB405314BD1C4F21708FFC47CE98370AM6PR07MB4053eurp_-- --_005_AM6PR07MB405314BD1C4F21708FFC47CE98370AM6PR07MB4053eurp_ Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Description: Webex_Meeting.ics Content-Disposition: attachment; filename="Webex_Meeting.ics"; size=5348; creation-date="Tue, 26 Nov 2019 13:57:37 GMT"; modification-date="Tue, 26 Nov 2019 13:57:37 GMT" Content-ID: <4C798CAF72D60B408AC00674131C7851@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL1JleWtqYXZpaw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96 b25laW5mby1vdXRsb29rL0F0bGFudGljL1JleWtqYXZpaw0KWC1MSUMtTE9DQVRJT046QXRsYW50 aWMvUmV5a2phdmlrDQpCRUdJTjpTVEFOREFSRA0KVFpPRkZTRVRGUk9NOiswMDAwDQpUWk9GRlNF VFRPOiswMDAwDQpUWk5BTUU6R01UDQpEVFNUQVJUOjE5NzAwMTAxVDAwMDAwMA0KRU5EOlNUQU5E QVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAxOTExMjZUMTM1NzIx Wg0KQVRURU5ERUU7Q049IkNCT1IgV29ya2luZyBHcm91cCI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7 UlNWUD1UUlVFOk1BSUxUTzpjYm9yLWNoYWlyc0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJDQk9S IFdvcmtpbmcgR3JvdXAiOk1BSUxUTzpjYm9yLWNoYWlyc0BpZXRmLm9yZw0KRFRTVEFSVDtUWklE PUF0bGFudGljL1JleWtqYXZpazoyMDIwMDExNVQxNjAwMDANCkRURU5EO1RaSUQ9QXRsYW50aWMv UmV5a2phdmlrOjIwMjAwMTE1VDE3MDAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmDQpUUkFOU1A6T1BBUVVFDQpTRVFVRU5DRToxNTc0Nzc2NjQxDQpVSUQ6NDg3MWM4OTYt ZGIxMy00YWQ0LTgyZTMtYzNkNWUzNzE3NWY5DQpERVNDUklQVElPTjpcblxuXG5cbkpPSU4gV0VC RVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTFmOTcw YjcwMzkwMWVlYzM3ZTE5MDc3MGNjMzUwYThkXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUp OiA2NDYgNDI0IDM0OVxuXG5cbk1lZXRpbmcgcGFzc3dvcmQ6IDdQRnBzUE10XG5cblxuXG5KT0lO IEJZIFBIT05FXG4xLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEp XG5UYXAgaGVyZSB0byBjYWxsIChtb2JpbGUgcGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0 ZWQpOiB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDY0MjQzNDklMjMlMjMqMDEqXG5cblxu XG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNp c2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFz ZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5m b3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1h eSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNz aW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91 IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMg d2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQtREVTQztG TVRUWVBFPXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxuKiB7XG4gICAgcGFkZGlu ZzogMDsgICAgbWFyZ2luOiAwO31cbnRhYmxlIHtcbglib3JkZXItY29sbGFwc2U6IHNlcGFyYXRl OyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2luZzogMDt9XG5cbnRyIHtcbgls aW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRkIHtcbglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFt aWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1icmVh azogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxuLnRpdGxlIHtcbglmb250LXNpemU6IDI4cHg7fVxu XG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwltYXgtd2lkdGg6IGF1dG87fVxuXG4uZm9vdGVyIHtc bgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7XG5cbn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRl dmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0bGUge1xuCQlmb250LXNpemU6IDIycHggIWltcG9y dGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRoOiBhdXRvICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6 IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290ZXIge1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50 OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxuCS5tYWluIHtcbgkJd2lkdGg6IDEw MCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbn1cbjwvc3R5 bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFyZ2lu OiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiPlxuCTx0ciBzdHlsZT0i aGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCTx0cj5cbgkJPHRkIGFsaWduPSJs ZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAiPlxuCQkJPCEtLTx0YWJsZSBi Z2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7IHdpZHRoOiAxMDAlOyBwYWRkaW5n LWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1h aW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5i c3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPi0tPlxuXG5cblxuXG5cbgkJCTx0 YWJsZT5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjQiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+V2hlbiBpdCdzIHRpbWUsIGpvaW4gdGhlIFdlYmV4IG1lZXRp bmcgaGVyZS48L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCQk8dHIgc3R5bGU9Imxp bmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3Ry PlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDYgNDI0IDM0 OTwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT5cbgkJCVxuCQkJPHRh YmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5N ZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj43UEZwc1BNdDwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT5cblxu ICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+ PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPHRyPlxuCQkJCTx0 ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4JCQkJCTx0YWJsZSBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5bGU9IndpZHRoOmF1dG87d2lkdGg6 YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNBOTQyOyBib3JkZXI6MHB4IHNvbGlk ICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdpZHRoOjE2MHB4IWltcG9ydGFudDsi PlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiBzdHlsZT0icGFkZGluZzox MHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tMWY5NzBiNzAzOTAxZWVjMzdlMTkwNzcwY2MzNTBhOGQiIHN0eWxlPSJjb2xvcjojRkZGRkZG OyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5Kb2luIG1lZXRpbmc8L2E+ PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4JCQkJPC90ZD5cbgkJCTwvdHI+XG4J CTwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9ImZvbnQt ZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJz cDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSI0IiBGQUNF PSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2lu IGJ5IHBob25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+PGI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQ2 NDI0MzQ5JTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29yYXRpb246 bm9uZTsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjRw eDsnPjEtNjUwLTQ3OS0zMjA4PC9hPjwvYj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRh KTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48QlI+XG5cbjx0YWJsZT48dHIgc3R5bGU9Imxp bmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3Ry PjwvdGFibGU+XG5cblxuXG5cblxuCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDogMTAwJTsiIGFsaWdu PSJsZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6 IDcycHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgc3R5bGU9Imhl aWdodDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OkFyaWFsOyBmb250LXNpemU6 IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBHbyB0byA8YSBocmVmPSJodHRw Oi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5OyB0ZXh0LWRlY29yYXRpb246 bm9uZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxu ICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48dGQ+Jm5ic3A7PC90ZD48 L3RyPlxuCQkJPC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90YWJsZT5cbg0KU1VNTUFSWTpD Qk9SIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nDQpQUklPUklUWTo1DQpDTEFTUzpQVUJMSUMNCkJF R0lOOlZBTEFSTQ0KVFJJR0dFUjotUFQ1TQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9OOlJl bWluZGVyDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= --_005_AM6PR07MB405314BD1C4F21708FFC47CE98370AM6PR07MB4053eurp_-- From nobody Wed Jan 15 07:37:09 2020 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 6917D120025; Wed, 15 Jan 2020 07:36:21 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 AlLBSVD9wHHJ; Wed, 15 Jan 2020 07:36:17 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B135A12004F; Wed, 15 Jan 2020 07:36:15 -0800 (PST) Received: from [192.168.217.119] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47yWd96T52z16B2; Wed, 15 Jan 2020 16:36:13 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: Date: Wed, 15 Jan 2020 16:36:13 +0100 Cc: Francesca Palombini , "cbor@ietf.org" , "draft-ietf-cbor-7049bis@ietf.org" , "cbor-chairs@ietf.org" X-Mao-Original-Outgoing-Id: 600795372.758034-3a5c4221c21c6757977399dcc5438742 Content-Transfer-Encoding: quoted-printable Message-Id: <3050C0BF-2B1A-4396-ADED-AD5ED4C6EC60@tzi.org> References: <293AFF31-D0EF-45D6-9B9D-E8136481C404@ericsson.com> To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-7049bis-09?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 15:36:22 -0000 Hi Jeffrey, Beyond the one comment that I singled out on 3.4.4, here are my = responses/proposals: > 1. Introduction > =E2=80=A2 "The format defined here follows some specific design = goals that are not well met by current formats." <- "Follows" doesn't = really work. Maybe "pursues"? "Satisfies"? "Pursues", I=E2=80=99d say. > =E2=80=A2 "It is important to note that this is not a proposal = that the grammar in RFC 8259 be extended in general, since doing so = would cause a significant backwards incompatibility with already = deployed JSON documents." <- This is probably not necessary anymore. It = could be removed entirely or replaced with "This format is not an = extension of the grammar in RFC 8259." I like that. > 3.1. Major Types > =E2=80=A2 In Table 1, can we spell out "Major Type" instead of = "mt"? We can, but that reduces space for the other columns; I=E2=80=99d rather = fix the caption to repeat the text about mt and N above the table. I took the liberty to add the equivalent table for indefinite length as = table 2; please review. > 3.4. Tagging of Items > =E2=80=A2 I'm not sure what "while retaining its structure" = accomplishes here. Can we remove it? (It really means: =E2=80=9Cwithout the need to change its structure=E2=80=9D= .) This is a bit of a trap door thing: Once you understand the concept, = this appears redundant. But I=E2=80=99m also at a loss how to say this better, so I agree we = should remove it. > =E2=80=A2 "That is, a tag is a data item consisting of a tag = number and an enclosed value. The content of the tag (the enclosed data = item) is the data item (the value) that is being tagged." might be = unnecessary. I think it's covered by the earlier text in this section. = If it's still needed, it should probably move earlier to where we define = tagged data. It doesn't fit next to the discussion of what it means to = put a tag inside a tag. Right, we should reverse the order. > =E2=80=A2 "it can just jump over the initial bytes of the tag = (that encode the tag number)" isn't quite right: it's not just skipping = it, it's reporting both the tag number and value to the application. = Maybe "Understanding the semantics of tags is optional for a decoder: it = can present the tag number and content to the application without = interpreting the tag as a whole." I made this a bit more specific about =E2=80=9Cinterpreting=E2=80=9D. > 3.4.1. Date and Time > =E2=80=A2 The next two sections seem like they should be = subsections. (This was already changed earlier.) >=20 > 3.4.3. Epoch-based Date/Time > =E2=80=A2 "An application that requires tag number 1 support may = restrict" has a lowercase MAY, which has an ambiguous effect after RFC = 8174. Do we want MAY or can? This is not an interoperability MAY, as it describes what an application = can do. That maybe raises the general question how we are using BCP14 language, = but RFC 8174 was written to clarify that lower case may does not have = the special meaning of upper case MAY. > 3.4.4. Bignums > =E2=80=A2 This section has a forward reference to "preferred = encoding", which should cite section 4.1. I note that 4.1 uses = "preferred serialization" instead, so maybe we should switch this = section to that term. Interesting fine point. I changed all =E2=80=9Cpreferred encoding=E2=80=9D= to =E2=80=9Cpreferred serialization=E2=80=9D (except the one that is = used in defining the latter) and added the reference. We may want to = keep some form of differentiation between preferred serialization (which = is never visible at the basic data model level) and the choice of a = basic data model realization for an extended data model value; maybe we = should discuss this with the item below. > =E2=80=A2 "and preferred encoding never makes use of bignums = that also can be expressed as basic integers (see below)." <- This seems = inconsistent with "In the generic data model, bignum values are not = equal to integers from the basic data model". If they're not the same = value at the data model level, they can't be alternate encodings of each = other. See separate message. > 3.4.5. Decimal Fractions and Bigfloats > =E2=80=A2 "Decimal fractions (tag number 4) use base-10 = exponents; the value of a decimal fraction data item is m*(10**e). = Bigfloats (tag number 5) use base-2 exponents; the value of a bigfloat = data item is m*(2**e)." is redundant with the first paragraph of the = section. Somewhat. The first paragraph says what can be represented, the fourth = exactly what is being represented. Is the redundancy a big problem? > =E2=80=A2 This section also suggests that integers be used = instead of integral bigdecimals and bigfloats. That only works if the = specific data model says they're equivalent. Maybe we should say = specific data models SHOULD make them equivalent and then SHOULD set the = preferred encoding to the integer version? Generally, we have been moving away from making int and float = equivalent, so I agree this recommendation needs to be reshaped. A = similar question occurs with basic floating point as well, so we should = come to a common view on these. Now issue #160: = https://github.com/cbor-wg/CBORbis/issues/160 > 3.4.6.2. Expected Later Encoding for CBOR-to-JSON Converters > =E2=80=A2 This section only defines the tags obliquely and never = says what tag 23 means. I suggest starting sentences with the tag = number, e.g. "Tag number 21 means the contained byte string is expected = to be encoded in base64url without padding ... Tag number 22 means ..." Did this; added reference to Section 8 of RFC 4648, and emphasized the = uppercase alphabetics used there. > 3.4.6.3. Encoded Text > =E2=80=A2 "Tag numbers 33 and 34 are for base64url- and = base64-encoded text strings" should maybe have "respectively"? Added. >=20 > 4.1. Preferred Serialization > =E2=80=A2 "1_000_000_000" has enough digits that maybe we should = use 10**9 (or 109 in v3) instead. Three by three is obvious enough to me, but I have added =E2=80=9C(one = billion)=E2=80=9D to add more fun to milliard-educated people like me. > 4.2. Deterministically Encoded CBOR > =E2=80=A2 "Some protocols may want" has a lowercase "may". = Consider "might". See comment on RFC 8174 above. (This is not a sufficiently remote corner case to use =E2=80=9Cmight=E2=80= =9D, in my eyes.) > 4.2.1. Core Deterministic Encoding Requirements > =E2=80=A2 This section says "Floating point values also MUST use = the shortest form that preserves the value, e.g. 1.5 is encoded as = 0xf93e00 and 1000000.5 as 0xfa49742408.", but 4.2.2 says "If a protocol = allows for IEEE floats, then additional deterministic encoding rules = might need to be added." We should only put the float rule in one of = these sections. Yes, we are now probably ready to reduce the variety here. I moved over = the text about trying successively shorter representations as an = implementation note for 4.2.1. I also added some text about an = application wanting to limit precision. > 4.2.2. Additional Deterministic Encoding Considerations > =E2=80=A2 "the deterministic format would not allow them" isn't = clear what "them" is. Do we mean "would not allow the data to be = tagged"? Or should we just say that the deterministic format for the = protocol needs to specify whether the tag is or is not present? > =E2=80=A2 The "If a protocol includes a field that can express = floating-point values" paragraph also assumes "=E2=80=A6 and the = protocol's specific data model declares integers and floating point = values to be interchangeable". Right. Case 3 is a bit questionable, as this is not conforming to = preferred serialization. > =E2=80=A2 The "A protocol might give encoders the choice of = representing a URL ..." item feels like it's repeating the "CBOR tags = present =E2=80=A6" paragraph. Maybe we should move it to an example in = that paragraph? Moved and made into an example. > =E2=80=A2 Maybe the ""Protocols that include floating, big = integer, or other complex values need to define extra requirements on = their deterministic encodings. For example:" introductory sentence = belongs at the top of the whole section. Right. I restructured the section a bit. The part about bignums maybe also needs to be made stronger. > 5. Creating CBOR-Based Protocols > =E2=80=A2 "This section discusses" might read better as "The = rest of this section" since it's after a bit of the section. Right. >=20 > 5.2. Generic Encoders and Decoders > =E2=80=A2 "Even though CBOR attempts to minimize these cases, = not all well-formed CBOR data is valid" is redundant with a lot of text = from earlier in the document. Right. Redundancy is not always bad, though; some repetition can be = useful. > =E2=80=A2 I wonder if this whole subsection is out of place. It = reads like a definition of generic en/decoders rather than a = consideration for designing protocols. Maybe it should be a subsection = of "Terminology"? Good point. Maybe the results of processing #156 will also point in = that direction. But the concept is not just terminology, it is a constraint on the = design decisions of CBOR and its protocols. If a protocol is designed = in such a way that it cannot use generic codecs, it really gives up a = major advantage of using CBOR =E2=80=94 this is why the subsection is = here at the moment. > 5.3. Validity of Items > =E2=80=A2 "The first layer that does process the semantics of an = invalid CBOR item MUST take one of two choices:" covers our discussion = of duplicate map keys. Right now, our requirements aren't consistent = with the requirements in this section, so we should make sure to = incorporate this section when we resolve those. Right. Issue #63. >=20 > 5.3.2. Tag validity > =E2=80=A2 "might present this tag to the application in a = similar way to how it would present a tag with an unknown tag number" = seems to suggest that it's wrong to replace the invalid tag with an = error marker or to stop processing entirely, even though that's what 5.3 = suggests. Again, discussion about what a generic decoder should do. Or, here, = specifically how the validity function of a tag could evolve. > 5.5. Numbers > =E2=80=A2 "the JavaScript number system treats all numbers as = floating point" is no longer true: = https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_O= bjects/BigInt BigInts are not JavaScript Numbers. (This legacy-forced separation is a = whole can of worms and does not really detract from what is said.) I = added =E2=80=9Cbasic=E2=80=9D. > =E2=80=A2 "a compact application should accept" uses a lowercase = "should" and would seem to discourage compact applications that check = for a deterministic decoding. Do we mean that accepting wider encodings = is likely to make the application more compact? Not all applications SHOULD check for deterministic encoding=E2=80=A6 Added "that does not require deterministic encoding=E2=80=9D. > =E2=80=A2 "The preferred encoding for a floating-point value is = the shortest floating-point encoding" is redundant with section 4.1, = although it does include more detail. I *think* I'd rather put the whole = definition of the preferred encoding in 4.1 instead of having some of it = in protocol considerations. Moved (and added back some text here). > 5.6. Specifying Keys for Maps > =E2=80=A2 "probably should be limited" -> "may need to be = limited" or "the specification is probably simpler if"? To avoid BCP 14 = terms.=20 Restated this slightly. > =E2=80=A2 We're already discussing the question of duplicate = keys in another thread. Yes; issue #63. > =E2=80=A2 "except to specify that some, orders" has an extra = comma. > =E2=80=A2 "be enough reason on its own" -> "on their own" > =E2=80=A2 The "should consider using small integers as keys" has = the downside that it makes it harder for humans to understand the = meaning of the data without the schema. "for constrained devices" might = protect the rest of us from that downside, but would it make sense to = say it explicitly? One word: =E2=80=9CBTU=E2=80=9D :-) I think we are already explicit about this, but we don=E2=80=99t mention = the downside (or the upside that you are now forced to properly define = the things). > 5.6.1. Equivalence of Keys > =E2=80=A2 This section might be shorter if it just says that map = keys are duplicates if they have the same value in the generic data = model or if the specific data model for the protocol (Section 2.2) says = they're equivalent. The rest of the section just duplicates information = that's already in Section 2. The note in the last paragraph does still = seem useful. Will handle with #63. > 8.1. Encoding Indicators > =E2=80=A2 "Note that the encoding indicator "_" is thus an = abbreviation of the full form "_7", which is not used." is confusing = where it is. It might make more sense if we swap its paragraph with the = previous one and move it to after the definition of "[_ 1, 2]". I=E2=80=99m not sure I understand how to do this without forward = references. > =E2=80=A2 "As a special case, byte and text strings of = indefinite length" doesn't seem like a special case to me. It's just the = way you represent the encoding of an indefinite-length byte or text = string. Yes. Removed =E2=80=9Cas a special case=E2=80=9D. (We still don=E2=80=99t have a way to notate an empty indefinite length = string.) >=20 > 9.2. Tags Registry > =E2=80=A2 Did we decide not to tighten registration for the = 256=E2=80=9365535 space? I couldn=E2=80=99t find anything conclusive; the discussion seemed to = center on the designated expert. > 9.3. Media Type ("MIME Type") > =E2=80=A2 Is there a reason this section switches to artwork in = the middle? Lazyness. (Oh, this probably should be fixed, too, now #161. There is a long-standing bug in XML2RFC that creates incorrect = formatting if this is done right.) >=20 > 9.4. CoAP Content-Format > =E2=80=A2 Could this section link to = https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#con= tent-formats? Yes. (Not sure how to do the sub registry part, though.) > Appendix A. Examples > =E2=80=A2 This starts with some references to Unicode code = points, which could use the new tag. If we want to take a full v3 plunge=E2=80=A6 >=20 > Appendix F. Changes from RFC 7049 > =E2=80=A2 This looks quite incomplete. Indeed! Now #163: https://github.com/cbor-wg/CBORbis/issues/162 Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 15 07:43:24 2020 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 8AA0F12004A; Wed, 15 Jan 2020 07:42:23 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 GVA-vbfQ33Ya; Wed, 15 Jan 2020 07:42:18 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5FB120091; Wed, 15 Jan 2020 07:42:17 -0800 (PST) Received: from [192.168.217.119] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47yWm81jZQz16LT; Wed, 15 Jan 2020 16:42:16 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: <3050C0BF-2B1A-4396-ADED-AD5ED4C6EC60@tzi.org> Date: Wed, 15 Jan 2020 16:42:15 +0100 Cc: Francesca Palombini , "cbor@ietf.org" , "draft-ietf-cbor-7049bis@ietf.org" , "cbor-chairs@ietf.org" X-Mao-Original-Outgoing-Id: 600795735.36531-ec56a0cc140701863d35d031349e18db Content-Transfer-Encoding: quoted-printable Message-Id: <72600F97-2608-4C7C-92BF-DBEA677F4795@tzi.org> References: <293AFF31-D0EF-45D6-9B9D-E8136481C404@ericsson.com> <3050C0BF-2B1A-4396-ADED-AD5ED4C6EC60@tzi.org> To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-7049bis-09?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 15:42:23 -0000 On 2020-01-15, at 16:36, Carsten Bormann wrote: >=20 > here are my responses/proposals And here is the pull request for the items that have not become separate = issues: https://github.com/cbor-wg/CBORbis/pull/163 Thanks again for that thoughtful review! Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 15 12:22:44 2020 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 5AACE1209FF for ; Wed, 15 Jan 2020 12:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.252 X-Spam-Level: X-Spam-Status: No, score=-9.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 DB8Nht9QwIj9 for ; Wed, 15 Jan 2020 12:22:42 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 F31211209EA for ; Wed, 15 Jan 2020 12:22:41 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id d71so17008243qkc.0 for ; Wed, 15 Jan 2020 12:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7/CSFSqsckVHg2Z4mXfQ+GtxSjtElgqLcIeYLgllLGM=; b=dxD46P0BeY3GccLf6tSvJ28pQ0f0sNT1ncVRqxfZcE818xQl1rl6L5DmLhm2pzVVjh +uRzI5jUj4X+ec09ixWVN7lEji/enRUSMVioGjeB0lkkKOEMAFKgNID77SAT4ZafTQ+W 0LSCdv0TigxG0TeKp/pKM2wfVAKbb9GK/MIzU= 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:content-transfer-encoding; bh=7/CSFSqsckVHg2Z4mXfQ+GtxSjtElgqLcIeYLgllLGM=; b=JRFvKdEtlGN9EzUEdbiiyBi3L7u6wRdNnoDSkt8Drp/fMHIpw6ghY/NEIv4dsHDQqT JkIR5Hl7Vxpic0tR9SG2AzotqbmjVvYMRifjSu/5aPdotho4R5xE13u7mZiY4xUG0YW0 Zm7LCNHex0WCJf13+Aqq/nwobd90FhlWxZvUi97P3g12KePx1GgtTWJ8OeeQPhslnp+4 wITVMjqqSo34wzH6Zzx57ZPTAITdeKTC0xQVt4CFUdBGR39NZo8ejnWXAnQnFWtD91Gj 3Zt7FcpLD1+I+HB5NTUa2rAIKPOlT4XEKmtCpwpqRK+YeUdQxWZAYDazVZyy/EkDkuic 46tA== X-Gm-Message-State: APjAAAVa+mRzrSkkZO1LV9sQKOCPO3k1pcV2WBUO23JXyW9afZrntLfd KkBplYsloeYfDpnhdaZZgdJ48o5sDnZMZVCl3OgPW7WXp4E= X-Google-Smtp-Source: APXvYqxavA0T5AWUUGYy3vbX4gpd13fS10ioKLu1ae+Nug999IWgdbQDeIIcmYMSSEDMWzbJ6/Kwbuf7gXYTjY9KMhY= X-Received: by 2002:a37:e505:: with SMTP id e5mr26526923qkg.324.1579119760662; Wed, 15 Jan 2020 12:22:40 -0800 (PST) MIME-Version: 1.0 References: <293AFF31-D0EF-45D6-9B9D-E8136481C404@ericsson.com> In-Reply-To: From: Jeffrey Yasskin Date: Wed, 15 Jan 2020 12:22:29 -0800 Message-ID: To: Carsten Bormann Cc: Jeffrey Yasskin , "cbor@ietf.org" , "draft-ietf-cbor-7049bis@ietf.org" , "cbor-chairs@ietf.org" , Francesca Palombini Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] =?utf-8?q?Bignums_and_the_generic_data_models_=28Re=3A_?= =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-7049bis-09=29?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 20:22:43 -0000 On Tue, Jan 14, 2020 at 1:52 PM Carsten Bormann wrote: > > On 2019-11-24, at 12:23, Jeffrey Yasskin wrote: > > > > 3.4.4. Bignums > > [=E2=80=A6] > > =E2=80=A2 "and preferred encoding never makes use of bignums that= also can be expressed as basic integers (see below)." <- This seems incons= istent with "In the generic data model, bignum values are not equal to inte= gers from the basic data model". If they're not the same value at the data = model level, they can't be alternate encodings of each other. > > Hi Jeffrey, > > of your many useful comments in that message, let me pick this one becaus= e answering it is a prerequisite to getting the map validity text right. > > Indeed, in the basic (unextended) generic data model, bignums are differe= nt from (mt0/1) integers. > > The extended generic data model for tag 2/3 changes this. It has to. Co= nsider: > > 2(h'00112233445566778899') > and > 2(h'112233445566778899') > > These are different in the basic generic data model, but both mean 316059= 037807746189465 in the extended generic data model, so that has to be diffe= rent from the basic one. > > So given that we already had to extend the generic data model with the va= lues (types) specific to the tag semantics, we also can (and should!) say t= hat > > 2(h'12') > > means 18 in the extended generic data model, the preferred encoding of wh= ich is 0x12 and not 0xc24112. > > For a generic codec, both options are available for a specific tag number= : > > - offer the basic generic data model. This leaves it to the application = to build the tag content in the way that fits to the tag definition and to = interpret it this way. It is then also up to the application to take care = of map validity (e.g., by not using both 2(h'00112233445566778899=E2=80=99)= and 2(h'112233445566778899=E2=80=99) as keys in the same map), and to issu= e preferred serialization if desired. > =E2=80=94 process the tag, i.e., offer the extended generic data model. = Now the generic codec can do all that work; for the example at hand, at the= codec API you only see integers. > > This is the direction in which I think we need to go if we want to enable= tag processing in generic codecs. > > (The cognitive dissonance here is maybe with ECMAscript bigints, which ar= e a separate type from numbers. But sending a bignum is not on its own a g= ood way to distinguish a number as a ES bigint; probably a language-specifi= c tag is a better way to make that language-specific distinction.) > I think either of the following situations would be plausible: 1. 2(h'12') is a different value from major-type-0 "18", in the same way major-type-0 18 is a different value from floating "18.0". 2. 2(h'12') is the same value as major-type-0 "18", but both are distinct from floating "18.0". (It would also have been plausible to declare that integral 18 is the same value as floating 18.0, but we discussed that a while ago and decided to keep them separate.) I don't think the wording in https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#extended-gen= eric-data-models nails down whether tags can offer alternate representations for elements of the basic generic data model. It's true that a tag can define a non-injective mapping into its domain, but I don't think that by itself requires that its domain be able to overlap the domain of the basic generic data model. The extended generic data model *does* specify that particular tag values in the basic generic data model are equal to other values in the extended generic data model, but in that case the identified values have the same encoding, so I don't think it helps much in deciding whether they can be equal to a value in the basic generic data model. My preference is to follow the decision we made to distinguish integers from floating point, and also distinguish bignums from primitives. However, if we decide not to do that, we need to remove the sentence in https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#bignums saying "In the generic data model, bignum values are not equal to integers from the basic data model" and the sentence in https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#fractions saying "As with bignums, values of different types are not equal in the generic data model." Jeffrey From nobody Wed Jan 15 12:52:30 2020 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 8E42912089C; Wed, 15 Jan 2020 12:52:28 -0800 (PST) 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_HELO_NONE=0.001, 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 NeiT00IIcF4X; Wed, 15 Jan 2020 12:52:26 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7CCD120288; Wed, 15 Jan 2020 12:52:25 -0800 (PST) Received: from [192.168.217.119] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47yfdz6RgDz16GD; Wed, 15 Jan 2020 21:52:23 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: Date: Wed, 15 Jan 2020 21:52:23 +0100 Cc: "draft-ietf-cbor-7049bis@ietf.org" , Francesca Palombini , "cbor-chairs@ietf.org" , "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 600814343.394309-e50ceaa1fa82d116aea0b3e59f6beb4f Content-Transfer-Encoding: quoted-printable Message-Id: <5A7E7B96-6F5D-479C-8660-D144A25AA882@tzi.org> References: <293AFF31-D0EF-45D6-9B9D-E8136481C404@ericsson.com> To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Cbor] =?utf-8?q?Bignums_and_the_generic_data_models_=28Re=3A_?= =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-7049bis-09=29?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 20:52:29 -0000 >=20 > I think either of the following situations would be plausible: >=20 > 1. 2(h'12') is a different value from major-type-0 "18", in the same > way major-type-0 18 is a different value from floating "18.0". > 2. 2(h'12') is the same value as major-type-0 "18", but both are > distinct from floating "18.0". (1) would then extend to numbers bigger than can be represented in basic = integers? I don=E2=80=99t think the simple fact that the range of an integer = exceeds the 64-bit + sign (=E2=80=9C65-bit=E2=80=9D) range of basic CBOR = integers should catapult it into a different universe. Once 128-bit = numbers are becoming more common, that would create an ugly = discontinuity. So I strongly believe that only (2) is compatible with = long-term stability of the format. > (It would also have been plausible to declare that integral 18 is the > same value as floating 18.0, but we discussed that a while ago and > decided to keep them separate.) Indeed. We kept this somewhat open in RFC 7049, but experience seems to = indicate that separating the integer world from the floating point world = is the right thing at least for the generic data models (application = data models can unite them). > I don't think the wording in > = https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#extended-ge= neric-data-models > nails down whether tags can offer alternate representations for > elements of the basic generic data model. >=20 > It's true that a tag can define a non-injective mapping into its > domain, but I don't think that by itself requires that its domain be > able to overlap the domain of the basic generic data model. >=20 > The extended generic data model *does* specify that particular tag > values in the basic generic data model are equal to other values in > the extended generic data model, but in that case the identified > values have the same encoding, so I don't think it helps much in > deciding whether they can be equal to a value in the basic generic > data model. >=20 > My preference is to follow the decision we made to distinguish > integers from floating point, and also distinguish bignums from > primitives. (I=E2=80=99d say: Yes, no =E2=80=94 See above.) > However, if we decide not to do that, we need to remove > the sentence in > https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#bignums > saying "In the generic data model, bignum values are not equal to > integers from the basic data model" and the sentence in > = https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#fractions > saying "As with bignums, values of different types are not equal in > the generic data model." Yes, that is work that needs to be done. Now #164: = https://github.com/cbor-wg/CBORbis/issues/164 (Peter Occil has another interesting observation about fractions in = https://github.com/cbor-wg/CBORbis/issues/160#issuecomment-574787487 =E2=80= =94 this probably requires more text about deterministic encoding for = these, as well.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 15 13:00:16 2020 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 9906E120911 for ; Wed, 15 Jan 2020 13:00:14 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 7X_2H87DZcGk for ; Wed, 15 Jan 2020 13:00:09 -0800 (PST) Received: from p3plsmtpa12-03.prod.phx3.secureserver.net (p3plsmtpa12-03.prod.phx3.secureserver.net [68.178.252.232]) (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 8192512090B for ; Wed, 15 Jan 2020 13:00:09 -0800 (PST) Received: from [192.168.1.76] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id rploiSNnX0h91rploimTIJ; Wed, 15 Jan 2020 14:00:09 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Laurence Lundblade In-Reply-To: Date: Wed, 15 Jan 2020 13:00:08 -0800 Cc: Carsten Bormann , "draft-ietf-cbor-7049bis@ietf.org" , Francesca Palombini , "cbor-chairs@ietf.org" , "cbor@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <293AFF31-D0EF-45D6-9B9D-E8136481C404@ericsson.com> To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfIrd/AnGBAQ6JTvF54/FQeM6wTZ1j5xvy8tw1xs1BcyFgzPBhXmXGouYGazy5dvHDq/h8GZnMJFx5IEb+BeuQo9/yuktMLDIpJ0Sedfjn8F4xrzQPV3j Jb73QSKfiv+t67Z9uXYgxhqWLJKifyyks9dKY7LnCP/lShV0+VgkxxGALwI5G6wsup0F+CJBBFvW1nx7+9sEkQWAg8ybH/vuDJIjnn0y8bDaQ1tAAIf86VrV vcEcFaavyOiKpg/bX7akPPZn9claEDCdVc1TU/WeojrGK35QqmjE5z+s1YZJfZrsVsO/Y1YqV/fy3hB8q53kBKXz1WXB/b817c4YZTGS/P99OxXr0KAxzR8D YxaO/qC1tPmbuEGOfir4pGlEXE7+5g== Archived-At: Subject: Re: [Cbor] =?utf-8?q?Bignums_and_the_generic_data_models_=28Re=3A_?= =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-7049bis-09=29?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 21:00:14 -0000 I=E2=80=99m in favor of bignums being quite separate: - There are very very few use cases for them, many fewer than floating = point, as we just don=E2=80=99t need the the range and the precision at = the same time - CPUs and programming languages don=E2=80=99t generally or generically = support them =E2=80=94 if you are writing code for bignums you are = writing very specific code For example, I don=E2=80=99t think it would be useful for a generic = decoder to convert bignums less than 0xffffffff to uint32_t and those = larger than that to a byte array when returned to the caller. I don=E2=80=99t think anyone is going to send smaller integer values as = the bignum type (some integer values like 0xffffff encode smaller as a = bignum type than they would as type 0 and 1, but I don=E2=80=99t think = we want to encourage that).=20 LL Bignum spelling auto correct: big numb lignum bingo bigness! > On Jan 15, 2020, at 12:22 PM, Jeffrey Yasskin = wrote: >=20 > On Tue, Jan 14, 2020 at 1:52 PM Carsten Bormann wrote: >>=20 >> On 2019-11-24, at 12:23, Jeffrey Yasskin = wrote: >>>=20 >>> 3.4.4. Bignums >>> [=E2=80=A6] >>> =E2=80=A2 "and preferred encoding never makes use of bignums = that also can be expressed as basic integers (see below)." <- This seems = inconsistent with "In the generic data model, bignum values are not = equal to integers from the basic data model". If they're not the same = value at the data model level, they can't be alternate encodings of each = other. >>=20 >> Hi Jeffrey, >>=20 >> of your many useful comments in that message, let me pick this one = because answering it is a prerequisite to getting the map validity text = right. >>=20 >> Indeed, in the basic (unextended) generic data model, bignums are = different from (mt0/1) integers. >>=20 >> The extended generic data model for tag 2/3 changes this. It has to. = Consider: >>=20 >> 2(h'00112233445566778899') >> and >> 2(h'112233445566778899') >>=20 >> These are different in the basic generic data model, but both mean = 316059037807746189465 in the extended generic data model, so that has to = be different from the basic one. >>=20 >> So given that we already had to extend the generic data model with = the values (types) specific to the tag semantics, we also can (and = should!) say that >>=20 >> 2(h'12') >>=20 >> means 18 in the extended generic data model, the preferred encoding = of which is 0x12 and not 0xc24112. >>=20 >> For a generic codec, both options are available for a specific tag = number: >>=20 >> - offer the basic generic data model. This leaves it to the = application to build the tag content in the way that fits to the tag = definition and to interpret it this way. It is then also up to the = application to take care of map validity (e.g., by not using both = 2(h'00112233445566778899=E2=80=99) and 2(h'112233445566778899=E2=80=99) = as keys in the same map), and to issue preferred serialization if = desired. >> =E2=80=94 process the tag, i.e., offer the extended generic data = model. Now the generic codec can do all that work; for the example at = hand, at the codec API you only see integers. >>=20 >> This is the direction in which I think we need to go if we want to = enable tag processing in generic codecs. >>=20 >> (The cognitive dissonance here is maybe with ECMAscript bigints, = which are a separate type from numbers. But sending a bignum is not on = its own a good way to distinguish a number as a ES bigint; probably a = language-specific tag is a better way to make that language-specific = distinction.) >>=20 >=20 > I think either of the following situations would be plausible: >=20 > 1. 2(h'12') is a different value from major-type-0 "18", in the same > way major-type-0 18 is a different value from floating "18.0". > 2. 2(h'12') is the same value as major-type-0 "18", but both are > distinct from floating "18.0". >=20 > (It would also have been plausible to declare that integral 18 is the > same value as floating 18.0, but we discussed that a while ago and > decided to keep them separate.) >=20 > I don't think the wording in > = https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#extended-ge= neric-data-models > nails down whether tags can offer alternate representations for > elements of the basic generic data model. >=20 > It's true that a tag can define a non-injective mapping into its > domain, but I don't think that by itself requires that its domain be > able to overlap the domain of the basic generic data model. >=20 > The extended generic data model *does* specify that particular tag > values in the basic generic data model are equal to other values in > the extended generic data model, but in that case the identified > values have the same encoding, so I don't think it helps much in > deciding whether they can be equal to a value in the basic generic > data model. >=20 > My preference is to follow the decision we made to distinguish > integers from floating point, and also distinguish bignums from > primitives. However, if we decide not to do that, we need to remove > the sentence in > https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#bignums > saying "In the generic data model, bignum values are not equal to > integers from the basic data model" and the sentence in > = https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#fractions > saying "As with bignums, values of different types are not equal in > the generic data model." >=20 > Jeffrey >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Jan 15 13:26:34 2020 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 C580A12097F; Wed, 15 Jan 2020 13:26:32 -0800 (PST) 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_HELO_NONE=0.001, 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 JQZbJ3aLy_C1; Wed, 15 Jan 2020 13:26:27 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A6F1209CB; Wed, 15 Jan 2020 13:26:27 -0800 (PST) Received: from [192.168.217.119] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47ygPF5R4bzygG; Wed, 15 Jan 2020 22:26:25 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: Date: Wed, 15 Jan 2020 22:26:25 +0100 Cc: Jeffrey Yasskin , "draft-ietf-cbor-7049bis@ietf.org" , Francesca Palombini , "cbor-chairs@ietf.org" , "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 600816385.263083-a3ccdb80545423b363f7de12684b0f56 Content-Transfer-Encoding: quoted-printable Message-Id: <334EE56C-6140-47D6-BB58-49A53184E847@tzi.org> References: <293AFF31-D0EF-45D6-9B9D-E8136481C404@ericsson.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Cbor] =?utf-8?q?Bignums_and_the_generic_data_models_=28Re=3A_?= =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-7049bis-09=29?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 21:26:33 -0000 Hi Laurence, The juicy bit was your last paragraph: > I don=E2=80=99t think anyone is going to send smaller integer values = as the bignum type (some integer values like 0xffffff encode smaller as = a bignum type than they would as type 0 and 1, but I don=E2=80=99t think = we want to encourage that).=20 Exactly. By making the basic integer the preferred serialization, we = make sure that bignums only occur where they are actually needed. That = is a strong reason to keep bignums in the same space as basic integers = and to make basic integers, when they fit, the preferred serialization = for a single integer domain. On 2020-01-15, at 22:00, Laurence Lundblade = wrote: >=20 > I=E2=80=99m in favor of bignums being quite separate: > - There are very very few use cases for them, many fewer than floating = point, as we just don=E2=80=99t need the the range and the precision at = the same time That depends a lot on the application. If we hadn=E2=80=99t provided bignums as a catch-all, I=E2=80=99m sure = we would already have activated ai=3D30 for 128-bit integers. With = bignums, we probably will never need that (we can still make that step = if we really have to). Bignums are the =E2=80=9Cdesign for decades=E2=80=9D relief for limiting = basic integers to 64 bits. > - CPUs and programming languages don=E2=80=99t generally or = generically support them =E2=80=94 if you are writing code for bignums = you are writing very specific code Again, that depends a lot on your application. > For example, I don=E2=80=99t think it would be useful for a generic = decoder to convert bignums less than 0xffffffff to uint32_t and those = larger than that to a byte array when returned to the caller. I would expect the generic decoder to decode a bignum as an integer in = the representations provided by the platform (*), just as with basic = integers. Now if the platform doesn=E2=80=99t have such representations, handing = up the tag (for plus/minus) and the byte string is exactly what I would = recommend a generic decoder to do. Not being able to decode 2(h=E2=80=9912=E2=80=99) as 18 is somewhat = equivalent to not being able to decode 0x1B0000000000000012 as a 32-bit = integer on a 32-bit platform =E2=80=94 not recommended, but an option = that CBOR gives to a generic decoder (both 2(h=E2=80=9912=E2=80=99) and = 0x1B0000000000000012 are not in preferred encoding). > Bignum spelling auto correct: big numb lignum bingo bigness! My Mac has quickly adapted: bignum (look, ma, no autocorrect!). Gr=C3=BC=C3=9Fe, Carsten (*) Popular platforms that don=E2=80=99t have arbitrary limits on = integer sizes include: Common Lisp, Erlang (of WhatsApp fame), Haskell, = Prolog, Python, Racket, Ruby, TCL. Other platforms such as C#, D, Go, Java, JavaScript, Julia, OCaml = provide standard libraries for handling unrestricted integers. For = other languages, there are multiple libraries available to get these, = e.g., for C/C++ you can find Boost, GMP, mbedTLS, OpenSSL. From nobody Tue Jan 21 03:14:51 2020 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 C10251200DE for ; Tue, 21 Jan 2020 03:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 btGAe2FD_8iy for ; Tue, 21 Jan 2020 03:14:44 -0800 (PST) Received: from b-painless.mh.aa.net.uk (b-painless.mh.aa.net.uk [IPv6:2001:8b0:0:30::52]) (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 1DD281200C1 for ; Tue, 21 Jan 2020 03:14:44 -0800 (PST) Received: from a-webmail.mh.aa.net.uk ([2001:8b0:0:30::75] helo=webmail.aa.net.uk) by b-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1itrUY-0004FB-QT for cbor@ietf.org; Tue, 21 Jan 2020 11:14:42 +0000 Received: from 130.14-255-62.static.virginmediabusiness.co.uk ([62.255.14.130]) by webmail.aa.net.uk with HTTP (HTTP/1.1 POST); Tue, 21 Jan 2020 11:14:39 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 Jan 2020 11:14:39 +0000 From: Kio Smallwood To: cbor@ietf.org Message-ID: <8eefb11ba6e49f7f19fd645d11d47a7f@mothers-arms.co.uk> X-Sender: kio@mothers-arms.co.uk User-Agent: Roundcube Webmail/1.3.8 Archived-At: Subject: [Cbor] Request for IANA registry addition for cbor tag X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 11:14:50 -0000 Hi CBOR list, I'd like to register the following tag for representing key-value maps where the order of keys is significant and must be passed through encode/decode steps without re-ordering: Requesting tag #272 Data item: array Semantics: Ordered Map Point of contact: kio.smallwood@flexitricity.com Description of semantics (URL): https://github.com/Sekenre/cbor-ordered-map-spec/blob/master/CBOR_Ordered_Map.md Thanks! From nobody Tue Jan 21 03:27:02 2020 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 5AE57120045 for ; Tue, 21 Jan 2020 03:27:00 -0800 (PST) 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, SPF_HELO_NONE=0.001, 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 COeGAaUNBdlc for ; Tue, 21 Jan 2020 03:26:55 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BAF1200F9 for ; Tue, 21 Jan 2020 03:26:55 -0800 (PST) Received: from sev.informatik.uni-bremen.de (sev.informatik.uni-bremen.de [134.102.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4825pj4Zhfzyrt; Tue, 21 Jan 2020 12:26:53 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: <8eefb11ba6e49f7f19fd645d11d47a7f@mothers-arms.co.uk> Date: Tue, 21 Jan 2020 12:26:53 +0100 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 601298813.031243-3e2c816d5177cb75cf6ce836076fec12 Content-Transfer-Encoding: quoted-printable Message-Id: <75E3B32F-CEF8-4338-917D-2264006287FF@tzi.org> References: <8eefb11ba6e49f7f19fd645d11d47a7f@mothers-arms.co.uk> To: Kio Smallwood X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Cbor] Request for IANA registry addition for cbor tag X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 11:27:01 -0000 Hi Kio, overall, your registration request looks good to me. (Nit: The way you are using single quotes in your diagnostic notation = triggers appendix G.2 of RFC 8610 [0], which apparently is not what you = want.) In the editorial revision of RFC 7049 that we are creating right now = [1], we are moving away from the concept of a strict decoder; instead we = are identifying the specific checking tasks in more detail (here: map = validity [2]). Thank you for also bringing this to the WG. A lot of people have been suggesting one or another form of ordered map = (including ordered multimaps, which would remove the need for avoiding = duplicate keys). Maybe we can have a short discussion if the = registration of this kind of ordered maps is a good reason to complete = registration of related kinds. Gr=C3=BC=C3=9Fe, Carsten [0]: https://tools.ietf.org/html/rfc8610#appendix-G.2 [1]: https://github.com/cbor-wg/CBORbis [2]: = https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#rfc.section= .5.3.1 > On 2020-01-21, at 12:14, Kio Smallwood wrote: >=20 > Hi CBOR list, >=20 > I'd like to register the following tag for representing key-value maps = where the order of keys is significant and must be passed through = encode/decode steps without re-ordering: >=20 >=20 > Requesting tag #272 > Data item: array > Semantics: Ordered Map > Point of contact: kio.smallwood@flexitricity.com > Description of semantics (URL): = https://github.com/Sekenre/cbor-ordered-map-spec/blob/master/CBOR_Ordered_= Map.md >=20 >=20 > Thanks! >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Tue Jan 21 03:59:33 2020 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 936751200F5 for ; Tue, 21 Jan 2020 03:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 tnGfb0gbRsTT for ; Tue, 21 Jan 2020 03:59:27 -0800 (PST) Received: from b-painless.mh.aa.net.uk (b-painless.mh.aa.net.uk [IPv6:2001:8b0:0:30::52]) (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 EC51A1200F4 for ; Tue, 21 Jan 2020 03:59:26 -0800 (PST) Received: from a-webmail.mh.aa.net.uk ([2001:8b0:0:30::75] helo=webmail.aa.net.uk) by b-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1itsBp-00060c-E7; Tue, 21 Jan 2020 11:59:25 +0000 Received: from 130.14-255-62.static.virginmediabusiness.co.uk ([62.255.14.130]) by webmail.aa.net.uk with HTTP (HTTP/1.1 POST); Tue, 21 Jan 2020 11:59:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 21 Jan 2020 11:59:19 +0000 From: Kio Smallwood To: Carsten Bormann Cc: cbor@ietf.org In-Reply-To: <75E3B32F-CEF8-4338-917D-2264006287FF@tzi.org> References: <8eefb11ba6e49f7f19fd645d11d47a7f@mothers-arms.co.uk> <75E3B32F-CEF8-4338-917D-2264006287FF@tzi.org> Message-ID: X-Sender: kio@mothers-arms.co.uk User-Agent: Roundcube Webmail/1.3.8 Archived-At: Subject: Re: [Cbor] Request for IANA registry addition for cbor tag X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 11:59:32 -0000 Hi Carsten, Thanks I've update the diagnostic notation. I've never looked at multimaps (Python replaces values with duplicate keys in it's native dict so it's never come up for us) Cheers, Kio On 2020-01-21 11:26, Carsten Bormann wrote: > Hi Kio, > > overall, your registration request looks good to me. > (Nit: The way you are using single quotes in your diagnostic notation > triggers appendix G.2 of RFC 8610 [0], which apparently is not what you > want.) > In the editorial revision of RFC 7049 that we are creating right now > [1], we are moving away from the concept of a strict decoder; instead > we are identifying the specific checking tasks in more detail (here: > map validity [2]). > > Thank you for also bringing this to the WG. > A lot of people have been suggesting one or another form of ordered map > (including ordered multimaps, which would remove the need for avoiding > duplicate keys). Maybe we can have a short discussion if the > registration of this kind of ordered maps is a good reason to complete > registration of related kinds. > > Grüße, Carsten > > [0]: https://tools.ietf.org/html/rfc8610#appendix-G.2 > [1]: https://github.com/cbor-wg/CBORbis > [2]: > https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#rfc.section.5.3.1 > >> On 2020-01-21, at 12:14, Kio Smallwood wrote: >> >> Hi CBOR list, >> >> I'd like to register the following tag for representing key-value maps >> where the order of keys is significant and must be passed through >> encode/decode steps without re-ordering: >> >> Requesting tag #272 >> Data item: array >> Semantics: Ordered Map >> Point of contact: kio.smallwood@flexitricity.com >> Description of semantics (URL): >> https://github.com/Sekenre/cbor-ordered-map-spec/blob/master/CBOR_Ordered_Map.md >> >> Thanks! >> >> _______________________________________________ >> 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 From nobody Tue Jan 21 09:58:49 2020 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 C2184120A69 for ; Tue, 21 Jan 2020 09:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 3mtKZXGHrrms for ; Tue, 21 Jan 2020 09:58:43 -0800 (PST) Received: from p3plsmtpa11-08.prod.phx3.secureserver.net (p3plsmtpa11-08.prod.phx3.secureserver.net [68.178.252.109]) (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 1517D120A5D for ; Tue, 21 Jan 2020 09:58:43 -0800 (PST) Received: from [192.168.1.76] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id txnViNgNGfcRItxnViq7b5; Tue, 21 Jan 2020 10:58:41 -0700 From: Laurence Lundblade Message-Id: <644EE647-CC60-4F4C-AE4A-94B511E9597F@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FB5854B9-A90A-4247-9661-34F3457E4BC0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 21 Jan 2020 09:58:40 -0800 In-Reply-To: <75E3B32F-CEF8-4338-917D-2264006287FF@tzi.org> Cc: Kio Smallwood , cbor@ietf.org To: Carsten Bormann References: <8eefb11ba6e49f7f19fd645d11d47a7f@mothers-arms.co.uk> <75E3B32F-CEF8-4338-917D-2264006287FF@tzi.org> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfJUkjbIfRVjSGxVd+L6EWwMZYRZWGoD7DfWgIpLCpWlaJzVOdUvtHLjA5Ub6OBtKMH5r22dkeVKxtVJgApdxfsWfCz/dp9+UXlulO4lQ6ihpcv071BC/ TSexzzsGdwLLjXfYE/OUszmHKtg8OTZyh0flMCJCFSNngABY58IrE9BHWcRKLXMLhijkBLTOTAs1FvPD13w8C/BR+aahQ8d66p56fXMvUqE9JhRvBeLtzI/Z Archived-At: Subject: Re: [Cbor] Request for IANA registry addition for cbor tag X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 17:58:48 -0000 --Apple-Mail=_FB5854B9-A90A-4247-9661-34F3457E4BC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here=E2=80=99s some decoders types in relation to this tag: 1) It recognizes the tag, supports it and does the right thing. 2) It recognizes the tag, knows it can=E2=80=99t do what is required and = errors out. For this decoder this type is invalid. 3) It doesn=E2=80=99t recognizes the tag and happens to do the wrong = thing. That is perfectly OK. 4) It doesn=E2=80=99t recognize the tag and happens to do the right = thing. So anyone using this tag really needs to be sure they are using a = decoder of type 1. Decoder types 3 and 4 are really the same in that = there is no way to know which one you=E2=80=99ve got. I don=E2=80=99t think we want some sort of implication that decoder type = 3 is defective creating a situation where all decoders are forced to = support this. I think this should be spelled out in the description of this tag. LL > On Jan 21, 2020, at 3:26 AM, Carsten Bormann wrote: >=20 > Hi Kio, >=20 > overall, your registration request looks good to me. > (Nit: The way you are using single quotes in your diagnostic notation = triggers appendix G.2 of RFC 8610 [0], which apparently is not what you = want.) > In the editorial revision of RFC 7049 that we are creating right now = [1], we are moving away from the concept of a strict decoder; instead we = are identifying the specific checking tasks in more detail (here: map = validity [2]). >=20 > Thank you for also bringing this to the WG. > A lot of people have been suggesting one or another form of ordered = map (including ordered multimaps, which would remove the need for = avoiding duplicate keys). Maybe we can have a short discussion if the = registration of this kind of ordered maps is a good reason to complete = registration of related kinds. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > [0]: https://tools.ietf.org/html/rfc8610#appendix-G.2 > [1]: https://github.com/cbor-wg/CBORbis > [2]: = https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#rfc.section= .5.3.1 >=20 >> On 2020-01-21, at 12:14, Kio Smallwood = wrote: >>=20 >> Hi CBOR list, >>=20 >> I'd like to register the following tag for representing key-value = maps where the order of keys is significant and must be passed through = encode/decode steps without re-ordering: >>=20 >>=20 >> Requesting tag #272 >> Data item: array >> Semantics: Ordered Map >> Point of contact: kio.smallwood@flexitricity.com >> Description of semantics (URL): = https://github.com/Sekenre/cbor-ordered-map-spec/blob/master/CBOR_Ordered_= Map.md >>=20 >>=20 >> Thanks! >>=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=_FB5854B9-A90A-4247-9661-34F3457E4BC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Here=E2=80=99s some decoders types in relation to this = tag:

1) It recognizes the = tag, supports it and does the right thing.

2) It recognizes the tag, knows it can=E2=80=99t = do what is required and errors out. For this decoder this type is = invalid.

3) It doesn=E2=80=99t = recognizes the tag and happens to do the wrong thing. That is perfectly = OK.

4) It doesn=E2=80=99t recognize = the tag and happens to do the right thing.

So anyone using this tag really needs to be sure = they are using a decoder of type 1. Decoder types 3 and 4 are really the = same in that there is no way to know which one you=E2=80=99ve = got.

I don=E2=80=99t think we want = some sort of implication that decoder type 3 is defective creating a = situation where all decoders are forced to support this.

I think this should be spelled out in the = description of this tag.

LL



On Jan 21, 2020, at 3:26 AM, Carsten Bormann = <cabo@tzi.org> = wrote:

Hi Kio,

overall, your = registration request looks good to me.
(Nit: The way you = are using single quotes in your diagnostic notation triggers appendix = G.2 of RFC 8610 [0], which apparently is not what you want.)
In the editorial revision of RFC 7049 that we are creating = right now [1], we are moving away from the concept of a strict decoder; = instead we are identifying the specific checking tasks in more detail = (here: map validity [2]).

Thank you for = also bringing this to the WG.
A lot of people have been = suggesting one or another form of ordered map (including ordered = multimaps, which would remove the need for avoiding duplicate keys). =  Maybe we can have a short discussion if the registration of this = kind of ordered maps is a good reason to complete registration of = related kinds.

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

[0]: https://tools.ietf.org/html/rfc8610#appendix-G.2
[1]: https://github.com/cbor-wg/CBORbis
[2]: https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#= rfc.section.5.3.1

On 2020-01-21, at 12:14, Kio Smallwood <kio@mothers-arms.co.uk> wrote:

Hi CBOR list,

I'd like to = register the following tag for representing key-value maps where the = order of keys is significant and must be passed through encode/decode = steps without re-ordering:


Requesting tag #272
Data item: array
Semantics: Ordered Map
Point of contact: kio.smallwood@flexitricity.com
Description = of semantics (URL): https://github.com/Sekenre/cbor-ordered-map-spec/blob/master/CB= OR_Ordered_Map.md


Thanks!

_______________________________________________
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=_FB5854B9-A90A-4247-9661-34F3457E4BC0-- From nobody Tue Jan 21 12:02:57 2020 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 953B7120072 for ; Tue, 21 Jan 2020 12:02:55 -0800 (PST) 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, SPF_HELO_NONE=0.001, 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 z_zpWr6hZfrg for ; Tue, 21 Jan 2020 12:02:50 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA9C120824 for ; Tue, 21 Jan 2020 12:02:44 -0800 (PST) Received: from [192.168.217.119] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 482KFt2vwKz16Hn; Tue, 21 Jan 2020 21:02:42 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: <644EE647-CC60-4F4C-AE4A-94B511E9597F@island-resort.com> Date: Tue, 21 Jan 2020 21:02:41 +0100 Cc: cbor@ietf.org, Kio Smallwood X-Mao-Original-Outgoing-Id: 601329761.76366-7594066cee1ea648a448e16b3270c8a5 Content-Transfer-Encoding: quoted-printable Message-Id: <8EB0DDFD-5AF1-4010-84AF-55F6E21688B2@tzi.org> References: <8eefb11ba6e49f7f19fd645d11d47a7f@mothers-arms.co.uk> <75E3B32F-CEF8-4338-917D-2264006287FF@tzi.org> <644EE647-CC60-4F4C-AE4A-94B511E9597F@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Cbor] Request for IANA registry addition for cbor tag X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 20:02:56 -0000 Hi Laurence, I=E2=80=99m not sure I follow. Decoders either implement a tag or they = don=E2=80=99t. > On 2020-01-21, at 18:58, Laurence Lundblade = wrote: >=20 > Here=E2=80=99s some decoders types in relation to this tag: >=20 > 1) It recognizes the tag, supports it and does the right thing. That would be a decoder that implements the tag. > 2) It recognizes the tag, knows it can=E2=80=99t do what is required = and errors out. For this decoder this type is invalid. That would be a decoder that fundamentally doesn=E2=80=99t accept this = tag. Not particularly useful. What does =E2=80=9Ccan=E2=80=99t do what is required=E2=80=9D mean? > 3) It doesn=E2=80=99t recognizes the tag and happens to do the wrong = thing. That is perfectly OK. How would that be OK? But maybe I don=E2=80=99t understand that =E2=80=9C= do the wrong thing=E2=80=9D means. > 4) It doesn=E2=80=99t recognize the tag and happens to do the right = thing. Which would be to present the tag number and the tag content to the = application. > So anyone using this tag really needs to be sure they are using a = decoder of type 1. Decoder types 3 and 4 are really the same in that = there is no way to know which one you=E2=80=99ve got. >=20 > I don=E2=80=99t think we want some sort of implication that decoder = type 3 is defective creating a situation where all decoders are forced = to support this. Now I=E2=80=99m completely lost about your type 3. =E2=80=9CDo the = wrong thing=E2=80=9D and =E2=80=9COK=E2=80=9D don=E2=80=99t mix that = well for me=E2=80=A6 > I think this should be spelled out in the description of this tag. I think 7049bis might need some more text about handling unimplemented = tags in decoders. Right now, it says: Implementations receiving an unknown tag number can choose to simply = ignore it or to process it as an unknown tag number wrapping the enclosed = data item. The IANA registry in {{ianatags}} is the appropriate way to But it also says: Generic encoders provide an application interface that allows the application to specify any well-formed value, including simple values and tags unknown to the encoder. So a generic encoder would not have problems with unimplemented tags; = but other (e.g., task-specific) implementations might. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jan 21 17:05:52 2020 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 5D3421200C5 for ; Tue, 21 Jan 2020 17:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 eRG4q_pxw-V0 for ; Tue, 21 Jan 2020 17:05:49 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1F11200C4 for ; Tue, 21 Jan 2020 17:05:49 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 21 Jan 2020 17:05:38 -0800 From: Jim Schaad To: 'Carsten Bormann' , 'Laurence Lundblade' CC: , 'Kio Smallwood' References: <8eefb11ba6e49f7f19fd645d11d47a7f@mothers-arms.co.uk> <75E3B32F-CEF8-4338-917D-2264006287FF@tzi.org> <644EE647-CC60-4F4C-AE4A-94B511E9597F@island-resort.com> <8EB0DDFD-5AF1-4010-84AF-55F6E21688B2@tzi.org> In-Reply-To: <8EB0DDFD-5AF1-4010-84AF-55F6E21688B2@tzi.org> Date: Tue, 21 Jan 2020 17:05:36 -0800 Message-ID: <000001d5d0c0$100a0cd0$301e2670$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQMncCY59d2Xg3V/x0PcOAKJW+BM4QIBEeFaAY+ltsEBZHBqAqUq9UvQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Request for IANA registry addition for cbor tag X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 01:05:51 -0000 -----Original Message----- From: CBOR On Behalf Of Carsten Bormann Sent: Tuesday, January 21, 2020 12:03 PM To: Laurence Lundblade Cc: cbor@ietf.org; Kio Smallwood Subject: Re: [Cbor] Request for IANA registry addition for cbor tag Hi Laurence, I=E2=80=99m not sure I follow. Decoders either implement a tag or they = don=E2=80=99t. > On 2020-01-21, at 18:58, Laurence Lundblade = wrote: >=20 > Here=E2=80=99s some decoders types in relation to this tag: >=20 > 1) It recognizes the tag, supports it and does the right thing. That would be a decoder that implements the tag. > 2) It recognizes the tag, knows it can=E2=80=99t do what is required = and errors out. For this decoder this type is invalid. That would be a decoder that fundamentally doesn=E2=80=99t accept this = tag. Not particularly useful. What does =E2=80=9Ccan=E2=80=99t do what is required=E2=80=9D mean? > 3) It doesn=E2=80=99t recognizes the tag and happens to do the wrong = thing. That is perfectly OK. How would that be OK? But maybe I don=E2=80=99t understand that = =E2=80=9Cdo the wrong thing=E2=80=9D means. > 4) It doesn=E2=80=99t recognize the tag and happens to do the right = thing. Which would be to present the tag number and the tag content to the = application. > So anyone using this tag really needs to be sure they are using a = decoder of type 1. Decoder types 3 and 4 are really the same in that = there is no way to know which one you=E2=80=99ve got. >=20 > I don=E2=80=99t think we want some sort of implication that decoder = type 3 is defective creating a situation where all decoders are forced = to support this. Now I=E2=80=99m completely lost about your type 3. =E2=80=9CDo the = wrong thing=E2=80=9D and =E2=80=9COK=E2=80=9D don=E2=80=99t mix that = well for me=E2=80=A6 > I think this should be spelled out in the description of this tag. I think 7049bis might need some more text about handling unimplemented = tags in decoders. Right now, it says: Implementations receiving an unknown tag number can choose to simply = ignore it or to process it as an unknown tag number wrapping the enclosed = data item. The IANA registry in {{ianatags}} is the appropriate way to [JLS] Carsten, I would argue that the decode that I use obeys the text above and would = fall into the category of decode that is going to do one of "bad" things = Laurence discussed above. It will return a tree with the following=20 [ ]+ However, depending on what the final language that the group comes up = with for the duplicate tag language, it will either take the first, the = last or throw and exception when a duplicate tag is found. That says = that it can not do the first option (hey dup tags are not done will for = hash based maps) and thus will either do 3 or totally fail. I would not really be a huge fan of this tag. If this is really what = you want to do then an array seems to me to be a better answer. Jim But it also says: Generic encoders provide an application interface that allows the = application to specify any well-formed value, including simple values = and tags unknown to the encoder. So a generic encoder would not have problems with unimplemented tags; = but other (e.g., task-specific) implementations might. Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ CBOR mailing list CBOR@ietf.org https://www.ietf.org/mailman/listinfo/cbor From nobody Tue Jan 21 18:25:35 2020 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 7249C1200C3 for ; Tue, 21 Jan 2020 18:25:34 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 dlJsgaH80bkb for ; Tue, 21 Jan 2020 18:25:32 -0800 (PST) Received: from p3plsmtpa11-07.prod.phx3.secureserver.net (p3plsmtpa11-07.prod.phx3.secureserver.net [68.178.252.108]) (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 2F1B0120013 for ; Tue, 21 Jan 2020 18:25:32 -0800 (PST) Received: from [192.168.1.76] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id u5hyirqXU9TSnu5hziW03Y; Tue, 21 Jan 2020 19:25:31 -0700 From: Laurence Lundblade Message-Id: <0A10ACB1-A2A2-450E-9394-D92B575F5AC0@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_40442990-8A6E-451C-A1CB-EC19D64E86C8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 21 Jan 2020 18:25:30 -0800 In-Reply-To: <000001d5d0c0$100a0cd0$301e2670$@augustcellars.com> Cc: Carsten Bormann , cbor@ietf.org, Kio Smallwood To: Jim Schaad References: <8eefb11ba6e49f7f19fd645d11d47a7f@mothers-arms.co.uk> <75E3B32F-CEF8-4338-917D-2264006287FF@tzi.org> <644EE647-CC60-4F4C-AE4A-94B511E9597F@island-resort.com> <8EB0DDFD-5AF1-4010-84AF-55F6E21688B2@tzi.org> <000001d5d0c0$100a0cd0$301e2670$@augustcellars.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfAuiRFkwzq08EeaYyAkMrtqSEgNw8RYXS24mIJl3OnIoaCe/2HbtObhSz1O7hcbwWfk+EuE9Ufv3yIJQQbiQauOv2iOW+Tqy7UQKe7rV/awmXZPmzYf8 jxPX1XbLEZE1oNvWy8TjfxGLEUXJcrIcXKw0ulqPY1yZX6cgsZw2bbOOy+WMb/I1RHVTQZhi7QN25MiPYmzoDFq1D+v7HufGSob9yr5shdTV0ULpkVoveCWQ EfZPedYNUAjrMgQ110l3Lw== Archived-At: Subject: Re: [Cbor] Request for IANA registry addition for cbor tag X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 02:25:34 -0000 --Apple-Mail=_40442990-8A6E-451C-A1CB-EC19D64E86C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My bad. I read the proposal wrong. Let me try again. 1) Decoder recognizes and supports the tag. A nice ordered map will be = returned to the caller. 2) Decoder knows nothing of the tag. A tag plus an array (not a map) = will be returned to the caller in order. 3) The programing environment can=E2=80=99t support returning an ordered = map and the implementor considers doing something about the tag 3a) The mellow implementor opts for 2). 3b) The knows-what-is-best implementor considers the input invalid and = returns an error. 3c) The lets-all-get-along implementor offers an option to behave as 2) = or 3b). This tag is really aimed at type 1) so it is sort of the same, if you = use this tag, be sure the decoder supports it. Same with just about any = tag. Seems OK. Separately... So it appears to me that no where does it say =E2=80=9Carrays are = ordered=E2=80=9D in 7049 or CBORbis. This seems like an omission that = should be fixed. They are ordered aren=E2=80=99t they? COSE would break = if they weren=E2=80=99t. Also, I noticed recently that JWT requires either duplicate detection or = take-last. CWT is silent on this including inheriting this behavior from = JWT. LL > On Jan 21, 2020, at 5:05 PM, Jim Schaad = wrote: >=20 >=20 >=20 > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Tuesday, January 21, 2020 12:03 PM > To: Laurence Lundblade > Cc: cbor@ietf.org; Kio Smallwood > Subject: Re: [Cbor] Request for IANA registry addition for cbor tag >=20 > Hi Laurence, >=20 > I=E2=80=99m not sure I follow. Decoders either implement a tag or = they don=E2=80=99t. >=20 >> On 2020-01-21, at 18:58, Laurence Lundblade = wrote: >>=20 >> Here=E2=80=99s some decoders types in relation to this tag: >>=20 >> 1) It recognizes the tag, supports it and does the right thing. >=20 > That would be a decoder that implements the tag. >=20 >> 2) It recognizes the tag, knows it can=E2=80=99t do what is required = and errors out. For this decoder this type is invalid. >=20 > That would be a decoder that fundamentally doesn=E2=80=99t accept this = tag. > Not particularly useful. > What does =E2=80=9Ccan=E2=80=99t do what is required=E2=80=9D mean? >=20 >> 3) It doesn=E2=80=99t recognizes the tag and happens to do the wrong = thing. That is perfectly OK. >=20 > How would that be OK? But maybe I don=E2=80=99t understand that =E2=80=9C= do the wrong thing=E2=80=9D means. >=20 >> 4) It doesn=E2=80=99t recognize the tag and happens to do the right = thing. >=20 > Which would be to present the tag number and the tag content to the = application. >=20 >> So anyone using this tag really needs to be sure they are using a = decoder of type 1. Decoder types 3 and 4 are really the same in that = there is no way to know which one you=E2=80=99ve got. >>=20 >> I don=E2=80=99t think we want some sort of implication that decoder = type 3 is defective creating a situation where all decoders are forced = to support this. >=20 > Now I=E2=80=99m completely lost about your type 3. =E2=80=9CDo the = wrong thing=E2=80=9D and =E2=80=9COK=E2=80=9D don=E2=80=99t mix that = well for me=E2=80=A6 >=20 >> I think this should be spelled out in the description of this tag. >=20 > I think 7049bis might need some more text about handling unimplemented = tags in decoders. >=20 > Right now, it says: > Implementations receiving an unknown tag number can choose to simply = ignore > it or to process it as an unknown tag number wrapping the enclosed = data > item. The IANA registry in {{ianatags}} is the appropriate way to >=20 > [JLS] > Carsten, >=20 > I would argue that the decode that I use obeys the text above and = would fall into the category of decode that is going to do one of "bad" = things Laurence discussed above. It will return a tree with the = following=20 > > > [ ]+ >=20 > However, depending on what the final language that the group comes up = with for the duplicate tag language, it will either take the first, the = last or throw and exception when a duplicate tag is found. That says = that it can not do the first option (hey dup tags are not done will for = hash based maps) and thus will either do 3 or totally fail. >=20 > I would not really be a huge fan of this tag. If this is really what = you want to do then an array seems to me to be a better answer. >=20 > Jim >=20 >=20 > But it also says: > Generic encoders provide an application interface that allows the = application to specify any well-formed value, including simple values = and tags unknown to the encoder. >=20 > So a generic encoder would not have problems with unimplemented tags; = but other (e.g., task-specific) implementations might. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 >=20 --Apple-Mail=_40442990-8A6E-451C-A1CB-EC19D64E86C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My = bad. I read the proposal wrong.  Let me try again.
1) Decoder recognizes and = supports the tag. A nice ordered map will be returned to the = caller.

2) = Decoder knows nothing of the tag. A tag plus an array (not a map) will = be returned to the caller in order.

3) The programing environment can=E2=80=99= t support returning an ordered map and the implementor considers doing = something about the tag

3a) The = mellow implementor opts for 2).

3b) The knows-what-is-best implementor considers the = input invalid and returns an error.

3c) = The lets-all-get-along implementor offers an option to behave as 2) or = 3b).

This tag is really aimed at type 1) so = it is sort of the same, if you use this tag, be sure the decoder = supports it. Same with just about any tag. Seems OK.


Separately...

So it appears to me that no where does it say =E2=80=9Carrays = are ordered=E2=80=9D in 7049 or CBORbis. This seems like an omission = that should be fixed. They are ordered aren=E2=80=99t they? COSE would = break if they weren=E2=80=99t.

Also, I noticed recently that JWT = requires either duplicate detection or take-last. CWT is silent on this = including inheriting this behavior from JWT.

LL



On Jan 21, 2020, at 5:05 PM, Jim Schaad = <ietf@augustcellars.com> wrote:



-----Original Message-----
From: = CBOR <cbor-bounces@ietf.org> On Behalf Of Carsten Bormann
Sent: Tuesday, January 21, 2020 12:03 PM
To: = Laurence Lundblade <lgl@island-resort.com>
Cc: cbor@ietf.org; Kio = Smallwood <kio@mothers-arms.co.uk>
Subject: Re: = [Cbor] Request for IANA registry addition for cbor tag

Hi Laurence,

I=E2=80=99m not = sure I follow.  Decoders either implement a tag or they don=E2=80=99t= .

On = 2020-01-21, at 18:58, Laurence Lundblade <lgl@island-resort.com> wrote:

Here=E2=80=99s some decoders types in relation to this = tag:

1) It recognizes the tag, supports it = and does the right thing.

That = would be a decoder that implements the tag.

2) It recognizes the = tag, knows it can=E2=80=99t do what is required and errors out. For this = decoder this type is invalid.

That would be a decoder that fundamentally doesn=E2=80=99t = accept this tag.
Not particularly useful.
What= does =E2=80=9Ccan=E2=80=99t do what is required=E2=80=9D mean?

3) It = doesn=E2=80=99t recognizes the tag and happens to do the wrong thing. = That is perfectly OK.

How = would that be OK?  But maybe I don=E2=80=99t understand that =E2=80=9C= do the wrong thing=E2=80=9D means.

4) It doesn=E2=80=99t = recognize the tag and happens to do the right thing.

Which would be to present the tag = number and the tag content to the application.

So anyone using this tag = really needs to be sure they are using a decoder of type 1. Decoder = types 3 and 4 are really the same in that there is no way to know which = one you=E2=80=99ve got.

I don=E2=80=99t = think we want some sort of implication that decoder type 3 is defective = creating a situation where all decoders are forced to support this.

Now I=E2=80=99m completely lost = about your type 3.  =E2=80=9CDo the wrong thing=E2=80=9D and = =E2=80=9COK=E2=80=9D don=E2=80=99t mix that well for me=E2=80=A6

I think = this should be spelled out in the description of this tag.

I think 7049bis might need some = more text about handling unimplemented tags in decoders.
Right now, it says:
 Implementations = receiving an unknown tag number can choose to simply ignore
=  it or to process it as an unknown tag number wrapping the = enclosed data
 item. The IANA registry in = {{ianatags}} is the appropriate way to

[JLS]
Carsten,

I = would argue that the decode that I use obeys the text above and would = fall into the category of decode that is going to do one of "bad" things = Laurence discussed above.  It will return a tree with the following =
<TAG  new tag number>
=   <MAP>
=       [<key> <value>]+

However, depending on what the final language = that the group comes up with for the duplicate tag language, it will = either take the first, the last or throw and exception when a duplicate = tag is found.  That says that it can not do the first option (hey = dup tags are not done will for hash based maps) and thus will either do = 3  or totally fail.

I would not really = be a huge fan of this tag.  If this is really what you want to do = then an array seems to me to be a better answer.

Jim


But it also = says:
Generic encoders provide an application interface = that allows the application to specify any well-formed value, including = simple values and tags unknown to the encoder.

So a generic encoder would not have problems with = unimplemented tags; but other (e.g., task-specific) implementations = might.

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

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



= --Apple-Mail=_40442990-8A6E-451C-A1CB-EC19D64E86C8-- From nobody Tue Jan 21 18:31:34 2020 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 5E3361200C3 for ; Tue, 21 Jan 2020 18:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=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 osyw5QLvQoJv for ; Tue, 21 Jan 2020 18:31:32 -0800 (PST) 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 BF15412002F for ; Tue, 21 Jan 2020 18:31:32 -0800 (PST) Received: from [10.32.60.83] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id 00M2VHe5022720 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jan 2020 19:31:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] claimed to be [10.32.60.83] From: "Paul Hoffman" To: "Laurence Lundblade" Cc: cbor@ietf.org Date: Tue, 21 Jan 2020 18:31:30 -0800 X-Mailer: MailMate (1.13.1r5671) Message-ID: <20456193-A3D8-4E36-99E4-136E132DEA09@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Cbor] On arrays X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 02:31:33 -0000 On 21 Jan 2020, at 18:25, Laurence Lundblade wrote: > So it appears to me that no where does it say “arrays are ordered” > in 7049 or CBORbis. This seems like an omission that should be fixed. > They are ordered aren’t they? COSE would break if they weren’t. The definition of array in the document is: a sequence of zero or more data items Isn't "sequence" sufficient? Is there really such a thing as an unordered sequence? --Paul Hoffman From nobody Tue Jan 21 18:45:29 2020 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 DED9B120044 for ; Tue, 21 Jan 2020 18:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 83nPG_kc5Isk for ; Tue, 21 Jan 2020 18:45:24 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25F012002F for ; Tue, 21 Jan 2020 18:45:23 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 21 Jan 2020 18:45:15 -0800 From: Jim Schaad To: 'Laurence Lundblade' CC: 'Carsten Bormann' , , 'Kio Smallwood' References: <8eefb11ba6e49f7f19fd645d11d47a7f@mothers-arms.co.uk> <75E3B32F-CEF8-4338-917D-2264006287FF@tzi.org> <644EE647-CC60-4F4C-AE4A-94B511E9597F@island-resort.com> <8EB0DDFD-5AF1-4010-84AF-55F6E21688B2@tzi.org> <000001d5d0c0$100a0cd0$301e2670$@augustcellars.com> <0A10ACB1-A2A2-450E-9394-D92B575F5AC0@island-resort.com> In-Reply-To: <0A10ACB1-A2A2-450E-9394-D92B575F5AC0@island-resort.com> Date: Tue, 21 Jan 2020 18:45:13 -0800 Message-ID: <001801d5d0cd$fabea990$f03bfcb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01D5D08A.EC9D8C70" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQMncCY59d2Xg3V/x0PcOAKJW+BM4QIBEeFaAY+ltsEBZHBqAgGqdiuBAYlmpE2lEXMt0A== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Request for IANA registry addition for cbor tag X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 02:45:28 -0000 ------=_NextPart_000_0019_01D5D08A.EC9D8C70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Laurence Lundblade =20 Sent: Tuesday, January 21, 2020 6:26 PM To: Jim Schaad Cc: Carsten Bormann ; cbor@ietf.org; Kio Smallwood = Subject: Re: [Cbor] Request for IANA registry addition for cbor tag =20 My bad. I read the proposal wrong. Let me try again. =20 1) Decoder recognizes and supports the tag. A nice ordered map will be = returned to the caller. =20 2) Decoder knows nothing of the tag. A tag plus an array (not a map) = will be returned to the caller in order. =20 3) The programing environment can=E2=80=99t support returning an ordered = map and the implementor considers doing something about the tag =20 3a) The mellow implementor opts for 2). =20 3b) The knows-what-is-best implementor considers the input invalid and = returns an error. =20 3c) The lets-all-get-along implementor offers an option to behave as 2) = or 3b). =20 This tag is really aimed at type 1) so it is sort of the same, if you = use this tag, be sure the decoder supports it. Same with just about any = tag. Seems OK. =20 =20 Separately... =20 So it appears to me that no where does it say =E2=80=9Carrays are = ordered=E2=80=9D in 7049 or CBORbis. This seems like an omission that = should be fixed. They are ordered aren=E2=80=99t they? COSE would break = if they weren=E2=80=99t. [JLS] I think that this is implicit in the definition. Everything = would break if arrays are not ordered. =20 Also, I noticed recently that JWT requires either duplicate detection or = take-last. CWT is silent on this including inheriting this behavior from = JWT. [JLS] I would actually say that CWT is going to inherit behavior from = 7049 not from JWT. =20 Jim =20 =20 LL =20 =20 On Jan 21, 2020, at 5:05 PM, Jim Schaad > wrote: =20 -----Original Message----- From: CBOR > On = Behalf Of Carsten Bormann Sent: Tuesday, January 21, 2020 12:03 PM To: Laurence Lundblade > Cc: cbor@ietf.org ; Kio Smallwood = > Subject: Re: [Cbor] Request for IANA registry addition for cbor tag Hi Laurence, I=E2=80=99m not sure I follow. Decoders either implement a tag or they = don=E2=80=99t. On 2020-01-21, at 18:58, Laurence Lundblade > wrote: Here=E2=80=99s some decoders types in relation to this tag: 1) It recognizes the tag, supports it and does the right thing. That would be a decoder that implements the tag. 2) It recognizes the tag, knows it can=E2=80=99t do what is required and = errors out. For this decoder this type is invalid. That would be a decoder that fundamentally doesn=E2=80=99t accept this = tag. Not particularly useful. What does =E2=80=9Ccan=E2=80=99t do what is required=E2=80=9D mean? 3) It doesn=E2=80=99t recognizes the tag and happens to do the wrong = thing. That is perfectly OK. How would that be OK? But maybe I don=E2=80=99t understand that = =E2=80=9Cdo the wrong thing=E2=80=9D means. 4) It doesn=E2=80=99t recognize the tag and happens to do the right = thing. Which would be to present the tag number and the tag content to the = application. So anyone using this tag really needs to be sure they are using a = decoder of type 1. Decoder types 3 and 4 are really the same in that = there is no way to know which one you=E2=80=99ve got. I don=E2=80=99t think we want some sort of implication that decoder type = 3 is defective creating a situation where all decoders are forced to = support this. Now I=E2=80=99m completely lost about your type 3. =E2=80=9CDo the = wrong thing=E2=80=9D and =E2=80=9COK=E2=80=9D don=E2=80=99t mix that = well for me=E2=80=A6 I think this should be spelled out in the description of this tag. I think 7049bis might need some more text about handling unimplemented = tags in decoders. Right now, it says: Implementations receiving an unknown tag number can choose to simply = ignore it or to process it as an unknown tag number wrapping the enclosed data item. The IANA registry in {{ianatags}} is the appropriate way to [JLS] Carsten, I would argue that the decode that I use obeys the text above and would = fall into the category of decode that is going to do one of "bad" things = Laurence discussed above. It will return a tree with the following=20 [ ]+ However, depending on what the final language that the group comes up = with for the duplicate tag language, it will either take the first, the = last or throw and exception when a duplicate tag is found. That says = that it can not do the first option (hey dup tags are not done will for = hash based maps) and thus will either do 3 or totally fail. I would not really be a huge fan of this tag. If this is really what = you want to do then an array seems to me to be a better answer. Jim But it also says: Generic encoders provide an application interface that allows the = application to specify any well-formed value, including simple values = and tags unknown to the encoder. So a generic encoder would not have problems with unimplemented tags; = but other (e.g., task-specific) implementations might. Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ CBOR mailing list CBOR@ietf.org =20 https://www.ietf.org/mailman/listinfo/cbor =20 ------=_NextPart_000_0019_01D5D08A.EC9D8C70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Laurence Lundblade = <lgl@island-resort.com>
Sent: Tuesday, January 21, 2020 = 6:26 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Carsten Bormann = <cabo@tzi.org>; cbor@ietf.org; Kio Smallwood = <kio@mothers-arms.co.uk>
Subject: Re: [Cbor] Request for = IANA registry addition for cbor tag

 

My bad. I = read the proposal wrong.  Let me try again.

 

1) Decoder recognizes and supports the tag. A nice = ordered map will be returned to the caller.

 

2) Decoder knows nothing of the tag. A tag plus an = array (not a map) will be returned to the caller in = order.

 

3) The programing environment can=E2=80=99t support = returning an ordered map and the implementor considers doing something = about the tag

 

3a) The mellow implementor opts for = 2).

 

3b) The knows-what-is-best implementor considers = the input invalid and returns an = error.

 

3c) The lets-all-get-along implementor offers an = option to behave as 2) or = 3b).

 

This tag is really aimed at type 1) so it is sort of = the same, if you use this tag, be sure the decoder supports it. Same = with just about any tag. Seems OK.

 

 

Separately...

 

So it appears to me that no where does it say = =E2=80=9Carrays are ordered=E2=80=9D in 7049 or CBORbis. This seems like = an omission that should be fixed. They are ordered aren=E2=80=99t they? = COSE would break if they weren=E2=80=99t.

[JLS]=C2=A0 I think that this is implicit in the = definition.=C2=A0 Everything would break if arrays are not = ordered.

 

Also, I noticed recently that JWT requires either = duplicate detection or take-last. CWT is silent on this including = inheriting this behavior from JWT.

[JLS] I would actually say that CWT is going to = inherit behavior from 7049 not from JWT.

 

Jim

 

 

LL

 

 



On Jan 21, 2020, at 5:05 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 



-----Original Message-----
From: CBOR = <cbor-bounces@ietf.org> On = Behalf Of Carsten Bormann
Sent: Tuesday, January 21, 2020 12:03 = PM
To: Laurence Lundblade <lgl@island-resort.com>
Cc= : cbor@ietf.org; Kio Smallwood = <kio@mothers-arms.co.uk>
= Subject: Re: [Cbor] Request for IANA registry addition for cbor = tag

Hi Laurence,

I=E2=80=99m not sure I follow. =  Decoders either implement a tag or they = don=E2=80=99t.


On = 2020-01-21, at 18:58, Laurence Lundblade <lgl@island-resort.com> = wrote:

Here=E2=80=99s some decoders types in relation to this = tag:

1) It recognizes the tag, supports it and does the right = thing.


That would be = a decoder that implements the tag.


2) = It recognizes the tag, knows it can=E2=80=99t do what is required and = errors out. For this decoder this type is = invalid.


That would = be a decoder that fundamentally doesn=E2=80=99t accept this tag.
Not = particularly useful.
What does =E2=80=9Ccan=E2=80=99t do what is = required=E2=80=9D mean?


3) = It doesn=E2=80=99t recognizes the tag and happens to do the wrong thing. = That is perfectly OK.


How would that be OK?  But maybe I = don=E2=80=99t understand that =E2=80=9Cdo the wrong thing=E2=80=9D = means.


4) = It doesn=E2=80=99t recognize the tag and happens to do the right = thing.


Which would = be to present the tag number and the tag content to the = application.


So = anyone using this tag really needs to be sure they are using a decoder = of type 1. Decoder types 3 and 4 are really the same in that there is no = way to know which one you=E2=80=99ve got.

I don=E2=80=99t think = we want some sort of implication that decoder type 3 is defective = creating a situation where all decoders are forced to support = this.


Now = I=E2=80=99m completely lost about your type 3.  =E2=80=9CDo the = wrong thing=E2=80=9D and =E2=80=9COK=E2=80=9D don=E2=80=99t mix that = well for me=E2=80=A6


I = think this should be spelled out in the description of this = tag.


I think 7049bis might need some more = text about handling unimplemented tags in decoders.

Right now, it = says:
 Implementations receiving an unknown tag number can = choose to simply ignore
 it or to process it as an unknown tag = number wrapping the enclosed data
 item. The IANA registry in = {{ianatags}} is the appropriate way to

[JLS]
Carsten,

I = would argue that the decode that I use obeys the text above and would = fall into the category of decode that is going to do one of = "bad" things Laurence discussed above.  It will return a = tree with the following
<TAG  new tag = number>
  <MAP>
     &n= bsp;[<key> <value>]+

However, depending on what the = final language that the group comes up with for the duplicate tag = language, it will either take the first, the last or throw and exception = when a duplicate tag is found.  That says that it can not do the = first option (hey dup tags are not done will for hash based maps) and = thus will either do 3  or totally fail.

I would not really = be a huge fan of this tag.  If this is really what you want to do = then an array seems to me to be a better = answer.

Jim


But it also says:
Generic encoders = provide an application interface that allows the application to specify = any well-formed value, including simple values and tags unknown to the = encoder.

So a generic encoder would not have problems with = unimplemented tags; but other (e.g., task-specific) implementations = might.

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

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

=

 

------=_NextPart_000_0019_01D5D08A.EC9D8C70-- From nobody Wed Jan 22 02:13:06 2020 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 694F1120071 for ; Wed, 22 Jan 2020 02:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 g6z7znx8fVk1 for ; Wed, 22 Jan 2020 02:12:59 -0800 (PST) Received: from a-painless.mh.aa.net.uk (a-painless.mh.aa.net.uk [IPv6:2001:8b0:0:30::51]) (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 C8E8E120043 for ; Wed, 22 Jan 2020 02:12:59 -0800 (PST) Received: from b-webmail.mh.aa.net.uk ([2001:8b0:0:30::77] helo=webmail.aa.net.uk) by a-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iuD0M-0000VK-EC; Wed, 22 Jan 2020 10:12:58 +0000 Received: from 130.14-255-62.static.virginmediabusiness.co.uk ([62.255.14.130]) by webmail.aa.net.uk with HTTP (HTTP/1.1 POST); Wed, 22 Jan 2020 10:12:18 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_0011c704e151b906bc9359ce5c11f386" Date: Wed, 22 Jan 2020 10:12:18 +0000 From: Kio Smallwood To: Carsten Bormann Cc: Laurence Lundblade , cbor@ietf.org In-Reply-To: <8EB0DDFD-5AF1-4010-84AF-55F6E21688B2@tzi.org> References: <8eefb11ba6e49f7f19fd645d11d47a7f@mothers-arms.co.uk> <75E3B32F-CEF8-4338-917D-2264006287FF@tzi.org> <644EE647-CC60-4F4C-AE4A-94B511E9597F@island-resort.com> <8EB0DDFD-5AF1-4010-84AF-55F6E21688B2@tzi.org> Message-ID: <9f5d77746511bcbd497b345348c75b85@mothers-arms.co.uk> X-Sender: kio@mothers-arms.co.uk User-Agent: Roundcube Webmail/1.3.8 Archived-At: Subject: Re: [Cbor] Request for IANA registry addition for cbor tag X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 10:13:02 -0000 --=_0011c704e151b906bc9359ce5c11f386 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Reply below; On 2020-01-21 20:02, Carsten Bormann wrote: > Hi Laurence, > > I'm not sure I follow. Decoders either implement a tag or they don't. > > > > I think 7049bis might need some more text about handling unimplemented tags in decoders. > > Right now, it says: > Implementations receiving an unknown tag number can choose to simply ignore > it or to process it as an unknown tag number wrapping the enclosed data > item. The IANA registry in {{ianatags}} is the appropriate way to > > But it also says: > Generic encoders provide an application interface that allows the > application to specify any well-formed value, including simple values > and tags unknown to the encoder. > > So a generic encoder would not have problems with unimplemented tags; but other (e.g., task-specific) implementations might. > > Grüße, Carsten I agree, As a maintainer of a generic decoder, unknown tags are passed to the calling application as a CBORTag(tag, value) [1] instance. Value is always the corresponding Python datatype to the basic CBOR datatype. This is serialized by the encoder into the same bytes, so it's round-trip safe. A more specialized decoder should raise an error if it encounters an unknown tag since that specialization implies some sort of schema that the decoder expects. I think the 7049bis should specify that a generic decoder should be able to produce objects that will be serialized identically (with the possible exception of decoding in relaxed mode, then encoding canonically) regardless of whether those objects have meaning to the application. Cheers, Kio Links: ------ [1] https://cbor2.readthedocs.io/en/latest/modules/types.html#cbor2.types.CBORTag --=_0011c704e151b906bc9359ce5c11f386 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Reply below;

On 2020-01-21 20:02, Carsten Bormann wrote:

= Hi Laurence,

I'm not sure I follow.  Decoders either impl= ement a tag or they don't.
=
<snip>
=
I think 7049bis might need some more text about handling unimplement= ed tags in decoders.

Right now, it says:
  Imp= lementations receiving an unknown tag number can choose to simply ignore   it or to process it as an unknown tag number wrapping the e= nclosed data
  item. The IANA registry in {{ianatags}} is t= he appropriate way to

But it also says:
Generic encoders= provide an application interface that allows the
application to spec= ify any well-formed value, including simple values
and tags unknown t= o the encoder.

So a generic encoder would not have problems wi= th unimplemented tags; but other (e.g., task-specific) implementations migh= t.

Grüße, Carsten

I agree,

As a maintainer of a generic decoder, unknown tags are passed to the cal= ling application as a CBORTag(tag, value) instance. Valu= e is always the corresponding Python datatype to the basic CBOR datatype. T= his is serialized by the encoder into the same bytes, so it's round-trip sa= fe.

A more specialized decoder should raise an error if it encounters an unk= nown tag since that specialization implies some sort of schema that the dec= oder expects.

I think the 7049bis should specify that a generic decoder should be able= to produce objects that will be serialized identically (with the possible = exception of decoding in relaxed mode, then encoding canonically) regardles= s of whether those objects have meaning to the application.

Cheers,

Kio

--=_0011c704e151b906bc9359ce5c11f386-- From nobody Wed Jan 29 02:52:07 2020 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 6D59E120832 for ; Wed, 29 Jan 2020 02:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_FONT_LOW_CONTRAST=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 (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8NpV-wAcEEJ for ; Wed, 29 Jan 2020 02:52:03 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30064.outbound.protection.outlook.com [40.107.3.64]) (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 0E53B120828 for ; Wed, 29 Jan 2020 02:52:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Sq1JsNLqpVTl8EgO0+hpUjpUILX5QtBTce9v1YJ6Ufhz5LEtaQyuVLY74Vz+VqT1ohZsO4aAw0wbnV8qjc1GSnqjHtRt8VJ8SzcqWThujOsGOiMSjLV59pSCC3ttdZSAsRMohAqgwIuk8CZBqQuBUmCCGAOSJQGv4NBbxIEmsmP3Wic3aoYUvAbs2BhyGcLw/lIn16svIVJ8plzPjnyOlBRLRWCJ8FBV+zZptYnvhKVDFTafYhBfkzOKiCWbHS6yWXouVBZ2dXSMGwjMJQZGMegMegJsWAaI6JGnmQl3TR3V1LJ5h1dsQab+Q3tg5zXbcic4KMe208gqcVzUo+XNiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pQ5fRwVmXmozQwzJ3sRrW55ewHENBHLUYkghz6XrTUE=; b=AtTQtotGISXedh618xvDA1NELy0AGRAdDE708lExv6UhgZc6n6YoIEJEIoC2XKLl80SpOk1U+8voG8oxRVl/PWg1fkc2iR3kq+sCbKZ7woik99LQoalDgCCSyiUV1baXaKyTVg3/+5vhb+dlfhWT4naU6ur7ewPYEv/oRB7uTfLC85j8/NhdU9OcjwICXT4sQYw7hhwXGpw60AjnRV6Mpvx4ylJrWDp6fpX4yU5bCKUTjr9Hg8w2H+Aek0sufJ6zlRyVRSuwkZVxdBSSdaPu5UFkRb3L0+weoxd95kXU6Cdo6epnJUNbVXSmf6zg3PDjbXOwUKPIQwZixFtx7kk6Yw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ietf.org; dkim=pass header.d=ietf.org; arc=none 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=pQ5fRwVmXmozQwzJ3sRrW55ewHENBHLUYkghz6XrTUE=; b=RJ0wGxRZhK5/vBLOZKKecmtZq+trm/VYXDMBMyoNvtNkrNMw6kmjtY0i+UpetfroeJLzgTh5wg2BQDyn7Dl4bnai+8MOQZUvL4FuPGCOTaaWbnAWErt9hk9rxv5k3+ly5W7oisucY8uH8Mge3OO4e9WYqGv/RJy0Kof+JveRhno= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB5767.eurprd07.prod.outlook.com (20.178.94.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.15; Wed, 29 Jan 2020 10:51:59 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7%5]) with mapi id 15.20.2686.025; Wed, 29 Jan 2020 10:51:59 +0000 From: CBOR Working Group To: "cbor@ietf.org" Thread-Topic: CBOR interim: 2020-01-29 Thread-Index: AQHV1pIg9o1jUtgA80e9jX0X20UNaA== Sender: Francesca Palombini Date: Wed, 29 Jan 2020 10:51:59 +0000 Message-ID: References: <97856203.989231574777180816.JavaMail.nobody@rva2rmd102.webex.com> In-Reply-To: <97856203.989231574777180816.JavaMail.nobody@rva2rmd102.webex.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-publictraffictype: Email authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 2 x-ms-exchange-meetingforward-message: Forward x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAAAAAAAAAAAAAAAAAAAAAAAAAAAMQAAAHZDYWwtVWlkAQAAADk5YWJhOTEwLTQzNGUtNGQ5OS04ZmEyLTNlODk0ZTA2MTVlYQA= x-originating-ip: [158.174.219.143] x-ms-office365-filtering-correlation-id: 6b385bb1-2f2a-4a05-4b66-08d7a4a9443d x-ms-traffictypediagnostic: AM6PR07MB5767:MeetingMessage x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(366004)(376002)(39860400002)(189003)(199004)(42882007)(66556008)(66476007)(6916009)(66446008)(71200400001)(64756008)(316002)(186003)(55016002)(66616009)(9686003)(91956017)(5660300002)(7846003)(76116006)(16799955002)(6636002)(66946007)(966005)(8676002)(2906002)(52536014)(8936002)(478600001)(7696005)(6506007)(33656002)(19627405001)(26005)(81166006)(81156014)(574754004)(24704002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5767; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 2 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KciMx+0WXYxvZl6DkZMlqD3pqeGnE3cIUrnT+9W5/AdLbV3ZcBuO6xCFvBqxvPVVrFshm+GpjK7U28gT/vRgbX8tnPl8rH9GmZB6wY+ZvLOWbQnl3a+tyvb4E5kX+06fByyeBMZZyMsQ3kDmUZAcaLEwHClvXPTXnBUKEikXHzrSa2dkatOR3LMOl7w0TFehIVM8oh6t8EiQa5JVIRqgxyC9A6Anmypx76qD8/lPKIbN1+53s6y4o7EfR2XuXmkddF/Xg98yX7Usr8adlMhb3JUbpud2mgfQ9G2amRQOX9GZ6vEBNLB/tvEKdnBWTdui7O9bV0L8RPjPQvOG5SxdxE1DM+xAs/zqEHHUADlO2eOmCAisgOpd54zyqC8U3QjxAlZbgUGcodavHOQMRfRIAFrYnr1NSPE06B3DXhnKrmSb7lrkn0+Q7gQYGT/Tunz/WXrBdMBFoYsLLIdqujAxdeBj0xH5s9wjrTgJL/aK2fCwov/eZdXhrNPuakcy/uE48ctJ6Yx8Kwg1UwaPOTQGx3QI5088Slm9qfZbcsooPs2HvvzS6xnEAUloTO/Xc4TN08z6W1olEMkOpKJEJhZfDS9yGZr62ewHtcg48AKGBEc= x-ms-exchange-antispam-messagedata: VWE/+46KPA4vhA2mLGbFJZYlge0nPL9X5BQT68F20esosm8EsGotgdrlhPRKfRk3T13LeaSOEuUc1yWCYPXnoqir+m+FCzp+mFdBE9J5gjMh9k+RfLutzYOgirpEpZfSN4/pk89W41hoIsB7n1v9Xg== x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_005_AM6PR07MB405385A1DAE22E2DB7D114CF98050AM6PR07MB4053eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b385bb1-2f2a-4a05-4b66-08d7a4a9443d X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 10:51:59.6371 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uiKjFd7DsRT4yJ6NgCw1qsXp0NepjP0O8H34RGPVyyDGfWVFoJ7kM5bC9CWMxX0tBvC94yVDSmTHi39G8o8ww+WMJROsEcjiHYXHeDtzhMRePr912Qynim3RODVRU7mw X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5767 Archived-At: Subject: [Cbor] CBOR interim: 2020-01-29 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, 29 Jan 2020 10:52:06 -0000 --_005_AM6PR07MB405385A1DAE22E2DB7D114CF98050AM6PR07MB4053eurp_ Content-Type: multipart/alternative; boundary="_000_AM6PR07MB405385A1DAE22E2DB7D114CF98050AM6PR07MB4053eurp_" --_000_AM6PR07MB405385A1DAE22E2DB7D114CF98050AM6PR07MB4053eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Just a reminder for our meeting later today. An agenda has been posted: https://datatracker.ietf.org/meeting/interim-202= 0-cbor-02/materials/agenda-interim-2020-cbor-02-sessa.txt The goal is to track the status update of CBOR bis and make the point on wh= at is left to do. Talk to you later, Francesca From: CBOR Working Group Reply to: Date: Tuesday, 26 November 2019 at 15:06 To: Subject: Webex meeting invitation: CBOR virtual interim meeting Resent from: Resent to: Jim Schaad , Francesca Palombini Resent date: Tue, 26 Nov 2019 06:06:23 -0800 (PST) CBOR Working Group invites you to join this Webex meeting. Meeting number (access code): 640 196 423 Meeting password: SDMhPrGY Wednesday, January 29, 2020 4:00 pm | (UTC+00:00) Monrovia, Reykjavik | 1 hr Join meeting Join by phone Tap to call in from a mobile device (attendees only) 1-650-479-3208 Call-in toll= number (US/Canada) Need help? Go to http://help.webex.com --_000_AM6PR07MB405385A1DAE22E2DB7D114CF98050AM6PR07MB4053eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

&nbs= p;

Just a re= minder for our meeting later today.

An agenda= has been posted: https://datatracker.ietf.o= rg/meeting/interim-2020-cbor-02/materials/agenda-interim-2020-cbor-02-sessa= .txt

&nbs= p;

The goal = is to track the status update of CBOR bis and make the point on what is lef= t to do.

&nbs= p;

Talk to y= ou later,

Francesca=

&nbs= p;

From= : CBOR Working Grou= p <messenger@webex.com>
Reply to: <cbor-chairs@ietf.org>
Date: Tuesday, 26 November 2019 at 15:06
To: <cbor-chairs@ietf.org>
Subject: Webex meeting invitation: CBOR virtual interim meeting
Resent from: <alias-bounces@ietf.org>
Resent to: Jim Schaad <ietf@augustcellars.com>, Francesca Palo= mbini <francesca.palombini@ericsson.com>
Resent date: Tue, 26 Nov 2019 06:06:23 -0800 (PST)=

 

 

CBOR Working Group invites you to join this Webex meeting.

 

 

 

Meeting number (access code): 640 196 423

 

Meeting password: SDMhPrGY

 

 

 

Wednesday, January 29, 2020

4:00 pm  |  (UTC+00:00) Monrovia, Reyk= javik  |  1 hr

 

 

 

Join meeting

 

 

 

Join by phone

Tap to call in from a mobile device (attendees only)=

1-650-479-3208&n= bsp;Call-in toll number (US/Canada)

 

 

 

Need help? Go to http://help.webex.com

 

 

--_000_AM6PR07MB405385A1DAE22E2DB7D114CF98050AM6PR07MB4053eurp_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpBdGxhbnRp Yy9SZXlramF2aWsNCkJFR0lOOlNUQU5EQVJEDQpEVFNUQVJUOjE2MDEwMTAxVDAwMDAwMA0KVFpP RkZTRVRGUk9NOiswMDAwDQpUWk9GRlNFVFRPOiswMDAwDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRB WUxJR0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAwMDAwMA0KVFpPRkZTRVRGUk9NOiswMDAwDQpUWk9G RlNFVFRPOiswMDAwDQpFTkQ6REFZTElHSFQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0K T1JHQU5JWkVSO0NOPUNCT1IgV29ya2luZyBHcm91cDtTRU5ULUJZPSJtYWlsdG86ZnJhbmNlc2Nh LnBhbG9tYmluaUBlcmljc3Nvbg0KIC5jb20iOm1haWx0bzpjYm9yLWNoYWlyc0BpZXRmLm9yZw0K QVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9 RkFMU0U7Q049Y2JvckBpZXRmDQogLm9yZzptYWlsdG86Y2JvckBpZXRmLm9yZw0KQVRUQUNIOkNJ RDpBQ0E5OTExNzc5MEE0MDQ0QTE4RjNEQzFGQkEzNzcwRkBldXJwcmQwNy5wcm9kLm91dGxvb2su Y29tDQpERVNDUklQVElPTjtMQU5HVUFHRT1lbi1HQjpIaSBhbGxcLFxuXG5KdXN0IGEgcmVtaW5k ZXIgZm9yIG91ciBtZWV0aW5nIGxhdGUNCiByIHRvZGF5LlxuQW4gYWdlbmRhIGhhcyBiZWVuIHBv c3RlZDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLw0KIGludGVyaW0tMjAy MC1jYm9yLTAyL21hdGVyaWFscy9hZ2VuZGEtaW50ZXJpbS0yMDIwLWNib3ItMDItc2Vzc2EudHh0 XG5cblRoDQogZSBnb2FsIGlzIHRvIHRyYWNrIHRoZSBzdGF0dXMgdXBkYXRlIG9mIENCT1IgYmlz IGFuZCBtYWtlIHRoZSBwb2ludCBvbiB3aGENCiB0IGlzIGxlZnQgdG8gZG8uXG5cblRhbGsgdG8g eW91IGxhdGVyXCxcbkZyYW5jZXNjYVxuXG5Gcm9tOiBDQk9SIFdvcmtpbmcgRw0KIHJvdXAgPG1l c3NlbmdlckB3ZWJleC5jb20+XG5SZXBseSB0bzogPGNib3ItY2hhaXJzQGlldGYub3JnPlxuRGF0 ZTogVHVlc2RhDQogeVwsIDI2IE5vdmVtYmVyIDIwMTkgYXQgMTU6MDZcblRvOiA8Y2Jvci1jaGFp cnNAaWV0Zi5vcmc+XG5TdWJqZWN0OiBXZWJleCANCiBtZWV0aW5nIGludml0YXRpb246IENCT1Ig dmlydHVhbCBpbnRlcmltIG1lZXRpbmdcblJlc2VudCBmcm9tOiA8YWxpYXMtYm91bg0KIGNlc0Bp ZXRmLm9yZz5cblJlc2VudCB0bzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT5c LCBGcmFuY2VzY2EgDQogUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNv bT5cblJlc2VudCBkYXRlOiBUdWVcLCAyNiBOb3YgMjANCiAxOSAwNjowNjoyMyAtMDgwMCAoUFNU KVxuXG5cbkNCT1IgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgVw0KIGVi ZXggbWVldGluZy5cblxuXG5cbk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0MCAxOTYg NDIzXG5cbk1lZXRpbmcgDQogcGFzc3dvcmQ6IFNETWhQckdZXG5cblxuXG5XZWRuZXNkYXlcLCBK YW51YXJ5IDI5XCwgMjAyMFxuNDowMCBwbSAgfCAgKFVUQysNCiAwMDowMCkgTW9ucm92aWFcLCBS ZXlramF2aWsgIHwgIDEgaHJcblxuXG5cbkpvaW4gbWVldGluZzxodHRwczovL2lldGYud2ViZQ0K IHguY29tL2lldGYvai5waHA/TVRJRD1tMWFlY2JkZGUzZTU4OTUyMjdlNjQwYmU0Y2E3ZjM5MTE+ XG5cblxuXG5Kb2luIGJ5IHBoDQogb25lXG5UYXAgdG8gY2FsbCBpbiBmcm9tIGEgbW9iaWxlIGRl dmljZSAoYXR0ZW5kZWVzIG9ubHkpXG4xLTY1MC00NzktMzIwODwNCiB0ZWw6JTJCMS02NTAtNDc5 LTMyMDhcLFwsKjAxKjY0MDE5NjQyMyUyMyUyMyowMSo+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVT Lw0KIENhbmFkYSlcblxuXG5cbk5lZWQgaGVscD8gR28gdG8gaHR0cDovL2hlbHAud2ViZXguY29t XG5cblxuDQpVSUQ6OTlhYmE5MTAtNDM0ZS00ZDk5LThmYTItM2U4OTRlMDYxNWVhDQpTVU1NQVJZ O0xBTkdVQUdFPWVuLUdCOkNCT1IgaW50ZXJpbTogMjAyMC0wMS0yOQ0KRFRTVEFSVDtUWklEPUF0 bGFudGljL1JleWtqYXZpazoyMDIwMDEyOVQxNjAwMDANCkRURU5EO1RaSUQ9QXRsYW50aWMvUmV5 a2phdmlrOjIwMjAwMTI5VDE3MDAwMA0KQ0xBU1M6UFVCTElDDQpQUklPUklUWTo1DQpEVFNUQU1Q OjIwMTkxMTI2VDE0MDYyMFoNClRSQU5TUDpPUEFRVUUNClNUQVRVUzpDT05GSVJNRUQNClNFUVVF TkNFOjE1NzQ3NzcxODANCkxPQ0FUSU9OO0xBTkdVQUdFPWVuLUdCOmh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zg0KWC1NSUNST1NPRlQtQ0RPLUFQUFQtU0VRVUVOQ0U6MTU3NDc3NzE4MA0KWC1N SUNST1NPRlQtQ0RPLUJVU1lTVEFUVVM6VEVOVEFUSVZFDQpYLU1JQ1JPU09GVC1DRE8tSU5URU5E RURTVEFUVVM6QlVTWQ0KWC1NSUNST1NPRlQtQ0RPLUFMTERBWUVWRU5UOkZBTFNFDQpYLU1JQ1JP U09GVC1DRE8tSU1QT1JUQU5DRToxDQpYLU1JQ1JPU09GVC1DRE8tSU5TVFRZUEU6MA0KWC1NSUNS T1NPRlQtRE9OT1RGT1JXQVJETUVFVElORzpGQUxTRQ0KWC1NSUNST1NPRlQtRElTQUxMT1ctQ09V TlRFUjpGQUxTRQ0KWC1NSUNST1NPRlQtTE9DQVRJT05TOlt7IkRpc3BsYXlOYW1lIjoiaHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmIlwsIkxvY2F0DQogaW9uQW5ub3RhdGlvbiI6IiJcLCJMb2Nh dGlvblVyaSI6IiJcLCJMb2NhdGlvblN0cmVldCI6IiJcLCJMb2NhdGlvbkNpdHkiOiINCiAiXCwi TG9jYXRpb25TdGF0ZSI6IiJcLCJMb2NhdGlvbkNvdW50cnkiOiIiXCwiTG9jYXRpb25Qb3N0YWxD b2RlIjoiIlwsIkxvYw0KIGF0aW9uRnVsbEFkZHJlc3MiOiIifV0NCkJFR0lOOlZBTEFSTQ0KREVT Q1JJUFRJT046UkVNSU5ERVINClRSSUdHRVI7UkVMQVRFRD1TVEFSVDotUFQ1TQ0KQUNUSU9OOkRJ U1BMQVkNCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== --_000_AM6PR07MB405385A1DAE22E2DB7D114CF98050AM6PR07MB4053eurp_-- --_005_AM6PR07MB405385A1DAE22E2DB7D114CF98050AM6PR07MB4053eurp_ Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Description: Webex_Meeting.ics Content-Disposition: attachment; filename="Webex_Meeting.ics"; size=5348; creation-date="Tue, 26 Nov 2019 14:06:41 GMT"; modification-date="Tue, 26 Nov 2019 14:06:41 GMT" Content-ID: Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL1JleWtqYXZpaw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96 b25laW5mby1vdXRsb29rL0F0bGFudGljL1JleWtqYXZpaw0KWC1MSUMtTE9DQVRJT046QXRsYW50 aWMvUmV5a2phdmlrDQpCRUdJTjpTVEFOREFSRA0KVFpPRkZTRVRGUk9NOiswMDAwDQpUWk9GRlNF VFRPOiswMDAwDQpUWk5BTUU6R01UDQpEVFNUQVJUOjE5NzAwMTAxVDAwMDAwMA0KRU5EOlNUQU5E QVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAxOTExMjZUMTQwNjIw Wg0KQVRURU5ERUU7Q049IkNCT1IgV29ya2luZyBHcm91cCI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7 UlNWUD1UUlVFOk1BSUxUTzpjYm9yLWNoYWlyc0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJDQk9S IFdvcmtpbmcgR3JvdXAiOk1BSUxUTzpjYm9yLWNoYWlyc0BpZXRmLm9yZw0KRFRTVEFSVDtUWklE PUF0bGFudGljL1JleWtqYXZpazoyMDIwMDEyOVQxNjAwMDANCkRURU5EO1RaSUQ9QXRsYW50aWMv UmV5a2phdmlrOjIwMjAwMTI5VDE3MDAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmDQpUUkFOU1A6T1BBUVVFDQpTRVFVRU5DRToxNTc0Nzc3MTgwDQpVSUQ6OTlhYmE5MTAt NDM0ZS00ZDk5LThmYTItM2U4OTRlMDYxNWVhDQpERVNDUklQVElPTjpcblxuXG5cbkpPSU4gV0VC RVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTFhZWNi ZGRlM2U1ODk1MjI3ZTY0MGJlNGNhN2YzOTExXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUp OiA2NDAgMTk2IDQyM1xuXG5cbk1lZXRpbmcgcGFzc3dvcmQ6IFNETWhQckdZXG5cblxuXG5KT0lO IEJZIFBIT05FXG4xLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEp XG5UYXAgaGVyZSB0byBjYWxsIChtb2JpbGUgcGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0 ZWQpOiB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDAxOTY0MjMlMjMlMjMqMDEqXG5cblxu XG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNp c2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFz ZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5m b3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1h eSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNz aW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91 IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMg d2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQtREVTQztG TVRUWVBFPXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxuKiB7XG4gICAgcGFkZGlu ZzogMDsgICAgbWFyZ2luOiAwO31cbnRhYmxlIHtcbglib3JkZXItY29sbGFwc2U6IHNlcGFyYXRl OyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2luZzogMDt9XG5cbnRyIHtcbgls aW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRkIHtcbglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFt aWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1icmVh azogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxuLnRpdGxlIHtcbglmb250LXNpemU6IDI4cHg7fVxu XG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwltYXgtd2lkdGg6IGF1dG87fVxuXG4uZm9vdGVyIHtc bgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7XG5cbn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRl dmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0bGUge1xuCQlmb250LXNpemU6IDIycHggIWltcG9y dGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRoOiBhdXRvICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6 IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290ZXIge1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50 OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxuCS5tYWluIHtcbgkJd2lkdGg6IDEw MCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbn1cbjwvc3R5 bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFyZ2lu OiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiPlxuCTx0ciBzdHlsZT0i aGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCTx0cj5cbgkJPHRkIGFsaWduPSJs ZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAiPlxuCQkJPCEtLTx0YWJsZSBi Z2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7IHdpZHRoOiAxMDAlOyBwYWRkaW5n LWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1h aW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5i c3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPi0tPlxuXG5cblxuXG5cbgkJCTx0 YWJsZT5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjQiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+V2hlbiBpdCdzIHRpbWUsIGpvaW4gdGhlIFdlYmV4IG1lZXRp bmcgaGVyZS48L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCQk8dHIgc3R5bGU9Imxp bmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3Ry PlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDAgMTk2IDQy MzwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT5cbgkJCVxuCQkJPHRh YmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5N ZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5TRE1oUHJHWTwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT5cblxu ICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+ PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPHRyPlxuCQkJCTx0 ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4JCQkJCTx0YWJsZSBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5bGU9IndpZHRoOmF1dG87d2lkdGg6 YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNBOTQyOyBib3JkZXI6MHB4IHNvbGlk ICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdpZHRoOjE2MHB4IWltcG9ydGFudDsi PlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiBzdHlsZT0icGFkZGluZzox MHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tMWFlY2JkZGUzZTU4OTUyMjdlNjQwYmU0Y2E3ZjM5MTEiIHN0eWxlPSJjb2xvcjojRkZGRkZG OyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5Kb2luIG1lZXRpbmc8L2E+ PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4JCQkJPC90ZD5cbgkJCTwvdHI+XG4J CTwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9ImZvbnQt ZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJz cDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSI0IiBGQUNF PSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2lu IGJ5IHBob25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+PGI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQw MTk2NDIzJTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29yYXRpb246 bm9uZTsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjRw eDsnPjEtNjUwLTQ3OS0zMjA4PC9hPjwvYj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRh KTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48QlI+XG5cbjx0YWJsZT48dHIgc3R5bGU9Imxp bmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3Ry PjwvdGFibGU+XG5cblxuXG5cblxuCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDogMTAwJTsiIGFsaWdu PSJsZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6 IDcycHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgc3R5bGU9Imhl aWdodDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OkFyaWFsOyBmb250LXNpemU6 IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBHbyB0byA8YSBocmVmPSJodHRw Oi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5OyB0ZXh0LWRlY29yYXRpb246 bm9uZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxu ICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48dGQ+Jm5ic3A7PC90ZD48 L3RyPlxuCQkJPC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90YWJsZT5cbg0KU1VNTUFSWTpD Qk9SIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nDQpQUklPUklUWTo1DQpDTEFTUzpQVUJMSUMNCkJF R0lOOlZBTEFSTQ0KVFJJR0dFUjotUFQ1TQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9OOlJl bWluZGVyDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= --_005_AM6PR07MB405385A1DAE22E2DB7D114CF98050AM6PR07MB4053eurp_-- From nobody Wed Jan 29 06:49:45 2020 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 43D5A1200BA; Wed, 29 Jan 2020 06:49:43 -0800 (PST) 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_HELO_NONE=0.001, 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 IAB2H5hFLag1; Wed, 29 Jan 2020 06:49:40 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DFB120088; Wed, 29 Jan 2020 06:49:39 -0800 (PST) Received: from [172.16.42.112] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4875wx5H18zycq; Wed, 29 Jan 2020 15:49:37 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: Date: Wed, 29 Jan 2020 15:49:37 +0100 Cc: "cbor@ietf.org" , "draft-ietf-cbor-7049bis@ietf.org" , "cbor-chairs@ietf.org" X-Mao-Original-Outgoing-Id: 602002177.163592-50c527fa18733132899d821dc29b5673 Content-Transfer-Encoding: quoted-printable Message-Id: <445FA6E3-5C29-476F-9AEB-716EAE1D8847@tzi.org> References: <293AFF31-D0EF-45D6-9B9D-E8136481C404@ericsson.com> To: Francesca Palombini X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-7049bis-09?= 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, 29 Jan 2020 14:49:44 -0000 Hi Francesca, here are my comments on your review. > * Section 3.4.7 > =20 > While reading this again, I realized that CBOR sequences cannot be = tagged, as by definition they are not one data item. I think being able = to tag CBOR sequence with the self-describing tag in the scenario = described in this section would be good. You can tag any single data item in the CBOR sequence. Since CBOR sequences are just concatenated encoded data items, I see no = easy way to add some overall information to the sequence itself. > * Section 4.2.2 > =20 > Second to last sub-bullet: "If a protocol includes a field that can = express integers..." > =20 > I noted an inconcistency here with the text on preferred encoding = preferring using maj types 0 and 1 (see text in section 3.4.4. "The = preferred encoding of an integer...") That section has recently been edited, and there are some new edits = waiting in #165. I hope to be able to cover this in #165. The intention is to recommend = using the preferred encoding for integers that fit into mt0/1, i.e., = basic integers. But a protocol could deviate, at the cost of requiring = more work in the application and possibly the generic codec (which would = need to separately handle the non-preferred case). =20 > * Section 9.5 > =20 > Considering the Apps Area Working Group does not exist anymore, should = the contact here being updated? Yes, I have added this to #161. My assumption is that the change controller simply is IESG. I note a lot of variation in how this is handled in recent RFCs, e.g., = in RFC 8628 there are registrations that have change controller IETF = (OAuth extensions); all others there have IESG. > Minor/Editorials > =20 > * Contributing > =20 > It might be good to put in a note for the RFC Editor to remove this = section. (BTW, the thing is a =E2=80=9Cnote", not a section =E2=80=94 at the same = level as abstracts.) Added in new branch =E2=80=9Cfrancesca-editorial=E2=80=9D. =20 >=20 > * Section 1.1, Point 2, sub-bullet 1 > =20 > For readability, I would put an example of "very small amount of code" = number directly in the text, in the parenthesis when mentioning class 1 = constrained nodes. What would be in that example? I=E2=80=99d be very hesitant in adding much to this section, which = should stay concise. > =20 > * Section 1.1, Point 4, sub-bullet 1 > =20 > "and by implementation complexity maintining a lower bound" does not = read correctly to me. Am I missing something? Citing the full text: 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. This is a bound to =E2=80=9Creasonable=E2=80=9D: we don=E2=80=99t want = to increase implementation complexity considerably to improve = compactness. So implementation complexity maintains a lower bound to = what is reasonable to achieve for the size. I have tried rephrasing = that in the new branch. =20 > * Section 1.1, Point 5, sub-bullet 1 > =20 > I would suggest to add "for example for devices of class 1" as an = example of what "reasonably frugal in CPU" means. But it means much more than that, as the next sentence explains. Again, I=E2=80=99d prefer to avoid adding much complexity to this = section. =20 > * Section 1.2 > =20 > The term "representation format" is only used in this section twice, = everywhere else "encoded data item" is used. I would go ahead and remove = this formulation, and only use encoded data item. This would also make = the part on decoder and encoder more symmetric (right now Decoder talks = about "encoded data item" and Encoder talks about "represetnation = format"). While this would simplify things, it would also increase the reliance on = a term that the reader is still trying to understand at this point = (essentially increasing circularity). =E2=80=9CRepresentation format=E2=80= =9D should be sufficiently generic for introductory text, which no need = for definitions. =20 > * Section 1.2, "Valid: " > =20 > This paragraph talks about "semantic restrictions that apply to CBOR = data items"; it would be good to add a hint on where these are defined = in the specification. Right. That would be a reference to Section 5.3, I=E2=80=99d assume, = not to all ~ 81 places that talk about validity? =20 > * Section 2 > =20 > "A simple value, identified by a number between 0 and 255, but = distinct from that number" > =20 > I had to read this sentence several times to understand that the part = "but distinct from that number" is meant to note to the reader that the = value of the item is not the number it's identified by. I would = formulate as written here, rather than as it is now. ("Note that the = value of the item is not the number it's identified by") Well, we need to define it, not just adding notes. Hmm. =20 > * Section 3.1, Major type 4 > =20 > The text states that arrays can also be called sequences. With the = publication of CBOR Sequences, can we remove this statement, as = sequences are (although related) different things? Good point. CBOR sequences are, but arrays are still called sequences in many other = places (which might include the applications sitting on top of CBOR). Need to think about a better way to say =E2=80=9Care also called=E2=80=9D.= Attempt in new branch. =20 > * Section 3.1, Major type 5 > =20 > Using underscoring to highlight a term (in this case "pairs") should = be explained in terminology. Solved by RFCXMLv3 :-) (Still needed for the plain text version, as is the equivalent for = typeset versions.) =20 > * Section 3.1, Major type 6 > =20 > To be consistent with other major types, it might be good to shortly = mention ranges for tags here. Good point! =20 > * Section 3.2 > =20 > While the motivation for arrays and maps is obvious, I would have = appreciated some more text on motivation (or an example of use case) = where indefinite-length strings are useful. That would be an expansion of calling out =E2=80=9Cstreaming=E2=80=9D, = right? Attempt is in the branch. > * Section 3.2.3 > =20 > I don't understand the link between the previous sentence and this = one: > =20 > " Note that this implies that the bytes of a single UTF-8 character > cannot be spread between chunks: a new chunk can only be started at = a > character boundary." > =20 > Nor am I sure of the meaning of the term "spread" here. All component strings need to be valid, i.e., sequences of UTF-8 = characters; this means a single character cannot be started in one = component string and then go on in the next component string. "split up" may be better. > =20 > * Section 3.3 > =20 > Re-appearance of the term "sequence", which I would still avoid. Yes. We also wanted to avoid =E2=80=9Cbyte string=E2=80=9D, because = that is always confusing (in particular if the data item encodes a byte = string). Maybe =E2=80=9Csequence of bytes=E2=80=9D? Or maybe: For example, assume an encoded data item consisting of the bytes: > =20 > * Table 4 > =20 > I would have explicitely stated what data items where allowed for each = tag number, rather than writing multiple. We could do that. There are two cases: Essentially anything (21=E2=80=932= 3, 55799), and the numbers allowed by tag 1; for the latter we could = write =E2=80=9Cinteger or float=E2=80=9D, and =E2=80=9C(any)=E2=80=9D = for the former. > * Section 3.4.4 > =20 > The term "preferred encoding" appears here for the first time without = any reference or introduction. (I think this is now 3.4.3.) The next now has a pointer to Section 4.1, and we are using =E2=80=9Cprefe= rred serialization=E2=80=9D. > =20 > * Section 3.4.5 > =20 > "while the mantissa also can be" -> "while the mantissa can also be" Yes. =20 > * Section 3.4.5 > =20 > Expand NaN on first appearance here (instead of 5.6.1) #165 now has a mention (and expansion) in the terminology section. We could expand here, as well, I=E2=80=99d probably leave the expansion = in 5.6.1. because there is not much context about non-finites here, = while there is in 3.4.5. =20 > * Section 4.2.2 > =20 > "may want to exclude them from interchange, interchanging" > =20 > I would reformulate this. Because it is wrong, misleading, or because the same word is used twice? If the latter, "may want to exclude them from the protocol format, interchanging" maybe? =20 > * Section 4.2.3 > =20 > Capitalize section title I=E2=80=99m sure the RFC editor will have a lot of these. Fixed in the branch now. =20 > * Section 4.2.3 > =20 > First paragraph: please add a reference to 4.2.1 when talking about = core deterministic encoding requirements. Yes. =20 > * Section 5.4 > =20 > "A generic encoder also may want" -> "A generic encoder may also want" Yes. =20 > * Section 5.6 > =20 > "Duplicate keys are also prohibited by CBOR decoders that > enforce validity (Section 5.4)." > =20 > I have a slight problem with the term "prohibited by" decoders... = Decoders do not prohibit, at most they do not accept. Good point. So let=E2=80=99s say =E2=80=9Cnot accepted=E2=80=9D. > =20 > * Section 5.6 > =20 > "except to specify that some, orders are disallowed" -> remove comma (Fixed previously.) > =20 > * Section 7.1, last sub-bullet > =20 > Please reference section 7.2. Yes. (Let=E2=80=99s see whether the RFC editor throws that out = again=E2=80=A6) > =20 > * Section 8.1 > =20 > I like examples. I would have liked an example for the second = paragraph of this section. Good point. =20 > * Appendix G > =20 > "this may not be actually be an error" -> "this may not actually be an = error" Yes. Now PR #166: https://github.com/cbor-wg/CBORbis/pull/166 Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 29 08:46:25 2020 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 0DC5D120888 for ; Wed, 29 Jan 2020 08:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3AMmv6aXRGY for ; Wed, 29 Jan 2020 08:46:15 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0618.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::618]) (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 D49771208B1 for ; Wed, 29 Jan 2020 08:46:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RIOxTuI/KuTq9SLS7B+8O/nePYR8GGnlgfx8I5eMvScWo8Lx2rGcmpbA+X/RtdJfIE55+SB7GItIdU3hOqT8EmvE62XXu9hqx0Tn/Ie2++eTu+duJ0XuyWOhDUQxjmig+kW7pABGBwKnimHWXDOpRWtyXWSNdttIayQUpfwUzimf4hIPMGDk1p41pqNFOijopW+MHQrQ6ySIV8A+JORQoz0OpcjKVhdWithQT+F+2PSom5nS1W/0GMRf4GsBa8/uoR/LjHioLL5HGfX1i0LvbKBqXWD910HPNzTMMLg+lwpDXzBIMhdP2VfeWeX02fhOlb+xVBexjSIQRUfZ/BFS4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nq+41l4OkwSkq/jltMt9w/mfCHCFirHI+P2V1Y4hom8=; b=icCXkO5p6CVESPUjbhaLWQ3ohyaI0eRLWPKhEE9WCXsI6iBVHKCnB3txmdrqqdxIKZyfsZldhEkl1DwR0nvqftVg87m93IydAMo1erT9cmKRt7ejqtLvYlqzUSa1AwUPi2XevpeNEPaLpGKEp2/6hSZ3t3p9fBnZzccYz3bPMjqjq6yy0lcmWVuoMZhvCSd70rL1F7v4/jjPMvxWu3WmJFHDaXiRZu/8GjSGEaXtsIKxa5wx09weD+i8jng2Y62y+oI17Fo5wtcQNN67buxtPXnqVUH6WlMF74QK2i+/oTZOO6ekOnf32QeD5nhwHO0Cesk1O9tbme5ULpgrVJ2kqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=nq+41l4OkwSkq/jltMt9w/mfCHCFirHI+P2V1Y4hom8=; b=oh/Kfy3PCJ1Nr1EkZNNZNxXz28cIztbxHepek8hJ/bxonMbROGZ86oYQuSe30xq7I/x3pwFrqCS/eycOGN9YUAKlP1LOSrWHWymxG7wWGFUbCp+uGIw9Ki26dkVUZslhhsIKw/rlvQDqEgJYmPpJ/r4AKaJHtgJ7jym7G+19EmA= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB5011.eurprd07.prod.outlook.com (20.177.118.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.19; Wed, 29 Jan 2020 16:46:12 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7%5]) with mapi id 15.20.2686.025; Wed, 29 Jan 2020 16:46:12 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: [Cbor] CBOR interim: 2020-01-29 Thread-Index: AQHV1sOdsOZ693IukkKF4d4ZbObGfw== Date: Wed, 29 Jan 2020 16:46:12 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 537c2d15-36d9-4e38-910e-08d7a4dabfff x-ms-traffictypediagnostic: AM6PR07MB5011: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(396003)(346002)(136003)(39860400002)(189003)(199004)(2616005)(86362001)(9326002)(91956017)(76116006)(44832011)(64756008)(71200400001)(66446008)(66946007)(66556008)(66476007)(6512007)(8936002)(6916009)(478600001)(33656002)(16799955002)(186003)(36756003)(8676002)(5660300002)(81166006)(2906002)(316002)(6486002)(53546011)(966005)(6506007)(81156014)(26005)(574754004)(24704002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5011; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Z3M4VYMNBMBj+4Eu7Vly4kTz9vKU1CIJBR2O9+O5rpm7Lo9NLnEsEEp40Iojrx4inMGlmpfc8Nh0W/csnl30nprbR/AVzXzy9TeGJRM1BvWcudbNVP8jPUNSKudzHaf+NdRrutJfKEQb79m7VSqFz4vGi1bH0wffMijMRYNOF7bpxcdvlv9HlUdDU7rW9bDU4NlgLJNlxLBhWq1rL3s+dPZ7CpZGo3bsDnAR/fdeFOygFnrIq9eHfOKj36HGlI+C4XIDRh+sMkmTVPZyd68O6IOU2yyAboK4h7UGF1bincofgwt7IICl6af8/SfR9UCd/GnXb0EvfhqkhkA0qsJ4/TIkxNkugso8dzZmB3A7q/aWuEuT8di9yV0OrSrRsAE4i3LncGwWrQEdTl2pPZ6vOo/ONHJvYKWE7JbUTmEVyboI900XgTJjD5AZQ/OU6E4b12jtPfEdzijhD6s74DgST2iJ4bmQgwkmjM/je39ib5cc9Fo4BiYu5AAK9aQTrJTHpPbmtoYHYqvruwQdp9utRlQ9U34cKpnhLY77CpK1g8qTn2Gq071eMitjZTrwrCQ7YGZ25/ToEE9g6NfcZ2aVnamxqE7mXy9tW1tKyMo8UBo= x-ms-exchange-antispam-messagedata: cNPV3qHWTezpQLYCzsuO83DOMJEeEk8mCqQUMoJzgtI7RRGXSBN3gRbUlKjRSedbVUQOobphT/0MvWDCUri/bn/LWLlhkDnFuudrr7NOvFSUPvumLMzBrCjQ9x1sIhReq+mWds+v+rGMBexnSm8nYA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_B2338E0551CD413487867276FCB7704Aericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 537c2d15-36d9-4e38-910e-08d7a4dabfff X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 16:46:12.6427 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: H/SdPOpL002cT8wnrV8vmIeflYoEjZLvPXqt4uAb73VeRPfJaBlSdICjuCrGwD9+zYmsWWma2qyE7LUn0ofjB3kJHMTvoXCO7x3SXN/yRJpcMjIWfpzjwjKE1SVtdJEr X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5011 Archived-At: Subject: Re: [Cbor] CBOR interim: 2020-01-29 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, 29 Jan 2020 16:46:21 -0000 --_000_B2338E0551CD413487867276FCB7704Aericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk1pbnV0ZXMgZm9yIHRoaXMgbWVldGluZyBoYXZlIGJlZW4gdXBsb2FkZWQ6IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMjAtY2Jvci0wMi9tYXRl cmlhbHMvbWludXRlcy1pbnRlcmltLTIwMjAtY2Jvci0wMi0yMDIwMDEyOTE2MDAudHh0DQoNClRo ZSByZWNvcmRpbmdzIHdpbGwgYmUgdXBkYXRlZCBhcyBzb29uIGFzIHRoZXkgYXJlIHVwbG9hZGVk Lg0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg0KRnJvbTogQ0JPUiA8Y2Jvci1ib3VuY2VzQGlldGYu b3JnPiBvbiBiZWhhbGYgb2YgQ0JPUiBXb3JraW5nIEdyb3VwIDxjYm9yLWNoYWlyc0BpZXRmLm9y Zz4NCkRhdGU6IFdlZG5lc2RheSwgMjkgSmFudWFyeSAyMDIwIGF0IDExOjUyDQpUbzogImNib3JA aWV0Zi5vcmciIDxjYm9yQGlldGYub3JnPg0KU3ViamVjdDogW0Nib3JdIENCT1IgaW50ZXJpbTog MjAyMC0wMS0yOQ0KDQpIaSBhbGwsDQoNCkp1c3QgYSByZW1pbmRlciBmb3Igb3VyIG1lZXRpbmcg bGF0ZXIgdG9kYXkuDQpBbiBhZ2VuZGEgaGFzIGJlZW4gcG9zdGVkOiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL21lZXRpbmcvaW50ZXJpbS0yMDIwLWNib3ItMDIvbWF0ZXJpYWxzL2FnZW5k YS1pbnRlcmltLTIwMjAtY2Jvci0wMi1zZXNzYS4udHh0PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMjAtY2Jvci0wMi9tYXRlcmlhbHMvYWdlbmRhLWludGVy aW0tMjAyMC1jYm9yLTAyLXNlc3NhLnR4dD4NCg0KVGhlIGdvYWwgaXMgdG8gdHJhY2sgdGhlIHN0 YXR1cyB1cGRhdGUgb2YgQ0JPUiBiaXMgYW5kIG1ha2UgdGhlIHBvaW50IG9uIHdoYXQgaXMgbGVm dCB0byBkby4NCg0KVGFsayB0byB5b3UgbGF0ZXIsDQpGcmFuY2VzY2ENCg0KRnJvbTogQ0JPUiBX b3JraW5nIEdyb3VwIDxtZXNzZW5nZXJAd2ViZXguY29tPg0KUmVwbHkgdG86IDxjYm9yLWNoYWly c0BpZXRmLm9yZz4NCkRhdGU6IFR1ZXNkYXksIDI2IE5vdmVtYmVyIDIwMTkgYXQgMTU6MDYNClRv OiA8Y2Jvci1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBXZWJleCBtZWV0aW5nIGludml0YXRp b246IENCT1IgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcNClJlc2VudCBmcm9tOiA8YWxpYXMtYm91 bmNlc0BpZXRmLm9yZz4NClJlc2VudCB0bzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4sIEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24u Y29tPg0KUmVzZW50IGRhdGU6IFR1ZSwgMjYgTm92IDIwMTkgMDY6MDY6MjMgLTA4MDAgKFBTVCkN Cg0KDQpDQk9SIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYmV4IG1l ZXRpbmcuDQoNCg0KDQpNZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDAgMTk2IDQyMw0K DQpNZWV0aW5nIHBhc3N3b3JkOiBTRE1oUHJHWQ0KDQoNCg0KV2VkbmVzZGF5LCBKYW51YXJ5IDI5 LCAyMDIwDQo0OjAwIHBtICB8ICAoVVRDKzAwOjAwKSBNb25yb3ZpYSwgUmV5a2phdmlrICB8ICAx IGhyDQoNCg0KDQpKb2luIG1lZXRpbmc8aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhw P01USUQ9bTFhZWNiZGRlM2U1ODk1MjI3ZTY0MGJlNGNhN2YzOTExPg0KDQoNCg0KSm9pbiBieSBw aG9uZQ0KVGFwIHRvIGNhbGwgaW4gZnJvbSBhIG1vYmlsZSBkZXZpY2UgKGF0dGVuZGVlcyBvbmx5 KQ0KMS02NTAtNDc5LTMyMDg8dGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQwMTk2NDIzJTIz JTIzKjAxKj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKQ0KDQoNCg0KTmVlZCBoZWxw PyBHbyB0byBodHRwOi8vaGVscC53ZWJleC5jb20NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXyBDQk9SIG1haWxpbmcgbGlzdCBDQk9SQGlldGYub3Jn IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Jvcg0K --_000_B2338E0551CD413487867276FCB7704Aericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <6782134C812F9845B213826D45CBE0CC@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMzMz MzMzOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMzMzMzMzIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5N aW51dGVzIGZvciB0aGlzIG1lZXRpbmcgaGF2ZSBiZWVuIHVwbG9hZGVkOg0KPC9zcGFuPjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMjAtY2Jv ci0wMi9tYXRlcmlhbHMvbWludXRlcy1pbnRlcmltLTIwMjAtY2Jvci0wMi0yMDIwMDEyOTE2MDAu dHh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAyMC1jYm9y LTAyL21hdGVyaWFscy9taW51dGVzLWludGVyaW0tMjAyMC1jYm9yLTAyLTIwMjAwMTI5MTYwMC50 eHQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlRoZSByZWNvcmRpbmdzIHdpbGwgYmUgdXBkYXRlZCBhcyBzb29uIGFzIHRo ZXkgYXJlIHVwbG9hZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsPGJyPg0KRnJhbmNlc2NhPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Q0JPUiAmbHQ7Y2Jvci1ib3VuY2VzQGlldGYu b3JnJmd0OyBvbiBiZWhhbGYgb2YgQ0JPUiBXb3JraW5nIEdyb3VwICZsdDtjYm9yLWNoYWlyc0Bp ZXRmLm9yZyZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCAyOSBKYW51YXJ5IDIwMjAg YXQgMTE6NTI8YnI+DQo8Yj5UbzogPC9iPiZxdW90O2Nib3JAaWV0Zi5vcmcmcXVvdDsgJmx0O2Ni b3JAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltDYm9yXSBDQk9SIGludGVyaW06 IDIwMjAtMDEtMjk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBhbGws PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkp1c3QgYSByZW1pbmRlciBmb3Igb3VyIG1lZXRpbmcgbGF0ZXIgdG9kYXkuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BbiBhZ2VuZGEgaGFzIGJlZW4gcG9zdGVkOg0KPC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIw MjAtY2Jvci0wMi9tYXRlcmlhbHMvYWdlbmRhLWludGVyaW0tMjAyMC1jYm9yLTAyLXNlc3NhLnR4 dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2lu dGVyaW0tMjAyMC1jYm9yLTAyL21hdGVyaWFscy9hZ2VuZGEtaW50ZXJpbS0yMDIwLWNib3ItMDIt c2Vzc2EuLnR4dDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIGdvYWwgaXMgdG8gdHJhY2sgdGhlIHN0YXR1cyB1cGRh dGUgb2YgQ0JPUiBiaXMgYW5kIG1ha2UgdGhlIHBvaW50IG9uIHdoYXQgaXMgbGVmdCB0byBkby48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+VGFsayB0byB5b3UgbGF0ZXIsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5GcmFu Y2VzY2E8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5DQk9SIFdvcmtp bmcgR3JvdXAgJmx0O21lc3NlbmdlckB3ZWJleC5jb20mZ3Q7PGJyPg0KPGI+UmVwbHkgdG86IDwv Yj4mbHQ7Y2Jvci1jaGFpcnNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXks IDI2IE5vdmVtYmVyIDIwMTkgYXQgMTU6MDY8YnI+DQo8Yj5UbzogPC9iPiZsdDtjYm9yLWNoYWly c0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+V2ViZXggbWVldGluZyBpbnZpdGF0 aW9uOiBDQk9SIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nPGJyPg0KPGI+UmVzZW50IGZyb206IDwv Yj4mbHQ7YWxpYXMtYm91bmNlc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5SZXNlbnQgdG86IDwvYj5K aW0gU2NoYWFkICZsdDtpZXRmQGF1Z3VzdGNlbGxhcnMuY29tJmd0OywgRnJhbmNlc2NhIFBhbG9t YmluaSAmbHQ7ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+UmVz ZW50IGRhdGU6IDwvYj5UdWUsIDI2IE5vdiAyMDE5IDA2OjA2OjIzIC0wODAwIChQU1QpPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUi IGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGFsaWduPSJsZWZ0IiB3aWR0aD0iMTAwJSIgc3R5 bGU9IndpZHRoOjEwMC4wJTtiYWNrZ3JvdW5kOndoaXRlIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0i aGVpZ2h0OjIxLjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdo dDoyMS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjVw dDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1l bGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7 bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFj dGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDE1LjBw dCAwY20gMTUuMHB0Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTYuNXB0Ij4NCjx0 ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjE2LjVwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTYuNXB0O21zby1lbGVtZW50OmZyYW1l O21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7 bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3It aG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Q0JPUiBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpvaW4g dGhpcyBXZWJleCBtZWV0aW5nLg0KPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTMuNXB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRp Y2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhl aWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBw dCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxNS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVu dDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90 ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxMy41cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUi IGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MGNtO3dp ZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzow Y20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjE2LjVwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0 O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs ZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk1lZXRpbmcgbnVtYmVyIChh Y2Nlc3MgY29kZSk6IDY0MCAxOTYgNDIzDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K PC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjEzLjVwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3Bh Y2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0 aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1o ZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9y ZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY207d2lkdGg6 YXV0byFpbXBvcnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTYu NXB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNv LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4 YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TWVldGluZyBwYXNzd29yZDogU0RN aFByR1k8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3Rh YmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjVwdDttc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50 LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVs ZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0i MCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRk aW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQt ZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1h bmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNv bHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMz MzMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N CjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuNXB0 O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVs ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0 bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRk aW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+ DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNi41cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1l bnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVu dC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFs OmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2 NjY2NjYiPldlZG5lc2RheSwgSmFudWFyeSAyOSwgMjAyMA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNi41cHQ7bXNvLWVs ZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13 cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVt ZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjQ6MDAgcG0mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5i c3A7KFVUQyYjNDM7MDA6MDApIE1vbnJvdmlhLCBSZXlramF2aWsmbmJzcDsmbmJzcDt8Jm5ic3A7 Jm5ic3A7MSBocg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5 Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy41 cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28t ZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBo O21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhh Y3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBh ZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHls ZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1l bGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVs ZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpv bnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMzMzMzMzIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwv dGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjEzLjVwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0 O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs ZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBj ZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY207d2lkdGg6YXV0byFpbXBv cnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBj bTt3aWR0aDphdXRvIWltcG9ydGFudCI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBi b3JkZXI9IjEiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxl PSJ3aWR0aDowY207YmFja2dyb3VuZDojNDNBOTQyO2JvcmRlcjpzb2xpZCAjNDNBOTQyIDEuMHB0 O3dpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0iYm9yZGVy Om5vbmU7cGFkZGluZzo3LjVwdCAyNy4wcHQgNy41cHQgMjcuMHB0O3dpZHRoOmF1dG8haW1wb3J0 YW50Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFs aWduOmNlbnRlcjtsaW5lLWhlaWdodDoxMy41cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1l bnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVu dC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFs OmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMz MzMzMzMiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0x YWVjYmRkZTNlNTg5NTIyN2U2NDBiZTRjYTdmMzkxMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox NS4wcHQ7Y29sb3I6d2hpdGU7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPkpvaW4gbWVldGluZzwvc3Bh bj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90 YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuNXB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVt ZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1l bnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRh bDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MzMzMzMzIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05v cm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0ciBzdHls ZT0iaGVpZ2h0OjM2LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hl aWdodDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjM2 LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21z by1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3Jh cGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpl eGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy41cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMzMzMzMzMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0i TXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRy Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTguMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVt ZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1l bnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRh bDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5Kb2luIGJ5IHBob25lPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTguMHB0O21zby1lbGVtZW50OmZyYW1l O21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7 bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3It aG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM5OTk5OTkiPlRhcCB0byBjYWxsIGluIGZyb20gYSBtb2JpbGUgZGV2aWNlIChhdHRl bmRlZXMgb25seSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0 ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjE4LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1m cmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFu Y2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29s dW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMz MyI+PGEgaHJlZj0idGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQwMTk2NDIzJTIzJTIzKjAx KiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFGRjk7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjEtNjUw LTQ3OS0zMjA4PC9zcGFuPjwvYT4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEp PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBh ZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjVwdDttc28tZWxlbWVu dDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2Vs bHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MjEuMHB0Ij4NCjx0ZCBz dHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjIxLjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MjEuMHB0O21zby1lbGVtZW50OmZyYW1lO21z by1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNv LWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9y aXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMzMzMzMzIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4N CjwvdGJvZHk+DQo8L3RhYmxlPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVy PSIwIiBjZWxscGFkZGluZz0iMCIgYWxpZ249ImxlZnQiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lk dGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjU0LjBwdCI+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDo1NC4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjVwdDttc28tZWxlbWVudDpmcmFtZTttc28t ZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1l bGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6 b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzMzMzMzMyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 dHIgc3R5bGU9ImhlaWdodDoxOC4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt IDBjbTtoZWlnaHQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxOC4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIu MjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5OZWVkIGhlbHA/IEdv IHRvDQo8YSBocmVmPSJodHRwOi8vaGVscC53ZWJleC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDQ5RkQ5O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwOi8vaGVscC53ZWJleC5jb208L3NwYW4+ PC9hPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9Imhl aWdodDozMy4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6 MzMuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy41cHQ7 bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxl bWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21z by1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3Rs eSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwv dGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OndoaXRlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBDQk9SIG1h aWxpbmcgbGlzdCBDQk9SQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2Jvcg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B2338E0551CD413487867276FCB7704Aericssoncom_-- From nobody Wed Jan 29 11:32:56 2020 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 637BF12002E; Wed, 29 Jan 2020 11:32:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158032637423.2719.271476731712725981@ietfa.amsl.com> Date: Wed, 29 Jan 2020 11:32:54 -0800 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-02-12 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 19:32:54 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2020-02-12 from 16:00 to 17:00 UTC. Agenda: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call. ------------------------- Francesca, CBOR chair Information about remote participation: WebEx information will be circulated on the CBOR WG mailing list before each meeting From nobody Wed Jan 29 11:34:41 2020 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 09D04120025; Wed, 29 Jan 2020 11:34:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158032647492.2723.10926510582116429126@ietfa.amsl.com> Date: Wed, 29 Jan 2020 11:34:34 -0800 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-02-26 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 19:34:35 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2020-02-26 from 16:00 to 17:00 UTC. Agenda: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call. ------------------------- Francesca, CBOR chair Information about remote participation: WebEx information will be circulated on the CBOR WG mailing list before each meeting From nobody Wed Jan 29 11:35:06 2020 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 CC510120130; Wed, 29 Jan 2020 11:34:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158032649579.2741.9514050353060003613@ietfa.amsl.com> Date: Wed, 29 Jan 2020 11:34:55 -0800 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-03-11 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 19:35:00 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2020-03-11 from 16:00 to 17:00 UTC. Agenda: We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. WebEx details will be sent to the mailing list before each call. ------------------------- Francesca, CBOR chair Information about remote participation: WebEx information will be circulated on the CBOR WG mailing list before each meeting From nobody Wed Jan 29 12:54:53 2020 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 873A412004E for ; Wed, 29 Jan 2020 12:54:51 -0800 (PST) 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, SPF_HELO_NONE=0.001, 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 4oNLnwlIA7dT for ; Wed, 29 Jan 2020 12:54:46 -0800 (PST) Received: from sjmda12.webex.com (sjmda12.webex.com [64.68.124.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16645120033 for ; Wed, 29 Jan 2020 12:54:46 -0800 (PST) Received: from rva2rmd101.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda12.webex.com (Postfix) with ESMTP id C09A93082368 for ; Wed, 29 Jan 2020 20:54:45 +0000 (GMT) Received: from rva2rmd101.webex.com (localhost [127.0.0.1]) by rva2rmd101.webex.com (Postfix) with ESMTP id 716AA101C805 for ; Wed, 29 Jan 2020 20:54:45 +0000 (GMT) Date: Wed, 29 Jan 2020 20:54:45 +0000 (GMT) From: CBOR Working Group Reply-To: cbor-chairs@ietf.org To: cbor@ietf.org Message-ID: <197853229.5754441580331285463.JavaMail.nobody@rva2rmd101.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1150864_1940603101.1580331285463" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=151647666911063962, X-WBX-TID=4zii9j1ibuemq4b10wal870to3yyt9jy4r037dkye69efgshqfy90qb6, X-WBX-RID=dc0911830ef144b28adc11e52c1cc18f, X-WBX-SVC:Meeting Center, X-WBX-TT:Meeting Invitation, Date:Wed Jan 29 20:54:45 GMT 2020 reminder-39.11.0-2724 Archived-At: Subject: [Cbor] Webex meeting invitation: CBOR working group conference 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, 29 Jan 2020 20:54:52 -0000 ------=_Part_1150864_1940603101.1580331285463 Content-Type: multipart/Alternative; boundary="----=_Part_1150865_875157988.1580331285463" ------=_Part_1150865_875157988.1580331285463 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhpLCBjYm9yQGlldGYub3JnLAoKQ0JPUiBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpv aW4gdGhpcyBXZWJleCBtZWV0aW5nLgoKCkNCT1Igd29ya2luZyBncm91cCBjb25mZXJlbmNlIGNh bGwKT2NjdXJzIGV2ZXJ5IDIgd2VlayhzKSBvbiBXZWRuZXNkYXkgZWZmZWN0aXZlIFdlZG5lc2Rh eSwgRmVicnVhcnkgMTIsIDIwMjAgdW50aWwgV2VkbmVzZGF5LCBNYXJjaCAxMSwgMjAyMCBmcm9t IDQ6MDAgUE0gdG8gNTowMCBQTSwgKFVUQyswMDowMCkgTW9ucm92aWEsIFJleWtqYXZpawo0OjAw IHBtICB8ICAoVVRDKzAwOjAwKSBNb25yb3ZpYSwgUmV5a2phdmlrICB8ICAxIGhyCk1lZXRpbmcg bnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0NCA0ODIgMjgyIApNZWV0aW5nIHBhc3N3b3JkOiA4azNY alBhYgoKCgpXaGVuIGl0J3MgdGltZSwgam9pbiB0aGUgbWVldGluZy4KaHR0cHM6Ly9pZXRmLndl YmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTQ2NGQ1MWJlY2UzZDA2MDczNzExOWRiNDRlZWNiNTJm CgpBZGQgdG8gQ2FsZW5kYXIKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9 bWJkZmUwMDUzY2FhNjM5ZDFiOTRmNDcwZGYzOTQyMGRiDQoNCgoKDQpKT0lOIEJZIFBIT05FDQox LTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpClRhcCBoZXJlIHRv IGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9zdHMgbm90IHN1cHBvcnRlZCk6IHRlbDolMkIx LTY1MC00NzktMzIwOCwsKjAxKjY0NDQ4MjI4MiUyMyUyMyowMSoKDQoNCgpKT0lOIEZST00gQSBW SURFTyBTWVNURU0gT1IgQVBQTElDQVRJT04KRGlhbCBzaXA6NjQ0NDgyMjgyQGlldGYud2ViZXgu Y29tCllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5n IG51bWJlci4KCgpKb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBm b3IgQnVzaW5lc3MKRGlhbCBzaXA6NjQ0NDgyMjgyLmlldGZAbHluYy53ZWJleC5jb20KCgpDYW4n dCBqb2luIHRoZSBtZWV0aW5nPwpodHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNvbS9h cnRpY2xlL1dCWDAwMDAyOTA1NQoKCklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQg dGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2Vu dCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3Zl cmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0 b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25z ZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9z dCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi4K ------=_Part_1150865_875157988.1580331285463 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KKiB7CiAgICBwYWRkaW5nOiAwOyAgICBtYXJnaW46IDA7 fQp0YWJsZSB7Cglib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVy OiAwOwlib3JkZXItc3BhY2luZzogMDt9Cgp0ciB7CglsaW5lLWhlaWdodDogMThweDt9CgphLCB0 ZCB7Cglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdv cmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO30KCi50 aXRsZSB7Cglmb250LXNpemU6IDI4cHg7fQoKLmltYWdlIHsKCXdpZHRoOiBhdXRvOwltYXgtd2lk dGg6IGF1dG87fQoKLmZvb3RlciB7Cgl3aWR0aDogNjA0cHg7fQoKLm1haW4gewoKfUBtZWRpYSBz Y3JlZW4gYW5kIChtYXgtZGV2aWNlLXdpZHRoOiA4MDBweCkgewoJLnRpdGxlIHsKCQlmb250LXNp emU6IDIycHggIWltcG9ydGFudDsJfQoJLmltYWdlIHsKCQl3aWR0aDogYXV0byAhaW1wb3J0YW50 OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX0KCS5mb290ZXIgewoJCXdpZHRoOiAxMDAl ICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnQKCX0KCS5tYWluIHsKCQl3 aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50Cgl9Cn0K PC9zdHlsZT4KCjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFy Z2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiPgoJPHRyIHN0eWxl PSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+Cgk8dHI+CgkJPHRkIGFsaWduPSJs ZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAiPgoJCQk8IS0tPHRhYmxlIGJn Y29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6IDEwMCU7IHBhZGRpbmct bGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFp biI+CgkJCQk8dHI+CgkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5ic3A7 CQkJCQk8L3RkPgoJCQkJPC90cj4KCQkJPC90YWJsZT4tLT4KCgo8dGFibGU+CiAgICAgICA8dHI+ CiAgICAgICAgICAgPHRkIHN0eWxlPSJoZWlnaHQ6IDIycHg7Y29sb3I6ICMwMDAwMDA7Zm9udC1m YW1pbHk6IEFyaWFsOwlmb250LXNpemU6IDE2cHg7Zm9udC13ZWlnaHQ6IGJvbGQ7bGluZS1oZWln aHQ6IDIycHg7Ij4KICAgICAgICAgICAgICAgIENCT1IgV29ya2luZyBHcm91cCBpbnZpdGVzIHlv dSB0byBqb2luIHRoaXMgV2ViZXggbWVldGluZy4KICAgICAgICAgICAgICAgIAkgICAgICAgICAg IDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoKPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWln aHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJs ZT4KCiAgICA8dGFibGUgc3R5bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50OyI+ CiAgICAgICAgPHRyPgogICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsg Y29sb3I6ICMwMDAwMDA7IGZvbnQtc2l6ZTogMTZweDsgbGluZS1oZWlnaHQ6IDIycHg7Ij4KICAg ICAgICAgICAgICAgIE1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0NCA0ODIgMjgyCiAg ICAgICAgICAgIDwvdGQ+CiAgICAgICAgPC90cj4KICAgIDwvdGFibGU+CiAgICA8dGFibGUgc3R5 bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50Ij4KICAgICAgICA8dHIgPgogICAg ICAgICAgICA8dGQgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6ICMwMDAwMDA7IGZv bnQtc2l6ZTogMTZweDsgbGluZS1oZWlnaHQ6IDIycHg7Ij5NZWV0aW5nIHBhc3N3b3JkOiA4azNY alBhYjwvdGQ+CiAgICAgICAgPC90cj4KICAgIDwvdGFibGU+CiAgICAgICAgCjx0YWJsZT48dHIg c3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7 PC90ZD48L3RyPjwvdGFibGU+CgogICAgPHRhYmxlICB3aWR0aD0iMTAwJSI+CiAgICAgICAgPHRy IHN0eWxlPSJtYXJnaW46MHB4O2NvbG9yOiAjNjY2NjY2O2ZvbnQtZmFtaWx5OiBBcmlhbDtmb250 LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDIycHg7Ij4KICAgICAgICAgICAgPHRkIHN0eWxlPSJt YXJnaW46MHB4O2NvbG9yOiAjNjY2NjY2O2ZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0 cHg7bGluZS1oZWlnaHQ6IDIycHg7Ij5PY2N1cnMgZXZlcnkgMiB3ZWVrKHMpIG9uIFdlZG5lc2Rh eSBlZmZlY3RpdmUgV2VkbmVzZGF5LCBGZWJydWFyeSAxMiwgMjAyMCB1bnRpbCBXZWRuZXNkYXks IE1hcmNoIDExLCAyMDIwIGZyb20gNDowMCBQTSB0byA1OjAwIFBNLCAoVVRDKzAwOjAwKSBNb25y b3ZpYSwgUmV5a2phdmlrCiAgICAgICAgICAgIDwvdGQ+CiAgICAgICAgPC90cj4KICAgICAgICA8 dHIgc3R5bGU9Im1hcmdpbjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2Zv bnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjJweDsiPgogICAgICAgICAgICA8dGQgc3R5bGU9 Im1hcmdpbjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTog MTRweDtsaW5lLWhlaWdodDogMjJweDsiPjQ6MDAgcG0mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7 KFVUQyswMDowMCkgTW9ucm92aWEsIFJleWtqYXZpayZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsx IGhyCiAgICAgICAgICAgIDwvdGQ+CiAgICAgICAgPC90cj4KICAgIDwvdGFibGU+CgogPEZPTlQg c2l6ZT0iMiIgQ09MT1I9IiNGRjAwMDAiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZP TlQ+CgogICAgCgoJCQk8dGFibGUgc3R5bGU9InBhZGRpbmctYm90dG9tOiA0cHg7Zm9udC1mYW1p bHk6IEFyaWFsOyI+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweCI+PHRkIHN0eWxlPSJoZWln aHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCTx0YWJsZSBzdHlsZT0nd2lkdGg6 YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDsnPjx0cj48dGQgc3R5bGU9J3dpZHRoOmF1dG8haW1w b3J0YW50OyAnPjx0YWJsZSBib3JkZXI9JzAnIGNlbGxwYWRkaW5nPScwJyBjZWxsc3BhY2luZz0n MCcgc3R5bGU9J3dpZHRoOmF1dG87d2lkdGg6YXV0byFpbXBvcnRhbnQ7IGJhY2tncm91bmQtY29s b3I6IzQzQTk0MjsgYm9yZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjIwcHg7 IG1pbi13aWR0aDoxNjBweCFpbXBvcnRhbnQ7Jz48dGJvZHk+PHRyPjx0ZCBhbGlnbj0nY2VudGVy JyBzdHlsZT0ncGFkZGluZzoxMHB4IDM2cHg7Zm9udC1mYW1pbHk6IEFyaWFsOyc+PGEgaHJlZj0n aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTQ2NGQ1MWJlY2UzZDA2MDcz NzExOWRiNDRlZWNiNTJmJyBzdHlsZT0nY29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRl eHQtZGVjb3JhdGlvbjpub25lOyc+Sm9pbiBtZWV0aW5nPC9hPjwvdGQ+PC90cj48L3Rib2R5Pjwv dGFibGU+PC90ZD48L3RyPjwvdGFibGU+CgkJCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0 OiA0OHB4Ij48dGQgc3R5bGU9ImhlaWdodDo0OHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4K CgoJPHRhYmxlPjx0Ym9keT48dHI+PHRkIHN0eWxlPSJjb2xvcjogIzAwMDAwMDtmb250LWZhbWls eTogQXJpYWw7IGZvbnQtc2l6ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0 OiAyNHB4OyI+PGI+Sm9pbiBieSBwaG9uZTwvYj48L3RkPjwvdHI+PHRyPjx0ZCBzdHlsZT0iY29s b3I6ICM5OTk5OTk7Zm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVp Z2h0OiAyNHB4OyI+VGFwIHRvIGNhbGwgaW4gZnJvbSBhIG1vYmlsZSBkZXZpY2UgKGF0dGVuZGVl cyBvbmx5KTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6 ICMzMzMzMzM7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDog MjRweDsiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjY0NDQ4MjI4MiUyMyUy MyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQt ZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7Jz4xLTY1MC00 NzktMzIwODwvYT4mbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6ICMzMzMzMzM7Ij5DYWxsLWluIHRv bGwgbnVtYmVyIChVUy9DYW5hZGEpPC9zcGFuPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjow cHgiPjx0ZCBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhl aWdodDogMjRweDsiPjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PHRhYmxlIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMCI+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjhweDsiPjx0ZCBz dHlsZT0iaGVpZ2h0OjI4cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJPHRhYmxlPjx0cj48 dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTog MTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiBmcm9t IGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxpY2F0aW9uPC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1h cmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7IGZvbnQtZmFtaWx5OiBBcmlhbDsg Zm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPkRpYWwgPGEgaHJlZj0iIHNpcDo2 NDQ0ODIyODJAaWV0Zi53ZWJleC5jb20iICAgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2Nv bG9yOiMwMEFGRjkiPjY0NDQ4MjI4MkBpZXRmLndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PHRyIHN0 eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZhbWlseTog QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5Zb3UgY2FuIGFsc28g ZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC90ZD48L3Ry PjwvdGFibGU+PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9 ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KICAgIDx0YWJsZSBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsg Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxp bmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3Nv ZnQgU2t5cGUgZm9yIEJ1c2luZXNzPC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgi Pjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXpl OiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPkRpYWwgPGEgaHJlZj0iIHNpcDo2NDQ0ODIyODIu aWV0ZkBseW5jLndlYmV4LmNvbSIgICBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6 IzAwQUZGOSI+NjQ0NDgyMjgyLmlldGZAbHluYy53ZWJleC5jb208L2E+PC90ZD48L3RyPjwvdGFi bGU+CgoJCQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJt YWluIj4KICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+Jm5ic3A7 PC90ZD48L3RyPgoJCQkJPHRyPgoJCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjog IzAwMDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6 IDI0cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIg c3R5bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hlbHAu d2ViZXguY29tPC9hPgoJCQkJCTwvdGQ+CgkJCQk8L3RyPgogICAgICAgICAgICAgICAgPHRyIHN0 eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+CgkJCTwvdGFibGU+CgkJPC90 ZD4KCTwvdHI+CjwvdGFibGU+Cg== ------=_Part_1150865_875157988.1580331285463 Content-Type: text/calendar;method=REQUEST;charset=utf-8; Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL1JleWtqYXZpaw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96 b25laW5mby1vdXRsb29rL0F0bGFudGljL1JleWtqYXZpaw0KWC1MSUMtTE9DQVRJT046QXRsYW50 aWMvUmV5a2phdmlrDQpCRUdJTjpTVEFOREFSRA0KVFpPRkZTRVRGUk9NOiswMDAwDQpUWk9GRlNF VFRPOiswMDAwDQpUWk5BTUU6R01UDQpEVFNUQVJUOjE5NzAwMTAxVDAwMDAwMA0KRU5EOlNUQU5E QVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMDAxMjlUMjA1NDQ1 Wg0KQVRURU5ERUU7Q049ImNib3JAaWV0Zi5vcmciO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9 VFJVRTpNQUlMVE86Y2JvckBpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJDQk9SIFdvcmtpbmcgR3Jv dXAiOk1BSUxUTzpjYm9yLWNoYWlyc0BpZXRmLm9yZw0KRFRTVEFSVDtUWklEPUF0bGFudGljL1Jl eWtqYXZpazoyMDIwMDIxMlQxNjAwMDANCkRURU5EO1RaSUQ9QXRsYW50aWMvUmV5a2phdmlrOjIw MjAwMjEyVDE3MDAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmDQpUUkFO U1A6T1BBUVVFDQpTRVFVRU5DRToxNTgwMzMxMjg1DQpVSUQ6MDdmMjBjYmEtMWJlYy00ZGIwLWJl ZDItMGMxNmQyYTY5MjU5DQpERVNDUklQVElPTjpcblxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xu aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTQ2NGQ1MWJlY2UzZDA2MDcz NzExOWRiNDRlZWNiNTJmXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDQgNDgyIDI4 MlxuXG5cbk1lZXRpbmcgcGFzc3dvcmQ6IDhrM1hqUGFiXG5cblxuXG5KT0lOIEJZIFBIT05FXG4x LTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0 byBjYWxsIChtb2JpbGUgcGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJC MS02NTAtNDc5LTMyMDgsLCowMSo2NDQ0ODIyODIlMjMlMjMqMDEqXG5cblxuXG5KT0lOIEZST00g QSBWSURFTyBTWVNURU0gT1IgQVBQTElDQVRJT05cbkRpYWwgc2lwOjY0NDQ4MjI4MkBpZXRmLndl YmV4LmNvbVxuWW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1l ZXRpbmcgbnVtYmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0 IFNreXBlIGZvciBCdXNpbmVzc1xuRGlhbCBzaXA6NjQ0NDgyMjgyLmlldGZAbHluYy53ZWJleC5j b21cblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25o ZWxwLmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6 IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3Ro ZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdo aWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhp cyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4g SWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29u Y2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQt REVTQztGTVRUWVBFPXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxuKiB7XG4gICAg cGFkZGluZzogMDsgICAgbWFyZ2luOiAwO31cbnRhYmxlIHtcbglib3JkZXItY29sbGFwc2U6IHNl cGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2luZzogMDt9XG5cbnRy IHtcbglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRkIHtcbglmb250LXNpemU6IDE0cHg7CWZv bnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQtd3JhcDogYnJlYWstd29yZDsJd29y ZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxuLnRpdGxlIHtcbglmb250LXNpemU6IDI4 cHg7fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwltYXgtd2lkdGg6IGF1dG87fVxuXG4uZm9v dGVyIHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7XG5cbn1AbWVkaWEgc2NyZWVuIGFuZCAo bWF4LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0bGUge1xuCQlmb250LXNpemU6IDIycHgg IWltcG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRoOiBhdXRvICFpbXBvcnRhbnQ7CQltYXgt d2lkdGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290ZXIge1xuCQl3aWR0aDogMTAwJSAhaW1w b3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxuCS5tYWluIHtcbgkJd2lk dGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbn1c bjwvc3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0icGFkZGluZzogMDsg bWFyZ2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiPlxuCTx0ciBz dHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCTx0cj5cbgkJPHRkIGFs aWduPSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAiPlxuCQkJPCEtLTx0 YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7IHdpZHRoOiAxMDAlOyBw YWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBhbGlnbj0ibGVmdCIgY2xh c3M9Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9w IiA+Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPi0tPlxuXG5cblxuXG5c bgkJCTx0YWJsZT5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjQiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+V2hlbiBpdCdzIHRpbWUsIGpvaW4gdGhlIFdlYmV4 IG1lZXRpbmcgaGVyZS48L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCQk8dHIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDQg NDgyIDI4MjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT5cbgkJCVxu CQkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj44azNYalBhYjwvRk9OVD48L3RkPjwvdHI+PC90YWJs ZT5cblxuICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAy MHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPHRyPlxu CQkJCTx0ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4JCQkJCTx0YWJsZSBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5bGU9IndpZHRoOmF1dG87 d2lkdGg6YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNBOTQyOyBib3JkZXI6MHB4 IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdpZHRoOjE2MHB4IWltcG9y dGFudDsiPlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiBzdHlsZT0icGFk ZGluZzoxMHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5w aHA/TVRJRD1tNDY0ZDUxYmVjZTNkMDYwNzM3MTE5ZGI0NGVlY2I1MmYiIHN0eWxlPSJjb2xvcjoj RkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5Kb2luIG1lZXRp bmc8L2E+PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4JCQkJPC90ZD5cbgkJCTwv dHI+XG4JCTwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFM Ij4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSI0 IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij5Kb2luIGJ5IHBob25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+PGI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwq MDEqNjQ0NDgyMjgyJTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29y YXRpb246bm9uZTsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdo dDogMjRweDsnPjEtNjUwLTQ3OS0zMjA4PC9hPjwvYj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMv Q2FuYWRhKTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48QlI+XG5cbjx0YWJsZT48dHIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpF PSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gZnJvbSBhIHZpZGVvIHN5c3Rl bSBvciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVmPSJzaXA6NjQ0NDgyMjgyQGlldGYud2Vi ZXguY29tIj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPjY0NDQ4 MjI4MkBpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42 OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05U PiZuYnNwOyA8QlI+XG5cbjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0 cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiB1 c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPC9iPjwv dGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7 IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsi PkRpYWwgPGEgaHJlZj0iIHNpcDo2NDQ0ODIyODIuaWV0ZkBseW5jLndlYmV4LmNvbSIgICBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOSI+NjQ0NDgyMjgyLmlldGZAbHlu Yy53ZWJleC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+XG5cbgkJCTx0YWJsZSBzdHlsZT0id2lk dGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0 ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJ CQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpB cmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28g dG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2ViZXguY29tIiBzdHlsZT0iY29sb3I6IzA0OUZEOTsg dGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRwOi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwv dGQ+XG4JCQkJPC90cj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+ PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwvdGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFi bGU+XG4NClNVTU1BUlk6Q0JPUiB3b3JraW5nIGdyb3VwIGNvbmZlcmVuY2UgY2FsbA0KUFJJT1JJ VFk6NQ0KQ0xBU1M6UFVCTElDDQpSUlVMRTpGUkVRPVdFRUtMWTtXS1NUPVNVO0NPVU5UPTM7SU5U RVJWQUw9MjtCWURBWT1XRQ0KQkVHSU46VkFMQVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElT UExBWQ0KREVTQ1JJUFRJT046UmVtaW5kZXINCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpW Q0FMRU5EQVINCg== ------=_Part_1150865_875157988.1580331285463-- ------=_Part_1150864_1940603101.1580331285463 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL1JleWtqYXZpaw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96 b25laW5mby1vdXRsb29rL0F0bGFudGljL1JleWtqYXZpaw0KWC1MSUMtTE9DQVRJT046QXRsYW50 aWMvUmV5a2phdmlrDQpCRUdJTjpTVEFOREFSRA0KVFpPRkZTRVRGUk9NOiswMDAwDQpUWk9GRlNF VFRPOiswMDAwDQpUWk5BTUU6R01UDQpEVFNUQVJUOjE5NzAwMTAxVDAwMDAwMA0KRU5EOlNUQU5E QVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMDAxMjlUMjA1NDQ1 Wg0KQVRURU5ERUU7Q049ImNib3JAaWV0Zi5vcmciO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9 VFJVRTpNQUlMVE86Y2JvckBpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJDQk9SIFdvcmtpbmcgR3Jv dXAiOk1BSUxUTzpjYm9yLWNoYWlyc0BpZXRmLm9yZw0KRFRTVEFSVDtUWklEPUF0bGFudGljL1Jl eWtqYXZpazoyMDIwMDIxMlQxNjAwMDANCkRURU5EO1RaSUQ9QXRsYW50aWMvUmV5a2phdmlrOjIw MjAwMjEyVDE3MDAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmDQpUUkFO U1A6T1BBUVVFDQpTRVFVRU5DRToxNTgwMzMxMjg1DQpVSUQ6MDdmMjBjYmEtMWJlYy00ZGIwLWJl ZDItMGMxNmQyYTY5MjU5DQpERVNDUklQVElPTjpcblxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xu aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTQ2NGQ1MWJlY2UzZDA2MDcz NzExOWRiNDRlZWNiNTJmXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDQgNDgyIDI4 MlxuXG5cbk1lZXRpbmcgcGFzc3dvcmQ6IDhrM1hqUGFiXG5cblxuXG5KT0lOIEJZIFBIT05FXG4x LTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0 byBjYWxsIChtb2JpbGUgcGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJC MS02NTAtNDc5LTMyMDgsLCowMSo2NDQ0ODIyODIlMjMlMjMqMDEqXG5cblxuXG5KT0lOIEZST00g QSBWSURFTyBTWVNURU0gT1IgQVBQTElDQVRJT05cbkRpYWwgc2lwOjY0NDQ4MjI4MkBpZXRmLndl YmV4LmNvbVxuWW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1l ZXRpbmcgbnVtYmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0 IFNreXBlIGZvciBCdXNpbmVzc1xuRGlhbCBzaXA6NjQ0NDgyMjgyLmlldGZAbHluYy53ZWJleC5j b21cblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25o ZWxwLmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6 IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3Ro ZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdo aWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhp cyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4g SWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29u Y2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQt REVTQztGTVRUWVBFPXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxuKiB7XG4gICAg cGFkZGluZzogMDsgICAgbWFyZ2luOiAwO31cbnRhYmxlIHtcbglib3JkZXItY29sbGFwc2U6IHNl cGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2luZzogMDt9XG5cbnRy IHtcbglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRkIHtcbglmb250LXNpemU6IDE0cHg7CWZv bnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQtd3JhcDogYnJlYWstd29yZDsJd29y ZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxuLnRpdGxlIHtcbglmb250LXNpemU6IDI4 cHg7fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwltYXgtd2lkdGg6IGF1dG87fVxuXG4uZm9v dGVyIHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7XG5cbn1AbWVkaWEgc2NyZWVuIGFuZCAo bWF4LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0bGUge1xuCQlmb250LXNpemU6IDIycHgg IWltcG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRoOiBhdXRvICFpbXBvcnRhbnQ7CQltYXgt d2lkdGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290ZXIge1xuCQl3aWR0aDogMTAwJSAhaW1w b3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxuCS5tYWluIHtcbgkJd2lk dGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbn1c bjwvc3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0icGFkZGluZzogMDsg bWFyZ2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiPlxuCTx0ciBz dHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCTx0cj5cbgkJPHRkIGFs aWduPSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAiPlxuCQkJPCEtLTx0 YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7IHdpZHRoOiAxMDAlOyBw YWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBhbGlnbj0ibGVmdCIgY2xh c3M9Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9w IiA+Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPi0tPlxuXG5cblxuXG5c bgkJCTx0YWJsZT5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjQiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+V2hlbiBpdCdzIHRpbWUsIGpvaW4gdGhlIFdlYmV4 IG1lZXRpbmcgaGVyZS48L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCQk8dHIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDQg NDgyIDI4MjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT5cbgkJCVxu CQkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj44azNYalBhYjwvRk9OVD48L3RkPjwvdHI+PC90YWJs ZT5cblxuICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAy MHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPHRyPlxu CQkJCTx0ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4JCQkJCTx0YWJsZSBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5bGU9IndpZHRoOmF1dG87 d2lkdGg6YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNBOTQyOyBib3JkZXI6MHB4 IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdpZHRoOjE2MHB4IWltcG9y dGFudDsiPlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiBzdHlsZT0icGFk ZGluZzoxMHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5w aHA/TVRJRD1tNDY0ZDUxYmVjZTNkMDYwNzM3MTE5ZGI0NGVlY2I1MmYiIHN0eWxlPSJjb2xvcjoj RkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5Kb2luIG1lZXRp bmc8L2E+PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4JCQkJPC90ZD5cbgkJCTwv dHI+XG4JCTwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFM Ij4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSI0 IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij5Kb2luIGJ5IHBob25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+PGI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwq MDEqNjQ0NDgyMjgyJTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29y YXRpb246bm9uZTsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdo dDogMjRweDsnPjEtNjUwLTQ3OS0zMjA4PC9hPjwvYj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMv Q2FuYWRhKTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48QlI+XG5cbjx0YWJsZT48dHIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpF PSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gZnJvbSBhIHZpZGVvIHN5c3Rl bSBvciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVmPSJzaXA6NjQ0NDgyMjgyQGlldGYud2Vi ZXguY29tIj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPjY0NDQ4 MjI4MkBpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42 OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05U PiZuYnNwOyA8QlI+XG5cbjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0 cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiB1 c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPC9iPjwv dGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7 IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsi PkRpYWwgPGEgaHJlZj0iIHNpcDo2NDQ0ODIyODIuaWV0ZkBseW5jLndlYmV4LmNvbSIgICBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOSI+NjQ0NDgyMjgyLmlldGZAbHlu Yy53ZWJleC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+XG5cbgkJCTx0YWJsZSBzdHlsZT0id2lk dGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0 ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJ CQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpB cmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28g dG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2ViZXguY29tIiBzdHlsZT0iY29sb3I6IzA0OUZEOTsg dGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRwOi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwv dGQ+XG4JCQkJPC90cj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+ PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwvdGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFi bGU+XG4NClNVTU1BUlk6Q0JPUiB3b3JraW5nIGdyb3VwIGNvbmZlcmVuY2UgY2FsbA0KUFJJT1JJ VFk6NQ0KQ0xBU1M6UFVCTElDDQpSUlVMRTpGUkVRPVdFRUtMWTtXS1NUPVNVO0NPVU5UPTM7SU5U RVJWQUw9MjtCWURBWT1XRQ0KQkVHSU46VkFMQVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElT UExBWQ0KREVTQ1JJUFRJT046UmVtaW5kZXINCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpW Q0FMRU5EQVINCg== ------=_Part_1150864_1940603101.1580331285463--