From nobody Tue Mar 3 14:42:11 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 5D8B63A0799 for ; Tue, 3 Mar 2020 14:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=microsoft.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 tD_Yk_mxEMB0 for ; Tue, 3 Mar 2020 14:41:55 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640097.outbound.protection.outlook.com [40.107.64.97]) (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 B348B3A0414 for ; Tue, 3 Mar 2020 14:41:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kSbcqsQOpOTrVDe3sZOJxVCjJGZiJhpMyVSWj5TRbwhw7hHO5pmTMZvJhf/cfdt62WM2ZAC5r3MLVNpBsc9e3wyfC8bn6Nj1pkfvMUByMyfQvI9uGXwPqrGT3CpmP5rkUo1PdY5WnY4C4ssuoEv6ye/taeJua6QCvnkaIx4InRkVDrgQBzd7+yv2FUWWnT6vrATfNNTwUypE5zboL7bAIAD8xBHqeEw8pmCkhqKIBrJO6eCDSS6ClEuZrIaYCdBh7hPNod17fG3EPKGvB++rmW9TFfcJlYd1KYSY/GgK1PFZ+LZvA0ZC1Hlh/tJX6kIVw0/OLttObQ7n9hTFE9S3PA== 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=EJ31X4fjIETlBcDzf9R1AXmUJ8mLxEYwoW4rwYns71I=; b=kfBC2TiwOwmtEVeXXB8WR47AW0qXdyuVGQmLGKz++TgiH12vXk6EI3THD9YJAvOiP4Mft7Hjb0aM5Qh47e0ZH09x8eAb0pPdmm5K82Dxc5f+SmNsbtF/t3qEbeFKPJMvCqAxCTSzaz2bbdyW3klolDY4thLqQz8Ru2gMMRsflnZDLTMfNL4tw3BR9aRAHqf8pCmRtiAFXFFMmJU+jVI/CRfDm8BcPzn4BCSN1YBNWjWEdM7aS9QfDVFYk+GST2RA4YbZwI8xdQsg7IrOLV77hW2O+Ym6HS4KgdqQkAIwyJocr+xrrT6SM1hVJwKXx7NNtPc3XklK5H+Jd/5gRSLYOw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EJ31X4fjIETlBcDzf9R1AXmUJ8mLxEYwoW4rwYns71I=; b=jFsmo7+V1LIa72d/3wuNVSiEUDqall5rNhSOBt+VqU+0H0oOopwBvQkx46fermwabcw0MXT6G7pdfu3NKcL4BJqXo1sgMsjY+hKpJoL3ZXrKALoQMFuhVLZ1lkJCX6kH40roefjbIUSnqfjSaTQ1Qlo/6sD9jZqkVAp48yuX1cY= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0828.namprd00.prod.outlook.com (2603:10b6:610:6f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2829.0; Tue, 3 Mar 2020 22:41:53 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::48c0:6588:83bc:d3a3]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::48c0:6588:83bc:d3a3%8]) with mapi id 15.20.2830.000; Tue, 3 Mar 2020 22:41:53 +0000 From: Mike Jones To: "cbor@ietf.org" CC: Anthony Nadalin Thread-Topic: CBOR tag for RFC 3339 full-date values Thread-Index: AdXxrBLX1008GiaeQtiQ4WRvpat/rA== Date: Tue, 3 Mar 2020 22:41:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=b122fef9-dbad-4f10-a50e-00007c9381a4; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-03-03T22:27:30Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:7:a5b5:76c6:699b:e1fb] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f0883b94-38be-4ff7-75f6-08d7bfc411e0 x-ms-traffictypediagnostic: CH2PR00MB0828:|CH2PR00MB0828: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03319F6FEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(376002)(39860400002)(136003)(346002)(366004)(189003)(199004)(316002)(8676002)(71200400001)(55016002)(10290500003)(86362001)(66574012)(186003)(6916009)(9686003)(2906002)(52536014)(478600001)(4744005)(966005)(8936002)(6506007)(8990500004)(7696005)(76116006)(81166006)(107886003)(64756008)(4326008)(66946007)(81156014)(5660300002)(66446008)(66476007)(33656002)(66556008); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0828; H:CH2PR00MB0679.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hZOhLdsWWwBK/Oog6KXgg6oGN5IzTC0Pxa4rkh/3NcGz8HCSZMhOybTkAai0bBOm8Z7zdgdQUNig6XPz1gWXsk9yRU6PCsJMetXZFJZR4vbI0+V+L1b/a2229h4/ZylZESChx+uH+Uyq+Q6RrCh9Z1zaNrQuCLX3K606CkJks6GsxJBHJef5WfuFyg3kl1ZKPVW1aT+MCFQzhAuXbI/V3VPmUODheV1+zQtYNERWFUzWkSN+Gs79Eg6FIGfS5+vEp7H1PXPoS2k7GrvUzhrm6Ty+CnmmXb92zQjlZhHHiuqMRj1OGMPM8bF3AtE4UlARfufMcQrIy5Qo+/V9zfXfiAxIcBz8j6Bk3OLNUt4B0ePVS3CYAGqht2jLqt/DS7/CCEpy2NT9jAtT0zThLnjK9edNGX7Hoe6NXFy5KN6IwF7SYifTUSZT8ppIEjf1E3SeRXJf03jMc/kUTHUWP8GwYW0EGjPFj4ZDl1jkkkcBwBociXw0mFN7GddL+uQFWbIDJNOs+f3lMIEE9WgB/0pW3A== x-ms-exchange-antispam-messagedata: 2aZrpwJk2sXQ55sh3u/bgEd6/lA+A6E42Q5AwOo8UmR/I5OSV2TGYMQsX5Qe0mXbXg0iRXYeVd0CJ/n998cEbRBVYh4+AEVwgf7pqrNQATB22srnEKgKFy+LXp3NN0aCfNzUZdVWVyDE8LECBZDhgbRtDLaH5Wg5704XJoezGrdVIuTOiNtaf4+vtZXSLzayMCivx2XfhZ92rmPgNHyr4A== Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0679818FABC93C37FF88A404F5E40CH2PR00MB0679namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0883b94-38be-4ff7-75f6-08d7bfc411e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2020 22:41:52.9935 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ab1V9x2HL3AZzibkS0Zg+qlf3T6ZxcY3HT1EprqHoD/9dotI86p5/p28jD0On92/KKvLYsR4HEtXz1ax/k3nHw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0828 Archived-At: Subject: [Cbor] CBOR tag for RFC 3339 full-date values 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, 03 Mar 2020 22:42:05 -0000 --_000_CH2PR00MB0679818FABC93C37FF88A404F5E40CH2PR00MB0679namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The working group ISO/IEC JTC 001/SC 17 "Cards and security devices for per= sonal identification" would like to have a CBOR tag allocated to identify R= FC 3339 full-date values (which are defined at https://tools.ietf.org/html/= rfc3339#section-5.6). This is needed for use by the ISO Mobile Driver's Li= cense specification, which contains this normative text: Dates in this document use either date-time or full-date fr= om RFC3339, unless otherwise indicated. While there's already tag 0 for date-time (which is defined at https://tool= s.ietf.org/html/rfc7049#section-2.4.1), there's currently no tag allocated for full-date. Is the best way to allocate this tag to create an Internet Draft and submit= it to the CBOR working group or would you suggest another course to accomp= lish this? Thanks, -- Mike --_000_CH2PR00MB0679818FABC93C37FF88A404F5E40CH2PR00MB0679namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The working group ISO/IEC JTC 001/SC 17 "Cards = and security devices for personal identification" would like to have a= CBOR tag allocated to identify RFC 3339 full-date values (which are define= d at https://tools.i= etf.org/html/rfc3339#section-5.6).  This is needed for use by the = ISO Mobile Driver’s License specification, which contains this normat= ive text:

        &nbs= p;       Dates in this document use either da= te-time or full-date from RFC3339, unless otherwise indicated.

 

While there’s already tag 0 for date-time (whi= ch is defined at https://tools.ietf.org/html/rfc7049#section-2.4.1), there’s curre= ntly no tag allocated for full-date.

 

Is the best way to allocate this tag to create an In= ternet Draft and submit it to the CBOR working group or would you suggest a= nother course to accomplish this?

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Thanks,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_CH2PR00MB0679818FABC93C37FF88A404F5E40CH2PR00MB0679namp_-- From nobody Tue Mar 3 14:59:56 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 48A2D3A07B0 for ; Tue, 3 Mar 2020 14:59:44 -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, 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 0IJbwlfvfxKa for ; Tue, 3 Mar 2020 14:59:41 -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 6DF1D3A07D5 for ; Tue, 3 Mar 2020 14:59:41 -0800 (PST) Received: from [172.16.42.113] (p5089A9C4.dip0.t-ipconnect.de [80.137.169.196]) (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 48XCBg2x6lz10sS; Tue, 3 Mar 2020 23:59:39 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: Date: Tue, 3 Mar 2020 23:59:38 +0100 Cc: "cbor@ietf.org" , Anthony Nadalin X-Mao-Original-Outgoing-Id: 604969178.884051-1173c66b9890ad962f9de0b3ce62a587 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mike Jones X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values 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, 03 Mar 2020 22:59:51 -0000 Hi Mike, > On 2020-03-03, at 23:41, Mike Jones = wrote: >=20 > The working group ISO/IEC JTC 001/SC 17 "Cards and security devices = for personal identification" would like to have a CBOR tag allocated to = identify RFC 3339 full-date values (which are defined = athttps://tools.ietf.org/html/rfc3339#section-5.6). =20 I presume you are thinking about the full-date production there? (Note that this cannot store time zone information, which may be of = interest even for dates in certain cases.) > This is needed for use by the ISO Mobile Driver=E2=80=99s License = specification, which contains this normative text: > Dates in this document use either date-time or = full-date from RFC3339, unless otherwise indicated. Right. =20 > While there=E2=80=99s already tag 0 for date-time (which is defined at = https://tools.ietf.org/html/rfc7049#section-2.4.1), there=E2=80=99s = currently no tag allocated for full-date. > =20 > Is the best way to allocate this tag to create an Internet Draft and = submit it to the CBOR working group or would you suggest another course = to accomplish this? Creating an I-D is definitely a good idea. We don=E2=80=99t necessarily = need to wait for that to be published before registering the tag: the = registry has various levels, from standards action via specification = required up to FCFS. One question that may need to be answered is how = constrained the space is for these data; if there is no particularly = pressing situation, we would go for the 1+2 space (where also the = extended time tag described in draft-bormann-cbor-time-tag was = allocated). [This is also registered, but not published =E2=80=94 at some point we = probably want to roll up a number of these and publish an RFC for them.] The need for a date (not time) tag has come up before; I just can=E2=80=99= t remember where. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Mar 3 23:43: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 C730B3A040F for ; Tue, 3 Mar 2020 23:43:03 -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=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 UaC90A7Uw_AZ for ; Tue, 3 Mar 2020 23:43:01 -0800 (PST) Received: from mail.pdv-fs.de (mail.pdv-fs.de [213.208.220.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0BBF3A0404 for ; Tue, 3 Mar 2020 23:43:01 -0800 (PST) Received: from mail.pdv-fs.de (unknown [192.168.180.95]) by mail.pdv-fs.de (Postfix) with ESMTPS; Wed, 4 Mar 2020 08:42:58 +0100 (CET) Received: from EXCHDB1.pdv-fs.de (192.168.180.94) by EXCHDB2.pdv-fs.de (192.168.180.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 4 Mar 2020 08:42:56 +0100 Received: from EXCHDB1.pdv-fs.de ([fe80::6c4a:8b1b:60f4:4437]) by EXCHDB1.pdv-fs.de ([fe80::6c4a:8b1b:60f4:4437%15]) with mapi id 15.01.1713.009; Wed, 4 Mar 2020 08:42:56 +0100 From: =?Windows-1252?Q?Richter=2C_J=F6rg?= To: Carsten Bormann , Mike Jones CC: "cbor@ietf.org" , Anthony Nadalin Thread-Topic: [Cbor] CBOR tag for RFC 3339 full-date values Thread-Index: AQHV8a0B9fEeIB5RW0GE31JPZx9/XKg3arYAgACfx6g= Date: Wed, 4 Mar 2020 07:42:56 +0000 Message-ID: <282209381d8b4a8b8e77515142266df2@pdv-FS.de> References: , In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.185.1] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TMASE-Version: DDEI-3.5-8.5.1020-25268.005 X-TMASE-Result: 10--5.992300-10.000000 X-TMASE-MatchedRID: j6N+ovIINR+n9EJj6muJHmCpu+NlpSDeou859sScIYpVTaZPGOkL02sG JiZSQICbnyMABw4V8Tjs0O7ms5ITYJydwblx2XNga8NP7ALumoVKRaXN2yYjHk+86maMM3aSCSq vzMGx6vEynIT+kqhg23Dt0CnaGnwb7ABo0upccSowo+sXt0rns5hwKdlCfPk8myiLZetSf8mXxk CsDPSYDDtQWIXrdOEn0C1sQRfQzEHEQdG7H66TyOP/mA9rOmnf9G84N7/KGEDzBM0a4skz04v8l DOGQCUyAj9RatMxYL2dKeYKkuyC7fK+VXpen3rZyYdBFCQZXYT6qyQImjI5YPwvmYdMOvkKp5DF xO/tuzWUSSJPERKCCG1G0sdA2yd47FHW4PQA8ke6rLuaBPjT2g== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 X-TMASE-INERTIA: 1-0;;J4gzHMCxkPyYUJl0x8cA1w==;; Archived-At: Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values 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, 04 Mar 2020 07:43:04 -0000 Hi, > The need for a date (not time) tag has come up before; I just can=92t rem= ember where. One year ago I sent a proposal f=FCr a date tag [1]. So far it has not made it into the overview of the assigned CBOR-tags [2]. I would very much appreciate if the suggested tag number is used for the da= te-tag, since we already use it internally. What is missing for the suggested tag numbers to be assigned? Btw. I have a= nother proposal for currencies and money amounts at [3] whose tags were not= assigned either. - J=F6rg [1] https://j-richter.github.io/CBOR/date.html [2] https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml [3] https://j-richter.github.io/CBOR/currency.html From nobody Wed Mar 4 10:41:19 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 7D2C13A146D; Wed, 4 Mar 2020 10:41:09 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 To8U3tdm6Cu2; Wed, 4 Mar 2020 10:41:07 -0800 (PST) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 F2D8F3A1460; Wed, 4 Mar 2020 10:41:06 -0800 (PST) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 024IewLX023637 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 4 Mar 2020 19:40:58 +0100 Received: from [192.168.178.13] (134.102.43.219) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 4 Mar 2020 19:40:53 +0100 To: "rats@ietf.org" , "ace@ietf.org" , "cbor@ietf.org" From: Henk Birkholz Message-ID: Date: Wed, 4 Mar 2020 19:40:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [134.102.43.219] Archived-At: Subject: [Cbor] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? 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, 04 Mar 2020 18:41:10 -0000 Hi RATS enthusiasts, hi ACE, hi CBOR, in the RATS WG we had a lot of discussions about the nature of an Entity Attestation Token (EAT): > https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ > https://github.com/ietf-rats-wg/eat/ A bit of (hopefully useful) context: an EAT is one way to convey believable evidence from an Attester (a role residing on a device-like entity) to a Verifier (another role defined by RATS - the appraiser of evidence). All that is done to provide a Relying Party with "simple enough" attestation results generated by the Verifier to enable Relying Parties (in general, the remote peer) to make an informed decision about whether to put trust in the trustworthiness of that Attester or not. In summary, an Attester could be compromised in some way and RATS tries to inhibit that Attester to lie about that. There are a lot of benefits if an EAT (representing evidence) is a CWT: * we avoid conflicting CWT claim index/label definitions in the IANA registry, while being able to use the CWT world of claims (existing, cnf soon, and such), * at first glance it seems simpler to use existing code that can process CWT, and * EAT can simply inherit the well defined COSE signing conventions. Alas, there is also a very specific drawback: * sometimes RATS might not want to sign a token (maybe that does render it not a token anymore, but rather a ticket. But that is just a rather minor detail for now) Why do RATS sometimes not require a signature around their CWT Claims Sets? Because the surrounding secure channel between two entities with well established authenticity and trustworthiness can be good enough to convey useful CWT Claims Sets without a signature (emphasis on: in RATS). Now - there are multiple options discussed in the RATS WG how to deal with this: 1.) go to COSE and ask for a "null signature", 2.) go to ACE and ask for an "unsigned token" option, or 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are not signed). At the last RATS virtual interim there was no certainty how to approach this. So this is a call out. COSE, ACE, and CBOR, how would you approach this "unsigned CWT Claims Set" requirement? If one of the three options highlighted above is out of the question, please say so (and please elaborate on the why for the sake of helping the RATS WG understand why that is not a good idea). If one of the three options looks like a low hanging fruit & viable, please say so (and... you know the drill). I hope that this email contains all the information required to help the RATS WG in this call out to other WGs. If it does not, please say so :) Last but not least, if there are other relevant WGs or experts that could lend opinions or alternatives, let us know. Viele Grüße, Henk From nobody Wed Mar 4 11:58:13 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 697E23A0416; Wed, 4 Mar 2020 11:58:07 -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, 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 UBJNndLKg3BV; Wed, 4 Mar 2020 11:58:05 -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 C94A03A0414; Wed, 4 Mar 2020 11:58:04 -0800 (PST) Received: from [172.16.42.113] (p5089A9C4.dip0.t-ipconnect.de [80.137.169.196]) (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 48Xl6f6k3Vz100y; Wed, 4 Mar 2020 20:58:02 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: Date: Wed, 4 Mar 2020 20:58:02 +0100 Cc: "rats@ietf.org" , "ace@ietf.org" , "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 605044682.456602-3bf3b410bc820e7981c0f1db4c03daa4 Content-Transfer-Encoding: quoted-printable Message-Id: <7A9AE14E-5DFD-41B4-93CD-91127133E038@tzi.org> References: To: Henk Birkholz X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Cbor] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? 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, 04 Mar 2020 19:58:08 -0000 On 2020-03-04, at 19:40, Henk Birkholz = wrote: >=20 > 1.) go to COSE and ask for a "null signature", https://en.wikipedia.org/wiki/Just_Say_No > 2.) go to ACE and ask for an "unsigned token" option, or > 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., = that are not signed). I believe this is pretty much the same option. I think ACE would come up with a CBOR tag as the obvious technical = solution, and CBOR would suggest exactly that to ACE as the group = responsible for CWT (and thus CWT Claims Sets). Apparently the only technical problem we have is that we don=E2=80=99t = have a defined way to mark a naked CWT Claims Set (NCCS) as such; EATs = would then be either NCCS or CWTs. CBOR tags are cheap and solve this problem. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 4 13:42:27 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 256263A099C; Wed, 4 Mar 2020 13:42:17 -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, 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 vs8JgDVbMu2j; Wed, 4 Mar 2020 13:42:15 -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 10F083A0A03; Wed, 4 Mar 2020 13:42:15 -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; Wed, 4 Mar 2020 13:42:10 -0800 From: Jim Schaad To: 'Henk Birkholz' , , , References: In-Reply-To: Date: Wed, 4 Mar 2020 13:42:08 -0800 Message-ID: <00d501d5f26d$c34454d0$49ccfe70$@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: AQIPc7l4+GCW+nItGLs4R66gGWmpXafF0IDw Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? 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, 04 Mar 2020 21:42:17 -0000 Henk, Well you have definitely written a message designed to get a response = from me. -----Original Message----- From: Ace On Behalf Of Henk Birkholz Sent: Wednesday, March 4, 2020 10:41 AM To: rats@ietf.org; ace@ietf.org; cbor@ietf.org Subject: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not = to be a CWT? Hi RATS enthusiasts, hi ACE, hi CBOR, in the RATS WG we had a lot of discussions about the nature of an Entity = Attestation Token (EAT): > https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ > https://github.com/ietf-rats-wg/eat/ A bit of (hopefully useful) context: an EAT is one way to convey = believable evidence from an Attester (a role residing on a device-like entity) to a Verifier (another role defined by RATS - the appraiser of = evidence). All that is done to provide a Relying Party with "simple = enough" attestation results generated by the Verifier to enable Relying = Parties (in general, the remote peer) to make an informed decision about = whether to put trust in the trustworthiness of that Attester or not. In = summary, an Attester could be compromised in some way and RATS tries to = inhibit that Attester to lie about that. There are a lot of benefits if an EAT (representing evidence) is a CWT: * we avoid conflicting CWT claim index/label definitions in the IANA = registry, while being able to use the CWT world of claims (existing, cnf = soon, and such), * at first glance it seems simpler to use existing code that can process = CWT, and * EAT can simply inherit the well defined COSE signing conventions. Alas, there is also a very specific drawback: * sometimes RATS might not want to sign a token (maybe that does render = it not a token anymore, but rather a ticket. But that is just a rather = minor detail for now) Why do RATS sometimes not require a signature around their CWT Claims = Sets? Because the surrounding secure channel between two entities with = well established authenticity and trustworthiness can be good enough to = convey useful CWT Claims Sets without a signature (emphasis on: in = RATS). Now - there are multiple options discussed in the RATS WG how to deal = with this: 1.) go to COSE and ask for a "null signature", [JLS] For suggesting this, you should have all of you security = credentials revoked. The idea of deliberately introducing a way to take = the security value of COSE signatures to zero is something that should = be staked like a vampire and not allowed to continue. I strongly = believe that this is a fatal flaw in the current JOSE security suite and = have several times deliberated writing a document to remove the "null = signature" from JOSE. While it is bad to have signatures which are no = longer adequately secure, having one with zero security is just brain = dead. 2.) go to ACE and ask for an "unsigned token" option, or [JLS] I don't have a problem with this, I am not sure that I see any = reason for it however. See below. 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that = are not signed). [JLS] I don't see any difference between this and option #2 [JLS] 4.) Just write your CWT code in a sensible manner. =20 My CWT code base does not make any assumptions about the number or order = of COSE security wrapping layers on a token. It thus looks like while (true) { if input has a COSE_Encrypt tag { decrypt it; set input to the = content; save the encryption information if needed e.g. shared key = authentication; continue; } if input has a COSE_MAC tag { validate it; set input to the content; = save the MAC information if needed e.g. shared key authentication; = continue;} if input has a COSE_Signature tag { validate it; set input to the = content; save the signer information; continue } if input is a map - return input as the set of claims; throw an exception because it is not the correct format. } This does not require a tag for a naked set of claims and would allow = that set of claims to be pass in the same place as a CWT can be passed. = What you are suggesting would require extra code to exist someplace that = is going to check for an additional tag. It is also going to lead to = people thinking that this new tag should be legal to place inside of a = CWT. After all it makes more sense to always include it than to just = sometimes include it. This would be more of an issue if an array rather = than a map was being used to carry the claims as there would be a chance = to not know what type of security wrapper exists. [JLS END] At the last RATS virtual interim there was no certainty how to approach = this. So this is a call out. COSE, ACE, and CBOR, how would you approach = this "unsigned CWT Claims Set" requirement? If one of the three options highlighted above is out of the question, = please say so (and please elaborate on the why for the sake of helping = the RATS WG understand why that is not a good idea). If one of the three options looks like a low hanging fruit & viable, = please say so (and... you know the drill). I hope that this email contains all the information required to help the = RATS WG in this call out to other WGs. If it does not, please say so :) Last but not least, if there are other relevant WGs or experts that = could lend opinions or alternatives, let us know. Viele Gr=C3=BC=C3=9Fe, Henk _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Wed Mar 4 14:33:43 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 38A8A3A0AD5; Wed, 4 Mar 2020 14:33:41 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 yFbjVOcP4HOS; Wed, 4 Mar 2020 14:33:38 -0800 (PST) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 409CF3A0AD3; Wed, 4 Mar 2020 14:33:37 -0800 (PST) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 024MXUFh032237 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 4 Mar 2020 23:33:30 +0100 Received: from [134.102.158.160] (134.102.158.160) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 4 Mar 2020 23:33:25 +0100 To: Jim Schaad , , , References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> From: Henk Birkholz Message-ID: <4a44342d-b856-351e-8e38-405646a5597b@sit.fraunhofer.de> Date: Wed, 4 Mar 2020 23:33:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [134.102.158.160] Archived-At: Subject: Re: [Cbor] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? 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, 04 Mar 2020 22:33:42 -0000 Hi Jim, I'll take a stake into my heart for the group then :) Please note that I claim that there is no evidence that I am a vampire nor that I am the provenance of option 1.). I tried to phrase the output of the last virtual interim as neutral as possible and I think your reply is to be categorized as: Option 1.) is "out of the question" as a reply from a COSE WG chair. Viele Grüße, Henk On 04.03.20 22:42, Jim Schaad wrote: > Henk, > > Well you have definitely written a message designed to get a response from me. > > -----Original Message----- > From: Ace On Behalf Of Henk Birkholz > Sent: Wednesday, March 4, 2020 10:41 AM > To: rats@ietf.org; ace@ietf.org; cbor@ietf.org > Subject: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? > > Hi RATS enthusiasts, > hi ACE, > hi CBOR, > > in the RATS WG we had a lot of discussions about the nature of an Entity Attestation Token (EAT): > > > https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ > > > https://github.com/ietf-rats-wg/eat/ > > A bit of (hopefully useful) context: an EAT is one way to convey believable evidence from an Attester (a role residing on a device-like > entity) to a Verifier (another role defined by RATS - the appraiser of evidence). All that is done to provide a Relying Party with "simple enough" attestation results generated by the Verifier to enable Relying Parties (in general, the remote peer) to make an informed decision about whether to put trust in the trustworthiness of that Attester or not. In summary, an Attester could be compromised in some way and RATS tries to inhibit that Attester to lie about that. > > There are a lot of benefits if an EAT (representing evidence) is a CWT: > > * we avoid conflicting CWT claim index/label definitions in the IANA registry, while being able to use the CWT world of claims (existing, cnf soon, and such), > * at first glance it seems simpler to use existing code that can process CWT, and > * EAT can simply inherit the well defined COSE signing conventions. > > Alas, there is also a very specific drawback: > > * sometimes RATS might not want to sign a token (maybe that does render it not a token anymore, but rather a ticket. But that is just a rather minor detail for now) > > Why do RATS sometimes not require a signature around their CWT Claims Sets? Because the surrounding secure channel between two entities with well established authenticity and trustworthiness can be good enough to convey useful CWT Claims Sets without a signature (emphasis on: in RATS). > > Now - there are multiple options discussed in the RATS WG how to deal with this: > > 1.) go to COSE and ask for a "null signature", > > [JLS] For suggesting this, you should have all of you security credentials revoked. The idea of deliberately introducing a way to take the security value of COSE signatures to zero is something that should be staked like a vampire and not allowed to continue. I strongly believe that this is a fatal flaw in the current JOSE security suite and have several times deliberated writing a document to remove the "null signature" from JOSE. While it is bad to have signatures which are no longer adequately secure, having one with zero security is just brain dead. > > 2.) go to ACE and ask for an "unsigned token" option, or > > [JLS] I don't have a problem with this, I am not sure that I see any reason for it however. See below. > > 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are not signed). > [JLS] I don't see any difference between this and option #2 > > [JLS] > 4.) Just write your CWT code in a sensible manner. > > My CWT code base does not make any assumptions about the number or order of COSE security wrapping layers on a token. It thus looks like > > while (true) { > if input has a COSE_Encrypt tag { decrypt it; set input to the content; save the encryption information if needed e.g. shared key authentication; continue; } > if input has a COSE_MAC tag { validate it; set input to the content; save the MAC information if needed e.g. shared key authentication; continue;} > if input has a COSE_Signature tag { validate it; set input to the content; save the signer information; continue } > if input is a map - return input as the set of claims; > throw an exception because it is not the correct format. > } > > This does not require a tag for a naked set of claims and would allow that set of claims to be pass in the same place as a CWT can be passed. What you are suggesting would require extra code to exist someplace that is going to check for an additional tag. It is also going to lead to people thinking that this new tag should be legal to place inside of a CWT. After all it makes more sense to always include it than to just sometimes include it. This would be more of an issue if an array rather than a map was being used to carry the claims as there would be a chance to not know what type of security wrapper exists. > > [JLS END] > > > At the last RATS virtual interim there was no certainty how to approach this. So this is a call out. COSE, ACE, and CBOR, how would you approach this "unsigned CWT Claims Set" requirement? > > If one of the three options highlighted above is out of the question, please say so (and please elaborate on the why for the sake of helping the RATS WG understand why that is not a good idea). > > If one of the three options looks like a low hanging fruit & viable, please say so (and... you know the drill). > > I hope that this email contains all the information required to help the RATS WG in this call out to other WGs. If it does not, please say so :) > > Last but not least, if there are other relevant WGs or experts that could lend opinions or alternatives, let us know. > > Viele Grüße, > > Henk > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > From nobody Wed Mar 4 14:46:22 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 5B26B3A0B0A; Wed, 4 Mar 2020 14:46:20 -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, 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 nSRfECEvPcBb; Wed, 4 Mar 2020 14:46: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 D6C3E3A0B04; Wed, 4 Mar 2020 14:46:17 -0800 (PST) Received: from [192.168.217.147] (p5089A9C4.dip0.t-ipconnect.de [80.137.169.196]) (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 48Xprm0J6Yz108b; Wed, 4 Mar 2020 23:46:16 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <4a44342d-b856-351e-8e38-405646a5597b@sit.fraunhofer.de> Date: Wed, 4 Mar 2020 23:46:15 +0100 Cc: Jim Schaad , rats@ietf.org, ace@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 605054775.493915-daa859d953590922773df91e40f2c0b7 Content-Transfer-Encoding: quoted-printable Message-Id: <30A65EE4-25BC-4AA2-B283-85471FA49278@tzi.org> References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <4a44342d-b856-351e-8e38-405646a5597b@sit.fraunhofer.de> To: Henk Birkholz X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Cbor] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? 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, 04 Mar 2020 22:46:20 -0000 On 2020-03-04, at 23:33, Henk Birkholz = wrote: >=20 > Option 1.) is "out of the question" as a reply from a COSE WG chair. Option 1.) is "out of the question" as a reply from the author of the = COSE specification. (And at least one other WG member agrees.) FTFY=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 4 14:48: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 0A1623A0B14; Wed, 4 Mar 2020 14:48:26 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 IT2zar6Z4u_r; Wed, 4 Mar 2020 14:48:24 -0800 (PST) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 DD7ED3A0B08; Wed, 4 Mar 2020 14:48:22 -0800 (PST) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 024MmFG3032497 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 4 Mar 2020 23:48:16 +0100 Received: from [134.102.158.160] (134.102.158.160) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 4 Mar 2020 23:48:10 +0100 To: Carsten Bormann CC: Jim Schaad , , , References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <4a44342d-b856-351e-8e38-405646a5597b@sit.fraunhofer.de> <30A65EE4-25BC-4AA2-B283-85471FA49278@tzi.org> From: Henk Birkholz Message-ID: <29993d66-fd6f-a648-b030-18ceb0d22434@sit.fraunhofer.de> Date: Wed, 4 Mar 2020 23:48:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <30A65EE4-25BC-4AA2-B283-85471FA49278@tzi.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [134.102.158.160] Archived-At: Subject: Re: [Cbor] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? 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, 04 Mar 2020 22:48:26 -0000 Oh. Yes. Sorry. Tired and therefore still claiming #notavampire On 04.03.20 23:46, Carsten Bormann wrote: > On 2020-03-04, at 23:33, Henk Birkholz wrote: >> >> Option 1.) is "out of the question" as a reply from a COSE WG chair. > > Option 1.) is "out of the question" as a reply from the author of the COSE specification. > (And at least one other WG member agrees.) > > FTFY… > > Grüße, Carsten > From nobody Wed Mar 4 15:02:11 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 7CA163A0B52; Wed, 4 Mar 2020 15:01:58 -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, 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 ylLBT5_a4AGt; Wed, 4 Mar 2020 15:01:56 -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 19B023A0B54; Wed, 4 Mar 2020 15:01:56 -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; Wed, 4 Mar 2020 15:01:50 -0800 From: Jim Schaad To: 'Henk Birkholz' , , , References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <4a44342d-b856-351e-8e38-405646a5597b@sit.fraunhofer.de> In-Reply-To: <4a44342d-b856-351e-8e38-405646a5597b@sit.fraunhofer.de> Date: Wed, 4 Mar 2020 15:01:49 -0800 Message-ID: <00e201d5f278$e4b6f310$ae24d930$@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: AQIPc7l4+GCW+nItGLs4R66gGWmpXQHDaFTrAZUxuCCnq0QkEA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? 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, 04 Mar 2020 23:01:59 -0000 -----Original Message----- From: Ace On Behalf Of Henk Birkholz Sent: Wednesday, March 4, 2020 2:33 PM To: Jim Schaad ; rats@ietf.org; ace@ietf.org; = cbor@ietf.org Subject: Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or = not to be a CWT? Hi Jim, I'll take a stake into my heart for the group then :) Please note that I = claim that there is no evidence that I am a vampire nor that I am the = provenance of option 1.). [JLS] Please note I was planning on staking the idea not the person, I = was just going to de-credential you. However that does raise the = question should I bring salt and a sewing kit (mummies) or a gun with a = silver bullet (werewolves)? I tried to phrase the output of the last virtual interim as neutral as = possible and I think your reply is to be categorized as: Option 1.) is "out of the question" as a reply from a COSE WG chair. [JLS] That would be the COSE author and ACE and CBOR WG chair. I am not = a COSE WG chair. However, I guess I hit all three asks. Viele Gr=C3=BC=C3=9Fe, Henk On 04.03.20 22:42, Jim Schaad wrote: > Henk, >=20 > Well you have definitely written a message designed to get a response = from me. >=20 > -----Original Message----- > From: Ace On Behalf Of Henk Birkholz > Sent: Wednesday, March 4, 2020 10:41 AM > To: rats@ietf.org; ace@ietf.org; cbor@ietf.org > Subject: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or = not to be a CWT? >=20 > Hi RATS enthusiasts, > hi ACE, > hi CBOR, >=20 > in the RATS WG we had a lot of discussions about the nature of an = Entity Attestation Token (EAT): >=20 > > https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ >=20 > > https://github.com/ietf-rats-wg/eat/ >=20 > A bit of (hopefully useful) context: an EAT is one way to convey=20 > believable evidence from an Attester (a role residing on a device-like > entity) to a Verifier (another role defined by RATS - the appraiser of = evidence). All that is done to provide a Relying Party with "simple = enough" attestation results generated by the Verifier to enable Relying = Parties (in general, the remote peer) to make an informed decision about = whether to put trust in the trustworthiness of that Attester or not. In = summary, an Attester could be compromised in some way and RATS tries to = inhibit that Attester to lie about that. >=20 > There are a lot of benefits if an EAT (representing evidence) is a = CWT: >=20 > * we avoid conflicting CWT claim index/label definitions in the IANA=20 > registry, while being able to use the CWT world of claims (existing,=20 > cnf soon, and such), > * at first glance it seems simpler to use existing code that can=20 > process CWT, and > * EAT can simply inherit the well defined COSE signing conventions. >=20 > Alas, there is also a very specific drawback: >=20 > * sometimes RATS might not want to sign a token (maybe that does=20 > render it not a token anymore, but rather a ticket. But that is just a = > rather minor detail for now) >=20 > Why do RATS sometimes not require a signature around their CWT Claims = Sets? Because the surrounding secure channel between two entities with = well established authenticity and trustworthiness can be good enough to = convey useful CWT Claims Sets without a signature (emphasis on: in = RATS). >=20 > Now - there are multiple options discussed in the RATS WG how to deal = with this: >=20 > 1.) go to COSE and ask for a "null signature", >=20 > [JLS] For suggesting this, you should have all of you security = credentials revoked. The idea of deliberately introducing a way to take = the security value of COSE signatures to zero is something that should = be staked like a vampire and not allowed to continue. I strongly = believe that this is a fatal flaw in the current JOSE security suite and = have several times deliberated writing a document to remove the "null = signature" from JOSE. While it is bad to have signatures which are no = longer adequately secure, having one with zero security is just brain = dead. >=20 > 2.) go to ACE and ask for an "unsigned token" option, or >=20 > [JLS] I don't have a problem with this, I am not sure that I see any = reason for it however. See below. >=20 > 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., = that are not signed). > [JLS] I don't see any difference between this and option #2 >=20 > [JLS] > 4.) Just write your CWT code in a sensible manner. >=20 > My CWT code base does not make any assumptions about the number or=20 > order of COSE security wrapping layers on a token. It thus looks like >=20 > while (true) { > if input has a COSE_Encrypt tag { decrypt it; set input to the = content; save the encryption information if needed e.g. shared key = authentication; continue; } > if input has a COSE_MAC tag { validate it; set input to the = content; save the MAC information if needed e.g. shared key = authentication; continue;} > if input has a COSE_Signature tag { validate it; set input to the = content; save the signer information; continue } > if input is a map - return input as the set of claims; > throw an exception because it is not the correct format. > } >=20 > This does not require a tag for a naked set of claims and would allow = that set of claims to be pass in the same place as a CWT can be passed. = What you are suggesting would require extra code to exist someplace that = is going to check for an additional tag. It is also going to lead to = people thinking that this new tag should be legal to place inside of a = CWT. After all it makes more sense to always include it than to just = sometimes include it. This would be more of an issue if an array rather = than a map was being used to carry the claims as there would be a chance = to not know what type of security wrapper exists. >=20 > [JLS END] >=20 >=20 > At the last RATS virtual interim there was no certainty how to = approach this. So this is a call out. COSE, ACE, and CBOR, how would you = approach this "unsigned CWT Claims Set" requirement? >=20 > If one of the three options highlighted above is out of the question, = please say so (and please elaborate on the why for the sake of helping = the RATS WG understand why that is not a good idea). >=20 > If one of the three options looks like a low hanging fruit & viable, = please say so (and... you know the drill). >=20 > I hope that this email contains all the information required to help=20 > the RATS WG in this call out to other WGs. If it does not, please say=20 > so :) >=20 > Last but not least, if there are other relevant WGs or experts that = could lend opinions or alternatives, let us know. >=20 > Viele Gr=C3=BC=C3=9Fe, >=20 > Henk >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Thu Mar 5 14:43: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 4422F3A0DA0; Thu, 5 Mar 2020 14:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 vh4E4tGch25P; Thu, 5 Mar 2020 14:43:30 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7CE3A0D95; Thu, 5 Mar 2020 14:43:30 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3C6823897A; Thu, 5 Mar 2020 17:42:20 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3DDF9108A; Thu, 5 Mar 2020 17:43:28 -0500 (EST) From: Michael Richardson To: rats@ietf.org, ace@ietf.org, cbor@ietf.org In-Reply-To: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 22:43:34 -0000 --=-=-= Content-Type: text/plain { I found Jim's very interesting email very hard to read without good quoting, I'm repeating the important part } henk> 2.) go to ACE and ask for an "unsigned token" option, or Jim Schaad wrote: jls> I don't have a problem with this, I am not sure that I see any jls> reason for it however. See below. henk> 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., henk> that are not signed). jls> I don't see any difference between this and option #2 jls> 4.) Just write your CWT code in a sensible manner. jls> My CWT code base does not make any assumptions about the number or jls> order of COSE security wrapping layers on a token. It thus looks jls> like jls> while (true) { jls> if input has a COSE_Encrypt tag { decrypt it; set input to the content; save the encryption information if needed e.g. shared key authentication; continue; } jls> if input has a COSE_MAC tag { validate it; set input to the content; save the MAC information if needed e.g. shared key authentication; continue;} jls> if input has a COSE_Signature tag { validate it; set input to the content; save the signer information; continue } jls> if input is a map - return input as the set of claims; jls> throw an exception because it is not the correct format. jls> } jls> This does not require a tag for a naked set of claims and would jls> allow that set of claims to be pass in the same place as a CWT can jls> be passed. What you are suggesting would require extra code to jls> exist someplace that is going to check for an additional tag. jls> IT IS jls> ALSO GOING TO LEAD TO PEOPLE THINKING THAT THIS NEW TAG SHOULD BE jls> LEGAL TO PLACE INSIDE OF A CWT. After all it makes more sense to jls> always include it than to just sometimes include it. Emphasis mine. So your suggestion is to do nothing. I also wondered why that wouldn't work, but I hadn't written enough code to ask the question intelligently. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl5hgI8ACgkQgItw+93Q 3WVFmAf9HuWf5vQH5hl78dS7wv14UNGY8eimlLiiJCXKKts6McvGcO4zKeqE6v9w 3yGv2eUeVjgeexj5EY0FPAiVbNQEhTeOu/a5/bOxNnE49qh/pJ7il3YcAVKyWGRi F/fs8irCVYePSFn5ZoctLY/TA+PorOEG0/77LbqGFi7RZkj+DVEqf81hs/jR21me djHKOtXQ8QCZDw1UXAsIMZof5bypxsuAZ2QUnZGx5LKJzv/98D7Ypm66TEXpdkPY 9DL2OvfWvBJkCQY5wTl13qUXY8BFzd4fQsa81eO3pLRKh/WHNCcQCQYskY0bc5m7 C0RYd4BYQLmNUQHx/BFxOYrTb6cRKg== =hh77 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 5 16:48: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 E52683A0FAE; Thu, 5 Mar 2020 16:47:56 -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, 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 zwe3eX5euY03; Thu, 5 Mar 2020 16:47:54 -0800 (PST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (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 46EFF3A0FAC; Thu, 5 Mar 2020 16:47:54 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2020 16:47:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,520,1574150400"; d="scan'208";a="241009530" Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8]) by orsmga003.jf.intel.com with ESMTP; 05 Mar 2020 16:47:53 -0800 Received: from orsmsx108.amr.corp.intel.com ([169.254.2.232]) by ORSMSX110.amr.corp.intel.com ([169.254.10.107]) with mapi id 14.03.0439.000; Thu, 5 Mar 2020 16:47:52 -0800 From: "Smith, Ned" To: Michael Richardson , "rats@ietf.org" , "ace@ietf.org" , "cbor@ietf.org" Thread-Topic: [Rats] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? Thread-Index: AQHV8m3bGOeJvfyngU+T/FkyTZFx26g7IDoA//+cpQA= Date: Fri, 6 Mar 2020 00:47:52 +0000 Message-ID: <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <12861.1583448208@localhost> In-Reply-To: <12861.1583448208@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 x-originating-ip: [10.254.184.168] Content-Type: text/plain; charset="utf-8" Content-ID: <1B06A3561797C344B84C742417202202@intel.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Cbor] [Rats] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 00:47:57 -0000 TXkgaW50ZXJwcmV0YXRpb24gb2YgdGhpcyB0aHJlYWQgd2FzIHRoYXQgQ1dUIHNwZWMgcmVxdWly ZXMgYXQgbGVhc3Qgb25lIG9mIChDT1NFX0VuY3J5cHQsIENPU0VfTUFDLCBDT1NFX1NpZ25hdHVy ZSkgb3IgaXQgaXNuJ3QgdmFsaWQgQ09TRS4gVGhhdCBpbXBsaWVzIHRoZSBwYXJzZXIgc2hvdWxk IG5ldmVyIGdldCB0byAiaWYgaW5wdXQgaXMgYSBtYXAiIGFzIGl0IGlzbid0IHZhbGlkIENPU0Uu IA0KDQpJZiB0aGUgYWJvdmUgaW50ZXJwcmV0YXRpb24gaXNuJ3QgdHJ1ZSB0aGVuIHRoZSAnZG8g bm90aGluZycgb3B0aW9uIGlzIGJlc3QuDQoNCi1OZWQNCg0K77u/T24gMy81LzIwLCAyOjQzIFBN LCAiUkFUUyBvbiBiZWhhbGYgb2YgTWljaGFlbCBSaWNoYXJkc29uIiA8cmF0cy1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBtY3IraWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KDQogICAg DQogICAgeyBJIGZvdW5kIEppbSdzIHZlcnkgaW50ZXJlc3RpbmcgZW1haWwgdmVyeSBoYXJkIHRv IHJlYWQgd2l0aG91dCBnb29kDQogICAgcXVvdGluZywgSSdtIHJlcGVhdGluZyB0aGUgaW1wb3J0 YW50IHBhcnQgfQ0KICAgIA0KICAgICAgICBoZW5rPiAyLikgZ28gdG8gQUNFIGFuZCBhc2sgZm9y IGFuICJ1bnNpZ25lZCB0b2tlbiIgb3B0aW9uLCBvcg0KICAgIA0KICAgIEppbSBTY2hhYWQgPGll dGZAYXVndXN0Y2VsbGFycy5jb20+IHdyb3RlOg0KICAgICAgICBqbHM+IEkgZG9uJ3QgaGF2ZSBh IHByb2JsZW0gd2l0aCB0aGlzLCBJIGFtIG5vdCBzdXJlIHRoYXQgSSBzZWUgYW55DQogICAgICAg IGpscz4gcmVhc29uIGZvciBpdCBob3dldmVyLiAgU2VlIGJlbG93Lg0KICAgIA0KICAgICAgICBo ZW5rPiAzLikgZ28gdG8gQ0JPUiBhbmQgYXNrIGZvciBhIHRhZyBmb3IgIm5ha2VkIiBDV1QgQ2xh aW0gU2V0cyAoaS5lLiwNCiAgICAgICAgaGVuaz4gdGhhdCBhcmUgbm90IHNpZ25lZCkuDQogICAg DQogICAgICAgIGpscz4gSSBkb24ndCBzZWUgYW55IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGlzIGFu ZCBvcHRpb24gIzINCiAgICANCiAgICAgICAgamxzPiA0LikgSnVzdCB3cml0ZSB5b3VyIENXVCBj b2RlIGluIGEgc2Vuc2libGUgbWFubmVyLg0KICAgIA0KICAgICAgICBqbHM+IE15IENXVCBjb2Rl IGJhc2UgZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIG51bWJlciBvcg0K ICAgICAgICBqbHM+IG9yZGVyIG9mIENPU0Ugc2VjdXJpdHkgd3JhcHBpbmcgbGF5ZXJzIG9uIGEg dG9rZW4uICBJdCB0aHVzIGxvb2tzDQogICAgICAgIGpscz4gbGlrZQ0KICAgIA0KICAgICAgICBq bHM+IHdoaWxlICh0cnVlKSB7DQogICAgICAgIGpscz4gaWYgaW5wdXQgaGFzIGEgQ09TRV9FbmNy eXB0IHRhZyB7IGRlY3J5cHQgaXQ7IHNldCBpbnB1dCB0byB0aGUgY29udGVudDsgc2F2ZSB0aGUg ZW5jcnlwdGlvbiBpbmZvcm1hdGlvbiBpZiBuZWVkZWQgZS5nLiBzaGFyZWQga2V5IGF1dGhlbnRp Y2F0aW9uOyBjb250aW51ZTsgfQ0KICAgICAgICBqbHM+IGlmIGlucHV0IGhhcyBhIENPU0VfTUFD IHRhZyB7IHZhbGlkYXRlIGl0OyBzZXQgaW5wdXQgdG8gdGhlIGNvbnRlbnQ7IHNhdmUgdGhlIE1B QyBpbmZvcm1hdGlvbiBpZiBuZWVkZWQgZS5nLiBzaGFyZWQga2V5IGF1dGhlbnRpY2F0aW9uOyBj b250aW51ZTt9DQogICAgICAgIGpscz4gaWYgaW5wdXQgaGFzIGEgQ09TRV9TaWduYXR1cmUgdGFn IHsgdmFsaWRhdGUgaXQ7IHNldCBpbnB1dCB0byB0aGUgY29udGVudDsgc2F2ZSB0aGUgc2lnbmVy IGluZm9ybWF0aW9uOyBjb250aW51ZSB9DQogICAgICAgIGpscz4gaWYgaW5wdXQgaXMgYSBtYXAg LSByZXR1cm4gaW5wdXQgYXMgdGhlIHNldCBvZiBjbGFpbXM7DQogICAgICAgIGpscz4gdGhyb3cg YW4gZXhjZXB0aW9uIGJlY2F1c2UgaXQgaXMgbm90IHRoZSBjb3JyZWN0IGZvcm1hdC4NCiAgICAg ICAgamxzPiB9DQogICAgDQogICAgICAgIGpscz4gVGhpcyBkb2VzIG5vdCByZXF1aXJlIGEgdGFn IGZvciBhIG5ha2VkIHNldCBvZiBjbGFpbXMgYW5kIHdvdWxkDQogICAgICAgIGpscz4gYWxsb3cg dGhhdCBzZXQgb2YgY2xhaW1zIHRvIGJlIHBhc3MgaW4gdGhlIHNhbWUgcGxhY2UgYXMgYSBDV1Qg Y2FuDQogICAgICAgIGpscz4gYmUgcGFzc2VkLiAgV2hhdCB5b3UgYXJlIHN1Z2dlc3Rpbmcgd291 bGQgcmVxdWlyZSBleHRyYSBjb2RlIHRvDQogICAgICAgIGpscz4gZXhpc3Qgc29tZXBsYWNlIHRo YXQgaXMgZ29pbmcgdG8gY2hlY2sgZm9yIGFuIGFkZGl0aW9uYWwgdGFnLg0KICAgIA0KICAgICAg ICBqbHM+IElUIElTDQogICAgICAgIGpscz4gQUxTTyBHT0lORyBUTyBMRUFEIFRPIFBFT1BMRSBU SElOS0lORyBUSEFUIFRISVMgTkVXIFRBRyBTSE9VTEQgQkUNCiAgICAgICAgamxzPiBMRUdBTCBU TyBQTEFDRSBJTlNJREUgT0YgQSBDV1QuICBBZnRlciBhbGwgaXQgbWFrZXMgbW9yZSBzZW5zZSB0 bw0KICAgICAgICBqbHM+IGFsd2F5cyBpbmNsdWRlIGl0IHRoYW4gdG8ganVzdCBzb21ldGltZXMg aW5jbHVkZSBpdC4NCiAgICANCiAgICBFbXBoYXNpcyBtaW5lLg0KICAgIFNvIHlvdXIgc3VnZ2Vz dGlvbiBpcyB0byBkbyBub3RoaW5nLg0KICAgIEkgYWxzbyB3b25kZXJlZCB3aHkgdGhhdCB3b3Vs ZG4ndCB3b3JrLCBidXQgSSBoYWRuJ3Qgd3JpdHRlbiBlbm91Z2ggY29kZSB0bw0KICAgIGFzayB0 aGUgcXVlc3Rpb24gaW50ZWxsaWdlbnRseS4NCiAgICANCiAgICAtLQ0KICAgIE1pY2hhZWwgUmlj aGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtz DQogICAgIC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCiAgICANCg0K From nobody Thu Mar 5 18:16: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 2C7D53A10FB; Thu, 5 Mar 2020 18:16:05 -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, 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 ObesZezDUkgt; Thu, 5 Mar 2020 18:16:02 -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 3EC473A10F7; Thu, 5 Mar 2020 18:16:01 -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; Thu, 5 Mar 2020 18:15:55 -0800 From: Jim Schaad To: "'Smith, Ned'" , 'Michael Richardson' , , , References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <12861.1583448208@localhost> <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> In-Reply-To: <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> Date: Thu, 5 Mar 2020 18:15:54 -0800 Message-ID: <017f01d5f35d$2c422c60$84c68520$@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: AQIPc7l4+GCW+nItGLs4R66gGWmpXQHDaFTrAg5IEhsBMlW0mKefsMNQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 02:16:06 -0000 I would not claim that a collection of CWT claims is a CWT. I would = agree that a CWT does require that some security be applied. I was = instead making the argument that there was no need to have a special = marking for the collection as oppose to the CWT since it is possible to = distinguish the cases apart. In CDDL I would put something like claimsMade =3D CWT / claimsMap=20 where the CWT is over a claimsMap element. In this case one could = easily distinguish between the two cases without additional tagging. Jim -----Original Message----- From: Ace On Behalf Of Smith, Ned Sent: Thursday, March 5, 2020 4:48 PM To: Michael Richardson ; rats@ietf.org; = ace@ietf.org; cbor@ietf.org Subject: Re: [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a = CWT or not to be a CWT? My interpretation of this thread was that CWT spec requires at least one = of (COSE_Encrypt, COSE_MAC, COSE_Signature) or it isn't valid COSE. That = implies the parser should never get to "if input is a map" as it isn't = valid COSE.=20 If the above interpretation isn't true then the 'do nothing' option is = best. -Ned =EF=BB=BFOn 3/5/20, 2:43 PM, "RATS on behalf of Michael Richardson" = wrote: =20 { I found Jim's very interesting email very hard to read without = good quoting, I'm repeating the important part } =20 henk> 2.) go to ACE and ask for an "unsigned token" option, or =20 Jim Schaad wrote: jls> I don't have a problem with this, I am not sure that I see = any jls> reason for it however. See below. =20 henk> 3.) go to CBOR and ask for a tag for "naked" CWT Claim = Sets (i.e., henk> that are not signed). =20 jls> I don't see any difference between this and option #2 =20 jls> 4.) Just write your CWT code in a sensible manner. =20 jls> My CWT code base does not make any assumptions about the = number or jls> order of COSE security wrapping layers on a token. It thus = looks jls> like =20 jls> while (true) { jls> if input has a COSE_Encrypt tag { decrypt it; set input to = the content; save the encryption information if needed e.g. shared key = authentication; continue; } jls> if input has a COSE_MAC tag { validate it; set input to the = content; save the MAC information if needed e.g. shared key = authentication; continue;} jls> if input has a COSE_Signature tag { validate it; set input = to the content; save the signer information; continue } jls> if input is a map - return input as the set of claims; jls> throw an exception because it is not the correct format. jls> } =20 jls> This does not require a tag for a naked set of claims and = would jls> allow that set of claims to be pass in the same place as a = CWT can jls> be passed. What you are suggesting would require extra = code to jls> exist someplace that is going to check for an additional = tag. =20 jls> IT IS jls> ALSO GOING TO LEAD TO PEOPLE THINKING THAT THIS NEW TAG = SHOULD BE jls> LEGAL TO PLACE INSIDE OF A CWT. After all it makes more = sense to jls> always include it than to just sometimes include it. =20 Emphasis mine. So your suggestion is to do nothing. I also wondered why that wouldn't work, but I hadn't written enough = code to ask the question intelligently. =20 -- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- =20 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Thu Mar 5 23:35:42 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 EB4153A0904; Thu, 5 Mar 2020 23:35:28 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 ttFzycSoZVvE; Thu, 5 Mar 2020 23:35:26 -0800 (PST) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 40BE03A0903; Thu, 5 Mar 2020 23:35:26 -0800 (PST) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 0267ZH7F013379 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Fri, 6 Mar 2020 08:35:18 +0100 Received: from [192.168.16.50] (79.206.149.19) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 6 Mar 2020 08:35:12 +0100 To: Jim Schaad , "'Smith, Ned'" , "'Michael Richardson'" , , , References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <12861.1583448208@localhost> <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> <017f01d5f35d$2c422c60$84c68520$@augustcellars.com> From: Henk Birkholz Message-ID: Date: Fri, 6 Mar 2020 08:35:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <017f01d5f35d$2c422c60$84c68520$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.149.19] Archived-At: Subject: Re: [Cbor] [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 07:35:29 -0000 Hi Jim, from an implementation point of view that is fine. To quote Carsten here "tags are cheap" and you would have to parse the whole structure to make sure it is an EAT Claims Set. My point is, it does not hurt to register a CBOR tag for an unsigned EAT Claims Set that adheres to the some content definitions as EAT, but that is not signed via a COSE array. In contrast, in most cases it does help, I think, and enables a clear semantic equivalence for the content. Viele Grüße, Henk On 06.03.20 03:15, Jim Schaad wrote: > I would not claim that a collection of CWT claims is a CWT. I would agree that a CWT does require that some security be applied. I was instead making the argument that there was no need to have a special marking for the collection as oppose to the CWT since it is possible to distinguish the cases apart. In CDDL I would put something like > > claimsMade = CWT / claimsMap > > where the CWT is over a claimsMap element. In this case one could easily distinguish between the two cases without additional tagging. > > Jim > > > -----Original Message----- > From: Ace On Behalf Of Smith, Ned > Sent: Thursday, March 5, 2020 4:48 PM > To: Michael Richardson ; rats@ietf.org; ace@ietf.org; cbor@ietf.org > Subject: Re: [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? > > My interpretation of this thread was that CWT spec requires at least one of (COSE_Encrypt, COSE_MAC, COSE_Signature) or it isn't valid COSE. That implies the parser should never get to "if input is a map" as it isn't valid COSE. > > If the above interpretation isn't true then the 'do nothing' option is best. > > -Ned > > On 3/5/20, 2:43 PM, "RATS on behalf of Michael Richardson" wrote: > > > { I found Jim's very interesting email very hard to read without good > quoting, I'm repeating the important part } > > henk> 2.) go to ACE and ask for an "unsigned token" option, or > > Jim Schaad wrote: > jls> I don't have a problem with this, I am not sure that I see any > jls> reason for it however. See below. > > henk> 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., > henk> that are not signed). > > jls> I don't see any difference between this and option #2 > > jls> 4.) Just write your CWT code in a sensible manner. > > jls> My CWT code base does not make any assumptions about the number or > jls> order of COSE security wrapping layers on a token. It thus looks > jls> like > > jls> while (true) { > jls> if input has a COSE_Encrypt tag { decrypt it; set input to the content; save the encryption information if needed e.g. shared key authentication; continue; } > jls> if input has a COSE_MAC tag { validate it; set input to the content; save the MAC information if needed e.g. shared key authentication; continue;} > jls> if input has a COSE_Signature tag { validate it; set input to the content; save the signer information; continue } > jls> if input is a map - return input as the set of claims; > jls> throw an exception because it is not the correct format. > jls> } > > jls> This does not require a tag for a naked set of claims and would > jls> allow that set of claims to be pass in the same place as a CWT can > jls> be passed. What you are suggesting would require extra code to > jls> exist someplace that is going to check for an additional tag. > > jls> IT IS > jls> ALSO GOING TO LEAD TO PEOPLE THINKING THAT THIS NEW TAG SHOULD BE > jls> LEGAL TO PLACE INSIDE OF A CWT. After all it makes more sense to > jls> always include it than to just sometimes include it. > > Emphasis mine. > So your suggestion is to do nothing. > I also wondered why that wouldn't work, but I hadn't written enough code to > ask the question intelligently. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > From nobody Fri Mar 6 02:31:23 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 122FF3A0C39; Fri, 6 Mar 2020 02:31:14 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 PYte2hYCtFs3; Fri, 6 Mar 2020 02:31:11 -0800 (PST) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 47E703A0C3C; Fri, 6 Mar 2020 02:31:09 -0800 (PST) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 026AUwVp022087 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Fri, 6 Mar 2020 11:30:58 +0100 Received: from [192.168.16.50] (79.206.149.19) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 6 Mar 2020 11:30:53 +0100 From: Henk Birkholz To: Jim Schaad , "'Smith, Ned'" , "'Michael Richardson'" , , , References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <12861.1583448208@localhost> <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> <017f01d5f35d$2c422c60$84c68520$@augustcellars.com> Message-ID: <600c2555-75af-a4dc-98c8-206a91b1af52@sit.fraunhofer.de> Date: Fri, 6 Mar 2020 11:30:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.149.19] Archived-At: Subject: Re: [Cbor] [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 10:31:14 -0000 Please let me correct myself: My proposal is to simply assign a single CBOR tag for unsigned (aka "naked") CWT Claims sets. I wrote "EAT" Claims Set before and that made me loose the perspective that an EAT is a CWT (I should read my own subject more often...). I think this is useful outside of RATS as well and will start a corresponding draft in RATS to create a more tangible proposal that elaborates on motivation & background: as with YANG modules, CBOR tags can be defined in any WG. There are multiple benefits to this approach: * parsers can choose to ignore tags in any case, * it is the least invasive approach (next to doing nothing), * we will not be the ones that attempt to reopen RFC8392, and * we detach this effort from progressing EAT as it is CWT-related. Viele Grüße, Henk On 06.03.20 08:35, Henk Birkholz wrote: > Hi Jim, > > from an implementation point of view that is fine. To quote Carsten here > "tags are cheap" and you would have to parse the whole structure to make > sure it is an EAT Claims Set. My point is, it does not hurt to register > a CBOR tag for an unsigned EAT Claims Set that adheres to the some > content definitions as EAT, but that is not signed via a COSE array. In > contrast, in most cases it does help, I think, and enables a clear > semantic equivalence for the content. > > Viele Grüße, > > Henk > > On 06.03.20 03:15, Jim Schaad wrote: >> I would not claim that a collection of CWT claims is a CWT.  I would >> agree that a CWT does require that some security be applied.  I was >> instead making the argument that there was no need to have a special >> marking for the collection as oppose to the CWT since it is possible >> to distinguish the cases apart.   In CDDL I would put something like >> >> claimsMade = CWT / claimsMap >> >> where the CWT is over a claimsMap element.   In this case one could >> easily distinguish between the two cases without additional tagging. >> >> Jim >> >> >> -----Original Message----- >> From: Ace On Behalf Of Smith, Ned >> Sent: Thursday, March 5, 2020 4:48 PM >> To: Michael Richardson ; rats@ietf.org; >> ace@ietf.org; cbor@ietf.org >> Subject: Re: [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be >> a CWT or not to be a CWT? >> >> My interpretation of this thread was that CWT spec requires at least >> one of (COSE_Encrypt, COSE_MAC, COSE_Signature) or it isn't valid >> COSE. That implies the parser should never get to "if input is a map" >> as it isn't valid COSE. >> >> If the above interpretation isn't true then the 'do nothing' option is >> best. >> >> -Ned >> >> On 3/5/20, 2:43 PM, "RATS on behalf of Michael Richardson" >> wrote: >> >>      { I found Jim's very interesting email very hard to read without >> good >>      quoting, I'm repeating the important part } >>          henk> 2.) go to ACE and ask for an "unsigned token" option, or >>      Jim Schaad wrote: >>          jls> I don't have a problem with this, I am not sure that I >> see any >>          jls> reason for it however.  See below. >>          henk> 3.) go to CBOR and ask for a tag for "naked" CWT Claim >> Sets (i.e., >>          henk> that are not signed). >>          jls> I don't see any difference between this and option #2 >>          jls> 4.) Just write your CWT code in a sensible manner. >>          jls> My CWT code base does not make any assumptions about the >> number or >>          jls> order of COSE security wrapping layers on a token.  It >> thus looks >>          jls> like >>          jls> while (true) { >>          jls> if input has a COSE_Encrypt tag { decrypt it; set input >> to the content; save the encryption information if needed e.g. shared >> key authentication; continue; } >>          jls> if input has a COSE_MAC tag { validate it; set input to >> the content; save the MAC information if needed e.g. shared key >> authentication; continue;} >>          jls> if input has a COSE_Signature tag { validate it; set >> input to the content; save the signer information; continue } >>          jls> if input is a map - return input as the set of claims; >>          jls> throw an exception because it is not the correct format. >>          jls> } >>          jls> This does not require a tag for a naked set of claims >> and would >>          jls> allow that set of claims to be pass in the same place as >> a CWT can >>          jls> be passed.  What you are suggesting would require extra >> code to >>          jls> exist someplace that is going to check for an additional >> tag. >>          jls> IT IS >>          jls> ALSO GOING TO LEAD TO PEOPLE THINKING THAT THIS NEW TAG >> SHOULD BE >>          jls> LEGAL TO PLACE INSIDE OF A CWT.  After all it makes more >> sense to >>          jls> always include it than to just sometimes include it. >>      Emphasis mine. >>      So your suggestion is to do nothing. >>      I also wondered why that wouldn't work, but I hadn't written >> enough code to >>      ask the question intelligently. >>      -- >>      Michael Richardson , Sandelman Software Works >>       -= IPv6 IoT consulting =- >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >> From nobody Fri Mar 6 07:40: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 C60BB3A09EA for ; Fri, 6 Mar 2020 07:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 HjbGJ3q-3wlZ for ; Fri, 6 Mar 2020 07:40:29 -0800 (PST) Received: from p3plsmtpa08-02.prod.phx3.secureserver.net (p3plsmtpa08-02.prod.phx3.secureserver.net [173.201.193.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DA53A09F8 for ; Fri, 6 Mar 2020 07:40:29 -0800 (PST) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id AF3EjuKphgX5OAF3Ej4HdA; Fri, 06 Mar 2020 08:38:12 -0700 X-CMAE-Analysis: v=2.3 cv=H/ulPNQi c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=0XtbOteLAAAA:20 a=48vgC7mUAAAA:8 a=l70xHGcnAAAA:8 a=VrHXGImtAAAA:8 a=mN-y9S7DSJMA7-8zbsQA:9 a=fezamol0LgihQ5Ud:21 a=0iCgnroI_H31GVVk:21 a=QEXdDO2ut3YA:10 a=-RoEEKskQ1sA:10 a=hiN3_Khlxz5gRMh4U6AA:9 a=LG3yvq6I43YsfyTC:21 a=su3LXDZAtqDTm6Wg:21 a=QG3mCUyt7ZD5F6Ra:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=JtN_ecm89k2WOvw5-HMO:22 a=rjybpTLx1R2UrS7S5igv:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1A895FF5-6C48-4DF1-996D-3909BE72750D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 6 Mar 2020 07:38:11 -0800 In-Reply-To: <600c2555-75af-a4dc-98c8-206a91b1af52@sit.fraunhofer.de> Cc: Jim Schaad , "Smith, Ned" , Michael Richardson , rats@ietf.org, ace@ietf.org, cbor@ietf.org To: Henk Birkholz References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <12861.1583448208@localhost> <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> <017f01d5f35d$2c422c60$84c68520$@augustcellars.com> <600c2555-75af-a4dc-98c8-206a91b1af52@sit.fraunhofer.de> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfCnXA7IDimf9l8UTbqD7FLTv/LIbhl8AgK8bXfy5JLAhfaBYq/S3fJ0p1oWv6tyesVz5ZpHMBcoQ4k/VMX2g2/ppMAZNVjqdhgR7Yk1f9s/RJtdJ2N0p zCAM5z9xn1VdeRf1WykWndkqMBHUBN+3rt1yg0g29t1T8ph1IrOkgYqa3NGyBxXy/+VzV97fJ0yGU5i+AD+niZ2TOVCrjkH2LecjaJR6p2+hPGByIm1ua3MH 3tuFv3jA0Phafqtb4euHdHS1shOSF7sD2QFU91n+fMRgahoQbSupyrWvgDOunHThsqigkOVkNwwYFWtgKkxE4aLJUVqVR5UipZKpGRqE6Jvc727QWZ3WdpAp DLzrk9pU Archived-At: Subject: Re: [Cbor] [Rats] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 15:40:32 -0000 --Apple-Mail=_1A895FF5-6C48-4DF1-996D-3909BE72750D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So far, there are three things we have turned up in work on EAT that we = would like considered as changes to CWT. 1) Naked CWT=E2=80=99s, probably tagged The point of the tag would be for use in protocols where you can=E2=80=99t= tell a naked CWT is a CWT by the context of the protocol. So far we = seem to always assign a tag to new CBOR data structures for this = purpose. For naked CWT=E2=80=99s, it seems we really should have the = tag, even if it makes Jim=E2=80=99s code larger. 2) Disallow floating point dates Right now CWT allows dates like the expiration date to be floating = point. The only use of floating point dates is fractional seconds and = dates so large they are not human time scale. As it stands a CWT decoder = MUST implement floating point. This is a substantial burden for no good = reason at all. One option here is an incompatible change to these data = items. Another is to define new integer-only data items (new = labels/keys) for the same data items. 3) Claims Characteristics for new registered claims A lot of people had a lot of opinions and points on what data formats = and types and such were used for claims back in 2019 in EAT. I = (hopefully) captured most of that in some recommendations for claims = characteristics. Text is currently here in a PR against the EAT draft = , but it seems it really = should be for all CWT claims. I don=E2=80=99t know if there are more things EAT would like to change = in CWT. Or maybe there are other uses of CWT that would like to change = it. I proposed that EAT be an update to the CWT RFC. Dave Thaler said they = should probably be separate from EAT and handled in the ACE WG and that = made sense to most of us. Seems to me that a new RFC that either updates = or obsoletes 8392 would be the thing to do, but maybe there are other = ways.=20 LL > On Mar 6, 2020, at 2:30 AM, Henk Birkholz = wrote: >=20 > Please let me correct myself: >=20 > My proposal is to simply assign a single CBOR tag for unsigned (aka = "naked") CWT Claims sets. I wrote "EAT" Claims Set before and that made = me loose the perspective that an EAT is a CWT (I should read my own = subject more often...). >=20 > I think this is useful outside of RATS as well and will start a = corresponding draft in RATS to create a more tangible proposal that = elaborates on motivation & background: as with YANG modules, CBOR tags = can be defined in any WG. >=20 > There are multiple benefits to this approach: >=20 > * parsers can choose to ignore tags in any case, > * it is the least invasive approach (next to doing nothing), > * we will not be the ones that attempt to reopen RFC8392, and > * we detach this effort from progressing EAT as it is CWT-related. >=20 > Viele Gr=C3=BC=C3=9Fe, >=20 > Henk >=20 >=20 > On 06.03.20 08:35, Henk Birkholz wrote: >> Hi Jim, >> from an implementation point of view that is fine. To quote Carsten = here "tags are cheap" and you would have to parse the whole structure to = make sure it is an EAT Claims Set. My point is, it does not hurt to = register a CBOR tag for an unsigned EAT Claims Set that adheres to the = some content definitions as EAT, but that is not signed via a COSE = array. In contrast, in most cases it does help, I think, and enables a = clear semantic equivalence for the content. >> Viele Gr=C3=BC=C3=9Fe, >> Henk >> On 06.03.20 03:15, Jim Schaad wrote: >>> I would not claim that a collection of CWT claims is a CWT. I would = agree that a CWT does require that some security be applied. I was = instead making the argument that there was no need to have a special = marking for the collection as oppose to the CWT since it is possible to = distinguish the cases apart. In CDDL I would put something like >>>=20 >>> claimsMade =3D CWT / claimsMap >>>=20 >>> where the CWT is over a claimsMap element. In this case one could = easily distinguish between the two cases without additional tagging. >>>=20 >>> Jim >>>=20 >>>=20 >>> -----Original Message----- >>> From: Ace On Behalf Of Smith, Ned >>> Sent: Thursday, March 5, 2020 4:48 PM >>> To: Michael Richardson ; rats@ietf.org; = ace@ietf.org; cbor@ietf.org >>> Subject: Re: [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to = be a CWT or not to be a CWT? >>>=20 >>> My interpretation of this thread was that CWT spec requires at least = one of (COSE_Encrypt, COSE_MAC, COSE_Signature) or it isn't valid COSE. = That implies the parser should never get to "if input is a map" as it = isn't valid COSE. >>>=20 >>> If the above interpretation isn't true then the 'do nothing' option = is best. >>>=20 >>> -Ned >>>=20 >>> =EF=BB=BFOn 3/5/20, 2:43 PM, "RATS on behalf of Michael Richardson" = wrote: >>>=20 >>> { I found Jim's very interesting email very hard to read = without good >>> quoting, I'm repeating the important part } >>> henk> 2.) go to ACE and ask for an "unsigned token" option, = or >>> Jim Schaad wrote: >>> jls> I don't have a problem with this, I am not sure that I = see any >>> jls> reason for it however. See below. >>> henk> 3.) go to CBOR and ask for a tag for "naked" CWT = Claim Sets (i.e., >>> henk> that are not signed). >>> jls> I don't see any difference between this and option #2 >>> jls> 4.) Just write your CWT code in a sensible manner. >>> jls> My CWT code base does not make any assumptions about = the number or >>> jls> order of COSE security wrapping layers on a token. It = thus looks >>> jls> like >>> jls> while (true) { >>> jls> if input has a COSE_Encrypt tag { decrypt it; set = input to the content; save the encryption information if needed e.g. = shared key authentication; continue; } >>> jls> if input has a COSE_MAC tag { validate it; set input = to the content; save the MAC information if needed e.g. shared key = authentication; continue;} >>> jls> if input has a COSE_Signature tag { validate it; set = input to the content; save the signer information; continue } >>> jls> if input is a map - return input as the set of claims; >>> jls> throw an exception because it is not the correct = format. >>> jls> } >>> jls> This does not require a tag for a naked set of claims = and would >>> jls> allow that set of claims to be pass in the same place = as a CWT can >>> jls> be passed. What you are suggesting would require = extra code to >>> jls> exist someplace that is going to check for an = additional tag. >>> jls> IT IS >>> jls> ALSO GOING TO LEAD TO PEOPLE THINKING THAT THIS NEW = TAG SHOULD BE >>> jls> LEGAL TO PLACE INSIDE OF A CWT. After all it makes = more sense to >>> jls> always include it than to just sometimes include it. >>> Emphasis mine. >>> So your suggestion is to do nothing. >>> I also wondered why that wouldn't work, but I hadn't written = enough code to >>> ask the question intelligently. >>> -- >>> Michael Richardson , Sandelman Software = Works >>> -=3D IPv6 IoT consulting =3D- >>>=20 >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>>=20 >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>>=20 >=20 > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats --Apple-Mail=_1A895FF5-6C48-4DF1-996D-3909BE72750D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
So far, there are three things we have turned up in work on = EAT that we would like considered as changes to CWT.

1) Naked CWT=E2=80=99s, = probably tagged
The point of the tag would be for = use in protocols where you can=E2=80=99t tell a naked CWT is a CWT by = the context of the protocol. So far we seem to always assign a tag to = new CBOR data structures for this purpose. For naked CWT=E2=80=99s, it = seems we really should have the tag, even if it makes Jim=E2=80=99s code = larger.

2) = Disallow floating point dates
Right now CWT allows = dates like the expiration date to be floating point. The only use of = floating point dates is fractional seconds and dates so large they are = not human time scale. As it stands a CWT decoder MUST implement floating = point. This is a substantial burden for no good reason at all. One = option here is an incompatible change to these data items. Another is to = define new integer-only data items (new labels/keys) for the same data = items.

3) = Claims Characteristics for new registered claims
A = lot of people had a lot of opinions and points on what data formats and = types and such were used for claims back in 2019 in EAT. I (hopefully) = captured most of that in some recommendations for claims = characteristics. Text is currently here in = a PR against the EAT draft, but it seems it really should be for all = CWT claims.


I don=E2=80=99t know if there are more = things EAT would like to change in CWT. Or maybe there are other uses of = CWT that would like to change it.


I = proposed that EAT be an update to the CWT RFC. Dave Thaler said they = should probably be separate from EAT and handled in the ACE WG and that = made sense to most of us. Seems to me that a new RFC that either updates = or obsoletes 8392 would be the thing to do, but maybe there are other = ways. 

LL


On Mar 6, 2020, at 2:30 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:

Please= let me correct myself:

My proposal is to = simply assign a single CBOR tag for unsigned (aka "naked") CWT Claims = sets. I wrote "EAT" Claims Set before and that made me loose the = perspective that an EAT is a CWT (I should read my own subject more = often...).

I think this is useful outside = of RATS as well and will start a corresponding draft in RATS to create a = more tangible proposal that elaborates on motivation & background: = as with YANG modules, CBOR tags can be defined in any WG.

There are multiple benefits to this = approach:

* parsers can choose to ignore = tags in any case,
* it is the least invasive approach = (next to doing nothing),
* we will not be the ones that = attempt to reopen RFC8392, and
* we detach this effort = from progressing EAT as it is CWT-related.

Viele Gr=C3=BC=C3=9Fe,

Henk


On 06.03.20 08:35, Henk = Birkholz wrote:
Hi = Jim,
from an implementation point of view that is fine. To = quote Carsten here "tags are cheap" and you would have to parse the = whole structure to make sure it is an EAT Claims Set. My point is, it = does not hurt to register a CBOR tag for an unsigned EAT Claims Set that = adheres to the some content definitions as EAT, but that is not signed = via a COSE array. In contrast, in most cases it does help, I think, and = enables a clear semantic equivalence for the content.
Viele = Gr=C3=BC=C3=9Fe,
Henk
On 06.03.20 03:15, Jim = Schaad wrote:
I would = not claim that a collection of CWT claims is a CWT.  I would agree = that a CWT does require that some security be applied.  I was = instead making the argument that there was no need to have a special = marking for the collection as oppose to the CWT since it is possible to = distinguish the cases apart.   In CDDL I would put something = like

claimsMade =3D CWT / claimsMap

where the CWT is over a claimsMap = element.   In this case one could easily distinguish between = the two cases without additional tagging.

Jim


-----Original = Message-----
From: Ace <ace-bounces@ietf.org> On Behalf Of Smith, Ned
Sent: Thursday, March 5, 2020 4:48 PM
To: = Michael Richardson <mcr+ietf@sandelman.ca>; rats@ietf.org; ace@ietf.org; cbor@ietf.org
Subject: Re: [Ace] [Rats] = RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a = CWT?

My interpretation of this thread was = that CWT spec requires at least one of (COSE_Encrypt, COSE_MAC, = COSE_Signature) or it isn't valid COSE. That implies the parser should = never get to "if input is a map" as it isn't valid COSE.
If the above interpretation isn't true then the 'do nothing' = option is best.

-Ned

=EF=BB=BFOn 3/5/20, 2:43 PM, "RATS on behalf of Michael = Richardson" <rats-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca> wrote:

     { I found Jim's very interesting = email very hard to read without good
     quoting, I'm repeating the important = part }
         = henk> 2.) go to ACE and ask for an "unsigned token" option, or
     Jim Schaad <ietf@augustcellars.com> wrote:
         jls> I = don't have a problem with this, I am not sure that I see any
         jls> = reason for it however.  See below.
         henk> 3.) = go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e.,
         henk> = that are not signed).
         jls> I = don't see any difference between this and option #2
         jls> 4.) = Just write your CWT code in a sensible manner.
         jls> My = CWT code base does not make any assumptions about the number or
         jls> = order of COSE security wrapping layers on a token.  It thus = looks
         = jls> like
         jls> = while (true) {
         jls> if = input has a COSE_Encrypt tag { decrypt it; set input to the content; = save the encryption information if needed e.g. shared key = authentication; continue; }
         jls> if = input has a COSE_MAC tag { validate it; set input to the content; save = the MAC information if needed e.g. shared key authentication; = continue;}
         = jls> if input has a COSE_Signature tag { validate it; set input to = the content; save the signer information; continue }
         jls> if = input is a map - return input as the set of claims;
         jls> = throw an exception because it is not the correct format.
         jls> }
         jls> This = does not require a tag for a naked set of claims and would
         jls> = allow that set of claims to be pass in the same place as a CWT can
         jls> be = passed.  What you are suggesting would require extra code to
         jls> = exist someplace that is going to check for an additional tag.
         jls> IT = IS
         = jls> ALSO GOING TO LEAD TO PEOPLE THINKING THAT THIS NEW TAG SHOULD = BE
         = jls> LEGAL TO PLACE INSIDE OF A CWT.  After all it makes more = sense to
         = jls> always include it than to just sometimes include it.
     Emphasis mine.
     So your suggestion is to do = nothing.
     I also wondered why that = wouldn't work, but I hadn't written enough code to
     ask the question intelligently.
     --
     Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
      -=3D IPv6 IoT consulting =3D-
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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


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

= --Apple-Mail=_1A895FF5-6C48-4DF1-996D-3909BE72750D-- From nobody Fri Mar 6 11:13:39 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 839123A07BA; Fri, 6 Mar 2020 11:13:25 -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, 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 x-2ZhDnGOfgE; Fri, 6 Mar 2020 11:13:22 -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 8263C3A07BF; Fri, 6 Mar 2020 11:13:21 -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; Fri, 6 Mar 2020 11:13:15 -0800 From: Jim Schaad To: 'Henk Birkholz' , , , References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <12861.1583448208@localhost> <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> <017f01d5f35d$2c422c60$84c68520$@augustcellars.com> In-Reply-To: Date: Fri, 6 Mar 2020 11:13:10 -0800 Message-ID: <01ae01d5f3eb$4a670fb0$df352f10$@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: AQIPc7l4+GCW+nItGLs4R66gGWmpXQHDaFTrAg5IEhsBMlW0mAJcsQyDAXKra+OnglFbMA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 19:13:26 -0000 Henk, I want to re-iterate that this is not quite the same no/low cost = situation that leads me to say - yes just tag it and be fine. There is a very high chance that making this change is going to lead one = into a situation where they are going to need to change their because = people are going to start using this tag all of the time and not just = when the claims are bare. That is the "unsigned CWT Claims Set" could = be passed into the a COSE library to be signed and the tag would never = be stripped. There is also a small cost in terms of message size, but I assume that = you are willing to absorb that. Jim -----Original Message----- From: Henk Birkholz =20 Sent: Thursday, March 5, 2020 11:35 PM To: Jim Schaad ; 'Smith, Ned' = ; 'Michael Richardson' ; = rats@ietf.org; ace@ietf.org; cbor@ietf.org Subject: Re: [Cbor] [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - = to be a CWT or not to be a CWT? Hi Jim, from an implementation point of view that is fine. To quote Carsten here = "tags are cheap" and you would have to parse the whole structure to make = sure it is an EAT Claims Set. My point is, it does not hurt to register = a CBOR tag for an unsigned EAT Claims Set that adheres to the some = content definitions as EAT, but that is not signed via a COSE array. In = contrast, in most cases it does help, I think, and enables a clear = semantic equivalence for the content. Viele Gr=C3=BC=C3=9Fe, Henk On 06.03.20 03:15, Jim Schaad wrote: > I would not claim that a collection of CWT claims is a CWT. I would = agree that a CWT does require that some security be applied. I was = instead making the argument that there was no need to have a special = marking for the collection as oppose to the CWT since it is possible to = distinguish the cases apart. In CDDL I would put something like >=20 > claimsMade =3D CWT / claimsMap >=20 > where the CWT is over a claimsMap element. In this case one could = easily distinguish between the two cases without additional tagging. >=20 > Jim >=20 >=20 > -----Original Message----- > From: Ace On Behalf Of Smith, Ned > Sent: Thursday, March 5, 2020 4:48 PM > To: Michael Richardson ; rats@ietf.org;=20 > ace@ietf.org; cbor@ietf.org > Subject: Re: [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be = a CWT or not to be a CWT? >=20 > My interpretation of this thread was that CWT spec requires at least = one of (COSE_Encrypt, COSE_MAC, COSE_Signature) or it isn't valid COSE. = That implies the parser should never get to "if input is a map" as it = isn't valid COSE. >=20 > If the above interpretation isn't true then the 'do nothing' option is = best. >=20 > -Ned >=20 > =EF=BB=BFOn 3/5/20, 2:43 PM, "RATS on behalf of Michael Richardson" = wrote: >=20 > =20 > { I found Jim's very interesting email very hard to read without = good > quoting, I'm repeating the important part } > =20 > henk> 2.) go to ACE and ask for an "unsigned token" option,=20 > or > =20 > Jim Schaad wrote: > jls> I don't have a problem with this, I am not sure that I = see any > jls> reason for it however. See below. > =20 > henk> 3.) go to CBOR and ask for a tag for "naked" CWT Claim = Sets (i.e., > henk> that are not signed). > =20 > jls> I don't see any difference between this and option #2 > =20 > jls> 4.) Just write your CWT code in a sensible manner. > =20 > jls> My CWT code base does not make any assumptions about the = number or > jls> order of COSE security wrapping layers on a token. It = thus looks > jls> like > =20 > jls> while (true) { > jls> if input has a COSE_Encrypt tag { decrypt it; set input = to the content; save the encryption information if needed e.g. shared = key authentication; continue; } > jls> if input has a COSE_MAC tag { validate it; set input to = the content; save the MAC information if needed e.g. shared key = authentication; continue;} > jls> if input has a COSE_Signature tag { validate it; set = input to the content; save the signer information; continue } > jls> if input is a map - return input as the set of claims; > jls> throw an exception because it is not the correct format. > jls> } > =20 > jls> This does not require a tag for a naked set of claims = and would > jls> allow that set of claims to be pass in the same place as = a CWT can > jls> be passed. What you are suggesting would require extra = code to > jls> exist someplace that is going to check for an additional = tag. > =20 > jls> IT IS > jls> ALSO GOING TO LEAD TO PEOPLE THINKING THAT THIS NEW TAG = SHOULD BE > jls> LEGAL TO PLACE INSIDE OF A CWT. After all it makes more = sense to > jls> always include it than to just sometimes include it. > =20 > Emphasis mine. > So your suggestion is to do nothing. > I also wondered why that wouldn't work, but I hadn't written = enough code to > ask the question intelligently. > =20 > -- > Michael Richardson , Sandelman Software = Works > -=3D IPv6 IoT consulting =3D- > =20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Fri Mar 6 11:24:43 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 1DF0E3A083B; Fri, 6 Mar 2020 11:24:24 -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, 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 pxNKwpMA-KKN; Fri, 6 Mar 2020 11:24:22 -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 5C54A3A0839; Fri, 6 Mar 2020 11:24:22 -0800 (PST) Received: from [192.168.217.147] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48YyGq5G9wz191b; Fri, 6 Mar 2020 20:24:19 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <01ae01d5f3eb$4a670fb0$df352f10$@augustcellars.com> Date: Fri, 6 Mar 2020 20:24:19 +0100 Cc: Henk Birkholz , rats@ietf.org, Ace Wg , cbor@ietf.org X-Mao-Original-Outgoing-Id: 605215459.201071-201240909d94d025f41c1f5a637f3497 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <12861.1583448208@localhost> <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> <017f01d5f35d$2c422c60$84c68520$@augustcellars.com> <01ae01d5f3eb$4a670fb0$df352f10$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Cbor] [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 19:24:24 -0000 Hi Jim, > On 2020-03-06, at 20:13, Jim Schaad wrote: >=20 > There is a very high chance that making this change is going to lead = one into a situation where they are going to need to change their = because people are going to start using this tag all of the time and not = just when the claims are bare. =20 So it should be made clear that this is not a valid CWT then. > That is the "unsigned CWT Claims Set" could be passed into the a COSE = library to be signed and the tag would never be stripped. It obviously could, but so could be many other things, which also = wouldn=E2=80=99t be a CWT. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Mar 6 11:59:22 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 ADF823A091D; Fri, 6 Mar 2020 11:59:15 -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, 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 gsSrFk8X6gZ2; Fri, 6 Mar 2020 11:59:13 -0800 (PST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (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 8BF5D3A0919; Fri, 6 Mar 2020 11:59:13 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2020 11:59:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,523,1574150400"; d="scan'208";a="233419708" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga007.fm.intel.com with ESMTP; 06 Mar 2020 11:59:13 -0800 Received: from orsmsx157.amr.corp.intel.com (10.22.240.23) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 6 Mar 2020 11:59:12 -0800 Received: from orsmsx108.amr.corp.intel.com ([169.254.2.232]) by ORSMSX157.amr.corp.intel.com ([169.254.9.95]) with mapi id 14.03.0439.000; Fri, 6 Mar 2020 11:59:12 -0800 From: "Smith, Ned" To: Carsten Bormann , Jim Schaad CC: "rats@ietf.org" , "cbor@ietf.org" , "Henk Birkholz" , Ace Wg Thread-Topic: [Rats] [Ace] [Cbor] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? Thread-Index: AQHV8+zc9Y1TwN0arEmFf2Tv/hQqNKg7+48A Date: Fri, 6 Mar 2020 19:59:12 +0000 Message-ID: References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <12861.1583448208@localhost> <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> <017f01d5f35d$2c422c60$84c68520$@augustcellars.com> <01ae01d5f3eb$4a670fb0$df352f10$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 x-originating-ip: [10.254.184.168] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Cbor] [Rats] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 19:59:17 -0000 VGhlIGVhcmxpZXIgdGhyZWFkIHN1Z2dlc3RlZCB0aGF0IGEgbmFrZWQgdG9rZW4gY291bGQgYmUg Z2l2ZW4gdG8gYSBwYXJzZXIgdGhhdCB3YXMgcHJvZ3JhbW1lZCBjb3JyZWN0bHkgYW5kIGl0IHdv dWxkICdqdXN0IHdvcmsnLiBCdXQgaWYgdGhlIGRlZmluaXRpb24gb2YgYSBDV1QvSldUIGlzIHRo YXQgaXQgbXVzdCBoYXZlIGJvdW5kaW5nIHNpZ25hdHVyZSwgbWFjLCBlbmNyeXB0aW9uIGVudmVs b3BpbmcsIHRoZW4gdGhlIHBhcnNlciBzaG91bGQgcmVqZWN0IG5ha2VkIHRva2VucyAodGFnZ2Vk IGFzIHN1Y2ggb3Igbm90KS4gDQoNCklmIHRoZSBuYWtlZCB0b2tlbiBpcyBkZWZpbmVkIGFuZCB0 aGUgbWFwIGhhcyBhIHRhZyB0aGF0IGluZGljYXRlcyBpdCB3YXMgZm9ybWVkIHdpdGhvdXQgc2Vj dXJlIGVudmVsb3BpbmcgdGhlbiB0aGUgcGFyc2VyIHNob3VsZCBhY2NlcHQgaXQsIGJ1dCB0aGUg Y29kZSB1c2luZyB0aGUgcGFyc2VyIG5lZWRzIHRvIGZpbmQgc29tZSBvdGhlciB3YXkgdG8gZW5z dXJlIHNlY3VyaXR5LiANCg0KSWYgYSBwYXJzZXIgcmVjZWl2ZXMgYSBtYXAgd2l0aCBib3RoIHNl Y3VyaXR5IGVudmVsb3BpbmcgYW5kIHRoZSBuYWtlZCB0b2tlbiB0YWcsIHRoZW4gaXQgc2hvdWxk IHJldHVybiBib3RoIHRoZSBtYXAgYW5kIHRoZSBzZWN1cml0eSBlbnZlbG9wZSBjb250ZXh0IGFu ZCBsZXQgdGhlIGNvZGUgdXNpbmcgdGhlIHBhcnNlciBkZWNpZGUgaWYgdGhlIHNlY3VyaXR5IGNv bnRleHQgc2F0aXNmaWVzIHRoZSBzZWN1cml0eSByZXF1aXJlbWVudC4NCg0KLU5lZA0KDQrvu79P biAzLzYvMjAsIDExOjI0IEFNLCAiUkFUUyBvbiBiZWhhbGYgb2YgQ2Fyc3RlbiBCb3JtYW5uIiA8 cmF0cy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjYWJvQHR6aS5vcmc+IHdyb3RlOg0K DQogICAgSGkgSmltLA0KICAgIA0KICAgID4gT24gMjAyMC0wMy0wNiwgYXQgMjA6MTMsIEppbSBT Y2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdyb3RlOg0KICAgID4gDQogICAgPiBUaGVy ZSBpcyBhIHZlcnkgaGlnaCBjaGFuY2UgdGhhdCBtYWtpbmcgdGhpcyBjaGFuZ2UgaXMgZ29pbmcg dG8gbGVhZCBvbmUgaW50byBhIHNpdHVhdGlvbiB3aGVyZSB0aGV5IGFyZSBnb2luZyB0byBuZWVk IHRvIGNoYW5nZSB0aGVpciBiZWNhdXNlIHBlb3BsZSBhcmUgZ29pbmcgdG8gc3RhcnQgdXNpbmcg dGhpcyB0YWcgYWxsIG9mIHRoZSB0aW1lIGFuZCBub3QganVzdCB3aGVuIHRoZSBjbGFpbXMgYXJl IGJhcmUuICANCiAgICANCiAgICBTbyBpdCBzaG91bGQgYmUgbWFkZSBjbGVhciB0aGF0IHRoaXMg aXMgbm90IGEgdmFsaWQgQ1dUIHRoZW4uDQogICAgDQogICAgPiBUaGF0IGlzIHRoZSAidW5zaWdu ZWQgQ1dUIENsYWltcyBTZXQiIGNvdWxkIGJlIHBhc3NlZCBpbnRvIHRoZSBhIENPU0UgbGlicmFy eSB0byBiZSBzaWduZWQgYW5kIHRoZSB0YWcgd291bGQgbmV2ZXIgYmUgc3RyaXBwZWQuDQogICAg DQogICAgSXQgb2J2aW91c2x5IGNvdWxkLCBidXQgc28gY291bGQgYmUgbWFueSBvdGhlciB0aGlu Z3MsIHdoaWNoIGFsc28gd291bGRu4oCZdCBiZSBhIENXVC4NCiAgICANCiAgICBHcsO8w59lLCBD YXJzdGVuDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCiAgICBSQVRTIG1haWxpbmcgbGlzdA0KICAgIFJBVFNAaWV0Zi5vcmcNCiAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JhdHMNCiAgICANCg0K From nobody Fri Mar 6 12:04: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 6ECF23A0971; Fri, 6 Mar 2020 12:04:12 -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, 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 VQYkVys3tlcr; Fri, 6 Mar 2020 12:04:09 -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 8B24B3A096E; Fri, 6 Mar 2020 12:04:09 -0800 (PST) Received: from [192.168.217.147] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48Yz8l6DR2z18v3; Fri, 6 Mar 2020 21:04:07 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: Date: Fri, 6 Mar 2020 21:04:07 +0100 Cc: Jim Schaad , "rats@ietf.org" , Ace Wg , Henk Birkholz , "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 605217847.22778-b7357b388bac625166f5f13328a2a580 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <12861.1583448208@localhost> <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> <017f01d5f35d$2c422c60$84c68520$@augustcellars.com> <01ae01d5f3eb$4a670fb0$df352f10$@augustcellars.com> To: "Smith, Ned" X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Cbor] [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 20:04:15 -0000 Hi Ned, What I was trying to say is that the Unprotected CWT Claims Set (UCCS) = is not a CWT, but an UCCS. So I wouldn=E2=80=99t call it a token (which = implies some form of protection to me). But it is still a useful data = structure to carry around. > On 2020-03-06, at 20:59, Smith, Ned wrote: >=20 > The earlier thread suggested that a naked token could be given to a = parser that was programmed correctly and it would 'just work'. But if = the definition of a CWT/JWT is that it must have bounding signature, = mac, encryption enveloping, then the parser should reject naked tokens = (tagged as such or not).=20 A CWT decoder would diagnose an UCCS as =E2=80=9Cnot a CWT=E2=80=9D. A CWT/UCCS decoder would diagnose it as =E2=80=9CUCCS=E2=80=9D. > If the naked token is defined and the map has a tag that indicates it = was formed without secure enveloping then the parser should accept it, = but the code using the parser needs to find some other way to ensure = security.=20 Right. An UCCS is only a useful assertion if received over a secure = channel with the right properties to make it a useful assertion. > If a parser receives a map with both security enveloping and the naked = token tag, then it should return both the map and the security envelope = context and let the code using the parser decide if the security context = satisfies the security requirement. Well, it should diagnose this as =E2=80=9Cnot a CWT=E2=80=9D (and not an = UCCS either). Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Mar 6 12:04:59 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 161163A09A7; Fri, 6 Mar 2020 12:04:47 -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, 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 vMKnrERBYqPK; Fri, 6 Mar 2020 12:04:44 -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 E442D3A0939; Fri, 6 Mar 2020 12:04:42 -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; Fri, 6 Mar 2020 12:04:36 -0800 From: Jim Schaad To: 'Laurence Lundblade' , 'Henk Birkholz' CC: , , References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <12861.1583448208@localhost> <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> <017f01d5f35d$2c422c60$84c68520$@augustcellars.com> <600c2555-75af-a4dc-98c8-206a91b1af52@sit.fraunhofer.de> In-Reply-To: Date: Fri, 6 Mar 2020 12:04:34 -0800 Message-ID: <01b501d5f3f2$76eebbd0$64cc3370$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B6_01D5F3AF.68CD2980" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIPc7l4+GCW+nItGLs4R66gGWmpXQHDaFTrAg5IEhsBMlW0mAJcsQyDAXKra+MB77wHngFJU4MWp2iWHLA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] [Rats] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 20:04:48 -0000 ------=_NextPart_000_01B6_01D5F3AF.68CD2980 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Laurence Lundblade =20 Sent: Friday, March 6, 2020 7:38 AM To: Henk Birkholz Cc: Jim Schaad ; Smith, Ned = ; Michael Richardson ; = rats@ietf.org; ace@ietf.org; cbor@ietf.org Subject: Re: [Rats] [Cbor] [Ace] RATS Entity Attestation Tokens (EAT) - = to be a CWT or not to be a CWT? =20 So far, there are three things we have turned up in work on EAT that we = would like considered as changes to CWT. =20 1) Naked CWT=E2=80=99s, probably tagged The point of the tag would be for use in protocols where you = can=E2=80=99t tell a naked CWT is a CWT by the context of the protocol. = So far we seem to always assign a tag to new CBOR data structures for = this purpose. For naked CWT=E2=80=99s, it seems we really should have = the tag, even if it makes Jim=E2=80=99s code larger. =20 2) Disallow floating point dates Right now CWT allows dates like the expiration date to be floating = point. The only use of floating point dates is fractional seconds and = dates so large they are not human time scale. As it stands a CWT decoder = MUST implement floating point. This is a substantial burden for no good = reason at all. One option here is an incompatible change to these data = items. Another is to define new integer-only data items (new = labels/keys) for the same data items. =20 =20 [JLS] As far as I am concerned this is just a profiling effort. I also = agree that it makes almost no sense to use floating point for dates in = almost all cases where CWT claims have been created. =20 3) Claims Characteristics for new registered claims A lot of people had a lot of opinions and points on what data formats = and types and such were used for claims back in 2019 in EAT. I = (hopefully) captured most of that in some recommendations for claims = characteristics. Text is currently here in a PR against the EAT draft = , but it seems it really = should be for all CWT claims. =20 [JLS] After one fast read, I think that these are good generic = suggestions, however I disagree that this should be true for all CWT = claims. There is an explicit expert review section that is designed for = the registration of extremely explicit claims that will violate these = guidelines. =20 =20 jim =20 I don=E2=80=99t know if there are more things EAT would like to change = in CWT. Or maybe there are other uses of CWT that would like to change = it. =20 =20 I proposed that EAT be an update to the CWT RFC. Dave Thaler said they = should probably be separate from EAT and handled in the ACE WG and that = made sense to most of us. Seems to me that a new RFC that either updates = or obsoletes 8392 would be the thing to do, but maybe there are other = ways.=20 =20 LL =20 On Mar 6, 2020, at 2:30 AM, Henk Birkholz = > wrote: =20 Please let me correct myself: My proposal is to simply assign a single CBOR tag for unsigned (aka = "naked") CWT Claims sets. I wrote "EAT" Claims Set before and that made = me loose the perspective that an EAT is a CWT (I should read my own = subject more often...). I think this is useful outside of RATS as well and will start a = corresponding draft in RATS to create a more tangible proposal that = elaborates on motivation & background: as with YANG modules, CBOR tags = can be defined in any WG. There are multiple benefits to this approach: * parsers can choose to ignore tags in any case, * it is the least invasive approach (next to doing nothing), * we will not be the ones that attempt to reopen RFC8392, and * we detach this effort from progressing EAT as it is CWT-related. Viele Gr=C3=BC=C3=9Fe, Henk On 06.03.20 08:35, Henk Birkholz wrote: Hi Jim, from an implementation point of view that is fine. To quote Carsten here = "tags are cheap" and you would have to parse the whole structure to make = sure it is an EAT Claims Set. My point is, it does not hurt to register = a CBOR tag for an unsigned EAT Claims Set that adheres to the some = content definitions as EAT, but that is not signed via a COSE array. In = contrast, in most cases it does help, I think, and enables a clear = semantic equivalence for the content. Viele Gr=C3=BC=C3=9Fe, Henk On 06.03.20 03:15, Jim Schaad wrote: I would not claim that a collection of CWT claims is a CWT. I would = agree that a CWT does require that some security be applied. I was = instead making the argument that there was no need to have a special = marking for the collection as oppose to the CWT since it is possible to = distinguish the cases apart. In CDDL I would put something like claimsMade =3D CWT / claimsMap where the CWT is over a claimsMap element. In this case one could = easily distinguish between the two cases without additional tagging. Jim -----Original Message----- From: Ace > On = Behalf Of Smith, Ned Sent: Thursday, March 5, 2020 4:48 PM To: Michael Richardson >; rats@ietf.org ; = ace@ietf.org ; cbor@ietf.org = =20 Subject: Re: [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a = CWT or not to be a CWT? My interpretation of this thread was that CWT spec requires at least one = of (COSE_Encrypt, COSE_MAC, COSE_Signature) or it isn't valid COSE. That = implies the parser should never get to "if input is a map" as it isn't = valid COSE. If the above interpretation isn't true then the 'do nothing' option is = best. -Ned =EF=BB=BFOn 3/5/20, 2:43 PM, "RATS on behalf of Michael Richardson" = on behalf of = mcr+ietf@sandelman.ca > wrote: { I found Jim's very interesting email very hard to read without = good quoting, I'm repeating the important part } henk> 2.) go to ACE and ask for an "unsigned token" option, or Jim Schaad = > wrote: jls> I don't have a problem with this, I am not sure that I see = any jls> reason for it however. See below. henk> 3.) go to CBOR and ask for a tag for "naked" CWT Claim = Sets (i.e., henk> that are not signed). jls> I don't see any difference between this and option #2 jls> 4.) Just write your CWT code in a sensible manner. jls> My CWT code base does not make any assumptions about the = number or jls> order of COSE security wrapping layers on a token. It = thus looks jls> like jls> while (true) { jls> if input has a COSE_Encrypt tag { decrypt it; set input to = the content; save the encryption information if needed e.g. shared key = authentication; continue; } jls> if input has a COSE_MAC tag { validate it; set input to = the content; save the MAC information if needed e.g. shared key = authentication; continue;} jls> if input has a COSE_Signature tag { validate it; set input = to the content; save the signer information; continue } jls> if input is a map - return input as the set of claims; jls> throw an exception because it is not the correct format. jls> } jls> This does not require a tag for a naked set of claims and = would jls> allow that set of claims to be pass in the same place as a = CWT can jls> be passed. What you are suggesting would require extra = code to jls> exist someplace that is going to check for an additional = tag. jls> IT IS jls> ALSO GOING TO LEAD TO PEOPLE THINKING THAT THIS NEW TAG = SHOULD BE jls> LEGAL TO PLACE INSIDE OF A CWT. After all it makes more = sense to jls> always include it than to just sometimes include it. Emphasis mine. So your suggestion is to do nothing. I also wondered why that wouldn't work, but I hadn't written enough = code to ask the question intelligently. -- Michael Richardson >, Sandelman Software Works -=3D IPv6 IoT consulting =3D- _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace _______________________________________________ CBOR mailing list CBOR@ietf.org =20 https://www.ietf.org/mailman/listinfo/cbor _______________________________________________ RATS mailing list RATS@ietf.org =20 https://www.ietf.org/mailman/listinfo/rats =20 ------=_NextPart_000_01B6_01D5F3AF.68CD2980 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Laurence Lundblade = <lgl@island-resort.com>
Sent: Friday, March 6, 2020 = 7:38 AM
To: Henk Birkholz = <henk.birkholz@sit.fraunhofer.de>
Cc: Jim Schaad = <ietf@augustcellars.com>; Smith, Ned <ned.smith@intel.com>; = Michael Richardson <mcr+ietf@sandelman.ca>; rats@ietf.org; = ace@ietf.org; cbor@ietf.org
Subject: Re: [Rats] [Cbor] [Ace] = RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a = CWT?

 

So far, = there are three things we have turned up in work on EAT that we would = like considered as changes to CWT.

 

1) Naked CWT=E2=80=99s, probably = tagged

The point of the = tag would be for use in protocols where you can=E2=80=99t tell a naked = CWT is a CWT by the context of the protocol. So far we seem to always = assign a tag to new CBOR data structures for this purpose. For naked = CWT=E2=80=99s, it seems we really should have the tag, even if it makes = Jim=E2=80=99s code larger.

 

2) Disallow floating point = dates

Right now CWT allows = dates like the expiration date to be floating point. The only use of = floating point dates is fractional seconds and dates so large they are = not human time scale. As it stands a CWT decoder MUST implement floating = point. This is a substantial burden for no good reason at all. One = option here is an incompatible change to these data items. Another is to = define new integer-only data items (new labels/keys) for the same data = items.

 

 

[JLS] As far = as I am concerned this is just a profiling effort.=C2=A0 I also agree = that it makes almost no sense to use floating point for dates in almost = all cases where CWT claims have been = created.

 

3) Claims Characteristics for new registered = claims

A lot of people had = a lot of opinions and points on what data formats and types and such = were used for claims back in 2019 in EAT. I (hopefully) captured most of = that in some recommendations for claims characteristics. Text is = currently here in = a PR against the EAT draft, but it seems it really should be for all = CWT claims.

 

[JLS]=C2=A0 After one fast read, I think that these = are good generic suggestions, however I disagree that this should be = true for all CWT claims.=C2=A0 There is an explicit expert review = section that is designed for the registration of extremely explicit = claims that will violate these guidelines.=C2=A0=C2=A0 =

 

jim

 

I = don=E2=80=99t know if there are more things EAT would like to change in = CWT. Or maybe there are other uses of CWT that would like to change = it.

 

 

I = proposed that EAT be an update to the CWT RFC. Dave Thaler said they = should probably be separate from EAT and handled in the ACE WG and that = made sense to most of us. Seems to me that a new RFC that either updates = or obsoletes 8392 would be the thing to do, but maybe there are other = ways. 

 

LL

 



On Mar 6, 2020, at 2:30 AM, Henk Birkholz <henk.birkholz@sit.fraunho= fer.de> wrote:

 

Please let me correct myself:

My proposal is to = simply assign a single CBOR tag for unsigned (aka "naked") CWT = Claims sets. I wrote "EAT" Claims Set before and that made me = loose the perspective that an EAT is a CWT (I should read my own subject = more often...).

I think this is useful outside of RATS as well = and will start a corresponding draft in RATS to create a more tangible = proposal that elaborates on motivation & background: as with YANG = modules, CBOR tags can be defined in any WG.

There are multiple = benefits to this approach:

* parsers can choose to ignore tags in = any case,
* it is the least invasive approach (next to doing = nothing),
* we will not be the ones that attempt to reopen RFC8392, = and
* we detach this effort from progressing EAT as it is = CWT-related.

Viele Gr=C3=BC=C3=9Fe,

Henk


On = 06.03.20 08:35, Henk Birkholz wrote:

Hi = Jim,
from an implementation point of view that is fine. To quote = Carsten here "tags are cheap" and you would have to parse the = whole structure to make sure it is an EAT Claims Set. My point is, it = does not hurt to register a CBOR tag for an unsigned EAT Claims Set that = adheres to the some content definitions as EAT, but that is not signed = via a COSE array. In contrast, in most cases it does help, I think, and = enables a clear semantic equivalence for the content.
Viele = Gr=C3=BC=C3=9Fe,
Henk
On 06.03.20 03:15, Jim Schaad = wrote:

I would not claim that a collection of = CWT claims is a CWT.  I would agree that a CWT does require that = some security be applied.  I was instead making the argument that = there was no need to have a special marking for the collection as oppose = to the CWT since it is possible to distinguish the cases = apart.   In CDDL I would put something like

claimsMade = =3D CWT / claimsMap

where the CWT is over a claimsMap = element.   In this case one could easily distinguish between = the two cases without additional = tagging.

Jim


-----Original Message-----
From: Ace = <ace-bounces@ietf.org> = On Behalf Of Smith, Ned
Sent: Thursday, March 5, 2020 4:48 PM
To: = Michael Richardson <mcr+ietf@sandelman.ca>; rats@ietf.org; ace@ietf.org; cbor@ietf.org
Subject: Re: [Ace] = [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a = CWT?

My interpretation of this thread was that CWT spec requires = at least one of (COSE_Encrypt, COSE_MAC, COSE_Signature) or it isn't = valid COSE. That implies the parser should never get to "if input = is a map" as it isn't valid COSE.

If the above = interpretation isn't true then the 'do nothing' option is = best.

-Ned

=EF=BB=BFOn 3/5/20, 2:43 PM, "RATS on = behalf of Michael Richardson" <rats-bounces@ietf.org on = behalf of mcr+ietf@sandelman.ca> = wrote:

     { I found Jim's very interesting = email very hard to read without good
     = quoting, I'm repeating the important part = }
         henk> 2.) go to = ACE and ask for an "unsigned token" option, = or
     Jim Schaad <ietf@augustcellars.com> = wrote:
         jls> I = don't have a problem with this, I am not sure that I see = any
         jls> reason = for it however.  See = below.
         henk> 3.) = go to CBOR and ask for a tag for "naked" CWT Claim Sets = (i.e.,
         henk> that = are not signed).
         = jls> I don't see any difference between this and option = #2
         jls> 4.) Just = write your CWT code in a sensible = manner.
         jls> My = CWT code base does not make any assumptions about the number = or
         jls> order of = COSE security wrapping layers on a token.  It thus = looks
         jls> = like
         jls> while = (true) {
         jls> if = input has a COSE_Encrypt tag { decrypt it; set input to the content; = save the encryption information if needed e.g. shared key = authentication; continue; = }
         jls> if input = has a COSE_MAC tag { validate it; set input to the content; save the MAC = information if needed e.g. shared key authentication; = continue;}
         jls> = if input has a COSE_Signature tag { validate it; set input to the = content; save the signer information; continue = }
         jls> if input = is a map - return input as the set of = claims;
         jls> = throw an exception because it is not the correct = format.
         jls> = }
         jls> This does = not require a tag for a naked set of claims and = would
         jls> allow = that set of claims to be pass in the same place as a CWT = can
         jls> be = passed.  What you are suggesting would require extra code = to
         jls> exist = someplace that is going to check for an additional = tag.
         jls> IT = IS
         jls> ALSO = GOING TO LEAD TO PEOPLE THINKING THAT THIS NEW TAG SHOULD = BE
         jls> LEGAL TO = PLACE INSIDE OF A CWT.  After all it makes more sense = to
         jls> always = include it than to just sometimes include = it.
     Emphasis = mine.
     So your suggestion is to do = nothing.
     I also wondered why that wouldn't = work, but I hadn't written enough code to
     = ask the question intelligently.
     = --
     Michael Richardson <mcr+IETF@sandelman.ca>, = Sandelman Software Works
      -=3D IPv6 IoT = consulting = =3D-

_______________________________________________
Ace = mailing list
Ace@ietf.org
https://www.ietf.org/m= ailman/listinfo/ace

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


_______________________________________________
= RATS mailing list
RATS@ietf.org
https://www.ietf.org/= mailman/listinfo/rats

 

------=_NextPart_000_01B6_01D5F3AF.68CD2980-- From nobody Fri Mar 6 15:56:55 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 75FD93A0DD9; Fri, 6 Mar 2020 15:56:53 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 vjiO9rdEK1Wd; Fri, 6 Mar 2020 15:56:50 -0800 (PST) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 0F4FD3A0DD7; Fri, 6 Mar 2020 15:56:48 -0800 (PST) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 026Nud9H024833 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Sat, 7 Mar 2020 00:56:40 +0100 Received: from [192.168.16.50] (79.206.149.19) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Sat, 7 Mar 2020 00:56:34 +0100 To: Jim Schaad , , , References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <12861.1583448208@localhost> <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> <017f01d5f35d$2c422c60$84c68520$@augustcellars.com> <01ae01d5f3eb$4a670fb0$df352f10$@augustcellars.com> From: Henk Birkholz Message-ID: Date: Sat, 7 Mar 2020 00:56:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <01ae01d5f3eb$4a670fb0$df352f10$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.149.19] Archived-At: Subject: Re: [Cbor] [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 23:56:54 -0000 Hi Jim, I never intended an unprotected CWT Claims Set to be a CWT anymore, because by definition it would not be one any more, today. I'll try to be more explicit and clear: An unprotected CWT Claims Set is not a change to CWT, but a new thing based on the definition of CWT Claims Set in RFC8392 and that new thing cannot be a CWT. The semantics of the registered claims are the same though, because a CWT Claims Set is composed of claims defined in the CWT Claims registry. I also agree with your point that simply replacing CWT with unprotected CCS would be nonsense in implementation/practice. Assuming that this leads to a very high chance of unprotected CCS taking over all the CWT use cases (which should also result in "not a CWT", I think) seems to be a bit of a drastic projection, don't you think? Especially, considering that CWT are intended be always appropriately identifiable (I assume you are very familiar with https://tools.ietf.org/html/rfc8392#section-6). Unprotected CCS must be unmistakably & appropriately identifiable as what they are, analogously. I do not quite follow the reasoning why anyone using CWT or intending to use CWT today would be "lead into a situation where to change their tag" all of the sudden? Could you elaborate on that please? If you put a tagged unprotected CCS in a COSE that would of course again be a violation - that is simply not a viable CWT anymore and a very weird way to interpret "unprotected", if I may add. If a minimal set of normative requirements (based on the topics discussed previously) are added, I am rather certain that implementers will not start to omit COSE from CWT Claims Sets and try to send these as CWT. Maybe I am still missing something very obvious that you are trying to tell me, though :) Viele Grüße, Henk On 06.03.20 20:13, Jim Schaad wrote: > Henk, > > I want to re-iterate that this is not quite the same no/low cost situation that leads me to say - yes just tag it and be fine. > > There is a very high chance that making this change is going to lead one into a situation where they are going to need to change their because people are going to start using this tag all of the time and not just when the claims are bare. That is the "unsigned CWT Claims Set" could be passed into the a COSE library to be signed and the tag would never be stripped. > > There is also a small cost in terms of message size, but I assume that you are willing to absorb that. > > Jim > > > -----Original Message----- > From: Henk Birkholz > Sent: Thursday, March 5, 2020 11:35 PM > To: Jim Schaad ; 'Smith, Ned' ; 'Michael Richardson' ; rats@ietf.org; ace@ietf.org; cbor@ietf.org > Subject: Re: [Cbor] [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? > > Hi Jim, > > from an implementation point of view that is fine. To quote Carsten here "tags are cheap" and you would have to parse the whole structure to make sure it is an EAT Claims Set. My point is, it does not hurt to register a CBOR tag for an unsigned EAT Claims Set that adheres to the some content definitions as EAT, but that is not signed via a COSE array. In contrast, in most cases it does help, I think, and enables a clear semantic equivalence for the content. > > Viele Grüße, > > Henk > > On 06.03.20 03:15, Jim Schaad wrote: >> I would not claim that a collection of CWT claims is a CWT. I would agree that a CWT does require that some security be applied. I was instead making the argument that there was no need to have a special marking for the collection as oppose to the CWT since it is possible to distinguish the cases apart. In CDDL I would put something like >> >> claimsMade = CWT / claimsMap >> >> where the CWT is over a claimsMap element. In this case one could easily distinguish between the two cases without additional tagging. >> >> Jim >> >> >> -----Original Message----- >> From: Ace On Behalf Of Smith, Ned >> Sent: Thursday, March 5, 2020 4:48 PM >> To: Michael Richardson ; rats@ietf.org; >> ace@ietf.org; cbor@ietf.org >> Subject: Re: [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? >> >> My interpretation of this thread was that CWT spec requires at least one of (COSE_Encrypt, COSE_MAC, COSE_Signature) or it isn't valid COSE. That implies the parser should never get to "if input is a map" as it isn't valid COSE. >> >> If the above interpretation isn't true then the 'do nothing' option is best. >> >> -Ned >> >> On 3/5/20, 2:43 PM, "RATS on behalf of Michael Richardson" wrote: >> >> >> { I found Jim's very interesting email very hard to read without good >> quoting, I'm repeating the important part } >> >> henk> 2.) go to ACE and ask for an "unsigned token" option, >> or >> >> Jim Schaad wrote: >> jls> I don't have a problem with this, I am not sure that I see any >> jls> reason for it however. See below. >> >> henk> 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., >> henk> that are not signed). >> >> jls> I don't see any difference between this and option #2 >> >> jls> 4.) Just write your CWT code in a sensible manner. >> >> jls> My CWT code base does not make any assumptions about the number or >> jls> order of COSE security wrapping layers on a token. It thus looks >> jls> like >> >> jls> while (true) { >> jls> if input has a COSE_Encrypt tag { decrypt it; set input to the content; save the encryption information if needed e.g. shared key authentication; continue; } >> jls> if input has a COSE_MAC tag { validate it; set input to the content; save the MAC information if needed e.g. shared key authentication; continue;} >> jls> if input has a COSE_Signature tag { validate it; set input to the content; save the signer information; continue } >> jls> if input is a map - return input as the set of claims; >> jls> throw an exception because it is not the correct format. >> jls> } >> >> jls> This does not require a tag for a naked set of claims and would >> jls> allow that set of claims to be pass in the same place as a CWT can >> jls> be passed. What you are suggesting would require extra code to >> jls> exist someplace that is going to check for an additional tag. >> >> jls> IT IS >> jls> ALSO GOING TO LEAD TO PEOPLE THINKING THAT THIS NEW TAG SHOULD BE >> jls> LEGAL TO PLACE INSIDE OF A CWT. After all it makes more sense to >> jls> always include it than to just sometimes include it. >> >> Emphasis mine. >> So your suggestion is to do nothing. >> I also wondered why that wouldn't work, but I hadn't written enough code to >> ask the question intelligently. >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >> > From nobody Fri Mar 6 18:27:41 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 7609F3A101F for ; Fri, 6 Mar 2020 18:27:39 -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 wqwLMFVfM4bd for ; Fri, 6 Mar 2020 18:27:32 -0800 (PST) Received: from p3plsmtpa07-10.prod.phx3.secureserver.net (p3plsmtpa07-10.prod.phx3.secureserver.net [173.201.192.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E023A1052 for ; Fri, 6 Mar 2020 18:27:30 -0800 (PST) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id APBZjByRH3mdrAPBZjipen; Fri, 06 Mar 2020 19:27:30 -0700 X-CMAE-Analysis: v=2.3 cv=AZbP4EfG c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=gKmFwSsBAAAA:8 a=QyXUC8HyAAAA:8 a=48vgC7mUAAAA:8 a=7VJOSAJciyv0Og2gw4sA:9 a=QEXdDO2ut3YA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com 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: Fri, 6 Mar 2020 18:27:29 -0800 Cc: "Smith, Ned" , "rats@ietf.org" , Jim Schaad , "cbor@ietf.org" , Henk Birkholz , Ace Wg Content-Transfer-Encoding: quoted-printable Message-Id: <3F7E9A70-18BE-454C-A5EB-F07A1EDFE7DC@island-resort.com> References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <12861.1583448208@localhost> <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> <017f01d5f35d$2c422c60$84c68520$@augustcellars.com> <01ae01d5f3eb$4a670fb0$df352f10$@augustcellars.com> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfKy83zi+U5PeWqH/6RsblKgIr+ls7hN0mEo4T4qN+7KucD5QTKfkz8wzeTB/1wjiLTTpMDMo7ZAKCwBPV0LFapn9al7Gw4ozo+uev7Om5w3H3yD3OJI2 tyLRlnG62UAs3Za/4MAytNfPR5DSwCN6J1Nq2l6sE/kPavSDpu/N1wyVMrK1kWtmedzH/Me0lTJDSV8NsHdH2DG730IgVAg18J//yW+CeaLXRM5b5Xg++CVD FBe0pr79TwRTzaiMGiBHU+iGjR1miEP1XKq3deq+lf8XtdxzQESLlCwIdcbJ+6Si7ghzTtkhL2UVh09jCpwTQ+xG9WdsbBH9mm8hJs5nGnU= Archived-At: Subject: Re: [Cbor] [Rats] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 02:27:40 -0000 Pretty sure UCCS as Carsten describes below works for me provided: - All the rules and requirements from CWT explicilty apply except = signing/encryption - It uses the same registry - There is a tag defined for it - You get an (untagged) UCCS when you remove all signing and encryption = layers LL > On Mar 6, 2020, at 12:04 PM, Carsten Bormann wrote: >=20 > Hi Ned, >=20 > What I was trying to say is that the Unprotected CWT Claims Set (UCCS) = is not a CWT, but an UCCS. So I wouldn=E2=80=99t call it a token (which = implies some form of protection to me). But it is still a useful data = structure to carry around. >=20 >> On 2020-03-06, at 20:59, Smith, Ned wrote: >>=20 >> The earlier thread suggested that a naked token could be given to a = parser that was programmed correctly and it would 'just work'. But if = the definition of a CWT/JWT is that it must have bounding signature, = mac, encryption enveloping, then the parser should reject naked tokens = (tagged as such or not).=20 >=20 > A CWT decoder would diagnose an UCCS as =E2=80=9Cnot a CWT=E2=80=9D. > A CWT/UCCS decoder would diagnose it as =E2=80=9CUCCS=E2=80=9D. >=20 >> If the naked token is defined and the map has a tag that indicates it = was formed without secure enveloping then the parser should accept it, = but the code using the parser needs to find some other way to ensure = security.=20 >=20 > Right. An UCCS is only a useful assertion if received over a secure = channel with the right properties to make it a useful assertion. >=20 >> If a parser receives a map with both security enveloping and the = naked token tag, then it should return both the map and the security = envelope context and let the code using the parser decide if the = security context satisfies the security requirement. >=20 > Well, it should diagnose this as =E2=80=9Cnot a CWT=E2=80=9D (and not = an UCCS either). >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats From nobody Sun Mar 8 12:05:50 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 40BB43A0785 for ; Sun, 8 Mar 2020 12:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mT-_W3-pyr1s for ; Sun, 8 Mar 2020 12:05:47 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9993A0783 for ; Sun, 8 Mar 2020 12:05:46 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 8 Mar 2020 12:05:41 -0700 From: Jim Schaad To: Date: Sun, 8 Mar 2020 12:05:40 -0700 Message-ID: <025a01d5f57c$91023b10$b306b130$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdX1fGmSgqw7om5xQYqVcOz92/iL6Q== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Planning for the Vancouver meeting X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 19:05:49 -0000 It appears that the logistics for the upcoming meeting in Vancouver are going to be more complicated than is normal. To start with at the present time it appears that neither of the chairs are going to be physically present for the meeting. Please let the chairs know if you desire to do a presentation for Vancouver. We will need the following information: 1. What document or proposed document are you addressing? 2. How long do you think it is going to take? 3. Are you planning to give the presentation locally or remotely? If you are going to be remote is there somebody who might be able to do it locally? In addition to the normal volunteers for a Jabber Scribe (local) and one or more notetakers (one local and others either local or remote), we are going to need to get somebody to sit up at the front of the meeting and get slides up and press buttons for meetecho. If you can do any of these please let us know that as well. Jim & Francesca From nobody Sun Mar 8 14:06:31 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 A3DC63A0ACE; Sun, 8 Mar 2020 14:06:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <158370158858.6863.7397458491055240720@ietfa.amsl.com> Date: Sun, 08 Mar 2020 14:06:28 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-7049bis-13.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 21:06:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF. Title : Concise Binary Object Representation (CBOR) Authors : Carsten Bormann Paul Hoffman Filename : draft-ietf-cbor-7049bis-13.txt Pages : 74 Date : 2020-03-08 Abstract: The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document is a revised edition of RFC 7049, with editorial improvements, added detail, and fixed errata. This revision formally obsoletes RFC 7049, while keeping full compatibility of the interchange format from RFC 7049. It does not create a new version of the format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-7049bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-7049bis-13 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-7049bis-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-7049bis-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 8 14:10:28 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 5E7103A0ADB for ; Sun, 8 Mar 2020 14:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3ZC_FKuuS6jr for ; Sun, 8 Mar 2020 14:10:24 -0700 (PDT) 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 CFF2C3A0ADE for ; Sun, 8 Mar 2020 14:10:23 -0700 (PDT) Received: from [192.168.217.147] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48bDXG1RN7z11BQ; Sun, 8 Mar 2020 22:10:22 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <158370158858.6863.7397458491055240720@ietfa.amsl.com> Date: Sun, 8 Mar 2020 22:10:21 +0100 X-Mao-Original-Outgoing-Id: 605394621.622323-cd09328adffec1440f52ddb4252e0e1b Content-Transfer-Encoding: quoted-printable Message-Id: <69C2E638-424A-454A-8F3F-763CB4017A64@tzi.org> References: <158370158858.6863.7397458491055240720@ietfa.amsl.com> To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-7049bis-13.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 21:10:27 -0000 This version closes all of the remaining issues (except for one task = that can be done during WGLC). As discussed in the interims, we believe this is now at the stage where = we want to have the Working-Group Last Call. Gr=C3=BC=C3=9Fe, Carsten > On 2020-03-08, at 22:06, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Concise Binary Object Representation = Maintenance and Extensions WG of the IETF. >=20 > Title : Concise Binary Object Representation (CBOR) > Authors : Carsten Bormann > Paul Hoffman > Filename : draft-ietf-cbor-7049bis-13.txt > Pages : 74 > Date : 2020-03-08 >=20 > Abstract: > The Concise Binary Object Representation (CBOR) is a data format > whose design goals include the possibility of extremely small code > size, fairly small message size, and extensibility without the need > for version negotiation. These design goals make it different from > earlier binary serializations such as ASN.1 and MessagePack. >=20 > This document is a revised edition of RFC 7049, with editorial > improvements, added detail, and fixed errata. This revision = formally > obsoletes RFC 7049, while keeping full compatibility of the > interchange format from RFC 7049. It does not create a new version > of the format. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cbor-7049bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-cbor-7049bis-13 > https://datatracker.ietf.org/doc/html/draft-ietf-cbor-7049bis-13 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-7049bis-13 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Mon Mar 9 09:49: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 8BF903A13C9; Mon, 9 Mar 2020 09:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, 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 pL9J0H8fuCUA; Mon, 9 Mar 2020 09:49:16 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20073.outbound.protection.outlook.com [40.107.2.73]) (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 6B3063A1459; Mon, 9 Mar 2020 09:49:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LT3Mt1y4btG8cSFcI44wX1q9Ujl3KMmsqKizmIbbi4Hn/wQm9N3HbWMddUBPIANCFj2ekOmwIcgJBSYYVHAYSxc1L0u14IM2wTH0CrONao23e6Zq/Ope7yDkQVCtLy1DcsIVZ18aX+HOKmfAPNPDyPC/do8S6DDS1Yh9u6duUNNMysBHSNrMYsIe4EcrZ4R0ga7E+leDWZc479ElGkBvfSBDyM1zb9mBBVV+W3ssjYFVNcRtOJ4p0+7CT5zpd+YEN7zI7vQSQhY48Dg689J7GKFNE5fW/yjQSZZq1x90/ZxyhdSFcmiRwcvKPDVD5AemQYMEii7ZrRVJklqen4HR6A== 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=l/qP5vg0EhJeIXh5yDKOdjRYYEWTJq1s+zM81WxxnsI=; b=QozyGkO/t3mYssXs/fqZCqYoqwTR9TZ1V6dWH2TOPaiD6Db/cbADx4NKHKsW6EQccjK5FYU5mchZDT1ymCUafjkh79Zjl5bCkC93tNHNBQSI9kClVRhWO9etIw8U5GJkjFzXb/bh5519zW9dao4ahk2EwEfo4EEbFUDArcjkBqGSACtceJj520+NhvwnVYxWM8+ntUGoGHZUTbWZnfVtsnTU5XXqCDLUAzElYrDOsmep/KYBYxH7g8pdlHkpl3VlBoD4kMb5wuPUzu3OGySfeWOBZuDhPPtu1w8GRqea73vmeeljhPD33w/7VrHwB9pqGSNUDYBGZLhFxmBkYZlWEA== 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=l/qP5vg0EhJeIXh5yDKOdjRYYEWTJq1s+zM81WxxnsI=; b=EHmS9oShMbRLk9d17ajRAiVui+bVpYdJUQ3VeAftgXHPDxBpWvp47uSbIpU1ziUcNsAeqEOyUoNTVEaXTcOYkeBKoDPXhUvmkDWbUFyZPisfvNuOsXPC5gG45qy9UyIN84qaYrAP3cEGLpc0/zrDPwjeiVyvhRGhz5lxbYQJJag= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (52.133.6.18) by HE1PR0702MB3643.eurprd07.prod.outlook.com (10.167.125.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.11; Mon, 9 Mar 2020 16:49:11 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::e49e:708f:4fe7:5d02]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::e49e:708f:4fe7:5d02%4]) with mapi id 15.20.2814.007; Mon, 9 Mar 2020 16:49:11 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "draft-ietf-cbor-7049bis@ietf.org" Thread-Topic: [Cbor] I-D Action: draft-ietf-cbor-7049bis-13.txt Thread-Index: AQHV9Y179Q8/DTmj3ki29GtqI3c69Kg/MNiAgAFaIAA= Date: Mon, 9 Mar 2020 16:49:11 +0000 Message-ID: References: <158370158858.6863.7397458491055240720@ietfa.amsl.com> <69C2E638-424A-454A-8F3F-763CB4017A64@tzi.org> In-Reply-To: <69C2E638-424A-454A-8F3F-763CB4017A64@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 307f1bb0-375f-439a-d26f-08d7c449caec x-ms-traffictypediagnostic: HE1PR0702MB3643: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0337AFFE9A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(346002)(366004)(136003)(39860400002)(199004)(189003)(8936002)(8676002)(6916009)(33656002)(81166006)(81156014)(316002)(6486002)(478600001)(966005)(66476007)(5660300002)(66946007)(76116006)(66446008)(44832011)(2616005)(186003)(26005)(91956017)(2906002)(66556008)(86362001)(64756008)(66574012)(6512007)(6506007)(53546011)(4326008)(450100002)(36756003)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3643; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xnN1xy2ZcSt9DBZ/yrnibOktLcjdxVwv/oq3qm1kXrJI3F/yiFUW7g16iVUkFH3K5XzI/SaVVi0jG3QW83nBsXkZheTV+i7oF83svDM4So05IMBWILNBWGEcMeOiHWMVpN8eo8a2QFEI4HRqQAstje6Tlt4craN/VI1lr9pg0NOxVsk7f4ocKFrrzrVUkHog53i8YLFbCvpnR9d9Wd/RYXKUabFJwAZSwLORkWFdtsME13GBG5m44lgt8rS4dSYKXmA9nzJmLzynZlAEzPVSynENOPZngugClv9/QYI/xHkXauWKb28WEpgRhtfFOBkJ/3fQmlrjxOAHhf1jJxWgAj3Zmnq9y3YfALdhSRmzN5Rt7jH6XL9PU3KazvGkshB+Oy58VR8XFjerogi2vEAA3w1u8/uvvTanTysIkQtN8EY5YgCGM4TzAcTlIfEuNz3ESTJOGAibs34ZNR+r6oLyYKYbPlVjrpqznsx4So4yT1Eg2AZgdkBSJvKjAMjZ+IsPNXhZqim310oKg9JIyCAa1w== x-ms-exchange-antispam-messagedata: EKow1EutF9B0p5iXCX2Vn10fV/w/QJB8zRVM49nNjE3Fcb5O5ww4jBQXBtDzOQskl0U4clt/KE4GwG6rqyWdnMTjK8uJmTKTSMS07cloiypTpLmGCKOXhkFnLVlwDx7ErP2yXOvio8dYQjWAOCD+ZA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <9B4AF2761A9FA24AAB202BE0095EA5AC@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 307f1bb0-375f-439a-d26f-08d7c449caec X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2020 16:49:11.1669 (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: NTt6DKldiTZTpxYJ2/LjemFfWPqELmpZ89zZs+LWtht5bJtE/GMDd9q6HbCUmTgILVugdmV7D+2daN4CZfbOubglGlMjfSb6mxFv8RSqv1K5zOTR5fHBtb4AyLLmv6Yr X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3643 Archived-At: Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-7049bis-13.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 16:49:24 -0000 Q0JPUiB3ZywNCiANClRoaXMgc3RhcnRzIGEgdHdvIHdlZWtzIFdHIGxhc3QgY2FsbCBvbiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jYm9yLTcwNDliaXMtMTMgLCBlbmRp bmcgb24gKk1vbmRheSwgMjNyZCBNYXJjaCouICBUaGlzIGlzIHRoZSBzZWNvbmQgV0dMQyBvbiB0 aGlzIGRvY3VtZW50Lg0KDQpQbGVhc2Ugc2VuZCBpbnB1dHMgdG8gdGhlIG1haWxpbmcgbGlzdCB0 aGF0IHlvdSBoYXZlIHJlYWQgdGhlIGRvY3VtZW50IGFuZCBkbyBvciBkbyBub3QgZmVlbCBpdCBp cyByZWFkeSB0byBwcm9ncmVzcywgYWxvbmcgd2l0aCBhbnkgaXNzdWVzIHRoYXQgeW91IGJlbGll dmUgbmVlZCB0byBiZSBkZWFsdCB3aXRoLg0KIA0KV2Ugd2lsbCBkaXNjdXNzIGFueSBvcGVuIGlz c3VlcyB3ZeKAmXZlIGdvdHRlbiBkdXJpbmcgb3VyIG5leHQgbWVldGluZywgc2NoZWR1bGVkIGZv ciBUaHVyc2RheSwgTWFyY2ggMjYuDQogDQpDQk9SIENoYWlycw0KSmltICYgRnJhbmNlc2NhDQoN Cu+7v09uIDA4LzAzLzIwMjAsIDIyOjEwLCAiQ0JPUiBvbiBiZWhhbGYgb2YgQ2Fyc3RlbiBCb3Jt YW5uIiA8Y2Jvci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjYWJvQHR6aS5vcmc+IHdy b3RlOg0KDQogICAgVGhpcyB2ZXJzaW9uIGNsb3NlcyBhbGwgb2YgdGhlIHJlbWFpbmluZyBpc3N1 ZXMgKGV4Y2VwdCBmb3Igb25lIHRhc2sgdGhhdCBjYW4gYmUgZG9uZSBkdXJpbmcgV0dMQykuDQog ICAgQXMgZGlzY3Vzc2VkIGluIHRoZSBpbnRlcmltcywgd2UgYmVsaWV2ZSB0aGlzIGlzIG5vdyBh dCB0aGUgc3RhZ2Ugd2hlcmUgd2Ugd2FudCB0byBoYXZlIHRoZSBXb3JraW5nLUdyb3VwIExhc3Qg Q2FsbC4NCiAgICANCiAgICBHcsO8w59lLCBDYXJzdGVuDQogICAgDQogICAgDQogICAgPiBPbiAy MDIwLTAzLTA4LCBhdCAyMjowNiwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KICAg ID4gDQogICAgPiANCiAgICA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICA+IFRoaXMgZHJh ZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXByZXNlbnRh dGlvbiBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9ucyBXRyBvZiB0aGUgSUVURi4NCiAgICA+IA0K ICAgID4gICAgICAgIFRpdGxlICAgICAgICAgICA6IENvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXBy ZXNlbnRhdGlvbiAoQ0JPUikNCiAgICA+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBDYXJzdGVu IEJvcm1hbm4NCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICBQYXVsIEhvZmZtYW4NCiAg ICA+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWNib3ItNzA0OWJpcy0xMy50eHQNCiAg ICA+IAlQYWdlcyAgICAgICAgICAgOiA3NA0KICAgID4gCURhdGUgICAgICAgICAgICA6IDIwMjAt MDMtMDgNCiAgICA+IA0KICAgID4gQWJzdHJhY3Q6DQogICAgPiAgIFRoZSBDb25jaXNlIEJpbmFy eSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENCT1IpIGlzIGEgZGF0YSBmb3JtYXQNCiAgICA+ICAg d2hvc2UgZGVzaWduIGdvYWxzIGluY2x1ZGUgdGhlIHBvc3NpYmlsaXR5IG9mIGV4dHJlbWVseSBz bWFsbCBjb2RlDQogICAgPiAgIHNpemUsIGZhaXJseSBzbWFsbCBtZXNzYWdlIHNpemUsIGFuZCBl eHRlbnNpYmlsaXR5IHdpdGhvdXQgdGhlIG5lZWQNCiAgICA+ICAgZm9yIHZlcnNpb24gbmVnb3Rp YXRpb24uICBUaGVzZSBkZXNpZ24gZ29hbHMgbWFrZSBpdCBkaWZmZXJlbnQgZnJvbQ0KICAgID4g ICBlYXJsaWVyIGJpbmFyeSBzZXJpYWxpemF0aW9ucyBzdWNoIGFzIEFTTi4xIGFuZCBNZXNzYWdl UGFjay4NCiAgICA+IA0KICAgID4gICBUaGlzIGRvY3VtZW50IGlzIGEgcmV2aXNlZCBlZGl0aW9u IG9mIFJGQyA3MDQ5LCB3aXRoIGVkaXRvcmlhbA0KICAgID4gICBpbXByb3ZlbWVudHMsIGFkZGVk IGRldGFpbCwgYW5kIGZpeGVkIGVycmF0YS4gIFRoaXMgcmV2aXNpb24gZm9ybWFsbHkNCiAgICA+ ICAgb2Jzb2xldGVzIFJGQyA3MDQ5LCB3aGlsZSBrZWVwaW5nIGZ1bGwgY29tcGF0aWJpbGl0eSBv ZiB0aGUNCiAgICA+ICAgaW50ZXJjaGFuZ2UgZm9ybWF0IGZyb20gUkZDIDcwNDkuICBJdCBkb2Vz IG5vdCBjcmVhdGUgYSBuZXcgdmVyc2lvbg0KICAgID4gICBvZiB0aGUgZm9ybWF0Lg0KICAgID4g DQogICAgPiANCiAgICA+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlz IGRyYWZ0IGlzOg0KICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1jYm9yLTcwNDliaXMvDQogICAgPiANCiAgICA+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVk IHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAgICA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWNib3ItNzA0OWJpcy0xMw0KICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWNib3ItNzA0OWJpcy0xMw0KICAgID4gDQogICAg PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQogICAg PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jYm9yLTcwNDli aXMtMTMNCiAgICA+IA0KICAgID4gDQogICAgPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAgPiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KICAgID4gDQogICAgPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxh YmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLw0KICAgID4gDQogICAgPiANCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBDQk9SIG1haWxpbmcgbGlzdA0KICAgID4g Q0JPUkBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jYm9yDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCiAgICBDQk9SIG1haWxpbmcgbGlzdA0KICAgIENCT1JAaWV0Zi5vcmcNCiAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3INCiAgICANCg0K From nobody Mon Mar 9 15:20:12 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 22F0E3A078C for ; Mon, 9 Mar 2020 15:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CDya7W-tMMSb for ; Mon, 9 Mar 2020 15:20:08 -0700 (PDT) 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 A60FF3A043D for ; Mon, 9 Mar 2020 15:20:08 -0700 (PDT) Received: from [172.16.42.113] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48bt2H0FX1z11cb; Mon, 9 Mar 2020 23:20:06 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 605485206.414951-b26ff691eaae69a1f9c260e10a769542 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Mon, 9 Mar 2020 23:20:06 +0100 Message-Id: <10E40B0C-6EA5-49B8-9BE8-F96A97F6A932@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [Cbor] ABNF in CDDL X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 22:20:10 -0000 When you wake up tomorrow to an I-D deadline that has passed, and need = some coffee table reading for relaxing: https://tools.ietf.org/html/draft-bormann-cbor-cddl-freezer-03#section-4 It is quite readable, without a need to touch RFC 8610 at all. I haven=E2=80=99t implemented my proposal yet, but will soon, to find = the nooks and crannies. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 9 16:18: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 E8BF33A0920 for ; Mon, 9 Mar 2020 16:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=microsoft.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 NKE5ktEs5y5u for ; Mon, 9 Mar 2020 16:18:05 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650132.outbound.protection.outlook.com [40.107.65.132]) (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 0D42A3A091F for ; Mon, 9 Mar 2020 16:18:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WyfPnh0ZWaBr3r5d7qDG6YExIEsT532RZC7J5KUsS1DOY6dlSyi9CiGBW9QyOhp5L/cpntzoPBd9+qbypMIAmasfNpP6s9NTWXTcbEhIyR7FeBLcbcc60KuKe72FB7kWxY9pmMKgvFNzg/bAscQcq+sPFpR/7i76V0mrG/ekjWma/bVpYl8O03JiGEeGc/DNPsFSzUXSjIJWbPTUmT9z7un+9PJuXTjaxZbBkb5hFeQTrGjZMguS/kQtfY3Oi/GNr1mm/01uJ6nvf4zcM1T22V1fhBMtAYs0q0m1FZEbyDDztCOnDztxiDp3rhPqhuip1QDUzuRGrWiH1GSzttDcEg== 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=vl1s1d9+B6L6awg7cnSNP8oT2RScHZ5v+tEg1PF6eZU=; b=bxxfcks/MPu2oT4T/Beco1su/TVmpxIz5ni01S4gu75j7Y3DvOgfv56/ZRLnRHgT7VkFoTRKb9bkeLiumdR6hP+A5GA4KoSEcGb+zMt2zGSOsayalkCOjwIq+4sZkm8CgKsD98ryWSIjfgNqUA2UfTy2La73902Le/pwIg+TnZopIflMWuhpj/uZgCmssf8/wCaadQAuJAtXaWT40rERMaM33LrG+N8n0fte1fD5G4na+/XMIvatoI2cl0LEMJkQ8i4qnkYpLaryjTxiuzp66qCpQ9Mkbc5qL1MPjax0qKaBlzgf8FVAjekJiXmNPMYEG+qt+d8qNENlZpvSssL+tg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vl1s1d9+B6L6awg7cnSNP8oT2RScHZ5v+tEg1PF6eZU=; b=SY1tRxRyaPFBEzKJKj+WOILrj+nNYikbZ/tYUSshYlrZOEN/TRU49d15kQ7tkbFpIJI2WTf8adjjO2E5N8HtXYVUFuERzgLzbKaGBVtdayu00BO2xtnFGP23wVXhIxVv7Fev341aX2WNg0GxBdvIXUirQTe8wTxTKfJMcA8943o= Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0762.namprd00.prod.outlook.com (2603:10b6:610:61::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2849.0; Mon, 9 Mar 2020 23:18:02 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::9544:f123:1e65:f212]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::9544:f123:1e65:f212%9]) with mapi id 15.20.2848.000; Mon, 9 Mar 2020 23:18:02 +0000 From: Mike Jones To: "cbor@ietf.org" CC: Anthony Nadalin , "cabo@tzi.org" Thread-Topic: Allocating a CBOR tag for RFC 3339 date strings Thread-Index: AdX2W8DDbDpPWeilQOiqMeakxrA6RA== Date: Mon, 9 Mar 2020 23:18:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5473ae63-f9b3-4833-a74f-0000a5a5c205; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-03-09T21:41:21Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.83.137] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 02d578f7-0f3f-418a-a810-08d7c4801d86 x-ms-traffictypediagnostic: CH2PR00MB0762:|CH2PR00MB0762: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0337AFFE9A x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10019020)(4636009)(136003)(39860400002)(366004)(396003)(346002)(376002)(199004)(189003)(52536014)(5660300002)(8676002)(76116006)(8990500004)(10290500003)(316002)(6506007)(81156014)(7696005)(81166006)(33656002)(21615005)(2906002)(66556008)(66446008)(66476007)(64756008)(66946007)(4326008)(86362001)(966005)(71200400001)(26005)(186003)(9686003)(6916009)(54906003)(55016002)(478600001)(4744005)(8936002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0762; H:CH2PR00MB0678.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gxRDv16mAJG/u+eDvqVOCgsuX2SlnzSC5ggAG72TlE2+WYNbr9LRtxTLrZPjd1T+Beoy0lPq5gdMAjbXMQ2hFwNB1SJhwXEKnib29KfpfvpIQjiX9aIvORdzkZJXjO+CcO6wIPQbmG1GRzXQgPbHFoCyTuvYnF5epJGTjCwIs3O7VY1f4eMAI6guR1a8chQAwoozXAj+h2F1vqx812Ns0qxZ2UnLN7VsV4XwnI9cHWMPWyYKISRO4S4QS5R1WXXVW86E0YX0zq4y4W4g+osDwSwtCF4NQwY3317rppFtmiUqeordUUblZ4bVox4Mq0cWHTbsDje89AiaXl+q6r8alMTSD0/jgYHqa5lOsw7CgM5mDzlHM74CyqBXIQJAfUIrfuxKorgKvt6gcKfoTcPEgCCcMVmQk7jLi6Z7jgKaB7WCxRPRZ0qg5G8A7beXdjsLRn2jBxd69zEiJ1aufQnbkoiB86WMygofiY6I5g71ZAqukw/ZjNikYpmTQzLJ5rNhXAg6wJrU1OV6KnoLRrzOnEfVKjgzLjFrwAAnK1VZVXsMEgKduBEp3L2Ml1C3K8RBjigWPTZGLgkcxmZqs36uPuhlSImx0Q6bpb1gXGL6KfLic1jhYe6iDjL3tGGpXmhvIbo/a298ZZk6e3MSeZGYng== x-ms-exchange-antispam-messagedata: Ae+K0kkbZG1yvKdjX80dQykhDpWVPh4zLh4dAvEz8il+/8sl7wHKCeurs4vOsJrFrsaOqgUFlbsDUaQwind6V3Evly97Opp8EcYZ2QcYQxnzXaaPuwIXuJrcq+Kzev0DlzQhya8Bo+Oe0CGKBTigVw== Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0678B46E058F2D24C6B544DBF5FE0CH2PR00MB0678namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 02d578f7-0f3f-418a-a810-08d7c4801d86 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2020 23:18:02.5042 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NFAiQONfh8jBwvftXI71hw0EnjAc612o76QnlBeHYQT6XP4xfP4RxvZIw4dxP+MJZA4iOU7ALggVUrs9HDaMBA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0762 Archived-At: Subject: [Cbor] Allocating a CBOR tag for RFC 3339 date strings X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 23:18:07 -0000 --_000_CH2PR00MB0678B46E058F2D24C6B544DBF5FE0CH2PR00MB0678namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have published the specification Concise Binary Object Representation (CB= OR) Tag for Date to allocate a CBOR tag for RFC 3339 full-date values. While there's already a tag f= or date-time values, the= re's currently no tag allocated for full-date values - a date string withou= t a time. The need for this arose for the ISO Mobile Driver's License spec= ification in the working group ISO/IEC JTC 1/SC 17 "Cards and security devices for personal identification". Thanks to Carsten Bormann for pointers on the best way to accomplish this. The specification is available at: * https://tools.ietf.org/html/draft-jones-cbor-date-tag-00 An HTML-formatted version is also available at: * https://self-issued.info/docs/draft-jones-cbor-date-tag-00.html -- Mike P.S. This notice was also posted at https://self-issued.info/?p=3D2059 and= as @selfissued. --_000_CH2PR00MB0678B46E058F2D24C6B544DBF5FE0CH2PR00MB0678namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have published the specification Concise Binary= Object Representation (CBOR) Tag for Date to allocate a CBOR tag for RFC 3339 full-d= ate values.  While there’s already a tag for dat= e-time values, there’s currently no tag allocated for full-date v= alues – a date string without a time.  The need for this arose f= or the ISO Mobile Driver’s License specification in the working group ISO= /IEC JTC 1/SC 17 “Cards and security devices for personal identif= ication”.

 

Thanks to Carsten Bormann for pointers on the best w= ay to accomplish this.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

        &nbs= p;             =              &n= bsp;            = ;       -- Mike

 

P.S.  This notice was also posted at https://self-issued.info/?p=3D2059 and as @selfissued.

 

--_000_CH2PR00MB0678B46E058F2D24C6B544DBF5FE0CH2PR00MB0678namp_-- From nobody Mon Mar 9 22:52:39 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 B2B793A076F for ; Mon, 9 Mar 2020 22:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rffqh-pkPdAI for ; Mon, 9 Mar 2020 22:52:31 -0700 (PDT) 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 9A9473A076E for ; Mon, 9 Mar 2020 22:52:31 -0700 (PDT) Received: from [172.16.42.113] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48c44965Fzz18mq; Tue, 10 Mar 2020 06:52:25 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: Date: Tue, 10 Mar 2020 06:52:25 +0100 X-Mao-Original-Outgoing-Id: 605512345.2027169-5bfa8b0ea228466f27c59b59643c9428 Content-Transfer-Encoding: quoted-printable Message-Id: <5BB66D81-6A55-4BDA-9D5F-DA4060AECB87@tzi.org> References: To: "cbor@ietf.org" X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Cbor] Allocating a CBOR tag for RFC 3339 date strings 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, 10 Mar 2020 05:52:38 -0000 It would be helpful if people who read this specification can send a = line or two to the mailing list. I=E2=80=99m going to recommend = registering this tag next week on Tuesday unless people see a serious = problem. In parallel, we can improve this specification. We haven=E2=80=99t really talked about the best way to handle these = small tag definition documents. I believe it would be best to do a = little bit of aggregation on them; maybe we can spend some time in the = interim tomorrow to discuss what is the best way to organize this = aggregation. This might include pulling in some of the most useful tag definitions = that are not available as I-D/RFC yet (e.g., tag 257 which is even = mentioned in 7049bis, but also others like 30, 31, 37, 260/261, 264/265, = 266/267 =E2=80=94 the choice here is totally personal, but not without = reason; we could develop these criteria a little bit to write them = down). Gr=C3=BC=C3=9Fe, Carsten > On 2020-03-10, at 00:18, Mike Jones = wrote: >=20 > I have published the specification Concise Binary Object = Representation (CBOR) Tag for Date to allocate a CBOR tag for RFC 3339 = full-date values. While there=E2=80=99s already a tag for date-time = values, there=E2=80=99s currently no tag allocated for full-date values = =E2=80=93 a date string without a time. The need for this arose for the = ISO Mobile Driver=E2=80=99s License specification in the working group = ISO/IEC JTC 1/SC 17 =E2=80=9CCards and security devices for personal = identification=E2=80=9D. > =20 > Thanks to Carsten Bormann for pointers on the best way to accomplish = this. > =20 > The specification is available at: > =E2=80=A2 = https://tools.ietf.org/html/draft-jones-cbor-date-tag-00 > =20 > An HTML-formatted version is also available at: > =E2=80=A2 = https://self-issued.info/docs/draft-jones-cbor-date-tag-00.html > =20 > -- Mike > =20 > P.S. This notice was also posted at https://self-issued.info/?p=3D2059 = and as @selfissued. > =20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Tue Mar 10 01:57:31 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 BA39F3A0E51; Tue, 10 Mar 2020 01:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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 1P-l-dWiZ7Im; Tue, 10 Mar 2020 01:57:28 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80084.outbound.protection.outlook.com [40.107.8.84]) (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 932113A0E4C; Tue, 10 Mar 2020 01:57:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bt7JkLJJB6XTIE6R+IDfQ/JL7ZBYvMgn7V9Rplsbc5gtreh3CGc5ogsRhi8BHnITNqUBEE+MvL5KpSrGT/b0FkqxjOWlPHda3L1T4GKLjv19jx8uXdhZRi2cSfhNZtEWgyIigVlV92xDQduQJ9Zru5z0/a8Xx/KOTWywj5YSM01XUoQ91vP1AXUxNk/RQBdZO1W5hAf4zrWe6LVlxlS6XN4/msZr5ioOcg/mO4BOdqMdHeJjPbWvnA+Af3MwwvlbvAOPsLl/YAxXbzvNYlzKWQSSW2utUC1HKhZ6DXho88ZCtasDGkv0XFxst+bXhBnhH9HFS+odbCvvlE0Z0OO60Q== 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=wJXfOlheYlVv4GvL5UtHd8XiMJ8mSRbH+GD/zd6Q3Zg=; b=Di+3wVw3JJ9YP0igiSviMbvit2GpAAN2rocFGzrow0fwGYXdgLoV5oEniNGHMS14aeSgRfWsBFNfYhoKDzACBT0DBQjLOoWS4+Ju43qg9HaBkbI4Am6rDMe2EpnMnrdcwLKpzKzCWrlYUZ2V1A8z0LJZzoFIehkBjPeEwLLw9T1fwDTU5LHuKbVIdvzxjPeaVffVETSQntkaQFvNGHIYzzJXXQrmnmVrVblNgAuvHnF1NhBjEDKCyp/2xmJiooqg9HPL0ffC2/JNJsHVU53/aF+QYXUpvZVH3sVfPkfI52wao0C3PaCGOmkoJ1Ky5jOM0uC+giH8DMt+tqiqKxJSIg== 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=wJXfOlheYlVv4GvL5UtHd8XiMJ8mSRbH+GD/zd6Q3Zg=; b=r9BmxMbwWilovppPkZyYLigR6DBUURRW96IAnmWsWQdvJ5wfQ1EXzKwrYfgygWTGO4QJqYGRO8Kg9LAcL+9PSPWNk6h8dlfv0Hbo3/NusrqlBa+357P4Y/LJ/G1pqbXHkwAwoms+iSIfrQfrHYq5SgYchybRxA1SzHOVBUSwe0E= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (52.133.6.18) by HE1PR0702MB3705.eurprd07.prod.outlook.com (52.133.7.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.9; Tue, 10 Mar 2020 08:57:22 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::e49e:708f:4fe7:5d02]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::e49e:708f:4fe7:5d02%4]) with mapi id 15.20.2814.007; Tue, 10 Mar 2020 08:57:22 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "draft-ietf-cbor-7049bis@ietf.org" Thread-Topic: =?utf-8?B?8J+UlCBXR0xDIG9uIGRyYWZ0LWlldGYtY2Jvci03MDQ5YmlzLTEz?= Thread-Index: AQHV9rnp3SHrJM/sMEmZ2y50F9KXNA== Date: Tue, 10 Mar 2020 08:57:22 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 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: e60be2a0-e72a-433b-2fdf-08d7c4d10c2f x-ms-traffictypediagnostic: HE1PR0702MB3705: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 033857D0BD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(346002)(136003)(376002)(39860400002)(189003)(199004)(33656002)(6916009)(316002)(2906002)(86362001)(478600001)(966005)(36756003)(66476007)(8936002)(66556008)(53546011)(81166006)(6506007)(66446008)(64756008)(71200400001)(66946007)(76116006)(66574012)(81156014)(5660300002)(6512007)(26005)(186003)(450100002)(6486002)(4326008)(44832011)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3705; H:HE1PR0702MB3818.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: 8I/FNxtssvJR29NRyCfWhDAmRi86g8gB8JFDHV091QXCg8WkxqnBbMm57AcXE7RAjHZ7FlV+2znoviY4hu88F+w1b8xKp7jpRs9QQID9zISZ7OTpW1NkX/r1ZtyDXCEFIEx1G1I2EJN08KRunwL7A9vXo2xbWdFpHIdAJekvS/QcDdEpaEGRoEa1JUwgGB/5dTclPxhDxHU2G1hkr2rnAtDP5T0blm/mKyAJITi5CjoO+w0quXJ/pXcQpHaIRtVe2ufKfROqWiYf80rzhZDiYh9iw1CZ8Hfd2mhdoeyiDuT1hz43FDgXL9GLXbDufkgfIogsc6KtxdSIwiextJ2DB8cg10ppWQfSIdW57RMUgpsOLKXo/sujZSSGPF7p5CWaqHyCGH7vjeKYZOhT+BU0cREjTbxcginEcfPSy0G4ZgDxmWgIVoeuZRAs3x6YOCw4T0z9uvdgxZiM/C7bGsXbP/lr9m6Osq/m1Pe8WOveJCvYWKymUuDnTllPxKSB86sz/4pUDdK28tfr+CrAE3OoBg== x-ms-exchange-antispam-messagedata: eciYlIVHwjFlUYOacnbIvqSJXwcTidPXu0L00DekBooTGkKMKeN0+eM3xTTIlwK3pdmeADrhRD3tpQj1WwmExIJbHlhIOBpClv2B4Kel/TKDnHt84ddHBAucQlrfw4jeyj0ZXqTYRccRIel6NSvn1Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e60be2a0-e72a-433b-2fdf-08d7c4d10c2f X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2020 08:57:22.6123 (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: IDGzQZ2Tc8/tGz4UfQVSs/eoYPa/JkCCLjOC0iDcHjSm44uC2CIfgl7oZJo8ZEeAGmQ73eigZt+Zv7PI9HaxhSDXb5f3jPNxnP43k3pcgaG4xs+7KUeApj8BVwM2SGck X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3705 Archived-At: Subject: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-7049bis-13?= 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, 10 Mar 2020 08:57:30 -0000 Tm93IHdpdGggdGhlIHJpZ2h0IHN1YmplY3QgZmllbGQuDQotLQ0KQ0JPUiB3ZywNCiAgICAgDQpU aGlzIHN0YXJ0cyBhIHR3byB3ZWVrcyBXRyBsYXN0IGNhbGwgb24gaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtY2Jvci03MDQ5YmlzLTEzICAsIGVuZGluZyBvbiAqTW9uZGF5 LCAyM3JkIE1hcmNoKi4gIFRoaXMgaXMgdGhlIHNlY29uZCBXR0xDIG9uIHRoaXMgZG9jdW1lbnQu DQogICAgDQpQbGVhc2Ugc2VuZCBpbnB1dHMgdG8gdGhlIG1haWxpbmcgbGlzdCB0aGF0IHlvdSBo YXZlIHJlYWQgdGhlIGRvY3VtZW50IGFuZCBkbyBvciBkbyBub3QgZmVlbCBpdCBpcyByZWFkeSB0 byBwcm9ncmVzcywgYWxvbmcgd2l0aCBhbnkgaXNzdWVzIHRoYXQgeW91IGJlbGlldmUgbmVlZCB0 byBiZSBkZWFsdCB3aXRoLg0KICAgICANCldlIHdpbGwgZGlzY3VzcyBhbnkgb3BlbiBpc3N1ZXMg d2XigJl2ZSBnb3R0ZW4gZHVyaW5nIG91ciBuZXh0IG1lZXRpbmcsIHNjaGVkdWxlZCBmb3IgVGh1 cnNkYXksIE1hcmNoIDI2Lg0KICAgICANCkNCT1IgQ2hhaXJzDQpKaW0gJiBGcmFuY2VzY2ENCiAg ICANCiAgICBPbiAwOC8wMy8yMDIwLCAyMjoxMCwgIkNCT1Igb24gYmVoYWxmIG9mIENhcnN0ZW4g Qm9ybWFubiIgPGNib3ItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2Fib0B0emkub3Jn PiB3cm90ZToNCiAgICANCiAgICAgICAgVGhpcyB2ZXJzaW9uIGNsb3NlcyBhbGwgb2YgdGhlIHJl bWFpbmluZyBpc3N1ZXMgKGV4Y2VwdCBmb3Igb25lIHRhc2sgdGhhdCBjYW4gYmUgZG9uZSBkdXJp bmcgV0dMQykuDQogICAgICAgIEFzIGRpc2N1c3NlZCBpbiB0aGUgaW50ZXJpbXMsIHdlIGJlbGll dmUgdGhpcyBpcyBub3cgYXQgdGhlIHN0YWdlIHdoZXJlIHdlIHdhbnQgdG8gaGF2ZSB0aGUgV29y a2luZy1Hcm91cCBMYXN0IENhbGwuDQogICAgICAgIA0KICAgICAgICBHcsO8w59lLCBDYXJzdGVu DQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgPiBPbiAyMDIwLTAzLTA4LCBhdCAyMjowNiwg aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KICAgICAgICA+IA0KICAgICAgICA+IA0K ICAgICAgICA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICAgICAgPiBUaGlzIGRyYWZ0IGlz IGEgd29yayBpdGVtIG9mIHRoZSBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24g TWFpbnRlbmFuY2UgYW5kIEV4dGVuc2lvbnMgV0cgb2YgdGhlIElFVEYuDQogICAgICAgID4gDQog ICAgICAgID4gICAgICAgIFRpdGxlICAgICAgICAgICA6IENvbmNpc2UgQmluYXJ5IE9iamVjdCBS ZXByZXNlbnRhdGlvbiAoQ0JPUikNCiAgICAgICAgPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDog Q2Fyc3RlbiBCb3JtYW5uDQogICAgICAgID4gICAgICAgICAgICAgICAgICAgICAgICAgIFBhdWwg SG9mZm1hbg0KICAgICAgICA+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWNib3ItNzA0 OWJpcy0xMy50eHQNCiAgICAgICAgPiAJUGFnZXMgICAgICAgICAgIDogNzQNCiAgICAgICAgPiAJ RGF0ZSAgICAgICAgICAgIDogMjAyMC0wMy0wOA0KICAgICAgICA+IA0KICAgICAgICA+IEFic3Ry YWN0Og0KICAgICAgICA+ICAgVGhlIENvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXByZXNlbnRhdGlv biAoQ0JPUikgaXMgYSBkYXRhIGZvcm1hdA0KICAgICAgICA+ICAgd2hvc2UgZGVzaWduIGdvYWxz IGluY2x1ZGUgdGhlIHBvc3NpYmlsaXR5IG9mIGV4dHJlbWVseSBzbWFsbCBjb2RlDQogICAgICAg ID4gICBzaXplLCBmYWlybHkgc21hbGwgbWVzc2FnZSBzaXplLCBhbmQgZXh0ZW5zaWJpbGl0eSB3 aXRob3V0IHRoZSBuZWVkDQogICAgICAgID4gICBmb3IgdmVyc2lvbiBuZWdvdGlhdGlvbi4gIFRo ZXNlIGRlc2lnbiBnb2FscyBtYWtlIGl0IGRpZmZlcmVudCBmcm9tDQogICAgICAgID4gICBlYXJs aWVyIGJpbmFyeSBzZXJpYWxpemF0aW9ucyBzdWNoIGFzIEFTTi4xIGFuZCBNZXNzYWdlUGFjay4N CiAgICAgICAgPiANCiAgICAgICAgPiAgIFRoaXMgZG9jdW1lbnQgaXMgYSByZXZpc2VkIGVkaXRp b24gb2YgUkZDIDcwNDksIHdpdGggZWRpdG9yaWFsDQogICAgICAgID4gICBpbXByb3ZlbWVudHMs IGFkZGVkIGRldGFpbCwgYW5kIGZpeGVkIGVycmF0YS4gIFRoaXMgcmV2aXNpb24gZm9ybWFsbHkN CiAgICAgICAgPiAgIG9ic29sZXRlcyBSRkMgNzA0OSwgd2hpbGUga2VlcGluZyBmdWxsIGNvbXBh dGliaWxpdHkgb2YgdGhlDQogICAgICAgID4gICBpbnRlcmNoYW5nZSBmb3JtYXQgZnJvbSBSRkMg NzA0OS4gIEl0IGRvZXMgbm90IGNyZWF0ZSBhIG5ldyB2ZXJzaW9uDQogICAgICAgID4gICBvZiB0 aGUgZm9ybWF0Lg0KICAgICAgICA+IA0KICAgICAgICA+IA0KICAgICAgICA+IFRoZSBJRVRGIGRh dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KICAgICAgICA+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2Jvci03MDQ5YmlzLw0KICAg ICAgICA+IA0KICAgICAgICA+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWls YWJsZSBhdDoNCiAgICAgICAgPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1jYm9yLTcwNDliaXMtMTMNCiAgICAgICAgPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LWlldGYtY2Jvci03MDQ5YmlzLTEzDQogICAgICAgID4gDQogICAgICAg ID4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KICAg ICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNib3It NzA0OWJpcy0xMw0KICAgICAgICA+IA0KICAgICAgICA+IA0KICAgICAgICA+IFBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24NCiAgICAgICAgPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgICAgICA+IA0KICAgICAgICA+IElu dGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCiAg ICAgICAgPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KICAgICAgICA+IA0K ICAgICAgICA+IA0KICAgICAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgICAgID4gQ0JPUiBtYWlsaW5nIGxpc3QNCiAgICAgICAgPiBDQk9S QGlldGYub3JnDQogICAgICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jYm9yDQogICAgICAgIA0KICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgICAgICBDQk9SIG1haWxpbmcgbGlzdA0KICAgICAgICBDQk9S QGlldGYub3JnDQogICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2Jvcg0KICAgICAgICANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgIENCT1IgbWFpbGluZyBsaXN0DQogICAgQ0JPUkBpZXRmLm9y Zw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Jvcg0KICAgIA0K DQo= From nobody Tue Mar 10 09:15: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 7ED293A160C for ; Tue, 10 Mar 2020 09:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=microsoft.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 1Y5bMhkTT1sw for ; Tue, 10 Mar 2020 09:15:47 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640135.outbound.protection.outlook.com [40.107.64.135]) (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 838903A1516 for ; Tue, 10 Mar 2020 09:15:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hGnTJT4HnQ6Lb6XGBfZRwG/HYFdsoLDeFSkf+qWt4j8mlKTH4e84GN2GCidMHo0sk1aWWjhwqwmJ+AnIzUgmwSCGGT5qZj89lvLXo3tOXRj0Bm8IcQa3Hj+yQG9+WyjpomTHihWYHVVJycF90BmAl/lEtGxxiKgGKFS8woXrKiMUatZ4S9hwx040e7TT5rV1ll2JZ1Emcdw14br6ZL4kZTBLXx1CxotbcPKKLeJi7eUweOl2OIEEt4yF9ltP6pOhoee7uQId0JL8h28Z0pHoa/vVuKgEbeWzSBH/IVyUzoduOZg8Kdz8gHo+1lG4Jlaym8BowNe/SJji9DKeJLfzNw== 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=PBNVmbSlAia5lHZRWEwvgeSu6u1fctcZGDHcSvFJPFY=; b=JbBfR86nxMKyOOYr21YPYARk2WZpiSJa9zFhQ3f6VXDbkVwv4ELXvkOzR/g2BQPALMMv3rg0RVn/aQJ/BDIJFBTYXonYO9qfYlP5PNsONS8yhine3NAMOwZUV8EVf8itpfs7HBPN4fjwOkZEOwZk/O/i+eGcpCHUL9A4Xi/qCPwotllEozvvJLDRPxRcSky/865uNtGMGuGUjoEJYtEjNaTEv+J8eUT2Mr2QrBdjkJk0WnFsVyXymJsQR5rW8xVDmUdXEtl0vYEagdNO/B3OFHCgqwuvHBZVJojoU2WuFGXJSsuGcD8DroaXJ9Xev89qB4zZPACtjICNj3zs7QZGIw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PBNVmbSlAia5lHZRWEwvgeSu6u1fctcZGDHcSvFJPFY=; b=iWsKoYv5zdsWq6+2nLPpWN2j1TP6axv3QQ3XKL+V3VqLKGcckslpGBzRlDwwv95Zq4ZcfdJf2s4BETg7f4MV/BRX/XLKEDomAy+N/WoRcFY5avQWvtkGVz/CfxGoVY4s92z6UVAQQRyUjnKh+FIlx4zOhpNuyw9MZM18mN9xddY= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0557.namprd00.prod.outlook.com (2603:10b6:208:fd::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2848.0; Tue, 10 Mar 2020 16:15:45 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::fcaa:2e27:4c08:f703]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::fcaa:2e27:4c08:f703%8]) with mapi id 15.20.2848.000; Tue, 10 Mar 2020 16:15:45 +0000 From: Mike Jones To: Francesca Palombini , "ietf@augustcellars.com" CC: "cabo@tzi.org" , Anthony Nadalin , "cbor@ietf.org" Thread-Topic: Presentation at IETF 107 on CBOR date tag Thread-Index: AdX29sgE3YKmpGW5RbSIXFjduyU7QQ== Date: Tue, 10 Mar 2020 16:15:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=0834556d-bcb2-49bb-b079-00002c001d0d; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-03-10T16:11:23Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.83.137] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 06088d53-8bda-4a7b-dc2d-08d7c50e49c8 x-ms-traffictypediagnostic: MN2PR00MB0557:|MN2PR00MB0557: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4303; x-forefront-prvs: 033857D0BD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(136003)(396003)(39860400002)(346002)(376002)(189003)(199004)(8676002)(8936002)(86362001)(110136005)(6506007)(316002)(9686003)(54906003)(966005)(71200400001)(4326008)(558084003)(81156014)(10290500003)(478600001)(8990500004)(52536014)(81166006)(66446008)(26005)(5660300002)(33656002)(64756008)(66946007)(2906002)(55016002)(66476007)(66556008)(7696005)(186003)(76116006); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR00MB0557; H:MN2PR00MB0686.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7OBk8egBAIiszaeZUn4sTLUfP8oKo+SHdOIMdDKbiY8AEvcK2GlW3IzXVvGmegrRJAlTSa1BcQc3BEue0yH7xRnm4tpwiV4O19XPMOKeNagu1fvWXZhhxqTtR51IY5Ay0lkDxFKKbiD7KEzMH3Q8eo7Sy6xixGFMlqfzbrmV5qNROvvTYEgnujaGzJZLX0gdiFIkaqzey4ZKJPkJ1vu2bezbdBYsqQrOOaGl1FJ+aZSucPx5KxHNckPoSK1sYrJ+j/Fc/10flC8iJ+3ZMPMDSK5rc1Clsz+L9mzQdCJTZ/zXOVWe2PfLr/OfiaXYDfJvixOtI0s6Vx05hH1O9dIy/QeqCIJOLzUcAcmwEHCI/eJ7Whm1TPDgsPQbNbmVZEckbUKK68nb2NqXkf9iIvXMJ4QeGV1kTkf5nBCIhPiQfbbeYONPupCKqvU2zrsrDqFlnVIezxyOD/ZB9pXgOv1IWDLgSBQ6R1KXVc2YJZnPbmN8NS8h76ZnfdYeRqRLncoluxuFXDD36BPvuqSU9o51lA== x-ms-exchange-antispam-messagedata: Oic2p4+E7bsWX7uf85GbFDeOTHYeCw8HE859hIZmsbT7NHBP4YcLmLg128uw8lwm8Hl1CMfSqe+OlU4SL+oKdgVA/ie+I00vaN4i8Qr6M7uHk9PlJvwfdQKIjllmmTyCJQMHowodf2mbSrF/9u86eg== Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0686966005C51977B13AC223F5FF0MN2PR00MB0686namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 06088d53-8bda-4a7b-dc2d-08d7c50e49c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2020 16:15:45.3273 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: I4AxyczhWiUfUklRH8J4UQ8TwDuyJqA6nzXSmxeOsUltcSWKknPVBTWbiaiaBS0l+VLpnjxugShGz6tVbjghCw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0557 Archived-At: Subject: [Cbor] Presentation at IETF 107 on CBOR date 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, 10 Mar 2020 16:15:50 -0000 --_000_MN2PR00MB0686966005C51977B13AC223F5FF0MN2PR00MB0686namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like 5-10 minutes at IETF 107 to discuss next steps for https://tools.i= etf.org/html/draft-jones-cbor-date-tag-00, which allocates a CBOR date tag. Thanks, -- Mike --_000_MN2PR00MB0686966005C51977B13AC223F5FF0MN2PR00MB0686namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d like 5-10 minutes at IETF 107 to discuss n= ext steps for https://tools.ietf.org/html/draft-jones-cbor-date-tag-00, which allocat= es a CBOR date tag.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        Thanks,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

--_000_MN2PR00MB0686966005C51977B13AC223F5FF0MN2PR00MB0686namp_-- From nobody Tue Mar 10 09:39: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 3AA723A168D for ; Tue, 10 Mar 2020 09:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GjkWMfvsEYUl for ; Tue, 10 Mar 2020 09:39:40 -0700 (PDT) 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 1C7B53A1693 for ; Tue, 10 Mar 2020 09:39:40 -0700 (PDT) Received: from [172.16.42.113] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48cLQy23Chzyqg; Tue, 10 Mar 2020 17:39:38 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <025a01d5f57c$91023b10$b306b130$@augustcellars.com> Date: Tue, 10 Mar 2020 17:39:37 +0100 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 605551177.581777-8eb8738bd4a48e4291558ae84af08b7c Content-Transfer-Encoding: quoted-printable Message-Id: <7710A406-8605-4D24-A3FE-869BB1C8D2D6@tzi.org> References: <025a01d5f57c$91023b10$b306b130$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Cbor] Planning for the Vancouver meeting 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, 10 Mar 2020 16:39:51 -0000 Hi Jim, > On 2020-03-08, at 20:05, Jim Schaad wrote: >=20 >=20 > 1. What document or proposed document are you addressing? > 2. How long do you think it is going to take? https://tools.ietf.org/html/draft-bormann-cbor-cddl-freezer-03 This now has a number of items that could be picked up and made into one = or more draft specifications, among these: (a) the JSON form of a CDDL spec (b) ABNF in CDDL We should gauge interest in the WG for completing these specifications. > On 2020-03-08, at 20:05, Jim Schaad wrote: >=20 >=20 > 1. What document or proposed document are you addressing? > 2. How long do you think it is going to take? https://tools.ietf.org/html/draft-bormann-cbor-time-tag-03 This may also be interesting in the context of Mike Jones=E2=80=99 draft It probably makes sense to pursue the two on their own timelines, but we = may want to ponder that part of the landscape, including what other = functions we want to put into the time-tag. > 3. Are you planning to give the presentation locally or remotely? If = you > are going to be remote is there somebody who might be able to do it = locally? Planning is a bit hard at the moment, but I=E2=80=99d say remote is more = likely. Obviously, we should also process the WGLC comments on 7049bis. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Mar 10 12:12: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 5CF1B3A093B for ; Tue, 10 Mar 2020 12:12:15 -0700 (PDT) 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 aC6wx7su4M1l for ; Tue, 10 Mar 2020 12:12:13 -0700 (PDT) Received: from mail.pdv-fs.de (mail.pdv-fs.de [213.208.220.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FE73A095A for ; Tue, 10 Mar 2020 12:12:12 -0700 (PDT) Received: from mail.pdv-fs.de (unknown [192.168.180.95]) by mail.pdv-fs.de (Postfix) with ESMTPS; Tue, 10 Mar 2020 20:12:10 +0100 (CET) Received: from EXCHDB1.pdv-fs.de (192.168.180.94) by EXCHDB2.pdv-fs.de (192.168.180.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 10 Mar 2020 20:12:09 +0100 Received: from EXCHDB1.pdv-fs.de ([fe80::6c4a:8b1b:60f4:4437]) by EXCHDB1.pdv-fs.de ([fe80::6c4a:8b1b:60f4:4437%15]) with mapi id 15.01.1713.009; Tue, 10 Mar 2020 20:12:09 +0100 From: =?utf-8?B?UmljaHRlciwgSsO2cmc=?= To: Carsten Bormann , "cbor@ietf.org" Thread-Topic: [Cbor] Allocating a CBOR tag for RFC 3339 date strings Thread-Index: AQHV9mkJYp1jPHQwlkmFDaGg+cN5yahBQpCAgADrN/A= Date: Tue, 10 Mar 2020 19:12:09 +0000 Message-ID: References: <5BB66D81-6A55-4BDA-9D5F-DA4060AECB87@tzi.org> In-Reply-To: <5BB66D81-6A55-4BDA-9D5F-DA4060AECB87@tzi.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.185.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TMASE-Version: DDEI-3.5-8.5.1020-25282.002 X-TMASE-Result: 10--12.375500-10.000000 X-TMASE-MatchedRID: jY540aspUU5pF64QACE+6SyKzJY7d2nbYERxjzVaKh3B8fZdmGC6ENQw +SLRgh+hzsyl/67iw++TnOeejF/wC3w7IPqRn1V9KpEngz2rs6/bKn2RRg4ex+ZMicrOlIVJw+M zwuh3HEY789MRlPRgIGmK24SSIESDr3tEZ4R0eb4J8QiVTQrM2KGdDpakt6BfBCzD0Dc8iUufMR 5C3+zgm3ld2u7MAaWCpSg1G+N/76wvY6V8986cVaJVTu7sjgg1OZUkkswTRZiwRV8TUkxV/V7nN 5dEttkXwkAoepAUQn8uzc30rY7blO6O03Qa5JcLvOAv94sAIMT5/a0OB377sMicqvB+icUL/DrA fnzvTp/i8zVgXoAltj2Xsf5MVCB1jaPj0W1qn0R7f8rdN44wGKE3Jo4yiIT8yrnfGIZPVqPt7dw axEbPOCExVVxOq/6RLjMDfpyruyQ= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 X-TMASE-INERTIA: 1-0;;J4gzHMCxkPyYUJl0x8cA1w==;; Archived-At: Subject: Re: [Cbor] Allocating a CBOR tag for RFC 3339 date strings 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, 10 Mar 2020 19:12:22 -0000 PiBJdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHBlb3BsZSB3aG8gcmVhZCB0aGlzIHNwZWNpZmljYXRp b24gY2FuIHNlbmQgYSBsaW5lIG9yIHR3byB0bw0KPiB0aGUgbWFpbGluZyBsaXN0LiAgSeKAmW0g Z29pbmcgdG8gcmVjb21tZW5kIHJlZ2lzdGVyaW5nIHRoaXMgdGFnIG5leHQgd2VlayBvbg0KPiBU dWVzZGF5IHVubGVzcyBwZW9wbGUgc2VlIGEgc2VyaW91cyBwcm9ibGVtLiAgSW4gcGFyYWxsZWws IHdlIGNhbiBpbXByb3ZlIHRoaXMNCj4gc3BlY2lmaWNhdGlvbi4NCg0KSXQncyBpbiBsaW5lIHdp dGggdGhlIHJlcXVlc3QgSSBtYWRlIGEgeWVhciBhZ28gWzFdIHRoYXQgaW4gZW5jb2RlcyB0aGUg ZGF0ZSBhcyANCllZWVktTU0tREQuIEkgcmVxdWVzdGVkIGFub3RoZXIgZW5jb2RpbmcgaW4gZGF5 cy1zaW5jZS1hbi1lcG9jaCANCihlLmcuIDE5NzAtMDEtMDEpLiBFbmNvZGVkIGFzIG1ham9yIHR5 cGUgMCBvciAxLiBUaGlzIHdvdWxkIGJlIGZhc3RlciBmb3IgDQp0aGUgY2FzZSB3aGVyZSB0aGUg ZGF0ZSBpcyBzdG9yZWQgYXMgYSBkYXkgY291bnQgc2luY2Ugc29tZSBmaXhlZCBkYXRlLiANCkNv bnZlcnNpb24gYmV0d2VlbiB0aGUgdHdvIHJlcHJlc2VudGF0aW9ucyBpcyBhIGNvbW1vbiBvcGVy YXRpb24gdGhhdCANCnNob3VsZCBiZSBvZmZlcmVkIHdpdGggYW55IGRhdGUvdGltZSBsaWJyYXJ5 Lg0KSSByZXF1ZXN0ZWQgdGFnIDEwMCBpbnN0ZWFkIG9mIDEwMDQuIEknbSBub3QgdmVyeSBhdHRh Y2hlZCB0byB0YWcgMTAwLCANCmJ1dCBJIHdvdWxkIGxpa2UgdGFnIDEwMCB0byBiZSB1c2VkIGlu c3RlYWQuDQoNCj4gV2UgaGF2ZW7igJl0IHJlYWxseSB0YWxrZWQgYWJvdXQgdGhlIGJlc3Qgd2F5 IHRvIGhhbmRsZSB0aGVzZSBzbWFsbCB0YWcgZGVmaW5pdGlvbg0KPiBkb2N1bWVudHMuIA0KDQpT aW5jZSBJIGhhdmUgYWxyZWFkeSByZXF1ZXN0ZWQgc2V2ZXJhbCB0YWdzLCBidXQgaGF2ZSBub3Qg cmVjZWl2ZWQgYW55IGZlZWRiYWNrLCANCkkgd291bGQgYXBwcmVjaWF0ZSBpdCBpZiBzb21lb25l IHdvdWxkIHBvaW50IG91dCB0aGUgY29ycmVjdCB3YXkgdG8gcmVxdWVzdCB0aGVtLiANCk90aGVy d2lzZSB0aGlzIGlzIGEgcmF0aGVyIGRpc2FwcG9pbnRpbmcgZXhwZXJpZW5jZSB0byBleHRlbmQg Q0JPUi4gDQoNCi0gSsO2cmcNCg0KWzFdIGh0dHBzOi8vai1yaWNodGVyLmdpdGh1Yi5pby9DQk9S L2RhdGUuaHRtbA0KDQo= From nobody Wed Mar 11 06:58:23 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 265DD3A193B for ; Wed, 11 Mar 2020 06:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] 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 q83DFqvFYKRJ for ; Wed, 11 Mar 2020 06:58:20 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20600.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::600]) (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 AE1733A1944 for ; Wed, 11 Mar 2020 06:58:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VCfuREfciTpA/1teOXumC/xjSW4dHwFALnfBzuOGOV6nS4gBByyxPHM8rWXs8SzU4Sf8OpstmhOsu1xO/YFtRx1bQAVSB0fkSPFicJ6fWg45kjr2qw1Ee7JJ7asnFQtn80Hsgra7BPMh1ezSzwy3fm7/Bg5mH5hZGLSgxAL14BPB9VDmkaWEYaKi4B8UDMBcpvxUacHf49k8BJtCbPFzKUZD4ZJ72U4K+Ob6pDZweUAYscSdd7B7bJ3nSJKw+7c29vXvGpC6G4lUbVg2/tEa6lmZtFfv6dQPyLrpZ+TT+RS3jPY7inZ971vWylKkzcdjD1tEdU6PmTEuBqEPlzGmEA== 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=AThi17NNP30bYZn7dBEn4+QKseBYapvJVQghBuEpByI=; b=N0AyOc77uicEWxtfUVPR4t+5LRhFLdsslHrrtKP/ONBJ35bL6dH5x9KHDZN1u+L0GV6s5fyLzGs/jVKfidMJMQYtx7iEuqkcS6qPQmHjen4J98AxR7RWM8+AavScaiB4uWL00P0dTdZotSWrqRKsHzpG720HErxjYSWAje/5Dw+XZdWdg5BDVM1Et/KUnqPvFSLG4vxKi4ejB7FtxG6L19b9LW+SOwj4jdmcmIla1gHsZE/oCQxNgJJWbr9CjYmcHpmX+YvPkggEL6UBQdY7At3eZpCtHfxprTfrHP0GQPIlyJvju2mHdwuaPXpkZWJI4EP1xggsDxmINNWBrjJu1A== 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=AThi17NNP30bYZn7dBEn4+QKseBYapvJVQghBuEpByI=; b=rpEoa/uL6QGXAhEI5volr3xJ5JkOpDgx16K57rIP71MwXcjYmwtQqA85TXN730kbiLrSwiyZdZJjSdzjYpSPeZvs2GCg4Woe/IxmADB/4/f95jTlVwDDccp5bL17SiWLnScaiJUEpP52RhpI4qL2Lnxw6k7W0OqTrbHB9SLQW/g= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (52.133.6.18) by HE1PR0702MB3641.eurprd07.prod.outlook.com (10.167.127.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.11; Wed, 11 Mar 2020 13:58:17 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::e49e:708f:4fe7:5d02]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::e49e:708f:4fe7:5d02%4]) with mapi id 15.20.2814.007; Wed, 11 Mar 2020 13:58:17 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: Interim today Thread-Index: AQHV960dO29+Oi8k1kO/H0bJnPOC/A== Date: Wed, 11 Mar 2020 13:58:16 +0000 Message-ID: <8D3CECED-24C6-4CE6-927C-C8184DFA70C2@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 61ef4967-256d-4a7e-c746-08d7c5c43fcf x-ms-traffictypediagnostic: HE1PR0702MB3641: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0339F89554 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(136003)(39860400002)(366004)(346002)(199004)(91956017)(6512007)(19627405001)(478600001)(186003)(64756008)(81156014)(6486002)(66556008)(66946007)(2906002)(8676002)(66476007)(8936002)(66446008)(6916009)(66616009)(45080400002)(7116003)(81166006)(76116006)(26005)(86362001)(6506007)(36756003)(44832011)(2616005)(966005)(3480700007)(316002)(5660300002)(33656002)(16799955002)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3641; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; 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: hP+Wl8Da/MS7XJ9PV0oHelCnX5MLfU6PDNSn281EErXqnF9tPzymjwNeent+KRZkUo4WbzcPTzFqB999kCLN/qGRdZ8HRD+qRuz+U7UAp1c0Gq+TH23JNvi5VF/2036X0Hx70Z2v3c27AlGb+w9iOmyP05YoaNd3aNGZljCFRsmUkfKDLo1NxWv0pzhmMRx7dftaOwTxepg/vTLDzpcNmfh1DFzVHFQ8XaNGITZZgk1+plL84ydiNDdToA0TO2zohTVrG68ckEQDuMjPbUmPX3fYH+EOm4K06IyJXzP1brYH5RoNtm6SUswJyTpm3DRiYb6GRrVTVydwxtnmpA5CCFMZhPKIzpHYqJpcKVAPkmuMDFrA4L+MzVkKYx944vtXLXr7xpu4Gn/FWK16hxf+3FQBUNcj/0qMobuzy1xu903KMSyIu+fBMoYeU1qVzm/sje8bgOR7GkdZ/3/Qld5h7ABxegqhPwypxh4Y9KT1lCILEzT7yj1hYs1OxlqPf9ZThkolcvuaVYCHWzc/NovHRA== x-ms-exchange-antispam-messagedata: strxWm9XoO7RAn5Y9ZZP2vw4k1LTBU5lQphSO5zCa0TXN08I3osYg9ArwQEzkTALdH7HrSKhWYWZ5NVvFlh3ZkEQaXa7oRCMiEb8j8pK5N0cRthoxCKdGtHamPCVfx+dyR8qzT5cJsmMLYveLokkRA== x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_004_8D3CECED24C64CE6927CC8184DFA70C2ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 61ef4967-256d-4a7e-c746-08d7c5c43fcf X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2020 13:58:16.9768 (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: ZBWliXS5yKkZEY007/Ny8CdDGUM7UdNkc+5cJ9WW0JndKnNxYwG+Ou2ZKD/V+jWB76NG7asmUFYmpIip+KMjUaghV7use93201/wQwHpA6qeZyPpHNSkynVZIxA0r70W X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3641 Archived-At: Subject: [Cbor] Interim today 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, 11 Mar 2020 13:58:22 -0000 --_004_8D3CECED24C64CE6927CC8184DFA70C2ericssoncom_ Content-Type: multipart/alternative; boundary="_000_8D3CECED24C64CE6927CC8184DFA70C2ericssoncom_" --_000_8D3CECED24C64CE6927CC8184DFA70C2ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpSZW1pbmRlciB0aGF0IHdlIGhhdmUgb3VyIG1lZXRpbmcgaW4gYXJvdW5kIDIg aG91cnMsIDE2OjAwIFVUQy4NCg0KQWdlbmRhIGhhcyBiZWVuIHBvc3RlZDogaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAyMC1jYm9yLTA1L21hdGVyaWFscy9h Z2VuZGEtaW50ZXJpbS0yMDIwLWNib3ItMDUtY2Jvci0wMS50eHQNCldlIHdpbGwgZGlzY3VzcyBD Qk9SIEJpcyBXR0xDIHRoYXQgaGFzIHN0YXJ0ZWQsICBhbmQgYW55IG90aGVyIG9wZW4gYnVzaW5l c3MuDQoNCkZyYW5jZXNjYQ0KDQpGcm9tOiBDQk9SIFdvcmtpbmcgR3JvdXAgPG1lc3NlbmdlckB3 ZWJleC5jb20+DQpSZXBseSB0bzogImNib3ItY2hhaXJzQGlldGYub3JnIiA8Y2Jvci1jaGFpcnNA aWV0Zi5vcmc+DQpEYXRlOiBXZWRuZXNkYXksIDI5IEphbnVhcnkgMjAyMCBhdCAyMTo1NQ0KVG86 ICJjYm9yLWNoYWlyc0BpZXRmLm9yZyIgPGNib3ItY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDog KEZvcndhcmQgdG8gb3RoZXJzKSBXZWJleCBtZWV0aW5nIGludml0YXRpb246IENCT1Igd29ya2lu ZyBncm91cCBjb25mZXJlbmNlIGNhbGwNClJlc2VudCBmcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRm Lm9yZz4NClJlc2VudCB0bzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4sIEZy YW5jZXNjYSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tPg0KUmVz ZW50IGRhdGU6IFdlZG5lc2RheSwgMjkgSmFudWFyeSAyMDIwIGF0IDIxOjU0DQoNCg0KWW91IGNh biBmb3J3YXJkIHRoaXMgaW52aXRhdGlvbiB0byBvdGhlcnMuDQoNCkNCT1IgV29ya2luZyBHcm91 cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViZXggbWVldGluZy4NCg0KDQoNCk1lZXRpbmcg bnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0NCA0ODIgMjgyDQoNCk1lZXRpbmcgcGFzc3dvcmQ6IDhr M1hqUGFiDQoNCg0KDQpPY2N1cnMgZXZlcnkgMiB3ZWVrKHMpIG9uIFdlZG5lc2RheSBlZmZlY3Rp dmUgV2VkbmVzZGF5LCBGZWJydWFyeSAxMiwgMjAyMCB1bnRpbCBXZWRuZXNkYXksIE1hcmNoIDEx LCAyMDIwIGZyb20gNDowMCBQTSB0byA1OjAwIFBNLCAoVVRDKzAwOjAwKSBNb25yb3ZpYSwgUmV5 a2phdmlrDQo0OjAwIHBtICB8ICAoVVRDKzAwOjAwKSBNb25yb3ZpYSwgUmV5a2phdmlrICB8ICAx IGhyDQoNCg0KDQpKb2luIG1lZXRpbmc8aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhw P01USUQ9bWVhMzJlMTIyYzFlYTYyMmJlY2IwOWE4Y2UxYTU2Y2FlPg0KDQoNCg0KSm9pbiBieSBw aG9uZQ0KVGFwIHRvIGNhbGwgaW4gZnJvbSBhIG1vYmlsZSBkZXZpY2UgKGF0dGVuZGVlcyBvbmx5 KQ0KMS02NTAtNDc5LTMyMDg8dGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQ0NDgyMjgyJTIz JTIzKjAxKj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKQ0KDQoNCg0KSm9pbiBmcm9t IGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxpY2F0aW9uDQpEaWFsIDY0NDQ4MjI4MkBpZXRmLndlYmV4 LmNvbTwlMjBzaXA6NjQ0NDgyMjgyQGlldGYud2ViZXguY29tPg0KWW91IGNhbiBhbHNvIGRpYWwg MTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLg0KDQoNCg0KSm9pbiB1 c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzDQpEaWFs IDY0NDQ4MjI4Mi5pZXRmQGx5bmMud2ViZXguY29tPCUyMHNpcDo2NDQ0ODIyODIuaWV0ZkBseW5j LndlYmV4LmNvbT4NCg0KTmVlZCBoZWxwPyBHbyB0byBodHRwOi8vaGVscC53ZWJleC5jb20NCg0K DQo= --_000_8D3CECED24C64CE6927CC8184DFA70C2ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <68018907693DCE44B2E57762EC9D2DFC@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMzMz MzMzOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMzMzMzMzIiB2bGlu az0iIzMzMzMzMyI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBhbGwsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPlJlbWluZGVyIHRoYXQgd2UgaGF2ZSBvdXIgbWVldGluZyBpbiBhcm91bmQgMiBob3Vycywg MTY6MDAgVVRDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5BZ2VuZGEgaGFzIGJlZW4gcG9zdGVkOg0KPC9zcGFuPjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMjAtY2Jvci0w NS9tYXRlcmlhbHMvYWdlbmRhLWludGVyaW0tMjAyMC1jYm9yLTA1LWNib3ItMDEudHh0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvaW50ZXJpbS0y MDIwLWNib3ItMDUvbWF0ZXJpYWxzL2FnZW5kYS1pbnRlcmltLTIwMjAtY2Jvci0wNS1jYm9yLTAx LnR4dDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldlIHdpbGwgZGlzY3VzcyBDQk9S IEJpcyBXR0xDIHRoYXQgaGFzIHN0YXJ0ZWQsICZuYnNwO2FuZCBhbnkgb3RoZXIgb3BlbiBidXNp bmVzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+RnJhbmNlc2NhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkNCT1IgV29ya2luZyBHcm91cCAmbHQ7 bWVzc2VuZ2VyQHdlYmV4LmNvbSZndDs8YnI+DQo8Yj5SZXBseSB0bzogPC9iPiZxdW90O2Nib3It Y2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtjYm9yLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8 Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCAyOSBKYW51YXJ5IDIwMjAgYXQgMjE6NTU8YnI+DQo8Yj5U bzogPC9iPiZxdW90O2Nib3ItY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtjYm9yLWNoYWlyc0Bp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+KEZvcndhcmQgdG8gb3RoZXJzKSBXZWJl eCBtZWV0aW5nIGludml0YXRpb246IENCT1Igd29ya2luZyBncm91cCBjb25mZXJlbmNlIGNhbGw8 YnI+DQo8Yj5SZXNlbnQgZnJvbTogPC9iPiZsdDthbGlhcy1ib3VuY2VzQGlldGYub3JnJmd0Ozxi cj4NCjxiPlJlc2VudCB0bzogPC9iPkppbSBTY2hhYWQgJmx0O2lldGZAYXVndXN0Y2VsbGFycy5j b20mZ3Q7LCBGcmFuY2VzY2EgUGFsb21iaW5pICZsdDtmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNz c29uLmNvbSZndDs8YnI+DQo8Yj5SZXNlbnQgZGF0ZTogPC9iPldlZG5lc2RheSwgMjkgSmFudWFy eSAyMDIwIGF0IDIxOjU0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0i MCIgY2VsbHBhZGRpbmc9IjAiIGFsaWduPSJsZWZ0IiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRo OjEwMC4wJTtiYWNrZ3JvdW5kOndoaXRlIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjIx LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoyMS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjVwdDttc28tZWxl bWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdy YXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1l bnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDE1LjBwdCAwY20gMTUu MHB0Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRp bmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4N Cjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjVwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVu dC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50 LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6 Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMz MzMzMyI+WW91IGNhbiBmb3J3YXJkIHRoaXMgaW52aXRhdGlvbiB0byBvdGhlcnMuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjVwdDttc28tZWxlbWVudDpmcmFt ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzMzMzMzMyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNs YXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+ DQo8dHIgc3R5bGU9ImhlaWdodDoxNi41cHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20g MGNtIDBjbTtoZWlnaHQ6MTYuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxNi41cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNl OjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGlj YWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5DQk9SIFdv cmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYmV4IG1lZXRpbmcuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy41cHQ7bXNvLWVsZW1l bnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFw OmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50 LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0K PHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzow Y20gMGNtIDBjbSAwY207aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1l LWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9y LXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47 bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3Rh YmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjVwdDttc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50 LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVs ZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0i MCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY207d2lkdGg6YXV0byFpbXBvcnRhbnQiPg0KPHRi b2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTYuNXB0O21zby1lbGVtZW50OmZyYW1l O21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7 bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3It aG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQ0IDQ4MiAyODIN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuNXB0O21zby1lbGVt ZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3Jh cDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVu dC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbTt3aWR0aDphdXRvIWltcG9ydGFudCI+DQo8dGJvZHk+ DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNi41cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5NZWV0aW5nIHBhc3N3b3JkOiA4azNYalBhYjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuNXB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50 LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQt YW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpj b2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMz MzMzIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1h bFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0i aGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdo dDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1l bGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7 bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFj dGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy41cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVs ZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxl bWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9u dGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMzMzMzMzMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNv Tm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHls ZT0id2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20g MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE2 LjVwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21z by1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3Jh cGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpl eGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+T2NjdXJzIGV2ZXJ5IDIgd2Vl ayhzKSBvbiBXZWRuZXNkYXkgZWZmZWN0aXZlIFdlZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMjAg dW50aWwgV2VkbmVzZGF5LCBNYXJjaCAxMSwgMjAyMCBmcm9tIDQ6MDAgUE0gdG8gNTowMCBQTSwg KFVUQyYjNDM7MDA6MDApIE1vbnJvdmlhLCBSZXlramF2aWsNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTYuNXB0O21zby1l bGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQt d3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxl bWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij40OjAwIHBtJm5ic3A7Jm5ic3A7fCZuYnNwOyZu YnNwOyhVVEMmIzQzOzAwOjAwKSBNb25yb3ZpYSwgUmV5a2phdmlrJm5ic3A7Jm5ic3A7fCZuYnNw OyZuYnNwOzEgaHINCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9k eT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMu NXB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNv LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4 YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxw YWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28t ZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1l bGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6 b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzMzMzMzMyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxMy41cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVw dDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFy YWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1 bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MGNtO3dpZHRoOmF1dG8haW1w b3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAw Y207d2lkdGg6YXV0byFpbXBvcnRhbnQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIg Ym9yZGVyPSIxIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHls ZT0id2lkdGg6MGNtO2JhY2tncm91bmQ6IzQzQTk0Mjtib3JkZXI6c29saWQgIzQzQTk0MiAxLjBw dDt3aWR0aDphdXRvIWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJvcmRl cjpub25lO3BhZGRpbmc6Ny41cHQgMjcuMHB0IDcuNXB0IDI3LjBwdDt3aWR0aDphdXRvIWltcG9y dGFudDtib3JkZXItcmFkaXVzOjIwcHg7bWluLXdpZHRoOjE2MHB4IWltcG9ydGFudCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7 bGluZS1oZWlnaHQ6MTMuNXB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhz cGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZl cnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNv LWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj48YSBo cmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tZWEzMmUxMjJjMWVh NjIyYmVjYjA5YThjZTFhNTZjYWUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2NvbG9y OndoaXRlO3RleHQtZGVjb3JhdGlvbjpub25lIj5Kb2luIG1lZXRpbmc8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3Rk Pg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjEzLjVwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1o c3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12 ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21z by1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMztkaXNw bGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNv Tm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyIHN0 eWxlPSJoZWlnaHQ6MzYuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207 aGVpZ2h0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MzYuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjVwdDttc28tZWxlbWVudDpmcmFtZTtt c28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21z by1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhv cml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzMzMzMzMztkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi Pg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTguMHB0O21zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDph cm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1h bmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Kb2luIGJ5IHBob25lPG86cD48L286cD48L3NwYW4+PC9i PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTguMHB0O21z by1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1l bnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28t ZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHki Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTk5OTkiPlRhcCB0byBjYWxsIGluIGZyb20gYSBtb2Jp bGUgZGV2aWNlIChhdHRlbmRlZXMgb25seSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K PC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE4LjBwdDttc28tZWxlbWVudDpmcmFt ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzMzMzMzMyI+PGEgaHJlZj0idGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQ0 NDgyMjgyJTIzJTIzKjAxKiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFGRjk7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPjEtNjUwLTQ3OS0zMjA4PC9zcGFuPjwvYT4mbmJzcDtDYWxsLWluIHRvbGwgbnVt YmVyIChVUy9DYW5hZGEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+ DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPC90cj4NCjwvdGJv ZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEz LjVwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21z by1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3Jh cGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpl eGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMztkaXNwbGF5Om5vbmUiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJv cmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0ciBz dHlsZT0iaGVpZ2h0OjIxLjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNt O2hlaWdodDoyMS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjIxLjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0 O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs ZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy41cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7 bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDtt c28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1o b3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMzMzMzMzM7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIw Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE4LjBwdDttc28tZWxlbWVu dDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxp Y2F0aW9uPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRk IHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTguMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZy YW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5j aG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1 bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMz Ij5EaWFsIDxhIGhyZWY9IiUyMHNpcDo2NDQ0ODIyODJAaWV0Zi53ZWJleC5jb20iPg0KPHNwYW4g c3R5bGU9ImNvbG9yOiMwMEFGRjk7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjY0NDQ4MjI4MkBpZXRm LndlYmV4LmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+ DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxOC4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMzMzMzMzMiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91 ciBtZWV0aW5nIG51bWJlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwv dGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjEzLjVwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0 O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs ZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMztkaXNwbGF5Om5vbmUiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUi IGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6 MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjE1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1l bGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQt d3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxl bWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjVwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1m cmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFu Y2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29s dW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMz MztkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFz cz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5n PSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE4LjBwdDttc28tZWxl bWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdy YXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1l bnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Sm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBN aWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwv dGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTguMHB0O21zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDph cm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1h bmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMzMzMzMzIj5EaWFsIDxhIGhyZWY9IiUyMHNpcDo2NDQ0ODIyODIuaWV0 ZkBseW5jLndlYmV4LmNvbSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRlY29y YXRpb246bm9uZSI+NjQ0NDgyMjgyLmlldGZAbHluYy53ZWJleC5jb208L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBhbGln bj0ibGVmdCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRy IHN0eWxlPSJoZWlnaHQ6NTQuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAw Y207aGVpZ2h0OjU0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTMuNXB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1 cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBh cmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1y dWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjBwdCI+ DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxOC4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE4LjBwdDttc28tZWxlbWVudDpm cmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJv dW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5j aG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPk5lZWQgaGVscD8gR28gdG8NCjxhIGhyZWY9Imh0dHA6Ly9oZWxw LndlYmV4LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwNDlGRDk7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvc3Bhbj48L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjMzLjBwdCI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDozMy4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjVwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzMzMzMzMyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8D3CECED24C64CE6927CC8184DFA70C2ericssoncom_-- --_004_8D3CECED24C64CE6927CC8184DFA70C2ericssoncom_ Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Description: Webex_Meeting.ics Content-Disposition: attachment; filename="Webex_Meeting.ics"; size=6577; creation-date="Wed, 11 Mar 2020 13:58:16 GMT"; modification-date="Wed, 11 Mar 2020 13:58:16 GMT" Content-ID: <67213E2D2CFA5E4CB78BB1AC8B03558F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL1JleWtqYXZpaw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96 b25laW5mby1vdXRsb29rL0F0bGFudGljL1JleWtqYXZpaw0KWC1MSUMtTE9DQVRJT046QXRsYW50 aWMvUmV5a2phdmlrDQpCRUdJTjpTVEFOREFSRA0KVFpPRkZTRVRGUk9NOiswMDAwDQpUWk9GRlNF VFRPOiswMDAwDQpUWk5BTUU6R01UDQpEVFNUQVJUOjE5NzAwMTAxVDAwMDAwMA0KRU5EOlNUQU5E QVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMDAxMjlUMjA1NDQ1 Wg0KQVRURU5ERUU7Q049IkNCT1IgV29ya2luZyBHcm91cCI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7 UlNWUD1UUlVFOk1BSUxUTzpjYm9yLWNoYWlyc0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJDQk9S IFdvcmtpbmcgR3JvdXAiOk1BSUxUTzpjYm9yLWNoYWlyc0BpZXRmLm9yZw0KRFRTVEFSVDtUWklE PUF0bGFudGljL1JleWtqYXZpazoyMDIwMDIxMlQxNjAwMDANCkRURU5EO1RaSUQ9QXRsYW50aWMv UmV5a2phdmlrOjIwMjAwMjEyVDE3MDAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmDQpUUkFOU1A6T1BBUVVFDQpTRVFVRU5DRToxNTgwMzMxMjg1DQpVSUQ6MDdmMjBjYmEt MWJlYy00ZGIwLWJlZDItMGMxNmQyYTY5MjU5DQpERVNDUklQVElPTjpcblxuXG5cbkpPSU4gV0VC RVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWVhMzJl MTIyYzFlYTYyMmJlY2IwOWE4Y2UxYTU2Y2FlXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUp OiA2NDQgNDgyIDI4MlxuXG5cbk1lZXRpbmcgcGFzc3dvcmQ6IDhrM1hqUGFiXG5cblxuXG5KT0lO IEJZIFBIT05FXG4xLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEp XG5UYXAgaGVyZSB0byBjYWxsIChtb2JpbGUgcGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0 ZWQpOiB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDQ0ODIyODIlMjMlMjMqMDEqXG5cblxu XG5KT0lOIEZST00gQSBWSURFTyBTWVNURU0gT1IgQVBQTElDQVRJT05cbkRpYWwgc2lwOjY0NDQ4 MjI4MkBpZXRmLndlYmV4LmNvbVxuWW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBl bnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMg b3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzc1xuRGlhbCBzaXA6NjQ0NDgyMjgyLmlldGZA bHluYy53ZWJleC5jb21cblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2Nv bGxhYm9yYXRpb25oZWxwLmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9S VEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBh dWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUg cmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5 IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2gg cmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNj dXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lv bi5cbg0KWC1BTFQtREVTQztGTVRUWVBFPXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3Mi PlxuKiB7XG4gICAgcGFkZGluZzogMDsgICAgbWFyZ2luOiAwO31cbnRhYmxlIHtcbglib3JkZXIt Y29sbGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2lu ZzogMDt9XG5cbnRyIHtcbglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRkIHtcbglmb250LXNp emU6IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQtd3JhcDogYnJl YWstd29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxuLnRpdGxlIHtcbglm b250LXNpemU6IDI4cHg7fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwltYXgtd2lkdGg6IGF1 dG87fVxuXG4uZm9vdGVyIHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7XG5cbn1AbWVkaWEg c2NyZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0bGUge1xuCQlmb250 LXNpemU6IDIycHggIWltcG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRoOiBhdXRvICFpbXBv cnRhbnQ7CQltYXgtd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290ZXIge1xuCQl3aWR0 aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxuCS5t YWluIHtcbgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9y dGFudFxuCX1cbn1cbjwvc3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0i cGFkZGluZzogMDsgbWFyZ2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249Imxl ZnQiPlxuCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCTx0 cj5cbgkJPHRkIGFsaWduPSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAi PlxuCQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7IHdp ZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBhbGln bj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFsaWduPSJjZW50ZXIi IHZhbGlnbj0idG9wIiA+Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPi0t PlxuXG5cblxuXG5cbgkJCTx0YWJsZT5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05U IFNJWkU9IjQiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+V2hlbiBpdCdzIHRpbWUsIGpv aW4gdGhlIFdlYmV4IG1lZXRpbmcgaGVyZS48L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5c bgkJCQk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBw eCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0la RT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNz IGNvZGUpOiA2NDQgNDgyIDI4MjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90 YWJsZT5cbgkJCVxuCQkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBT SVpFPSIyIiAgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj44azNYalBhYjwvRk9OVD48L3Rk PjwvdHI+PC90YWJsZT5cblxuICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9Imxp bmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3Ry PlxuCQkJPHRyPlxuCQkJCTx0ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4JCQkJ CTx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5bGU9 IndpZHRoOmF1dG87d2lkdGg6YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNBOTQy OyBib3JkZXI6MHB4IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdpZHRo OjE2MHB4IWltcG9ydGFudDsiPlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2VudGVy IiBzdHlsZT0icGFkZGluZzoxMHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYvai5waHA/TVRJRD1tZWEzMmUxMjJjMWVhNjIyYmVjYjA5YThjZTFhNTZjYWUiIHN0 eWxlPSJjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7 Ij5Kb2luIG1lZXRpbmc8L2E+PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4JCQkJ PC90ZD5cbgkJCTwvdHI+XG4JCTwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZG MDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9IjEi IEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxCUj48 Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9 IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PGI+PGEgaHJlZj0ndGVsOiUyQjEtNjUw LTQ3OS0zMjA4LCwqMDEqNjQ0NDgyMjgyJTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7 ICB0ZXh0LWRlY29yYXRpb246bm9uZTsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRw eDtsaW5lLWhlaWdodDogMjRweDsnPjEtNjUwLTQ3OS0zMjA4PC9hPjwvYj4gQ2FsbC1pbiB0b2xs IG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xP Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48QlI+XG5cbjx0 YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBw eCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFM Ij48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gZnJvbSBh IHZpZGVvIHN5c3RlbSBvciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQgU0laRT0iMiIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVmPSJzaXA6NjQ0NDgy MjgyQGlldGYud2ViZXguY29tIj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0i YXJpYWwiPjY0NDQ4MjI4MkBpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9O VCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4gYWxzbyBkaWFs IDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNw OyA8QlI+PC9GT05UPiZuYnNwOyA8QlI+XG5cbjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjAiPjx0cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFy aWFsO2ZvbnQtc2l6ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4 OyI+PGI+Sm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1 c2luZXNzPC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29s b3I6ICMzMzMzMzM7IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhl aWdodDogMjRweDsiPkRpYWwgPGEgaHJlZj0iIHNpcDo2NDQ0ODIyODIuaWV0ZkBseW5jLndlYmV4 LmNvbSIgICBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOSI+NjQ0NDgy MjgyLmlldGZAbHluYy53ZWJleC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+XG5cbgkJCTx0YWJs ZSBzdHlsZT0id2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuICAgICAg ICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxu CQkJCTx0cj5cbgkJCQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7IGNvbG9yOiAjMDAwMDAwOyBm b250LWZhbWlseTpBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPk5l ZWQgaGVscD8gR28gdG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2ViZXguY29tIiBzdHlsZT0iY29s b3I6IzA0OUZEOTsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRwOi8vaGVscC53ZWJleC5jb208 L2E+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9Imhl aWdodDogNDRweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwvdGFibGU+XG4JCTwvdGQ+XG4J PC90cj5cbjwvdGFibGU+XG4NClNVTU1BUlk6Q0JPUiB3b3JraW5nIGdyb3VwIGNvbmZlcmVuY2Ug Y2FsbA0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElDDQpSUlVMRTpGUkVRPVdFRUtMWTtXS1NUPVNV O0NPVU5UPTM7SU5URVJWQUw9MjtCWURBWT1XRQ0KQkVHSU46VkFMQVJNDQpUUklHR0VSOi1QVDVN DQpBQ1RJT046RElTUExBWQ0KREVTQ1JJUFRJT046UmVtaW5kZXINCkVORDpWQUxBUk0NCkVORDpW RVZFTlQNCkVORDpWQ0FMRU5EQVINCg== --_004_8D3CECED24C64CE6927CC8184DFA70C2ericssoncom_-- From nobody Wed Mar 11 08:10:59 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 88FCA3A088A for ; Wed, 11 Mar 2020 08:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ep2ze681hzKX for ; Wed, 11 Mar 2020 08:10:48 -0700 (PDT) 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 040833A08A8 for ; Wed, 11 Mar 2020 08:10:47 -0700 (PDT) Received: from [172.16.42.113] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48cwPx6Dm3zyNv; Wed, 11 Mar 2020 16:10:45 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <8D3CECED-24C6-4CE6-927C-C8184DFA70C2@ericsson.com> Date: Wed, 11 Mar 2020 16:10:45 +0100 Cc: "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 605632245.242274-f3bca731681979a0adfb89defe6c56f6 Content-Transfer-Encoding: quoted-printable Message-Id: <7B41A92B-9463-435B-AC9C-3D7550FD49DF@tzi.org> References: <8D3CECED-24C6-4CE6-927C-C8184DFA70C2@ericsson.com> To: Francesca Palombini X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Cbor] Interim today 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, 11 Mar 2020 15:10:51 -0000 Hi Francesca, On 2020-03-11, at 14:58, Francesca Palombini = wrote: >=20 > We will discuss CBOR Bis WGLC that has started, and any other open = business. I think we should talk about tags briefly, in particular Joerg=E2=80=99s = complaint. He is of course right in saying that we didn=E2=80=99t handle his input = very well (which I can say because it=E2=80=99s all my fault). We need = a timely decision now what do to about dates, so they can go into the = driving license standard. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 11 08:25:27 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 E51F13A09C1 for ; Wed, 11 Mar 2020 08:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1YRaHgJfisqq for ; Wed, 11 Mar 2020 08:25:13 -0700 (PDT) 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 7270C3A094F for ; Wed, 11 Mar 2020 08:25:13 -0700 (PDT) Received: from [172.16.42.113] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48cwkb4lFvz18m8; Wed, 11 Mar 2020 16:25:11 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <282209381d8b4a8b8e77515142266df2@pdv-FS.de> Date: Wed, 11 Mar 2020 16:25:11 +0100 Cc: Mike Jones , "cbor@ietf.org" , Anthony Nadalin X-Mao-Original-Outgoing-Id: 605633110.9209599-096bc4226b64c93069a01e67f62e80c9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <282209381d8b4a8b8e77515142266df2@pdv-FS.de> To: =?utf-8?B?IlJpY2h0ZXIsIErDtnJnIg==?= X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values 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, 11 Mar 2020 15:25:25 -0000 Hi Joerg, I=E2=80=99m sorry we didn=E2=80=99t handle your requests properly. Let=E2=80=99s try to fix this now. > On 2020-03-04, at 08:42, Richter, J=C3=B6rg = wrote: >=20 > Hi, >=20 >> The need for a date (not time) tag has come up before; I just can=E2=80= =99t remember where. >=20 > One year ago I sent a proposal f=C3=BCr a date tag [1]. > So far it has not made it into the overview of the assigned CBOR-tags = [2]. >=20 > I would very much appreciate if the suggested tag number is used for = the date-tag, since we already use it internally. What I like about Mike=E2=80=99s draft is that he references RFC 3339, = which already is an established specification for how to write dates = textually. For that half of the proposal, I don=E2=80=99t think there = is a technical difference with your proposal (except that Mike suggested = a different tag number). Beyond Mike=E2=80=99s draft, we would need to = decide that we like to use the same tag with an epoch-based numeric = date. I think this is OK; it just requires users of the tag to specify = which of the internal structures (or both) they would accept. Note that = we are running into the same issue with tag 1 (as used in EAT in the = RATS WG), so that may help accepting that this is a normal thing to so. > What is missing for the suggested tag numbers to be assigned? I think we just have to make the decision to spend the 1+1 (short) tag. That becomes somewhat easier with including the numeric date, because = that is indeed quite compact and merits a short tag. > Btw. I have another proposal for currencies and money amounts at [3] = whose tags were not assigned either. Let=E2=80=99s get to that, too, right after we are done with the date = tag. Gr=C3=BC=C3=9Fe, Carsten > - J=C3=B6rg >=20 > [1] https://j-richter.github.io/CBOR/date.html > [2] https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml > [3] https://j-richter.github.io/CBOR/currency.html >=20 From nobody Wed Mar 11 08:41:59 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 6634E3A0982 for ; Wed, 11 Mar 2020 08:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, 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 nm_LDOilFufq for ; Wed, 11 Mar 2020 08:41:56 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2051.outbound.protection.outlook.com [40.107.20.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 B14773A0A02 for ; Wed, 11 Mar 2020 08:41:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F926t5XkYDEZXxR3U2DfN48F9SLqUESgBOf1fz5A07hIxl2N1mv84JVZqcImYzCAfwbrNJxUO3WTAHBMHONdQQop2acgIgKaQjuCvENZFRPdDTlFooJkOG8pfihovU488AmkniZhWjO9+g7TuewKzQBkWZHHykOAJmULAkVO+8uccd5/ogQw2HzI817BJGM7eHA4W1CD9BvsCxtCBrLPmq+1c3s/1O2E2wkGvxluGl8JiACCwICjB/OjjuETsnSkikZCuXgGoqRGt9nLlOJVJ1hEW0yi2Z8ebSwBc+1cHMpLDoCWSy72VQDi27R6TLXvmZMdL0/OQQ6ZehYOdl2v9w== 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=uchI0G0knXaPiZ/djYht0fVwPsLD0UYKHol1x4kfP2A=; b=Q8wI65z56sD3w1ZE2v5fTNZMD40HZ7dz4oGeQd1GoHXwxMoZarkOWzgovsczMwxfVXcTYv+gSPfpl3gXuC1qKFCuyVOFvGIUrms9weM2b5JZ+V8JaI5PuWsZJwbq081DSHJjYRT+NhZBdsRJ57vYQpQsVCMl74sUnavizJYZuc8qd+Jnsp3uG+l8yhXyV9TImSrbxAYoesJ64Qu6nfvrXzEgz3jUl1KdzIMGuWmYb26Fyn1e8phneWWYV0OIns/NyCEianE0QLiAuMm/QNRdsyGj36bcUr07XdzrFR7i4I1p/K+X0dV8XYFYsLHH/TaFUsRYyQ6qoHfhJo8/6mHdPQ== 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=uchI0G0knXaPiZ/djYht0fVwPsLD0UYKHol1x4kfP2A=; b=Nvq7iRKZKZ/KJKV0R6980lqLdAwzgXNU4xkQNoOggqYUyr4wu9a43Ss3RZbz4OLEm3LqSguTqqAW2WyY8ZeiWKA3xqQe6kWBij3qmWxPbrQeFynlzhtkD+yVlag3VOY1Tz5wIuv0hK5dhUbFlY3DQKosHAbgRdQIcg/HgnAaHTk= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (52.133.6.18) by HE1PR0702MB3563.eurprd07.prod.outlook.com (10.167.124.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.9; Wed, 11 Mar 2020 15:41:51 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::e49e:708f:4fe7:5d02]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::e49e:708f:4fe7:5d02%4]) with mapi id 15.20.2814.007; Wed, 11 Mar 2020 15:41:51 +0000 From: Francesca Palombini To: Carsten Bormann , =?utf-8?B?UmljaHRlciwgSsO2cmc=?= , Mike Jones CC: "cbor@ietf.org" Thread-Topic: [Cbor] Interim today Thread-Index: AQHV960dO29+Oi8k1kO/H0bJnPOC/KhDfx+AgAAZcoA= Date: Wed, 11 Mar 2020 15:41:51 +0000 Message-ID: <02CA05AB-D19D-4BDE-9852-A905D83FF424@ericsson.com> References: <8D3CECED-24C6-4CE6-927C-C8184DFA70C2@ericsson.com> <7B41A92B-9463-435B-AC9C-3D7550FD49DF@tzi.org> In-Reply-To: <7B41A92B-9463-435B-AC9C-3D7550FD49DF@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 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: de0864e8-6a89-45d2-baae-08d7c5d2b7cc x-ms-traffictypediagnostic: HE1PR0702MB3563: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0339F89554 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(376002)(136003)(346002)(39860400002)(199004)(316002)(81166006)(33656002)(81156014)(6512007)(16799955002)(5660300002)(6486002)(8676002)(110136005)(2906002)(186003)(478600001)(44832011)(26005)(6506007)(966005)(8936002)(4326008)(71200400001)(2616005)(66476007)(66556008)(76116006)(66946007)(66446008)(53546011)(4744005)(64756008)(36756003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3563; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; 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: vvBH19ZdOO1fjjZLjabjMASZfNfCLZC0JxuviVrpoBzO5Jq/nCs7i83PQ1Mw9Oer0vZUeadDUuOQxBeEQ/FGjmir5L9YiC9/n6qchQ7BgJzyoJ9hy4ceeXY3Q7xExjh8KCS32cr/98ukCXaclVNeZXHH7Mzk2C329IDE4IdS1SziZb4I602FN9JizpIGT0POGV40BPq3PPzurpCfa37OBtADx/T5xMsxkdD9k3gViFkhugSPJpHY3ODjodCtbZwLVUo/erjQD87gsn1kyVfaTuIRhtjlsmH92jSJhrwVXETj5ev0DU047+idud/nIdNJbtfsvI2fnEjxQFnkcHQh03mpdjkommBxh3la7lXWVsgqkj9bKKGOXd6xjnZURvy4JsrjkPGiOKUfsQUXyNblCEaSPk7mwREh+swP2pjlqBsnXY04f5y7TAKNdxeeuJLXYq+V38ec8psbSuQmW/fuBkttk1fep013rqUrFGsPjeuKNIRG68/lS7EygY398Q154Qhf6E1f3qMEQOt35H8PtQ== x-ms-exchange-antispam-messagedata: fmsQsGyjIQslFY7V9mfa3qYTMlGyq7O4yeWVt5OQ5NU0YKqOrCkajyJC02t0HyRJxbXKSp2M8BlnilAg3+3v2xOxTiFX5biVyuLVPksx0IpjLjon2xKjcXhr1cjvKXRFIXK0sLMCRyCNMGJsSF09gQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: de0864e8-6a89-45d2-baae-08d7c5d2b7cc X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2020 15:41:51.1827 (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: o7HHaBySnb5v+UWMKTgnNAyTcQXNIpjCLb0LIsWg9l4mauDR7v+w+bn9U4NTxLIqRkJyDb6l4vmfiYySMMuKaipPyOgolD96UJiRkeasW5LZwAm8RnY7kj5VcZXzx68+ X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3563 Archived-At: Subject: Re: [Cbor] Interim today 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, 11 Mar 2020 15:41:58 -0000 WWVzLCBvZiBjb3Vyc2UuIEpvZXJnIGFuZCBNaWtlLCB5b3UgYXJlIHdlbGNvbWUgdG8gY2FsbCBp biBhcyB3ZWxsIGlmIHlvdSBjYW4gKG1lZXRpbmcgaW4gMjAgbWludXRlcyksIHVzaW5nIHRoZSB3 ZWJleCBsaW5rOiBodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tZWEzMmUx MjJjMWVhNjIyYmVjYjA5YThjZTFhNTZjYWUNCg0KRnJhbmNlc2NhDQoNCu+7v09uIDExLzAzLzIw MjAsIDE2OjExLCAiQ0JPUiBvbiBiZWhhbGYgb2YgQ2Fyc3RlbiBCb3JtYW5uIiA8Y2Jvci1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjYWJvQHR6aS5vcmc+IHdyb3RlOg0KDQogICAgSGkg RnJhbmNlc2NhLA0KICAgIA0KICAgIE9uIDIwMjAtMDMtMTEsIGF0IDE0OjU4LCBGcmFuY2VzY2Eg UGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYu b3JnPiB3cm90ZToNCiAgICA+IA0KICAgID4gV2Ugd2lsbCBkaXNjdXNzIENCT1IgQmlzIFdHTEMg dGhhdCBoYXMgc3RhcnRlZCwgIGFuZCBhbnkgb3RoZXIgb3BlbiBidXNpbmVzcy4NCiAgICANCiAg ICBJIHRoaW5rIHdlIHNob3VsZCB0YWxrIGFib3V0IHRhZ3MgYnJpZWZseSwgaW4gcGFydGljdWxh ciBKb2VyZ+KAmXMgY29tcGxhaW50Lg0KICAgIEhlIGlzIG9mIGNvdXJzZSByaWdodCBpbiBzYXlp bmcgdGhhdCB3ZSBkaWRu4oCZdCBoYW5kbGUgaGlzIGlucHV0IHZlcnkgd2VsbCAod2hpY2ggSSBj YW4gc2F5IGJlY2F1c2UgaXTigJlzIGFsbCBteSBmYXVsdCkuICBXZSBuZWVkIGEgdGltZWx5IGRl Y2lzaW9uIG5vdyB3aGF0IGRvIHRvIGFib3V0IGRhdGVzLCBzbyB0aGV5IGNhbiBnbyBpbnRvIHRo ZSBkcml2aW5nIGxpY2Vuc2Ugc3RhbmRhcmQuDQogICAgDQogICAgR3LDvMOfZSwgQ2Fyc3Rlbg0K ICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQogICAgQ0JPUiBtYWlsaW5nIGxpc3QNCiAgICBDQk9SQGlldGYub3JnDQogICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYm9yDQogICAgDQoNCg== From nobody Wed Mar 11 09:50:46 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 971233A0D8D for ; Wed, 11 Mar 2020 09:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y1ZKlIovyaGk for ; Wed, 11 Mar 2020 09:50:41 -0700 (PDT) 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 6014D3A0D8A for ; Wed, 11 Mar 2020 09:50:41 -0700 (PDT) Received: from [172.16.42.113] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48cydC2BrZzyRp; Wed, 11 Mar 2020 17:50:39 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: Date: Wed, 11 Mar 2020 17:50:38 +0100 Cc: "cbor@ietf.org" , Anthony Nadalin X-Mao-Original-Outgoing-Id: 605638238.7303801-e8adbe4f48305fa3463b687e5f145af0 Content-Transfer-Encoding: quoted-printable Message-Id: <5D27981B-81C8-43C0-A229-66343D9D67B4@tzi.org> References: <282209381d8b4a8b8e77515142266df2@pdv-FS.de> To: =?utf-8?B?IlJpY2h0ZXIsIErDtnJnIg==?= , Mike Jones X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values 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, 11 Mar 2020 16:50:45 -0000 Hi Joerg, Mike, we discussed the date tag proposals at the CBOR interim today. The meeting consensus was that we should merge the date tag part of = Joerg=E2=80=99s specification (i.e., both textual and numeric date = references) with Mike=E2=80=99s draft, and spend a 1+1 tag (which would = indeed conveniently be tag 100 =3D =E2=80=98d=E2=80=99). I would like to work with the two of you to generate a -01 of Mike=E2=80=99= s draft with text from Joerg, for discussion on May 25th (or whatever = replacement we find for the physical IETF107 meeting.) (We would look at time-of-day and timezone right after registering the = date tag from -01; maybe in a -02. My personal view would be that the = time-of-day tag from Joerg would go right in, but we might want to go = for a 1+2 tag for timezone [29818 for =E2=80=99tz=E2=80=99 maybe?]. But = let=E2=80=99s discuss this when we are there.) Is that a good way forward? Gr=C3=BC=C3=9Fe, Carsten > On 2020-03-11, at 16:25, Carsten Bormann wrote: >=20 > Hi Joerg, >=20 > I=E2=80=99m sorry we didn=E2=80=99t handle your requests properly. > Let=E2=80=99s try to fix this now. >=20 >> On 2020-03-04, at 08:42, Richter, J=C3=B6rg = wrote: >>=20 >> Hi, >>=20 >>> The need for a date (not time) tag has come up before; I just = can=E2=80=99t remember where. >>=20 >> One year ago I sent a proposal f=C3=BCr a date tag [1]. >> So far it has not made it into the overview of the assigned CBOR-tags = [2]. >>=20 >> I would very much appreciate if the suggested tag number is used for = the date-tag, since we already use it internally. >=20 > What I like about Mike=E2=80=99s draft is that he references RFC 3339, = which already is an established specification for how to write dates = textually. For that half of the proposal, I don=E2=80=99t think there = is a technical difference with your proposal (except that Mike suggested = a different tag number). Beyond Mike=E2=80=99s draft, we would need to = decide that we like to use the same tag with an epoch-based numeric = date. I think this is OK; it just requires users of the tag to specify = which of the internal structures (or both) they would accept. Note that = we are running into the same issue with tag 1 (as used in EAT in the = RATS WG), so that may help accepting that this is a normal thing to so. >=20 >> What is missing for the suggested tag numbers to be assigned? >=20 > I think we just have to make the decision to spend the 1+1 (short) = tag. > That becomes somewhat easier with including the numeric date, because = that is indeed quite compact and merits a short tag. >=20 >> Btw. I have another proposal for currencies and money amounts at [3] = whose tags were not assigned either. >=20 > Let=E2=80=99s get to that, too, right after we are done with the date = tag. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> - J=C3=B6rg >>=20 >> [1] https://j-richter.github.io/CBOR/date.html >> [2] https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml >> [3] https://j-richter.github.io/CBOR/currency.html >>=20 >=20 From nobody Wed Mar 11 09:57:50 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 838D53A0DAB for ; Wed, 11 Mar 2020 09:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 mpoX_ngOR25o for ; Wed, 11 Mar 2020 09:57:45 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-bl2nam06on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe55::729]) (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 680CC3A0D9D for ; Wed, 11 Mar 2020 09:57:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gpBPUU6bfcfe0q+0Y0R7fn+5El/yq2hYwiNHyWso7TBH+FCoNywnS0B2YWz3n5ped6qBmpQ5st5Lsq4pgUB1M1goIplsyNRKqSogkj01PGszfh8MsEkVpQ1xLGcsox/KyDBKDu9mVKZN5pfaDVfyrLMdH9ej7GsNvCE+iR2Lv2mtd4qvYdTCYqz40iDhO+WXcRdoJpTc1q4F11xdNIOxFJt4TgA9fuBQTfoymaNFtQCaH+qPn+Ct61Hpj8AtjGFmwEEzlN/WpCAUUgJL3ZHN/rpvnKkMb1nOV2H96aInrYMeKDdYZrxk5Z7ApqXboOU0oGOjgQUftZJNHYUgm1FBhA== 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=vmsGMHdkRv/rsb38bBPPvBT6alaQnuSW+50lltjTiRU=; b=QGIo7bNMm9q3MdF8xAYzvDmvl/AYnWuHsVYt4nkOYBtMqYVaGffEokp//8/CNoYT6f46WZGsyLKr5uE3nQNWCll+1BNHyrbKZAQNPkZRbKq+yOEH5wNZoKd1doKMJFMyBVCV5UCiIdxafrdvF7/abSsK1YlM1MkIB0lrJIrmvAaFoKi+FwCQmWrFE9We/mVdHTHV2K5E6eOeCYO2tjICQSdK2fPuKwgT0kUt0TWy8RBfTR6hwF0iGmcb2l0SK19YfNKXuUCnqz2pq63hju1MQvGfeU9plCtlLLCTIQxaDLU3Uowq/bWTe8OYhldVICZcOnjg1+SvlLMDrqx5ovBsMQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vmsGMHdkRv/rsb38bBPPvBT6alaQnuSW+50lltjTiRU=; b=KwO7H63JSyzLBt13/0Xfzz7nF6hrTdwN83OtC5mfh8/8FsnFIvGm1sDYHH7CNzeR8E0AuGA4tW7Ccb4zBTMQymRUhPtC1DezQSnNp7RY+upWLZRDeR/gPJNQmIQK/yegQcxEhdGinmhqg70/oPrLRz1XVjW5nL5qBQ33Zdw/CTQ= Received: from CH2PR00MB0678.namprd00.prod.outlook.com (20.180.6.215) by CH2PR00MB0794.namprd00.prod.outlook.com (10.186.139.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2854.0; Wed, 11 Mar 2020 16:57:06 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::f116:29ee:b1b2:a099]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::f116:29ee:b1b2:a099%9]) with mapi id 15.20.2850.000; Wed, 11 Mar 2020 16:57:06 +0000 From: Mike Jones To: Carsten Bormann , =?utf-8?B?IlJpY2h0ZXIsIErDtnJnIg==?= , Mike Jones CC: "cbor@ietf.org" , Anthony Nadalin Thread-Topic: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values Thread-Index: AQHV8fiNx9FAVJg+YEmb//E1cavkUqhDjpGAgAAX3wCAAADkkA== Date: Wed, 11 Mar 2020 16:57:06 +0000 Message-ID: References: <282209381d8b4a8b8e77515142266df2@pdv-FS.de> <5D27981B-81C8-43C0-A229-66343D9D67B4@tzi.org> In-Reply-To: <5D27981B-81C8-43C0-A229-66343D9D67B4@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=64358d5b-77e5-4188-b0bc-00007c79bfb0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-03-11T16:53:49Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.83.137] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 056b4a47-4b03-4171-5668-08d7c5dd3b29 x-ms-traffictypediagnostic: CH2PR00MB0794:|CH2PR00MB0794: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0339F89554 x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10019020)(4636009)(376002)(366004)(39860400002)(346002)(136003)(396003)(199004)(26005)(53546011)(6506007)(7696005)(33656002)(86362001)(55016002)(110136005)(8990500004)(54906003)(316002)(107886003)(4326008)(9686003)(186003)(76116006)(66446008)(64756008)(66556008)(66476007)(66946007)(2906002)(966005)(478600001)(10290500003)(71200400001)(5660300002)(8676002)(81156014)(81166006)(52536014)(8936002)(66574012); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0794; H:CH2PR00MB0678.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fC5yvBrozotk5bes8TcoCbb2DHCtvjTnrwxaRV3kM7+qtqSORGb46o0J39iZOjSk7EhdkadOIUwsocvXCR8QcVmFNMnie0tyRvUYpEKViCa+Y/qHzMKo8DTkcnWhXb17XYvV4oeRG1r9uAIuRkN1kDCmIQfahgM2ZlN6GtTYKO/UyJE+MGlJe5OJfLB92Ipcup03no5jdOhQ7Gcl+L4uWluexepJgh7qfVXXgxK36sGyxNIp9lnFdNI7BT0AQPzNp9tcwxM318HoqKd3QiVz+oPRCZnJ3C8QNd1VMWMg8K7q61rVhsmGWlDTvIeQxD6/THq6Oh4f0b738q5e/nKD9sCP2AlbxDVLDX09rfDVhirHpfd1v3DIIA7im5xY3++1YACFp1msogKR2I/ijSsESIrgV+xhUpZc0aITkQuCR557tJ3SaPl/QiVdqa+gcpaZGaE4tJvLP5v0bWTKDGABX5IN+pyZVx61v1hoCRAkHnEtwcLkLNjZT/1yB2IbWIPdJCGxszoiSHtGXneA4JMO3/bJKzFUiKsAwcQtOFhTuBCM2wpBSDDdZmPcxWgxjz+/a6m4evQDumDxe/4EFkSqZIzlM/M+XFJbDmlA7/TIjdpKkJ98A9UIfKaGPkmSY3xa x-ms-exchange-antispam-messagedata: G41YyypyDxLhCS2k3AqW54/GsFRmuePofEijkmb1eTxALAUR1LMhJKPvXNdjWZhbPehHel9sDSIFpwV0uqBU+3dEbn7Y3BtLElr+gjGY1KHRUYft60TFp5pXlJV8jhMSzRmUXBH8thuqQM/zYgbVJg== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 056b4a47-4b03-4171-5668-08d7c5dd3b29 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2020 16:57:06.5740 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gcASMIkawPApFbiv+p/IOePnCfG3z/beNyirLdLz8poQKLrnd67mlX9BHfwr/dwTKCzBcs8x2qHmF3lE3A174w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0794 Archived-At: Subject: Re: [Cbor] [EXTERNAL] Re: CBOR tag for RFC 3339 full-date values 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, 11 Mar 2020 16:57:48 -0000 SSdtIGZpbmUgbWVyZ2luZyBKw7ZyZydzIG51bWVyaWMgZGF0ZSB0YWcgaW50byBteSBkcmFmdCwg cHJvdmlkZWQgdGhhdCB0aGUgcmVzdWx0IGlzIG5vdCBhIHBvbHltb3JwaGljIHRhZywgaW4gd2hp Y2ggdGhlIHZhbHVlIGNvdWxkIGJlIGVpdGhlciBhIG51bWJlciBvciBhIHN0cmluZy4gIFdlIHNo b3VsZCBhbGxvY2F0ZSBzZXBhcmF0ZSB0YWdzIGZvciBzdHJpbmcgZGF0ZSBhbmQgbnVtZXJpYyBk YXRlLCBqdXN0IGFzIHRhZ3MgMCBhbmQgMSBhcmUgZGlmZmVyZW50LCBhbmQgbm90IHBvbHltb3Jw aGljLg0KDQpJZiB0aGlzIHdvcmtzIGZvciBldmVyeW9uZSwgSSdsbCBhZGQgdGhlIG51bWVyaWMg ZGF0ZSB0YWcgd2l0aCBwcm9wb3NlZCB2YWx1ZSAnZCcgaW50byBteSBkcmFmdC4NCg0KCQkJCS0t IE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENCT1IgPGNib3ItYm91 bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIENhcnN0ZW4gQm9ybWFubg0KU2VudDogV2VkbmVz ZGF5LCBNYXJjaCAxMSwgMjAyMCA5OjUxIEFNDQpUbzogIlJpY2h0ZXIsIErDtnJnIiA8Sm9lcmcu UmljaHRlckBwZHYtRlMuZGU+OyBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0 LmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBjYm9yQGlldGYub3JnOyBBbnRob255IE5hZGFsaW4g PHRvbnluYWRAbWljcm9zb2Z0LmNvbT4NClN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtDYm9yXSBD Qk9SIHRhZyBmb3IgUkZDIDMzMzkgZnVsbC1kYXRlIHZhbHVlcw0KDQpIaSBKb2VyZywgTWlrZSwN Cg0Kd2UgZGlzY3Vzc2VkIHRoZSBkYXRlIHRhZyBwcm9wb3NhbHMgYXQgdGhlIENCT1IgaW50ZXJp bSB0b2RheS4NClRoZSBtZWV0aW5nIGNvbnNlbnN1cyB3YXMgdGhhdCB3ZSBzaG91bGQgbWVyZ2Ug dGhlIGRhdGUgdGFnIHBhcnQgb2YgSm9lcmfigJlzIHNwZWNpZmljYXRpb24gKGkuZS4sIGJvdGgg dGV4dHVhbCBhbmQgbnVtZXJpYyBkYXRlIHJlZmVyZW5jZXMpIHdpdGggTWlrZeKAmXMgZHJhZnQs IGFuZCBzcGVuZCBhIDErMSB0YWcgKHdoaWNoIHdvdWxkIGluZGVlZCBjb252ZW5pZW50bHkgYmUg dGFnIDEwMCA9IOKAmGTigJkpLg0KDQpJIHdvdWxkIGxpa2UgdG8gd29yayB3aXRoIHRoZSB0d28g b2YgeW91IHRvIGdlbmVyYXRlIGEgLTAxIG9mIE1pa2XigJlzIGRyYWZ0IHdpdGggdGV4dCBmcm9t IEpvZXJnLCBmb3IgZGlzY3Vzc2lvbiBvbiBNYXkgMjV0aCAob3Igd2hhdGV2ZXIgcmVwbGFjZW1l bnQgd2UgZmluZCBmb3IgdGhlIHBoeXNpY2FsIElFVEYxMDcgbWVldGluZy4pDQoNCihXZSB3b3Vs ZCBsb29rIGF0IHRpbWUtb2YtZGF5IGFuZCB0aW1lem9uZSByaWdodCBhZnRlciByZWdpc3Rlcmlu ZyB0aGUgZGF0ZSB0YWcgZnJvbSAtMDE7IG1heWJlIGluIGEgLTAyLiAgTXkgcGVyc29uYWwgdmll dyB3b3VsZCBiZSB0aGF0IHRoZSB0aW1lLW9mLWRheSB0YWcgZnJvbSBKb2VyZyB3b3VsZCBnbyBy aWdodCBpbiwgYnV0IHdlIG1pZ2h0IHdhbnQgdG8gZ28gZm9yIGEgMSsyIHRhZyBmb3IgdGltZXpv bmUgWzI5ODE4IGZvciDigJl0euKAmSBtYXliZT9dLiAgQnV0IGxldOKAmXMgZGlzY3VzcyB0aGlz IHdoZW4gd2UgYXJlIHRoZXJlLikNCg0KSXMgdGhhdCBhIGdvb2Qgd2F5IGZvcndhcmQ/DQoNCkdy w7zDn2UsIENhcnN0ZW4NCg0KDQo+IE9uIDIwMjAtMDMtMTEsIGF0IDE2OjI1LCBDYXJzdGVuIEJv cm1hbm4gPGNhYm9AdHppLm9yZz4gd3JvdGU6DQo+IA0KPiBIaSBKb2VyZywNCj4gDQo+IEnigJlt IHNvcnJ5IHdlIGRpZG7igJl0IGhhbmRsZSB5b3VyIHJlcXVlc3RzIHByb3Blcmx5Lg0KPiBMZXTi gJlzIHRyeSB0byBmaXggdGhpcyBub3cuDQo+IA0KPj4gT24gMjAyMC0wMy0wNCwgYXQgMDg6NDIs IFJpY2h0ZXIsIErDtnJnIDxKb2VyZy5SaWNodGVyQHBkdi1GUy5kZT4gd3JvdGU6DQo+PiANCj4+ IEhpLA0KPj4gDQo+Pj4gVGhlIG5lZWQgZm9yIGEgZGF0ZSAobm90IHRpbWUpIHRhZyBoYXMgY29t ZSB1cCBiZWZvcmU7IEkganVzdCBjYW7igJl0IHJlbWVtYmVyIHdoZXJlLg0KPj4gDQo+PiBPbmUg eWVhciBhZ28gSSBzZW50IGEgcHJvcG9zYWwgZsO8ciBhIGRhdGUgdGFnIFsxXS4NCj4+IFNvIGZh ciBpdCBoYXMgbm90IG1hZGUgaXQgaW50byB0aGUgb3ZlcnZpZXcgb2YgdGhlIGFzc2lnbmVkIENC T1ItdGFncyBbMl0uDQo+PiANCj4+IEkgd291bGQgdmVyeSBtdWNoIGFwcHJlY2lhdGUgaWYgdGhl IHN1Z2dlc3RlZCB0YWcgbnVtYmVyIGlzIHVzZWQgZm9yIHRoZSBkYXRlLXRhZywgc2luY2Ugd2Ug YWxyZWFkeSB1c2UgaXQgaW50ZXJuYWxseS4NCj4gDQo+IFdoYXQgSSBsaWtlIGFib3V0IE1pa2Xi gJlzIGRyYWZ0IGlzIHRoYXQgaGUgcmVmZXJlbmNlcyBSRkMgMzMzOSwgd2hpY2ggYWxyZWFkeSBp cyBhbiBlc3RhYmxpc2hlZCBzcGVjaWZpY2F0aW9uIGZvciBob3cgdG8gd3JpdGUgZGF0ZXMgdGV4 dHVhbGx5LiAgRm9yIHRoYXQgaGFsZiBvZiB0aGUgcHJvcG9zYWwsIEkgZG9u4oCZdCB0aGluayB0 aGVyZSBpcyBhIHRlY2huaWNhbCBkaWZmZXJlbmNlIHdpdGggeW91ciBwcm9wb3NhbCAoZXhjZXB0 IHRoYXQgTWlrZSBzdWdnZXN0ZWQgYSBkaWZmZXJlbnQgdGFnIG51bWJlcikuICBCZXlvbmQgTWlr ZeKAmXMgZHJhZnQsIHdlIHdvdWxkIG5lZWQgdG8gZGVjaWRlIHRoYXQgd2UgbGlrZSB0byB1c2Ug dGhlIHNhbWUgdGFnIHdpdGggYW4gZXBvY2gtYmFzZWQgbnVtZXJpYyBkYXRlLiAgSSB0aGluayB0 aGlzIGlzIE9LOyBpdCBqdXN0IHJlcXVpcmVzIHVzZXJzIG9mIHRoZSB0YWcgdG8gc3BlY2lmeSB3 aGljaCBvZiB0aGUgaW50ZXJuYWwgc3RydWN0dXJlcyAob3IgYm90aCkgdGhleSB3b3VsZCBhY2Nl cHQuICBOb3RlIHRoYXQgd2UgYXJlIHJ1bm5pbmcgaW50byB0aGUgc2FtZSBpc3N1ZSB3aXRoIHRh ZyAxIChhcyB1c2VkIGluIEVBVCBpbiB0aGUgUkFUUyBXRyksIHNvIHRoYXQgbWF5IGhlbHAgYWNj ZXB0aW5nIHRoYXQgdGhpcyBpcyBhIG5vcm1hbCB0aGluZyB0byBzby4NCj4gDQo+PiBXaGF0IGlz IG1pc3NpbmcgZm9yIHRoZSBzdWdnZXN0ZWQgdGFnIG51bWJlcnMgdG8gYmUgYXNzaWduZWQ/DQo+ IA0KPiBJIHRoaW5rIHdlIGp1c3QgaGF2ZSB0byBtYWtlIHRoZSBkZWNpc2lvbiB0byBzcGVuZCB0 aGUgMSsxIChzaG9ydCkgdGFnLg0KPiBUaGF0IGJlY29tZXMgc29tZXdoYXQgZWFzaWVyIHdpdGgg aW5jbHVkaW5nIHRoZSBudW1lcmljIGRhdGUsIGJlY2F1c2UgdGhhdCBpcyBpbmRlZWQgcXVpdGUg Y29tcGFjdCBhbmQgbWVyaXRzIGEgc2hvcnQgdGFnLg0KPiANCj4+IEJ0dy4gSSBoYXZlIGFub3Ro ZXIgcHJvcG9zYWwgZm9yIGN1cnJlbmNpZXMgYW5kIG1vbmV5IGFtb3VudHMgYXQgWzNdIHdob3Nl IHRhZ3Mgd2VyZSBub3QgYXNzaWduZWQgZWl0aGVyLg0KPiANCj4gTGV04oCZcyBnZXQgdG8gdGhh dCwgdG9vLCByaWdodCBhZnRlciB3ZSBhcmUgZG9uZSB3aXRoIHRoZSBkYXRlIHRhZy4NCj4gDQo+ IEdyw7zDn2UsIENhcnN0ZW4NCj4gDQo+IA0KPj4gLSBKw7ZyZw0KPj4gDQo+PiBbMV0gaHR0cHM6 Ly9qLXJpY2h0ZXIuZ2l0aHViLmlvL0NCT1IvZGF0ZS5odG1sDQo+PiBbMl0gaHR0cHM6Ly93d3cu aWFuYS5vcmcvYXNzaWdubWVudHMvY2Jvci10YWdzL2Nib3ItdGFncy54aHRtbA0KPj4gWzNdIGh0 dHBzOi8vai1yaWNodGVyLmdpdGh1Yi5pby9DQk9SL2N1cnJlbmN5Lmh0bWwNCj4+IA0KPiANCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNCT1IgbWFp bGluZyBsaXN0DQpDQk9SQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Nib3INCg== From nobody Wed Mar 11 10:03:12 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 C8B953A0DBB for ; Wed, 11 Mar 2020 10:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rt0MTXKIyXl8 for ; Wed, 11 Mar 2020 10:03:07 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 104983A0DEB for ; Wed, 11 Mar 2020 10:03:05 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id n27so1838128vsa.0 for ; Wed, 11 Mar 2020 10:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Iz7pwt8pldEAFx4auP8CVbkRorGs+oYmbyojRGkJ+Ng=; b=Z/rgjSJOLL71+1M6SC0Lnu9aWbBOfg/uhkQ36CXte9oWY4BreQKO/5CEqX3sl4Dn1k eR2T0Avz8D7zYdIwbykkx21OPXhV60pMCeUoQ98sBkvdgK4UC8zdsj/O7ThA5YovoIN3 dkkqGhhFkARmpqIMQiA0nCViD8MLkpvyzcd0NVuo6CM5ZtkwTIxCGYt+6mpMBeWhzTOz PEKHAlruSiDHrQpiNzTP7jcTBxAMmX7O54v+zYJL0FMZWa18jrbzqL9vugaz3nPDcd5Y B0BsaK8IFlCxefFO603yUoeRPn4cu/L8ByWzstFbzi6gBYVroXQzE+MICTeflWP/y5Xl Sipg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Iz7pwt8pldEAFx4auP8CVbkRorGs+oYmbyojRGkJ+Ng=; b=PkGYJVIiSCFhFCkBy6WMykUKIL35uf/3C2+6GW8dpkSaHdXrLDsxTP5lDk9B0JMOJb GOLFlSiFsKB8mde5mQWCi03JdM5VYcv7M6+OSeUH7i4I3Lx6DITrmLugabiJvlyBgtIe Ax+v5XehTb8X5BicLLr+y1gEvpXYqdvNK80ERsWc+XTkCfsg1GS7YZL61RsAofDoDTt/ y0amqVJjEWkCwW6WvJCrsr0U8sfe9M8G+oAtIlKLeuECpD7ny32zMJgYuhX50X7LxdfX ThWdPsCcp70n07wnkTq0a8iTXriVo4GsFtlxSGTvQL6gVrNwFxgeEtaEgphoequJAskj 3daw== X-Gm-Message-State: ANhLgQ1JWTuLb47WfMTKgkChcm39XxtHdNb5F0/jbP2XClYv7c18NQsY QWyQkrFedwTHQY/BX4Xnex60c1Bfoy4FO0zpU44= X-Google-Smtp-Source: ADFU+vt4SbOpY52By8NondT7g5RBgAop3X9GkUMZ60gzyCj6BhpaYEihx+Eg5g/8H7zpObWzSJ6LY//TtxC3VRn/yBw= X-Received: by 2002:a67:fad8:: with SMTP id g24mr2726226vsq.136.1583946184947; Wed, 11 Mar 2020 10:03:04 -0700 (PDT) MIME-Version: 1.0 References: <8D3CECED-24C6-4CE6-927C-C8184DFA70C2@ericsson.com> <7B41A92B-9463-435B-AC9C-3D7550FD49DF@tzi.org> <02CA05AB-D19D-4BDE-9852-A905D83FF424@ericsson.com> In-Reply-To: <02CA05AB-D19D-4BDE-9852-A905D83FF424@ericsson.com> From: Ira McDonald Date: Wed, 11 Mar 2020 13:02:51 -0400 Message-ID: To: Francesca Palombini , Ira McDonald Cc: Carsten Bormann , =?UTF-8?B?UmljaHRlciwgSsO2cmc=?= , Mike Jones , "cbor@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b27b7105a097359d" Archived-At: Subject: Re: [Cbor] Interim today 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, 11 Mar 2020 17:03:11 -0000 --000000000000b27b7105a097359d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Francesca, When scheduling the new CBOR Interim series starting on April 8th, please be sure to make it 3pm (UTC 1500), to keep it at 8am US PDT / 11am US EDT. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434 (to 30 April 2020) 203 W Oak St Ellettsville, IN 47429 812-876-9970 On Wed, Mar 11, 2020 at 11:42 AM Francesca Palombini wrote: > Yes, of course. Joerg and Mike, you are welcome to call in as well if you > can (meeting in 20 minutes), using the webex link: > https://ietf.webex.com/ietf/j.php?MTID=3Dmea32e122c1ea622becb09a8ce1a56ca= e > > Francesca > > =EF=BB=BFOn 11/03/2020, 16:11, "CBOR on behalf of Carsten Bormann" < > cbor-bounces@ietf.org on behalf of cabo@tzi.org> wrote: > > Hi Francesca, > > On 2020-03-11, at 14:58, Francesca Palombini 40ericsson.com@dmarc.ietf.org> wrote: > > > > We will discuss CBOR Bis WGLC that has started, and any other open > business. > > I think we should talk about tags briefly, in particular Joerg=E2=80= =99s > complaint. > He is of course right in saying that we didn=E2=80=99t handle his inp= ut very > well (which I can say because it=E2=80=99s all my fault). We need a time= ly > decision now what do to about dates, so they can go into the driving > license standard. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > 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 > --000000000000b27b7105a097359d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francesca,

When schedulin= g the new CBOR Interim series starting on April 8th, please
be su= re to make it 3pm (UTC 1500), to keep it at 8am US PDT / 11am US EDT.
=

Cheers,
- Ira

<= div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature= ">
Ira McDonald (Musician / Software Architect)
Co-C= hair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata = Access Protocol SG
Chair - Linux Foundation Open = Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IE= EE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP &= amp; Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gma= il.com
(permanent) PO Box 221=C2=A0 Grand Marais, MI 49839=C2=A0 906= -494-2434
(to 30 April 2020) 203 W Oak St=C2=A0 Ellettsville, IN = 47429=C2=A0 812-876-9970


=
On Wed, Ma= r 11, 2020 at 11:42 AM Francesca Palombini <francesca.palombini=3D40ericsson.com@dmarc.ietf.org> wrote:
Yes= , of course. Joerg and Mike, you are welcome to call in as well if you can = (meeting in 20 minutes), using the webex link: https://ietf.webex.com/ietf/j.php?MTID=3Dmea32e122c1ea= 622becb09a8ce1a56cae

Francesca

=EF=BB=BFOn 11/03/2020, 16:11, "CBOR on behalf of Carsten Bormann"= ; <cbor-bounc= es@ietf.org on behalf of cabo@tzi.org> wrote:

=C2=A0 =C2=A0 Hi Francesca,

=C2=A0 =C2=A0 On 2020-03-11, at 14:58, Francesca Palombini <francesca.pa= lombini=3D40ericsson.com@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > We will discuss CBOR Bis WGLC that has started,=C2=A0 an= d any other open business.

=C2=A0 =C2=A0 I think we should talk about tags briefly, in particular Joer= g=E2=80=99s complaint.
=C2=A0 =C2=A0 He is of course right in saying that we didn=E2=80=99t handle= his input very well (which I can say because it=E2=80=99s all my fault).= =C2=A0 We need a timely decision now what do to about dates, so they can go= into the driving license standard.

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

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


_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
--000000000000b27b7105a097359d-- From nobody Wed Mar 11 10:34:19 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 AD3513A0EF7 for ; Wed, 11 Mar 2020 10:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cYbVyp729JKQ for ; Wed, 11 Mar 2020 10:34:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17EB3A0EEF for ; Wed, 11 Mar 2020 10:34:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 02D0738986 for ; Wed, 11 Mar 2020 13:32:54 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D81C2AE8 for ; Wed, 11 Mar 2020 13:34:06 -0400 (EDT) From: Michael Richardson To: "cbor\@ietf.org" In-Reply-To: References: <8D3CECED-24C6-4CE6-927C-C8184DFA70C2@ericsson.com> <7B41A92B-9463-435B-AC9C-3D7550FD49DF@tzi.org> <02CA05AB-D19D-4BDE-9852-A905D83FF424@ericsson.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] Interim today 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, 11 Mar 2020 17:34:18 -0000 --=-=-= Content-Type: text/plain Ira McDonald wrote: > Hi Francesca, > When scheduling the new CBOR Interim series starting on April 8th, > please be sure to make it 3pm (UTC 1500), to keep it at 8am US PDT / > 11am US EDT. I think you mean that we should make it 17:00 CET, which is what I think we discussed. (Not anchored to UTC, but CET) Webex will let you specify the timezone, and I think the datatracker will too. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl5pIQ4ACgkQgItw+93Q 3WUncwgAsy0hldNvGPck80iQ790GVYQTiwHw3qvEytEaVy0uq5wa4DEzc0ZTuTf+ vuFjo7eqPjAAnrj6VRQyc2niEw6+xzLkUrHm8j49C+KaLDNKi8SQspOXZC40e1XC 0ql0uZnkyTQ7J15oc0AkkQVLQ0BfFTgSxuVlIVEqZ1BRivaQ4pnCZjQ1Ir9u4QA6 SUu5g4VbFX8ifnRkL11XQbcrXJwdflBNeB27hJAckkE6kKI0bSuC/6afuTDt9GAc N9tt8EPgOE9hEQHctW8+DIWsWY0I0BqjwWajtlP7Pt9XHR+DRafEV/k0l1phTd+/ ixj4FQCaZlA0QF7lsBQpABAmjuBGug== =eLpH -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 11 10:35:01 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 7D6FD3A0EFB for ; Wed, 11 Mar 2020 10:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gs-6m_ViF20l for ; Wed, 11 Mar 2020 10:34:57 -0700 (PDT) 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 C96F33A0EF7 for ; Wed, 11 Mar 2020 10:34:56 -0700 (PDT) Received: from [172.16.42.113] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48czcH1NpGzyQp; Wed, 11 Mar 2020 18:34:55 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: Date: Wed, 11 Mar 2020 18:34:54 +0100 Cc: Francesca Palombini , =?utf-8?B?IlJpY2h0ZXIsIErDtnJnIg==?= , "cbor@ietf.org" , Mike Jones X-Mao-Original-Outgoing-Id: 605640894.634969-ad3b33a079bd1d8eeee39a75e3447034 Content-Transfer-Encoding: quoted-printable Message-Id: <07E9B3E1-4493-4A92-BAFE-5F4B0A932087@tzi.org> References: <8D3CECED-24C6-4CE6-927C-C8184DFA70C2@ericsson.com> <7B41A92B-9463-435B-AC9C-3D7550FD49DF@tzi.org> <02CA05AB-D19D-4BDE-9852-A905D83FF424@ericsson.com> To: Ira McDonald X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Cbor] Interim today 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, 11 Mar 2020 17:35:00 -0000 On 2020-03-11, at 18:02, Ira McDonald wrote: >=20 > When scheduling the new CBOR Interim series starting on April 8th, = please > be sure to make it 3pm (UTC 1500), to keep it at 8am US PDT / 11am US = EDT. Right. So really, we should be scheduling this to PT (PST/PDT) so that = always stays on 08:00 even when the timing in Europe wobbles around. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 11 11:56:56 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 3CB923A115B for ; Wed, 11 Mar 2020 11:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 yCNRn8fsNeSS for ; Wed, 11 Mar 2020 11:56:52 -0700 (PDT) Received: from p3plsmtpa07-05.prod.phx3.secureserver.net (p3plsmtpa07-05.prod.phx3.secureserver.net [173.201.192.234]) (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 6665E3A115A for ; Wed, 11 Mar 2020 11:56:52 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id C6XDjdwvIVFE6C6XDjL0QA; Wed, 11 Mar 2020 11:56:52 -0700 X-CMAE-Analysis: v=2.3 cv=aJiOVo1m c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=48vgC7mUAAAA:8 a=yMhMjlubAAAA:8 a=gKmFwSsBAAAA:8 a=DJVM3KTjAAAA:8 a=I0CVDw5ZAAAA:8 a=9iNY4oMFKxKMKoEu75AA:9 a=UGs9-W9-5jXaKDlP:21 a=WQttM2v-UL960qre:21 a=QEXdDO2ut3YA:10 a=Unaa3BaWtZcA:10 a=CUE2eSOWeB8A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=nnPW6aIcBuj1ljLj_o6Q:22 a=jRQN-ld2qtESDXB7g7zv:22 a=YdXdGVBxRxTCRzIkH2Jn:22 X-SECURESERVER-ACCT: lgl@island-resort.com 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, 11 Mar 2020 11:56:51 -0700 Cc: Carsten Bormann , =?utf-8?B?IlJpY2h0ZXIsIErDtnJnIg==?= , "cbor@ietf.org" , Anthony Nadalin Content-Transfer-Encoding: quoted-printable Message-Id: <352FBB13-09FB-4998-8646-FC8FE51392FA@island-resort.com> References: <282209381d8b4a8b8e77515142266df2@pdv-FS.de> <5D27981B-81C8-43C0-A229-66343D9D67B4@tzi.org> To: Mike Jones X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfPqyxlDdrAgoXV+PBNdpbkV04mMXP9oJdONDjD9TDFZx7NSW9hbTjqmhbwRBiz4A/BRJJbNlAjeIcylwEA4VIILFFsYtRQmokvX9jnqw2T1DcPsWMCon Iso0dIFxM7qse57ymKYk/pNb54EC6RpG4zRHodSZ/a1YzBJGBOudCPcH2XPSC2JS4VHdbvtYq2GF4V+eQgYdOHPO/uRkeZhzi7voPdcyw1F4v+B/ZmIAVkiM VaIlh/e5+BQv1zVa+vTy9NvdfXHgtoYooJJHeMCcOHiLkRv+aKDNcM+CL7X5lLHHo9rWiaVpbrWYNLJ3FSfcRQ== Archived-At: Subject: Re: [Cbor] [EXTERNAL] Re: CBOR tag for RFC 3339 full-date values 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, 11 Mar 2020 18:56:54 -0000 I=E2=80=99d suggest the numeric date be restricted to integers. No = floats, bignums, decimal fractions=E2=80=A6 Fractions of days can be = represented by tag 0 or tag 1 using hours, minutes, seconds. 64-bit = integer counts of days are large enough. LL > On Mar 11, 2020, at 9:57 AM, Mike Jones = wrote: >=20 > I'm fine merging J=C3=B6rg's numeric date tag into my draft, provided = that the result is not a polymorphic tag, in which the value could be = either a number or a string. We should allocate separate tags for = string date and numeric date, just as tags 0 and 1 are different, and = not polymorphic. >=20 > If this works for everyone, I'll add the numeric date tag with = proposed value 'd' into my draft. >=20 > -- Mike >=20 > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Wednesday, March 11, 2020 9:51 AM > To: "Richter, J=C3=B6rg" ; Mike Jones = > Cc: cbor@ietf.org; Anthony Nadalin > Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values >=20 > Hi Joerg, Mike, >=20 > we discussed the date tag proposals at the CBOR interim today. > The meeting consensus was that we should merge the date tag part of = Joerg=E2=80=99s specification (i.e., both textual and numeric date = references) with Mike=E2=80=99s draft, and spend a 1+1 tag (which would = indeed conveniently be tag 100 =3D =E2=80=98d=E2=80=99). >=20 > I would like to work with the two of you to generate a -01 of Mike=E2=80= =99s draft with text from Joerg, for discussion on May 25th (or whatever = replacement we find for the physical IETF107 meeting.) >=20 > (We would look at time-of-day and timezone right after registering the = date tag from -01; maybe in a -02. My personal view would be that the = time-of-day tag from Joerg would go right in, but we might want to go = for a 1+2 tag for timezone [29818 for =E2=80=99tz=E2=80=99 maybe?]. But = let=E2=80=99s discuss this when we are there.) >=20 > Is that a good way forward? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On 2020-03-11, at 16:25, Carsten Bormann wrote: >>=20 >> Hi Joerg, >>=20 >> I=E2=80=99m sorry we didn=E2=80=99t handle your requests properly. >> Let=E2=80=99s try to fix this now. >>=20 >>> On 2020-03-04, at 08:42, Richter, J=C3=B6rg = wrote: >>>=20 >>> Hi, >>>=20 >>>> The need for a date (not time) tag has come up before; I just = can=E2=80=99t remember where. >>>=20 >>> One year ago I sent a proposal f=C3=BCr a date tag [1]. >>> So far it has not made it into the overview of the assigned = CBOR-tags [2]. >>>=20 >>> I would very much appreciate if the suggested tag number is used for = the date-tag, since we already use it internally. >>=20 >> What I like about Mike=E2=80=99s draft is that he references RFC = 3339, which already is an established specification for how to write = dates textually. For that half of the proposal, I don=E2=80=99t think = there is a technical difference with your proposal (except that Mike = suggested a different tag number). Beyond Mike=E2=80=99s draft, we = would need to decide that we like to use the same tag with an = epoch-based numeric date. I think this is OK; it just requires users of = the tag to specify which of the internal structures (or both) they would = accept. Note that we are running into the same issue with tag 1 (as = used in EAT in the RATS WG), so that may help accepting that this is a = normal thing to so. >>=20 >>> What is missing for the suggested tag numbers to be assigned? >>=20 >> I think we just have to make the decision to spend the 1+1 (short) = tag. >> That becomes somewhat easier with including the numeric date, because = that is indeed quite compact and merits a short tag. >>=20 >>> Btw. I have another proposal for currencies and money amounts at [3] = whose tags were not assigned either. >>=20 >> Let=E2=80=99s get to that, too, right after we are done with the date = tag. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>> - J=C3=B6rg >>>=20 >>> [1] https://j-richter.github.io/CBOR/date.html >>> [2] https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml >>> [3] https://j-richter.github.io/CBOR/currency.html >>>=20 >>=20 >=20 > _______________________________________________ > 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 Wed Mar 11 13:25:49 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 C85EF3A09C3; Wed, 11 Mar 2020 13:25:37 -0700 (PDT) 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.120.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158395833747.1666.1343907101806680235@ietfa.amsl.com> Date: Wed, 11 Mar 2020 13:25:37 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-04-08 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, 11 Mar 2020 20:25:38 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2020-04-08 from 17:00 to 18:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: WebEx details will be sent to the CBOR mailing list before each call. The CBOR working group will have conference calls running every two weeks through the end of July 2020 (until IETF 108). Day: every other Wednesday beginning on 8 April Dates: 8, 22 Apr; 6, 20 May; 3, 17 Jun; 1, 15 Jul Time: 17:00 to 18:00 CET/CEST We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. From nobody Wed Mar 11 13:26:11 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 C4E0E3A0B32; Wed, 11 Mar 2020 13:25:58 -0700 (PDT) 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.120.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158395835874.1724.4992235217550293729@ietfa.amsl.com> Date: Wed, 11 Mar 2020 13:25:58 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-04-22 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 20:26:07 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2020-04-22 from 17:00 to 18:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: WebEx details will be sent to the CBOR mailing list before each call. The CBOR working group will have conference calls running every two weeks through the end of July 2020 (until IETF 108). Day: every other Wednesday beginning on 8 April Dates: 8, 22 Apr; 6, 20 May; 3, 17 Jun; 1, 15 Jul Time: 17:00 to 18:00 CET/CEST We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. From nobody Wed Mar 11 13:26:25 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 82EEB3A0C2F; Wed, 11 Mar 2020 13:26:17 -0700 (PDT) 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.120.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158395837743.1728.8385467266797430566@ietfa.amsl.com> Date: Wed, 11 Mar 2020 13:26:17 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-05-06 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 20:26:24 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2020-05-06 from 17:00 to 18:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: WebEx details will be sent to the CBOR mailing list before each call. The CBOR working group will have conference calls running every two weeks through the end of July 2020 (until IETF 108). Day: every other Wednesday beginning on 8 April Dates: 8, 22 Apr; 6, 20 May; 3, 17 Jun; 1, 15 Jul Time: 17:00 to 18:00 CET/CEST We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. From nobody Wed Mar 11 13:26:45 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 F1A433A09CC; Wed, 11 Mar 2020 13:26:32 -0700 (PDT) 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.120.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158395839293.1461.16378907043342289427@ietfa.amsl.com> Date: Wed, 11 Mar 2020 13:26:32 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-05-20 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, 11 Mar 2020 20:26:40 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2020-05-20 from 17:00 to 18:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: WebEx details will be sent to the CBOR mailing list before each call. The CBOR working group will have conference calls running every two weeks through the end of July 2020 (until IETF 108). Day: every other Wednesday beginning on 8 April Dates: 8, 22 Apr; 6, 20 May; 3, 17 Jun; 1, 15 Jul Time: 17:00 to 18:00 CET/CEST We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. From nobody Wed Mar 11 13:26:59 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 158483A0C3C; Wed, 11 Mar 2020 13:26:50 -0700 (PDT) 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.120.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158395841004.1573.7736806537010986108@ietfa.amsl.com> Date: Wed, 11 Mar 2020 13:26:50 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-06-03 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 20:26:57 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2020-06-03 from 17:00 to 18:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: WebEx details will be sent to the CBOR mailing list before each call. The CBOR working group will have conference calls running every two weeks through the end of July 2020 (until IETF 108). Day: every other Wednesday beginning on 8 April Dates: 8, 22 Apr; 6, 20 May; 3, 17 Jun; 1, 15 Jul Time: 17:00 to 18:00 CET/CEST We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. From nobody Wed Mar 11 13:27:11 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 2BA323A0C4D; Wed, 11 Mar 2020 13:26:58 -0700 (PDT) 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.120.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158395841812.1564.7295803517719040487@ietfa.amsl.com> Date: Wed, 11 Mar 2020 13:26:58 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-06-17 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 20:27:05 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2020-06-17 from 17:00 to 18:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: WebEx details will be sent to the CBOR mailing list before each call. The CBOR working group will have conference calls running every two weeks through the end of July 2020 (until IETF 108). Day: every other Wednesday beginning on 8 April Dates: 8, 22 Apr; 6, 20 May; 3, 17 Jun; 1, 15 Jul Time: 17:00 to 18:00 CET/CEST We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. From nobody Wed Mar 11 13:27:19 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 885303A0D8A; Wed, 11 Mar 2020 13:27:05 -0700 (PDT) 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.120.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158395842551.1427.1305922917911653847@ietfa.amsl.com> Date: Wed, 11 Mar 2020 13:27:05 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-07-01 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, 11 Mar 2020 20:27:13 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2020-07-01 from 17:00 to 18:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: WebEx details will be sent to the CBOR mailing list before each call. The CBOR working group will have conference calls running every two weeks through the end of July 2020 (until IETF 108). Day: every other Wednesday beginning on 8 April Dates: 8, 22 Apr; 6, 20 May; 3, 17 Jun; 1, 15 Jul Time: 17:00 to 18:00 CET/CEST We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. From nobody Wed Mar 11 13:27:25 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 89DAD3A0CEB; Wed, 11 Mar 2020 13:27:13 -0700 (PDT) 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.120.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158395843352.1461.15922887718459801294@ietfa.amsl.com> Date: Wed, 11 Mar 2020 13:27:13 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-07-15 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, 11 Mar 2020 20:27:21 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2020-07-15 from 17:00 to 18:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: WebEx details will be sent to the CBOR mailing list before each call. The CBOR working group will have conference calls running every two weeks through the end of July 2020 (until IETF 108). Day: every other Wednesday beginning on 8 April Dates: 8, 22 Apr; 6, 20 May; 3, 17 Jun; 1, 15 Jul Time: 17:00 to 18:00 CET/CEST We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. From nobody Wed Mar 11 13:32:00 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 8C1403A0C03 for ; Wed, 11 Mar 2020 13:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J2viNbbnH6Kk for ; Wed, 11 Mar 2020 13:31:49 -0700 (PDT) Received: from mail.pdv-fs.de (mail.pdv-fs.de [213.208.220.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4353A0C59 for ; Wed, 11 Mar 2020 13:31:49 -0700 (PDT) Received: from mail.pdv-fs.de (unknown [192.168.180.94]) by mail.pdv-fs.de (Postfix) with ESMTPS; Wed, 11 Mar 2020 21:31:47 +0100 (CET) Received: from EXCHDB1.pdv-fs.de (192.168.180.94) by EXCHDB1.pdv-fs.de (192.168.180.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 11 Mar 2020 21:31:46 +0100 Received: from EXCHDB1.pdv-fs.de ([fe80::6c4a:8b1b:60f4:4437]) by EXCHDB1.pdv-fs.de ([fe80::6c4a:8b1b:60f4:4437%15]) with mapi id 15.01.1913.007; Wed, 11 Mar 2020 21:31:46 +0100 From: =?utf-8?B?UmljaHRlciwgSsO2cmc=?= To: Carsten Bormann , Mike Jones CC: "cbor@ietf.org" , Anthony Nadalin Thread-Topic: [Cbor] CBOR tag for RFC 3339 full-date values Thread-Index: AQHV8a0B9fEeIB5RW0GE31JPZx9/XKg3arYAgACfx6iAC3PngIAAF+AAgABFU5A= Date: Wed, 11 Mar 2020 20:31:46 +0000 Message-ID: References: <282209381d8b4a8b8e77515142266df2@pdv-FS.de> <5D27981B-81C8-43C0-A229-66343D9D67B4@tzi.org> In-Reply-To: <5D27981B-81C8-43C0-A229-66343D9D67B4@tzi.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.185.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TMASE-Version: DDEI-3.5-8.5.1020-25284.001 X-TMASE-Result: 10--0.029000-10.000000 X-TMASE-MatchedRID: 5IBTOSGC9OS5rzEqaXlmzfHkpkyUphL9s9oMcuQXwlDkMnUVL5d0E5Yj XCUnFqgeiK4AoRG6tnCIV5WesVAuqdEUjczUrsJlD2tWc5ns1ranZS/aYgjrzm2ByMVAI+ZIWiM H3xEQxoP+M7N/it0rQ92ib8sTd6MuNZgeA8Gk1dbJ/bVh4iw9hh+26QzoWaY2a73+XlYDLuytab Krs9q4eSgju7NFfqM/Gg/kX2OR0In6nTFnNW6djhlJRfzNw8afxYt6Ilbxn6lZt8OgpoPsDeiqq 9cInCOjW9zSv8665/7giyJNf8JB3FsibBvw54hingIgpj8eDcDBa6VG2+9jFNZE3xJMmmXc+gtH j7OwNO0NstCXmf87HLOuelgNCzz/hYVD0FfmpwvgXdWmCRAI4N6tWvsRM7YpdDgnzkqM+leCFT9 qgcHJrWLrfmHAqc7dQcBXoYOQIyJd4Cb0CF6MJU8jxvONzeaafEwSr4v8H0fxemJbhO7ZfZTIXc erO/Bu X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 X-TMASE-INERTIA: 1-0;;J4gzHMCxkPyYUJl0x8cA1w==;; Archived-At: Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values 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, 11 Mar 2020 20:31:59 -0000 KFJlcGx5aW5nIHRvIG1vcmUgdGhhbiBvbmUgbWVzc2FnZSBoZXJlKQ0KDQpDYXJzdGVuIEJvcm1h bm46IA0KPiBJcyB0aGF0IGEgZ29vZCB3YXkgZm9yd2FyZD8NCg0KSSBhbSBmaW5lIHdpdGggdGhl IHN1Z2dlc3RlZCBwcm9jZWR1cmUuIA0KDQo+IFdoYXQgSSBsaWtlIGFib3V0IE1pa2XigJlzIGRy YWZ0IGlzIHRoYXQgaGUgcmVmZXJlbmNlcyBSRkMgMzMzOSwgd2hpY2ggYWxyZWFkeSBpcyANCj4g YW4gZXN0YWJsaXNoZWQgc3BlY2lmaWNhdGlvbiBmb3IgaG93IHRvIHdyaXRlIGRhdGVzIHRleHR1 YWxseQ0KDQpJU08gODYwMSBhbHNvIGRlZmluZXMgdGhpcyBmb3JtYXQgZm9yIGRhdGVzLiBJdCBp cyBtZW50aW9uZWQgaW4gdGhlICJEZXRhaWxlZCBTZW1hbnRpY3MiIA0Kc2VjdGlvbiBvZiBteSBw cm9wb3NhbC4NCg0KTWlrZSBKb25lczoNCj4gSSdtIGZpbmUgbWVyZ2luZyBKw7ZyZydzIG51bWVy aWMgZGF0ZSB0YWcgaW50byBteSBkcmFmdCwgcHJvdmlkZWQgdGhhdCB0aGUgcmVzdWx0IGlzIA0K PiBub3QgYSBwb2x5bW9ycGhpYyB0YWcsIGluIHdoaWNoIHRoZSB2YWx1ZSBjb3VsZCBiZSBlaXRo ZXIgYSBudW1iZXIgb3IgYSBzdHJpbmcuICANCj4gV2Ugc2hvdWxkIGFsbG9jYXRlIHNlcGFyYXRl IHRhZ3MgZm9yIHN0cmluZyBkYXRlIGFuZCBudW1lcmljIGRhdGUsIGp1c3QgYXMgdGFncyANCj4g MCBhbmQgMSBhcmUgZGlmZmVyZW50LCBhbmQgbm90IHBvbHltb3JwaGljLg0KDQpJJ3ZlIGdvdCB0 aGUgaW1wcmVzc2lvbiB0aGF0IHVzaW5nIGEgcG9seW1vcnBoaWMgdGFnIHdvdWxkIGJlIG5vIG1h am9yIHByb2JsZW0uDQpXZSBjYW4gZXZlbiBzcGVjaWZ5IHRoYXQgZGVjb2RlcnMgbWlnaHQgb25s eSBzdXBwb3J0IG9uZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgdGFnLg0KSSB0aGluayBpdCB3b3Vs ZCBoYXZlIHRoZSBzYW1lIGVmZmVjdCBpZiBhIGRlY29kZXIgc3VwcG9ydHMgb25seSBvbmUgb2Yg dGhlIHR3byB0YWdzLg0KQnV0IGVpdGhlciB3YXkgSSB3b3VsZCBoYXZlIG5vIG9iamVjdGlvbnMg dG8gdXNpbmcgdHdvIHRhZ3MuDQoNCkxhdXJlbmNlIEx1bmRibGFkZToNCj4gSeKAmWQgc3VnZ2Vz dCB0aGUgbnVtZXJpYyBkYXRlIGJlIHJlc3RyaWN0ZWQgdG8gaW50ZWdlcnMuIE5vIGZsb2F0cywg YmlnbnVtcywNCj4gZGVjaW1hbCBmcmFjdGlvbnPigKYgDQoNClllcywgdGhhdCB3YXMgdGhlIHBs YW4uIE9ubHkgbWFqb3IgdHlwZXMgMCBhbmQgMS4gDQoNCj4gRnJhY3Rpb25zIG9mIGRheXMgY2Fu IGJlIHJlcHJlc2VudGVkIGJ5IHRhZyAwIG9yIHRhZyAxIHVzaW5nDQo+IGhvdXJzLCBtaW51dGVz LCBzZWNvbmRzLiA2NC1iaXQgaW50ZWdlciBjb3VudHMgb2YgZGF5cyBhcmUgbGFyZ2UgZW5vdWdo Lg0KDQpUaGlzIEkgZG9uJ3QgdW5kZXJzdGFuZC4gVGhlIHByb3Bvc2FsIG9ubHkgaGFuZGxlcyB3 aG9sZSBkYXlzIGFzIG9uZSBudW1iZXIuDQoNCkFub3RoZXIgdGhpbmcgdG8gY29uc2lkZXI6DQpX ZSBzaG91bGQgbWVudGlvbiB0aGF0IHRoaXMgdGFnKHMpIHVzZSB0aGUgcHJvbGVwdGljIEdyZWdv cmlhbiBjYWxlbmRhci4gU28gdGhhdCANCmRhdGVzIGJlZm9yZSB0aGUgR3JlZ29yaWFuIGNhbGVu ZGFyIGhhdmUgYSB1bmlxdWUgc2VtYW50aWNzLg0KDQotIErDtnJnDQoNCg== From nobody Wed Mar 11 14:09:46 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 9A9933A0C82 for ; Wed, 11 Mar 2020 14:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 x6xkS25C_4cP for ; Wed, 11 Mar 2020 14:09:42 -0700 (PDT) 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 5AD243A0CB7 for ; Wed, 11 Mar 2020 14:09:37 -0700 (PDT) Received: from [172.16.42.113] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48d4Mr5qBkzyT3; Wed, 11 Mar 2020 22:09:27 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: Date: Wed, 11 Mar 2020 22:09:17 +0100 Cc: Mike Jones , "cbor@ietf.org" , Anthony Nadalin X-Mao-Original-Outgoing-Id: 605653757.100925-7ddf90c371449ca745f160c7d8ecb3e7 Content-Transfer-Encoding: quoted-printable Message-Id: <79EDF742-2E54-4829-93F2-BE5A009734E2@tzi.org> References: <282209381d8b4a8b8e77515142266df2@pdv-FS.de> <5D27981B-81C8-43C0-A229-66343D9D67B4@tzi.org> To: =?utf-8?B?IlJpY2h0ZXIsIErDtnJnIg==?= X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values 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, 11 Mar 2020 21:09:45 -0000 On 2020-03-11, at 21:31, Richter, J=C3=B6rg = wrote: >=20 > (Replying to more than one message here) >=20 > Carsten Bormann:=20 >> Is that a good way forward? >=20 > I am fine with the suggested procedure.=20 Great! >=20 >> What I like about Mike=E2=80=99s draft is that he references RFC = 3339, which already is=20 >> an established specification for how to write dates textually >=20 > ISO 8601 also defines this format for dates. It is mentioned in the = "Detailed Semantics"=20 > section of my proposal. ISO 8601 is very =E2=80=9Cflexible=E2=80=9D. RFC 3339 uses ISO 8601, = but helps by restricting this to commonly used cases. So I think referencing RFC 3339 is strictly better than just naked ISO = 8601. > Mike Jones: >> I'm fine merging J=C3=B6rg's numeric date tag into my draft, provided = that the result is=20 >> not a polymorphic tag, in which the value could be either a number or = a string. =20 >> We should allocate separate tags for string date and numeric date, = just as tags=20 >> 0 and 1 are different, and not polymorphic. >=20 > I've got the impression that using a polymorphic tag would be no major = problem. > We can even specify that decoders might only support one = representation of the tag. > I think it would have the same effect if a decoder supports only one = of the two tags. > But either way I would have no objections to using two tags. I=E2=80=99m not sure I like the term =E2=80=9Cpolymorphic=E2=80=9D here = too much =E2=80=94 in any case, the =E2=80=9Cvalue=E2=80=9D would be a = date. The content could be both text and number. Tag 1 already does = this (integer vs. floating-point), so we already have to deal with these = (i.e., allow applications to not just say =E2=80=9CTag 1=E2=80=9D, but = =E2=80=9CTag 1 with integer content=E2=80=9D). But we did separate Tag = 0 and Tag 1, mostly because the semantics of the value are subtly = different. Are they here? > Laurence Lundblade: >> I=E2=80=99d suggest the numeric date be restricted to integers. No = floats, bignums, >> decimal fractions=E2=80=A6=20 >=20 > Yes, that was the plan. Only major types 0 and 1.=20 Finer granularity between dates would be times, which we already have, = so this naturally should be integers. >> Fractions of days can be represented by tag 0 or tag 1 using >> hours, minutes, seconds. 64-bit integer counts of days are large = enough. >=20 > This I don't understand. The proposal only handles whole days as one = number. Right. Only full days. (The related observation is that these are = always in the local time of some context that is not expressed, which is = rather different from our time tags.) > Another thing to consider: > We should mention that this tag(s) use the proleptic Gregorian = calendar. So that=20 > dates before the Gregorian calendar have a unique semantics. Good point. In 7049bis, we just say: Negative values (major type 1 and negative floating-point numbers) are interpreted as determined by the application requirements as there is no universal standard for UTC count-of-seconds time before 1970-01-01T00:00Z (this is particularly true for points in time that precede discontinuities in national calendars). [=E2=80=A6] That is less of a problem on the date-only side (as long as dates change = on local midnight=E2=80=A6 and not noon), so we may be able to be more = specific. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 11 15:11:12 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 A750E3A077E for ; Wed, 11 Mar 2020 15:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, 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=microsoft.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 gthf5tZiCh88 for ; Wed, 11 Mar 2020 15:11:01 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650100.outbound.protection.outlook.com [40.107.65.100]) (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 8D81D3A07AB for ; Wed, 11 Mar 2020 15:11:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WfR0C/kog3/ev9u467ljo7Qa93n2XJO5lwjSS/A0gBXJjEt8sDEYI5C/C+cfIFg4DEkE0rXi3k84hPlYUwE0pyoKy8bjNcifqT82OhBCEKRB7p1f7qBe6BTaLA+DARxDC3C9tvCnhfU7sKh0syRtfyNdjwpIpUV44vg8COLfP2WbazXrQUHikKMFK8lh5Ox/SV3cgbTYxMoB08sBcn87xZWnnD5c+/DxID/1rf0drqVMCdk5i8JI/8spSwTjnQCviAExtIODrnZXZmBdHXoGWR9bO7W1fdljwHyFzY0DKZ1B8VjB45OD766/OMHHkT88Arf+N68csHqjEdagEqGM1g== 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=bW78B/Tpg6cVA18JpLfka7UybRtga8BXyjkhqCiI9RU=; b=ObXFtptxmYC9io9U/jXjY3G9pVfiIixX2D09mHIr4XVE6lD3dzdHnwMOeZuZVP9zALCHWy0ygDWliUwfr3Qz3DEdj4AI77/tgvDpxkOx5Jj8zyQLRZ0dNdIXEYou/5zESdhMNRbEaFLZUWhkF/7CksqZxTUypF2w7KEuIRNqvhdijiCAl+iJ4quGmbTWBBChT6Ul3v2zLClbR2jI+UKyEN8Zu9Hxd3s1YjPilMkFc5UKNeSQ2eQSfQ+CxaNQ+qW/x2g+DOn5M3uac/hGZaNbjOkYzqeHHwOEH8WHAAoSE2nAzP1bWbkyA9TGQvnDQNV/htQ6JUbhBo2kEfKDIwmH0w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bW78B/Tpg6cVA18JpLfka7UybRtga8BXyjkhqCiI9RU=; b=EbJ2PUqmBmUaUiLgvOTEyD+pCiWj97cc+pv757BlDRX46LQYAwqympioEKRY+Yp8VOeTPUSasR5OQXap8OOQIQkQiEom/PVckkr9kkePloelFt2Y03aleDo5nV4mSr5+0byq3JTvg9Z3k8RgnQRDaYarXtYjd8iptQjUOhavNxU= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0747.namprd00.prod.outlook.com (2603:10b6:610:68::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2849.0; Wed, 11 Mar 2020 22:10:59 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::588a:9529:739a:961f]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::588a:9529:739a:961f%7]) with mapi id 15.20.2853.000; Wed, 11 Mar 2020 22:10:59 +0000 From: Mike Jones To: Carsten Bormann , =?utf-8?B?IlJpY2h0ZXIsIErDtnJnIg==?= CC: "cbor@ietf.org" , Mike Jones , Anthony Nadalin Thread-Topic: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values Thread-Index: AQHV9+QoB1aP19tdwk+LBcQJWzg8U6hD4t2AgAANTWA= Date: Wed, 11 Mar 2020 22:10:58 +0000 Message-ID: References: <282209381d8b4a8b8e77515142266df2@pdv-FS.de> <5D27981B-81C8-43C0-A229-66343D9D67B4@tzi.org> <79EDF742-2E54-4829-93F2-BE5A009734E2@tzi.org> In-Reply-To: <79EDF742-2E54-4829-93F2-BE5A009734E2@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=731aab9e-566c-4749-ac3a-0000f1af9fd5; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-03-11T21:56:54Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.83.137] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 00427531-d4ce-44aa-83a5-08d7c6091431 x-ms-traffictypediagnostic: CH2PR00MB0747:|CH2PR00MB0747: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0339F89554 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(366004)(39860400002)(396003)(346002)(376002)(199004)(52536014)(53546011)(8990500004)(2906002)(316002)(76116006)(81156014)(66946007)(7696005)(66476007)(6506007)(8676002)(81166006)(66446008)(33656002)(10290500003)(5660300002)(4326008)(66556008)(64756008)(186003)(26005)(478600001)(71200400001)(55016002)(107886003)(966005)(110136005)(86362001)(9686003)(66574012)(8936002)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0747; H:CH2PR00MB0679.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6HvmdhyBKtEGQqWZk4Xn6PZtj/3Q5NtcIOhIYodO8puetUmoHPhnpjVAN2RN5s287xFGmMiUfUjs/xiXe1YUhgPFuN2YfeIG26sMEDx1ag/UmcBO6iM4YCQ4jBFBDyjNCZb9jMcIGQeOG4A25OkmfjEqeHFg+oD61zYOO8A38XaXwwui9DKh3tVTZHn9u+n5ffZMs1lz8/a9GT1QbUiwDqoU3bbXFPWrzHILypi+TjwQIbh6+Qi7PFa4Lub414k4ALXO/F2djHtggmNoR7J9xVz3nM+rrIJLbafOS0B4xyWM003nqY8vdhu5Vj7EOtnnYxfPiKYyxU7Pjeg2bVnYrPG/mmQBNtJWqLB1Sm6g93Yise9ZnYUwwUCX6Awuog/B/2iHzPn9fCNovKnENpJiikWvDZgNiYJ947AqaooQJ/ahO9XgSbjxHQgzu6TR7D6fiOvD2fdIKIUcERwgFeLOmxCKegQQJ1n9a9EHDBi6ejbadg9HQZaovx0Wap9Ef7Wn0gwMrj4vXrUm0aAdarjATA== x-ms-exchange-antispam-messagedata: pe3bPItUT/nuKtV9gwAecxb4lzVErsubKG5XB4QV0ycomAJW+8uQ4dqFFVLPDcdrsyCqxeLBY+hJssVu8zK9dH2jSBancospQJ+pr9+Sff+I+GWT+m5c8QSJLBKDA8WO63HW6U4lDhkVw3Yo1SegIQ== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 00427531-d4ce-44aa-83a5-08d7c6091431 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2020 22:10:58.8892 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: t3g5JLNhEjlbkLLm5l2gbrJZnbmW/SG+MVNTzmuaUlxli34h422AXDOcPBwt3wY5iZovldKVWLmOPWlhxPJO0A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0747 Archived-At: Subject: Re: [Cbor] [EXTERNAL] Re: CBOR tag for RFC 3339 full-date values 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, 11 Mar 2020 22:11:11 -0000 VGhlIHBvaW50IG9mIGhhdmluZyB0aGUgdGFnIGlzIHRoYXQgdGhlIGNvZGUga25vd3Mgd2hhdCBm b2xsb3dzLiAgSWYgYSBwb2x5bW9ycGhpYyB0YWcgd2VyZSB1c2VkLCBpbiB3aGljaCB0d28gdW5y ZWxhdGVkIHJlcHJlc2VudGF0aW9ucyBvZiBkYXRlcyBhcmUgbGVnYWwsIHRoZW4gdGhlIGNvZGUg ZG9lc24ndCBrbm93IHdoYXQgZm9sbG93cy4gIEFuZCBpdCBhbHNvIG9wZW5zIHVwIHF1ZXN0aW9u cyB0aGF0IGl0IHdvdWxkIGJlIGNsZWFuZXIgdG8gbmV2ZXIgaGF2ZSB0byBjb25zaWRlciAtIHF1 ZXN0aW9ucyBzdWNoIGFzICJJZiB0aGUgcG9seW1vcnBoaWMgdGFnIGlzIGFkb3B0ZWQsIG11c3Qg TW9iaWxlIERyaXZlcidzIExpY2Vuc2VzIGFjY2VwdCBib3RoIHJlcHJlc2VudGF0aW9ucz8iICBB bmQgIldpbGwgaW50ZXJvcGVyYWJpbGl0eSBiZSBoYXJtZWQgaWYgc29tZSBNb2JpbGUgRHJpdmVy J3MgTGljZW5zZXMgdXNlIG9uZSByZXByZXNlbnRhdGlvbiBhbmQgc29tZSB1c2UgdGhlIG90aGVy PyIgIChUaGUgYW5zd2VyIHRvIHRoYXQgb25lIGlzIHByb2JhYmx5ICJZZXMsIGludGVyb3BlcmFi aWxpdHkgd2lsbCBiZSBoYXJtZWQiLikNCg0KQ2Fyc3RlbiwgSSB0YWtlIHlvdXIgcG9pbnQgYWJv dXQgYm90aCBpbnRlZ2VycyBhbmQgZmxvYXRzIGJlaW5nIGFjY2VwdGFibGUgZm9yIHRhZyAxLiAg QnV0IHRob3NlIGFyZSBjbG9zZWx5IHJlbGF0ZWQgKG51bWVyaWMpIHJlcHJlc2VudGF0aW9ucyBv ZiB0aGUgc2FtZSB0aGluZy4gIFdoZXJlYXMgYSBkYXRlIHN0cmluZyB2ZXJzdXMgbnVtYmVyIG9m IGRheXMgcmVsYXRpdmUgdG8gdGhlIEVwb2NoIGFyZSBuZWFybHkgdW5yZWxhdGVkIHJlcHJlc2Vu dGF0aW9ucywgd2l0aCBmYWlybHkgY29tcGxpY2F0ZWQgY29udmVyc2lvbiBydWxlcyBiZXR3ZWVu IHRoZW0gKGludm9sdmluZyBsZWFwIHllYXJzLCBsZWFwIGNlbnR1cmllcywgbGVhcCA0MDB0aCB5 ZWFycywgZXRjLikuDQoNCkdpdmVuIHRoYXQgSsO2cmcgc3RhdGVkIGJlbG93IHRoYXQgaGUncyBP SyB3aXRoIHVzaW5nIGRpZmZlcmVudCB0YWdzLCBJIHByb3Bvc2UgdGhhdCB3ZSBtb3ZlIGZvcndh cmQgd2l0aCB1c2luZyB0YWcgMTAwNCAocmVxdWVzdGVkKSBmb3IgUkZDIDMzMzkgZnVsbC1kYXRl IHZhbHVlcyBhbmQgdGFnIGNoYXIoJ2QnKSAocmVxdWVzdGVkKSBmb3IgaW50ZWdlciBudW1iZXIg b2YgZGF5cyByZWxhdGl2ZSB0byB0aGUgRXBvY2guICBJZiBJIGRvbid0IGhlYXIgb2JqZWN0aW9u cyBzb29uLCBJJ2xsIHB1Ymxpc2ggdGhhdCBkcmFmdC4NCg0KSsO2cmcgLSBJJ2xsIGFsc28gYWRk IHlvdSBhcyBhIGNvLWF1dGhvci4gIFdoYXQgYWZmaWxpYXRpb24gYW5kIGUtbWFpbCBhZGRyZXNz IGZvciB5b3Ugc2hvdWxkIEkgdXNlPyAgQW5kIGlzIHRoZXJlIGEgVVJMIGZvciBhIGJsb2cgb3Ig V2VicGFnZSB5b3UnZCBhbHNvIGxpa2UgbWUgdG8gaW5jbHVkZSBmb3IgeW91Pw0KDQoJCQkJQ2hl ZXJzLA0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENC T1IgPGNib3ItYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIENhcnN0ZW4gQm9ybWFubg0K U2VudDogV2VkbmVzZGF5LCBNYXJjaCAxMSwgMjAyMCAyOjA5IFBNDQpUbzogIlJpY2h0ZXIsIErD tnJnIiA8Sm9lcmcuUmljaHRlckBwZHYtRlMuZGU+DQpDYzogY2JvckBpZXRmLm9yZzsgTWlrZSBK b25lcyA8TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+OyBBbnRo b255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT4NClN1YmplY3Q6IFtFWFRFUk5BTF0g UmU6IFtDYm9yXSBDQk9SIHRhZyBmb3IgUkZDIDMzMzkgZnVsbC1kYXRlIHZhbHVlcw0KDQpPbiAy MDIwLTAzLTExLCBhdCAyMTozMSwgUmljaHRlciwgSsO2cmcgPEpvZXJnLlJpY2h0ZXJAcGR2LUZT LmRlPiB3cm90ZToNCj4gDQo+IChSZXBseWluZyB0byBtb3JlIHRoYW4gb25lIG1lc3NhZ2UgaGVy ZSkNCj4gDQo+IENhcnN0ZW4gQm9ybWFubjogDQo+PiBJcyB0aGF0IGEgZ29vZCB3YXkgZm9yd2Fy ZD8NCj4gDQo+IEkgYW0gZmluZSB3aXRoIHRoZSBzdWdnZXN0ZWQgcHJvY2VkdXJlLiANCg0KR3Jl YXQhDQoNCj4gDQo+PiBXaGF0IEkgbGlrZSBhYm91dCBNaWtl4oCZcyBkcmFmdCBpcyB0aGF0IGhl IHJlZmVyZW5jZXMgUkZDIDMzMzksIHdoaWNoIA0KPj4gYWxyZWFkeSBpcyBhbiBlc3RhYmxpc2hl ZCBzcGVjaWZpY2F0aW9uIGZvciBob3cgdG8gd3JpdGUgZGF0ZXMgDQo+PiB0ZXh0dWFsbHkNCj4g DQo+IElTTyA4NjAxIGFsc28gZGVmaW5lcyB0aGlzIGZvcm1hdCBmb3IgZGF0ZXMuIEl0IGlzIG1l bnRpb25lZCBpbiB0aGUgIkRldGFpbGVkIFNlbWFudGljcyIgDQo+IHNlY3Rpb24gb2YgbXkgcHJv cG9zYWwuDQoNCklTTyA4NjAxIGlzIHZlcnkg4oCcZmxleGlibGXigJ0uICBSRkMgMzMzOSB1c2Vz IElTTyA4NjAxLCBidXQgaGVscHMgYnkgcmVzdHJpY3RpbmcgdGhpcyB0byBjb21tb25seSB1c2Vk IGNhc2VzLg0KU28gSSB0aGluayByZWZlcmVuY2luZyBSRkMgMzMzOSBpcyBzdHJpY3RseSBiZXR0 ZXIgdGhhbiBqdXN0IG5ha2VkIElTTyA4NjAxLg0KDQo+IE1pa2UgSm9uZXM6DQo+PiBJJ20gZmlu ZSBtZXJnaW5nIErDtnJnJ3MgbnVtZXJpYyBkYXRlIHRhZyBpbnRvIG15IGRyYWZ0LCBwcm92aWRl ZCB0aGF0IA0KPj4gdGhlIHJlc3VsdCBpcyBub3QgYSBwb2x5bW9ycGhpYyB0YWcsIGluIHdoaWNo IHRoZSB2YWx1ZSBjb3VsZCBiZSBlaXRoZXIgYSBudW1iZXIgb3IgYSBzdHJpbmcuDQo+PiBXZSBz aG91bGQgYWxsb2NhdGUgc2VwYXJhdGUgdGFncyBmb3Igc3RyaW5nIGRhdGUgYW5kIG51bWVyaWMg ZGF0ZSwgDQo+PiBqdXN0IGFzIHRhZ3MNCj4+IDAgYW5kIDEgYXJlIGRpZmZlcmVudCwgYW5kIG5v dCBwb2x5bW9ycGhpYy4NCj4gDQo+IEkndmUgZ290IHRoZSBpbXByZXNzaW9uIHRoYXQgdXNpbmcg YSBwb2x5bW9ycGhpYyB0YWcgd291bGQgYmUgbm8gbWFqb3IgcHJvYmxlbS4NCj4gV2UgY2FuIGV2 ZW4gc3BlY2lmeSB0aGF0IGRlY29kZXJzIG1pZ2h0IG9ubHkgc3VwcG9ydCBvbmUgcmVwcmVzZW50 YXRpb24gb2YgdGhlIHRhZy4NCj4gSSB0aGluayBpdCB3b3VsZCBoYXZlIHRoZSBzYW1lIGVmZmVj dCBpZiBhIGRlY29kZXIgc3VwcG9ydHMgb25seSBvbmUgb2YgdGhlIHR3byB0YWdzLg0KPiBCdXQg ZWl0aGVyIHdheSBJIHdvdWxkIGhhdmUgbm8gb2JqZWN0aW9ucyB0byB1c2luZyB0d28gdGFncy4N Cg0KSeKAmW0gbm90IHN1cmUgSSBsaWtlIHRoZSB0ZXJtIOKAnHBvbHltb3JwaGlj4oCdIGhlcmUg dG9vIG11Y2gg4oCUIGluIGFueSBjYXNlLCB0aGUg4oCcdmFsdWXigJ0gd291bGQgYmUgYSBkYXRl LiAgVGhlIGNvbnRlbnQgY291bGQgYmUgYm90aCB0ZXh0IGFuZCBudW1iZXIuICBUYWcgMSBhbHJl YWR5IGRvZXMgdGhpcyAoaW50ZWdlciB2cy4gZmxvYXRpbmctcG9pbnQpLCBzbyB3ZSBhbHJlYWR5 IGhhdmUgdG8gZGVhbCB3aXRoIHRoZXNlIChpLmUuLCBhbGxvdyBhcHBsaWNhdGlvbnMgdG8gbm90 IGp1c3Qgc2F5IOKAnFRhZyAx4oCdLCBidXQg4oCcVGFnIDEgd2l0aCBpbnRlZ2VyIGNvbnRlbnTi gJ0pLiAgQnV0IHdlIGRpZCBzZXBhcmF0ZSBUYWcgMCBhbmQgVGFnIDEsIG1vc3RseSBiZWNhdXNl IHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHZhbHVlIGFyZSBzdWJ0bHkgZGlmZmVyZW50LiAgQXJlIHRo ZXkgaGVyZT8NCg0KPiBMYXVyZW5jZSBMdW5kYmxhZGU6DQo+PiBJ4oCZZCBzdWdnZXN0IHRoZSBu dW1lcmljIGRhdGUgYmUgcmVzdHJpY3RlZCB0byBpbnRlZ2Vycy4gTm8gZmxvYXRzLCANCj4+IGJp Z251bXMsIGRlY2ltYWwgZnJhY3Rpb25z4oCmDQo+IA0KPiBZZXMsIHRoYXQgd2FzIHRoZSBwbGFu LiBPbmx5IG1ham9yIHR5cGVzIDAgYW5kIDEuIA0KDQpGaW5lciBncmFudWxhcml0eSBiZXR3ZWVu IGRhdGVzIHdvdWxkIGJlIHRpbWVzLCB3aGljaCB3ZSBhbHJlYWR5IGhhdmUsIHNvIHRoaXMgbmF0 dXJhbGx5IHNob3VsZCBiZSBpbnRlZ2Vycy4NCg0KPj4gRnJhY3Rpb25zIG9mIGRheXMgY2FuIGJl IHJlcHJlc2VudGVkIGJ5IHRhZyAwIG9yIHRhZyAxIHVzaW5nIGhvdXJzLCANCj4+IG1pbnV0ZXMs IHNlY29uZHMuIDY0LWJpdCBpbnRlZ2VyIGNvdW50cyBvZiBkYXlzIGFyZSBsYXJnZSBlbm91Z2gu DQo+IA0KPiBUaGlzIEkgZG9uJ3QgdW5kZXJzdGFuZC4gVGhlIHByb3Bvc2FsIG9ubHkgaGFuZGxl cyB3aG9sZSBkYXlzIGFzIG9uZSBudW1iZXIuDQoNClJpZ2h0LiAgT25seSBmdWxsIGRheXMuICAo VGhlIHJlbGF0ZWQgb2JzZXJ2YXRpb24gaXMgdGhhdCB0aGVzZSBhcmUgYWx3YXlzIGluIHRoZSBs b2NhbCB0aW1lIG9mIHNvbWUgY29udGV4dCB0aGF0IGlzIG5vdCBleHByZXNzZWQsIHdoaWNoIGlz IHJhdGhlciBkaWZmZXJlbnQgZnJvbSBvdXIgdGltZSB0YWdzLikNCg0KPiBBbm90aGVyIHRoaW5n IHRvIGNvbnNpZGVyOg0KPiBXZSBzaG91bGQgbWVudGlvbiB0aGF0IHRoaXMgdGFnKHMpIHVzZSB0 aGUgcHJvbGVwdGljIEdyZWdvcmlhbiANCj4gY2FsZW5kYXIuIFNvIHRoYXQgZGF0ZXMgYmVmb3Jl IHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIgaGF2ZSBhIHVuaXF1ZSBzZW1hbnRpY3MuDQoNCkdvb2Qg cG9pbnQuICBJbiA3MDQ5YmlzLCB3ZSBqdXN0IHNheToNCg0KTmVnYXRpdmUgdmFsdWVzIChtYWpv ciB0eXBlIDEgYW5kIG5lZ2F0aXZlIGZsb2F0aW5nLXBvaW50IG51bWJlcnMpIGFyZSBpbnRlcnBy ZXRlZCBhcyBkZXRlcm1pbmVkIGJ5IHRoZSBhcHBsaWNhdGlvbiByZXF1aXJlbWVudHMgYXMgdGhl cmUgaXMgbm8gdW5pdmVyc2FsIHN0YW5kYXJkIGZvciBVVEMgY291bnQtb2Ytc2Vjb25kcyB0aW1l IGJlZm9yZSAxOTcwLTAxLTAxVDAwOjAwWiAodGhpcyBpcyBwYXJ0aWN1bGFybHkgdHJ1ZSBmb3Ig cG9pbnRzIGluIHRpbWUgdGhhdCBwcmVjZWRlIGRpc2NvbnRpbnVpdGllcyBpbiBuYXRpb25hbCBj YWxlbmRhcnMpLiAgW+KApl0NCg0KVGhhdCBpcyBsZXNzIG9mIGEgcHJvYmxlbSBvbiB0aGUgZGF0 ZS1vbmx5IHNpZGUgKGFzIGxvbmcgYXMgZGF0ZXMgY2hhbmdlIG9uIGxvY2FsIG1pZG5pZ2h04oCm IGFuZCBub3Qgbm9vbiksIHNvIHdlIG1heSBiZSBhYmxlIHRvIGJlIG1vcmUgc3BlY2lmaWMuDQoN Ckdyw7zDn2UsIENhcnN0ZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkNCT1IgbWFpbGluZyBsaXN0DQpDQk9SQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3INCg== From nobody Wed Mar 11 16:44:47 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 0055C3A0C38 for ; Wed, 11 Mar 2020 16:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gYjAGX3XrBu9 for ; Wed, 11 Mar 2020 16:44:43 -0700 (PDT) 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 0CC7D3A0C2F for ; Wed, 11 Mar 2020 16:44:43 -0700 (PDT) Received: from [172.16.42.113] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48d7px1RnGzyVH; Thu, 12 Mar 2020 00:44:41 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: Date: Thu, 12 Mar 2020 00:44:40 +0100 Cc: =?utf-8?B?IlJpY2h0ZXIsIErDtnJnIg==?= , "cbor@ietf.org" , Mike Jones , Anthony Nadalin X-Mao-Original-Outgoing-Id: 605663080.576508-4711138006608f5f63540ecf7d6dfb49 Content-Transfer-Encoding: quoted-printable Message-Id: <11241B9D-13A0-426A-A994-9E36EBC099F3@tzi.org> References: <282209381d8b4a8b8e77515142266df2@pdv-FS.de> <5D27981B-81C8-43C0-A229-66343D9D67B4@tzi.org> <79EDF742-2E54-4829-93F2-BE5A009734E2@tzi.org> To: Mike Jones X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Cbor] [EXTERNAL] CBOR tag for RFC 3339 full-date values 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, 11 Mar 2020 23:44:46 -0000 Hi Mike, I don=E2=80=99t mind if the outcome of the discussion is as you propose, = but I=E2=80=99d like to point out why I think the outcome I proposed is = also valid. > On 2020-03-11, at 23:10, Mike Jones = wrote: >=20 > The point of having the tag is that the code knows what follows. =20 Not quite: The code already knows "what follows=E2=80=9D (what is the = tag content) =E2=80=94 it is *right there!*. The tag allows the code to know that what follows is meant as a date. In either outcome, the code will have to check that the tag content = actually is the string that it expected. So I don=E2=80=99t think there is much of an advantage to having = different tags. (There is a slight POLS violation that tag 0 and tag 1 are separate but = there is only one tag for dates, in my preferred outcome, I have to = concede.) > If a polymorphic tag were used, in which two unrelated representations = of dates are legal, then the code doesn't know what follows. =20 (It still has to check the tag content.) > And it also opens up questions that it would be cleaner to never have = to consider - questions such as "If the polymorphic tag is adopted, must = Mobile Driver's Licenses accept both representations?" =20 The draft could be quite explicit that the answer is no (i.e., that it = is the job of the application protocol to say which of the forms can be = used). > And "Will interoperability be harmed if some Mobile Driver's Licenses = use one representation and some use the other?" (The answer to that one = is probably "Yes, interoperability will be harmed".) That would indeed be a bad outcome, so I=E2=80=99d day don=E2=80=99t do = that. > Carsten, I take your point about both integers and floats being = acceptable for tag 1. But those are closely related (numeric) = representations of the same thing. Whereas a date string versus number = of days relative to the Epoch are nearly unrelated representations, with = fairly complicated conversion rules between them (involving leap years, = leap centuries, leap 400th years, etc.). (Which is maybe a reason to use the numeric form in the driver=E2=80=99s = license, but I think that ship has sailed. And you only need the 4-year = component until 2100 :-)) > Given that J=C3=B6rg stated below that he's OK with using different = tags, I propose that we move forward with using tag 1004 (requested) for = RFC 3339 full-date values and tag char('d') (requested) for integer = number of days relative to the Epoch. If I don't hear objections soon, = I'll publish that draft. In that case, we have two separate registrations and don=E2=80=99t have = to merge the documents! (It would still be nice if they referred to each other as complementary = at some point.) If we have tag 1004, we also can simplify 100 to be numeric only (and = probably should do the same split for time-of-day later). Gr=C3=BC=C3=9Fe, Carsten >=20 > J=C3=B6rg - I'll also add you as a co-author. What affiliation and = e-mail address for you should I use? And is there a URL for a blog or = Webpage you'd also like me to include for you? >=20 > Cheers, > -- Mike >=20 > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Wednesday, March 11, 2020 2:09 PM > To: "Richter, J=C3=B6rg" > Cc: cbor@ietf.org; Mike Jones = ; Anthony Nadalin = > Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values >=20 > On 2020-03-11, at 21:31, Richter, J=C3=B6rg = wrote: >>=20 >> (Replying to more than one message here) >>=20 >> Carsten Bormann:=20 >>> Is that a good way forward? >>=20 >> I am fine with the suggested procedure.=20 >=20 > Great! >=20 >>=20 >>> What I like about Mike=E2=80=99s draft is that he references RFC = 3339, which=20 >>> already is an established specification for how to write dates=20 >>> textually >>=20 >> ISO 8601 also defines this format for dates. It is mentioned in the = "Detailed Semantics"=20 >> section of my proposal. >=20 > ISO 8601 is very =E2=80=9Cflexible=E2=80=9D. RFC 3339 uses ISO 8601, = but helps by restricting this to commonly used cases. > So I think referencing RFC 3339 is strictly better than just naked ISO = 8601. >=20 >> Mike Jones: >>> I'm fine merging J=C3=B6rg's numeric date tag into my draft, = provided that=20 >>> the result is not a polymorphic tag, in which the value could be = either a number or a string. >>> We should allocate separate tags for string date and numeric date,=20= >>> just as tags >>> 0 and 1 are different, and not polymorphic. >>=20 >> I've got the impression that using a polymorphic tag would be no = major problem. >> We can even specify that decoders might only support one = representation of the tag. >> I think it would have the same effect if a decoder supports only one = of the two tags. >> But either way I would have no objections to using two tags. >=20 > I=E2=80=99m not sure I like the term =E2=80=9Cpolymorphic=E2=80=9D = here too much =E2=80=94 in any case, the =E2=80=9Cvalue=E2=80=9D would = be a date. The content could be both text and number. Tag 1 already = does this (integer vs. floating-point), so we already have to deal with = these (i.e., allow applications to not just say =E2=80=9CTag 1=E2=80=9D, = but =E2=80=9CTag 1 with integer content=E2=80=9D). But we did separate = Tag 0 and Tag 1, mostly because the semantics of the value are subtly = different. Are they here? >=20 >> Laurence Lundblade: >>> I=E2=80=99d suggest the numeric date be restricted to integers. No = floats,=20 >>> bignums, decimal fractions=E2=80=A6 >>=20 >> Yes, that was the plan. Only major types 0 and 1.=20 >=20 > Finer granularity between dates would be times, which we already have, = so this naturally should be integers. >=20 >>> Fractions of days can be represented by tag 0 or tag 1 using hours,=20= >>> minutes, seconds. 64-bit integer counts of days are large enough. >>=20 >> This I don't understand. The proposal only handles whole days as one = number. >=20 > Right. Only full days. (The related observation is that these are = always in the local time of some context that is not expressed, which is = rather different from our time tags.) >=20 >> Another thing to consider: >> We should mention that this tag(s) use the proleptic Gregorian=20 >> calendar. So that dates before the Gregorian calendar have a unique = semantics. >=20 > Good point. In 7049bis, we just say: >=20 > Negative values (major type 1 and negative floating-point numbers) are = interpreted as determined by the application requirements as there is no = universal standard for UTC count-of-seconds time before = 1970-01-01T00:00Z (this is particularly true for points in time that = precede discontinuities in national calendars). [=E2=80=A6] >=20 > That is less of a problem on the date-only side (as long as dates = change on local midnight=E2=80=A6 and not noon), so we may be able to be = more specific. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Mar 11 19:03:32 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 038B33A112F for ; Wed, 11 Mar 2020 19:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, 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 BbYEx6cAxA7S for ; Wed, 11 Mar 2020 19:03:30 -0700 (PDT) Received: from p3plsmtpa06-02.prod.phx3.secureserver.net (p3plsmtpa06-02.prod.phx3.secureserver.net [173.201.192.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B4B3A112D for ; Wed, 11 Mar 2020 19:03:29 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id CDC4jC1LAJHZdCDC5j8tGK; Wed, 11 Mar 2020 19:03:29 -0700 X-CMAE-Analysis: v=2.3 cv=KYasTjQD c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=gKmFwSsBAAAA:8 a=fG3tKtGKH3ytwyPhRw4A:9 a=QEXdDO2ut3YA:10 a=YDy5t6Yr9p8wp1XV9_4A:9 a=I38kX-qWtSvyL0C0:21 a=_W_S_7VecoQA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <0CC4FB79-5655-4983-AD89-42DEFADD1D92@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F611B07D-2108-4FDE-8010-2E2356047729" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 11 Mar 2020 19:03:28 -0700 In-Reply-To: <79EDF742-2E54-4829-93F2-BE5A009734E2@tzi.org> Cc: =?utf-8?B?IlJpY2h0ZXIsIErDtnJnIg==?= , "cbor@ietf.org" , Mike Jones , Anthony Nadalin To: Carsten Bormann References: <282209381d8b4a8b8e77515142266df2@pdv-FS.de> <5D27981B-81C8-43C0-A229-66343D9D67B4@tzi.org> <79EDF742-2E54-4829-93F2-BE5A009734E2@tzi.org> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfE7p0qRqrFd0tOUSPLYmBNiK1lihfcuhzhFxdgBJlbl1vePADtPY4NJp+OKOS5G1npGXmI8eXuqCsxezB5OWG2F5DTvtDC0PbCzmkCCiSwx0pPdmsdEL kfTC82LKvAWjGyZJJ59kdAXYfUqmt5CmG8HxGREYYA5pKoXH9Ua0gA4Ke8y9cmzi8SGDcsH72VHOTdaLnfmUCjPhRGC/VoBkC7vNrKgEEs+azN5XfUJscRP6 WlV85Jsa6vbZ/ova+hoShBurN7OK5rFKsA5yD/VxOh4wZjE4kMITC5jDIu3uklbxAcJkojxpr6Si5KmBkRYCeg== Archived-At: Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 02:03:31 -0000 --Apple-Mail=_F611B07D-2108-4FDE-8010-2E2356047729 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 11, 2020, at 2:09 PM, Carsten Bormann wrote: >=20 >>> Fractions of days can be represented by tag 0 or tag 1 using >>> hours, minutes, seconds. 64-bit integer counts of days are large = enough. >>=20 >> This I don't understand. The proposal only handles whole days as one = number. >=20 > Right. Only full days. (The related observation is that these are = always in the local time of some context that is not expressed, which is = rather different from our time tags.) Right. If you wish to represent a fraction of a day (which is a time), = don=E2=80=99t use this tag. Use tag 0 or tag 1 that already exists to = represent a time. This tag doesn=E2=80=99t need to handle it. Same with = distant future or past. LL --Apple-Mail=_F611B07D-2108-4FDE-8010-2E2356047729 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Mar 11, 2020, at 2:09 PM, Carsten Bormann <cabo@tzi.org> = wrote:

Fractions of days can be = represented by tag 0 or tag 1 using
hours, minutes, = seconds. 64-bit integer counts of days are large enough.

This I don't understand. The = proposal only handles whole days as one number.

Right.  Only full days.  (The related observation = is that these are always in the local time of some context that is not = expressed, which is rather different from our time = tags.)

Right. If you wish to represent a fraction of a day (which is = a time), don=E2=80=99t use this tag. Use tag 0 or tag 1 that already = exists to represent a time. This tag doesn=E2=80=99t need to handle it. = Same with distant future or past.

LL

= --Apple-Mail=_F611B07D-2108-4FDE-8010-2E2356047729-- From nobody Mon Mar 16 11:52:43 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 F070B3A0F01 for ; Mon, 16 Mar 2020 11:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, 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=microsoft.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 PuxTXxeTpjWz for ; Mon, 16 Mar 2020 11:52:41 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640119.outbound.protection.outlook.com [40.107.64.119]) (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 14E313A0EFE for ; Mon, 16 Mar 2020 11:52:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z3SCYXckVT9X2+ZNSZV4TADqm6uXb7N/6o9Or8h+j1qRnaeJABAXOrTABZRpk0CEaxcsXIxwbldQaudyDBiYRBIy5iCVQZh2b7jPheivg4czS7xjLbYg9iHeiOf0pdIO9nS2BsnOpHi5w4USXhXHt37e/OV+RgO4Rr9t2+L135AFqIg+pJDtFGcxXJP5BJdPMRjUEeWVm0VTJAM69RfK35P5h/AZquy4Vu8gnLmfK/oPxqJPJxjkOIY3pMsoqm4fahb4ehSyt/1zl2f+JS8Rf0FnqkUqaYDDhG3xWA4Ny+THHCPJXSdhu6mj84mMjTxHmOOnLP3B4q+1kniiCUSz+g== 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=00kImuUz8/qJFwzmZI89XUGd/9hqaflSJk5LlLudAHo=; b=JI5gTveSJBKh67PsHRAD9iSdS3UdVecO0A/kcJEWo12PFg4RxaaI6/44U3GPPwdMfB/APBG+TQrpZYGWt6syIBxySh8VJa5bKBsfhBVcrdoi8RG63UakN8zBWkH/CVgrzQoxqg80PQqvx9z3GaSdvml9u4+ZyHz+pGWBCVx3JHzTZvuCv4gNCAc4jCdhSbbLxGaaNWQwlhQSWWL6j6LigMQrfbtsbOv3E8iw9ie8Aag5tw2hk3eCCExt9yOyIxloy4WmpTeCxJfiQcMXLDP8JocXfyPU2LQwPAoXXxdieCPIKc+qvdk2miKOimG1Z+HWrRuIpOguDM+v1+4nLJmxAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=00kImuUz8/qJFwzmZI89XUGd/9hqaflSJk5LlLudAHo=; b=X6oIGPz1sTM9eTuGu1lm6ieTk+0/+nOXXAhP6nzYl3PFBRO7AUpE9foh5EVx5dP1ybNaoxnCcJdV2dVAoCFBramJ96bhwXeBzVg2IQEio2VizKTQmJgwqOUwcdEDcc8dXSlD1CoFm71NcIurZ5jgh7L9Pmhu7pTGiVjjqi49vXQ= Received: from DM6PR00MB0684.namprd00.prod.outlook.com (2603:10b6:5:21c::8) by DM6PR00MB0816.namprd00.prod.outlook.com (2603:10b6:5:208::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2853.0; Mon, 16 Mar 2020 18:52:38 +0000 Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::6442:6f5e:972:c9f7]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::6442:6f5e:972:c9f7%6]) with mapi id 15.20.2858.000; Mon, 16 Mar 2020 18:52:38 +0000 From: Mike Jones To: =?utf-8?B?IlJpY2h0ZXIsIErDtnJnIg==?= CC: "cbor@ietf.org" , Carsten Bormann , Anthony Nadalin Thread-Topic: [Cbor] CBOR tag for RFC 3339 full-date values Thread-Index: AdX7xA8PIgFZYmMBTM6TZdKF95Ac5Q== Date: Mon, 16 Mar 2020 18:52:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=731aab9e-566c-4749-ac3a-0000f1af9fd5; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-03-11T21:56:54Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.81.134] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9d661f19-d65b-488c-7025-08d7c9db3325 x-ms-traffictypediagnostic: DM6PR00MB0816:|DM6PR00MB0816: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03449D5DD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(376002)(136003)(346002)(396003)(366004)(199004)(52536014)(10290500003)(2906002)(316002)(71200400001)(966005)(7696005)(107886003)(81156014)(6506007)(53546011)(478600001)(5660300002)(54906003)(8936002)(8676002)(86362001)(26005)(64756008)(66446008)(8990500004)(55016002)(33656002)(9686003)(4326008)(81166006)(66574012)(6916009)(76116006)(186003)(66946007)(66476007)(66556008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0816; H:DM6PR00MB0684.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 99fvHa35ddWbhBVs4tkqyW8Gx9bn7iSklii1qforyIN5h4IEqDsYcMYor/5Oj4Ev048aNbMmUa1egn/lM+WmU9734jMj0w0GyIaivZWmw3ilyWxUcSxLKiHQz1p4hmNm2RQkv4ON20pl1mmAY9tM/4guSEaZ9JY0TfcnraCG737yE9EX51UePojXZ7oe42eXeRFutkF3/ES3u6b2ucDVBoWDkKrAfQNmOsYWIhXyHRpETGufiIa4jkORmyoWjAOa98zCE6sg4gfIjVd2lmvIATSx1aDqramA34+b1Vs+/yfvXyAvpYWDV7oIlX7W0nM4S/cf32WG60UYyGbyra1jhX1bdU9mqFMGyNFDpuQIqVu+j2HrHJAk6DY6o4yuSJifVgrthjZkoeuaHaGdNS+T5LG9jqnTQa/zXxG4sYcsuPpkSGEqjUjlESMf535wsRWAdPNN8sXlsn0zuGdml0PBfNIl2UlSd8sY9rbk3fvR0am2X3hMjNg/NSJ34RL/kn3LWcpOolEUmW5Y3G8YTGCDzQ== x-ms-exchange-antispam-messagedata: 5Qdu37UlYtIvAVtgx9yfTT28BV4HHIXXZhFWXZvuSn9LWrw3Rpc5eWC+pArBHbJfBqIfNhKnWgOMT/bgtTbXomf3OUBx0Fn2aRB5381zP/4uvLWezMp6BEo9YCgDZbHdMGDdFa+Awv030lEo+Vlv9A== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9d661f19-d65b-488c-7025-08d7c9db3325 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2020 18:52:38.7903 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QTpWySMrwoaU11ZSAt8zlyDX4+p9kEBxBQ+KiHNbuSsdJ0yRQOcCUymwIcbNnXLoIZUcVhV0PjoPUqdYKixd5A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0816 Archived-At: Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 18:52:43 -0000 SsO2cmcgLSBwbGVhc2UgcmVzcG9uZCB0byBteSByZXF1ZXN0IGJlbG93IGZvciBjby1hdXRob3Ig aW5mb3JtYXRpb24uDQoNCgkJCQlUaGFua3MsDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lcz00MG1pY3Jvc29m dC5jb21AZG1hcmMuaWV0Zi5vcmc+IA0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAxMSwgMjAyMCAz OjExIFBNDQpUbzogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+OyAiUmljaHRlciwgSsO2 cmciIDxKb2VyZy5SaWNodGVyQHBkdi1GUy5kZT4NCkNjOiBjYm9yQGlldGYub3JnOyBNaWtlIEpv bmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBBbnRob255IE5hZGFsaW4gPHRvbnlu YWRAbWljcm9zb2Z0LmNvbT4NClN1YmplY3Q6IFJlOiBbQ2Jvcl0gQ0JPUiB0YWcgZm9yIFJGQyAz MzM5IGZ1bGwtZGF0ZSB2YWx1ZXMNCg0KVGhlIHBvaW50IG9mIGhhdmluZyB0aGUgdGFnIGlzIHRo YXQgdGhlIGNvZGUga25vd3Mgd2hhdCBmb2xsb3dzLiAgSWYgYSBwb2x5bW9ycGhpYyB0YWcgd2Vy ZSB1c2VkLCBpbiB3aGljaCB0d28gdW5yZWxhdGVkIHJlcHJlc2VudGF0aW9ucyBvZiBkYXRlcyBh cmUgbGVnYWwsIHRoZW4gdGhlIGNvZGUgZG9lc24ndCBrbm93IHdoYXQgZm9sbG93cy4gIEFuZCBp dCBhbHNvIG9wZW5zIHVwIHF1ZXN0aW9ucyB0aGF0IGl0IHdvdWxkIGJlIGNsZWFuZXIgdG8gbmV2 ZXIgaGF2ZSB0byBjb25zaWRlciAtIHF1ZXN0aW9ucyBzdWNoIGFzICJJZiB0aGUgcG9seW1vcnBo aWMgdGFnIGlzIGFkb3B0ZWQsIG11c3QgTW9iaWxlIERyaXZlcidzIExpY2Vuc2VzIGFjY2VwdCBi b3RoIHJlcHJlc2VudGF0aW9ucz8iICBBbmQgIldpbGwgaW50ZXJvcGVyYWJpbGl0eSBiZSBoYXJt ZWQgaWYgc29tZSBNb2JpbGUgRHJpdmVyJ3MgTGljZW5zZXMgdXNlIG9uZSByZXByZXNlbnRhdGlv biBhbmQgc29tZSB1c2UgdGhlIG90aGVyPyIgIChUaGUgYW5zd2VyIHRvIHRoYXQgb25lIGlzIHBy b2JhYmx5ICJZZXMsIGludGVyb3BlcmFiaWxpdHkgd2lsbCBiZSBoYXJtZWQiLikNCg0KQ2Fyc3Rl biwgSSB0YWtlIHlvdXIgcG9pbnQgYWJvdXQgYm90aCBpbnRlZ2VycyBhbmQgZmxvYXRzIGJlaW5n IGFjY2VwdGFibGUgZm9yIHRhZyAxLiAgQnV0IHRob3NlIGFyZSBjbG9zZWx5IHJlbGF0ZWQgKG51 bWVyaWMpIHJlcHJlc2VudGF0aW9ucyBvZiB0aGUgc2FtZSB0aGluZy4gIFdoZXJlYXMgYSBkYXRl IHN0cmluZyB2ZXJzdXMgbnVtYmVyIG9mIGRheXMgcmVsYXRpdmUgdG8gdGhlIEVwb2NoIGFyZSBu ZWFybHkgdW5yZWxhdGVkIHJlcHJlc2VudGF0aW9ucywgd2l0aCBmYWlybHkgY29tcGxpY2F0ZWQg Y29udmVyc2lvbiBydWxlcyBiZXR3ZWVuIHRoZW0gKGludm9sdmluZyBsZWFwIHllYXJzLCBsZWFw IGNlbnR1cmllcywgbGVhcCA0MDB0aCB5ZWFycywgZXRjLikuDQoNCkdpdmVuIHRoYXQgSsO2cmcg c3RhdGVkIGJlbG93IHRoYXQgaGUncyBPSyB3aXRoIHVzaW5nIGRpZmZlcmVudCB0YWdzLCBJIHBy b3Bvc2UgdGhhdCB3ZSBtb3ZlIGZvcndhcmQgd2l0aCB1c2luZyB0YWcgMTAwNCAocmVxdWVzdGVk KSBmb3IgUkZDIDMzMzkgZnVsbC1kYXRlIHZhbHVlcyBhbmQgdGFnIGNoYXIoJ2QnKSAocmVxdWVz dGVkKSBmb3IgaW50ZWdlciBudW1iZXIgb2YgZGF5cyByZWxhdGl2ZSB0byB0aGUgRXBvY2guICBJ ZiBJIGRvbid0IGhlYXIgb2JqZWN0aW9ucyBzb29uLCBJJ2xsIHB1Ymxpc2ggdGhhdCBkcmFmdC4N Cg0KSsO2cmcgLSBJJ2xsIGFsc28gYWRkIHlvdSBhcyBhIGNvLWF1dGhvci4gIFdoYXQgYWZmaWxp YXRpb24gYW5kIGUtbWFpbCBhZGRyZXNzIGZvciB5b3Ugc2hvdWxkIEkgdXNlPyAgQW5kIGlzIHRo ZXJlIGEgVVJMIGZvciBhIGJsb2cgb3IgV2VicGFnZSB5b3UnZCBhbHNvIGxpa2UgbWUgdG8gaW5j bHVkZSBmb3IgeW91Pw0KDQoJCQkJQ2hlZXJzLA0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IENCT1IgPGNib3ItYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIENhcnN0ZW4gQm9ybWFubg0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAxMSwgMjAyMCAy OjA5IFBNDQpUbzogIlJpY2h0ZXIsIErDtnJnIiA8Sm9lcmcuUmljaHRlckBwZHYtRlMuZGU+DQpD YzogY2JvckBpZXRmLm9yZzsgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5j b21AZG1hcmMuaWV0Zi5vcmc+OyBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNv bT4NClN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtDYm9yXSBDQk9SIHRhZyBmb3IgUkZDIDMzMzkg ZnVsbC1kYXRlIHZhbHVlcw0KDQpPbiAyMDIwLTAzLTExLCBhdCAyMTozMSwgUmljaHRlciwgSsO2 cmcgPEpvZXJnLlJpY2h0ZXJAcGR2LUZTLmRlPiB3cm90ZToNCj4gDQo+IChSZXBseWluZyB0byBt b3JlIHRoYW4gb25lIG1lc3NhZ2UgaGVyZSkNCj4gDQo+IENhcnN0ZW4gQm9ybWFubjogDQo+PiBJ cyB0aGF0IGEgZ29vZCB3YXkgZm9yd2FyZD8NCj4gDQo+IEkgYW0gZmluZSB3aXRoIHRoZSBzdWdn ZXN0ZWQgcHJvY2VkdXJlLiANCg0KR3JlYXQhDQoNCj4gDQo+PiBXaGF0IEkgbGlrZSBhYm91dCBN aWtl4oCZcyBkcmFmdCBpcyB0aGF0IGhlIHJlZmVyZW5jZXMgUkZDIDMzMzksIHdoaWNoIA0KPj4g YWxyZWFkeSBpcyBhbiBlc3RhYmxpc2hlZCBzcGVjaWZpY2F0aW9uIGZvciBob3cgdG8gd3JpdGUg ZGF0ZXMgDQo+PiB0ZXh0dWFsbHkNCj4gDQo+IElTTyA4NjAxIGFsc28gZGVmaW5lcyB0aGlzIGZv cm1hdCBmb3IgZGF0ZXMuIEl0IGlzIG1lbnRpb25lZCBpbiB0aGUgIkRldGFpbGVkIFNlbWFudGlj cyIgDQo+IHNlY3Rpb24gb2YgbXkgcHJvcG9zYWwuDQoNCklTTyA4NjAxIGlzIHZlcnkg4oCcZmxl eGlibGXigJ0uICBSRkMgMzMzOSB1c2VzIElTTyA4NjAxLCBidXQgaGVscHMgYnkgcmVzdHJpY3Rp bmcgdGhpcyB0byBjb21tb25seSB1c2VkIGNhc2VzLg0KU28gSSB0aGluayByZWZlcmVuY2luZyBS RkMgMzMzOSBpcyBzdHJpY3RseSBiZXR0ZXIgdGhhbiBqdXN0IG5ha2VkIElTTyA4NjAxLg0KDQo+ IE1pa2UgSm9uZXM6DQo+PiBJJ20gZmluZSBtZXJnaW5nIErDtnJnJ3MgbnVtZXJpYyBkYXRlIHRh ZyBpbnRvIG15IGRyYWZ0LCBwcm92aWRlZCB0aGF0IA0KPj4gdGhlIHJlc3VsdCBpcyBub3QgYSBw b2x5bW9ycGhpYyB0YWcsIGluIHdoaWNoIHRoZSB2YWx1ZSBjb3VsZCBiZSBlaXRoZXIgYSBudW1i ZXIgb3IgYSBzdHJpbmcuDQo+PiBXZSBzaG91bGQgYWxsb2NhdGUgc2VwYXJhdGUgdGFncyBmb3Ig c3RyaW5nIGRhdGUgYW5kIG51bWVyaWMgZGF0ZSwgDQo+PiBqdXN0IGFzIHRhZ3MNCj4+IDAgYW5k IDEgYXJlIGRpZmZlcmVudCwgYW5kIG5vdCBwb2x5bW9ycGhpYy4NCj4gDQo+IEkndmUgZ290IHRo ZSBpbXByZXNzaW9uIHRoYXQgdXNpbmcgYSBwb2x5bW9ycGhpYyB0YWcgd291bGQgYmUgbm8gbWFq b3IgcHJvYmxlbS4NCj4gV2UgY2FuIGV2ZW4gc3BlY2lmeSB0aGF0IGRlY29kZXJzIG1pZ2h0IG9u bHkgc3VwcG9ydCBvbmUgcmVwcmVzZW50YXRpb24gb2YgdGhlIHRhZy4NCj4gSSB0aGluayBpdCB3 b3VsZCBoYXZlIHRoZSBzYW1lIGVmZmVjdCBpZiBhIGRlY29kZXIgc3VwcG9ydHMgb25seSBvbmUg b2YgdGhlIHR3byB0YWdzLg0KPiBCdXQgZWl0aGVyIHdheSBJIHdvdWxkIGhhdmUgbm8gb2JqZWN0 aW9ucyB0byB1c2luZyB0d28gdGFncy4NCg0KSeKAmW0gbm90IHN1cmUgSSBsaWtlIHRoZSB0ZXJt IOKAnHBvbHltb3JwaGlj4oCdIGhlcmUgdG9vIG11Y2gg4oCUIGluIGFueSBjYXNlLCB0aGUg4oCc dmFsdWXigJ0gd291bGQgYmUgYSBkYXRlLiAgVGhlIGNvbnRlbnQgY291bGQgYmUgYm90aCB0ZXh0 IGFuZCBudW1iZXIuICBUYWcgMSBhbHJlYWR5IGRvZXMgdGhpcyAoaW50ZWdlciB2cy4gZmxvYXRp bmctcG9pbnQpLCBzbyB3ZSBhbHJlYWR5IGhhdmUgdG8gZGVhbCB3aXRoIHRoZXNlIChpLmUuLCBh bGxvdyBhcHBsaWNhdGlvbnMgdG8gbm90IGp1c3Qgc2F5IOKAnFRhZyAx4oCdLCBidXQg4oCcVGFn IDEgd2l0aCBpbnRlZ2VyIGNvbnRlbnTigJ0pLiAgQnV0IHdlIGRpZCBzZXBhcmF0ZSBUYWcgMCBh bmQgVGFnIDEsIG1vc3RseSBiZWNhdXNlIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHZhbHVlIGFyZSBz dWJ0bHkgZGlmZmVyZW50LiAgQXJlIHRoZXkgaGVyZT8NCg0KPiBMYXVyZW5jZSBMdW5kYmxhZGU6 DQo+PiBJ4oCZZCBzdWdnZXN0IHRoZSBudW1lcmljIGRhdGUgYmUgcmVzdHJpY3RlZCB0byBpbnRl Z2Vycy4gTm8gZmxvYXRzLCANCj4+IGJpZ251bXMsIGRlY2ltYWwgZnJhY3Rpb25z4oCmDQo+IA0K PiBZZXMsIHRoYXQgd2FzIHRoZSBwbGFuLiBPbmx5IG1ham9yIHR5cGVzIDAgYW5kIDEuIA0KDQpG aW5lciBncmFudWxhcml0eSBiZXR3ZWVuIGRhdGVzIHdvdWxkIGJlIHRpbWVzLCB3aGljaCB3ZSBh bHJlYWR5IGhhdmUsIHNvIHRoaXMgbmF0dXJhbGx5IHNob3VsZCBiZSBpbnRlZ2Vycy4NCg0KPj4g RnJhY3Rpb25zIG9mIGRheXMgY2FuIGJlIHJlcHJlc2VudGVkIGJ5IHRhZyAwIG9yIHRhZyAxIHVz aW5nIGhvdXJzLCANCj4+IG1pbnV0ZXMsIHNlY29uZHMuIDY0LWJpdCBpbnRlZ2VyIGNvdW50cyBv ZiBkYXlzIGFyZSBsYXJnZSBlbm91Z2guDQo+IA0KPiBUaGlzIEkgZG9uJ3QgdW5kZXJzdGFuZC4g VGhlIHByb3Bvc2FsIG9ubHkgaGFuZGxlcyB3aG9sZSBkYXlzIGFzIG9uZSBudW1iZXIuDQoNClJp Z2h0LiAgT25seSBmdWxsIGRheXMuICAoVGhlIHJlbGF0ZWQgb2JzZXJ2YXRpb24gaXMgdGhhdCB0 aGVzZSBhcmUgYWx3YXlzIGluIHRoZSBsb2NhbCB0aW1lIG9mIHNvbWUgY29udGV4dCB0aGF0IGlz IG5vdCBleHByZXNzZWQsIHdoaWNoIGlzIHJhdGhlciBkaWZmZXJlbnQgZnJvbSBvdXIgdGltZSB0 YWdzLikNCg0KPiBBbm90aGVyIHRoaW5nIHRvIGNvbnNpZGVyOg0KPiBXZSBzaG91bGQgbWVudGlv biB0aGF0IHRoaXMgdGFnKHMpIHVzZSB0aGUgcHJvbGVwdGljIEdyZWdvcmlhbiANCj4gY2FsZW5k YXIuIFNvIHRoYXQgZGF0ZXMgYmVmb3JlIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIgaGF2ZSBhIHVu aXF1ZSBzZW1hbnRpY3MuDQoNCkdvb2QgcG9pbnQuICBJbiA3MDQ5YmlzLCB3ZSBqdXN0IHNheToN Cg0KTmVnYXRpdmUgdmFsdWVzIChtYWpvciB0eXBlIDEgYW5kIG5lZ2F0aXZlIGZsb2F0aW5nLXBv aW50IG51bWJlcnMpIGFyZSBpbnRlcnByZXRlZCBhcyBkZXRlcm1pbmVkIGJ5IHRoZSBhcHBsaWNh dGlvbiByZXF1aXJlbWVudHMgYXMgdGhlcmUgaXMgbm8gdW5pdmVyc2FsIHN0YW5kYXJkIGZvciBV VEMgY291bnQtb2Ytc2Vjb25kcyB0aW1lIGJlZm9yZSAxOTcwLTAxLTAxVDAwOjAwWiAodGhpcyBp cyBwYXJ0aWN1bGFybHkgdHJ1ZSBmb3IgcG9pbnRzIGluIHRpbWUgdGhhdCBwcmVjZWRlIGRpc2Nv bnRpbnVpdGllcyBpbiBuYXRpb25hbCBjYWxlbmRhcnMpLiAgW+KApl0NCg0KVGhhdCBpcyBsZXNz IG9mIGEgcHJvYmxlbSBvbiB0aGUgZGF0ZS1vbmx5IHNpZGUgKGFzIGxvbmcgYXMgZGF0ZXMgY2hh bmdlIG9uIGxvY2FsIG1pZG5pZ2h04oCmIGFuZCBub3Qgbm9vbiksIHNvIHdlIG1heSBiZSBhYmxl IHRvIGJlIG1vcmUgc3BlY2lmaWMuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNCT1IgbWFpbGluZyBsaXN0DQpD Qk9SQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3IN Cg== From nobody Mon Mar 16 12:22:32 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 E532B3A0F68 for ; Mon, 16 Mar 2020 12:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_NONE=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 ZjuU3R_sXbJY for ; Mon, 16 Mar 2020 12:22:23 -0700 (PDT) Received: from p3plsmtpa06-02.prod.phx3.secureserver.net (p3plsmtpa06-02.prod.phx3.secureserver.net [173.201.192.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B4B3A09AD for ; Mon, 16 Mar 2020 12:22:23 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id DvJejg0O3JHZdDvJejEHFR; Mon, 16 Mar 2020 12:22:22 -0700 X-CMAE-Analysis: v=2.3 cv=KYasTjQD c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=48vgC7mUAAAA:8 a=gKmFwSsBAAAA:8 a=yMhMjlubAAAA:8 a=rSNq6B1uzVQi6kzghJkA:9 a=fpj-FYEl631FWnq0:21 a=tG4otHbj-72ldxEB:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=nnPW6aIcBuj1ljLj_o6Q:22 X-SECURESERVER-ACCT: lgl@island-resort.com 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: Mon, 16 Mar 2020 12:22:21 -0700 Cc: =?utf-8?B?IlJpY2h0ZXIsIErDtnJnIg==?= , "cbor@ietf.org" , Carsten Bormann , Anthony Nadalin Content-Transfer-Encoding: quoted-printable Message-Id: <3601F656-D758-40D5-B8A3-E86EB6A5F2B8@island-resort.com> References: To: Mike Jones X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfG07JifQEhR48L163UdXD39f04TDTZsttUUs9LmeS3le2HVJ6h8xWtD0O2G0SCffgyAPjqMzybOMD2lJAzngWLDGBSs/bs4KWOWbZT/qBVFiR122f+iP 2bXujymSHuBWSHXC+SQHdnf+i2U87EGJjlh1ozGXf/s7JMJ9xKZDi0Jvqi+2vK+SUzdCIQzSxHM5tNk+xv4wdFwSZErRCqbmVoKs04NuO+1l6tC44wSrsFSf MUIYe/bmCFPuBfe7+h+Qe1edQvDDW0hGPLO7vmYWoaRrrXCIYGhCJUoCw8Wd1zFbR+p+f0FFZkgVmR6Gaz5IaA== Archived-At: Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 19:22:30 -0000 FYI, I did a quick implementation of the single tag proposal that = Carsten made. The implementation doesn=E2=80=99t try to do conversion = from one form to the other. It just returns a string for one for and an = integer for the other. I don=E2=80=99t think it needs to do the = conversion. The implementation was done as an addition to QCBOR that = already handles tag 0 and 1. The implementation was very simple and easy. The two tag proposal that = Mike made is just as simple and easy. LL =20 > On Mar 16, 2020, at 11:52 AM, Mike Jones = wrote: >=20 > J=C3=B6rg - please respond to my request below for co-author = information. >=20 > Thanks, > -- Mike >=20 > -----Original Message----- > From: Mike Jones =20 > Sent: Wednesday, March 11, 2020 3:11 PM > To: Carsten Bormann ; "Richter, J=C3=B6rg" = > Cc: cbor@ietf.org; Mike Jones ; Anthony = Nadalin > Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values >=20 > The point of having the tag is that the code knows what follows. If a = polymorphic tag were used, in which two unrelated representations of = dates are legal, then the code doesn't know what follows. And it also = opens up questions that it would be cleaner to never have to consider - = questions such as "If the polymorphic tag is adopted, must Mobile = Driver's Licenses accept both representations?" And "Will = interoperability be harmed if some Mobile Driver's Licenses use one = representation and some use the other?" (The answer to that one is = probably "Yes, interoperability will be harmed".) >=20 > Carsten, I take your point about both integers and floats being = acceptable for tag 1. But those are closely related (numeric) = representations of the same thing. Whereas a date string versus number = of days relative to the Epoch are nearly unrelated representations, with = fairly complicated conversion rules between them (involving leap years, = leap centuries, leap 400th years, etc.). >=20 > Given that J=C3=B6rg stated below that he's OK with using different = tags, I propose that we move forward with using tag 1004 (requested) for = RFC 3339 full-date values and tag char('d') (requested) for integer = number of days relative to the Epoch. If I don't hear objections soon, = I'll publish that draft. >=20 > J=C3=B6rg - I'll also add you as a co-author. What affiliation and = e-mail address for you should I use? And is there a URL for a blog or = Webpage you'd also like me to include for you? >=20 > Cheers, > -- Mike >=20 > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Wednesday, March 11, 2020 2:09 PM > To: "Richter, J=C3=B6rg" > Cc: cbor@ietf.org; Mike Jones = ; Anthony Nadalin = > Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values >=20 > On 2020-03-11, at 21:31, Richter, J=C3=B6rg = wrote: >>=20 >> (Replying to more than one message here) >>=20 >> Carsten Bormann:=20 >>> Is that a good way forward? >>=20 >> I am fine with the suggested procedure.=20 >=20 > Great! >=20 >>=20 >>> What I like about Mike=E2=80=99s draft is that he references RFC = 3339, which=20 >>> already is an established specification for how to write dates=20 >>> textually >>=20 >> ISO 8601 also defines this format for dates. It is mentioned in the = "Detailed Semantics"=20 >> section of my proposal. >=20 > ISO 8601 is very =E2=80=9Cflexible=E2=80=9D. RFC 3339 uses ISO 8601, = but helps by restricting this to commonly used cases. > So I think referencing RFC 3339 is strictly better than just naked ISO = 8601. >=20 >> Mike Jones: >>> I'm fine merging J=C3=B6rg's numeric date tag into my draft, = provided that=20 >>> the result is not a polymorphic tag, in which the value could be = either a number or a string. >>> We should allocate separate tags for string date and numeric date,=20= >>> just as tags >>> 0 and 1 are different, and not polymorphic. >>=20 >> I've got the impression that using a polymorphic tag would be no = major problem. >> We can even specify that decoders might only support one = representation of the tag. >> I think it would have the same effect if a decoder supports only one = of the two tags. >> But either way I would have no objections to using two tags. >=20 > I=E2=80=99m not sure I like the term =E2=80=9Cpolymorphic=E2=80=9D = here too much =E2=80=94 in any case, the =E2=80=9Cvalue=E2=80=9D would = be a date. The content could be both text and number. Tag 1 already = does this (integer vs. floating-point), so we already have to deal with = these (i.e., allow applications to not just say =E2=80=9CTag 1=E2=80=9D, = but =E2=80=9CTag 1 with integer content=E2=80=9D). But we did separate = Tag 0 and Tag 1, mostly because the semantics of the value are subtly = different. Are they here? >=20 >> Laurence Lundblade: >>> I=E2=80=99d suggest the numeric date be restricted to integers. No = floats,=20 >>> bignums, decimal fractions=E2=80=A6 >>=20 >> Yes, that was the plan. Only major types 0 and 1.=20 >=20 > Finer granularity between dates would be times, which we already have, = so this naturally should be integers. >=20 >>> Fractions of days can be represented by tag 0 or tag 1 using hours,=20= >>> minutes, seconds. 64-bit integer counts of days are large enough. >>=20 >> This I don't understand. The proposal only handles whole days as one = number. >=20 > Right. Only full days. (The related observation is that these are = always in the local time of some context that is not expressed, which is = rather different from our time tags.) >=20 >> Another thing to consider: >> We should mention that this tag(s) use the proleptic Gregorian=20 >> calendar. So that dates before the Gregorian calendar have a unique = semantics. >=20 > Good point. In 7049bis, we just say: >=20 > Negative values (major type 1 and negative floating-point numbers) are = interpreted as determined by the application requirements as there is no = universal standard for UTC count-of-seconds time before = 1970-01-01T00:00Z (this is particularly true for points in time that = precede discontinuities in national calendars). [=E2=80=A6] >=20 > That is less of a problem on the date-only side (as long as dates = change on local midnight=E2=80=A6 and not noon), so we may be able to be = more specific. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > 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 Mon Mar 16 12:33: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 C0B823A0FB5 for ; Mon, 16 Mar 2020 12:33:28 -0700 (PDT) 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 5EZau1ihUhOF for ; Mon, 16 Mar 2020 12:33:26 -0700 (PDT) Received: from mail.pdv-fs.de (mail.pdv-fs.de [213.208.220.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ADA93A0F9E for ; Mon, 16 Mar 2020 12:33:25 -0700 (PDT) Received: from mail.pdv-fs.de (unknown [192.168.180.94]) by mail.pdv-fs.de (Postfix) with ESMTPS; Mon, 16 Mar 2020 20:33:23 +0100 (CET) Received: from EXCHDB1.pdv-fs.de (192.168.180.94) by EXCHDB1.pdv-fs.de (192.168.180.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 16 Mar 2020 20:33:23 +0100 Received: from EXCHDB1.pdv-fs.de ([fe80::6c4a:8b1b:60f4:4437]) by EXCHDB1.pdv-fs.de ([fe80::6c4a:8b1b:60f4:4437%15]) with mapi id 15.01.1913.007; Mon, 16 Mar 2020 20:33:23 +0100 From: =?Windows-1252?Q?Richter=2C_J=F6rg?= To: Mike Jones CC: "cbor@ietf.org" , Carsten Bormann , "Anthony Nadalin" Thread-Topic: [Cbor] CBOR tag for RFC 3339 full-date values Thread-Index: AQHV+8QSHPhfqRAmEUORL/XuRcFM+6hLmzAJ Date: Mon, 16 Mar 2020 19:33:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.185.1] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TMASE-Version: DDEI-3.5-8.5.1020-25296.002 X-TMASE-Result: 10--24.129900-10.000000 X-TMASE-MatchedRID: CBwTv/eNPl1JJDuM6qazTguLP4ROdWHVNV9S7O+u3KZ5xaVclJA5pb7I tozLGgGlz+wn3hu4AlZAZoZQH6vhA6Q6DGKWa7RZdZnGxcSCdeUqnZ5Ugk1IN2LSWlSXv8Cxrp5 /D2DsKbHNcmM6OYlLQKNYj4CoIiwd8S2p7ncUaFFDXSxqBHb4QR+3R3jwh6/fDO+DX+rUwfYJip B2cm6VKALKc+DLigYD92Z/EZ/JdbNp71qAvI563rzgL/eLACDEKOMMBwapUb5tgcjFQCPmSNi+A YIN6VlPWTck9+zY4l27BPS56m6SB/HHEVq7BUCQJ2be3zx+/IVp6KLIpjpTXChaT4eu9QAgMGRd yGJR2sZzti1eMwy1U2itnBG1/u/BtKLr0dxeQcA+Cy4l41tPqB+26QzoWaY28CWGWvy/Nx3hy2M UPlhPvXmBme6xafzsgPnQDZLxtV7IdzimPvNHQe5b8GtgkaX9er1wlVoR6TQAjiw/nJICh361GO XdgI9Dz+mxSdqUNTPP80InLliIEghV0mWPUAie9Ib/6w+1lWR+S5m2/8VLmoTiscmlKoiZCKI67 N2qKSE+RzON45L4PrXN8ZtrUQp9wtOA1g8gH4VJkkUW0nPbN323AkKVZZKXj6Xh9k1IeO5RLTER hRg1gwLHfojINhZ0uv6ZDJWKxT7uYyJZe8HYSyqRJ4M9q7OvAgvM6h73BtoUvn93ewYigic5aFl jLyodDneCuLmjO/ujwmyFuKKBZLnhJyMNIAe2ZdorcofH/GnAGLyVFMzIGph4xM9oAcst5DRgxA FJ8l4mR2E80MK2vbFoL8xCnnbhWyJsG/DniGKeAiCmPx4NwMHGqwpJzOMi9yEa3tvzanYXeuQCq Ixled934/rDAK3zUc1+O1X9AzE= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 X-TMASE-INERTIA: 1-0;;J4gzHMCxkPyYUJl0x8cA1w==;; Archived-At: Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 19:33:29 -0000 > J=F6rg - I'll also add you as a co-author. What affiliation and e-mail a= ddress for you should I use? And is there a URL for a blog or Webpage you'= d also like me to include for you? Sorry, I missed this one. You can use joerg.richter@pdv-fs.de (pdv Financial Software GmbH). I got no= blog or webpage. Thanks, - J=F6rg ________________________________________ Von: Mike Jones Gesendet: Montag, 16. M=E4rz 2020 19:52:38 An: Richter, J=F6rg Cc: cbor@ietf.org; Carsten Bormann; Anthony Nadalin Betreff: Re: [Cbor] CBOR tag for RFC 3339 full-date values J=F6rg - please respond to my request below for co-author information. Thanks, -- Mike -----Original Message----- From: Mike Jones Sent: Wednesday, March 11, 2020 3:11 PM To: Carsten Bormann ; "Richter, J=F6rg" Cc: cbor@ietf.org; Mike Jones ; Anthony Nadali= n Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values The point of having the tag is that the code knows what follows. If a poly= morphic tag were used, in which two unrelated representations of dates are = legal, then the code doesn't know what follows. And it also opens up quest= ions that it would be cleaner to never have to consider - questions such as= "If the polymorphic tag is adopted, must Mobile Driver's Licenses accept b= oth representations?" And "Will interoperability be harmed if some Mobile = Driver's Licenses use one representation and some use the other?" (The ans= wer to that one is probably "Yes, interoperability will be harmed".) Carsten, I take your point about both integers and floats being acceptable = for tag 1. But those are closely related (numeric) representations of the = same thing. Whereas a date string versus number of days relative to the Ep= och are nearly unrelated representations, with fairly complicated conversio= n rules between them (involving leap years, leap centuries, leap 400th year= s, etc.). Given that J=F6rg stated below that he's OK with using different tags, I pr= opose that we move forward with using tag 1004 (requested) for RFC 3339 ful= l-date values and tag char('d') (requested) for integer number of days rela= tive to the Epoch. If I don't hear objections soon, I'll publish that draf= t. J=F6rg - I'll also add you as a co-author. What affiliation and e-mail add= ress for you should I use? And is there a URL for a blog or Webpage you'd = also like me to include for you? Cheers, -- Mike -----Original Message----- From: CBOR On Behalf Of Carsten Bormann Sent: Wednesday, March 11, 2020 2:09 PM To: "Richter, J=F6rg" Cc: cbor@ietf.org; Mike Jones ; Anthony Nadalin Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values On 2020-03-11, at 21:31, Richter, J=F6rg wrote: > > (Replying to more than one message here) > > Carsten Bormann: >> Is that a good way forward? > > I am fine with the suggested procedure. Great! > >> What I like about Mike=92s draft is that he references RFC 3339, which >> already is an established specification for how to write dates >> textually > > ISO 8601 also defines this format for dates. It is mentioned in the "Deta= iled Semantics" > section of my proposal. ISO 8601 is very =93flexible=94. RFC 3339 uses ISO 8601, but helps by rest= ricting this to commonly used cases. So I think referencing RFC 3339 is strictly better than just naked ISO 8601= . > Mike Jones: >> I'm fine merging J=F6rg's numeric date tag into my draft, provided that >> the result is not a polymorphic tag, in which the value could be either = a number or a string. >> We should allocate separate tags for string date and numeric date, >> just as tags >> 0 and 1 are different, and not polymorphic. > > I've got the impression that using a polymorphic tag would be no major pr= oblem. > We can even specify that decoders might only support one representation o= f the tag. > I think it would have the same effect if a decoder supports only one of t= he two tags. > But either way I would have no objections to using two tags. I=92m not sure I like the term =93polymorphic=94 here too much =97 in any c= ase, the =93value=94 would be a date. The content could be both text and n= umber. Tag 1 already does this (integer vs. floating-point), so we already= have to deal with these (i.e., allow applications to not just say =93Tag 1= =94, but =93Tag 1 with integer content=94). But we did separate Tag 0 and = Tag 1, mostly because the semantics of the value are subtly different. Are= they here? > Laurence Lundblade: >> I=92d suggest the numeric date be restricted to integers. No floats, >> bignums, decimal fractions=85 > > Yes, that was the plan. Only major types 0 and 1. Finer granularity between dates would be times, which we already have, so t= his naturally should be integers. >> Fractions of days can be represented by tag 0 or tag 1 using hours, >> minutes, seconds. 64-bit integer counts of days are large enough. > > This I don't understand. The proposal only handles whole days as one numb= er. Right. Only full days. (The related observation is that these are always = in the local time of some context that is not expressed, which is rather di= fferent from our time tags.) > Another thing to consider: > We should mention that this tag(s) use the proleptic Gregorian > calendar. So that dates before the Gregorian calendar have a unique seman= tics. Good point. In 7049bis, we just say: Negative values (major type 1 and negative floating-point numbers) are inte= rpreted as determined by the application requirements as there is no univer= sal standard for UTC count-of-seconds time before 1970-01-01T00:00Z (this i= s particularly true for points in time that precede discontinuities in nati= onal calendars). [=85] That is less of a problem on the date-only side (as long as dates change on= local midnight=85 and not noon), so we may be able to be more specific. Gr=FC=DFe, Carsten _______________________________________________ CBOR mailing list CBOR@ietf.org https://www.ietf.org/mailman/listinfo/cbor From nobody Tue Mar 17 01:18:00 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 08D6B3A1A6C for ; Tue, 17 Mar 2020 01:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Osyj8O6mQZmG for ; Tue, 17 Mar 2020 01:17:55 -0700 (PDT) Received: from sjmda13.webex.com (sjmda13.webex.com [64.68.124.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1293A1AB5 for ; Tue, 17 Mar 2020 01:17:55 -0700 (PDT) Received: from rva2rmd101.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda13.webex.com (Postfix) with ESMTP id 2C4FA300DB8D for ; Tue, 17 Mar 2020 08:17:54 +0000 (GMT) Received: from rva2rmd101.webex.com (localhost [127.0.0.1]) by rva2rmd101.webex.com (Postfix) with ESMTP id D23A3102289F for ; Tue, 17 Mar 2020 08:17:53 +0000 (GMT) Date: Tue, 17 Mar 2020 08:17:53 +0000 (GMT) From: CBOR Working Group Reply-To: cbor-chairs@ietf.org To: cbor@ietf.org Message-ID: <627744896.875371584433073860.JavaMail.nobody@rva2rmd101.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_175062_541030867.1584433073860" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=155948703787527787, X-WBX-TID=2fg4je28fyq1i01jp4pys80sdbr7o8evmgxljgwfpah3jazirxorld83, X-WBX-RID=fc58aa5f32464f7fb204bda5c7eec57e, X-WBX-SVC:Meeting Center, X-WBX-TT:Meeting Invitation, Date:Tue Mar 17 08:17:53 GMT 2020 reminder-40.1.1-4 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: Tue, 17 Mar 2020 08:17:57 -0000 ------=_Part_175062_541030867.1584433073860 Content-Type: multipart/Alternative; boundary="----=_Part_175063_1778916515.1584433073860" ------=_Part_175063_1778916515.1584433073860 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhpLCBjYm9yQGlldGYub3JnLAoKQ0JPUiBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpv aW4gdGhpcyBXZWJleCBtZWV0aW5nLgoKCkNCT1Igd29ya2luZyBncm91cCBjb25mZXJlbmNlIGNh bGwKT2NjdXJzIGV2ZXJ5IDIgd2VlayhzKSBvbiBXZWRuZXNkYXkgZWZmZWN0aXZlIFdlZG5lc2Rh eSwgQXByaWwgOCwgMjAyMCB1bnRpbCBXZWRuZXNkYXksIEp1bHkgMTUsIDIwMjAgZnJvbSA1OjAw IFBNIHRvIDY6MDAgUE0sIChVVEMrMDE6MDApIEFtc3RlcmRhbSwgQmVybGluLCBCZXJuLCBSb21l LCBTdG9ja2hvbG0sIFZpZW5uYQo1OjAwIHBtICB8ICAoVVRDKzAxOjAwKSBBbXN0ZXJkYW0sIEJl cmxpbiwgQmVybiwgUm9tZSwgU3RvY2tob2xtLCBWaWVubmEgIHwgIDEgaHIKTWVldGluZyBudW1i ZXIgKGFjY2VzcyBjb2RlKTogNjQ3IDgzNiA0MjAgCk1lZXRpbmcgcGFzc3dvcmQ6IGVtSHJpZ0My Mks0CgoKCldoZW4gaXQncyB0aW1lLCBqb2luIHRoZSBtZWV0aW5nLgpodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tNWRiNTNhZDg1MDI0NGUyNWZjZWNmMTBjMzBhMWE4MTEK CkFkZCB0byBDYWxlbmRhcgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1t OTMyNDU1NDcwYmFmZjA4Y2U0YWNkNThiMTQ4NzNjM2QNCg0KCgoNCkpPSU4gQlkgUEhPTkUNCjEt NjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkKVGFwIGhlcmUgdG8g Y2FsbCAobW9iaWxlIHBob25lcyBvbmx5LCBob3N0cyBub3Qgc3VwcG9ydGVkKTogdGVsOiUyQjEt NjUwLTQ3OS0zMjA4LCwqMDEqNjQ3ODM2NDIwJTIzJTIzKjAxKgoNCg0KCkpPSU4gRlJPTSBBIFZJ REVPIFNZU1RFTSBPUiBBUFBMSUNBVElPTgpEaWFsIHNpcDo2NDc4MzY0MjBAaWV0Zi53ZWJleC5j b20KWW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcg bnVtYmVyLgoKCkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZv ciBCdXNpbmVzcwpEaWFsIHNpcDo2NDc4MzY0MjAuaWV0ZkBseW5jLndlYmV4LmNvbQoKCkNhbid0 IGpvaW4gdGhlIG1lZXRpbmc/Cmh0dHBzOi8vY29sbGFib3JhdGlvbmhlbHAuY2lzY28uY29tL2Fy dGljbGUvV0JYMDAwMDI5MDU1CgoKSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0 aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50 IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVy YWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRv bWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNl bnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0 IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLgo= ------=_Part_175063_1778916515.1584433073860 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 ICAgICAgICAgICAgIE1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0NyA4MzYgNDIwCiAg ICAgICAgICAgIDwvdGQ+CiAgICAgICAgPC90cj4KICAgIDwvdGFibGU+CiAgICA8dGFibGUgc3R5 bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50Ij4KICAgICAgICA8dHIgPgogICAg ICAgICAgICA8dGQgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6ICMwMDAwMDA7IGZv bnQtc2l6ZTogMTZweDsgbGluZS1oZWlnaHQ6IDIycHg7Ij5NZWV0aW5nIHBhc3N3b3JkOiBlbUhy aWdDMjJLNDwvdGQ+CiAgICAgICAgPC90cj4KICAgIDwvdGFibGU+CiAgICAgICAgCjx0YWJsZT48 dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5i c3A7PC90ZD48L3RyPjwvdGFibGU+CgogICAgPHRhYmxlICB3aWR0aD0iMTAwJSI+CiAgICAgICAg PHRyIHN0eWxlPSJtYXJnaW46MHB4O2NvbG9yOiAjNjY2NjY2O2ZvbnQtZmFtaWx5OiBBcmlhbDtm b250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDIycHg7Ij4KICAgICAgICAgICAgPHRkIHN0eWxl PSJtYXJnaW46MHB4O2NvbG9yOiAjNjY2NjY2O2ZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6 IDE0cHg7bGluZS1oZWlnaHQ6IDIycHg7Ij5PY2N1cnMgZXZlcnkgMiB3ZWVrKHMpIG9uIFdlZG5l c2RheSBlZmZlY3RpdmUgV2VkbmVzZGF5LCBBcHJpbCA4LCAyMDIwIHVudGlsIFdlZG5lc2RheSwg SnVseSAxNSwgMjAyMCBmcm9tIDU6MDAgUE0gdG8gNjowMCBQTSwgKFVUQyswMTowMCkgQW1zdGVy ZGFtLCBCZXJsaW4sIEJlcm4sIFJvbWUsIFN0b2NraG9sbSwgVmllbm5hCiAgICAgICAgICAgIDwv dGQ+CiAgICAgICAgPC90cj4KICAgICAgICA8dHIgc3R5bGU9Im1hcmdpbjowcHg7Y29sb3I6ICM2 NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjJw eDsiPgogICAgICAgICAgICA8dGQgc3R5bGU9Im1hcmdpbjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9u dC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjJweDsiPjU6MDAg cG0mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7KFVUQyswMTowMCkgQW1zdGVyZGFtLCBCZXJsaW4s IEJlcm4sIFJvbWUsIFN0b2NraG9sbSwgVmllbm5hJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzEg aHIKICAgICAgICAgICAgPC90ZD4KICAgICAgICA8L3RyPgogICAgPC90YWJsZT4KCiA8Rk9OVCBz aXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9O VD4KCiAgICAKCgkJCTx0YWJsZSBzdHlsZT0icGFkZGluZy1ib3R0b206IDRweDtmb250LWZhbWls eTogQXJpYWw7Ij48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdo dDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJPHRhYmxlIHN0eWxlPSd3aWR0aDph dXRvO3dpZHRoOmF1dG8haW1wb3J0YW50Oyc+PHRyPjx0ZCBzdHlsZT0nd2lkdGg6YXV0byFpbXBv cnRhbnQ7ICc+PHRhYmxlIGJvcmRlcj0nMCcgY2VsbHBhZGRpbmc9JzAnIGNlbGxzcGFjaW5nPScw JyBzdHlsZT0nd2lkdGg6YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDsgYmFja2dyb3VuZC1jb2xv cjojNDNBOTQyOyBib3JkZXI6MHB4IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjBweDsg bWluLXdpZHRoOjE2MHB4IWltcG9ydGFudDsnPjx0Ym9keT48dHI+PHRkIGFsaWduPSdjZW50ZXIn IHN0eWxlPSdwYWRkaW5nOjEwcHggMzZweDtmb250LWZhbWlseTogQXJpYWw7Jz48YSBocmVmPSdo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tNWRiNTNhZDg1MDI0NGUyNWZj ZWNmMTBjMzBhMWE4MTEnIHN0eWxlPSdjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4 dC1kZWNvcmF0aW9uOm5vbmU7Jz5Kb2luIG1lZXRpbmc8L2E+PC90ZD48L3RyPjwvdGJvZHk+PC90 YWJsZT48L3RkPjwvdHI+PC90YWJsZT4KCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6 IDQ4cHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjQ4cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoK Cgk8dGFibGU+PHRib2R5Pjx0cj48dGQgc3R5bGU9ImNvbG9yOiAjMDAwMDAwO2ZvbnQtZmFtaWx5 OiBBcmlhbDsgZm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6 IDI0cHg7Ij48Yj5Kb2luIGJ5IHBob25lPC9iPjwvdGQ+PC90cj48dHI+PHRkIHN0eWxlPSJjb2xv cjogIzk5OTk5OTtmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWln aHQ6IDI0cHg7Ij5UYXAgdG8gY2FsbCBpbiBmcm9tIGEgbW9iaWxlIGRldmljZSAoYXR0ZW5kZWVz IG9ubHkpPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjog IzMzMzMzMztmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAy NHB4OyI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQ3ODM2NDIwJTIzJTIz KjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29yYXRpb246bm9uZTsgZm9udC1m YW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjRweDsnPjEtNjUwLTQ3 OS0zMjA4PC9hPiZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsiPkNhbGwtaW4gdG9s bCBudW1iZXIgKFVTL0NhbmFkYSk8L3NwYW4+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBw eCI+PHRkIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVp Z2h0OiAyNHB4OyI+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48dGFibGUgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIwIj48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyOHB4OyI+PHRkIHN0 eWxlPSJoZWlnaHQ6MjhweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+Cgk8dGFibGU+PHRyPjx0 ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAx MnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIGZyb20g YSB2aWRlbyBzeXN0ZW0gb3IgYXBwbGljYXRpb248L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFy Z2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBm b250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjY0 NzgzNjQyMEBpZXRmLndlYmV4LmNvbSIgICBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29s b3I6IzAwQUZGOSI+NjQ3ODM2NDIwQGlldGYud2ViZXguY29tPC9hPjwvdGQ+PC90cj48dHIgc3R5 bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7IGZvbnQtZmFtaWx5OiBB cmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPllvdSBjYW4gYWxzbyBk aWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L3RkPjwvdHI+ PC90YWJsZT48dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0i aGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgogICAgPHRhYmxlIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRyPjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBm b250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGlu ZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29m dCBTa3lwZSBmb3IgQnVzaW5lc3M8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+ PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6 IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjY0NzgzNjQyMC5p ZXRmQGx5bmMud2ViZXguY29tIiAgIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjoj MDBBRkY5Ij42NDc4MzY0MjAuaWV0ZkBseW5jLndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90YWJs ZT4KCgkJCTx0YWJsZSBzdHlsZT0id2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1h aW4iPgogICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDcycHgiPjx0ZD4mbmJzcDs8 L3RkPjwvdHI+CgkJCQk8dHI+CgkJCQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7IGNvbG9yOiAj MDAwMDAwOyBmb250LWZhbWlseTpBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDog MjRweDsiPk5lZWQgaGVscD8gR28gdG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2ViZXguY29tIiBz dHlsZT0iY29sb3I6IzA0OUZEOTsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRwOi8vaGVscC53 ZWJleC5jb208L2E+CgkJCQkJPC90ZD4KCQkJCTwvdHI+CiAgICAgICAgICAgICAgICA8dHIgc3R5 bGU9ImhlaWdodDogNDRweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj4KCQkJPC90YWJsZT4KCQk8L3Rk PgoJPC90cj4KPC90YWJsZT4K ------=_Part_175063_1778916515.1584433073860 Content-Type: text/calendar;method=REQUEST;charset=utf-8; Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkV1cm9wZS9BbXN0ZXJkYW0NClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9FdXJvcGUvQW1zdGVyZGFtDQpYLUxJQy1MT0NBVElPTjpFdXJvcGUvQW1z dGVyZGFtDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9GRlNFVFRPOisw MjAwDQpUWk5BTUU6Q0VTVA0KRFRTVEFSVDoxOTcwMDMyOVQwMjAwMDANClJSVUxFOkZSRVE9WUVB UkxZO0JZTU9OVEg9MztCWURBWT0tMVNVDQpFTkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpU Wk9GRlNFVEZST006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClRaTkFNRTpDRVQNCkRUU1RBUlQ6 MTk3MDEwMjVUMDMwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTEwO0JZREFZPS0xU1UN CkVORDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAw MzE3VDA4MTc1M1oNCkFUVEVOREVFO0NOPSJjYm9yQGlldGYub3JnIjtST0xFPVJFUS1QQVJUSUNJ UEFOVDtSU1ZQPVRSVUU6TUFJTFRPOmNib3JAaWV0Zi5vcmcNCk9SR0FOSVpFUjtDTj0iQ0JPUiBX b3JraW5nIEdyb3VwIjpNQUlMVE86Y2Jvci1jaGFpcnNAaWV0Zi5vcmcNCkRUU1RBUlQ7VFpJRD1F dXJvcGUvQW1zdGVyZGFtOjIwMjAwNDA4VDE3MDAwMA0KRFRFTkQ7VFpJRD1FdXJvcGUvQW1zdGVy ZGFtOjIwMjAwNDA4VDE4MDAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm L2oucGhwP01USUQ9bTVkYjUzYWQ4NTAyNDRlMjVmY2VjZjEwYzMwYTFhODExDQpUUkFOU1A6T1BB UVVFDQpTRVFVRU5DRToxNTg0NDMzMDczDQpVSUQ6YWRjNzJjNDAtOTQ5MC00NWRkLWJmN2EtZjIx MDVjZmM1OThiDQpERVNDUklQVElPTjpcblxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTVkYjUzYWQ4NTAyNDRlMjVmY2VjZjEw YzMwYTFhODExXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDcgODM2IDQyMFxuXG5c bk1lZXRpbmcgcGFzc3dvcmQ6IGVtSHJpZ0MyMks0XG5cblxuXG5KT0lOIEJZIFBIT05FXG4xLTY1 MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0byBj YWxsIChtb2JpbGUgcGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJCMS02 NTAtNDc5LTMyMDgsLCowMSo2NDc4MzY0MjAlMjMlMjMqMDEqXG5cblxuXG5KT0lOIEZST00gQSBW SURFTyBTWVNURU0gT1IgQVBQTElDQVRJT05cbkRpYWwgc2lwOjY0NzgzNjQyMEBpZXRmLndlYmV4 LmNvbVxuWW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRp bmcgbnVtYmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNr eXBlIGZvciBCdXNpbmVzc1xuRGlhbCBzaXA6NjQ3ODM2NDIwLmlldGZAbHluYy53ZWJleC5jb21c blxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25oZWxw LmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBs ZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIg aW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNo IG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBz ZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYg eW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2Vy bnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQtREVT QztGTVRUWVBFPXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxuKiB7XG4gICAgcGFk ZGluZzogMDsgICAgbWFyZ2luOiAwO31cbnRhYmxlIHtcbglib3JkZXItY29sbGFwc2U6IHNlcGFy YXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2luZzogMDt9XG5cbnRyIHtc bglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRkIHtcbglmb250LXNpemU6IDE0cHg7CWZvbnQt ZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1i cmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxuLnRpdGxlIHtcbglmb250LXNpemU6IDI4cHg7 fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwltYXgtd2lkdGg6IGF1dG87fVxuXG4uZm9vdGVy IHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7XG5cbn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4 LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0bGUge1xuCQlmb250LXNpemU6IDIycHggIWlt cG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRoOiBhdXRvICFpbXBvcnRhbnQ7CQltYXgtd2lk dGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290ZXIge1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0 YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxuCS5tYWluIHtcbgkJd2lkdGg6 IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbn1cbjwv c3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFy Z2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiPlxuCTx0ciBzdHls ZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCTx0cj5cbgkJPHRkIGFsaWdu PSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAiPlxuCQkJPCEtLTx0YWJs ZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7IHdpZHRoOiAxMDAlOyBwYWRk aW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBhbGlnbj0ibGVmdCIgY2xhc3M9 Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+ Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPi0tPlxuXG5cblxuXG5cbgkJ CTx0YWJsZT5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjQiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+V2hlbiBpdCdzIHRpbWUsIGpvaW4gdGhlIFdlYmV4IG1l ZXRpbmcgaGVyZS48L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCQk8dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48 L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDcgODM2 IDQyMDwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT5cbgkJCVxuCQkJ PHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5lbUhyaWdDMjJLNDwvRk9OVD48L3RkPjwvdHI+PC90YWJs ZT5cblxuICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAy MHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPHRyPlxu CQkJCTx0ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4JCQkJCTx0YWJsZSBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5bGU9IndpZHRoOmF1dG87 d2lkdGg6YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNBOTQyOyBib3JkZXI6MHB4 IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdpZHRoOjE2MHB4IWltcG9y dGFudDsiPlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiBzdHlsZT0icGFk ZGluZzoxMHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5w aHA/TVRJRD1tNWRiNTNhZDg1MDI0NGUyNWZjZWNmMTBjMzBhMWE4MTEiIHN0eWxlPSJjb2xvcjoj RkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5Kb2luIG1lZXRp bmc8L2E+PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4JCQkJPC90ZD5cbgkJCTwv dHI+XG4JCTwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFM Ij4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSI0 IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij5Kb2luIGJ5IHBob25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+PGI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwq MDEqNjQ3ODM2NDIwJTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29y YXRpb246bm9uZTsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdo dDogMjRweDsnPjEtNjUwLTQ3OS0zMjA4PC9hPjwvYj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMv Q2FuYWRhKTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48QlI+XG5cbjx0YWJsZT48dHIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpF PSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gZnJvbSBhIHZpZGVvIHN5c3Rl bSBvciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVmPSJzaXA6NjQ3ODM2NDIwQGlldGYud2Vi ZXguY29tIj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPjY0Nzgz NjQyMEBpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42 OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05U PiZuYnNwOyA8QlI+XG5cbjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0 cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiB1 c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPC9iPjwv dGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7 IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsi PkRpYWwgPGEgaHJlZj0iIHNpcDo2NDc4MzY0MjAuaWV0ZkBseW5jLndlYmV4LmNvbSIgICBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOSI+NjQ3ODM2NDIwLmlldGZAbHlu Yy53ZWJleC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+XG5cbgkJCTx0YWJsZSBzdHlsZT0id2lk dGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0 ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJ CQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpB cmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28g dG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2ViZXguY29tIiBzdHlsZT0iY29sb3I6IzA0OUZEOTsg dGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRwOi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwv dGQ+XG4JCQkJPC90cj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+ PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwvdGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFi bGU+XG4NClNVTU1BUlk6Q0JPUiB3b3JraW5nIGdyb3VwIGNvbmZlcmVuY2UgY2FsbA0KUFJJT1JJ VFk6NQ0KQ0xBU1M6UFVCTElDDQpSUlVMRTpGUkVRPVdFRUtMWTtXS1NUPVNVO1VOVElMPTIwMjAw NzE1O0lOVEVSVkFMPTI7QllEQVk9V0UNCkJFR0lOOlZBTEFSTQ0KVFJJR0dFUjotUFQ1TQ0KQUNU SU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9OOlJlbWluZGVyDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5U DQpFTkQ6VkNBTEVOREFSDQo= ------=_Part_175063_1778916515.1584433073860-- ------=_Part_175062_541030867.1584433073860 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkV1cm9wZS9BbXN0ZXJkYW0NClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9FdXJvcGUvQW1zdGVyZGFtDQpYLUxJQy1MT0NBVElPTjpFdXJvcGUvQW1z dGVyZGFtDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9GRlNFVFRPOisw MjAwDQpUWk5BTUU6Q0VTVA0KRFRTVEFSVDoxOTcwMDMyOVQwMjAwMDANClJSVUxFOkZSRVE9WUVB UkxZO0JZTU9OVEg9MztCWURBWT0tMVNVDQpFTkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpU Wk9GRlNFVEZST006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClRaTkFNRTpDRVQNCkRUU1RBUlQ6 MTk3MDEwMjVUMDMwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTEwO0JZREFZPS0xU1UN CkVORDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAw MzE3VDA4MTc1M1oNCkFUVEVOREVFO0NOPSJjYm9yQGlldGYub3JnIjtST0xFPVJFUS1QQVJUSUNJ UEFOVDtSU1ZQPVRSVUU6TUFJTFRPOmNib3JAaWV0Zi5vcmcNCk9SR0FOSVpFUjtDTj0iQ0JPUiBX b3JraW5nIEdyb3VwIjpNQUlMVE86Y2Jvci1jaGFpcnNAaWV0Zi5vcmcNCkRUU1RBUlQ7VFpJRD1F dXJvcGUvQW1zdGVyZGFtOjIwMjAwNDA4VDE3MDAwMA0KRFRFTkQ7VFpJRD1FdXJvcGUvQW1zdGVy ZGFtOjIwMjAwNDA4VDE4MDAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm L2oucGhwP01USUQ9bTVkYjUzYWQ4NTAyNDRlMjVmY2VjZjEwYzMwYTFhODExDQpUUkFOU1A6T1BB UVVFDQpTRVFVRU5DRToxNTg0NDMzMDczDQpVSUQ6YWRjNzJjNDAtOTQ5MC00NWRkLWJmN2EtZjIx MDVjZmM1OThiDQpERVNDUklQVElPTjpcblxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTVkYjUzYWQ4NTAyNDRlMjVmY2VjZjEw YzMwYTFhODExXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDcgODM2IDQyMFxuXG5c bk1lZXRpbmcgcGFzc3dvcmQ6IGVtSHJpZ0MyMks0XG5cblxuXG5KT0lOIEJZIFBIT05FXG4xLTY1 MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0byBj YWxsIChtb2JpbGUgcGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJCMS02 NTAtNDc5LTMyMDgsLCowMSo2NDc4MzY0MjAlMjMlMjMqMDEqXG5cblxuXG5KT0lOIEZST00gQSBW SURFTyBTWVNURU0gT1IgQVBQTElDQVRJT05cbkRpYWwgc2lwOjY0NzgzNjQyMEBpZXRmLndlYmV4 LmNvbVxuWW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRp bmcgbnVtYmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNr eXBlIGZvciBCdXNpbmVzc1xuRGlhbCBzaXA6NjQ3ODM2NDIwLmlldGZAbHluYy53ZWJleC5jb21c blxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25oZWxw LmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBs ZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIg aW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNo IG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBz ZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYg eW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2Vy bnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQtREVT QztGTVRUWVBFPXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxuKiB7XG4gICAgcGFk ZGluZzogMDsgICAgbWFyZ2luOiAwO31cbnRhYmxlIHtcbglib3JkZXItY29sbGFwc2U6IHNlcGFy YXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2luZzogMDt9XG5cbnRyIHtc bglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRkIHtcbglmb250LXNpemU6IDE0cHg7CWZvbnQt ZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1i cmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxuLnRpdGxlIHtcbglmb250LXNpemU6IDI4cHg7 fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwltYXgtd2lkdGg6IGF1dG87fVxuXG4uZm9vdGVy IHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7XG5cbn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4 LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0bGUge1xuCQlmb250LXNpemU6IDIycHggIWlt cG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRoOiBhdXRvICFpbXBvcnRhbnQ7CQltYXgtd2lk dGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290ZXIge1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0 YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxuCS5tYWluIHtcbgkJd2lkdGg6 IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbn1cbjwv c3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFy Z2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiPlxuCTx0ciBzdHls ZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCTx0cj5cbgkJPHRkIGFsaWdu PSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAiPlxuCQkJPCEtLTx0YWJs ZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7IHdpZHRoOiAxMDAlOyBwYWRk aW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBhbGlnbj0ibGVmdCIgY2xhc3M9 Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+ Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPi0tPlxuXG5cblxuXG5cbgkJ CTx0YWJsZT5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjQiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+V2hlbiBpdCdzIHRpbWUsIGpvaW4gdGhlIFdlYmV4IG1l ZXRpbmcgaGVyZS48L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCQk8dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48 L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDcgODM2 IDQyMDwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT5cbgkJCVxuCQkJ PHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5lbUhyaWdDMjJLNDwvRk9OVD48L3RkPjwvdHI+PC90YWJs ZT5cblxuICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAy MHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPHRyPlxu CQkJCTx0ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4JCQkJCTx0YWJsZSBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5bGU9IndpZHRoOmF1dG87 d2lkdGg6YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNBOTQyOyBib3JkZXI6MHB4 IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdpZHRoOjE2MHB4IWltcG9y dGFudDsiPlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiBzdHlsZT0icGFk ZGluZzoxMHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5w aHA/TVRJRD1tNWRiNTNhZDg1MDI0NGUyNWZjZWNmMTBjMzBhMWE4MTEiIHN0eWxlPSJjb2xvcjoj RkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5Kb2luIG1lZXRp bmc8L2E+PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4JCQkJPC90ZD5cbgkJCTwv dHI+XG4JCTwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFM Ij4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSI0 IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij5Kb2luIGJ5IHBob25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+PGI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwq MDEqNjQ3ODM2NDIwJTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29y YXRpb246bm9uZTsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdo dDogMjRweDsnPjEtNjUwLTQ3OS0zMjA4PC9hPjwvYj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMv Q2FuYWRhKTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48QlI+XG5cbjx0YWJsZT48dHIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpF PSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gZnJvbSBhIHZpZGVvIHN5c3Rl bSBvciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVmPSJzaXA6NjQ3ODM2NDIwQGlldGYud2Vi ZXguY29tIj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPjY0Nzgz NjQyMEBpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42 OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05U PiZuYnNwOyA8QlI+XG5cbjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0 cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiB1 c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPC9iPjwv dGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7 IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsi PkRpYWwgPGEgaHJlZj0iIHNpcDo2NDc4MzY0MjAuaWV0ZkBseW5jLndlYmV4LmNvbSIgICBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOSI+NjQ3ODM2NDIwLmlldGZAbHlu Yy53ZWJleC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+XG5cbgkJCTx0YWJsZSBzdHlsZT0id2lk dGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0 ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJ CQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpB cmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28g dG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2ViZXguY29tIiBzdHlsZT0iY29sb3I6IzA0OUZEOTsg dGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRwOi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwv dGQ+XG4JCQkJPC90cj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+ PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwvdGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFi bGU+XG4NClNVTU1BUlk6Q0JPUiB3b3JraW5nIGdyb3VwIGNvbmZlcmVuY2UgY2FsbA0KUFJJT1JJ VFk6NQ0KQ0xBU1M6UFVCTElDDQpSUlVMRTpGUkVRPVdFRUtMWTtXS1NUPVNVO1VOVElMPTIwMjAw NzE1O0lOVEVSVkFMPTI7QllEQVk9V0UNCkJFR0lOOlZBTEFSTQ0KVFJJR0dFUjotUFQ1TQ0KQUNU SU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9OOlJlbWluZGVyDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5U DQpFTkQ6VkNBTEVOREFSDQo= ------=_Part_175062_541030867.1584433073860--