From nobody Wed Jul 1 00:21: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 8A9C23A093E; Wed, 1 Jul 2020 00:21:30 -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 ztoKwsjsSL_Z; Wed, 1 Jul 2020 00:21:28 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB69B3A093D; Wed, 1 Jul 2020 00:21:27 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 15480670; Wed, 1 Jul 2020 09:21:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 4HoMv7Ul-CuT; Wed, 1 Jul 2020 09:21:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 Jul 2020 09:21:24 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id B783D20154; Wed, 1 Jul 2020 09:21:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id Z6T71eHYsSZq; Wed, 1 Jul 2020 09:21:24 +0200 (CEST) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 87B10200E4; Wed, 1 Jul 2020 09:21:24 +0200 (CEST) Date: Wed, 1 Jul 2020 09:21:23 +0200 From: Juergen Schoenwaelder To: draft-ietf-cbor-date-tag@ietf.org Cc: cbor@ietf.org Message-ID: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: Subject: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 01 Jul 2020 07:21:31 -0000 Hi, I just saw your CBOR date type and it seems it does not include a timezone offset. This means a date value does not represent a 24 hour time interval but something larger. XML schema's date type allows the optional inclusion of a timezone offset. The date definition in draft-ietf-netmod-rfc6991-bis-03.txt (still under discussion) includes a mandatory timezone offset (since it was already mandatory for date-and-time). I do not know whether we should have a common approach for this. Note that your 'number of days since the epoch 1970-01-01 does not really say 1970-01-01T00:00:00 and also leaves it open whether this is calculated in UTC or not (on Unix-like systems, time is usually counted in UTC). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jul 1 01:18: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 3E31A3A0A96; Wed, 1 Jul 2020 01:18:38 -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, RCVD_IN_MSPIKE_H4=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 V6InxyFWGDiP; Wed, 1 Jul 2020 01:18:33 -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 7221C3A0A8D; Wed, 1 Jul 2020 01:18:32 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49xYyZ0WVkzyRj; Wed, 1 Jul 2020 10:18:30 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> Date: Wed, 1 Jul 2020 10:18:29 +0200 Cc: draft-ietf-cbor-date-tag@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 615284309.5378031-5c6b4a6183d2e9bbde5487335db8542c Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 01 Jul 2020 08:18:38 -0000 Hi Juergen, thank you for that comment. There are two different concepts of =E2=80=9Cdate", and I think the = current draft needs to be more explicit that it is about one and not the = other. > On 2020-07-01, at 09:21, Juergen Schoenwaelder = wrote: >=20 > Hi, >=20 > I just saw your CBOR date type and it seems it does not include a > timezone offset. This means a date value does not represent a 24 hour > time interval but something larger. Well, it represents the abstract date, as opposed to a time period = starting at 00:00 on that date and ending at 24:00, both in some time = zone (which in practice may be 23, 24, 24.00028, or 25 hours). Angela Merkel=E2=80=99s birthday was 1954-07-17. You will find that on = her passport. The passport will be mute about the time zone in which = she was born, as that is irrelevant to the identification principle. = (Other example: I was born at 00:05 UTC, but that doesn=E2=80=99t mean I = have a different birthday in New York, where that specific instant would = have been 20:05 the previous day, I think.) > XML schema's date type allows the > optional inclusion of a timezone offset. Which is useful when you want to convert a date into that ~24-hour time = period. > The date definition in > draft-ietf-netmod-rfc6991-bis-03.txt (still under discussion) includes > a mandatory timezone offset (since it was already mandatory for > date-and-time). I do not know whether we should have a common approach > for this. I think there is a use case for these periods (see also = draft-bormann-cbor-time-tag for a little more about periods, even though = we haven=E2=80=99t started to flesh out that part of the spec). It is = not the one addressed by these tags. > Note that your 'number of days since the epoch 1970-01-01 does not > really say 1970-01-01T00:00:00 and also leaves it open whether this is > calculated in UTC or not (on Unix-like systems, time is usually > counted in UTC). It doesn=E2=80=99t have to, as it talks about the date, not the = anchoring in a time scale of the start and end of the period covering = that date in a specific time zone. Joerg=E2=80=99s original proposal has a separate tag for time zone, = which (with the time zone data base and, depending on the time scale, = information about leap seconds) may be used to do the conversion. This = is not included in the current draft, because the use case is for = abstract dates, but it certainly will be addressed by some future tags. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 1 01:36:33 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 F3A9C3A0B33; Wed, 1 Jul 2020 01:36:24 -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: 7.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159359258490.19135.17129012598607244961@ietfa.amsl.com> Date: Wed, 01 Jul 2020 01:36:24 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-07-01 CHANGED 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, 01 Jul 2020 08:36:25 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2020-07-01 from 17:00 to 18:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: CBOR WG Meeting - Interim 20-12 Wednesday, July 1, 2020, 17:00 - 18:00 CEST Chairs: Francesca Palombini, Jim Schaad Webex: https://ietf.webex.com/ietf/j.php?MTID=m5db53ad850244e25fcecf10c30a1a811 Meeting number (access code): 647 836 420 Meeting password: emHrigC22K4 Jabber: cbor@jabber.ietf.org Miutes: https://codimd.ietf.org/notes-ietf-interim-2020-cbor-12-cbor Agenda: * CBOR Tag for Date status : Mike https://tools.ietf.org/html/draft-jones-cbor-date-tag-02 * New CBOR OID draft : Carsten https://raw.githack.com/cabo/cbor-oid/cleanup/draft-bormann-cbor-tags-oid.html * CDDL Module designe https://mailarchive.ietf.org/arch/msg/cbor/BayziLDbvL8zghvYYqsdJpiTp-0/ * IETF 108 scheduling https://datatracker.ietf.org/meeting/108/agenda/ * AoB Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m5db53ad850244e25fcecf10c30a1a811 Meeting number (access code): 647 836 420 Meeting password: emHrigC22K4 Minutes: https://codimd.ietf.org/notes-ietf-interim-2020-cbor-12-cbor From nobody Wed Jul 1 01:44:48 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520563A0B78; Wed, 1 Jul 2020 01:44:46 -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, 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 j-8Rt-WBITRR; Wed, 1 Jul 2020 01:44:43 -0700 (PDT) Received: from mail-edgeKA24.fraunhofer.de (mail-edgeka24.fraunhofer.de [153.96.1.24]) (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 A43E13A0B77; Wed, 1 Jul 2020 01:44:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FfAABYTPxe/xoBYJlgGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFKgxmBMwqEJ5BvJZt7CQsBAQEBAQEBAQE?= =?us-ascii?q?GAQEYCwoCBAEBAoRFAoIUASQ4EwIQAQEGAQEBAQEGBAIChkQMg1GBAgEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEWAkNVEgEBHgEBAQMBASEPAQU2CxAJAg4CCAICJgI?= =?us-ascii?q?CJyAQBgEMAQUCAQGDIgGCewULkjmbeoEyhVGDcYE6BoEOKoxoD4FMP4ERJww?= =?us-ascii?q?Dglo+glwBAYR1gmAEkjWiJSgHgVmBBoEHBAuYIAUKHYJziS6EdAaNfyuFDYw?= =?us-ascii?q?cnl4CBAIJAhWBaoF5TSRPgmlQFwINWJZLhURyNwIGAQcBAQMJfI4xAYEQAQE?= X-IPAS-Result: =?us-ascii?q?A2FfAABYTPxe/xoBYJlgGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFKgxmBMwqEJ5BvJZt7CQsBAQEBAQEBAQEGAQEYCwoCBAEBA?= =?us-ascii?q?oRFAoIUASQ4EwIQAQEGAQEBAQEGBAIChkQMg1GBAgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEWAkNVEgEBHgEBAQMBASEPAQU2CxAJAg4CCAICJgICJyAQBgEMAQUCA?= =?us-ascii?q?QGDIgGCewULkjmbeoEyhVGDcYE6BoEOKoxoD4FMP4ERJwwDglo+glwBAYR1g?= =?us-ascii?q?mAEkjWiJSgHgVmBBoEHBAuYIAUKHYJziS6EdAaNfyuFDYwcnl4CBAIJAhWBa?= =?us-ascii?q?oF5TSRPgmlQFwINWJZLhURyNwIGAQcBAQMJfI4xAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.75,299,1589234400"; d="scan'208";a="22685631" Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeKA24.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2020 10:44:38 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAADnS/xe/1lIDI1gGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFKgipvA1QwLAqEJ5BvJZwECwEDAQEBAQE?= =?us-ascii?q?GAQEYCwoCBAEBhEcCghICJDgTAhABAQUBAQECAQYEbYVbDIVvAQEEAQEhDwE?= =?us-ascii?q?FNgsQCQIOAggCAiYCAicgEAYBDAEFAgEBgyIBgwALkjubeoEyhVGDcYE6BoE?= =?us-ascii?q?OKoxoD4FMP4ERJwwDglo+glwBAYR1gmAEkjWiJSgHgVmBBoEHBAuYIAUKHYJ?= =?us-ascii?q?ziS6EdAaNfyuFDYwcnl4CBAIJAhWBaiKBVk0kT4JpUBcCDViWS4VEQTE3AgY?= =?us-ascii?q?BBwEBAwl8jjEBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,299,1589234400"; d="scan'208";a="85390029" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2020 10:44:36 +0200 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 0618iZcT011360 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 1 Jul 2020 10:44:35 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 1 Jul 2020 10:44:30 +0200 To: Carsten Bormann , Juergen Schoenwaelder CC: , References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> From: Henk Birkholz Message-ID: <18fefc08-b407-8925-5d1a-f35cf4a844ef@sit.fraunhofer.de> Date: Wed, 1 Jul 2020 10:44:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 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.156.41] Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 01 Jul 2020 08:44:46 -0000 Hi all, in other words (and please correct me, if I am wrong): Effectively, the date tag is about calendars instead of timescales. These are two separate concepts. In calendars you count days (e.g. day of year or days since epoch, based on the rotation of the earth around its axis), in timescales you count time intervals (e.g. time of day or seconds since epoch, typically based on the rotation of the earth around the sun). Both calendars and timescales can share the same epoch, though. Viele Grüße, Henk On 01.07.20 10:18, Carsten Bormann wrote: > Hi Juergen, > > thank you for that comment. > > There are two different concepts of “date", and I think the current draft needs to be more explicit that it is about one and not the other. > >> On 2020-07-01, at 09:21, Juergen Schoenwaelder wrote: >> >> Hi, >> >> I just saw your CBOR date type and it seems it does not include a >> timezone offset. This means a date value does not represent a 24 hour >> time interval but something larger. > > Well, it represents the abstract date, as opposed to a time period starting at 00:00 on that date and ending at 24:00, both in some time zone (which in practice may be 23, 24, 24.00028, or 25 hours). > > Angela Merkel’s birthday was 1954-07-17. You will find that on her passport. The passport will be mute about the time zone in which she was born, as that is irrelevant to the identification principle. (Other example: I was born at 00:05 UTC, but that doesn’t mean I have a different birthday in New York, where that specific instant would have been 20:05 the previous day, I think.) > >> XML schema's date type allows the >> optional inclusion of a timezone offset. > > Which is useful when you want to convert a date into that ~24-hour time period. > >> The date definition in >> draft-ietf-netmod-rfc6991-bis-03.txt (still under discussion) includes >> a mandatory timezone offset (since it was already mandatory for >> date-and-time). I do not know whether we should have a common approach >> for this. > > I think there is a use case for these periods (see also draft-bormann-cbor-time-tag for a little more about periods, even though we haven’t started to flesh out that part of the spec). It is not the one addressed by these tags. > >> Note that your 'number of days since the epoch 1970-01-01 does not >> really say 1970-01-01T00:00:00 and also leaves it open whether this is >> calculated in UTC or not (on Unix-like systems, time is usually >> counted in UTC). > > It doesn’t have to, as it talks about the date, not the anchoring in a time scale of the start and end of the period covering that date in a specific time zone. > > Joerg’s original proposal has a separate tag for time zone, which (with the time zone data base and, depending on the time scale, information about leap seconds) may be used to do the conversion. This is not included in the current draft, because the use case is for abstract dates, but it certainly will be addressed by some future tags. > > Grüße, Carsten > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > From nobody Wed Jul 1 02:05:44 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778B53A0C76; Wed, 1 Jul 2020 02:05:41 -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 Y5INJQwLD4M4; Wed, 1 Jul 2020 02:05:39 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A423A0C75; Wed, 1 Jul 2020 02:05:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B27B5670; Wed, 1 Jul 2020 11:05:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id zec18FSQym5D; Wed, 1 Jul 2020 11:05:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 Jul 2020 11:05:37 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6202520154; Wed, 1 Jul 2020 11:05:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id nO82oVUU7pYJ; Wed, 1 Jul 2020 11:05:37 +0200 (CEST) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 0D750200E4; Wed, 1 Jul 2020 11:05:37 +0200 (CEST) Date: Wed, 1 Jul 2020 11:05:36 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: draft-ietf-cbor-date-tag@ietf.org, cbor@ietf.org Message-ID: <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 01 Jul 2020 09:05:42 -0000 On Wed, Jul 01, 2020 at 10:18:29AM +0200, Carsten Bormann wrote: > Hi Juergen, >=20 > thank you for that comment. >=20 > There are two different concepts of =E2=80=9Cdate", and I think the cur= rent draft needs to be more explicit that it is about one and not the oth= er. >=20 > > On 2020-07-01, at 09:21, Juergen Schoenwaelder wrote: > >=20 > > Hi, > >=20 > > I just saw your CBOR date type and it seems it does not include a > > timezone offset. This means a date value does not represent a 24 hour > > time interval but something larger. >=20 > Well, it represents the abstract date, as opposed to a time period star= ting at 00:00 on that date and ending at 24:00, both in some time zone (w= hich in practice may be 23, 24, 24.00028, or 25 hours). >=20 > Angela Merkel=E2=80=99s birthday was 1954-07-17. You will find that on= her passport. The passport will be mute about the time zone in which sh= e was born, as that is irrelevant to the identification principle. (Othe= r example: I was born at 00:05 UTC, but that doesn=E2=80=99t mean I have = a different birthday in New York, where that specific instant would have = been 20:05 the previous day, I think.) I am not sure about Angela's passport but my passport in addition states where I was born (which implies a certain time zone). I do not know whether this example is useful or not, perhaps you just want to say that in some use cases the time zone does not matter and this is fine. But on the other hand, two systems may tag an event with 1954-07-17 but in UTC they would be not the same dates or two systems can tag an event with two different dates but they are actually the same date in UTC. In distributed systems operating across many timezones, simple comparisons of date values can be surprising. =20 > > XML schema's date type allows the > > optional inclusion of a timezone offset. >=20 > Which is useful when you want to convert a date into that ~24-hour time= period. Or you want to compare dates, see above. > > The date definition in > > draft-ietf-netmod-rfc6991-bis-03.txt (still under discussion) include= s > > a mandatory timezone offset (since it was already mandatory for > > date-and-time). I do not know whether we should have a common approac= h > > for this. >=20 > I think there is a use case for these periods (see also draft-bormann-c= bor-time-tag for a little more about periods, even though we haven=E2=80=99= t started to flesh out that part of the spec). It is not the one address= ed by these tags. >=20 > > Note that your 'number of days since the epoch 1970-01-01 does not > > really say 1970-01-01T00:00:00 and also leaves it open whether this i= s > > calculated in UTC or not (on Unix-like systems, time is usually > > counted in UTC). >=20 > It doesn=E2=80=99t have to, as it talks about the date, not the anchori= ng in a time scale of the start and end of the period covering that date = in a specific time zone. > Joerg=E2=80=99s original proposal has a separate tag for time zone, whi= ch (with the time zone data base and, depending on the time scale, inform= ation about leap seconds) may be used to do the conversion. This is not = included in the current draft, because the use case is for abstract dates= , but it certainly will be addressed by some future tags. >=20 If the ambiguity caused by timezones is what this WG wants, fine. But then I think the WG should add a warning that naive comparisons of date values can be surprising. Let me check POSIX.1 that is cited for the epoch. Section 4.16 says: If the year is >=3D1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 I read this as POSIX.1 says the calculation has to be done in UTC. This means you can have date =3D 1970-01-02 with days since 1970-01-01 =3D= 0, no? /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jul 1 02:06: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 627693A0C77; Wed, 1 Jul 2020 02:06:40 -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, RCVD_IN_MSPIKE_H4=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 wF-DgFz2lE6H; Wed, 1 Jul 2020 02:06:36 -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 505183A0C6B; Wed, 1 Jul 2020 02:06:36 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49xb225K6vz100G; Wed, 1 Jul 2020 11:06:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <18fefc08-b407-8925-5d1a-f35cf4a844ef@sit.fraunhofer.de> Date: Wed, 1 Jul 2020 11:06:34 +0200 Cc: Juergen Schoenwaelder , draft-ietf-cbor-date-tag@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 615287194.246299-a77a7410acf4c08e9249d5c35b3e2ef7 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <18fefc08-b407-8925-5d1a-f35cf4a844ef@sit.fraunhofer.de> To: Henk Birkholz X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 01 Jul 2020 09:06:40 -0000 On 2020-07-01, at 10:44, Henk Birkholz = wrote: >=20 > Both calendars and timescales can share the same epoch, though. Not sure that statement is pedantically correct, but yes. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 1 03:20: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 C9A5E3A0D96; Wed, 1 Jul 2020 03:20:22 -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, 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 xSj6w0KuRxuQ; Wed, 1 Jul 2020 03:20:20 -0700 (PDT) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (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 60D243A0D94; Wed, 1 Jul 2020 03:20:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EEAwCoYvxe/xmnZsBgHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqETAqEJ5ESnAQLAQEBAQEBAQEBBgEBLQIEAQGERwKCFgE?= =?us-ascii?q?kOBMCEAEBBgEBAQEBBgQCAoZQhkgBBSMPAQVBEAkCDgoCAiYCAkcQBg0BBQI?= =?us-ascii?q?BAYMign0EkkGbeoEyhVGDZoFAgQ4qjGgPgUw/gTgPglo+h1OCYASPEIMloiU?= =?us-ascii?q?oB4FZgQaBBwQLmCAFCh2CYY40Bo1/K4UNqnoCBAIJAhWBaoF5TSSDOFAXAg2?= =?us-ascii?q?cZ3ICNQIGAQcBAQMJfI4xAYEQAQE?= X-IPAS-Result: =?us-ascii?q?A2EEAwCoYvxe/xmnZsBgHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?UqETAqEJ5ESnAQLAQEBAQEBAQEBBgEBLQIEAQGERwKCFgEkOBMCEAEBBgEBA?= =?us-ascii?q?QEBBgQCAoZQhkgBBSMPAQVBEAkCDgoCAiYCAkcQBg0BBQIBAYMign0EkkGbe?= =?us-ascii?q?oEyhVGDZoFAgQ4qjGgPgUw/gTgPglo+h1OCYASPEIMloiUoB4FZgQaBBwQLm?= =?us-ascii?q?CAFCh2CYY40Bo1/K4UNqnoCBAIJAhWBaoF5TSSDOFAXAg2cZ3ICNQIGAQcBA?= =?us-ascii?q?QMJfI4xAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.75,299,1589234400"; d="scan'208";a="22811836" Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2020 12:20:14 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNBACoYvxe/1lIDI1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqCKnJUMCwKhCeREpwECwEDAQEBAQEGAQEtAgQBAYRHAoI?= =?us-ascii?q?UAiQ4EwIQAQEFAQEBAgEGBG2FZ4VvAQUjDwEFQRAJAg4KAgImAgJHEAYNAQU?= =?us-ascii?q?CAQGDIoMBkkGbeoEyhVGDZoFAgQ4qjGgPgUw/gTgPglo+h1OCYASPEIMloiU?= =?us-ascii?q?oB4FZgQaBBwQLmCAFCh2CYY40Bo1/K4UNqnoCBAIJAhWBaiKBVk0kgzhQFwI?= =?us-ascii?q?NnGdBMQI1AgYBBwEBAwl8jjEBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,299,1589234400"; d="scan'208";a="85298135" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2020 12:20:11 +0200 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 061AKAUE017151 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 1 Jul 2020 12:20:10 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 1 Jul 2020 12:20:05 +0200 To: Carsten Bormann CC: Juergen Schoenwaelder , , References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <18fefc08-b407-8925-5d1a-f35cf4a844ef@sit.fraunhofer.de> From: Henk Birkholz Message-ID: Date: Wed, 1 Jul 2020 12:20:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 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.156.41] Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 01 Jul 2020 10:20:23 -0000 I was referring to well-known epoch concepts only, such as the beginning of the common era, of course. Going into all the required details (reference timescales) without simplification is probably unnecessary complexity. Viele Grüße, Henk On 01.07.20 11:06, Carsten Bormann wrote: > On 2020-07-01, at 10:44, Henk Birkholz wrote: >> >> Both calendars and timescales can share the same epoch, though. > > Not sure that statement is pedantically correct, but yes. > > Grüße, Carsten > From nobody Wed Jul 1 03:42:10 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 C508F3A0DDB; Wed, 1 Jul 2020 03:42:08 -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, 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 BT-YSrn8dIeS; Wed, 1 Jul 2020 03:42:06 -0700 (PDT) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (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 3B5973A0DDA; Wed, 1 Jul 2020 03:42:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FFAABxZ/xe/xoBYJlgGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAgUqBdQaCUQqEJ5BtJZwECwEBAQE?= =?us-ascii?q?BAQEBAQYBAS0CBAEBhEcCghYBJDgTAhABAQYBAQEBAQYEAgKGUIZHAQEBAQI?= =?us-ascii?q?BIw8BBUEQCQIOAggCAiYCAkcQBgEMAQUCAQGCV0uCXR8FkkibBHaBMoVRg1+?= =?us-ascii?q?BQIEOKgGMZw+BTD+BEScMA4JaPodTgmAEkjWGaJs9KAeBWYEGgQcEC5ggBQo?= =?us-ascii?q?dgnOJLoR0BieINoUiK4UNjByeXgIEAgkCFYFqgXlNJIM4UBcCDViNUheOJnI?= =?us-ascii?q?3AgYBBwEBAwl8jjEBgRABAQ?= X-IPAS-Result: =?us-ascii?q?A2FFAABxZ/xe/xoBYJlgGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQFAgUqBdQaCUQqEJ5BtJZwECwEBAQEBAQEBAQYBAS0CB?= =?us-ascii?q?AEBhEcCghYBJDgTAhABAQYBAQEBAQYEAgKGUIZHAQEBAQIBIw8BBUEQCQIOA?= =?us-ascii?q?ggCAiYCAkcQBgEMAQUCAQGCV0uCXR8FkkibBHaBMoVRg1+BQIEOKgGMZw+BT?= =?us-ascii?q?D+BEScMA4JaPodTgmAEkjWGaJs9KAeBWYEGgQcEC5ggBQodgnOJLoR0BieIN?= =?us-ascii?q?oUiK4UNjByeXgIEAgkCFYFqgXlNJIM4UBcCDViNUheOJnI3AgYBBwEBAwl8j?= =?us-ascii?q?jEBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,299,1589234400"; d="scan'208";a="22812420" Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2020 12:42:02 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAAAUaPxe/1lIDI1gGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAgUqBdQYvclQwLAqEJ5BsJZwECwE?= =?us-ascii?q?DAQEBAQEGAQEtAgQBAYRHAoIUAiQ4EwIQAQEFAQEBAgEGBG2FZ4VuAQEBAwE?= =?us-ascii?q?jDwEFQRAJAg4CCAICJgICRxAGAQwBBQIBAYJXS4JdJJJHmwR2gTKFUYNlgUC?= =?us-ascii?q?BDioBjGcPgUw/gREnDAOCWj6HU4JgBJI1hmibPSgHgVmBBoEHBAuYIAUKHYJ?= =?us-ascii?q?ziS6EdAYniDaFIiuFDYwcnl4CBAIJAhWBaiKBVk0kgzhQFwINWI1SF44mQTE?= =?us-ascii?q?3AgYBBwEBAwl8jjEBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,299,1589234400"; d="scan'208";a="85405731" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2020 12:41:59 +0200 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 061Afwlq019115 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 1 Jul 2020 12:41:58 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 1 Jul 2020 12:41:53 +0200 To: Juergen Schoenwaelder , Carsten Bormann CC: , References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> From: Henk Birkholz Message-ID: <2e979e71-ea3d-77a3-9724-eeb17e028550@sit.fraunhofer.de> Date: Wed, 1 Jul 2020 12:41:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.156.41] Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 01 Jul 2020 10:42:09 -0000 Hi Jürgen, comments in-line. On 01.07.20 11:05, Juergen Schoenwaelder wrote: > On Wed, Jul 01, 2020 at 10:18:29AM +0200, Carsten Bormann wrote: >> Hi Juergen, >> >> thank you for that comment. >> >> There are two different concepts of “date", and I think the current draft needs to be more explicit that it is about one and not the other. >> >>> On 2020-07-01, at 09:21, Juergen Schoenwaelder wrote: >>> >>> Hi, >>> >>> I just saw your CBOR date type and it seems it does not include a >>> timezone offset. This means a date value does not represent a 24 hour >>> time interval but something larger. >> >> Well, it represents the abstract date, as opposed to a time period starting at 00:00 on that date and ending at 24:00, both in some time zone (which in practice may be 23, 24, 24.00028, or 25 hours). >> >> Angela Merkel’s birthday was 1954-07-17. You will find that on her passport. The passport will be mute about the time zone in which she was born, as that is irrelevant to the identification principle. (Other example: I was born at 00:05 UTC, but that doesn’t mean I have a different birthday in New York, where that specific instant would have been 20:05 the previous day, I think.) > > I am not sure about Angela's passport but my passport in addition > states where I was born (which implies a certain time zone). I do not > know whether this example is useful or not, perhaps you just want to > say that in some use cases the time zone does not matter and this is > fine. That is an excellent example. Personally, I think that a geo-location is a way more stable reference to a time zone at a given point in time than a time zone offset associated with that geo-location (as these change surprisingly often over time). Having said that, associating a calendar day with a time zone of course supports the association of calendar day with my local timescale. Please see below. > > But on the other hand, two systems may tag an event with 1954-07-17 > but in UTC they would be not the same dates or two systems can tag an > event with two different dates but they are actually the same date in > UTC. In distributed systems operating across many timezones, simple > comparisons of date values can be surprising. "in UTC" is the association of a calendar day with a timescale. If you do that, time-zones become relevant. If I add a calendar event to my schedule, I want to associate it with a local timescale / TZ, otherwise I will probably miss the event. That is why calendar days are often bundled with a time zone in an event description. It supports the association with a given timescale. > >>> XML schema's date type allows the >>> optional inclusion of a timezone offset. >> >> Which is useful when you want to convert a date into that ~24-hour time period. > > Or you want to compare dates, see above. > >>> The date definition in >>> draft-ietf-netmod-rfc6991-bis-03.txt (still under discussion) includes >>> a mandatory timezone offset (since it was already mandatory for >>> date-and-time). I do not know whether we should have a common approach >>> for this. >> >> I think there is a use case for these periods (see also draft-bormann-cbor-time-tag for a little more about periods, even though we haven’t started to flesh out that part of the spec). It is not the one addressed by these tags. >> >>> Note that your 'number of days since the epoch 1970-01-01 does not >>> really say 1970-01-01T00:00:00 and also leaves it open whether this is >>> calculated in UTC or not (on Unix-like systems, time is usually >>> counted in UTC). >> >> It doesn’t have to, as it talks about the date, not the anchoring in a time scale of the start and end of the period covering that date in a specific time zone. > >> Joerg’s original proposal has a separate tag for time zone, which (with the time zone data base and, depending on the time scale, information about leap seconds) may be used to do the conversion. This is not included in the current draft, because the use case is for abstract dates, but it certainly will be addressed by some future tags. >> > > If the ambiguity caused by timezones is what this WG wants, fine. But > then I think the WG should add a warning that naive comparisons of > date values can be surprising. > > Let me check POSIX.1 that is cited for the epoch. Section 4.16 says: > > If the year is >=1970 and the value is non-negative, the value is > related to a Coordinated Universal Time name according to the > C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and > tm_year are all integer types: > > tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + > (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - > ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 > > I read this as POSIX.1 says the calculation has to be done in UTC. > > This means you can have date = 1970-01-02 with days since 1970-01-01 = 0, no? All definitions in IEEE 1003.1 are about timescales and not calendar days (as indicated by the use of the UTC timescale). Viele Grüße, Henk > > /js > From nobody Wed Jul 1 07:28: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 4E9093A0C5C; Wed, 1 Jul 2020 07:28:12 -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 44M-ImK1YlpZ; Wed, 1 Jul 2020 07:28:10 -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 ACD413A0C41; Wed, 1 Jul 2020 07:28:09 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 1 Jul 2020 07:28:01 -0700 From: Jim Schaad To: 'Mike Jones' , CC: References: , <03c801d64f44$d265ddb0$77319910$@augustcellars.com> In-Reply-To: Date: Wed, 1 Jul 2020 07:27:59 -0700 Message-ID: <03ff01d64fb3$d415d830$7c418890$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0400_01D64F79.27B7EA90" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQG9hUW0rmWg4KI81Ec+8sUnWhASEwN/3HsqAh4zqBwBSm0FeqjtGBng X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Review draft-ietf-cbor-date-tag-01 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, 01 Jul 2020 14:28:13 -0000 ------=_NextPart_000_0400_01D64F79.27B7EA90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit That text does not represent what I was looking for. I was thinking of something more along the lines of When using this data type for decision making, for examples access control, it needs to be noted that since this does not represent a specific point in time the results of the evaluation can differ depending upon where the decision is made. This can represent more than 24-hour period in total as a different 24-hours are used in the timezone -12:00 and +12:00. That text probably needs to get cleaned up and expanded but it gives the gist of what I am looking for. You can also look at the latest email on the CBOR mailing list. Jim From: Mike Jones Sent: Tuesday, June 30, 2020 6:43 PM To: Jim Schaad ; draft-ietf-cbor-date-tag@ietf.org Cc: cbor@ietf.org Subject: RE: Review draft-ietf-cbor-date-tag-01 I created text. -- Mike _____ From: Jim Schaad > Sent: Tuesday, June 30, 2020 6:13:22 PM To: Mike Jones >; draft-ietf-cbor-date-tag@ietf.org > Cc: cbor@ietf.org > Subject: [EXTERNAL] RE: Review draft-ietf-cbor-date-tag-01 > -----Original Message----- > From: Mike Jones > > Sent: Tuesday, June 30, 2020 5:41 PM > To: Jim Schaad >; draft-ietf-cbor-date-tag@ietf.org > Cc: cbor@ietf.org > Subject: RE: Review draft-ietf-cbor-date-tag-01 > > Hi Jim, > > I've applied these changes in https://tools.ietf.org/html/draft-ietf-cbor-date- > tag-02. > > Thanks again, > -- Mike > > -----Original Message----- > From: Mike Jones > Sent: Friday, June 12, 2020 11:52 AM > To: Jim Schaad >; draft-ietf-cbor-date-tag@ietf.org > Cc: cbor@ietf.org > Subject: RE: Review draft-ietf-cbor-date-tag-01 > > Thanks for your review, Jim. My replies are inline below... > > Is it time to start WGLC so others also get their reviews in? I'll note that the > IANA registrations have already occurred at > https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml. > > -----Original Message----- > From: Jim Schaad > > Sent: Thursday, June 11, 2020 11:48 AM > To: draft-ietf-cbor-date-tag@ietf.org > Cc: cbor@ietf.org > Subject: Review draft-ietf-cbor-date-tag-01 > > * Is there any chance that you can upgrade to using the v3 of xml2rfc schema? > If not then there is not an issue as the RFC Editor will do it. > > I haven't really learned all the ins and outs of the new syntax yet, so I'd have > more confidence with the RFC Editor doing it correctly than me. > > * Introduction: I prefer the abstract form of /date but not a time/date without > a time/ > > I agree and will make this change in the next published draft. > > * While this is something that is clear to me, I got a recent comment when I > suggested that this be used elsewhere of, "But how does this work with time > zones?". Based on that I think that there needs to be some text about why time > zones are not of interest here. > > Agreed and will do. > > * Section 3- I think that the second paragraph would be wise to distinguish > between a point in time and a date when looking at access control decisions. > > I understand your point in general. Is there particular text that you'd suggest > that I incorporate? No I don't have any text in mind. Jim > > Jim > > Thanks again, > -- Mike > ------=_NextPart_000_0400_01D64F79.27B7EA90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That text = does not represent what I was looking for.  I was thinking of = something more along the lines of

 

When using = this data type for decision making, for examples access control, it = needs to be noted that since this does not represent a specific point in = time the results of the evaluation can differ depending upon where the = decision is made.  This can represent more than  24-hour = period in total as a different 24-hours are used in the timezone -12:00 = and +12:00.

 

That text probably needs to get cleaned up and = expanded but it gives the gist of what I am looking for.  You can = also look at the latest email on the CBOR mailing list.

 

Jim

 

 

From: Mike = Jones <Michael.Jones@microsoft.com>
Sent: Tuesday, June = 30, 2020 6:43 PM
To: Jim Schaad = <ietf@augustcellars.com>; = draft-ietf-cbor-date-tag@ietf.org
Cc: = cbor@ietf.org
Subject: RE: Review = draft-ietf-cbor-date-tag-01

 

I created = text.

 

-- = Mike

 

From: Jim Schaad <ietf@augustcellars.com>
= Sent: Tuesday, June 30, 2020 6:13:22 PM
To: Mike Jones = <Michael.Jones@microsoft.com>; draft-ietf-cbor-date-ta= g@ietf.org <draft-ietf-cbor-date-ta= g@ietf.org>
Cc: cbor@ietf.org <cbor@ietf.org>
Subject: = [EXTERNAL] RE: Review draft-ietf-cbor-date-tag-01 =

 



> = -----Original Message-----
> From: Mike Jones <Michael.Jones@microsoft.com>
> Sent: Tuesday, June 30, 2020 5:41 PM
> To: Jim = Schaad <ietf@augustcellars.com>; = draft-ietf-cbor-date-ta= g@ietf.org
> Cc: cbor@ietf.org
> Subject: RE: = Review draft-ietf-cbor-date-tag-01
>
> Hi Jim,
> =
> I've applied these changes in
https://tools.= ietf.org/html/draft-ietf-cbor-date-
> tag-02.
> =
>           = ;            =          Thanks = again,
>          = ;            =           -- Mike
> =
> -----Original Message-----
> From: Mike Jones
> = Sent: Friday, June 12, 2020 11:52 AM
> To: Jim Schaad <ietf@augustcellars.com>; = draft-ietf-cbor-date-ta= g@ietf.org
> Cc: cbor@ietf.org
> Subject: RE: = Review draft-ietf-cbor-date-tag-01
>
> Thanks for your = review, Jim.  My replies are inline below...
>
> Is it = time to start WGLC so others also get their reviews in?  I'll = note
that the
> IANA registrations have already occurred = at
> https= ://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml.
> =
> -----Original Message-----
> From: Jim Schaad <ietf@augustcellars.com>
= > Sent: Thursday, June 11, 2020 11:48 AM
> To: draft-ietf-cbor-date-ta= g@ietf.org
> Cc: cbor@ietf.org
> Subject: Review = draft-ietf-cbor-date-tag-01
>
> * Is there any chance that = you can upgrade to using the v3 of xml2rfc
schema?
> If not = then there is not an issue as the RFC Editor will do it.
> =
> I haven't really learned all the ins and outs of the new syntax = yet, so
I'd have
> more confidence with the RFC Editor doing it = correctly than me.
>
> * Introduction:  I prefer the = abstract form of /date but not a time/date
without
> a = time/
>
> I agree and will make this change in the next = published draft.
>
> * While this is something that is = clear to me, I got a recent comment when
I
> suggested that = this be used elsewhere of, "But how does this work = with
time
> zones?".  Based on that I think that = there needs to be some text about why
time
> zones are not of = interest here.
>
> Agreed and will do.
>
> * = Section 3- I think that the second paragraph would be wise = to
distinguish
> between a point in time and a date when = looking at access control
decisions.
>
> I understand = your point in general.  Is there particular text that = you'd
suggest
> that I incorporate?

No I don't have any = text in mind.

Jim

>
> Jim
> =
>           = ;            =          Thanks = again,
>          = ;            =           -- Mike
> =

------=_NextPart_000_0400_01D64F79.27B7EA90-- From nobody Wed Jul 1 07:31:26 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 81E423A0BEA for ; Wed, 1 Jul 2020 07:31:25 -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 9cl2f4ueWmQt for ; Wed, 1 Jul 2020 07:31:23 -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 8230E3A0BE5 for ; Wed, 1 Jul 2020 07:31:22 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 1 Jul 2020 07:30:59 -0700 From: Jim Schaad To: References: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> <24433.1593575640@localhost> <03db01d64f66$cc797a20$656c6e60$@augustcellars.com> In-Reply-To: <03db01d64f66$cc797a20$656c6e60$@augustcellars.com> Date: Wed, 1 Jul 2020 07:30:57 -0700 Message-ID: <040401d64fb4$3d776230$b8662690$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQJ5T9b3i55/+CwwqSdD3kqEjEw/wAJfVF68AeUcwNOniqSJUA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] CDDL Module Design 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, 01 Jul 2020 14:31:26 -0000 Adding new issues to the list: 1. Are there any items for which the order of evaluation of the modules is going to be important. I think the answer is yes - consider adding elements to a group and then using the group in an array. 2. Are there places where the current definitions of anything get messed up with multiple modules and ordering. I am thinking of cuts in maps (where I can't remember which hill things died on) or maybe the newly proposed .feature control. Jim > -----Original Message----- > From: CBOR On Behalf Of Jim Schaad > Sent: Tuesday, June 30, 2020 10:17 PM > To: 'Michael Richardson' > Cc: cbor@ietf.org > Subject: Re: [Cbor] CDDL Module Design > > > > > -----Original Message----- > > From: Michael Richardson > > Sent: Tuesday, June 30, 2020 8:54 PM > > To: Jim Schaad > > Cc: cbor@ietf.org > > Subject: Re: [Cbor] CDDL Module Design > > > > > > Jim Schaad wrote: > > > 1. What is the naming scheme to be used? Both XML Schema and > > ASN.1 use > > > unique identifiers for a module. The problem with this approach > > is > that a > > > revised module has a new identifier even if all of the changes were > > > preserving of the old module. This can also present problems if two > > > different versions of the same module are used as it can be > difficult to > > > know which version of a module is being provided. > > > > Doesn't the version problem also include the "DLL hell" problem? > > That is: > > module A includes module B.1 which includes C.1 > > A includes module D.1 which includes C.2 > > > > and who knows if C.1 and C.2 can be used at the same time? > > > > So I totally agree that this is a problem. > > > > > I think therefore it > > > would be nice to have a naming system that recognizes version > numbers, > > but > > > can be used with a "latest version" mode. One possible way to > > do > this > > would > > > be to use a query parameter to get a specific version of a > > module > while > > > without the query parameter the compiler grabs the most recent > version it > > > has. > > > > I think that this is probably a very elegant solution. > > > > > 2. Do want the naming scheme to be used to access a module name > from > > the > > > web, and to create a server to host all of the IETF based CDDL > modules? > > > > A think that I dislike about the ENTITY stuff in XML is that the URLs > > are > way > > too specific. Do you want avoid that? Will it be some URN space? > > I was thinking about the question of doing a URN instead of a URL - hence the > term naming scheme. The interesting question is how should the naming be > done and what short of mapping is needed. One of the nice things about DOIs > is that they can be used as an indirect reference with a well known server to > get actual URLs > > > > > > 3. For any number of reasons we need to be able to state that > > some symbols > > > are going to be imported from a different module. There are > > some > issues > > > around doing a couple of other things: > > > * If all symbols are imported then you either need to have a > > module > based > > > naming system or you need to ensure that there are no collisions. > > > * If only specific symbols are imported, then they could either > > be > a) made > > > to be unique by renaming or b) made to be unique in the current > module > > > simply by how the module is written > > > > Can you give an example of (b)? > > I think that Python mostly got this process right. > > (b) is just - don't define any conflicts between what I am importing and what I > have written in the text. If I am going to use COSE_Signed as an import, then I > really should define a different symbol in the current CDDL file by that name. > > > > > > 4. ASN.1 has a method to say that only specific symbols can be > exported > > > from a module. I have never used this capability and I am not > > clear > that it > > > would be useful to have here. Should we support it anyway? > > > > No. It just leads to stupid work arounds. > > _ for things that should not be exported, but not enforced. > > I tend to agree with this. One of the interesting questions would be transitive > imports though. If module A imports COSE_Signed from module B can module > B import COSE_Signed from module B or must it reference module A. > I remember the first time I figured out that ASN.1 allows this and to be frank I > found it somewhat irritating. It does allow moving symbols between modules, > but that has the potential to break other modules suddenly. > > > > > > 5. How should the system be setup to be able to recognize this > capability. > > > The suggestion in the freezer document currently is to use a > > pragma system. > > > Introducing a pragma system can easily be seen as a step to > > allow > for > > > compilers of CDDL to be written. The A2C compiler that I wrote > used --# > > > and #-- as the start and stop delimiters for pragmas as "--" is the > > > start/stop comment character. (ASN.1 is not line based so there > > is > no > > > comment till a return.) A similar approach can easily be used here. > > > > I prefer that the statement not be a pre-processor-like hack. > > The interesting question then, is how much do we want to change the CDDL > language. If we do pragmas this is a standalone document. If we do changes in > the grammar then it is harder to make this standalone. > > > > > > 6. If we use a pragma naming system, do we want to setup in > > advance > for > > it > > > to have namespaces so that a single module could be used with > different > > > compilers. I ended up using a different string than the OSS > compiler did > > > ("--<" ">--") to be able to do this but having a namespace could > also > > > support this. > > > > I don't understand. > > Suppose I write a CDDL compiler - called my_great_cddl_compiler and Carsten > writes one called no_so_good_cddl_compiler. I could reference pragmas as > ME:UseInt32 and CB:UseInt32 as separate pragmas in the same file and each > compiler would recognize that one that it implements and do the right thing > (which is to use some int sized at least 32 bits?) They could have different > behavior for the same name. > > > > > > 7. What set of pragmas are we looking at to start with. XML > > Schema > has > > > some attributes that can be used for controlling the compiler. > > One > of this > > > is a location hint attribute which can be used for giving alternate > > > locations to use for finding a module (such as a location on my > machine). > > > There might be some other pragmas that might be useful to > > specify as well. > > > It might be easier to specify co-occurrence constraints using > pragmas > > rather > > > than trying to put it directly into the language. > > > > This is useful at the top-level file. > > Particularly for a group of people who are working together. > > For "location on my machine", I think that I'd rather be providing a > command > > flag, but I don't object to having ../.. paths or > https://my.little.server.example/ > > in a file. > > Another one at the top level might be to use one of the more interesting things > that the OSS compiler does is to allow one to say - This is the list of symbols to > emit which can be used rather than either emit everything or emit the first > symbol in the file which made me do some really strange things in the COSE > CDDL. > > Jim > > > > > > -- > > Michael Richardson , Sandelman Software Works > > - = IPv6 IoT consulting =- > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Jul 1 07:49:44 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188B63A0C1E for ; Wed, 1 Jul 2020 07:49:41 -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, RCVD_IN_MSPIKE_H4=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 mDR_9pKs3j0a for ; Wed, 1 Jul 2020 07:49:38 -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 E8B173A0B1B for ; Wed, 1 Jul 2020 07:49:37 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49xkdr2zQzzygH; Wed, 1 Jul 2020 16:49:36 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <040401d64fb4$3d776230$b8662690$@augustcellars.com> Date: Wed, 1 Jul 2020 16:49:36 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 615307775.9535331-587d97a70f32040caea1addabef342ef Content-Transfer-Encoding: quoted-printable Message-Id: <675ADAFF-7A32-49D1-835C-866432BFED58@tzi.org> References: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> <24433.1593575640@localhost> <03db01d64f66$cc797a20$656c6e60$@augustcellars.com> <040401d64fb4$3d776230$b8662690$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] CDDL Module Design 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, 01 Jul 2020 14:49:42 -0000 Hi Jim, On 2020-07-01, at 16:30, Jim Schaad wrote: >=20 > Adding new issues to the list: >=20 > 1. Are there any items for which the order of evaluation of the = modules is > going to be important. I think the answer is yes - consider adding = elements > to a group and then using the group in an array. What do you mean by =E2=80=9Cadding elements=E2=80=9D? CDDL was designed to be insensitive to the order of rules, with the = exception of the special meaning of the first rule. I would expect that we compose at the level of rules. However, prioritized choice and =E2=80=9C/=3D=E2=80=9C/"//=3D=E2=80=9C = conspire against that original design. So, yes, where a choice is = composed from multiple =E2=80=9C/=3D=E2=80=9C/"//=3D=E2=80=9C rules, the = order is indeed relevant. > 2. Are there places where the current definitions of anything get = messed up > with multiple modules and ordering. I am thinking of cuts in maps = (where I > can't remember which hill things died on) or maybe the newly proposed > ..feature control. Ordering within a group (different from the above) is important. (That order controls cuts and other forms of prioritized choice, even if = the group creates a map that by definition is not order-sensitive.) But composition from separate rules needs to be explicit here, e.g. in = SDF: sdfinfo =3D { title: text version: text copyright: text license: text EXTENSION-POINT } EXTENSION-POINT =3D ( * text =3D> any )=20 Putting the extension point first would enable the use of values that do = not match `text` in title, version, copyright, and license entries. But the specifier put EXTENSION-POINT last explicitly, so there is no = such danger. I can=E2=80=99t imagine at the moment how .feature would introduce new = order sensitivities. Gr=C3=BC=C3=9Fe, Carsten >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: CBOR On Behalf Of Jim Schaad >> Sent: Tuesday, June 30, 2020 10:17 PM >> To: 'Michael Richardson' >> Cc: cbor@ietf.org >> Subject: Re: [Cbor] CDDL Module Design >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Michael Richardson >>> Sent: Tuesday, June 30, 2020 8:54 PM >>> To: Jim Schaad >>> Cc: cbor@ietf.org >>> Subject: Re: [Cbor] CDDL Module Design >>>=20 >>>=20 >>> Jim Schaad wrote: >>>> 1. What is the naming scheme to be used? Both XML Schema and >>> ASN.1 use >>>> unique identifiers for a module. The problem with this approach >>> is >> that a >>>> revised module has a new identifier even if all of the changes > were >>>> preserving of the old module. This can also present problems if > two >>>> different versions of the same module are used as it can be >> difficult to >>>> know which version of a module is being provided. >>>=20 >>> Doesn't the version problem also include the "DLL hell" problem? >>> That is: >>> module A includes module B.1 which includes C.1 >>> A includes module D.1 which includes C.2 >>>=20 >>> and who knows if C.1 and C.2 can be used at the same time? >>>=20 >>> So I totally agree that this is a problem. >>>=20 >>>> I think therefore it >>>> would be nice to have a naming system that recognizes version >> numbers, >>> but >>>> can be used with a "latest version" mode. One possible way to >>> do >> this >>> would >>>> be to use a query parameter to get a specific version of a >>> module >> while >>>> without the query parameter the compiler grabs the most recent >> version it >>>> has. >>>=20 >>> I think that this is probably a very elegant solution. >>>=20 >>>> 2. Do want the naming scheme to be used to access a module name >> from >>> the >>>> web, and to create a server to host all of the IETF based CDDL >> modules? >>>=20 >>> A think that I dislike about the ENTITY stuff in XML is that the = URLs >>> are >> way >>> too specific. Do you want avoid that? Will it be some URN space? >>=20 >> I was thinking about the question of doing a URN instead of a URL - = hence > the >> term naming scheme. The interesting question is how should the = naming be >> done and what short of mapping is needed. One of the nice things = about > DOIs >> is that they can be used as an indirect reference with a well known = server > to >> get actual URLs >>=20 >>>=20 >>>> 3. For any number of reasons we need to be able to state that >>> some symbols >>>> are going to be imported from a different module. There are >>> some >> issues >>>> around doing a couple of other things: >>>> * If all symbols are imported then you either need to have a >>> module >> based >>>> naming system or you need to ensure that there are no collisions. >>>> * If only specific symbols are imported, then they could either >>> be >> a) made >>>> to be unique by renaming or b) made to be unique in the current >> module >>>> simply by how the module is written >>>=20 >>> Can you give an example of (b)? >>> I think that Python mostly got this process right. >>=20 >> (b) is just - don't define any conflicts between what I am importing = and > what I >> have written in the text. If I am going to use COSE_Signed as an = import, > then I >> really should define a different symbol in the current CDDL file by = that > name. >>=20 >>>=20 >>>> 4. ASN.1 has a method to say that only specific symbols can be >> exported >>>> from a module. I have never used this capability and I am not >>> clear >> that it >>>> would be useful to have here. Should we support it anyway? >>>=20 >>> No. It just leads to stupid work arounds. >>> _ for things that should not be exported, but not enforced. >>=20 >> I tend to agree with this. One of the interesting questions would be > transitive >> imports though. If module A imports COSE_Signed from module B can = module >> B import COSE_Signed from module B or must it reference module A. >> I remember the first time I figured out that ASN.1 allows this and to = be > frank I >> found it somewhat irritating. It does allow moving symbols between > modules, >> but that has the potential to break other modules suddenly. >>=20 >>>=20 >>>> 5. How should the system be setup to be able to recognize this >> capability. >>>> The suggestion in the freezer document currently is to use a >>> pragma system. >>>> Introducing a pragma system can easily be seen as a step to >>> allow >> for >>>> compilers of CDDL to be written. The A2C compiler that I wrote >> used --# >>>> and #-- as the start and stop delimiters for pragmas as "--" is > the >>>> start/stop comment character. (ASN.1 is not line based so there >>> is >> no >>>> comment till a return.) A similar approach can easily be used > here. >>>=20 >>> I prefer that the statement not be a pre-processor-like hack. >>=20 >> The interesting question then, is how much do we want to change the = CDDL >> language. If we do pragmas this is a standalone document. If we do > changes in >> the grammar then it is harder to make this standalone. >>=20 >>>=20 >>>> 6. If we use a pragma naming system, do we want to setup in >>> advance >> for >>> it >>>> to have namespaces so that a single module could be used with >> different >>>> compilers. I ended up using a different string than the OSS >> compiler did >>>> ("--<" ">--") to be able to do this but having a namespace could >> also >>>> support this. >>>=20 >>> I don't understand. >>=20 >> Suppose I write a CDDL compiler - called my_great_cddl_compiler and > Carsten >> writes one called no_so_good_cddl_compiler. I could reference = pragmas as >> ME:UseInt32 and CB:UseInt32 as separate pragmas in the same file and = each >> compiler would recognize that one that it implements and do the right > thing >> (which is to use some int sized at least 32 bits?) They could have > different >> behavior for the same name. >>=20 >>>=20 >>>> 7. What set of pragmas are we looking at to start with. XML >>> Schema >> has >>>> some attributes that can be used for controlling the compiler. >>> One >> of this >>>> is a location hint attribute which can be used for giving > alternate >>>> locations to use for finding a module (such as a location on my >> machine). >>>> There might be some other pragmas that might be useful to >>> specify as well. >>>> It might be easier to specify co-occurrence constraints using >> pragmas >>> rather >>>> than trying to put it directly into the language. >>>=20 >>> This is useful at the top-level file. >>> Particularly for a group of people who are working together. >>> For "location on my machine", I think that I'd rather be providing a >> command >>> flag, but I don't object to having ../.. paths or >> https://my.little.server.example/ >>> in a file. >>=20 >> Another one at the top level might be to use one of the more = interesting > things >> that the OSS compiler does is to allow one to say - This is the list = of > symbols to >> emit which can be used rather than either emit everything or emit the > first >> symbol in the file which made me do some really strange things in the = COSE >> CDDL. >>=20 >> Jim >>=20 >>=20 >>>=20 >>> -- >>> Michael Richardson , Sandelman Software Works >>> - =3D IPv6 IoT consulting =3D- >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Jul 1 07:49: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 785013A0B1B for ; Wed, 1 Jul 2020 07:49:42 -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 08A5Plvu8hFl for ; Wed, 1 Jul 2020 07:49:40 -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 BFE813A0C1A for ; Wed, 1 Jul 2020 07:49:39 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 1 Jul 2020 07:49:34 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: References: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> <58F93C93-9EC6-465E-B421-12AA69F17CAF@tzi.org> In-Reply-To: <58F93C93-9EC6-465E-B421-12AA69F17CAF@tzi.org> Date: Wed, 1 Jul 2020 07:49:32 -0700 Message-ID: <040901d64fb6$d6669ea0$8333dbe0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQJ5T9b3i55/+CwwqSdD3kqEjEw/wALtmhslp5VekwA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] CDDL Module Design 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, 01 Jul 2020 14:49:43 -0000 > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Tuesday, June 30, 2020 10:33 PM > To: Jim Schaad > Cc: cbor@ietf.org > Subject: Re: [Cbor] CDDL Module Design >=20 > Hi Jim, >=20 > we have had a long discussion about namespacing in the SDF work, and = came > up with: > https://www.ietf.org/id/draft-onedm-t2trg-sdf-00.html#name-names-and- > namespaces >=20 > Now SDF is not CDDL, but I think there are lessons to be learned. >=20 > For a while, we were thinking about using URIs to find referenced = parts of a > specification. This is comparable to the way Java does its module = naming; you > essentially need to put the code into the place that is implied by its = name. >=20 > Instead, we have decided to go for a push model, which is essentially = the way > C++, C#, and other languages maintain their namespaces. A module = declares > into which namespaces its names go. There is no automatic finding of > modules, but there also is no pain about who can contribute to a = namespace. There is also nothing to prevent the reuse of the same name in the in = the same namespace by multiple contributors. =20 >=20 > > On 2020-07-01, at 02:52, Jim Schaad wrote: > > > > Here is a topic that we can potentially discuss tomorrow if there is > > extra time on the agenda. > > > > When looking at a CDDL module design, there are a set of questions > > that I think need to be addressed: > > > > 1. What is the naming scheme to be used? Both XML Schema and ASN.1 > > use unique identifiers for a module. The problem with this approach > > is that a revised module has a new identifier even if all of the > > changes were preserving of the old module. This can also present > > problems if two different versions of the same module are used as it = can be > difficult to > > know which version of a module is being provided. I think = therefore it > > would be nice to have a naming system that recognizes version = numbers, >=20 > (I think you are talking about revision numbers. > Version numbers are often not what one wants; instead one should use = feature > identifiers.) I am happy with the term revision number here. Without having a better = description of what you think is the difference, I am not sure that I = see a significant one. I do have a potential problem with the use of = feature identifiers as we would not be tagging it with two different = meanings that need to be distinguished. At one point were we going to = use this for differences in the CDDL language and now you are also using = it for differences in CDDL sources. >=20 > > but > > can be used with a "latest version" mode. One possible way to do = this > > would be to use a query parameter to get a specific version of a > > module while without the query parameter the compiler grabs the most > > recent version it has. > > > > 2. Do want the naming scheme to be used to access a module name = from > > the web, and to create a server to host all of the IETF based CDDL = modules? >=20 > That was what we decided we didn=E2=80=99t want to do in SDF. >=20 > > 3. For any number of reasons we need to be able to state that some > > symbols are going to be imported from a different module. >=20 > Note how C++ doesn=E2=80=99t really do that. > (Well, if you declare a name and don=E2=80=99t define it, it needs to = be external.) And yet C++ does end up with header files which need to be included (or = duplicated) in order to have the same consistent view of what any class = does. It also will end up with problems if two different source files = declare (and define) a single name in the same namespace. >=20 > > There are some issues > > around doing a couple of other things: > > * If all symbols are imported then you either need to have a module > > based naming system or you need to ensure that there are no = collisions. >=20 > I would like to separate the external naming system from the internal = one we > use in a spec. >=20 > Note how a spec already today uses symbols from the prelude and from = the > spec itself. (This of course works =E2=80=9Cautomagically=E2=80=9D = only because the prelude is > fixed and you simply cannot use the symbols that the prelude squats = on.) >=20 > > * If only specific symbols are imported, then they could either be = a) > > made to be unique by renaming or b) made to be unique in the current > > module simply by how the module is written >=20 > Yes. >=20 > > 4. ASN.1 has a method to say that only specific symbols can be > > exported from a module. I have never used this capability and I am > > not clear that it would be useful to have here. Should we support = it anyway? >=20 > I think there might be a place for an advisory-level setting (as in = =E2=80=9Cthese names > will normally be imported if this module is imported = whole-sale=E2=80=9D). Experience > shows that there are good reasons to violate any = =E2=80=9Cencapsulation=E2=80=9D attempt, so I > would not disallow importing further names from a module explicitly. >=20 > > 5. How should the system be setup to be able to recognize this = capability. > > The suggestion in the freezer document currently is to use a pragma = system. > > Introducing a pragma system can easily be seen as a step to allow = for > > compilers of CDDL to be written. The A2C compiler that I wrote = used --# > > and #-- as the start and stop delimiters for pragmas as "--" is the > > start/stop comment character. (ASN.1 is not line based so there is = no > > comment till a return.) A similar approach can easily be used here. >=20 > This is the approach I would prefer. >=20 > However, there also is semantics imparted by using a symbol. > In actual CDDL usage, the symbols used become annotations in the post- > validation instance. These annotations will need to be namespaced, = and > possibly be linked to RDF names (which are URIs not intended for > dereferencing). >=20 > > 6. If we use a pragma naming system, do we want to setup in advance > > for it to have namespaces so that a single module could be used with > > different compilers. I ended up using a different string than the > > OSS compiler did ("--<" ">--") to be able to do this but having a > > namespace could also support this. >=20 > Indeed, we could play around with more than one module/namespace > management system, as long as there is a way to generate a basic CDDL > specification from each. >=20 > > 7. What set of pragmas are we looking at to start with. XML Schema > > has some attributes that can be used for controlling the compiler. > > One of this is a location hint attribute which can be used for = giving > > alternate locations to use for finding a module (such as a location = on my > machine). >=20 > Tempting, but this leads us back into pull land. >=20 > > There might be some other pragmas that might be useful to specify as = well. > > It might be easier to specify co-occurrence constraints using = pragmas > > rather than trying to put it directly into the language. >=20 > I think that all constraints need to be part of the language. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Jul 1 07:54: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 6D2493A0C2B for ; Wed, 1 Jul 2020 07:54:53 -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, RCVD_IN_MSPIKE_H4=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 nb8i0zX2B0Co for ; Wed, 1 Jul 2020 07:54:51 -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 0B0AD3A094C for ; Wed, 1 Jul 2020 07:54:50 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49xkls01JSzydy; Wed, 1 Jul 2020 16:54:48 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <24433.1593575640@localhost> Date: Wed, 1 Jul 2020 16:54:47 +0200 Cc: Jim Schaad , cbor@ietf.org X-Mao-Original-Outgoing-Id: 615308087.874382-9cea0f44cbeb294a04dfb91aeae0c521 Content-Transfer-Encoding: quoted-printable Message-Id: <51575EAF-1090-4989-A124-D19CE5553494@tzi.org> References: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> <24433.1593575640@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] CDDL Module Design 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, 01 Jul 2020 14:54:53 -0000 On 2020-07-01, at 05:54, Michael Richardson = wrote: >=20 > I prefer that the statement not be a pre-processor-like hack. The C/C++ preprocessor may be considered a hack because it operates at a = lexical level. We should not make that mistake. Apart from that, it = does useful things. Or, in other words, your hack may be my perfect layering. I would prefer it if a CDDL compiler (using that word in its english = sense) could spit out something that looks like CDDL 1.0 and has the = same semantics (well, maybe except for semantic names, which don=E2=80=99t= exist in CDDL 1.0). Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 1 08:30:45 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4609B3A0F2B for ; Wed, 1 Jul 2020 08:30: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 UJip-d1_nciL for ; Wed, 1 Jul 2020 08:30:42 -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 066283A0F2A for ; Wed, 1 Jul 2020 08:30:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3AD22389C2; Wed, 1 Jul 2020 11:27:53 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Odgli90TaAfl; Wed, 1 Jul 2020 11:27:52 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 187E4389BE; Wed, 1 Jul 2020 11:27:52 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B74223DE; Wed, 1 Jul 2020 11:30:39 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: Jim Schaad , cbor@ietf.org In-Reply-To: <51575EAF-1090-4989-A124-D19CE5553494@tzi.org> References: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> <24433.1593575640@localhost> <51575EAF-1090-4989-A124-D19CE5553494@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] CDDL Module Design 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, 01 Jul 2020 15:30:44 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 2020-07-01, at 05:54, Michael Richardson w= rote: >> >> I prefer that the statement not be a pre-processor-like hack. > The C/C++ preprocessor may be considered a hack because it operates at > a lexical level. We should not make that mistake. Apart from that, = it > does useful things. > Or, in other words, your hack may be my perfect layering. I agree. As has been pointed out in https://www.goodreads.com/book/show/44919.Working_Effectively_with_Legac= y_Code the preprocessor is a really good tool for inserting shims. But, gosh, I'm hoping that this won't be a requirement for CDDL? > I would prefer it if a CDDL compiler (using that word in its english > sense) could spit out something that looks like CDDL 1.0 and has the > same semantics (well, maybe except for semantic names, which don=E2= =80=99t > exist in CDDL 1.0). Hmm. yes. Okay. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl78rB8ACgkQgItw+93Q 3WVyjAf/VfBV9PTHdHlVBJ13eR1121PU+Y1/GQZWrCl/x8eBGQNXf/4o67pRzcM6 cQfYkal2ccavVgT90A1QPnNibS/8NKnlH9e/SELE0ONUnI5cnRpJDj8ZolEjIfhG K9S2FznGWWkpPvRzrCDdMXaAMMUKHYLawwc6B7kEw1hZUeHGCnK02v16AgsbPwxf YA4Efl70SbumHFfDKuBYGl5jFOKHN80zK9jEcc31zRRJLlXSjsaCzYFHDcIYM779 4WWqGEtxtBbwaaShykpnbW1nVeh+myIkWrFfTeQgJc4TYcBerD3d1IpMkXrIGNSw LMdJSjXBFJBsc0c9Bk2SiXKVZ17ktw== =4uLE -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 1 08:51:21 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 179953A0F55; Wed, 1 Jul 2020 08:51:19 -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 vb4zsWdoLqRm; Wed, 1 Jul 2020 08:51:16 -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 C710C3A0C20; Wed, 1 Jul 2020 08:51:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1CD00389C2; Wed, 1 Jul 2020 11:48:28 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id p9sgiQmOWoDd; Wed, 1 Jul 2020 11:48:26 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 58774389BE; Wed, 1 Jul 2020 11:48:26 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 05B3D3DE; Wed, 1 Jul 2020 11:51:14 -0400 (EDT) From: Michael Richardson To: Juergen Schoenwaelder cc: Carsten Bormann , draft-ietf-cbor-date-tag@ietf.org, cbor@ietf.org In-Reply-To: <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 01 Jul 2020 15:51:19 -0000 --=-=-= Content-Type: text/plain Juergen Schoenwaelder wrote: > I am not sure about Angela's passport but my passport in addition > states where I was born (which implies a certain time zone). I do not > know whether this example is useful or not, perhaps you just want to > say that in some use cases the time zone does not matter and this is > fine. > But on the other hand, two systems may tag an event with 1954-07-17 > but in UTC they would be not the same dates or two systems can tag an > event with two different dates but they are actually the same date in > UTC. In distributed systems operating across many timezones, simple > comparisons of date values can be surprising. The failure of the Nipponese to declare war on the USA on December 8, 1941 (they date of the attack on Pearl Habou^Hr in Japan...) is perhaps a better example of failures to get the time zone right. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl78sPEACgkQgItw+93Q 3WWCOAgAncaQw/tZ1lh5QChfuozVi5u+9XmMWEOUcfLE9lcG91MypVcl64KZrGgA VLufQWhHvbZFVS7rwCBrLw4JTVmivv2o/EnG9fm5F08CQaJubjjddT2MXilPBRBm dSToHVjngii+sbGdPH0NbgfhgY88czsRWiu+BLLVrd5lIykSlkkYVB271zZ/TWo7 03GrN1ekEhYnwgSeva4n/djI/2R6lFtx9FCxnjTaTHYrNR8Iw2JLUVJzdwrkhUNa f4MBJKEuqJ1f1NMHBrv0btPCYnFMevb1j2uOs5aOKVzvNNgFF7RtgCf0zfTfkkIH RDQ1Yo5LHFKwbJisdGfvVVJrP98KMg== =xfah -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 1 09:23: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 CE2A83A1207; Wed, 1 Jul 2020 09:23:39 -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, RCVD_IN_MSPIKE_H4=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 I0TVB34l3vBc; Wed, 1 Jul 2020 09:23:35 -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 07D0C3A1204; Wed, 1 Jul 2020 09:23:34 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49xmkC0L3PzygH; Wed, 1 Jul 2020 18:23:31 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <5244.1593618673@localhost> Date: Wed, 1 Jul 2020 18:23:30 +0200 Cc: Juergen Schoenwaelder , draft-ietf-cbor-date-tag@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 615313410.522671-87c34ccb2124fef2c5011838ad7546b9 Content-Transfer-Encoding: quoted-printable Message-Id: <04FEC6E5-F8E9-472D-A4D6-71C6C00D79E6@tzi.org> References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> <5244.1593618673@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 01 Jul 2020 16:23:40 -0000 On 2020-07-01, at 17:51, Michael Richardson = wrote: >=20 > The failure of the Nipponese to declare war on the USA on December 8, = 1941 > (they date of the attack on Pearl Habou^Hr in Japan...) is perhaps a = better > example of failures to get the time zone right. =E2=80=A6 and then there is V-E Day which is on 1945-05-08 everywhere = except in some countries usually more or less loosely related to the = Soviet Union, where it is on 1945-05-09 (even though the actual = capitulation document was signed on 21:20 Central European Summer Time, = which I think was 22:20 in Moscow which didn=E2=80=99t follow DST at the = time=E2=80=A6 =20 No time left to set up parades, so -05-09 it was :-). I=E2=80=99m citing this as an example where a calendar date was chosen = entirely by fiat, not based on the exact time of the actual event as = adjusted for a specific place/time zone. It does make sense to separate = calendar dates from day-length periods anchored on a time scale, and = this document is about representing calendar dates in CBOR. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 1 10:43: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 6A7863A080E for ; Wed, 1 Jul 2020 10:43: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 fgqBqF_eZ7dK for ; Wed, 1 Jul 2020 10:43:42 -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 57B2F3A07FF for ; Wed, 1 Jul 2020 10:43:41 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 1 Jul 2020 10:43:27 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: References: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> <24433.1593575640@localhost> <03db01d64f66$cc797a20$656c6e60$@augustcellars.com> <040401d64fb4$3d776230$b8662690$@augustcellars.com> <675ADAFF-7A32-49D1-835C-866432BFED58@tzi.org> In-Reply-To: <675ADAFF-7A32-49D1-835C-866432BFED58@tzi.org> Date: Wed, 1 Jul 2020 10:43:25 -0700 Message-ID: <042f01d64fcf$21428340$63c789c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQJ5T9b3i55/+CwwqSdD3kqEjEw/wAJfVF68AeUcwNMB7vWdugHja1Xkp2w7v8A= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] CDDL Module Design 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, 01 Jul 2020 17:43:45 -0000 > -----Original Message----- > From: Carsten Bormann > Sent: Wednesday, July 1, 2020 7:50 AM > To: Jim Schaad > Cc: cbor@ietf.org > Subject: Re: [Cbor] CDDL Module Design >=20 > Hi Jim, >=20 > On 2020-07-01, at 16:30, Jim Schaad wrote: > > > > Adding new issues to the list: > > > > 1. Are there any items for which the order of evaluation of the > > modules is going to be important. I think the answer is yes - > > consider adding elements to a group and then using the group in an = array. >=20 > What do you mean by =E2=80=9Cadding elements=E2=80=9D? >=20 > CDDL was designed to be insensitive to the order of rules, with the = exception of > the special meaning of the first rule. > I would expect that we compose at the level of rules. >=20 > However, prioritized choice and = =E2=80=9C/=3D=E2=80=9C/"//=3D=E2=80=9C conspire against that original > design. So, yes, where a choice is composed from multiple = =E2=80=9C/=3D=E2=80=9C/"//=3D=E2=80=9C rules, the > order is indeed relevant. This is the case that I was thinking of. =20 Module A group =3D ( element1 : string ) Module B group //=3D ( element2 : int ) Module C group //=3D (element3 : float ) Module D myArray =3D [ group ] >=20 > > 2. Are there places where the current definitions of anything get > > messed up with multiple modules and ordering. I am thinking of cuts > > in maps (where I can't remember which hill things died on) or maybe > > the newly proposed ..feature control. >=20 > Ordering within a group (different from the above) is important. > (That order controls cuts and other forms of prioritized choice, even = if the > group creates a map that by definition is not order-sensitive.) But = composition > from separate rules needs to be explicit here, e.g. in SDF: >=20 > sdfinfo =3D { > title: text > version: text > copyright: text > license: text > EXTENSION-POINT > } >=20 > EXTENSION-POINT =3D ( * text =3D> any ) >=20 > Putting the extension point first would enable the use of values that = do not > match `text` in title, version, copyright, and license entries. > But the specifier put EXTENSION-POINT last explicitly, so there is no = such > danger. The question comes if you add more elements to the end of the map. We = have had this discussion during the cut process and I think that I lost = that round but I would need to do a deep read on this to figure that = out. Things become interesting if you do sdfinfo =3D { title: text, version: text, copyright: text, license: text, More-attributes, EXTENSION-POINT } More-attributes =3D () >=20 >=20 > I can=E2=80=99t imagine at the moment how .feature would introduce new = order > sensitivities. I am not sure that I do either, it just is something that raises = questions about what happens if I add new fields to a map. In the = above, does the .feature on EXTENSION-POINT always come into effect if I = add something to More-attributes in a different module? Jim >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > > > Jim > > > > > >> -----Original Message----- > >> From: CBOR On Behalf Of Jim Schaad > >> Sent: Tuesday, June 30, 2020 10:17 PM > >> To: 'Michael Richardson' > >> Cc: cbor@ietf.org > >> Subject: Re: [Cbor] CDDL Module Design > >> > >> > >> > >>> -----Original Message----- > >>> From: Michael Richardson > >>> Sent: Tuesday, June 30, 2020 8:54 PM > >>> To: Jim Schaad > >>> Cc: cbor@ietf.org > >>> Subject: Re: [Cbor] CDDL Module Design > >>> > >>> > >>> Jim Schaad wrote: > >>>> 1. What is the naming scheme to be used? Both XML Schema and > >>> ASN.1 use > >>>> unique identifiers for a module. The problem with this approach > >>> is > >> that a > >>>> revised module has a new identifier even if all of the changes > > were > >>>> preserving of the old module. This can also present problems if > > two > >>>> different versions of the same module are used as it can be > >> difficult to > >>>> know which version of a module is being provided. > >>> > >>> Doesn't the version problem also include the "DLL hell" problem? > >>> That is: > >>> module A includes module B.1 which includes C.1 > >>> A includes module D.1 which includes C.2 > >>> > >>> and who knows if C.1 and C.2 can be used at the same time? > >>> > >>> So I totally agree that this is a problem. > >>> > >>>> I think therefore it > >>>> would be nice to have a naming system that recognizes version > >> numbers, > >>> but > >>>> can be used with a "latest version" mode. One possible way to > >>> do > >> this > >>> would > >>>> be to use a query parameter to get a specific version of a > >>> module > >> while > >>>> without the query parameter the compiler grabs the most recent > >> version it > >>>> has. > >>> > >>> I think that this is probably a very elegant solution. > >>> > >>>> 2. Do want the naming scheme to be used to access a module name > >> from > >>> the > >>>> web, and to create a server to host all of the IETF based CDDL > >> modules? > >>> > >>> A think that I dislike about the ENTITY stuff in XML is that the > >>> URLs are > >> way > >>> too specific. Do you want avoid that? Will it be some URN = space? > >> > >> I was thinking about the question of doing a URN instead of a URL - > >> hence > > the > >> term naming scheme. The interesting question is how should the > >> naming be done and what short of mapping is needed. One of the = nice > >> things about > > DOIs > >> is that they can be used as an indirect reference with a well known > >> server > > to > >> get actual URLs > >> > >>> > >>>> 3. For any number of reasons we need to be able to state that > >>> some symbols > >>>> are going to be imported from a different module. There are > >>> some > >> issues > >>>> around doing a couple of other things: > >>>> * If all symbols are imported then you either need to have a > >>> module > >> based > >>>> naming system or you need to ensure that there are no collisions. > >>>> * If only specific symbols are imported, then they could either > >>> be > >> a) made > >>>> to be unique by renaming or b) made to be unique in the current > >> module > >>>> simply by how the module is written > >>> > >>> Can you give an example of (b)? > >>> I think that Python mostly got this process right. > >> > >> (b) is just - don't define any conflicts between what I am = importing > >> and > > what I > >> have written in the text. If I am going to use COSE_Signed as an > >> import, > > then I > >> really should define a different symbol in the current CDDL file by > >> that > > name. > >> > >>> > >>>> 4. ASN.1 has a method to say that only specific symbols can be > >> exported > >>>> from a module. I have never used this capability and I am not > >>> clear > >> that it > >>>> would be useful to have here. Should we support it anyway? > >>> > >>> No. It just leads to stupid work arounds. > >>> _ for things that should not be exported, but not enforced. > >> > >> I tend to agree with this. One of the interesting questions would = be > > transitive > >> imports though. If module A imports COSE_Signed from module B can > >> module B import COSE_Signed from module B or must it reference = module > A. > >> I remember the first time I figured out that ASN.1 allows this and = to > >> be > > frank I > >> found it somewhat irritating. It does allow moving symbols between > > modules, > >> but that has the potential to break other modules suddenly. > >> > >>> > >>>> 5. How should the system be setup to be able to recognize this > >> capability. > >>>> The suggestion in the freezer document currently is to use a > >>> pragma system. > >>>> Introducing a pragma system can easily be seen as a step to > >>> allow > >> for > >>>> compilers of CDDL to be written. The A2C compiler that I wrote > >> used --# > >>>> and #-- as the start and stop delimiters for pragmas as "--" is > > the > >>>> start/stop comment character. (ASN.1 is not line based so there > >>> is > >> no > >>>> comment till a return.) A similar approach can easily be used > > here. > >>> > >>> I prefer that the statement not be a pre-processor-like hack. > >> > >> The interesting question then, is how much do we want to change the > >> CDDL language. If we do pragmas this is a standalone document. If > >> we do > > changes in > >> the grammar then it is harder to make this standalone. > >> > >>> > >>>> 6. If we use a pragma naming system, do we want to setup in > >>> advance > >> for > >>> it > >>>> to have namespaces so that a single module could be used with > >> different > >>>> compilers. I ended up using a different string than the OSS > >> compiler did > >>>> ("--<" ">--") to be able to do this but having a namespace could > >> also > >>>> support this. > >>> > >>> I don't understand. > >> > >> Suppose I write a CDDL compiler - called my_great_cddl_compiler and > > Carsten > >> writes one called no_so_good_cddl_compiler. I could reference > >> pragmas as > >> ME:UseInt32 and CB:UseInt32 as separate pragmas in the same file = and > >> each compiler would recognize that one that it implements and do = the > >> right > > thing > >> (which is to use some int sized at least 32 bits?) They could have > > different > >> behavior for the same name. > >> > >>> > >>>> 7. What set of pragmas are we looking at to start with. XML > >>> Schema > >> has > >>>> some attributes that can be used for controlling the compiler. > >>> One > >> of this > >>>> is a location hint attribute which can be used for giving > > alternate > >>>> locations to use for finding a module (such as a location on my > >> machine). > >>>> There might be some other pragmas that might be useful to > >>> specify as well. > >>>> It might be easier to specify co-occurrence constraints using > >> pragmas > >>> rather > >>>> than trying to put it directly into the language. > >>> > >>> This is useful at the top-level file. > >>> Particularly for a group of people who are working together. > >>> For "location on my machine", I think that I'd rather be providing = a > >> command > >>> flag, but I don't object to having ../.. paths or > >> https://my.little.server.example/ > >>> in a file. > >> > >> Another one at the top level might be to use one of the more > >> interesting > > things > >> that the OSS compiler does is to allow one to say - This is the = list > >> of > > symbols to > >> emit which can be used rather than either emit everything or emit = the > > first > >> symbol in the file which made me do some really strange things in = the > >> COSE CDDL. > >> > >> Jim > >> > >> > >>> > >>> -- > >>> Michael Richardson , Sandelman Software > Works > >>> - =3D IPv6 IoT consulting =3D- > >> > >> _______________________________________________ > >> 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 Jul 1 13: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 59E273A0D6F for ; Wed, 1 Jul 2020 13:52:41 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 8YlqwCmWbB7S for ; Wed, 1 Jul 2020 13:52:38 -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 A38B73A0D71 for ; Wed, 1 Jul 2020 13:52:38 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49xthh09r7zyhR; Wed, 1 Jul 2020 22:52:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <042f01d64fcf$21428340$63c789c0$@augustcellars.com> Date: Wed, 1 Jul 2020 22:52:35 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 615329555.583293-d275117bf30745827822db22875743df Content-Transfer-Encoding: quoted-printable Message-Id: <134B9212-5C96-4621-8A59-26051F5E1933@tzi.org> References: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> <24433.1593575640@localhost> <03db01d64f66$cc797a20$656c6e60$@augustcellars.com> <040401d64fb4$3d776230$b8662690$@augustcellars.com> <675ADAFF-7A32-49D1-835C-866432BFED58@tzi.org> <042f01d64fcf$21428340$63c789c0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] CDDL Module Design 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, 01 Jul 2020 20:52:41 -0000 Hi Jim, let me pick on your example some more :-) > This is the case that I was thinking of. =20 >=20 > Module A > group =3D ( > element1 : string > ) >=20 > Module B > group //=3D ( element2 : int ) >=20 > Module C > group //=3D (element3 : float ) >=20 > Module D > myArray =3D [ group ] Right. Note that `group` is a group choice, so only one (and exactly = one) of the alternatives can be chosen. As the types =E2=80=9Celement1", = =E2=80=9Celement2", =E2=80=9Celement3=E2=80=9D (yes, the bare words turn = into strings) do not overlap, the sequence in the choice is irrelevant. = If they did overlap, the first match would win, and the implied cut = makes sure the alternatives are not tried. So this is different from =E2=80=9Cadding entries to the group=E2=80=9D, = which would allow multiple of the entries to go into the array. >>> 2. Are there places where the current definitions of anything get >>> messed up with multiple modules and ordering. I am thinking of cuts >>> in maps (where I can't remember which hill things died on) or maybe >>> the newly proposed ..feature control. >>=20 >> Ordering within a group (different from the above) is important. >> (That order controls cuts and other forms of prioritized choice, even = if the >> group creates a map that by definition is not order-sensitive.) But = composition >> from separate rules needs to be explicit here, e.g. in SDF: >>=20 >> sdfinfo =3D { >> title: text >> version: text >> copyright: text >> license: text >> EXTENSION-POINT >> } >>=20 >> EXTENSION-POINT =3D ( * text =3D> any ) >>=20 >> Putting the extension point first would enable the use of values that = do not >> match `text` in title, version, copyright, and license entries. >> But the specifier put EXTENSION-POINT last explicitly, so there is no = such >> danger. >=20 > The question comes if you add more elements to the end of the map. We = have had this discussion during the cut process and I think that I lost = that round but I would need to do a deep read on this to figure that = out. Things become interesting if you do >=20 > sdfinfo =3D { > title: text, > version: text, > copyright: text, > license: text, > More-attributes, > EXTENSION-POINT > } >=20 > More-attributes =3D () I would expect you are trying to build a group choice that is called = More-attributes, so that we then can say: More-attributes //=3D (foo: =E2=80=9Cbar=E2=80=9D) Starting that choice with () doesn=E2=80=99t work very well =E2=80=94 = the empty group always matches, and because of prioritized choice, = nothing of the other alternatives is tried. So let=E2=80=99s start it with something that never matches. There is = no idiomatic way to do this in CDDL yet, so let me invent one: More-attributes =3D (1 .eq 2 =3D> 3) (This stochastically breaks the little brain of the CDDL tool, but = let=E2=80=99s ignore that for now; maybe there are better ways to build = impossible group choices.) Now I can add=20 More-attributes //=3D (foo: =E2=80=9Cbar=E2=80=9D) And More-attributes //=3D (3: 4) For good measure. The way this is used in the maps means that only exactly one of the = choices is ever added, which is not what I would call =E2=80=9Cadding = entries"; if you want to be able to add from all of them (and optionally = so), use * More-attributes, in the map. This is all a bit tedious, why it is not a very idiomatic way to build = up maps. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 1 14:40:58 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 3C0B53A0E04 for ; Wed, 1 Jul 2020 14:40:56 -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 g2FKBw5uvYw0 for ; Wed, 1 Jul 2020 14:40:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993333A0E03 for ; Wed, 1 Jul 2020 14:40:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5E795389CC; Wed, 1 Jul 2020 17:37:53 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6KE3J43WGOdm; Wed, 1 Jul 2020 17:37:52 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id EFF56389CB; Wed, 1 Jul 2020 17:37:51 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D771E62C; Wed, 1 Jul 2020 17:40:39 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , cbor@ietf.org, Jim Schaad In-Reply-To: <32409.1593617439@localhost> References: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> <24433.1593575640@localhost> <51575EAF-1090-4989-A124-D19CE5553494@tzi.org> <32409.1593617439@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] CDDL Module Design 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, 01 Jul 2020 21:40:56 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: >> On 2020-07-01, at 05:54, Michael Richardson wrote: >>> >>> I prefer that the statement not be a pre-processor-like hack. >> The C/C++ preprocessor may be considered a hack because it operates at >> a lexical level. We should not make that mistake. Apart from that, it >> does useful things. >> Or, in other words, your hack may be my perfect layering. > I agree. > As has been pointed out in > https://www.goodreads.com/book/show/44919.Working_Effectively_with_Legacy_Code > the preprocessor is a really good tool for inserting shims. The word I wanted was "seams", not shims. C gives you pre-processor seams, and link seams. Java lets you have neither. A seam is a way to replace some function, usually something low-level like "open(2)" or "socket(2)" so that in a unit test you can feed in test data rather than live data. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl79AtcACgkQgItw+93Q 3WWxsAf/fcy4JiAW3v4CpEJwrZQI+btP3xEVasK+rWAciK8ysQTA8o8GwOS7o66Q IAhWubFCWKAifim766iVzZSZEO4npTtFuHHzN2XuZVII9htCcX4uiqc9wLi15TBe sZf6gH6baT4XEJoUDzEESj+sBadaPhWHmM3dG62vUmsN98qDDTCgCa7J9MUghlzL fpdNP2CjQVL+P2v9Yi+QHauaa6ci8FbFWm8QopoIPQng2LJMvbY2xWWXm1jrAypQ Sr/M2ICDW/IRo2K5RiXWPaa+KNJ9M2UDL0NwAmcDXtuX2paK/E+U/HLlMHir1LpL rAjbypabp1aIyf7lc054Ok8XyK44Ug== =NO4z -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 1 14:57: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 D42963A0E1C for ; Wed, 1 Jul 2020 14:57:31 -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, RCVD_IN_MSPIKE_H4=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 3d57MA5R3EZg for ; Wed, 1 Jul 2020 14:57:29 -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 C4BB93A0E1A for ; Wed, 1 Jul 2020 14:57:28 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49xw7V4k0rzyjd; Wed, 1 Jul 2020 23:57:26 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <26498.1593639639@localhost> Date: Wed, 1 Jul 2020 23:57:26 +0200 Cc: cbor@ietf.org, Jim Schaad X-Mao-Original-Outgoing-Id: 615333446.2779469-671f50105a836c2d5bce3325284c5182 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> <24433.1593575640@localhost> <51575EAF-1090-4989-A124-D19CE5553494@tzi.org> <32409.1593617439@localhost> <26498.1593639639@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] CDDL Module Design 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, 01 Jul 2020 21:57:32 -0000 > On 2020-07-01, at 23:40, Michael Richardson wrote: >=20 >=20 > Michael Richardson wrote: >>> On 2020-07-01, at 05:54, Michael Richardson = wrote: >>>>=20 >>>> I prefer that the statement not be a pre-processor-like hack. >=20 >>> The C/C++ preprocessor may be considered a hack because it operates = at >>> a lexical level. We should not make that mistake. Apart from that, = it >>> does useful things. >=20 >>> Or, in other words, your hack may be my perfect layering. >=20 >> I agree. >> As has been pointed out in >> = https://www.goodreads.com/book/show/44919.Working_Effectively_with_Legacy_= Code >=20 >> the preprocessor is a really good tool for inserting shims. >=20 > The word I wanted was "seams", not shims. > C gives you pre-processor seams, and link seams. > Java lets you have neither. >=20 > A seam is a way to replace some function, usually something low-level = like > "open(2)" or "socket(2)" so that in a unit test you can feed in test = data > rather than live data. We call that a =E2=80=9Cmock=E2=80=9D (see [1] for another take of this, = which involves =E2=80=9Cfake=E2=80=9Ds). (Which may be implemented as a = shim, i.e., recurring on the real function, which when made into an art = form is also known as =E2=80=9Cadvising=E2=80=9D or =E2=80=9Cadvice=E2=80=9D= [2]. Or as a =E2=80=9Cstub=E2=80=9D.) Real programming involves the use of linker scripts, where you often can = rearrange some of the symbols or map one to the other. I think it would = be good if we have some isolation between the world of external names = (and name references) and the internal symbols in a specification. If = this is not to become too tedious, some optional automation of setting = up the mapping (and a way to gradually escape that automation) is = desirable. Hacking some of this functionality together at the lexical level (as the = preprocessor makes you do) usually provides leaky abstractions, where = the leak eventually bites you. That=E2=80=99s why CDDL has generics, = not macros (not that macros would be wrong, if done hygienically instead = of lexically). Gr=C3=BC=C3=9Fe, Carsten [1]: = https://www.infoworld.com/article/3143104/my-two-cents-on-fakes-stubs-mock= s-and-shims.html [2]: https://en.wikipedia.org/wiki/Advice_(programming) From nobody Wed Jul 1 15:44: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 2ED353A0EA8 for ; Wed, 1 Jul 2020 15:44:30 -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, 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 CD24AY-ggcUD for ; Wed, 1 Jul 2020 15:44:29 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (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 1A3D13A0E9D for ; Wed, 1 Jul 2020 15:44:28 -0700 (PDT) IronPort-SDR: qeDUOoFUqMATDIr6HXzP8eIPS2GnR1IJ/vl2cj3m92bL012n+tXYvx/Hl3TD19ddXZJMMNJP9T NHltLt4kfrfA== X-IronPort-AV: E=McAfee;i="6000,8403,9669"; a="164772186" X-IronPort-AV: E=Sophos;i="5.75,302,1589266800"; d="scan'208";a="164772186" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2020 15:44:28 -0700 IronPort-SDR: iapR//izinrjnUEFH3+UGi9Bl6/2M9VnD2rv3HPBBaWQqLldRfpJpYkq5bfUar3hNHzjKk5PuZ NzXYWWnNi4yw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,302,1589266800"; d="scan'208";a="425742291" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga004.jf.intel.com with ESMTP; 01 Jul 2020 15:44:27 -0700 Received: from tjmaciei-mobl1.localnet (10.255.231.158) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 1 Jul 2020 15:44:27 -0700 From: Thiago Macieira To: Date: Wed, 1 Jul 2020 15:44:21 -0700 Message-ID: <1706672.Z9AvMLu6bI@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <04FEC6E5-F8E9-472D-A4D6-71C6C00D79E6@tzi.org> References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <5244.1593618673@localhost> <04FEC6E5-F8E9-472D-A4D6-71C6C00D79E6@tzi.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.255.231.158] Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 01 Jul 2020 22:44:30 -0000 On Wednesday, 1 July 2020 09:23:30 PDT Carsten Bormann wrote: > I=E2=80=99m citing this as an example where a calendar date was chosen en= tirely by > fiat, not based on the exact time of the actual event as adjusted for a > specific place/time zone. It does make sense to separate calendar dates > from day-length periods anchored on a time scale, and this document is > about representing calendar dates in CBOR. What we need is a way to represent dates with and without a timezone=20 information. If a timezone is absent, it needs to be inferred from context,= =20 such as birthdays as discussed, and is usually interpreted as local time. Unix Timestamps have implied UTC (suitably un-corrected for leap seconds,=20 whatever) and RFC 3339 or ISO 8601 timestamps have a way of representing a= =20 timezone or its absence, including dates without time. Can you explain why we need these two new tags? Why doesn't it suffice to u= se=20 tags 0 and 1? It is possible to use a date without a time with tag 0, after= =20 all. I also question assigning a low tag number for the number-of-days-since-197= 0.=20 That's not standardising existing practice, it's inventing a new format. =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products From nobody Wed Jul 1 16:31: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 4D8D93A11C9 for ; Wed, 1 Jul 2020 16:31:17 -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, RCVD_IN_MSPIKE_H4=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 S_2pCbAl7U3i for ; Wed, 1 Jul 2020 16:31:14 -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 ED8B43A11C5 for ; Wed, 1 Jul 2020 16:31:13 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49xyCb2pr2zyrl; Thu, 2 Jul 2020 01:31:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <1706672.Z9AvMLu6bI@tjmaciei-mobl1> Date: Thu, 2 Jul 2020 01:31:08 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 615339068.150067-50ee7f6510845b7b9def7a0b446968a3 Content-Transfer-Encoding: quoted-printable Message-Id: <57901798-D61B-4FEB-B622-4201EE632396@tzi.org> References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <5244.1593618673@localhost> <04FEC6E5-F8E9-472D-A4D6-71C6C00D79E6@tzi.org> <1706672.Z9AvMLu6bI@tjmaciei-mobl1> To: Thiago Macieira X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 01 Jul 2020 23:31:17 -0000 Hi Thiago, On 2020-07-02, at 00:44, Thiago Macieira = wrote: >=20 > On Wednesday, 1 July 2020 09:23:30 PDT Carsten Bormann wrote: >> I=E2=80=99m citing this as an example where a calendar date was = chosen entirely by >> fiat, not based on the exact time of the actual event as adjusted for = a >> specific place/time zone. It does make sense to separate calendar = dates >> from day-length periods anchored on a time scale, and this document = is >> about representing calendar dates in CBOR. >=20 > What we need is a way to represent dates with and without a timezone=20= > information. If a timezone is absent, it needs to be inferred from = context,=20 > such as birthdays as discussed, and is usually interpreted as local = time. That may be your (and my) need, but it is not the need these two tags = were defined for. You are arguing that a date always needs to be a day-size period of time = anchored on a time scale. Yes, we need that, but giving the start time = or end time of that period is a good enough proxy for this (except where = you really care about both times), so we have made do with RFC 3339 (tag = 0) and UNIX/Posix (tag 1). The tag 1003 we proposed in draft-bormann-cbor-time-tag may be useful if = both ends are needed; we should flesh this out. What the tags in Mike=E2=80=99s and Joerg=E2=80=99s document try to = express is the abstract notion of a calendar date. This need comes up in documents that have a legal or social meaning (as = opposed to a technical one). > Unix Timestamps have implied UTC (suitably un-corrected for leap = seconds,=20 > whatever) and RFC 3339 or ISO 8601 timestamps have a way of = representing a=20 > timezone or its absence, including dates without time. Yes. Since this is about calendar dates, RFC 3339 full-date is what is = used in the new tag 1004. Tag 100 is an analogy that abuses the UNIX = epoch as a calendar epoch; this works well enough for all intents and = purposes of this draft and makes the UNIX time conversion library = immediately available for processing these dates. > Can you explain why we need these two new tags? Why doesn't it suffice = to use=20 > tags 0 and 1? It is possible to use a date without a time with tag 0, = after=20 > all. Tag 0 requires conformance to the production date-time in RFC 3339; this = is not very well said in RFC 7049: Tag value 0 is for date/time strings that follow the standard format described in [RFC3339], as refined by Section 3.3 of [RFC4287]. =E2=80=A6 but it becomes clear from section 3.3 of RFC 4287: https://tools.ietf.org/html/rfc4287#section-3.3 So, no, it is not possible to use a date without a time with tag 0, = unless we extend the domain of tag 0 (which the WG historically has = tried not to do for tags once defined). Tag 1004 to the rescue. > I also question assigning a low tag number for the = number-of-days-since-1970.=20 > That's not standardising existing practice, it's inventing a new = format. That is indeed valid criticism. =20 With respect to using a 1+1 tag number, I think the format for tag 100 = is suitably compact (the number will fit in 16 bits until the year 2149) = and dates are sufficiently widely used that the use of a 1+1 tag number = is justified. =20 With respect to inventing things, several other epochs come to mind (I = mentioned MJDs with 1858-11-17 as used in DEC VMS, MATLAB uses = 0000-01-00, what ever that is supposed to mean, and there are several = other attempts at defining a common era epoch, Microsoft Windows uses = 1601-01-01, Microsoft Excel uses 1900-01-01 or sometimes 1904-01-01), = but days since 1970-01-01 is both close enough to UNIX times to be easy = to use for software developers and short enough to fit in 16 bits for a = while. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 1 17:30: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 922B23A1290 for ; Wed, 1 Jul 2020 17:30:43 -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 8oBCtEYMTygo for ; Wed, 1 Jul 2020 17:30:42 -0700 (PDT) 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 136E63A1258 for ; Wed, 1 Jul 2020 17:30:41 -0700 (PDT) IronPort-SDR: 4aQX7KigerfsDTFiKquKEsvmw6RU+sb4K20E+4VnHg5c1Me2rDOnaz+gNqvhXpq/pleaziWnUM 9aByxIWKDxHA== X-IronPort-AV: E=McAfee;i="6000,8403,9669"; a="208272734" X-IronPort-AV: E=Sophos;i="5.75,302,1589266800"; d="scan'208";a="208272734" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2020 17:30:40 -0700 IronPort-SDR: dxSMyJrtv43GqxzFe1FpJkWQBwNEDLVtWo3bOS0UPvo61NcQeytLgL/F/oYqH3R1eoQukhTehf 1k4G79rDepRg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,302,1589266800"; d="scan'208";a="387169562" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga001.fm.intel.com with ESMTP; 01 Jul 2020 17:30:40 -0700 Received: from tjmaciei-mobl1.localnet (10.255.231.158) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 1 Jul 2020 17:30:40 -0700 From: Thiago Macieira To: Carsten Bormann CC: Date: Wed, 1 Jul 2020 17:30:39 -0700 Message-ID: <1672876.8Ir19O8pe9@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <57901798-D61B-4FEB-B622-4201EE632396@tzi.org> References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <1706672.Z9AvMLu6bI@tjmaciei-mobl1> <57901798-D61B-4FEB-B622-4201EE632396@tzi.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.255.231.158] Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 02 Jul 2020 00:30:45 -0000 On Wednesday, 1 July 2020 16:31:08 PDT Carsten Bormann wrote: > > What we need is a way to represent dates with and without a timezone > > information. If a timezone is absent, it needs to be inferred from > > context, > > such as birthdays as discussed, and is usually interpreted as local tim= e. >=20 > That may be your (and my) need, but it is not the need these two tags were > defined for. >=20 > You are arguing that a date always needs to be a day-size period of time > anchored on a time scale. Yes, we need that, but giving the start time or > end time of that period is a good enough proxy for this (except where you > really care about both times), so we have made do with RFC 3339 (tag 0) a= nd > UNIX/Posix (tag 1). The tag 1003 we proposed in draft-bormann-cbor-time-t= ag > may be useful if both ends are needed; we should flesh this out. >=20 > What the tags in Mike=E2=80=99s and Joerg=E2=80=99s document try to expre= ss is the abstract > notion of a calendar date. This need comes up in documents that have a > legal or social meaning (as opposed to a technical one). Sorry, you've lost me. Why can't the new tag 1004 accept: 2020-07-01 2020-07-01Z 2020-07-01-07:00 ? The GNU coreutils date tool accepts it: $ LC_ALL=3DC date -d 2020-07-01 Wed Jul 1 00:00:00 PDT 2020 $ LC_ALL=3DC date -d 2020-07-01Z Tue Jun 30 17:00:00 PDT 2020 > > Can you explain why we need these two new tags? Why doesn't it suffice = to > > use tags 0 and 1? It is possible to use a date without a time with tag = 0, > > after all. >=20 > Tag 0 requires conformance to the production date-time in RFC 3339; this = is > not very well said in RFC 7049: >=20 > Tag value 0 is for date/time strings that follow the standard format > described in [RFC3339], as refined by Section 3.3 of [RFC4287]. As a lenient parser, I've been accepting timestamps that include no time in= =20 tag 0. See:=20 https://code.qt.io/cgit/qt/qtbase.git/tree/tests/auto/corelib/serialization/ qcborvalue/tst_qcborvalue.cpp#n425 But in "be strict in what you generate", it always includes T00:00:00.000=20 time. > With respect to using a 1+1 tag number, I think the format for tag 100 is > suitably compact (the number will fit in 16 bits until the year 2149) and > dates are sufficiently widely used that the use of a 1+1 tag number is > justified. >=20 > With respect to inventing things, several other epochs come to mind (I > mentioned MJDs with 1858-11-17 as used in DEC VMS, MATLAB uses 0000-01-00, > what ever that is supposed to mean, and there are several other attempts = at > defining a common era epoch, Microsoft Windows uses 1601-01-01, Microsoft > Excel uses 1900-01-01 or sometimes 1904-01-01), but days since 1970-01-01 > is both close enough to UNIX times to be easy to use for software > developers and short enough to fit in 16 bits for a while. Sure, but who is going to use this? I suppose it's useful for microcontroll= ers=20 so they don't have to do string parsing, but this goes back to existing=20 practice. It seems to me you have a solution in search of a problem. I would recommend we don't add two semantically equivalent tags unless ther= e's=20 a very specific need for it. Unix Time and ISO-8601 / RFC 3339 formatted=20 strings, though overlapping, clearly have uses. =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products From nobody Wed Jul 1 19:00:29 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 196983A07C5; Wed, 1 Jul 2020 19:00:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <159365522705.4849.4181248928986915026@ietfa.amsl.com> Date: Wed, 01 Jul 2020 19:00:27 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-date-tag-03.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: Thu, 02 Jul 2020 02:00:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF. Title : Concise Binary Object Representation (CBOR) Tags for Date Authors : Michael B. Jones Anthony Nadalin Jörg Richter Filename : draft-ietf-cbor-date-tag-03.txt Pages : 5 Date : 2020-07-01 Abstract: The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (RFC 3339 date/time string) and tag 1 (Posix "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for an RFC 3339 date text string, for applications needing a textual date representation without a time. It also defines a CBOR tag for days since the Posix epoch, for applications needing a numeric date representation without a time. These tags are both for representations of calendar dates. It is intended as the reference document for the IANA registration of the CBOR tags defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-date-tag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-date-tag-03 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-date-tag-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-date-tag-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 1 19:05: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 81CE43A07E6 for ; Wed, 1 Jul 2020 19:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Xt1xJx-belIj for ; Wed, 1 Jul 2020 19:05:19 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650122.outbound.protection.outlook.com [40.107.65.122]) (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 7F8D73A07E5 for ; Wed, 1 Jul 2020 19:05:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CRZbqUyEEDNw+i+sFg7rVlDw9bD+/gpdLGdzznt3WFVIWwLHpkS/B3envn25i0lqtTFAggwRSwe93YYkIgMjXeafcw+vGHQVW8xncNB7A9+F1Pzob4ILAAg8XOAt+stvw5rV9VCDhtkWu+Lyh7y3sn0mWk/kC8HcNYcKdey5J1WIb9Ys/o07EJ1op9+oc+Q5FspvsA2BPxzNiYZmng7j/jcFCj1eWwHZ1WtwkWYLM8Oh1/tSqkMwUQnIuiLNnOYyNpfvsOZpS2LWQGKE04Y1IoRM2WMFgYFUR8exk0Sl8XjnIC0eMtnzxMWxdfWoVuxZZsvYAMHLokIeyW7RoXlh/Q== 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=kai9RcjuWoHH4yEO6K1xDgCANyF2jEoo1pyrrr7b8qQ=; b=VNLCTw4i5DnA4Kr8svtacZ0IazJ0sEXjVV9tjy6aqvME9z5ulVYuT/Vh9H9TUZ4gJ8xfy3SQ71fGHY0aLtQKH/kY4Ss0fFcBzhQ/ywPrCMybeyiB9ojiaMwlS2HNTfF2KkfbppNhe7DrGdDGPUNWKhpuKj9h4klp2j3+TSBZfo68tcUWi2TKzh3FpJgJQJeUxiVnRkgEbDR2wQPRIzfUWXDl7zS/Ucpt11/Afv8W99XWzwW0OEV6j6TzCTNyCAmkG+pExVAwrSPZhGNTfkk3yw2etVhVoS4dQThoACHnoqJODs7cExs7cchExSSYDq4+fpav66EAvf8nZbCWglovOA== 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=kai9RcjuWoHH4yEO6K1xDgCANyF2jEoo1pyrrr7b8qQ=; b=SZ8EF2pEgfO3Do7N+qVMTVxCKEbmGWW2ki/mDdVA9bx+pyWkw1v8Cjrh0NckyjV9DvT/Fy6SV8nsOrMwSixQvdYkSUDVzvXxxNyMxwEBR9ZBuuBezLeGiZxuyLH9gHONpY4YQXx5Uo+zUvwtU4XjNLyIGDUEAhgZYmq+0FSWel4= Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0833.namprd00.prod.outlook.com (2603:10b6:208:17e::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3194.0; Thu, 2 Jul 2020 02:05:01 +0000 Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::71f9:f0d5:7156:7942]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::71f9:f0d5:7156:7942%2]) with mapi id 15.20.3193.000; Thu, 2 Jul 2020 02:05:01 +0000 From: Mike Jones To: "cbor@ietf.org" Thread-Topic: [Cbor] I-D Action: draft-ietf-cbor-date-tag-03.txt Thread-Index: AdZQFTBdZCPFgtvVQvCpjGXkTrunFQ== Date: Thu, 2 Jul 2020 02:05:01 +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=88a25e00-651f-479e-ac90-eb29e982a243; 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-07-02T02:04:05Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: cb6875a1-1e0f-49ce-24bb-08d81e2c5474 x-ms-traffictypediagnostic: BL0PR00MB0833: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: flwpt2L8/dRaUwAdeWpwTWz6nN4auEbQAERuzfUOYEPcqtfbVM4G+mWEWFVuA0ExmoAy72IWMj79iRgFBPoa7zxWyiKE01CIUfgVZyYeVoesAqu5JIRhyGNJXdbZ64aQMGZhN9090cCTXCyNhFGNXg8A3nwHed8ClJg/STDX+KQ5HdKiliWMyzY7lksiF+81ITtArX1TDgUhNf+FNhWJ+L2Zs7awZ3+QWwnwNFFPEcAnIDVM2P7JAg5z2k9tDqBK6eQVaBFhllax/HNZepn1HIqWfVT7bNukJncb+B/3lwffMxJCYTuGLhpqC/wJby+70eqBOrfthav/rCM0CfHh/4v0KWxEXjg/FTS3FQEiLSY4azo87dak0Vt0LmDwvBQ9+W2eyJKXGZ1xh+lpluui6Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(39860400002)(136003)(376002)(346002)(7696005)(76116006)(10290500003)(82950400001)(82960400001)(9686003)(186003)(6916009)(5660300002)(478600001)(66574015)(26005)(8676002)(2906002)(6506007)(66556008)(66476007)(83380400001)(64756008)(66946007)(52536014)(66446008)(8936002)(53546011)(166002)(71200400001)(966005)(8990500004)(86362001)(33656002)(55016002)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: i8wu9KF40LUkzgLZkpAxMhscrvY78QjjKJoJtN/Kq2AoUT08ytmP3z3QSqSOTZNpFD3fo8tNLKd1MF6ubi9L17c4JYqv4P5pkgk7w4XEuIL4dwbiVhlmcg4mJ6dgA1h1V3MuWnAhhAY+jkUWSg+jFdl4W8ktjnZqcDddKmzo8BJ4fOSD6bLk4U90GrUCob0Hk0IMXkfW7InFnEUuuidaK8alzVYsuMa1v4iQAEQeO6OnRO8RJTYXmTDjayeLp+wZ2VvUkRioo6QvFIPQiS3F0HLnO7TZVe6uM44IfdIOHYX1fPt1FQKYqvdN/fY+0s8rIaAyP3Y/EjqgRYs0udCM+Qwds/g4pmhRtYgBUIScvvq60s/CfGjoA0jJv5Blpse/ONrjAqJppzuwjf8NmmqpralUbMKZATptXYKgBUTWRZAAdZepNDVp0w55A45x8mbosgYRuh8OERmvH4RbPX9aNmnsxiT5ex0nTdMv3mmSwec= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB068818CFCAB875118B48E32EF56D0MN2PR00MB0688namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cb6875a1-1e0f-49ce-24bb-08d81e2c5474 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2020 02:05:01.2109 (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: 9xz16y0Ym+f98UBepfcZXbeuQI4l5ViWXZN8b6f0PS3PlEEnzbYbXpmHkwJFBD55A/6qmWLliYMO2/1u1xTSAQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0833 Archived-At: Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-date-tag-03.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 02:05:22 -0000 --_000_MN2PR00MB068818CFCAB875118B48E32EF56D0MN2PR00MB0688namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVyIGRpc2N1c3Npb25zIG9uIHRvZGF5J3Mgd29ya2luZyBncm91cCBjYWxsIGFuZCBvbiB0aGUg bGlzdCwgSSd2ZSBwdWJsaXNoZWQgYW4gdXBkYXRlZCBkcmFmdCB3aXRoIHRoZXNlIGFkZGl0aW9u czoNCg0KICAqICAgQWRkZWQgc3RhdGVtZW50IHRoYXQgdGhlc2UgdGFncyBhcmUgYm90aCBmb3Ig cmVwcmVzZW50YXRpb25zIG9mIGNhbGVuZGFyIGRhdGVzLg0KICAqICAgRGVzY3JpYmVkIGNvbnNl cXVlbmNlcyBvZiB1c2luZyBjYWxlbmRhciBkYXRlcyBpbiBhY2Nlc3MgY29udHJvbCBkZWNpc2lv bnMuDQogICogICBBY2tub3dsZWRnZWQgYWRkaXRpb25hbCByZXZpZXdlcnMuDQoNCg0KDQpJIGJl bGlldmUgdGhhdCB0aGlzIHNwZWNpZmljYXRpb24gaXMgbm93IHJlYWR5IGZvciB0aGUgc2hlcGhl cmQgcmV2aWV3Lg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFRoYW5rcyBhbGwsDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ0JPUiA8Y2Jvci1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhh bGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMSwg MjAyMCA3OjAwIFBNDQpUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQpDYzogY2JvckBpZXRmLm9y Zw0KU3ViamVjdDogW0Nib3JdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0w My50eHQNCg0KDQoNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQoNClRoaXMgZHJhZnQgaXMg YSB3b3JrIGl0ZW0gb2YgdGhlIENvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXByZXNlbnRhdGlvbiBN YWludGVuYW5jZSBhbmQgRXh0ZW5zaW9ucyBXRyBvZiB0aGUgSUVURi4NCg0KDQoNCiAgICAgICAg VGl0bGUgICAgICAgICAgIDogQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIChD Qk9SKSBUYWdzIGZvciBEYXRlDQoNCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTWljaGFlbCBC LiBKb25lcw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgIEFudGhvbnkgTmFkYWxpbg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgIErDtnJnIFJpY2h0ZXINCg0KICAgICAgICAgICAgICBG aWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWNib3ItZGF0ZS10YWctMDMudHh0DQoNCiAgICAg ICAgICAgICAgUGFnZXMgICAgICAgICAgIDogNQ0KDQogICAgICAgICAgICAgIERhdGUgICAgICAg ICAgICA6IDIwMjAtMDctMDENCg0KDQoNCkFic3RyYWN0Og0KDQogICBUaGUgQ29uY2lzZSBCaW5h cnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIChDQk9SLCBSRkMgNzA0OSkgaXMgYSBkYXRhDQoNCiAg IGZvcm1hdCB3aG9zZSBkZXNpZ24gZ29hbHMgaW5jbHVkZSB0aGUgcG9zc2liaWxpdHkgb2YgZXh0 cmVtZWx5IHNtYWxsDQoNCiAgIGNvZGUgc2l6ZSwgZmFpcmx5IHNtYWxsIG1lc3NhZ2Ugc2l6ZSwg YW5kIGV4dGVuc2liaWxpdHkgd2l0aG91dCB0aGUNCg0KICAgbmVlZCBmb3IgdmVyc2lvbiBuZWdv dGlhdGlvbi4NCg0KDQoNCiAgIEluIENCT1IsIG9uZSBwb2ludCBvZiBleHRlbnNpYmlsaXR5IGlz IHRoZSBkZWZpbml0aW9uIG9mIENCT1IgdGFncy4NCg0KICAgUkZDIDcwNDkgZGVmaW5lcyB0d28g dGFncyBmb3IgdGltZTogQ0JPUiB0YWcgMCAoUkZDIDMzMzkgZGF0ZS90aW1lDQoNCiAgIHN0cmlu ZykgYW5kIHRhZyAxIChQb3NpeCAic2Vjb25kcyBzaW5jZSB0aGUgZXBvY2giKS4gIFNpbmNlIHRo ZW4sDQoNCiAgIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIGhhdmUgYmVjb21lIGtub3duLiAgVGhp cyBzcGVjaWZpY2F0aW9uDQoNCiAgIGRlZmluZXMgYSBDQk9SIHRhZyBmb3IgYW4gUkZDIDMzMzkg ZGF0ZSB0ZXh0IHN0cmluZywgZm9yIGFwcGxpY2F0aW9ucw0KDQogICBuZWVkaW5nIGEgdGV4dHVh bCBkYXRlIHJlcHJlc2VudGF0aW9uIHdpdGhvdXQgYSB0aW1lLiAgSXQgYWxzbw0KDQogICBkZWZp bmVzIGEgQ0JPUiB0YWcgZm9yIGRheXMgc2luY2UgdGhlIFBvc2l4IGVwb2NoLCBmb3IgYXBwbGlj YXRpb25zDQoNCiAgIG5lZWRpbmcgYSBudW1lcmljIGRhdGUgcmVwcmVzZW50YXRpb24gd2l0aG91 dCBhIHRpbWUuICBUaGVzZSB0YWdzIGFyZQ0KDQogICBib3RoIGZvciByZXByZXNlbnRhdGlvbnMg b2YgY2FsZW5kYXIgZGF0ZXMuICBJdCBpcyBpbnRlbmRlZCBhcyB0aGUNCg0KICAgcmVmZXJlbmNl IGRvY3VtZW50IGZvciB0aGUgSUFOQSByZWdpc3RyYXRpb24gb2YgdGhlIENCT1IgdGFncw0KDQog ICBkZWZpbmVkLg0KDQoNCg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZv ciB0aGlzIGRyYWZ0IGlzOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLWNib3ItZGF0ZS10YWcvDQoNCg0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJz aW9ucyBhdmFpbGFibGUgYXQ6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWNib3ItZGF0ZS10YWctMDMNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1pZXRmLWNib3ItZGF0ZS10YWctMDMNCg0KDQoNCkEgZGlmZiBmcm9tIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wMw0KDQoNCg0KDQoNClBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCg0KZnRwOi8vZnRwLmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy8NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpDQk9SIG1haWxpbmcgbGlzdA0KDQpDQk9SQGlldGYub3JnPG1h aWx0bzpDQk9SQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Nib3INCg== --_000_MN2PR00MB068818CFCAB875118B48E32EF56D0MN2PR00MB0688namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29QbGFpblRl eHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1p ZDo4ODA5NDAwMDY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjY0NDAyMDU3OCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBlciBkaXNjdXNzaW9ucyBvbiB0b2RheSdz IHdvcmtpbmcgZ3JvdXAgY2FsbCBhbmQgb24gdGhlIGxpc3QsIEkndmUgcHVibGlzaGVkIGFuIHVw ZGF0ZWQgZHJhZnQgd2l0aCB0aGVzZSBhZGRpdGlvbnM6PG86cD48L286cD48L3A+DQo8dWwgc3R5 bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkFkZGVkIHN0YXRlbWVudCB0aGF0IHRo ZXNlIHRhZ3MgYXJlIGJvdGggZm9yIHJlcHJlc2VudGF0aW9ucyBvZiBjYWxlbmRhciBkYXRlcy48 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+RGVzY3JpYmVkIGNvbnNlcXVlbmNlcyBvZiB1c2luZyBjYWxlbmRhciBk YXRlcyBpbiBhY2Nlc3MgY29udHJvbCBkZWNpc2lvbnMuPG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkFja25vd2xl ZGdlZCBhZGRpdGlvbmFsIHJldmlld2Vycy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+SSBiZWxpZXZlIHRoYXQgdGhpcyBzcGVjaWZpY2F0aW9uIGlzIG5vdyByZWFkeSBmb3Ig dGhlIHNoZXBoZXJkIHJldmlldy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyBhbGwsPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IENCT1IgJmx0O2Nib3ItYm91bmNlc0BpZXRm Lm9yZyZndDsgT24gQmVoYWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxicj4NClNlbnQ6 IFdlZG5lc2RheSwgSnVseSAxLCAyMDIwIDc6MDAgUE08YnI+DQpUbzogaS1kLWFubm91bmNlQGll dGYub3JnPGJyPg0KQ2M6IGNib3JAaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBbQ2Jvcl0gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTAzLnR4dDwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BIE5ldyBJbnRl cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMg ZGlyZWN0b3JpZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVz ZW50YXRpb24gTWFpbnRlbmFuY2UgYW5kIEV4dGVuc2lvbnMgV0cgb2YgdGhlIElFVEYuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBUaXRsZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA6IENvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXByZXNlbnRhdGlv biAoQ0JPUikgVGFncyBmb3IgRGF0ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1dGhvcnMm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBNaWNoYWVs IEIuIEpvbmVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QW50aG9ueSBOYWRhbGluPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSsO2cmcgUmljaHRlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTAzLnR4dDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFBhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDogNTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhdGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAyMDIwLTA3LTAxPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFRoZSBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVw cmVzZW50YXRpb24gKENCT1IsIFJGQyA3MDQ5KSBpcyBhIGRhdGE8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBmb3JtYXQgd2hvc2UgZGVzaWduIGdv YWxzIGluY2x1ZGUgdGhlIHBvc3NpYmlsaXR5IG9mIGV4dHJlbWVseSBzbWFsbDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGNvZGUgc2l6ZSwgZmFp cmx5IHNtYWxsIG1lc3NhZ2Ugc2l6ZSwgYW5kIGV4dGVuc2liaWxpdHkgd2l0aG91dCB0aGU8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBuZWVkIGZv ciB2ZXJzaW9uIG5lZ290aWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsgSW4gQ0JPUiwgb25lIHBvaW50IG9mIGV4dGVuc2liaWxpdHkgaXMgdGhlIGRlZmlu aXRpb24gb2YgQ0JPUiB0YWdzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7IFJGQyA3MDQ5IGRlZmluZXMgdHdvIHRhZ3MgZm9yIHRpbWU6IENCT1Ig dGFnIDAgKFJGQyAzMzM5IGRhdGUvdGltZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHN0cmluZykgYW5kIHRhZyAxIChQb3NpeCAmcXVvdDtzZWNv bmRzIHNpbmNlIHRoZSBlcG9jaCZxdW90OykuJm5ic3A7IFNpbmNlIHRoZW4sPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYWRkaXRpb25hbCByZXF1 aXJlbWVudHMgaGF2ZSBiZWNvbWUga25vd24uJm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlvbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGRlZmluZXMg YSBDQk9SIHRhZyBmb3IgYW4gUkZDIDMzMzkgZGF0ZSB0ZXh0IHN0cmluZywgZm9yIGFwcGxpY2F0 aW9uczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 IG5lZWRpbmcgYSB0ZXh0dWFsIGRhdGUgcmVwcmVzZW50YXRpb24gd2l0aG91dCBhIHRpbWUuJm5i c3A7IEl0IGFsc288bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyBkZWZpbmVzIGEgQ0JPUiB0YWcgZm9yIGRheXMgc2luY2UgdGhlIFBvc2l4IGVwb2No LCBmb3IgYXBwbGljYXRpb25zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgbmVlZGluZyBhIG51bWVyaWMgZGF0ZSByZXByZXNlbnRhdGlvbiB3aXRo b3V0IGEgdGltZS4mbmJzcDsgVGhlc2UgdGFncyBhcmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBib3RoIGZvciByZXByZXNlbnRhdGlvbnMgb2Yg Y2FsZW5kYXIgZGF0ZXMuJm5ic3A7IEl0IGlzIGludGVuZGVkIGFzIHRoZTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHJlZmVyZW5jZSBkb2N1bWVu dCBmb3IgdGhlIElBTkEgcmVnaXN0cmF0aW9uIG9mIHRoZSBDQk9SIHRhZ3M8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBkZWZpbmVkLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRy YWZ0IGlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFn LyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy88 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGVyZSBhcmUgYWxzbyBo dG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1jYm9yLWRhdGUtdGFnLTAzIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0 LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt Y2Jvci1kYXRlLXRhZy0wMzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wMyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTAzPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2Jvci1kYXRl LXRhZy0wMyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNib3ItZGF0 ZS10YWctMDM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0OjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy8iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNCT1Ig bWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBo cmVmPSJtYWlsdG86Q0JPUkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPkNCT1JAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jYm9yIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jYm9yPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_MN2PR00MB068818CFCAB875118B48E32EF56D0MN2PR00MB0688namp_-- From nobody Wed Jul 1 19:07: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 5C02E3A07E6; Wed, 1 Jul 2020 19:06:59 -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 IkWZNXmDguz9; Wed, 1 Jul 2020 19:06:57 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650122.outbound.protection.outlook.com [40.107.65.122]) (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 2A0B93A07E5; Wed, 1 Jul 2020 19:06:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UAo7ubARIMuRpa29uq1FsoE4qYXLkQ68M103G/hB+oprcXJTGb3AhWDGOD7atORRP7TNBrg2QNsA/LrchLeIAV+JlLgtmmvw8zOal3pSs0BMoonTcX5A2jZGECa5jvUO8h8qLjfZOCUUPNN+LDplvZOJHvOdRXgXO26Uc+4w9pCXLmW6pfQVvfq1UdBUnkkMLrz0RCUy2Pn9ABdwNfT8sGIS/5WB8Zu3qg2nCS435d6WcW4S/bbnCdFg9RsZ/+ABmGTafcG9nNkHvXGPnPXDvMRZgIfXvg0iylB+gc0I5knZPMzkT4Aib6HEAdpLyxS7FLk4OA+riOPhB0u/nMYSkQ== 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=VybSOQDbLA6fmLiEHrXX81C2Zgm/60WZaXDQuZM59uI=; b=J31jrdYkVTbubPRUvclzhxi/MdKYZKibN8/2nLJbf1fnekSy6/f0c5rrzfsfVTz5Weos/ywyoI9o9o3AA3zd/wuocJYoWG+sPPJO0GyG1EVJ9K/kp1gdGLxfrnYcbhRhytZj/AZypS9bfrixrnWLu4+BqDysghZy0ujpgyGqmiekV+EEuuV2uqj8kC0ovb6ndVKR7ipu1dCEfwjNBN/mSM5sk2QLim8CUp64S1JBlUtQR4cNNcc9vpsfwnefkCkL2QAPTAh1oRR23BQi9Tz+PunikX/E+2M60s+GObLx59nc1xX+cwHm+wd9xRSSK1LtOmuafySuMC/R38mtiL4DYw== 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=VybSOQDbLA6fmLiEHrXX81C2Zgm/60WZaXDQuZM59uI=; b=E+rj850JRTRC1G0GWL7aLjRUPnMVdgiFdYfLE2X22OTZI4+GKrcbrqCP+SIci5RTESse28Z1G7lefbqEqQIhaaILmhAEL8d+fHA+qg1prsWDHubDlwood5BCLyuS+RmXQgo79Xrr7F1m4nmCJximrEJ46+JPb2ssikaCXWOxUrM= Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0833.namprd00.prod.outlook.com (2603:10b6:208:17e::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3194.0; Thu, 2 Jul 2020 02:06:55 +0000 Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::71f9:f0d5:7156:7942]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::71f9:f0d5:7156:7942%2]) with mapi id 15.20.3193.000; Thu, 2 Jul 2020 02:06:55 +0000 From: Mike Jones To: Jim Schaad , "draft-ietf-cbor-date-tag@ietf.org" CC: "cbor@ietf.org" Thread-Topic: Review draft-ietf-cbor-date-tag-01 Thread-Index: AdZQFXRmogmmF2ncRc2sNli+KXJt/A== Date: Thu, 2 Jul 2020 02:06:55 +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=2490efad-78d3-4ee0-b04a-85de7c5e3d7b; 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-07-02T02:05:14Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 517bd897-2c06-4a99-0ab2-08d81e2c9862 x-ms-traffictypediagnostic: BL0PR00MB0833: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ha+1U8P3K4Asm5LGpepc0G2WAb5mlg6TRD+QPpMIDZIWUqDzWAVS6OBZYAzzF8iGfSdVPlG6vvNXrauyB1T0ZZEHYOClMCxYholj3WGcYAEa/Ox8V6lmsaCypjgGhE3/McAITLvNN8deA4+lj+EHrSRblbLYZqhCrezZeKPQiO4bAsiT+bYmpTY85ggiXI733SrBbduITnQH0J65XgJxdnnCNCG+nwTXnLrkGTgign5MoNnnM+ZaY23RVCUmp3Bn0J6mQVrcJZc1edLylM7myXMW66MOUzrTpYp5lUZSYCV3NGUHm3z9/Bt71kAW25tT33mzHA/EWUphvOVewRDKDiDbYriI0rxXkWLpRMRlbJcGnA8hdmu9VjvbyGoxu/mMzA+9Gc9bIZWz6QJA+WR7FA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(39860400002)(136003)(376002)(346002)(7696005)(76116006)(10290500003)(82950400001)(82960400001)(9686003)(186003)(5660300002)(478600001)(26005)(8676002)(2906002)(6506007)(66556008)(66476007)(83380400001)(64756008)(66946007)(52536014)(66446008)(8936002)(53546011)(166002)(71200400001)(966005)(8990500004)(86362001)(33656002)(110136005)(4326008)(55016002)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: L9adq1Bt2xxYwxy3LHd77/oCSqFJ11JJxFP3DlI47jztHfei2bB+7xHX6w/xOuSZSfyYqiWQz61y7mY+0QeT70NsiXmJL9DrE6du+PeBVX30um38d/CBOg+FOuQpZVqcRbB970CwNFN+bAbBSIA+pvNITPEslo6OtU71/QYqUBO+y8f0qTD9NvMGmoWiK5e3YIkMQAlHRlBdGMpXO6FdGyu93CL6COuu1z5nujZCyYaChfAuCz8fRtF7LR0oKrVYUIOCdesOGpEduK8M4ZDogziwdmQGBHCyQmRIe0yHvas33TPJZiUWQKYz3r/6hWsIgQlnqmVgb29b84N2wt4zZxBUb9RC+XI5WGUEq883D6w1fbvF1BIz43Vw7ZA7FLaUc4jHNpZpQUI2+t8Ch7h0KAiM7Id09QOrjeAo9rkPkDYqMFSW7KOkwHcQGdjRHrCc6JkRCo5d2pYOt7Zzfz+0ppegQJ1BXSVYffOrVyZPnyw= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0688D7B943447DD86E2988FCF56D0MN2PR00MB0688namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 517bd897-2c06-4a99-0ab2-08d81e2c9862 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2020 02:06:55.4342 (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: juoJITZGBtCTJrZ0Ch2c+mqW4eLAS8hqRXbTma75BBAyjoOHyg2VSAmLax4vJT7nNodtwdWm+wZPrAXLfHZ+ag== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0833 Archived-At: Subject: Re: [Cbor] Review draft-ietf-cbor-date-tag-01 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, 02 Jul 2020 02:06:59 -0000 --_000_MN2PR00MB0688D7B943447DD86E2988FCF56D0MN2PR00MB0688namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the suggested wording, Jim. I used your first sentence and subs= tituted a real-world example that should resonate with people for the latte= r part of the second one. -- Mike From: Jim Schaad Sent: Wednesday, July 1, 2020 7:28 AM To: Mike Jones ; draft-ietf-cbor-date-tag@ietf= .org Cc: cbor@ietf.org Subject: RE: Review draft-ietf-cbor-date-tag-01 That text does not represent what I was looking for. I was thinking of som= ething more along the lines of When using this data type for decision making, for examples access control,= it needs to be noted that since this does not represent a specific point i= n time the results of the evaluation can differ depending upon where the de= cision is made. This can represent more than 24-hour period in total as a= different 24-hours are used in the timezone -12:00 and +12:00. That text probably needs to get cleaned up and expanded but it gives the gi= st of what I am looking for. You can also look at the latest email on the = CBOR mailing list. Jim From: Mike Jones > Sent: Tuesday, June 30, 2020 6:43 PM To: Jim Schaad >; dra= ft-ietf-cbor-date-tag@ietf.org Cc: cbor@ietf.org Subject: RE: Review draft-ietf-cbor-date-tag-01 I created text. -- Mike ________________________________ From: Jim Schaad > Sent: Tuesday, June 30, 2020 6:13:22 PM To: Mike Jones >; draft-ietf-cbor-date-tag@ietf.org > Cc: cbor@ietf.org > Subject: [EXTERNAL] RE: Review draft-ietf-cbor-date-tag-01 > -----Original Message----- > From: Mike Jones > > Sent: Tuesday, June 30, 2020 5:41 PM > To: Jim Schaad >; d= raft-ietf-cbor-date-tag@ietf.org > Cc: cbor@ietf.org > Subject: RE: Review draft-ietf-cbor-date-tag-01 > > Hi Jim, > > I've applied these changes in https://tools.ietf.org/html/draft-ietf-cbor-date- > tag-02. > > Thanks again, > -- Mike > > -----Original Message----- > From: Mike Jones > Sent: Friday, June 12, 2020 11:52 AM > To: Jim Schaad >; d= raft-ietf-cbor-date-tag@ietf.org > Cc: cbor@ietf.org > Subject: RE: Review draft-ietf-cbor-date-tag-01 > > Thanks for your review, Jim. My replies are inline below... > > Is it time to start WGLC so others also get their reviews in? I'll note that the > IANA registrations have already occurred at > https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml. > > -----Original Message----- > From: Jim Schaad > > Sent: Thursday, June 11, 2020 11:48 AM > To: draft-ietf-cbor-date-tag@ietf.org > Cc: cbor@ietf.org > Subject: Review draft-ietf-cbor-date-tag-01 > > * Is there any chance that you can upgrade to using the v3 of xml2rfc schema? > If not then there is not an issue as the RFC Editor will do it. > > I haven't really learned all the ins and outs of the new syntax yet, so I'd have > more confidence with the RFC Editor doing it correctly than me. > > * Introduction: I prefer the abstract form of /date but not a time/date without > a time/ > > I agree and will make this change in the next published draft. > > * While this is something that is clear to me, I got a recent comment whe= n I > suggested that this be used elsewhere of, "But how does this work with time > zones?". Based on that I think that there needs to be some text about wh= y time > zones are not of interest here. > > Agreed and will do. > > * Section 3- I think that the second paragraph would be wise to distinguish > between a point in time and a date when looking at access control decisions. > > I understand your point in general. Is there particular text that you'd suggest > that I incorporate? No I don't have any text in mind. Jim > > Jim > > Thanks again, > -- Mike > --_000_MN2PR00MB0688D7B943447DD86E2988FCF56D0MN2PR00MB0688namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the suggest= ed wording, Jim.  I used your first sentence and substituted a real-wo= rld example that should resonate with people for the latter part of the sec= ond one.

 

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

 

From: Jim Schaad <ietf@augustcellars.com&g= t;
Sent: Wednesday, July 1, 2020 7:28 AM
To: Mike Jones <Michael.Jones@microsoft.com>; draft-ietf-cbor-= date-tag@ietf.org
Cc: cbor@ietf.org
Subject: RE: Review draft-ietf-cbor-date-tag-01

 

That text does not represent what I was looking for.=   I was thinking of something more along the lines of

 

When using this data type for decision making, for e= xamples access control, it needs to be noted that since this does not repre= sent a specific point in time the results of the evaluation can differ depe= nding upon where the decision is made.  This can represent more than  24-hour period in total as a different = 24-hours are used in the timezone -12:00 and +12:00.

 

That text probably needs to get cleaned up and expan= ded but it gives the gist of what I am looking for.  You can also look= at the latest email on the CBOR mailing list.

 

Jim

 

 

From: Mike Jones <Michael.Jones@microsoft.com>
Sent: Tuesday, June 30, 2020 6:43 PM
To: Jim Schaad <ietf@au= gustcellars.com>; draft-ietf-cbor-date-t= ag@ietf.org
Cc: cbor@ietf.org
Subject: RE: Review draft-ietf-cbor-date-tag-01

 

I created text.

 

-- Mike

 

From: Jim Schaad <ietf@augustcellars.com>
Sent: Tuesday, June 30, 2020 6:13:22 PM
To: Mike Jones <Mi= chael.Jones@microsoft.com>; draft-ietf-cbor-date-t= ag@ietf.org <dr= aft-ietf-cbor-date-tag@ietf.org>
Cc: cbor@ietf.org <cbor@ietf.org>
Subject: [EXTERNAL] RE: Review draft-ietf-cbor-date-tag-01

 



> -----Original Message-----
> From: Mike Jones <Mi= chael.Jones@microsoft.com>
> Sent: Tuesday, June 30, 2020 5:41 PM
> To: Jim Schaad <ietf@augu= stcellars.com>; draft-ietf-cbor-date-t= ag@ietf.org
> Cc: cbor@ietf.org
> Subject: RE: Review draft-ietf-cbor-date-tag-01
>
> Hi Jim,
>
> I've applied these changes in
https://tools= .ietf.org/html/draft-ietf-cbor-date-
> tag-02.
>
>            = ;            &n= bsp;       Thanks again,
>            = ;            &n= bsp;       -- Mike
>
> -----Original Message-----
> From: Mike Jones
> Sent: Friday, June 12, 2020 11:52 AM
> To: Jim Schaad <ietf@augu= stcellars.com>; draft-ietf-cbor-date-t= ag@ietf.org
> Cc: cbor@ietf.org
> Subject: RE: Review draft-ietf-cbor-date-tag-01
>
> Thanks for your review, Jim.  My replies are inline below...
>
> Is it time to start WGLC so others also get their reviews in?  I'= ll note
that the
> IANA registrations have already occurred at
> https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml.
>
> -----Original Message-----
> From: Jim Schaad <ietf@au= gustcellars.com>
> Sent: Thursday, June 11, 2020 11:48 AM
> To: draft-ietf-cb= or-date-tag@ietf.org
> Cc: cbor@ietf.org
> Subject: Review draft-ietf-cbor-date-tag-01
>
> * Is there any chance that you can upgrade to using the v3 of xml2rfc<= br> schema?
> If not then there is not an issue as the RFC Editor will do it.
>
> I haven't really learned all the ins and outs of the new syntax yet, s= o
I'd have
> more confidence with the RFC Editor doing it correctly than me.
>
> * Introduction:  I prefer the abstract form of /date but not a ti= me/date
without
> a time/
>
> I agree and will make this change in the next published draft.
>
> * While this is something that is clear to me, I got a recent comment = when
I
> suggested that this be used elsewhere of, "But how does this work= with
time
> zones?".  Based on that I think that there needs to be some = text about why
time
> zones are not of interest here.
>
> Agreed and will do.
>
> * Section 3- I think that the second paragraph would be wise to
distinguish
> between a point in time and a date when looking at access control
decisions.
>
> I understand your point in general.  Is there particular text tha= t you'd
suggest
> that I incorporate?

No I don't have any text in mind.

Jim

>
> Jim
>
>            = ;            &n= bsp;       Thanks again,
>            = ;            &n= bsp;       -- Mike
>

--_000_MN2PR00MB0688D7B943447DD86E2988FCF56D0MN2PR00MB0688namp_-- From nobody Thu Jul 2 17:21:52 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 A4FEF3A09D3; Thu, 2 Jul 2020 17:20:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: cbor@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373563266.30173.2786156161784199902@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:20:32 -0700 Archived-At: Subject: [Cbor] cbor - Requested session has been scheduled for IETF 108 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 00:20:41 -0000 Dear Francesca Palombini, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. cbor Session 1 (0:50 requested) Monday, 27 July 2020, Session II 1300-1350 Room Name: Room 2 size: 2 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/sessions/cbor.ics Request Information: --------------------------------------------------------- Working Group Name: Concise Binary Object Representation Maintenance and Extensions Area Name: Applications and Real-Time Area Session Requester: Francesca Palombini Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: saag ace core lamps cose lake gendispatch secdispatch Technology Overlap: rats suit teep lwig 6tisch 6lo anima t2trg lpwan Key Participant Conflict: cfrg emu tls oauth artarea roll sacm dots dnsop wpack People who must be present: Carsten Bormann Barry Leiba Jim Schaad Francesca Palombini Resources Requested: Special Requests: Please avoid collision with any Sec and IoT-related BoFs. --------------------------------------------------------- From nobody Thu Jul 2 22:28: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 E5B253A0CA9; Thu, 2 Jul 2020 22:28:43 -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, RCVD_IN_MSPIKE_H4=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 hGdR2K-CrVCs; Thu, 2 Jul 2020 22:28: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 6C22D3A0CA6; Thu, 2 Jul 2020 22:28:40 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49yk5f24r0zyTZ; Fri, 3 Jul 2020 07:28:38 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 615446917.9053921-b5c3f4f63088f5577dd523c75f704e63 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 3 Jul 2020 07:28:37 +0200 Message-Id: <46C68869-C5F5-4AB0-A605-4E5224352D0F@tzi.org> To: Ace Wg , core , cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Cbor] Constrained Node/Network Cluster @ IETF108: FINAL AGENDA X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 05:28:44 -0000 Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF108. Remember that, occasionally, further agenda changes do happen. There has been no change from the DRAFT AGENDA in the Conflicts I noted: LAKE/SUIT (!). ACE/RATS. (I think 6LO/COSE can be ignored.) The only significant change is that LAKE/SUIT/LOOPS has been exchanged with CORE/TLS/TSVWG (Tuesday 1410Z vs. Friday 1100Z). Also, the mysterious HACKATHON has vanished. All times appear to be in UTC, even though nothing says so in the text agenda; https://datatracker.ietf.org/meeting/agenda-utc gives the same times. This time, I have focused on the events in Week 31; please see the original agenda for Week 30 preliminaries. Gr=C3=BC=C3=9Fe, Carsten MONDAY, July 27, 2020 1100-1240 Session I Rm 1 ART dispatch Dispatch WG - Joint with ARTAREA Rm 2 IRTF pearg Privacy Enhancements and Assessments Research = Group Rm 5 SEC *** teep Trusted Execution Environment Provisioning WG 1300-1350 Session II Rm 2 ART *** cbor Concise Binary Object Representation Maintenance = and Extensions WG Rm 3 INT intarea Internet Area Working Group WG Rm 6 RTG babel Babel routing protocol WG Rm 7 RTG detnet Deterministic Networking WG 1410-1550 Session III Rm 1 ART webtrans WebTransport WG Rm 3 IRTF qirg Quantum Internet Research Group Rm 7 SEC gnap Grant Negotiation and Authorization Protocol WG TUESDAY, July 28, 2020 1100-1240 Session I Rm 1 ART *** asdf A Semantic Definition Format for Data and = Interactions of Things BOF Rm 2 INT 6man IPv6 Maintenance WG Rm 3 IRTF irtfopen IRTF Open Meeting Rm 8 TSV masque Multiplexed Application Substrate over QUIC = Encryption WG 1300-1350 Session II Rm 7 SEC mls Messaging Layer Security WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG 1410-1550 Session III Rm 1 ART *** core Constrained RESTful Environments WG Rm 6 SEC tls Transport Layer Security WG Rm 7 TSV tsvwg Transport Area Working Group WG WEDNESDAY, July 29, 2020 1100-1240 Session I Rm 4 RTG bier Bit Indexed Explicit Replication WG Rm 5 SEC *** ace Authentication and Authorization for Constrained = Environments WG Rm 6 SEC *** rats Remote ATtestation ProcedureS WG Rm 7 TSV quic QUIC WG 1300-1350 Session II Rm 1 INT *** 6lo IPv6 over Networks of Resource-constrained Nodes = WG Rm 4 RTG rift Routing In Fat Trees WG Rm 5 SEC *** cose CBOR Object Signing and Encryption WG Rm 6 TSV tsvarea Transport Area Open Meeting 1410-1550 IETF Plenary - Plenary THURSDAY, July 30, 2020 1100-1240 Session I Rm 3 OPS anima Autonomic Networking Integrated Model and = Approach WG Rm 4 RTG raw Reliable and Available Wireless WG Rm 5 SEC secdispatch Security Dispatch WG Rm 6 TSV tsvwg Transport Area Working Group WG 1300-1350 Session II Rm 4 INT *** lpwan IPv6 over Low Power Wide-Area Networks WG Rm 7 SEC saag Security Area Open Meeting 1410-1550 Session III Rm 2 INT add Adaptive DNS Discovery WG Rm 3 INT *** drip Drone Remote ID Protocol WG Rm 6 SEC acme Automated Certificate Management Environment WG FRIDAY, July 31, 2020 1100-1240 Session I Rm 5 SEC *** lake Lightweight Authenticated Key Exchange WG Rm 6 SEC *** suit Software Updates for Internet of Things WG Rm 7 TSV loops Local Optimizations on Path Segments BOF 1300-1350 Session II Rm 3 ART wpack Web Packaging WG Rm 4 INT 6man IPv6 Maintenance WG Rm 6 SEC emu EAP Method Update WG 1410-1550 Session III Rm 1 ART *** core Constrained RESTful Environments WG Rm 4 IRTF coinrg Computing in the Network Research Group Rm 7 SEC privacypass Privacy Pass WG From nobody Thu Jul 2 23:08: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 E16CA3A0D2A; Thu, 2 Jul 2020 23:08:32 -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, RCVD_IN_DNSWL_BLOCKED=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 D7MynTETPHAH; Thu, 2 Jul 2020 23:08:31 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14FE93A0C75; Thu, 2 Jul 2020 23:08:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 6EE24375; Fri, 3 Jul 2020 08:08:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id epQSidjAaOoK; Fri, 3 Jul 2020 08:08:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 3 Jul 2020 08:08:22 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1284920154; Fri, 3 Jul 2020 08:08:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id BRoq_eQjsCHe; Fri, 3 Jul 2020 08:08:21 +0200 (CEST) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 8A5C1200E4; Fri, 3 Jul 2020 08:08:21 +0200 (CEST) Date: Fri, 3 Jul 2020 08:08:20 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: Michael Richardson , draft-ietf-cbor-date-tag@ietf.org, cbor@ietf.org Message-ID: <20200703060820.ydmbdmp5fy2v6wgf@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> <5244.1593618673@localhost> <04FEC6E5-F8E9-472D-A4D6-71C6C00D79E6@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <04FEC6E5-F8E9-472D-A4D6-71C6C00D79E6@tzi.org> X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 03 Jul 2020 06:08:33 -0000 On Wed, Jul 01, 2020 at 06:23:30PM +0200, Carsten Bormann wrote: > On 2020-07-01, at 17:51, Michael Richardson wro= te: > >=20 > > The failure of the Nipponese to declare war on the USA on December 8,= 1941 > > (they date of the attack on Pearl Habou^Hr in Japan...) is perhaps a = better > > example of failures to get the time zone right. >=20 > =E2=80=A6 and then there is V-E Day which is on 1945-05-08 everywhere e= xcept in some countries usually more or less loosely related to the Sovie= t Union, where it is on 1945-05-09 (even though the actual capitulation d= ocument was signed on 21:20 Central European Summer Time, which I think w= as 22:20 in Moscow which didn=E2=80=99t follow DST at the time=E2=80=A6 =20 > No time left to set up parades, so -05-09 it was :-). >=20 > I=E2=80=99m citing this as an example where a calendar date was chosen = entirely by fiat, not based on the exact time of the actual event as adju= sted for a specific place/time zone. It does make sense to separate cale= ndar dates from day-length periods anchored on a time scale, and this doc= ument is about representing calendar dates in CBOR. > You often associate an event with a date. If you ignore timezone, then (1) two systems may associate the same event with different dates and (2) comparisons of date values may lead to "wrong" results. Since number of days since 1970-01-01 seems to be calculated in UTC (the document refers to the POSIX epoch which seems to be in UTC) (3) a 'date' value and a 'number of days since 1970-01-01' value can be "inconsistent". I think this deserves a clear warning. The -03 version has text in the security considerations section scoped to access control decisions but the fact that comparisons of date values and number of days since 1970-01-01 values may be surprising is not limited to access control, i.e., I prefer to see this explicitly discussed in section 2.1, perhaps including advice what should be done if proper comparison of date values is desirable. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 2 23:29:07 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EE13A0D4F; Thu, 2 Jul 2020 23:29:06 -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, RCVD_IN_MSPIKE_H4=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 AF4qyCCpaz5U; Thu, 2 Jul 2020 23:29:03 -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 5A4EC3A0D4E; Thu, 2 Jul 2020 23:29:03 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49ylRK4hrKzyV2; Fri, 3 Jul 2020 08:29:01 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <20200703060820.ydmbdmp5fy2v6wgf@anna.jacobs.jacobs-university.de> Date: Fri, 3 Jul 2020 08:29:01 +0200 Cc: draft-ietf-cbor-date-tag@ietf.org, Michael Richardson , cbor@ietf.org X-Mao-Original-Outgoing-Id: 615450541.248722-0851f1cc7216e6ee0bde1b9c3a248705 Content-Transfer-Encoding: quoted-printable Message-Id: <99A557CE-559D-409A-A3DC-5D20F2F55F5E@tzi.org> References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> <5244.1593618673@localhost> <04FEC6E5-F8E9-472D-A4D6-71C6C00D79E6@tzi.org> <20200703060820.ydmbdmp5fy2v6wgf@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 03 Jul 2020 06:29:06 -0000 > On 2020-07-03, at 08:08, Juergen Schoenwaelder = wrote: >=20 > On Wed, Jul 01, 2020 at 06:23:30PM +0200, Carsten Bormann wrote: >> On 2020-07-01, at 17:51, Michael Richardson = wrote: >>>=20 >>> The failure of the Nipponese to declare war on the USA on December = 8, 1941 >>> (they date of the attack on Pearl Habou^Hr in Japan...) is perhaps a = better >>> example of failures to get the time zone right. >>=20 >> =E2=80=A6 and then there is V-E Day which is on 1945-05-08 everywhere = except in some countries usually more or less loosely related to the = Soviet Union, where it is on 1945-05-09 (even though the actual = capitulation document was signed on 21:20 Central European Summer Time, = which I think was 22:20 in Moscow which didn=E2=80=99t follow DST at the = time=E2=80=A6 =20 >> No time left to set up parades, so -05-09 it was :-). >>=20 >> I=E2=80=99m citing this as an example where a calendar date was = chosen entirely by fiat, not based on the exact time of the actual event = as adjusted for a specific place/time zone. It does make sense to = separate calendar dates from day-length periods anchored on a time = scale, and this document is about representing calendar dates in CBOR. >>=20 >=20 > You often associate an event with a date. If you ignore timezone, then >=20 > (1) two systems may associate the same event with different dates and Yes, that was the point of my VE-day example. > (2) comparisons of date values may lead to "wrong" results. >=20 > Since number of days since 1970-01-01 seems to be calculated in UTC > (the document refers to the POSIX epoch which seems to be in UTC) Yes, that is not entirely clean. Since for many people (those west of = the Atlantic) the Posix epoch falls on 1969-12-31; we need to be = explicit that this is based on the calendar date of 1970-01-01. (Using = the Posix libraries still works out if you translate the calendar date = into a Posix time based on UTC, *and* translate back based on UTC as = well.) There may also be a need for a note that negative numbers are = applied using the proleptic Gregorian calendar; Angela Merkel=E2=80=99s = birthday is 100(-5844), and Charlemagne was crowned Roman Emperor on = 100(-427334). > (3) a 'date' value and a 'number of days since 1970-01-01' value can > be "inconsistent". Not sure how that can be; a common Gregorian calendar seems to be in = use. > I think this deserves a clear warning. The -03 version has text in the > security considerations section scoped to access control decisions but > the fact that comparisons of date values and number of days since > 1970-01-01 values may be surprising is not limited to access control, > i.e., I prefer to see this explicitly discussed in section 2.1, > perhaps including advice what should be done if proper comparison of > date values is desirable. I agree. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 2 23:47: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 6A6D13A0D6B; Thu, 2 Jul 2020 23:46:59 -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, RCVD_IN_DNSWL_BLOCKED=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 9Q2ueiNBUL7a; Thu, 2 Jul 2020 23:46:57 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3F83A0D6A; Thu, 2 Jul 2020 23:46:56 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D45AA375; Fri, 3 Jul 2020 08:46:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id GQZtByg0OC75; Fri, 3 Jul 2020 08:46:54 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 3 Jul 2020 08:46:54 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82A8320156; Fri, 3 Jul 2020 08:46:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id Kprq_zDp18IN; Fri, 3 Jul 2020 08:46:54 +0200 (CEST) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 1D07220154; Fri, 3 Jul 2020 08:46:54 +0200 (CEST) Date: Fri, 3 Jul 2020 08:46:52 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: draft-ietf-cbor-date-tag@ietf.org, Michael Richardson , cbor@ietf.org Message-ID: <20200703064652.m7tuvfcglxyvfque@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> <5244.1593618673@localhost> <04FEC6E5-F8E9-472D-A4D6-71C6C00D79E6@tzi.org> <20200703060820.ydmbdmp5fy2v6wgf@anna.jacobs.jacobs-university.de> <99A557CE-559D-409A-A3DC-5D20F2F55F5E@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <99A557CE-559D-409A-A3DC-5D20F2F55F5E@tzi.org> Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 03 Jul 2020 06:47:00 -0000 On Fri, Jul 03, 2020 at 08:29:01AM +0200, Carsten Bormann wrote: > > > > (3) a 'date' value and a 'number of days since 1970-01-01' value can > > be "inconsistent". > > Not sure how that can be; a common Gregorian calendar seems to be in use. > A system may have determined a local date 1970-01-01, which in UTC is 1969-12-31 or 1970-01-01 or 1970-01-02. Hence, days since 1970-01-01 may be -1, 0, or 1, depending on how this is calculated. If the 'number of days since 1970-01-01' is always calculated in the same unknown local timezone as the local date value, the problem goes away, but it is likely difficult to enforce this (unless timzone information is explicit). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 2 23:47:37 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 EC70E3A0D6C; Thu, 2 Jul 2020 23:47:35 -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, RCVD_IN_MSPIKE_H4=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 0-SNGTd2zw_e; Thu, 2 Jul 2020 23:47:34 -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 A284C3A0D6B; Thu, 2 Jul 2020 23:47:33 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49ylrh09pGzyZn; Fri, 3 Jul 2020 08:47:31 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <99A557CE-559D-409A-A3DC-5D20F2F55F5E@tzi.org> Date: Fri, 3 Jul 2020 08:47:31 +0200 Cc: draft-ietf-cbor-date-tag@ietf.org, Michael Richardson , cbor@ietf.org X-Mao-Original-Outgoing-Id: 615451651.579178-68ec8ab1343bc1154bdf603597e198bc Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> <5244.1593618673@localhost> <04FEC6E5-F8E9-472D-A4D6-71C6C00D79E6@tzi.org> <20200703060820.ydmbdmp5fy2v6wgf@anna.jacobs.jacobs-university.de> <99A557CE-559D-409A-A3DC-5D20F2F55F5E@tzi.org> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 03 Jul 2020 06:47:36 -0000 On 2020-07-03, at 08:29, Carsten Bormann wrote: >=20 > Charlemagne was crowned Roman Emperor on 100(-427334). Well, maybe, 100(-426971) (tried a different date/time library; that is = an amazing amount of brokenness =E2=80=94 a year and three days off). = Maybe don=E2=80=99t recommend numeric day counts to historians... Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 3 00:05:58 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 959E13A0DBE; Fri, 3 Jul 2020 00:05:54 -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, RCVD_IN_MSPIKE_H4=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 yUAyzfq01s0h; Fri, 3 Jul 2020 00:05:52 -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 71C513A0DA3; Fri, 3 Jul 2020 00:05:52 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49ymFp6WhDzyV1; Fri, 3 Jul 2020 09:05:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <20200703064652.m7tuvfcglxyvfque@anna.jacobs.jacobs-university.de> Date: Fri, 3 Jul 2020 09:05:50 +0200 Cc: draft-ietf-cbor-date-tag@ietf.org, Michael Richardson , cbor@ietf.org X-Mao-Original-Outgoing-Id: 615452750.485857-97bab8709d0a75c98814afdbfd82cf10 Content-Transfer-Encoding: quoted-printable Message-Id: <2A137293-075C-4862-91C2-CC583B9B2FF6@tzi.org> References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> <5244.1593618673@localhost> <04FEC6E5-F8E9-472D-A4D6-71C6C00D79E6@tzi.org> <20200703060820.ydmbdmp5fy2v6wgf@anna.jacobs.jacobs-university.de> <99A557CE-559D-409A-A3DC-5D20F2F55F5E@tzi.org> <20200703064652.m7tuvfcglxyvfque@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 03 Jul 2020 07:05:57 -0000 > On 2020-07-03, at 08:46, Juergen Schoenwaelder = wrote: >=20 > On Fri, Jul 03, 2020 at 08:29:01AM +0200, Carsten Bormann wrote: >>=20 >>=20 >>> (3) a 'date' value and a 'number of days since 1970-01-01' value can >>> be "inconsistent". >>=20 >> Not sure how that can be; a common Gregorian calendar seems to be in = use. >>=20 >=20 > A system may have determined a local date 1970-01-01, which in UTC is > 1969-12-31 or 1970-01-01 or 1970-01-02. Yes, but the UTC time is irrelevant; this is about calendar dates, and = if the calendar on my wall says 1969-12-31, that is the date = (represented as 100(-1)). So I think what you are saying is that the current calendar date at the = same instant in time (*) may be different in different parts of the = world? That=E2=80=99s why we want to get away from anchoring these dates on a = time scale. > Hence, days since 1970-01-01 > may be -1, 0, or 1, depending on how this is calculated. If the > 'number of days since 1970-01-01' is always calculated in the same > unknown local timezone as the local date value, the problem goes away, > but it is likely difficult to enforce this (unless timzone information > is explicit). Doing this conversion in a time zone is dangerous; you=E2=80=99ll need = to make sure that you properly round off the daylight savings time = transitions. Better to always to this in world time (UTC), which is = then benign (unless your libraries have a bug, see previous message). Counting calendar sheets ripped off the wall is rather unambiguous, = though. The problems that you are alluding to come from transitioning between = the calendar day domain and the time anchored on a time scale domain; = additional problems are caused with this when the time involves time = zones that vary in world time offset. I think we need firmer text that makes clear that the dates covered by = tags 100 and 1004 are calendar dates, and that conversions between these = and times on a timescale can be done, but require attention and usually = some additional context. Gr=C3=BC=C3=9Fe, Carsten (*) No, I=E2=80=99m not opening the relativistic can of worms. From nobody Fri Jul 3 03:32:26 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 C2A983A0C00; Fri, 3 Jul 2020 03:32:24 -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 PGFzp6mI6c6R; Fri, 3 Jul 2020 03:32:22 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BAC03A0BFE; Fri, 3 Jul 2020 03:32:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CE6C6375; Fri, 3 Jul 2020 12:32:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ffqib4Wv5TVx; Fri, 3 Jul 2020 12:32:13 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 3 Jul 2020 12:32:13 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D1E720154; Fri, 3 Jul 2020 12:32:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id xsF17ONENE4t; Fri, 3 Jul 2020 12:32:13 +0200 (CEST) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 0DAD1200E4; Fri, 3 Jul 2020 12:32:13 +0200 (CEST) Date: Fri, 3 Jul 2020 12:32:12 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: draft-ietf-cbor-date-tag@ietf.org, Michael Richardson , cbor@ietf.org Message-ID: <20200703103212.kwl5pbxubznjqpf6@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> <5244.1593618673@localhost> <04FEC6E5-F8E9-472D-A4D6-71C6C00D79E6@tzi.org> <20200703060820.ydmbdmp5fy2v6wgf@anna.jacobs.jacobs-university.de> <99A557CE-559D-409A-A3DC-5D20F2F55F5E@tzi.org> <20200703064652.m7tuvfcglxyvfque@anna.jacobs.jacobs-university.de> <2A137293-075C-4862-91C2-CC583B9B2FF6@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A137293-075C-4862-91C2-CC583B9B2FF6@tzi.org> Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 03 Jul 2020 10:32:25 -0000 On Fri, Jul 03, 2020 at 09:05:50AM +0200, Carsten Bormann wrote: [...] > Counting calendar sheets ripped off the wall is rather unambiguous, though. > > The problems that you are alluding to come from transitioning between the calendar day domain and the time anchored on a time scale domain; additional problems are caused with this when the time involves time zones that vary in world time offset. You like to view a date as something entirely detached from the notion of time. I am not sure what the use cases for this are, in particular for computers. I can see, however, a number of use cases where a date is associated with a specific event and in these situations the date value is ambiguous since multiple systems rightfully may assign different dates to the same event (the same point in time). Hence, code comparing date values or making calculations with them has to be careful that surprises may happen. /js PS: There are even events where there is no natural time zone that can be associated with the event, like the first step on the moon. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jul 3 05:11:08 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 41F3F3A0D19; Fri, 3 Jul 2020 05:11:06 -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, RCVD_IN_MSPIKE_H4=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 Cye_ztXVEdN2; Fri, 3 Jul 2020 05:11:04 -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 4CD853A0D0F; Fri, 3 Jul 2020 05:11:02 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49yv1w6w1WzyXp; Fri, 3 Jul 2020 14:11:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <20200703103212.kwl5pbxubznjqpf6@anna.jacobs.jacobs-university.de> Date: Fri, 3 Jul 2020 14:11:00 +0200 Cc: draft-ietf-cbor-date-tag@ietf.org, Michael Richardson , cbor@ietf.org X-Mao-Original-Outgoing-Id: 615471060.372417-362f42fcb781453ee030dae3dea04f6f Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> <5244.1593618673@localhost> <04FEC6E5-F8E9-472D-A4D6-71C6C00D79E6@tzi.org> <20200703060820.ydmbdmp5fy2v6wgf@anna.jacobs.jacobs-university.de> <99A557CE-559D-409A-A3DC-5D20F2F55F5E@tzi.org> <20200703064652.m7tuvfcglxyvfque@anna.jacobs.jacobs-university.de> <2A137293-075C-4862-91C2-CC583B9B2FF6@tzi.org> <20200703103212.kwl5pbxubznjqpf6@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 03 Jul 2020 12:11:06 -0000 On 2020-07-03, at 12:32, Juergen Schoenwaelder = wrote: >=20 > PS: There are even events where there is no natural time zone that can > be associated with the event, like the first step on the moon. (For those who weren=E2=80=99t there when it happened:) Indeed, Monday, 1969-07-21T02:56:15Z. Most Americans will tell you Sunday 1969-07-20 for the first steps. = The exact time was actually specifically chosen to occur on prime time = TV in the US (and then was slightly delayed, but managed to stay in = window), which spans several time zones, which all have this on = 1969-07-20. Yes, I agree we should have some text on this (not the moon landing, but = the issues in converting between calendar dates and times anchored on = time scales). Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 3 09:48:21 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 EF9703A0816 for ; Fri, 3 Jul 2020 09:48:19 -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, RCVD_IN_MSPIKE_H4=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 0xB3F4v7uUhz for ; Fri, 3 Jul 2020 09:48:16 -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 8D5713A080C for ; Fri, 3 Jul 2020 09:48:16 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49z19p3qGgzyXP; Fri, 3 Jul 2020 18:48:14 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <4F2A6C32-A89C-472F-AC22-455FA7DF6BC4@tzi.org> Date: Fri, 3 Jul 2020 18:48:14 +0200 X-Mao-Original-Outgoing-Id: 615487694.041067-5ef6c89457fdc85df1117e6c09b7bf83 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F2A6C32-A89C-472F-AC22-455FA7DF6BC4@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Update of OID draft 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, 03 Jul 2020 16:48:20 -0000 I cleaned this up further and submitted as -07. (I also added a bit of CDDL, let=E2=80=99s discuss whether that=E2=80=99s = the right approach.) URL: https://www.ietf.org/id/draft-bormann-cbor-tags-oid-07.html Status: https://datatracker.ietf.org/doc/draft-bormann-cbor-tags-oid/ Htmlized: https://tools.ietf.org/html/draft-bormann-cbor-tags-oid-07 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-cbor-tags-oid-07 I believe this draft is ready for a WG adoption call. In that process, we might want to discuss the intended status = (Informational + eventual downref license vs. Standards Track). Gr=C3=BC=C3=9Fe, Carsten > On 2020-07-01, at 00:06, Carsten Bormann wrote: >=20 > I put a proposed update of the OID draft up at the branch >=20 > https://github.com/cabo/cbor-oid/tree/cleanup >=20 > Please see >=20 > = https://raw.githack.com/cabo/cbor-oid/cleanup/draft-bormann-cbor-tags-oid.= html >=20 > for the HTML, and, if you want to see the gory details, >=20 > = https://tools.ietf.org/rfcdiff?url1=3Ddraft-bormann-cbor-tags-oid-06.txt&u= rl2=3Dhttps://raw.githack.com/cabo/cbor-oid/cleanup/draft-bormann-cbor-tag= s-oid.txt >=20 > for the diff from -06. >=20 > This version removes anything but the actual Object-Identifier tag = definitions (and keeps a little bit of explanatory text around them). >=20 > Comments welcome (maybe we can discuss this approach, if not details, = in the CBOR Interim today?). If we like that, I=E2=80=99m going to ask = for WG adoption next. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Fri Jul 3 11:40: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 707BD3A0D3F; Fri, 3 Jul 2020 11:40:07 -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 vD7EnF4gB4CU; Fri, 3 Jul 2020 11:40:06 -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 EDD473A0D3A; Fri, 3 Jul 2020 11:40:02 -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; Fri, 3 Jul 2020 11:39:55 -0700 From: Jim Schaad To: CC: Date: Fri, 3 Jul 2020 11:39:53 -0700 Message-ID: <000801d65169$5915dfb0$0b419f10$@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: AdZRZH8ZZu7a2NxcQvq/7ir45/t56g== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Review draft-bormann-cbor-tags-oid-07 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, 03 Jul 2020 18:40:07 -0000 * Section 1 - There has been a recent argument on one of the mailing lists about the question between the value of an encoding and the contents of the value of the encoding. I think that it needs to be highlighted that this is referring to the V portion of TLV for BER. "The contents of these encodings..." is mostly likely going to cause somebody to have the same problem. * Section 1 - last sentence - What it is being referred to here? * Section 2 - What is a "primary integer"? Is this one that has not yet gone to high school? * Section 2.1 - I don't think it is the tag that is invalid, but rather the value in the tag that is invalid. The "tagged value"? (Is this a well-formed error?) * You need to update references and text to the CBOR bis document. * Section 5 - Does it make any sense to allow the tags to be specified in a nested manner? TBD110(X) [TBD111(Y)] ? * Section 5 - One way to handle the problem would be to define a new tag which cancels any tag inheritance as a general purpose thing. This might also be useful for other tags which might be defined in this way in the future. * Section 7 - I would agree that having an operator that parses string dotted format does not make any sense. It might be useful to include the .oid operator however which has the property of doing the magic. * Section 7 - I need an example of .sdnv because I am having a problem figuring out how it would be used. * Section 7 - If we do nesting behavior on these tags, then a control operator to make A relative to B would be useful as well. Jim From nobody Fri Jul 3 15:47: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 0CA283A0A2B; Fri, 3 Jul 2020 15:47:46 -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, RCVD_IN_MSPIKE_H4=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 yClhaMYd_afD; Fri, 3 Jul 2020 15:47: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 A08133A0A27; Fri, 3 Jul 2020 15:47:41 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49z98X03MgzyVf; Sat, 4 Jul 2020 00:47:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <000801d65169$5915dfb0$0b419f10$@augustcellars.com> Date: Sat, 4 Jul 2020 00:47:39 +0200 Cc: draft-bormann-cbor-tags-oid@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 615509259.561434-dd21459be295ed41f94a64164a33f254 Content-Transfer-Encoding: quoted-printable Message-Id: <5E9374BB-8893-4CB5-9548-672BC9556E55@tzi.org> References: <000801d65169$5915dfb0$0b419f10$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Review draft-bormann-cbor-tags-oid-07 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, 03 Jul 2020 22:47:46 -0000 Hi Jim, thank you for this flash override review :-) > On 2020-07-03, at 20:39, Jim Schaad wrote: >=20 > * Section 1 - There has been a recent argument on one of the mailing = lists > about the question between the value of an encoding and the contents = of the > value of the encoding. I think that it needs to be highlighted that = this is > referring to the V portion of TLV for BER. "The contents of these > encodings..." is mostly likely going to cause somebody to have the = same > problem. I added =C2=BB(the "value" part of BER's type-length-value structure)=C2=AB. > * Section 1 - last sentence - What it is being referred to here? Last sentence: It is intended as the reference document for the IANA registration of the tags so defined. It =3D this document? Or did you mean the penultimate sentence? That needed to be fixed; = done. > * Section 2 - What is a "primary integer"? Is this one that has not = yet > gone to high school? I have no idea. ASN.1 term? Ah right, X.660. Since arcs can be = identified both by its actual integer value and (not necessarily = unambiguous) secondary identifiers, the integer value is called = =E2=80=9Cprimary=E2=80=9D integer value. Fixed this by adding = explanation and getting rid of the =E2=80=9Cprimary=E2=80=9D elsewhere.=20= > * Section 2.1 - I don't think it is the tag that is invalid, but = rather the > value in the tag that is invalid. =20 Well, the value (tag content) is a byte string, and there are no = validity requirements on byte strings. It is that tag formed out of tag = number and tag content that is invalid. > The "tagged value"? =20 We now call that =E2=80=9Ctag content=E2=80=9D in 7049bis. > (Is this a > well-formed error?) No, a validity error. > * You need to update references and text to the CBOR bis document. Eventually=E2=80=A6 But yes, using the terms from 7049bis helps. Fixed. > * Section 5 - Does it make any sense to allow the tags to be specified = in a > nested manner? TBD110(X) [TBD111(Y)] ? Not sure how that would work. Can you give an example? I was thinking about stacking tags to deepen their effect into arrays = and maps, but haven=E2=80=99t quite figured that out either. > * Section 5 - One way to handle the problem would be to define a new = tag > which cancels any tag inheritance as a general purpose thing. This = might > also be useful for other tags which might be defined in this way in = the > future. Yes, but if you generate an example, that becomes unwieldy as well (the = neutralizer needs to be inserted in awkward places; the CDDL will be = horrendous). So instead of starting out with an infinitely deep effect that then = needs to be stopped, I was thinking about one-deep plus a way to extend = that. But first we need a few good examples. > * Section 7 - I would agree that having an operator that parses string > dotted format does not make any sense. It might be useful to include = the > .oid operator however which has the property of doing the magic. Done. > * Section 7 - I need an example of .sdnv because I am having a problem > figuring out how it would be used. If there is a .fooseq, there should be a .foo for exactly one foo. RFC5050blockflags-encoded =3D bytes .sdnv block-flags block-flags =3D uint .bits &( Block-must-be-replicated-in-every-fragment: 0 Transmit-status-report-if-block-cant-be-processed: 1 Delete-bundle-if-block-cant-be-processed: 2 Last-block: 3 Discard-block-if-it-cant-be-processed: 4 Block-was-forwarded-without-being-processed: 5 Block-contains-an-EID-reference-field: 6 ) Well, yeah, any reasonable spec would just carry the uint. > * Section 7 - If we do nesting behavior on these tags, then a control > operator to make A relative to B would be useful as well. Again, if you have an example for that, I=E2=80=99m all ears. I pushed an update to https://github.com/cabo/cbor-oid/tree/cleanup; = view formatted at = https://raw.githack.com/cabo/cbor-oid/cleanup/draft-bormann-cbor-tags-oid.= html =E2=80=94 plaintext diff at = https://tools.ietf.org/rfcdiff?url1=3Ddraft-bormann-cbor-tags-oid-07.txt&u= rl2=3Dhttps://raw.githubusercontent.com/cabo/cbor-oid/cleanup/draft-borman= n-cbor-tags-oid.txt Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 3 18:53: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 D39183A09C5; Fri, 3 Jul 2020 18:53:45 -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 Xb_wQlmZTDuN; Fri, 3 Jul 2020 18:53:44 -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 981E33A09C4; Fri, 3 Jul 2020 18:53:43 -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; Fri, 3 Jul 2020 18:53:37 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: , References: <000801d65169$5915dfb0$0b419f10$@augustcellars.com> <5E9374BB-8893-4CB5-9548-672BC9556E55@tzi.org> In-Reply-To: <5E9374BB-8893-4CB5-9548-672BC9556E55@tzi.org> Date: Fri, 3 Jul 2020 18:53:34 -0700 Message-ID: <001701d651a5$ef08e6c0$cd1ab440$@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: AQJCS8mg84/kdNNiFdYaRblosMwr0AHMNoBHqBBOhVA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Review draft-bormann-cbor-tags-oid-07 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, 04 Jul 2020 01:53:46 -0000 > -----Original Message----- > From: Carsten Bormann > Sent: Friday, July 3, 2020 3:48 PM > To: Jim Schaad > Cc: draft-bormann-cbor-tags-oid@ietf.org; cbor@ietf.org > Subject: Re: Review draft-bormann-cbor-tags-oid-07 >=20 > Hi Jim, >=20 > thank you for this flash override review :-) >=20 > > On 2020-07-03, at 20:39, Jim Schaad wrote: > > > > * Section 1 - There has been a recent argument on one of the mailing > > lists about the question between the value of an encoding and the > > contents of the value of the encoding. I think that it needs to be > > highlighted that this is referring to the V portion of TLV for BER. > > "The contents of these encodings..." is mostly likely going to cause > > somebody to have the same problem. >=20 > I added =C2=BB(the "value" part of BER's > type-length-value structure)=C2=AB. >=20 > > * Section 1 - last sentence - What it is being referred to here? >=20 > Last sentence: >=20 > It is intended as the reference document for the IANA registration of = the tags so > defined. >=20 > It =3D this document? >=20 > Or did you mean the penultimate sentence? That needed to be fixed; = done. I thought that this was true, but given the distance between "This = document" and "It" it was not a sure thing. >=20 > > * Section 2 - What is a "primary integer"? Is this one that has not > > yet gone to high school? >=20 > I have no idea. ASN.1 term? Ah right, X.660. Since arcs can be = identified both > by its actual integer value and (not necessarily unambiguous) = secondary > identifiers, the integer value is called =E2=80=9Cprimary=E2=80=9D = integer value. Fixed this by > adding explanation and getting rid of the =E2=80=9Cprimary=E2=80=9D = elsewhere. Ah yes - this would have been from=20 { joint-iso-itu-t country us organization gov csor nistalgorithm = hashalgs sha256(1) } Which is legal as long as the strings have been defined elsewhere. >=20 > > * Section 2.1 - I don't think it is the tag that is invalid, but > > rather the value in the tag that is invalid. >=20 > Well, the value (tag content) is a byte string, and there are no = validity > requirements on byte strings. It is that tag formed out of tag number = and tag > content that is invalid. >=20 > > The "tagged value"? >=20 > We now call that =E2=80=9Ctag content=E2=80=9D in 7049bis. I really need to try and memorize the new terminology. >=20 > > (Is this a > > well-formed error?) >=20 > No, a validity error. >=20 > > * You need to update references and text to the CBOR bis document. >=20 > Eventually=E2=80=A6 But yes, using the terms from 7049bis helps. = Fixed. >=20 > > * Section 5 - Does it make any sense to allow the tags to be = specified > > in a nested manner? TBD110(X) [TBD111(Y)] ? >=20 > Not sure how that would work. > Can you give an example? >=20 > I was thinking about stacking tags to deepen their effect into arrays = and maps, > but haven=E2=80=99t quite figured that out either. I managed to get my numbers backwards above - so that would probably = make it harder to understand. For short things it probably does not = matter, but for longer things it might be useful. tag(111) h'608680165030402' [ / 2.16.840.1.101.3.4.2 tag(110) h'01', / .1 sha256 tag(110) h'02' / .2 sha??? I would have to look it up, but = it is one of the sha-2 hash functions. ] An array of two hash functions which could be parsed into the two rooted = OID values >=20 > > * Section 5 - One way to handle the problem would be to define a new > > tag which cancels any tag inheritance as a general purpose thing. > > This might also be useful for other tags which might be defined in > > this way in the future. >=20 > Yes, but if you generate an example, that becomes unwieldy as well = (the > neutralizer needs to be inserted in awkward places; the CDDL will be > horrendous). > So instead of starting out with an infinitely deep effect that then = needs to be > stopped, I was thinking about one-deep plus a way to extend that. > But first we need a few good examples. Yeah, the CDDL would be just terrible to write. >=20 > > * Section 7 - I would agree that having an operator that parses = string > > dotted format does not make any sense. It might be useful to = include > > the .oid operator however which has the property of doing the magic. >=20 > Done. >=20 > > * Section 7 - I need an example of .sdnv because I am having a = problem > > figuring out how it would be used. >=20 > If there is a .fooseq, there should be a .foo for exactly one foo. >=20 > RFC5050blockflags-encoded =3D bytes .sdnv block-flags block-flags =3D = uint .bits &( > Block-must-be-replicated-in-every-fragment: 0 > Transmit-status-report-if-block-cant-be-processed: 1 > Delete-bundle-if-block-cant-be-processed: 2 > Last-block: 3 > Discard-block-if-it-cant-be-processed: 4 > Block-was-forwarded-without-being-processed: 5 > Block-contains-an-EID-reference-field: 6 > ) >=20 > Well, yeah, any reasonable spec would just carry the uint. Ok - I thought that I what you meant. I just could not believe that was = true. >=20 > > * Section 7 - If we do nesting behavior on these tags, then a = control > > operator to make A relative to B would be useful as well. >=20 > Again, if you have an example for that, I=E2=80=99m all ears. root-sha2 =3D bytes .sdnvseq [ 60 840 1 101 3 4 2 ] root-sha256 =3D byte .sdnvseq [ 60 840 1 101 3 4 2 1 ] rel-sha25 =3D root-sha256 .oidrel root-sha2 >=20 > I pushed an update to https://github.com/cabo/cbor-oid/tree/cleanup; = view > formatted at = https://raw.githack.com/cabo/cbor-oid/cleanup/draft-bormann- > cbor-tags-oid.html =E2=80=94 plaintext diff at >=20 > https://tools.ietf.org/rfcdiff?url1=3Ddraft-bormann-cbor-tags-oid- > = 07.txt&url2=3Dhttps://raw.githubusercontent.com/cabo/cbor-oid/cleanup/dra= ft- > bormann-cbor-tags-oid.txt >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Jul 4 04:49:04 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 70E163A0A87; Sat, 4 Jul 2020 04:49:02 -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, RCVD_IN_MSPIKE_H4=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 USngr81vtI5O; Sat, 4 Jul 2020 04:48:59 -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 83F453A0A80; Sat, 4 Jul 2020 04:48:58 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49zVV058VPzyVV; Sat, 4 Jul 2020 13:48:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <001701d651a5$ef08e6c0$cd1ab440$@augustcellars.com> Date: Sat, 4 Jul 2020 13:48:56 +0200 Cc: draft-bormann-cbor-tags-oid@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 615556136.197926-9254fe05c883cc76315b744606c11acc Content-Transfer-Encoding: quoted-printable Message-Id: References: <000801d65169$5915dfb0$0b419f10$@augustcellars.com> <5E9374BB-8893-4CB5-9548-672BC9556E55@tzi.org> <001701d651a5$ef08e6c0$cd1ab440$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Cbor] Prefix compression (Re: Review draft-bormann-cbor-tags-oid-07) 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, 04 Jul 2020 11:49:03 -0000 Hi Jim, On 2020-07-04, at 03:53, Jim Schaad wrote: >=20 > An array of two hash functions which could be parsed into the two = rooted OID values Prefix compression is applicable to other data than OIDs (most = prominently URIs). I think we should handle that in a more generic way than specifically = for OIDs. (I had a short presentation at an IETF a couple of years ago about what = I called =E2=80=9CTag 6 compression=E2=80=9D because it had been around = since about 2013 =E2=80=94 I finally need to write this up. It really = works, and it is really low cost for a decoder...) Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Jul 4 16:43:53 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4873A11F0; Sat, 4 Jul 2020 16:43:52 -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, RCVD_IN_MSPIKE_H4=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 HtwPPUcJTk2R; Sat, 4 Jul 2020 16:43: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 697D83A11EF; Sat, 4 Jul 2020 16:43:48 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49zpLm5tVRzyXN; Sun, 5 Jul 2020 01:43:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <20200704225242.3264EF406D5@rfc-editor.org> Date: Sun, 5 Jul 2020 01:43:44 +0200 Cc: Paul Hoffman , iesg@ietf.org, cheshire@apple.com, cbor@ietf.org X-Mao-Original-Outgoing-Id: 615599024.2888139-e1a630fa2b1cc6c2a245453065fde3a8 Content-Transfer-Encoding: quoted-printable Message-Id: <25ADFCDD-1B4D-4A9C-87DE-780F89DC0F87@tzi.org> References: <20200704225242.3264EF406D5@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] [Technical Errata Reported] RFC7049 (6221) 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, 04 Jul 2020 23:43:52 -0000 Hi Stuart, thank you for this errata report. Are you aware of the 7049bis effort? That document was submitted to the IESG a couple of weeks ago. We had exactly that same discussion in = https://github.com/cbor-wg/CBORbis/issues/96, and added = https://github.com/cbor-wg/CBORbis/pull/101/files as a fix. > Alternatively, the =E2=80=9Cwell_formed=E2=80=9D function could return = an > indication of whether the item it determined to be well-formed > was in fact a definite-length item or an indefinite-length item, > and that would then be checked on the =E2=80=9Cif (it !=3D mt)=E2=80=9D = line. Which is exactly what is there, and what is explained better now with = the above fix. So I believe there is no problem in the pseudocode (which only has a = comment changed in the above fix). A couple of questions come up here: * Is the pseudocode possibly too clever? Maybe. We even had one other misread of the pseudocode in = https://github.com/cbor-wg/CBORbis/issues/148. After seven years, I=E2=80=99m not sure that replacing the time-tested = code from RFC 7049 by new code doesn=E2=80=99t incur too much risk. =20 (In those seven years, we found we had to add one line, which checks = against excluded two-byte forms of simple values.) * Shouldn=E2=80=99t we allow indefinite strings as chunks in indefinite = strings? No. An implementation that wants to put together indefinite strings = from strings that are (possibly) indefinite can simply take out the = brackets off the inner ones. The actual use case for indefinite strings = is =E2=80=9Cstreaming=E2=80=9D, where you just don=E2=80=99t know how = long your string will be before you have to start sending it, called = =E2=80=9Cchunking=E2=80=9D in other contexts. When you do that and have = an indefinite string to send, it is very easy to take off the brackets = (0x5f/0x7f and 0xff). Having multiple ways to say the same thing can always lead to = interoperability issues (and increases the cost of interoperability = tests). Worse, some applications or implementations will start to ascribe = semantics to the presence or absence of redundant pairs of brackets. Indefinite-length strings already add considerable complexity to some = CBOR-consuming code; removing the ability to rely on only definit-length = chunks being in there would add further complexity. * Why doesn=E2=80=99t your own code check for this? Touch=C3=A9. In my backlog... Gr=C3=BC=C3=9Fe, Carsten > On 2020-07-05, at 00:52, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7049, > "Concise Binary Object Representation (CBOR)". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6221 >=20 > -------------------------------------- > Type: Technical > Reported by: Stuart Cheshire >=20 > Section: Appendix C >=20 > Original Text > ------------- > well_formed_indefinite(mt, breakable) { > switch (mt) { > case 2: case 3: > while ((it =3D well_formed(true)) !=3D -1) > if (it !=3D mt) // need finite embedded > fail(); // of same type > break; >=20 > Corrected Text > -------------- > Various possible fixes exist; however, none can be > expressed briefly in just a few lines of replacement text. >=20 > Possibly the =E2=80=9Cwell_formed=E2=80=9D function could be changed > to take an additional parameter indicating whether > indefinite length items are allowed. >=20 > Alternatively, the =E2=80=9Cwell_formed=E2=80=9D function could return = an > indication of whether the item it determined to be well-formed > was in fact a definite-length item or an indefinite-length item, > and that would then be checked on the =E2=80=9Cif (it !=3D mt)=E2=80=9D = line. >=20 > Notes > ----- > Appendix C gives pseudocode for verifying whether a CBOR item is = well-formed. However, it does not match the rules specified elsewhere in = the RFC. >=20 > The normative text in the body of the RFC states: >=20 >> Indefinite-length byte strings and text strings are actually a >> concatenation of zero or more definite-length byte or text strings >> ("chunks") that are together treated as one contiguous string. >=20 > The restrictive term =E2=80=9Cdefinite-length=E2=80=9D is crucial = there, and the pseudocode in Appendix C disregards this. >=20 > The pseudocode deems an indefinite-length byte/text string to be valid = if it consists of a sequence of constituent items of the same type that = are definite-length *or* indefinite-length. >=20 > It could be argued that the pseudocode is actually more sensible. = Since an indefinite-length string item is the concatenation of zero or = more well-formed string items, why shouldn=E2=80=99t it allow some of = those well-formed string items to themselves be indefinite-length = strings? There is no clear argument why not. If indefinite-length = strings within other items are a useful concept in the first place, why = wouldn=E2=80=99t they also be a useful concept within indefinite-length = string items? Perhaps there is a library that outputs indefinite-length = strings, and you want to use that library to output a string that is = itself part of a larger indefinite-length string? >=20 > Indeed, a decoder applying Postel=E2=80=99s Robustness Principle (be = liberal with what you accept) may choose to allow indefinite-length = strings containing indefinite-length strings, nested arbitrarily deeply, = since the intent, meaning, encoding and decoding of such items is clear = and unambiguous. >=20 > However, such an implementation, applying the Robustness Principle, = would accept input deemed illegal by the specification. Different = implementations, some more liberal and some less, would decode the same = input differently. >=20 > In the case where security policy is decided using one decoder = implementation, and acting on the message is handled by another decoder = implementation, this could result in security failures. >=20 > Possibly the normative text of the format specification could be = changed to match the pseudocode, allowing any well-formed string of the = right type (definite-length or indefinite-length) to be a constituent = within an indefinite-length string. >=20 > Alternatively, if this is not desirable, it would be helpful for the = specification text to explain, in unambiguous terms, why the designers = chose to disallow indefinite-length strings to be used as constituents = within an indefinite-length string. This would discourage creative = implementers from feeling that it would be beneficial to be liberal and = accept this input anyway, and would reduce the risk of inconsistent = parsing by different implementations. In this case, the pseudocode = should be corrected, to avoid implementers basing their code on that and = getting incorrect implementations as a result. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7049 (draft-bormann-cbor-09) > -------------------------------------- > Title : Concise Binary Object Representation (CBOR) > Publication Date : October 2013 > Author(s) : C. Bormann, P. Hoffman > Category : PROPOSED STANDARD > Source : IETF - NON WORKING GROUP > Area : N/A > Stream : IETF > Verifying Party : IESG From nobody Sat Jul 4 19:41: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 0D4A63A0809; Sat, 4 Jul 2020 19:41:05 -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 4lIhlob2vOR1; Sat, 4 Jul 2020 19:41:02 -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 1D24D3A0808; Sat, 4 Jul 2020 19:41:01 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 4 Jul 2020 19:40:36 -0700 From: Jim Schaad To: 'Carsten Bormann' , 'RFC Errata System' CC: , , 'Paul Hoffman' , References: <20200704225242.3264EF406D5@rfc-editor.org> <25ADFCDD-1B4D-4A9C-87DE-780F89DC0F87@tzi.org> In-Reply-To: <25ADFCDD-1B4D-4A9C-87DE-780F89DC0F87@tzi.org> Date: Sat, 4 Jul 2020 19:40:33 -0700 Message-ID: <003901d65275$aa6e87b0$ff4b9710$@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: AQKqUehVnd6CTzXa4cuEuM5FqHfZ5AClSWwGp0scylA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] [Technical Errata Reported] RFC7049 (6221) 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, 05 Jul 2020 02:41:05 -0000 > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Saturday, July 4, 2020 4:44 PM > To: RFC Errata System > Cc: cheshire@apple.com; cbor@ietf.org; Paul Hoffman > ; iesg@ietf.org > Subject: Re: [Cbor] [Technical Errata Reported] RFC7049 (6221) >=20 > Hi Stuart, >=20 > thank you for this errata report. >=20 > Are you aware of the 7049bis effort? > That document was submitted to the IESG a couple of weeks ago. >=20 > We had exactly that same discussion in https://github.com/cbor- > wg/CBORbis/issues/96, and added https://github.com/cbor- > wg/CBORbis/pull/101/files as a fix. >=20 > > Alternatively, the =E2=80=9Cwell_formed=E2=80=9D function could = return an indication > > of whether the item it determined to be well-formed was in fact a > > definite-length item or an indefinite-length item, and that would = then > > be checked on the =E2=80=9Cif (it !=3D mt)=E2=80=9D line. >=20 > Which is exactly what is there, and what is explained better now with = the above > fix. >=20 > So I believe there is no problem in the pseudocode (which only has a = comment > changed in the above fix). >=20 > A couple of questions come up here: >=20 > * Is the pseudocode possibly too clever? >=20 > Maybe. We even had one other misread of the pseudocode in > https://github.com/cbor-wg/CBORbis/issues/148. >=20 > After seven years, I=E2=80=99m not sure that replacing the time-tested = code from RFC > 7049 by new code doesn=E2=80=99t incur too much risk. > (In those seven years, we found we had to add one line, which checks = against > excluded two-byte forms of simple values.) >=20 > * Shouldn=E2=80=99t we allow indefinite strings as chunks in = indefinite strings? >=20 > No. An implementation that wants to put together indefinite strings = from > strings that are (possibly) indefinite can simply take out the = brackets off the > inner ones. The actual use case for indefinite strings is = =E2=80=9Cstreaming=E2=80=9D, where you > just don=E2=80=99t know how long your string will be before you have = to start sending it, > called =E2=80=9Cchunking=E2=80=9D in other contexts. When you do that = and have an indefinite > string to send, it is very easy to take off the brackets (0x5f/0x7f = and 0xff). >=20 > Having multiple ways to say the same thing can always lead to = interoperability > issues (and increases the cost of interoperability tests). >=20 > Worse, some applications or implementations will start to ascribe = semantics to > the presence or absence of redundant pairs of brackets. >=20 > Indefinite-length strings already add considerable complexity to some = CBOR- > consuming code; removing the ability to rely on only definit-length = chunks > being in there would add further complexity. Even worse, the ability to have nested indefinite-length objects leads = to stack overflow problems as it can just go on indefinitely. Many = implementations of ASN.1 which support this feature have had bugs = reported against them. Jim >=20 > * Why doesn=E2=80=99t your own code check for this? >=20 > Touch=C3=A9. In my backlog... >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > On 2020-07-05, at 00:52, RFC Errata System = > wrote: > > > > The following errata report has been submitted for RFC7049, "Concise > > Binary Object Representation (CBOR)". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6221 > > > > -------------------------------------- > > Type: Technical > > Reported by: Stuart Cheshire > > > > Section: Appendix C > > > > Original Text > > ------------- > > well_formed_indefinite(mt, breakable) { > > switch (mt) { > > case 2: case 3: > > while ((it =3D well_formed(true)) !=3D -1) > > if (it !=3D mt) // need finite embedded > > fail(); // of same type > > break; > > > > Corrected Text > > -------------- > > Various possible fixes exist; however, none can be expressed briefly > > in just a few lines of replacement text. > > > > Possibly the =E2=80=9Cwell_formed=E2=80=9D function could be changed = to take an > > additional parameter indicating whether indefinite length items are > > allowed. > > > > Alternatively, the =E2=80=9Cwell_formed=E2=80=9D function could = return an indication > > of whether the item it determined to be well-formed was in fact a > > definite-length item or an indefinite-length item, and that would = then > > be checked on the =E2=80=9Cif (it !=3D mt)=E2=80=9D line. > > > > Notes > > ----- > > Appendix C gives pseudocode for verifying whether a CBOR item is = well- > formed. However, it does not match the rules specified elsewhere in = the RFC. > > > > The normative text in the body of the RFC states: > > > >> Indefinite-length byte strings and text strings are actually a > >> concatenation of zero or more definite-length byte or text = strings > >> ("chunks") that are together treated as one contiguous string. > > > > The restrictive term =E2=80=9Cdefinite-length=E2=80=9D is crucial = there, and the pseudocode in > Appendix C disregards this. > > > > The pseudocode deems an indefinite-length byte/text string to be = valid if it > consists of a sequence of constituent items of the same type that are = definite- > length *or* indefinite-length. > > > > It could be argued that the pseudocode is actually more sensible. = Since an > indefinite-length string item is the concatenation of zero or more = well-formed > string items, why shouldn=E2=80=99t it allow some of those well-formed = string items to > themselves be indefinite-length strings? There is no clear argument = why not. If > indefinite-length strings within other items are a useful concept in = the first > place, why wouldn=E2=80=99t they also be a useful concept within = indefinite-length string > items? Perhaps there is a library that outputs indefinite-length = strings, and you > want to use that library to output a string that is itself part of a = larger > indefinite-length string? > > > > Indeed, a decoder applying Postel=E2=80=99s Robustness Principle (be = liberal with what > you accept) may choose to allow indefinite-length strings containing = indefinite- > length strings, nested arbitrarily deeply, since the intent, meaning, = encoding > and decoding of such items is clear and unambiguous. > > > > However, such an implementation, applying the Robustness Principle, = would > accept input deemed illegal by the specification. Different = implementations, > some more liberal and some less, would decode the same input = differently. > > > > In the case where security policy is decided using one decoder > implementation, and acting on the message is handled by another = decoder > implementation, this could result in security failures. > > > > Possibly the normative text of the format specification could be = changed to > match the pseudocode, allowing any well-formed string of the right = type > (definite-length or indefinite-length) to be a constituent within an = indefinite- > length string. > > > > Alternatively, if this is not desirable, it would be helpful for the = specification > text to explain, in unambiguous terms, why the designers chose to = disallow > indefinite-length strings to be used as constituents within an = indefinite-length > string. This would discourage creative implementers from feeling that = it would > be beneficial to be liberal and accept this input anyway, and would = reduce the > risk of inconsistent parsing by different implementations. In this = case, the > pseudocode should be corrected, to avoid implementers basing their = code on > that and getting incorrect implementations as a result. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or = rejected. > > When a decision is reached, the verifying party can log in to change > > the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC7049 (draft-bormann-cbor-09) > > -------------------------------------- > > Title : Concise Binary Object Representation (CBOR) > > Publication Date : October 2013 > > Author(s) : C. Bormann, P. Hoffman > > Category : PROPOSED STANDARD > > Source : IETF - NON WORKING GROUP > > Area : N/A > > Stream : IETF > > Verifying Party : IESG >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Sun Jul 5 14:52: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 F1B803A0B5F; Sun, 5 Jul 2020 14:52:09 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 mB4_Ax_bmwWj; Sun, 5 Jul 2020 14:52:03 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 F06DB3A0B4E; Sun, 5 Jul 2020 14:52:02 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 065LptcV041372; Sun, 5 Jul 2020 14:51:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=QHt9zMB2itbL3iuW/QevS/N+jr2bJ3ELN3NcN0Uwqwg=; b=FFIfxK5WG7qaOORZbme52eUh4QiX1USgWpZE6AinDK/oTX3C//lyRK5Q8nNTvQT/pctJ lziGJc4ex6sUTa1ZDU7a8I0u8e9kEhIrD6KEILrIjhHpyn0TLtNI7jnKOUJxNYx7D7v8 F/RNyuIEftTatIvleWj1il9vy4agO4d64eSTZ6QlNtKePrwr/4W8oC77tl5qgEJWdSWm sn/6/3fuMKxgtDD+VxBHqwV9hcXoAxBylH39XX8aTa6KPsQxR3F5xj/CU+a0ta3mRsda 0R9ePJwpc2ljHR7v8uX9yLMFPnsFiBB3Yj/LdqY/vTdUD7+x99LcTWKaKpddolD5ITIS xg== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by nwk-aaemail-lapp02.apple.com with ESMTP id 322pbfk512-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 05 Jul 2020 14:51:55 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QD0007RTNEJSO30@rn-mailsvcp-mta-lapp02.rno.apple.com>; Sun, 05 Jul 2020 14:51:55 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QD000G00M5QQR00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Sun, 05 Jul 2020 14:51:55 -0700 (PDT) X-Va-A: X-Va-T-CD: 053c1d1aa99167e76124f1672650fcc5 X-Va-E-CD: 71f448cfc1aee7d7b825b3007edd9c87 X-Va-R-CD: 667ecdd0b818eeb45b824e0dd7199898 X-Va-CD: 0 X-Va-ID: c7ad4579-6f9c-4576-9064-a54d73753905 X-V-A: X-V-T-CD: 053c1d1aa99167e76124f1672650fcc5 X-V-E-CD: 71f448cfc1aee7d7b825b3007edd9c87 X-V-R-CD: 667ecdd0b818eeb45b824e0dd7199898 X-V-CD: 0 X-V-ID: 4af5f7a9-e070-4829-9097-cc2a6108d34c X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-05_15:2020-07-02, 2020-07-05 signatures=0 Received: from [17.232.202.219] (unknown [17.232.202.219]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QD000U03NEFAP00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Sun, 05 Jul 2020 14:51:54 -0700 (PDT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Stuart Cheshire In-reply-to: <25ADFCDD-1B4D-4A9C-87DE-780F89DC0F87@tzi.org> Date: Sun, 05 Jul 2020 14:51:51 -0700 Cc: RFC Errata System , Paul Hoffman , The IESG , cbor@ietf.org Content-transfer-encoding: quoted-printable Message-id: <07D4D5BC-C6F2-438A-B707-87B2928211F3@apple.com> References: <20200704225242.3264EF406D5@rfc-editor.org> <25ADFCDD-1B4D-4A9C-87DE-780F89DC0F87@tzi.org> To: Carsten Bormann , Jim Schaad X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-05_15:2020-07-02, 2020-07-05 signatures=0 Archived-At: Subject: Re: [Cbor] [Technical Errata Reported] RFC7049 (6221) 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, 05 Jul 2020 21:52:10 -0000 On 4 Jul 2020, at 16:43, Carsten Bormann wrote: > Hi Stuart, >=20 > thank you for this errata report. Thanks Carsten and Jim for your quick replies. And I apologize for filing a mistaken erratum report. RFC Editor, if it = is possible to simply delete this erratum report, please do so. Stuart Cheshire From nobody Sun Jul 5 15:52:14 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 E1E863A0BAC; Sun, 5 Jul 2020 15:52:08 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 d0WtONXud0UZ; Sun, 5 Jul 2020 15:52:07 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 46AB33A0BAA; Sun, 5 Jul 2020 15:52:07 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 065Mq0Tg028686; Sun, 5 Jul 2020 15:52:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=sZXlNU9VERvIkDxc9cb538Awv/aT/RR4STf6lK/fi9A=; b=PnedX/rLr9yeBSVMTRHqZY+Nts41nNfJxj/LdHA1/PzoKWSOXV9CGKpZfrDMkVvwf5bB omeyN2dR+FMj+0hLKxzF1QPQET+M2cL40zKsTPcetTLVoRY/cyoMIVFMvBHlsPsr4oDx NGlIDDWNxyqwvEPymEkHL/SwrSGJKedUyOFqYvfdeq6WRy8p4a/IeguGENQnmUG0zPIB wJSBVQbEBesU1LDr1YF6NOvuvHY76UX1oRjC3G+lcj/T2pDYKnjh0fTre1VChYuHJk7X 5ZziUt8+FjjLpXizkRXID42CbCEn1EOMV2qQMt90+KKSXVzFyryNGxWoQsa+NdZRbPer Hg== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 322rrv2gg5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 05 Jul 2020 15:51:59 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QD00050JQ6GH040@rn-mailsvcp-mta-lapp02.rno.apple.com>; Sun, 05 Jul 2020 15:51:52 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QD000J00OXLKI00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Sun, 05 Jul 2020 15:51:52 -0700 (PDT) X-Va-A: X-Va-T-CD: 053c1d1aa99167e76124f1672650fcc5 X-Va-E-CD: 71f448cfc1aee7d7b825b3007edd9c87 X-Va-R-CD: 667ecdd0b818eeb45b824e0dd7199898 X-Va-CD: 0 X-Va-ID: 9132a234-6a77-4e65-8705-9c0ec814ca8d X-V-A: X-V-T-CD: 053c1d1aa99167e76124f1672650fcc5 X-V-E-CD: 71f448cfc1aee7d7b825b3007edd9c87 X-V-R-CD: 667ecdd0b818eeb45b824e0dd7199898 X-V-CD: 0 X-V-ID: 612478d5-fab4-49e3-93cb-2aa6b0c1a0bb X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-05_15:2020-07-02, 2020-07-05 signatures=0 Received: from [17.232.202.219] (unknown [17.232.202.219]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QD000Y02Q6DH400@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Sun, 05 Jul 2020 15:51:52 -0700 (PDT) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Stuart Cheshire In-reply-to: <25ADFCDD-1B4D-4A9C-87DE-780F89DC0F87@tzi.org> Date: Sun, 05 Jul 2020 15:51:49 -0700 Cc: Paul Hoffman , The IESG , cbor@ietf.org Content-transfer-encoding: quoted-printable Message-id: References: <20200704225242.3264EF406D5@rfc-editor.org> <25ADFCDD-1B4D-4A9C-87DE-780F89DC0F87@tzi.org> To: Carsten Bormann , Jim Schaad X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-05_15:2020-07-02, 2020-07-05 signatures=0 Archived-At: Subject: Re: [Cbor] [Technical Errata Reported] RFC7049 (6221) 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, 05 Jul 2020 22:52:09 -0000 On 4 Jul 2020, at 16:43, Carsten Bormann wrote: > Are you aware of the 7049bis effort? I am now. If you would like my feedback I can review it and send you = comments. I realize it would not be appropriate to make any technical = changes at this stage, but I may think of suggestions about minor = wording changes to improve clarity. Is draft-ietf-cbor-7049bis-14 the = latest version? > So I believe there is no problem in the pseudocode (which only has a = comment changed in the above fix). >=20 > A couple of questions come up here: >=20 > * Is the pseudocode possibly too clever? >=20 > Maybe. We even had one other misread of the pseudocode in = https://github.com/cbor-wg/CBORbis/issues/148. >=20 > After seven years, I=E2=80=99m not sure that replacing the time-tested = code from RFC 7049 by new code doesn=E2=80=99t incur too much risk. =20 > (In those seven years, we found we had to add one line, which checks = against excluded two-byte forms of simple values.) Now that I understand it properly, I see how the pseudocode works, and I = see why I was confused. Without comments or a definition in RFC7049 of the well_formed function, = I was left guessing. I guessed (wrongly) that it is defined to return = the major type of the item consumed. The new explanatory text in = draft-ietf-cbor-7049bis-14 makes it clear that it is not this simple. Yes, the pseudocode is clever. Not too clever -- there is considerable = merit in being able to make pseudocode that fits on one page of an RFC. = I think a few minor tweaks can reduce misunderstandings, and still keep = it fitting on a single page. A minor textual suggestion. One of the function definitions below has a = space before the opening parenthesis and one does not. I would suggest = making them consistent. well_formed (breakable =3D false) well_formed_indefinite(mt, breakable) The comments in the pseudocode use the terms =E2=80=9Cfinite data = item=E2=80=9D and =E2=80=9Cfinite-length chunk=E2=80=9D, which are not = used elsewhere in the RFC. Perhaps, to be consistent with the rest of = the document, I suggest =E2=80=9Cdefinite-length item=E2=80=9D and = =E2=80=9Cdefinite-length chunk=E2=80=9D. One thing I would suggest to improve the clarity of the code would be = not to overload the value zero to mean *both* that an item with major = type zero was consumed (positive integer) *and* that an = indefinite-length item was consumed (of any major type). Perhaps well_formed_indefinite could return -1 when a "break" stop code = is consumed, and -2 when an entire indefinite-length item is consumed. Or maybe make well_formed_indefinite end with =E2=80=9Creturn mt | = 0x80=E2=80=9D so that it *does* return the correct major type, but with = the top bit set to show that it was an indefinite-length variant of that = major type. Also, the final comment =E2=80=9Cno break out=E2=80=9D is a little = confusing. What it really means is that this *is* the end of an = indefinite-length item, so it really *does* break out of processing a = complete indefinite-length item. Maybe the comments at the end of well_formed and well_formed_indefinite = (respectively) could be: well_formed: return mt; // definite-length data item well_formed_indefinite: return mt | 0x80; // indefinite-length data item or return -2; // indefinite-length data item > * Shouldn=E2=80=99t we allow indefinite strings as chunks in = indefinite strings? >=20 > No. An implementation that wants to put together indefinite strings = from strings that are (possibly) indefinite can simply take out the = brackets off the inner ones. The actual use case for indefinite strings = is =E2=80=9Cstreaming=E2=80=9D, where you just don=E2=80=99t know how = long your string will be before you have to start sending it, called = =E2=80=9Cchunking=E2=80=9D in other contexts. When you do that and have = an indefinite string to send, it is very easy to take off the brackets = (0x5f/0x7f and 0xff). >=20 > Having multiple ways to say the same thing can always lead to = interoperability issues (and increases the cost of interoperability = tests). >=20 > Worse, some applications or implementations will start to ascribe = semantics to the presence or absence of redundant pairs of brackets. >=20 > Indefinite-length strings already add considerable complexity to some = CBOR-consuming code; removing the ability to rely on only definit-length = chunks being in there would add further complexity. I agree with you 100% on this. The arguments you make, plus the stack = usage point that Jim Schaad made, are all good. However I didn=E2=80=99t find any explanation like this in = draft-ietf-cbor-7049bis-14. Given that the CBOR format could trivially support nested = indefinite-length strings, there may be temptation for creative = implementers to =E2=80=9Cimprove=E2=80=9D CBOR by allowing this. I can = imagine a discussion between engineers debating whether to do this. = Having clear text in the RFC stating that this was considered and = rejected, and is considered unnecessary and a bad idea, and why, would = help avoid those engineering debates ending with the wrong conclusion. Stuart Cheshire From nobody Sun Jul 5 17:19:15 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 AB7F53A0C4F; Sun, 5 Jul 2020 17:19:07 -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 UZWZHN011MNj; Sun, 5 Jul 2020 17:19:05 -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 47BC13A0C4E; Sun, 5 Jul 2020 17:19:05 -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, 5 Jul 2020 17:18:39 -0700 From: Jim Schaad To: 'Stuart Cheshire' , 'Carsten Bormann' CC: 'Paul Hoffman' , 'The IESG' , References: <20200704225242.3264EF406D5@rfc-editor.org> <25ADFCDD-1B4D-4A9C-87DE-780F89DC0F87@tzi.org> In-Reply-To: Date: Sun, 5 Jul 2020 17:18:37 -0700 Message-ID: <005101d6532b$00919b90$01b4d2b0$@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: AQKqUehVnd6CTzXa4cuEuM5FqHfZ5AClSWwGAcwbHuKnPibswA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] [Technical Errata Reported] RFC7049 (6221) 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, 06 Jul 2020 00:19:08 -0000 We have not gone through the IETF wide Last Call - so any comments are = welcome. Jim > -----Original Message----- > From: Stuart Cheshire > Sent: Sunday, July 5, 2020 3:52 PM > To: Carsten Bormann ; Jim Schaad = > Cc: Paul Hoffman ; The IESG ; > cbor@ietf.org > Subject: Re: [Technical Errata Reported] RFC7049 (6221) >=20 > On 4 Jul 2020, at 16:43, Carsten Bormann wrote: >=20 > > Are you aware of the 7049bis effort? >=20 > I am now. If you would like my feedback I can review it and send you > comments. I realize it would not be appropriate to make any technical = changes > at this stage, but I may think of suggestions about minor wording = changes to > improve clarity. Is draft-ietf-cbor-7049bis-14 the latest version? >=20 >=20 > > So I believe there is no problem in the pseudocode (which only has a > comment changed in the above fix). > > > > A couple of questions come up here: > > > > * Is the pseudocode possibly too clever? > > > > Maybe. We even had one other misread of the pseudocode in > https://github.com/cbor-wg/CBORbis/issues/148. > > > > After seven years, I=E2=80=99m not sure that replacing the = time-tested code from RFC > 7049 by new code doesn=E2=80=99t incur too much risk. > > (In those seven years, we found we had to add one line, which checks = against > excluded two-byte forms of simple values.) >=20 > Now that I understand it properly, I see how the pseudocode works, and = I see > why I was confused. >=20 > Without comments or a definition in RFC7049 of the well_formed = function, I > was left guessing. I guessed (wrongly) that it is defined to return = the major type > of the item consumed. The new explanatory text in = draft-ietf-cbor-7049bis-14 > makes it clear that it is not this simple. >=20 > Yes, the pseudocode is clever. Not too clever -- there is considerable = merit in > being able to make pseudocode that fits on one page of an RFC. I think = a few > minor tweaks can reduce misunderstandings, and still keep it fitting = on a single > page. >=20 > A minor textual suggestion. One of the function definitions below has = a space > before the opening parenthesis and one does not. I would suggest = making them > consistent. > well_formed (breakable =3D false) > well_formed_indefinite(mt, breakable) >=20 > The comments in the pseudocode use the terms =E2=80=9Cfinite data = item=E2=80=9D and =E2=80=9Cfinite- > length chunk=E2=80=9D, which are not used elsewhere in the RFC. = Perhaps, to be > consistent with the rest of the document, I suggest = =E2=80=9Cdefinite-length item=E2=80=9D and > =E2=80=9Cdefinite-length chunk=E2=80=9D. >=20 > One thing I would suggest to improve the clarity of the code would be = not to > overload the value zero to mean *both* that an item with major type = zero was > consumed (positive integer) *and* that an indefinite-length item was > consumed (of any major type). >=20 > Perhaps well_formed_indefinite could return -1 when a "break" stop = code is > consumed, and -2 when an entire indefinite-length item is consumed. >=20 > Or maybe make well_formed_indefinite end with =E2=80=9Creturn mt | = 0x80=E2=80=9D so that it > *does* return the correct major type, but with the top bit set to show = that it > was an indefinite-length variant of that major type. >=20 > Also, the final comment =E2=80=9Cno break out=E2=80=9D is a little = confusing. What it really > means is that this *is* the end of an indefinite-length item, so it = really *does* > break out of processing a complete indefinite-length item. >=20 > Maybe the comments at the end of well_formed and = well_formed_indefinite > (respectively) could be: >=20 > well_formed: > return mt; // definite-length data item >=20 > well_formed_indefinite: > return mt | 0x80; // indefinite-length data item > or > return -2; // indefinite-length data item >=20 >=20 > > * Shouldn=E2=80=99t we allow indefinite strings as chunks in = indefinite strings? > > > > No. An implementation that wants to put together indefinite strings = from > strings that are (possibly) indefinite can simply take out the = brackets off the > inner ones. The actual use case for indefinite strings is = =E2=80=9Cstreaming=E2=80=9D, where you > just don=E2=80=99t know how long your string will be before you have = to start sending it, > called =E2=80=9Cchunking=E2=80=9D in other contexts. When you do that = and have an indefinite > string to send, it is very easy to take off the brackets (0x5f/0x7f = and 0xff). > > > > Having multiple ways to say the same thing can always lead to > interoperability issues (and increases the cost of interoperability = tests). > > > > Worse, some applications or implementations will start to ascribe = semantics > to the presence or absence of redundant pairs of brackets. > > > > Indefinite-length strings already add considerable complexity to = some CBOR- > consuming code; removing the ability to rely on only definit-length = chunks > being in there would add further complexity. >=20 > I agree with you 100% on this. The arguments you make, plus the stack = usage > point that Jim Schaad made, are all good. >=20 > However I didn=E2=80=99t find any explanation like this in = draft-ietf-cbor-7049bis-14. >=20 > Given that the CBOR format could trivially support nested = indefinite-length > strings, there may be temptation for creative implementers to = =E2=80=9Cimprove=E2=80=9D > CBOR by allowing this. I can imagine a discussion between engineers = debating > whether to do this. Having clear text in the RFC stating that this was = considered > and rejected, and is considered unnecessary and a bad idea, and why, = would > help avoid those engineering debates ending with the wrong conclusion. >=20 > Stuart Cheshire From nobody Mon Jul 6 02:37: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 1C4453A127E for ; Mon, 6 Jul 2020 02:37:44 -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, RCVD_IN_MSPIKE_H4=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 z6t5tyMKVFhL for ; Mon, 6 Jul 2020 02:37: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 339A53A127D for ; Mon, 6 Jul 2020 02:37:40 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B0gTZ5WlTzyhD; Mon, 6 Jul 2020 11:37:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Mon, 6 Jul 2020 11:37:38 +0200 Cc: Jim Schaad , Paul Hoffman , cbor@ietf.org X-Mao-Original-Outgoing-Id: 615721058.075371-98ac6aa433625019a1d2220c692960eb Content-Transfer-Encoding: quoted-printable Message-Id: <7195076E-C5B1-461B-A2BC-B1B5E8DC2E69@tzi.org> References: <20200704225242.3264EF406D5@rfc-editor.org> <25ADFCDD-1B4D-4A9C-87DE-780F89DC0F87@tzi.org> To: Stuart Cheshire X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] [Technical Errata Reported] RFC7049 (6221) 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, 06 Jul 2020 09:37:44 -0000 Hi Stuart, (Trimming CC list) Indeed, feedback is very welcome. The repository is at https://github.com/cbor-wg/CBORbis, which is also = where pull requests are being made that lead to future versions. The = current I-D version, for which publication has been requested, indeed is = draft-ietf-cbor-7049bis-14 > A minor textual suggestion. One of the function definitions below has = a space before the opening parenthesis and one does not. I would suggest = making them consistent. > well_formed (breakable =3D false) > well_formed_indefinite(mt, breakable) Fixed. > The comments in the pseudocode use the terms =E2=80=9Cfinite data = item=E2=80=9D and =E2=80=9Cfinite-length chunk=E2=80=9D, which are not = used elsewhere in the RFC. Perhaps, to be consistent with the rest of = the document, I suggest =E2=80=9Cdefinite-length item=E2=80=9D and = =E2=80=9Cdefinite-length chunk=E2=80=9D. Yes! Fixed. > One thing I would suggest to improve the clarity of the code would be = not to overload the value zero to mean *both* that an item with major = type zero was consumed (positive integer) *and* that an = indefinite-length item was consumed (of any major type). >=20 > Perhaps well_formed_indefinite could return -1 when a "break" stop = code is consumed, and -2 when an entire indefinite-length item is = consumed. >=20 > Or maybe make well_formed_indefinite end with =E2=80=9Creturn mt | = 0x80=E2=80=9D so that it *does* return the correct major type, but with = the top bit set to show that it was an indefinite-length variant of that = major type. I went for 99. (Shades of FORTRAN=E2=80=A6) > Also, the final comment =E2=80=9Cno break out=E2=80=9D is a little = confusing. What it really means is that this *is* the end of an = indefinite-length item, so it really *does* break out of processing a = complete indefinite-length item. >=20 > Maybe the comments at the end of well_formed and = well_formed_indefinite (respectively) could be: >=20 > well_formed: > return mt; // definite-length data item >=20 > well_formed_indefinite: > return mt | 0x80; // indefinite-length data item > or > return -2; // indefinite-length data item Fixed (with 99). >> * Shouldn=E2=80=99t we allow indefinite strings as chunks in = indefinite strings? >>=20 >> No. An implementation that wants to put together indefinite strings = from strings that are (possibly) indefinite can simply take out the = brackets off the inner ones. The actual use case for indefinite strings = is =E2=80=9Cstreaming=E2=80=9D, where you just don=E2=80=99t know how = long your string will be before you have to start sending it, called = =E2=80=9Cchunking=E2=80=9D in other contexts. When you do that and have = an indefinite string to send, it is very easy to take off the brackets = (0x5f/0x7f and 0xff). >>=20 >> Having multiple ways to say the same thing can always lead to = interoperability issues (and increases the cost of interoperability = tests). >>=20 >> Worse, some applications or implementations will start to ascribe = semantics to the presence or absence of redundant pairs of brackets. >>=20 >> Indefinite-length strings already add considerable complexity to some = CBOR-consuming code; removing the ability to rely on only definit-length = chunks being in there would add further complexity. >=20 > I agree with you 100% on this. The arguments you make, plus the stack = usage point that Jim Schaad made, are all good. >=20 > However I didn=E2=80=99t find any explanation like this in = draft-ietf-cbor-7049bis-14. This is what I wrote to go into Section 3.2.3: (Note that a decision has been made not to allow nesting indefinite-length strings as chunks into indefinite-length strings. This would require decoder implementations to keep a stack, or at least a count, of nesting levels. It is also unnecessary on the encoder side, as the inner indefinite-length string would consist of chunks, which can simply be put right into the outer indefinite-length string.) > Given that the CBOR format could trivially support nested = indefinite-length strings, there may be temptation for creative = implementers to =E2=80=9Cimprove=E2=80=9D CBOR by allowing this. I can = imagine a discussion between engineers debating whether to do this. = Having clear text in the RFC stating that this was considered and = rejected, and is considered unnecessary and a bad idea, and why, would = help avoid those engineering debates ending with the wrong conclusion. I agree that it is good to be explicit about these decisions. I turned these fixes/additions into a pull request, which I hope to be = turning into -15 together with any changes form the AD review. https://github.com/cbor-wg/CBORbis/pull/203 = https://cbor-wg.github.io/CBORbis/input-stuart/draft-ietf-cbor-7049bis.htm= l = https://tools.ietf.org/rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-ietf= -cbor-7049bis.txt&url2=3Dhttps://cbor-wg.github.io/CBORbis/input-stuart/dr= aft-ietf-cbor-7049bis.txt (The rfcdiff is less useful than expected because the xml2rfc processing = in the I-D submission pipeline is different from that in the version of = Martin Thomson=E2=80=99s I-D repo template we seem to be using.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 6 09:42: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 0C86F3A16F6; Mon, 6 Jul 2020 09:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BI-_r5w-9s4V; Mon, 6 Jul 2020 09:42:38 -0700 (PDT) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (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 030EF3A16EB; Mon, 6 Jul 2020 09:42:37 -0700 (PDT) Received: by mail-io1-f44.google.com with SMTP id f6so24481920ioj.5; Mon, 06 Jul 2020 09:42:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YUA7pyVhtd5TzMS2BrN62voL2luxsRNBfEFqVBzH/nk=; b=VfM8HTKdfQy7VsoM1CMXYEGtBHWgY13Xq8uNNE3To5Yhu5p+pEPYKOJrOC+xma3vlr Inwd++JUfXCBAbDsYh/b/RakX3rJkDJOi1YlzqcAir0LbuJr6k3x1yNqrBwwfzNvVKLA kVq7XEtM90IqW15NbF/SVI7DmcxeoOq2FYnJ3xQY7rOxKA4m+GyW2dQYo6+zm5xY7GI7 j9lqlTgwobA6958ZC2pNYdxgNoP02gc0RvbrAOKCi2YoSpvD1JTc7kXV8zZoZyaJMRTs D+j6YGqTtAhOi3Mrdn6KlWvVlXOH+sI/h+eH7IjRkrwWxdcsZkPXrtG73NEha/9R8DPR xG5w== X-Gm-Message-State: AOAM530Jlu4x1JzgSHbhKrC2ZRVTsvRWhqhTE5/9kPNB5YBzZaJVeBCC KMBuWgr0AhY/tbyRp/qz2+nOgLO46SWJbR4VK+w= X-Google-Smtp-Source: ABdhPJzJLJNYAjipkn/4tpXwRysOXNEsKwoAlrY9YyJreGaceH9wOnJ01qKLJq0Q2HeCsb7D7afM82WQhMwGuj9AzKY= X-Received: by 2002:a02:cd91:: with SMTP id l17mr52733831jap.88.1594053757198; Mon, 06 Jul 2020 09:42:37 -0700 (PDT) MIME-Version: 1.0 References: <20200704225242.3264EF406D5@rfc-editor.org> <25ADFCDD-1B4D-4A9C-87DE-780F89DC0F87@tzi.org> <07D4D5BC-C6F2-438A-B707-87B2928211F3@apple.com> In-Reply-To: <07D4D5BC-C6F2-438A-B707-87B2928211F3@apple.com> From: Barry Leiba Date: Mon, 6 Jul 2020 12:42:26 -0400 Message-ID: To: Stuart Cheshire Cc: Carsten Bormann , Jim Schaad , The IESG , cbor@ietf.org, Paul Hoffman , RFC Errata System Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cbor] [Technical Errata Reported] RFC7049 (6221) 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, 06 Jul 2020 16:42:39 -0000 On Sun, Jul 5, 2020 at 5:52 PM Stuart Cheshire wrote: > > On 4 Jul 2020, at 16:43, Carsten Bormann wrote: > > > Hi Stuart, > > > > thank you for this errata report. > > Thanks Carsten and Jim for your quick replies. > > And I apologize for filing a mistaken erratum report. RFC Editor, if it is possible to simply delete this erratum report, please do so. Alternatively, I can close it as "Held for Document Update". Barry From nobody Tue Jul 7 21:46:38 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 B2F5D3A07B7; Tue, 7 Jul 2020 21:46: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 jfFWjdwXdSZH; Tue, 7 Jul 2020 21:46:35 -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 0A7DB3A07BA; Tue, 7 Jul 2020 21:46:34 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 7 Jul 2020 21:46:28 -0700 From: Jim Schaad To: CC: References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> <5244.1593618673@localhost> <04FEC6E5-F8E9-472D-A4D6-71C6C00D79E6@tzi.org> <20200703060820.ydmbdmp5fy2v6wgf@anna.jacobs.jacobs-university.de> <99A557CE-559D-409A-A3DC-5D20F2F55F5E@tzi.org> <20200703064652.m7tuvfcglxyvfque@anna.jacobs.jacobs-university.de> <2A137293-075C-4862-91C2-CC583B9B2FF6@tzi.org> <20200703103212.kwl5pbxubznjqpf6@anna.jacobs.jacobs-university.de> In-Reply-To: Date: Tue, 7 Jul 2020 21:46:27 -0700 Message-ID: <00e401d654e2$bf5e78f0$3e1b6ad0$@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: AQMU5yeauQxX0hjM4GfOz2W/LucNvAH4br1nAKY8+HkBOcSm+QITMJZnAnyyGq4CVt8YfwKsgMEwAViKGgMBzvB2iAJ3KK1BpedkjuA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 04:46:37 -0000 Mike, Based on the messages that I have seen, I would suggest the following = actions: Create a new section dealing with the following:=20 a) a definition of what calendar day means b) a definition of a term other than Unix Epoch to be used as the basis. = This is a point in time rather than a calendar day so having this as = the basis point seems to be generation frisson. It would appear that it = is better to use 1970-01-01 as a POSIX calendar date epoch. c) Guidance on how to use two points in time to compute a calendar day = count. d) Information on why it is a bad idea or how to compare a calendar date = and a point in time. e) Guidance on how to compare two calendar dates (this should be easy). Jim > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Friday, July 3, 2020 5:11 AM > To: Juergen Schoenwaelder > Cc: draft-ietf-cbor-date-tag@ietf.org; Michael Richardson > ; cbor@ietf.org > Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time = zone offsets >=20 > On 2020-07-03, at 12:32, Juergen Schoenwaelder = university.de> wrote: > > > > PS: There are even events where there is no natural time zone that = can > > be associated with the event, like the first step on the moon. >=20 > (For those who weren=E2=80=99t there when it happened:) >=20 > Indeed, Monday, 1969-07-21T02:56:15Z. >=20 > Most Americans will tell you Sunday 1969-07-20 for the first steps. = The exact > time was actually specifically chosen to occur on prime time TV in the = US (and > then was slightly delayed, but managed to stay in window), which spans = several > time zones, which all have this on 1969-07-20. >=20 > Yes, I agree we should have some text on this (not the moon landing, = but the > issues in converting between calendar dates and times anchored on time > scales). >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Tue Jul 7 22:20: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 9BC3E3A0858; Tue, 7 Jul 2020 22:20:17 -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, RCVD_IN_MSPIKE_H4=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 sy-OHjVhOB4B; Tue, 7 Jul 2020 22:20:15 -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 832A83A0856; Tue, 7 Jul 2020 22:20:14 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B1ngT2xBDzybG; Wed, 8 Jul 2020 07:20:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <00e401d654e2$bf5e78f0$3e1b6ad0$@augustcellars.com> Date: Wed, 8 Jul 2020 07:19:58 +0200 Cc: draft-ietf-cbor-date-tag@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 615878398.560549-89ce546d15768d16b1c80aff0c49f275 Content-Transfer-Encoding: quoted-printable Message-Id: <4CB207D4-4CC4-4AA1-833D-9B1F9B47204B@tzi.org> References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> <5244.1593618673@localhost> <04FEC6E5-F8E9-472D-A4D6-71C6C00D79E6@tzi.org> <20200703060820.ydmbdmp5fy2v6wgf@anna.jacobs.jacobs-university.de> <99A557CE-559D-409A-A3DC-5D20F2F55F5E@tzi.org> <20200703064652.m7tuvfcglxyvfque@anna.jacobs.jacobs-university.de> <2A137293-075C-4862-91C2-CC583B9B2FF6@tzi.org> <20200703103212.kwl5pbxubznjqpf6@anna.jacobs.jacobs-university.de> <00e401d654e2$bf5e78f0$3e1b6ad0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 05:20:18 -0000 > On 2020-07-08, at 06:46, Jim Schaad wrote: >=20 > Mike, >=20 > Based on the messages that I have seen, I would suggest the following = actions: >=20 > Create a new section dealing with the following:=20 Let me try... > a) a definition of what calendar day means A calendar day is a day on a (here: the Gregorian) calendar. The specific mapping of calendar days on civil time (here: UTC) is = established by convention outside the scope of the date tags. > b) a definition of a term other than Unix Epoch to be used as the = basis. This is a point in time rather than a calendar day so having = this as the basis point seems to be generation frisson. It would appear = that it is better to use 1970-01-01 as a POSIX calendar date epoch. 1970-01-01 was chosen as the epoch for counting calendar days for the = date tags because it is convenient on systems that have Posix date/time = libraries available. > c) Guidance on how to use two points in time to compute a calendar day = count. Well, that goes deep into date/time library APIs. But, usually, these APIs allow you to apply a timezone to a point in = time and retrieve a calendar day and a time-of-day. By zeroing out the time-of-day, time deltas can be produced that, = divided by 86400 and *rounded* to the nearest integer give you a = calendar day count. Watch out when using historical dates (the Gregorian calendar has a = discontinuity in 1582, which was integrated into the civil calendars = either immediately or later, say, 1752, 1753, =E2=80=A6 or 1923 if you = are in Greece); make sure these are actually on the (proleptic) = Gregorian calendar already. Also, historically, the calendar date = changed at sunrise, noon (astronomical day/Julian day number), or sunset = on some calendars, and the year number on March 25th. Again, not a = problem as long as all dates are on the proleptic Gregorian calendar and = your date/time libraries aren=E2=80=99t broken (which many are for = historical dates). > d) Information on why it is a bad idea or how to compare a calendar = date and a point in time. A calendar date is not anchored on a timescale, only adding timezone = information does that. > e) Guidance on how to compare two calendar dates (this should be = easy). If you have the day number (tag 100), that is easy. If you have the RFC 3339 full-date, go through a date/time library = (using UTC as a time zone is the simplest approach). Amazing. I would not have thought that talking about calendar dates = would evoke all this complexity... Gr=C3=BC=C3=9Fe, Carsten >=20 > Jim >=20 >=20 >=20 >> -----Original Message----- >> From: CBOR On Behalf Of Carsten Bormann >> Sent: Friday, July 3, 2020 5:11 AM >> To: Juergen Schoenwaelder >> Cc: draft-ietf-cbor-date-tag@ietf.org; Michael Richardson >> ; cbor@ietf.org >> Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time = zone offsets >>=20 >> On 2020-07-03, at 12:32, Juergen Schoenwaelder = > university.de> wrote: >>>=20 >>> PS: There are even events where there is no natural time zone that = can >>> be associated with the event, like the first step on the moon. >>=20 >> (For those who weren=E2=80=99t there when it happened:) >>=20 >> Indeed, Monday, 1969-07-21T02:56:15Z. >>=20 >> Most Americans will tell you Sunday 1969-07-20 for the first steps. = The exact >> time was actually specifically chosen to occur on prime time TV in = the US (and >> then was slightly delayed, but managed to stay in window), which = spans several >> time zones, which all have this on 1969-07-20. >>=20 >> Yes, I agree we should have some text on this (not the moon landing, = but the >> issues in converting between calendar dates and times anchored on = time >> scales). >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Jul 8 10:26: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 954673A003E; Wed, 8 Jul 2020 10:26:07 -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 Y8ik5jEhqFJH; Wed, 8 Jul 2020 10:26:05 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640092.outbound.protection.outlook.com [40.107.64.92]) (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 98B843A003D; Wed, 8 Jul 2020 10:26:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dqyoSGiE1xILShNp+olKXRK1oRWMrSQ9Llx6hrVyzcVDlV/4tljoIsEvxW2d/66QnZeW+WWKT0w6bC3AezeF/va5GUH6JtF8zpIywd/OJ+Of/gQHUjOKjvfcUByZpnW08gL7AXSENAoTO8sXmRFR9iZFFMVLquH00D4Ye0jR7lRzujkx4Nkv1OUH96dOBdWX5fkbIyQuE9ncLHY/F6I33Zr7R9FPQS3E07T8Po/UXVgd60ZrLtUhBZDxcMIBOlcX1r4ZF7KKcipGu1cXV1BR3ngBl9cJzkglSCnWJrSr32sNSbL6/hxilRcmFOcbn5+7/Y6PNrhyx+8p1fqG4Qmy7A== 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=Hgb0BUaNRAmTH9DeVmUr8MgmKlz16GfIkNiIROMGLpg=; b=XN1a8ZC0STLqDDPcSfnoboDPQrnHK+ghLchc5Qp1ybS4QL097oHDBEe54YLQcdvfNvruU/TtLpkIlBVhGdNDwmVBSAw8aS+DungzeD1Ac/I9XOs69OdRKfUITJ0VC07fJvN3xIpJaAwh+hhEoBnxW/Et0mxxGSBrq3iZeiI/Q5F+eKI9s5M0iwgqOJIkI4J1CsD3HEnXETEMcKl4/vPzpGpULtp/81xaIWqOSaT94HG0CyK37GeISCdmzDpbbcGK6blLY1iqh/oIxyImP1+aUtaOZZsdxavRZtZrGrdq+jtcGdUO+VrGF541iXunpF9paLPDmRZ32pNOIipNgbcmfQ== 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=Hgb0BUaNRAmTH9DeVmUr8MgmKlz16GfIkNiIROMGLpg=; b=UH0yBuZF3+7fFKBcnD4Nh9v3vjO0rSjxshPcYj7Qjlo9R+Fo2Mvqn67hbLaUwvM8ns/A8gsMfHx3ANNRMnjmgrzN7arHJG386AfiHS61XSESZB6UsHcs42p9jpF/rji/PmfWGuh3PuWz7xXGuwvHx2FlHL0N14C5PmnJdzUYFIg= Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0338.namprd00.prod.outlook.com (2603:10b6:207:1f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3213.0; Wed, 8 Jul 2020 17:26:03 +0000 Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::2834:4ff8:111f:c308]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::2834:4ff8:111f:c308%9]) with mapi id 15.20.3213.000; Wed, 8 Jul 2020 17:26:03 +0000 From: Mike Jones To: Carsten Bormann , Jim Schaad CC: "draft-ietf-cbor-date-tag@ietf.org" , "cbor@ietf.org" Thread-Topic: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets Thread-Index: AdZVTNiYPeqQWbWHRAKE4VQU3qApQg== Date: Wed, 8 Jul 2020 17:26:03 +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=d6ab2a1f-85b7-4259-941c-ca1ffb9d1ece; 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-07-08T17:17:07Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c0366b12-717f-449f-8ee4-08d82363fda3 x-ms-traffictypediagnostic: BL0PR00MB0338: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HEqHUfGh9vdSh6JJ7fpR453HNA8haAFyfOIaNqs0Hhvid7wGZsIPp0vuwNCR4wLVA87LkYdF4RqfNjU8QIL/EhTHkBqQnf8zd1I9y63XEa1DQr5LbW2hClvJlzq0Z9LdBWgmpJouxjBmJ1xRSUDiRGoJ3PkeQn5PeMwDHORuXuZU5Lv2kHz/dIFTVtlAmFSibtuqftsDF2GzERt+sewyRBmv7HSTG+/70X0dD89P/MnsYGc1Cfz5ZfFlm10irTgi/kTWN03jmQuxWtTocVuGDpXSbGjvNx/FMpltR5m3byBalxmNxF29m/2dvMX0ot0L+XmaP3n+sCU5Ll3IQfO4yw07mZpAF6WHagzG7WZekzq3M6Cm/WEdsmkvoJEQa3tnTKhAF+TZUXAXnoMk8m/D4Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(396003)(376002)(346002)(136003)(33656002)(9686003)(52536014)(8676002)(110136005)(53546011)(8990500004)(54906003)(2906002)(8936002)(6506007)(82960400001)(82950400001)(55016002)(71200400001)(966005)(26005)(66556008)(86362001)(5660300002)(478600001)(66946007)(66476007)(316002)(4326008)(7696005)(76116006)(10290500003)(66446008)(83380400001)(64756008)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 1UW4bQollE9j4TPPvTfHqZ7GeMMByNYj2YC7yCphaGdWlT2H0TXiC0BydVl1tQOF9mWNh8nSa9s7+fKX9ltYxQYQpAQMO7ozY0fdblKTBn3u0MlkoLyuE5me/T3tmmG7RqlVv3/FXyYKbeaULXPkh+sfF9aLG42MOx/upX1QZFOHp0dQx3XkFKDbwv3gNA6NAEfB3CPcLSaQiVpGwDd22G/DMijD8Y6bJFq4oxy6cDEInNkauW4CZQ14mWB/PVIrLKjq8qJ8zXUuiGwkKaRF/uVy5xk0m5cCU420RjJqkjGnQmUCE7aqO16KR1u/hMOa8UEWaOtcQRRwnjDJknc/gTuA5SfTqOFH/JCqxy2J1WahaKxfUSLBfUtrpHn9CRP2GH8JuLnxfW9z5yAK3U9C6JOTPAIp/erbHHuueEUGZHF3Ocuc3DVYIlmQn73Zwt0NPBpVggdCpaRM3+FPRGKFmHCjv4Bg4YSBdVbh3fzVmBI= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c0366b12-717f-449f-8ee4-08d82363fda3 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2020 17:26:03.5301 (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: QE7NrpmpVuQvaMJCf3as7pud7nfydL4TCUrbDlUhVrEegIiRauy/FOozZ0/QJ3dS/lJ62oeIxuQwmJFeXrw25w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0338 Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 17:26:08 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgSmltLCBhbmQgZm9yIHlvdXIgc3RhYiBhdCBhZGRyZXNz aW5nIGl0LCBDYXJzdGVuLiAgSSdsbCBkbyBzb21lIG9mIHRoaXMsIGJ1dCBJIGRvbid0IHRoaW5r IHdlIHNob3VsZCBpbmNvcnBvcmF0ZSBpbmZvcm1hdGlvbiBhYm91dCBkZXRhaWxzIHZhZ2FyaWVz IG9mIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIgb3ZlciB0aGUgY2VudHVyaWVzLiAgU3VjaCBzdGF0 ZW1lbnRzIHdvdWxkbid0IGJlIGF1dGhvcml0YXRpdmUgb3IgYWN0aW9uYWJsZS4gIEknZCByYXRo ZXIgcmVmZXJlbmNlIGFub3RoZXIgUkZDIGFzIHRoZSBhdXRob3JpdHkgb24gdGltZSBwcm9jZXNz aW5nIHRoYW4gaW5jbHVkZSBkZXRhaWxzIGhlcmUsIHNpbmNlIHRpbWUgcHJvY2Vzc2luZyBpcyBv dXQgb2Ygc2NvcGUuICBJJ20gdGhpbmtpbmcgdGhhdCB3ZSBzaG91bGQgcmVmZXJlbmNlIFJGQyAz MzM5IGFzIHRoZSBhdXRob3JpdHkgb24gdGltZSBwcm9jZXNzaW5nLg0KDQpCVFcsIGhhdmUgdGhl IGNoYWlycyBkZWNpZGVkIHdobyB0aGUgc2hlcGhlcmQgd2lsbCBiZT8gIEknbSB3b25kZXJpbmcg d2hldGhlciB0byB3YWl0IHRvIGFkZCB0aGlzIG5ldyB0ZXh0IHVudGlsIHRoZSBzaGVwaGVyZCBy ZXZpZXcgYWxzbyBjb21lcyBpbi4NCg0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPiANClNlbnQ6IFR1 ZXNkYXksIEp1bHkgNywgMjAyMCAxMDoyMCBQTQ0KVG86IEppbSBTY2hhYWQgPGlldGZAYXVndXN0 Y2VsbGFycy5jb20+DQpDYzogZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnQGlldGYub3JnOyBjYm9y QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0Nib3JdIGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0w MiAtIGhhbmRsaW5nIG9mIHRpbWUgem9uZSBvZmZzZXRzDQoNCg0KPiBPbiAyMDIwLTA3LTA4LCBh dCAwNjo0NiwgSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4gd3JvdGU6DQo+IA0K PiBNaWtlLA0KPiANCj4gQmFzZWQgb24gdGhlIG1lc3NhZ2VzIHRoYXQgSSBoYXZlIHNlZW4sIEkg d291bGQgc3VnZ2VzdCB0aGUgZm9sbG93aW5nIGFjdGlvbnM6DQo+IA0KPiBDcmVhdGUgYSBuZXcg c2VjdGlvbiBkZWFsaW5nIHdpdGggdGhlIGZvbGxvd2luZzogDQoNCkxldCBtZSB0cnkuLi4NCg0K PiBhKSBhIGRlZmluaXRpb24gb2Ygd2hhdCBjYWxlbmRhciBkYXkgbWVhbnMNCg0KQSBjYWxlbmRh ciBkYXkgaXMgYSBkYXkgb24gYSAoaGVyZTogdGhlIEdyZWdvcmlhbikgY2FsZW5kYXIuDQpUaGUg c3BlY2lmaWMgbWFwcGluZyBvZiBjYWxlbmRhciBkYXlzIG9uIGNpdmlsIHRpbWUgKGhlcmU6IFVU QykgaXMgZXN0YWJsaXNoZWQgYnkgY29udmVudGlvbiBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUg ZGF0ZSB0YWdzLg0KDQo+IGIpIGEgZGVmaW5pdGlvbiBvZiBhIHRlcm0gb3RoZXIgdGhhbiBVbml4 IEVwb2NoIHRvIGJlIHVzZWQgYXMgdGhlIGJhc2lzLiAgVGhpcyAgaXMgYSBwb2ludCBpbiB0aW1l IHJhdGhlciB0aGFuIGEgY2FsZW5kYXIgZGF5IHNvIGhhdmluZyB0aGlzIGFzIHRoZSBiYXNpcyBw b2ludCBzZWVtcyB0byBiZSBnZW5lcmF0aW9uIGZyaXNzb24uICBJdCB3b3VsZCBhcHBlYXIgdGhh dCBpdCBpcyBiZXR0ZXIgdG8gdXNlIDE5NzAtMDEtMDEgYXMgYSBQT1NJWCBjYWxlbmRhciBkYXRl IGVwb2NoLg0KDQoxOTcwLTAxLTAxIHdhcyBjaG9zZW4gYXMgdGhlIGVwb2NoIGZvciBjb3VudGlu ZyBjYWxlbmRhciBkYXlzIGZvciB0aGUgZGF0ZSB0YWdzIGJlY2F1c2UgaXQgaXMgY29udmVuaWVu dCBvbiBzeXN0ZW1zIHRoYXQgaGF2ZSBQb3NpeCBkYXRlL3RpbWUgbGlicmFyaWVzIGF2YWlsYWJs ZS4NCg0KPiBjKSBHdWlkYW5jZSBvbiBob3cgdG8gdXNlIHR3byBwb2ludHMgaW4gdGltZSB0byBj b21wdXRlIGEgY2FsZW5kYXIgZGF5IGNvdW50Lg0KDQpXZWxsLCB0aGF0IGdvZXMgZGVlcCBpbnRv IGRhdGUvdGltZSBsaWJyYXJ5IEFQSXMuDQpCdXQsIHVzdWFsbHksIHRoZXNlIEFQSXMgYWxsb3cg eW91IHRvIGFwcGx5IGEgdGltZXpvbmUgdG8gYSBwb2ludCBpbiB0aW1lIGFuZCByZXRyaWV2ZSBh IGNhbGVuZGFyIGRheSBhbmQgYSB0aW1lLW9mLWRheS4NCkJ5IHplcm9pbmcgb3V0IHRoZSB0aW1l LW9mLWRheSwgdGltZSBkZWx0YXMgY2FuIGJlIHByb2R1Y2VkIHRoYXQsIGRpdmlkZWQgYnkgODY0 MDAgYW5kICpyb3VuZGVkKiB0byB0aGUgbmVhcmVzdCBpbnRlZ2VyIGdpdmUgeW91IGEgY2FsZW5k YXIgZGF5IGNvdW50Lg0KDQpXYXRjaCBvdXQgd2hlbiB1c2luZyBoaXN0b3JpY2FsIGRhdGVzICh0 aGUgR3JlZ29yaWFuIGNhbGVuZGFyIGhhcyBhIGRpc2NvbnRpbnVpdHkgaW4gMTU4Miwgd2hpY2gg d2FzIGludGVncmF0ZWQgaW50byB0aGUgY2l2aWwgY2FsZW5kYXJzIGVpdGhlciBpbW1lZGlhdGVs eSBvciBsYXRlciwgc2F5LCAxNzUyLCAxNzUzLCDigKYgb3IgMTkyMyBpZiB5b3UgYXJlIGluIEdy ZWVjZSk7IG1ha2Ugc3VyZSB0aGVzZSBhcmUgYWN0dWFsbHkgb24gdGhlIChwcm9sZXB0aWMpIEdy ZWdvcmlhbiBjYWxlbmRhciBhbHJlYWR5LiAgQWxzbywgaGlzdG9yaWNhbGx5LCB0aGUgY2FsZW5k YXIgZGF0ZSBjaGFuZ2VkIGF0IHN1bnJpc2UsIG5vb24gKGFzdHJvbm9taWNhbCBkYXkvSnVsaWFu IGRheSBudW1iZXIpLCBvciBzdW5zZXQgb24gc29tZSBjYWxlbmRhcnMsIGFuZCB0aGUgeWVhciBu dW1iZXIgb24gTWFyY2ggMjV0aC4gIEFnYWluLCBub3QgYSBwcm9ibGVtIGFzIGxvbmcgYXMgYWxs IGRhdGVzIGFyZSBvbiB0aGUgcHJvbGVwdGljIEdyZWdvcmlhbiBjYWxlbmRhciBhbmQgeW91ciBk YXRlL3RpbWUgbGlicmFyaWVzIGFyZW7igJl0IGJyb2tlbiAod2hpY2ggbWFueSBhcmUgZm9yIGhp c3RvcmljYWwgZGF0ZXMpLg0KDQo+IGQpIEluZm9ybWF0aW9uIG9uIHdoeSBpdCBpcyBhIGJhZCBp ZGVhIG9yIGhvdyB0byBjb21wYXJlIGEgY2FsZW5kYXIgZGF0ZSBhbmQgYSBwb2ludCBpbiB0aW1l Lg0KDQpBIGNhbGVuZGFyIGRhdGUgaXMgbm90IGFuY2hvcmVkIG9uIGEgdGltZXNjYWxlLCBvbmx5 IGFkZGluZyB0aW1lem9uZSBpbmZvcm1hdGlvbiBkb2VzIHRoYXQuDQoNCj4gZSkgR3VpZGFuY2Ug b24gaG93IHRvIGNvbXBhcmUgdHdvIGNhbGVuZGFyIGRhdGVzICh0aGlzIHNob3VsZCBiZSBlYXN5 KS4NCg0KSWYgeW91IGhhdmUgdGhlIGRheSBudW1iZXIgKHRhZyAxMDApLCB0aGF0IGlzIGVhc3ku DQpJZiB5b3UgaGF2ZSB0aGUgUkZDIDMzMzkgZnVsbC1kYXRlLCBnbyB0aHJvdWdoIGEgZGF0ZS90 aW1lIGxpYnJhcnkgKHVzaW5nIFVUQyBhcyBhIHRpbWUgem9uZSBpcyB0aGUgc2ltcGxlc3QgYXBw cm9hY2gpLg0KDQpBbWF6aW5nLiAgSSB3b3VsZCBub3QgaGF2ZSB0aG91Z2h0IHRoYXQgdGFsa2lu ZyBhYm91dCBjYWxlbmRhciBkYXRlcyB3b3VsZCBldm9rZSBhbGwgdGhpcyBjb21wbGV4aXR5Li4u DQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KPiANCj4gSmltDQo+IA0KPiANCj4gDQo+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogQ0JPUiA8Y2Jvci1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQo+PiBTZW50OiBGcmlkYXksIEp1bHkgMywg MjAyMCA1OjExIEFNDQo+PiBUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxk ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQo+PiBDYzogZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFn QGlldGYub3JnOyBNaWNoYWVsIFJpY2hhcmRzb24gDQo+PiA8bWNyK2lldGZAc2FuZGVsbWFuLmNh PjsgY2JvckBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtDYm9yXSBkcmFmdC1pZXRmLWNib3It ZGF0ZS10YWctMDIgLSBoYW5kbGluZyBvZiB0aW1lIA0KPj4gem9uZSBvZmZzZXRzDQo+PiANCj4+ IE9uIDIwMjAtMDctMDMsIGF0IDEyOjMyLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgDQo+PiA8ai5z Y2hvZW53YWVsZGVyQGphY29icy0gdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+Pj4gDQo+Pj4gUFM6 IFRoZXJlIGFyZSBldmVuIGV2ZW50cyB3aGVyZSB0aGVyZSBpcyBubyBuYXR1cmFsIHRpbWUgem9u ZSB0aGF0IGNhbg0KPj4+ICAgYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBldmVudCwgbGlrZSB0aGUg Zmlyc3Qgc3RlcCBvbiB0aGUgbW9vbi4NCj4+IA0KPj4gKEZvciB0aG9zZSB3aG8gd2VyZW7igJl0 IHRoZXJlIHdoZW4gaXQgaGFwcGVuZWQ6KQ0KPj4gDQo+PiBJbmRlZWQsIE1vbmRheSwgMTk2OS0w Ny0yMVQwMjo1NjoxNVouDQo+PiANCj4+IE1vc3QgQW1lcmljYW5zIHdpbGwgdGVsbCB5b3UgU3Vu ZGF5IDE5NjktMDctMjAgZm9yIHRoZSBmaXJzdCBzdGVwcy4gICBUaGUgZXhhY3QNCj4+IHRpbWUg d2FzIGFjdHVhbGx5IHNwZWNpZmljYWxseSBjaG9zZW4gdG8gb2NjdXIgb24gcHJpbWUgdGltZSBU ViBpbiANCj4+IHRoZSBVUyAoYW5kIHRoZW4gd2FzIHNsaWdodGx5IGRlbGF5ZWQsIGJ1dCBtYW5h Z2VkIHRvIHN0YXkgaW4gDQo+PiB3aW5kb3cpLCB3aGljaCBzcGFucyBzZXZlcmFsIHRpbWUgem9u ZXMsIHdoaWNoIGFsbCBoYXZlIHRoaXMgb24gMTk2OS0wNy0yMC4NCj4+IA0KPj4gWWVzLCBJIGFn cmVlIHdlIHNob3VsZCBoYXZlIHNvbWUgdGV4dCBvbiB0aGlzIChub3QgdGhlIG1vb24gbGFuZGlu ZywgDQo+PiBidXQgdGhlIGlzc3VlcyBpbiBjb252ZXJ0aW5nIGJldHdlZW4gY2FsZW5kYXIgZGF0 ZXMgYW5kIHRpbWVzIA0KPj4gYW5jaG9yZWQgb24gdGltZSBzY2FsZXMpLg0KPj4gDQo+PiBHcsO8 w59lLCBDYXJzdGVuDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBDQk9SIG1haWxpbmcgbGlzdA0KPj4gQ0JPUkBpZXRmLm9yZw0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYm9yDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBDQk9SIG1haWxpbmcg bGlzdA0KPiBDQk9SQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2Jvcg0KDQo= From nobody Wed Jul 8 14:27:29 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922543A0772 for ; Wed, 8 Jul 2020 14:27:20 -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 hHtUvq0zrgrL for ; Wed, 8 Jul 2020 14:27:18 -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 24CB03A07BD for ; Wed, 8 Jul 2020 14:27:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 73CB8389A0; Wed, 8 Jul 2020 17:24:21 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GLq2h6WgHvLS; Wed, 8 Jul 2020 17:24:20 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A8EC538999; Wed, 8 Jul 2020 17:24:20 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E289A4B5; Wed, 8 Jul 2020 17:27:14 -0400 (EDT) From: Michael Richardson To: Mike Jones , cbor@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] draft-ietf-cbor-date-tag-02 - handling of time zone offsets X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 21:27:27 -0000 --=-=-= Content-Type: text/plain Mike Jones wrote: > Thanks for your review, Jim, and for your stab at addressing it, > Carsten. I'll do some of this, but I don't think we should incorporate > information about details vagaries of the Gregorian calendar over the > centuries. > Such statements wouldn't be authoritative or actionable. I suggest you include text like: Note that since both tags are for dates without times, time zones and leap seconds are not applicable to these values. These tags are both for representations of calendar dates. + These formats are capable of representing dates in the distant past as + well as in the future. There have been a variety of calendars in use + prior to modern times, and this specification may not be suitable for uses + where human centric calendar concepts like the day of the week are important. I suggest that you start: When using a calendar date for decision making, for example access control, it needs to be noted that since calendar dates do not represent a specific point in time, the results of the evaluation can differ depending upon where the decision is made. For instance, a person may have reached their 21st birthday in Japan while simultaneously being a day short of their 21st birthday in Hawaii. as a new paragraph. * Would an RFC3339 example be worth while? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8GOjIACgkQgItw+93Q 3WWvsAf/TWOQA37RvebJV4UoWh5qds2finH5qn2ngc9gDFEvhlbd+D/XVmrGSS8T BL6rWWEQQUmkjGchRDI0dKj6Zwc0UhlgMynUA2XuAMBJanh9E8fBJedlVuNn8jHY X+SQd5d2+VsJrez1QSrru7OcOCqIno4Oyu+KXxLFahOk7OHS3QydYm7D0va2jIg8 ivjh7wkz1jZzXs24YYnAbYmZH8GoDGDHO/Idr/XTks92UmqXdCYIY4zci6kjiDRw TbJLVJn4aNHf1dgM4HC/8a19tA/VosodECUV4n/xVyysUEcUZELYt8P1w3oZWTt6 55OgbwZUV+Ug+35YkqQK01J95b8u9g== =sTjr -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 8 21:04: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 E02A03A0EE1; Wed, 8 Jul 2020 21:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DtuA6DxC-oEu; Wed, 8 Jul 2020 21:04:11 -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 8157F3A0EDA; Wed, 8 Jul 2020 21:04:10 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 8 Jul 2020 21:04:03 -0700 From: Jim Schaad To: 'Mike Jones' , 'Carsten Bormann' CC: , References: In-Reply-To: Date: Wed, 8 Jul 2020 21:04:02 -0700 Message-ID: <014101d655a5$fcf4ba30$f6de2e90$@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: AQJIhsHhPONjQ3BTLLKJx5D/wiZg36gaPg1A Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 09 Jul 2020 04:04:13 -0000 Yes we know who is doing the shepherd review. She has started doing it = I think.=20 I agree that I don't want to deal with differences in calendars. It = might have been easier to go with the Jewish calendar but that would not = be at all well known. The conversions on dates should assume that the = calendars are the same (and reasonable). Jim > -----Original Message----- > From: Mike Jones > Sent: Wednesday, July 8, 2020 10:26 AM > To: Carsten Bormann ; Jim Schaad = > Cc: draft-ietf-cbor-date-tag@ietf.org; cbor@ietf.org > Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time = zone offsets >=20 > Thanks for your review, Jim, and for your stab at addressing it, = Carsten. I'll do > some of this, but I don't think we should incorporate information = about details > vagaries of the Gregorian calendar over the centuries. Such = statements > wouldn't be authoritative or actionable. I'd rather reference another = RFC as > the authority on time processing than include details here, since time > processing is out of scope. I'm thinking that we should reference RFC = 3339 as > the authority on time processing. >=20 > BTW, have the chairs decided who the shepherd will be? I'm wondering > whether to wait to add this new text until the shepherd review also = comes in. >=20 > -- Mike >=20 > -----Original Message----- > From: Carsten Bormann > Sent: Tuesday, July 7, 2020 10:20 PM > To: Jim Schaad > Cc: draft-ietf-cbor-date-tag@ietf.org; cbor@ietf.org > Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time = zone offsets >=20 >=20 > > On 2020-07-08, at 06:46, Jim Schaad wrote: > > > > Mike, > > > > Based on the messages that I have seen, I would suggest the = following > actions: > > > > Create a new section dealing with the following: >=20 > Let me try... >=20 > > a) a definition of what calendar day means >=20 > A calendar day is a day on a (here: the Gregorian) calendar. > The specific mapping of calendar days on civil time (here: UTC) is = established > by convention outside the scope of the date tags. >=20 > > b) a definition of a term other than Unix Epoch to be used as the = basis. This > is a point in time rather than a calendar day so having this as the = basis point > seems to be generation frisson. It would appear that it is better to = use 1970- > 01-01 as a POSIX calendar date epoch. >=20 > 1970-01-01 was chosen as the epoch for counting calendar days for the = date > tags because it is convenient on systems that have Posix date/time = libraries > available. >=20 > > c) Guidance on how to use two points in time to compute a calendar = day > count. >=20 > Well, that goes deep into date/time library APIs. > But, usually, these APIs allow you to apply a timezone to a point in = time and > retrieve a calendar day and a time-of-day. > By zeroing out the time-of-day, time deltas can be produced that, = divided by > 86400 and *rounded* to the nearest integer give you a calendar day = count. >=20 > Watch out when using historical dates (the Gregorian calendar has a > discontinuity in 1582, which was integrated into the civil calendars = either > immediately or later, say, 1752, 1753, =E2=80=A6 or 1923 if you are in = Greece); make > sure these are actually on the (proleptic) Gregorian calendar already. = Also, > historically, the calendar date changed at sunrise, noon (astronomical > day/Julian day number), or sunset on some calendars, and the year = number on > March 25th. Again, not a problem as long as all dates are on the = proleptic > Gregorian calendar and your date/time libraries aren=E2=80=99t broken = (which many > are for historical dates). >=20 > > d) Information on why it is a bad idea or how to compare a calendar = date and > a point in time. >=20 > A calendar date is not anchored on a timescale, only adding timezone > information does that. >=20 > > e) Guidance on how to compare two calendar dates (this should be = easy). >=20 > If you have the day number (tag 100), that is easy. > If you have the RFC 3339 full-date, go through a date/time library = (using UTC as > a time zone is the simplest approach). >=20 > Amazing. I would not have thought that talking about calendar dates = would > evoke all this complexity... >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > > > > Jim > > > > > > > >> -----Original Message----- > >> From: CBOR On Behalf Of Carsten Bormann > >> Sent: Friday, July 3, 2020 5:11 AM > >> To: Juergen Schoenwaelder > >> Cc: draft-ietf-cbor-date-tag@ietf.org; Michael Richardson > >> ; cbor@ietf.org > >> Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time > >> zone offsets > >> > >> On 2020-07-03, at 12:32, Juergen Schoenwaelder > >> wrote: > >>> > >>> PS: There are even events where there is no natural time zone that = can > >>> be associated with the event, like the first step on the moon. > >> > >> (For those who weren=E2=80=99t there when it happened:) > >> > >> Indeed, Monday, 1969-07-21T02:56:15Z. > >> > >> Most Americans will tell you Sunday 1969-07-20 for the first steps. = The > exact > >> time was actually specifically chosen to occur on prime time TV in > >> the US (and then was slightly delayed, but managed to stay in > >> window), which spans several time zones, which all have this on = 1969-07-20. > >> > >> Yes, I agree we should have some text on this (not the moon = landing, > >> but the issues in converting between calendar dates and times > >> anchored on time scales). > >> > >> 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 From nobody Thu Jul 9 00:37:58 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 EDA4F3A086E; Thu, 9 Jul 2020 00:37:56 -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, RCVD_IN_MSPIKE_H4=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 RiN_SdPz3fLu; Thu, 9 Jul 2020 00:37:54 -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 90A133A086C; Thu, 9 Jul 2020 00:37:54 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B2Sgv2rBjz17p1; Thu, 9 Jul 2020 09:37:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <014101d655a5$fcf4ba30$f6de2e90$@augustcellars.com> Date: Thu, 9 Jul 2020 09:37:35 +0200 Cc: Mike Jones , draft-ietf-cbor-date-tag@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 615973055.2951061-8584596602d9aee061858a21744d97f2 Content-Transfer-Encoding: quoted-printable Message-Id: References: <014101d655a5$fcf4ba30$f6de2e90$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets 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, 09 Jul 2020 07:37:57 -0000 > On 2020-07-09, at 06:04, Jim Schaad wrote: >=20 > I agree that I don't want to deal with differences in calendars. =20 Tag 100 is calendar agnostic, as long as the calendar has an equivalent = to what is 1970-01-01 in the Gregorian calendar, and can count earth = days back/forward from that. Tag 1004 has the Gregorian calendar baked in, with leap years etc. That = also means that 1582-10-04 (100(-141428)) is immediately followed by = 1582-10-15 (100(-141427)), and even more caution is needed before this = date (proleptic Gregorian calendar). But we don=E2=80=99t have to = explain all that, just point out that there is some complexity with the = proleptic Gregorian calendar. Tag 100 dates inherit some of that complexity if combined with/converted = to/from Gregorian dates, more so if the conversion actually is to/from a = date-time anchored to a time zone (civil time). That is also pretty = much all we need to say about that. > It might have been easier to go with the Jewish calendar but that = would not be at all well known. The conversions on dates should assume = that the calendars are the same (and reasonable). I=E2=80=99d go with the French revolutionary calendar =E2=80=94 ten-day = weeks (properly split into five workdays and five-day weekends, of = course) would be so much more natural. But I digress=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 9 07:06: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 427033A0B87 for ; Thu, 9 Jul 2020 07:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 CDALydxxvbsL for ; Thu, 9 Jul 2020 07:06:44 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130073.outbound.protection.outlook.com [40.107.13.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 C8FFA3A0B8B for ; Thu, 9 Jul 2020 07:06:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lhmTJKMAv4EQ+1dIPQ8BlSjCSQhKXvLEa01bwGQ5l7xl9V5vKgclMwXUeqIOrzZ7BZaJjjJDK4SP1s77ZnRG+LQtbyLB9vmnOjCuEVg+Jfj1t2Wd+/VIw8QY3cUNhaiN+rtjcrgn3gJLyrfcrYkv4FtirWuHUHeAcgvZTyUoxPjRaJK1yrmK6dMEvauHNRDBert8qGlh4hiWIegW/kTrvX+cWiERUFjbSXhRxv+c/Pqaiw7QIRw9dXXag3PDald+SHPvltqNUlrzZc8oBDgCfSZEBTrLH+6l2RfBBg4fhkcbhqL5lhCECkkw0eF7MC/SNEcztduhmAWu6lXIDKPTiA== 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=WpyfmNCNIyweYTuFpnP9wGIC/a+lr/IypIBWetAnDv8=; b=npxZqs4U7z2FL6OIIgCRQ1miTiFzDLjM/SB7SmHUTud5n05nAuZUhdo4CSND/ektn7tX1/uqfWVqMHCpZsxC7MrdjLUn08NVLqngdn+sLU5tNmtNGQg5waVATjVnzbrVai/p8dgNDr7wO48Jb7GBEyelqrkLXg3XMnBLWC+oJT6KR29JmdLGRquiVv1xX9PG1pJK+hvLMxxCmCjlL4iZz7fnfdcYWh/CB0nWffzKcAcr0LfY5xvqUa6Z0e3mxs5mfj+669h81jtRXfJVYRiiA4Eq9qkzb2swl4n6xQiL64gOgqgobzP+i/6vERAtY0qqkZUInoOk6+tSqntGXnopXg== 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=WpyfmNCNIyweYTuFpnP9wGIC/a+lr/IypIBWetAnDv8=; b=ustRS6EfuuiAI8exFtKWGH9HYs4ZgIh/bAGU25WFxzPabuCR99/N3jPAzJKjZoasFFGZQBzgpx+PzsSf3NkAahKt11Fssw766u2VOEgc6P2soLv+V7iSJRWbRun5M/f9IszY8BiFEf4UlmvuwdTJtaNGPkuGGkoNBt18dArYn80= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0701MB2777.eurprd07.prod.outlook.com (2603:10a6:3:99::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.16; Thu, 9 Jul 2020 14:06:41 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3174.022; Thu, 9 Jul 2020 14:06:41 +0000 From: Francesca Palombini To: Mike Jones , "cbor@ietf.org" Thread-Topic: Review of draft-ietf-cbor-date-tag-03 Thread-Index: AQHWVforjATfXTEzb0Ka+jqc+aOJ7w== Date: Thu, 9 Jul 2020 14:06:41 +0000 Message-ID: <8919FFEE-2A57-4C0D-975C-5B65B3CC3AE8@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.153.190.14] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b057a7de-82b6-4a04-640a-08d824114dfc x-ms-traffictypediagnostic: HE1PR0701MB2777: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: E3/vLM/IGUd+SX0Y5JKsMxnKAa1wnNLQVAN7L7EBH5LnrO48vAGnDSMyID7nStcUAtzS/5UK0i0HxrCf8vjWqDrj6qmUU4vX5VJSMFFfL7M5XHDEtAerPBAgKTE6EKjtDVWXkkVSg2jAgcmD/6xPrxlFoYmtxBonjDc5D6zUUtQ4DVIF1NDQa8Gaa0RX96XJ5sR9tANPM2VBpX3fAppHOL/eXFMEtsXnuM3x2ayVQJWBePmUI5/iTUrQ9acG9rkUiB6o2ubZq0jULOGkn2jnb1qd0ES49S2zCbmurgXhaeIwVgSQ/VvwWSh07mfBoOtziEkNuDLlmFpOjy7RAaD5QQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(346002)(39860400002)(136003)(366004)(4744005)(33656002)(8936002)(8676002)(66556008)(110136005)(316002)(66446008)(6512007)(76116006)(91956017)(6486002)(478600001)(71200400001)(2906002)(86362001)(44832011)(186003)(36756003)(26005)(66946007)(2616005)(6506007)(64756008)(66476007)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: MHFNDPY28TZdDhCv56czdQ0Kw7d/KVEBkANEVZ88VgGyRXh3SZyV+6WoXSxn6jtz0eChfpbF6YeMwxQab99decJtoTuU9d4wKH7twRTQ02sBIW7o1yoijTtpncIv5M8Cmr368a0tIxwSHZ7Zo3y5fAUSftutLaSMs0s8wj7oR5NT4M2FFSSvoTyqQxJhd9He2mO5V5rPygDNUutzForHodo/NdvthFXUt7jw+PSgIzhJLcr5om6jmrs42CadhYLQDW0uwMxlZstVzFrPMrhgkLrx18w/MOQcv1XQ7G8vHa9Zd1CRMnmHdzneJWHbQTFP61JshVBLJD4tl7b789U4B2K2iwD1Ms0OMlI5BCcaKNcN66RWPkR79prC/EvPTvnlVXKVN5i267wZynA7yaEZCkT03IrvtFnTcW7x3bvixrgt7gETXt6kbKwHy6im/XABc94ma9rNaKa5Zf69mM0uWBJa5ORKq0AN9vqCRFWLMrbM5pVjCOPf6I9qB02AVPDy 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b057a7de-82b6-4a04-640a-08d824114dfc X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2020 14:06:41.3286 (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: LFd5gxNTR4IenLhTdCDhcQBg5ROh3K9qZ2GyBt9izSOLEjg1F69NtSgY3dN/QcRqYMX35LJmpEdRs624u8iFTL/HJgnXSCpxBNqvWxpQDDJD3yJRqi6rsjokauWgH+m/ X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2777 Archived-At: Subject: [Cbor] Review of draft-ietf-cbor-date-tag-03 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, 09 Jul 2020 14:06:45 -0000 SGkgTWlrZSwNCg0KV2hpbGUgcmV2aWV3aW5nIGZvciB0aGUgc2hlcGhlcmQgd3JpdGV1cCBJIGZv dW5kIHRoZSBmb2xsb3dpbmcgbWlub3IgaXNzdWVzOg0KDQpTZWN0aW9uIDE6DQpJIHdvdWxkIHN1 Z2dlc3QgcmVtb3ZpbmcgdGhlIGNvbW1hIGZyb20gdGhlIG51bWJlcjogNDAsNTg3LiBVc2luZyB0 aGUgY29tbWEgYXMgc2VwYXJhdG9yIGlzIG5vdCB0aGUgYmVzdCwgYXMgaW4gc29tZSBjb3VudHJp ZXMgaXQgaXMgdXNlZCBhcyBkZWNpbWFsIHNpZ24gKGFsc28gbm90IHByZWZlcnJlZCBidXQgYWxs b3dlZCBpbiBJU08gODYwMSkuDQoNCkZyb20gSS1EIG5pdHM6DQogID09IFRoZSBkb2N1bWVudCBk b2Vzbid0IHVzZSBhbnkgUkZDIDIxMTkga2V5d29yZHMsIHlldCBzZWVtcyB0byBoYXZlIFJGQw0K ICAgICAyMTE5IGJvaWxlcnBsYXRlIHRleHQuDQpJcyBpdCBuZWNlc3NhcnkgdG8gaGF2ZSB0aGUg MjExOSAtIDgxNzQgYm9pbGVycGxhdGUgdGV4dCBldmVuIGlmIG5vIG5vcm1hdGl2ZSBrZXl3b3Jk cyBhcmUgdXNlZD8gDQoNCltQT1NJWC4xXSBzZWVtcyBtb3JlIGxpa2UgYSBub3JtYXRpdmUgcmVm ZXJlbmNlIHRvIG1lLCBkb24ndCB5b3UgdGhpbms/DQoNClRoYW5rcywNCkZyYW5jZXNjYQ0KDQo= From nobody Thu Jul 9 10:43: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 E81253A0DE2 for ; Thu, 9 Jul 2020 10:43:41 -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, RCVD_IN_MSPIKE_H4=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 locz7sQ_Qsz1 for ; Thu, 9 Jul 2020 10:43:39 -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 A67A63A0DDE for ; Thu, 9 Jul 2020 10:43:39 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B2k6x3rXKzyVj; Thu, 9 Jul 2020 19:43:37 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <8919FFEE-2A57-4C0D-975C-5B65B3CC3AE8@ericsson.com> Date: Thu, 9 Jul 2020 19:43:37 +0200 Cc: Mike Jones , "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 616009417.070136-c9d647d0ea9236afc4932d8ee291df6b Content-Transfer-Encoding: quoted-printable Message-Id: <4E660A0C-1124-4D49-945D-A072321D095A@tzi.org> References: <8919FFEE-2A57-4C0D-975C-5B65B3CC3AE8@ericsson.com> To: Francesca Palombini X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Review of draft-ietf-cbor-date-tag-03 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, 09 Jul 2020 17:43:42 -0000 On 2020-07-09, at 16:06, Francesca Palombini = wrote: >=20 > [POSIX.1] seems more like a normative reference to me, don't you = think? Actually, no. You do not have to have read that to implement this spec. (This is markedly different from Tag 1). The epoch used for tag 100 is inspired by UNIX time (Posix), but does = not rely in its definition on understanding UNIX time. (As we have = found, understanding UNIX time is slightly counterproductive :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 10 09:21: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 C26B33A0C57 for ; Fri, 10 Jul 2020 09:21:49 -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, RCVD_IN_MSPIKE_H4=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 LF9-RMAzn0Xh for ; Fri, 10 Jul 2020 09:21:46 -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 AB3513A0C46 for ; Fri, 10 Jul 2020 09:21:46 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B3JG10D0CzycY; Fri, 10 Jul 2020 18:21:45 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 616090904.268791-18b6bfe9dfda615522275424a0b53e86 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 10 Jul 2020 18:21:44 +0200 Message-Id: <8E326169-AB6E-4447-8D45-73AEB210866B@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Cbor] CDDL modules and Semantic labels 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, 10 Jul 2020 16:21:50 -0000 A CDDL specification can not only be used for validating an instance = (which is yielding a yes/no decision and nothing else), but also to = annotate the instance tree with semantic labels (resulting in an = annotated "post-validation instance"). (A not very well-developed version of semantic labels becomes visible as = comments in the CDDL tool when using the secret "vp" or "gp" features.) There are two main sources for semantic labels in CDDL: -- rule names -- keys in group entries When validating an instance successfully(*) matches a subtree against a = rule, the name of the rule can be used as a semantic identifier for that = subtree. This means that rule names can have an impact beyond serving = as an internal identifier in a CDDL specification. We currently do not have a way to indicate that a rule name is = *intended* to serve as a semantic identifier; so rules that only exist = to structure or factor some specification may accidentally introduce an = unwanted semantic identifier. Of course, a simple convention such as = capitalizing semantic identifiers and using lower case rule names for = rules without such identification intent works. Once we are putting = together specifications from modules coming from different sources, we'd = need to agree on such a convention though, or be able to indicate it = separately for each module. Keys in group entries have an implicit identifying meaning (obvious for = maps, where they actually occur in the data item), or their meaning can = be buried in the specification (for arrays and "&" choices -- see = Section 2.2.2.2 of RFC 8610 [1] for an example of the latter). Since = they generally are redundant, some identifying intent could be implied = from the latter use. However, often the identification is local to the = array/choice; it would be beneficial to be able to anchor these in their = context: steak =3D &(bleu: 0, a-point: 1, incinere: 2) couleur =3D &(rouge: 0, jaune: 1, vert: 2, bleu: 3) Gr=C3=BC=C3=9Fe, Carsten (*) Where "successfully" here means that there is not only a match, but = that this match is the one that is actually used in the enclosing = construct (i.e., it is not undone through backtracking). [1]: https://tools.ietf.org/html/rfc8610#section-2.2.2.2 From nobody Fri Jul 10 09:27:08 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 87D143A0C57 for ; Fri, 10 Jul 2020 09:27:05 -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, RCVD_IN_MSPIKE_H4=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 nslB7ExDhPil for ; Fri, 10 Jul 2020 09:27:03 -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 A559F3A0EEF for ; Fri, 10 Jul 2020 09:27:01 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B3JN42kk1zycY; Fri, 10 Jul 2020 18:27:00 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 616091219.5651881-0a528c076f55465db1d837a2efad645c Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 10 Jul 2020 18:26:59 +0200 Message-Id: <413FE7A3-F98C-4593-8513-E5E1C7A0FA74@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Cbor] CDDL modules: sockets and features 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, 10 Jul 2020 16:27:06 -0000 CDDL provides a convention to indicate extension points by "sockets", = Section 3.9 of RFC 8610 [1]. That section provides a few examples how = sockets can be used for indicating extensibility for both type choices = and group choices. In practice, a specification will tend to provide the "plugs" = (alternatives filled in for a socket) that exist at the time the = specification, but of course cannot provide those that will be defined = only in the future. A common idiom to provide unlimited extensibility is to provide the = general type of the alternatives expected in the socket as a last item = in the choice: foo =3D $foo / text $foo /=3D "ant" $foo /=3D "bat" $foo /=3D "cat" This can be combined with .within to restrict what can go into the = socket: foo =3D $foo .within text / text ... (which is a bit non-DRY [2], but usually tolerably so). The problem with this idiom is that anything validates now; there is no = longer any help in identifying typos. The .feature control operator = comes to the rescue: foo =3D $foo .within text / text .feature "foo-ext" ... When the CDDL tool is asked to generate ten examples for this: /foo/ "cat" /foo/ "isolationist" /foo/ "treater" /foo/ "bat" /foo/ "ant" /foo/ "bat" /foo/ "epigenist" /foo/ "transpersonal" /foo/ "recast" /foo/ "uncompounding" it tells us: ** Features potentially used: foo-ext: ["isolationist"] ** Features potentially used: foo-ext: ["treater"] ** Features potentially used: foo-ext: ["epigenist"] ** Features potentially used: foo-ext: ["transpersonal"] ** Features potentially used: foo-ext: ["recast"] ** Features potentially used: foo-ext: ["uncompounding"] So we get warned (the warning is not a validation failure!) that there = are six new words in the foo-ext extension point (some of which might be = typos) besides the already sanctioned usage of ant, bat, and cat. Sockets have been defined already to allow composition, there is = relatively little support needed to do that composition beyond single = modules (some form of namespacing, I'd think). A related question is how CDDL specifications might incorporate = alternatives that are registered in an IANA registry; this could be = modeled as a module import to a module that is generated from the = current state of that registry. Gr=C3=BC=C3=9Fe, Carsten [1]: https://tools.ietf.org/html/rfc8610#section-3.9 [2]: https://en.wikipedia.org/wiki/Don%27t_repeat_yourself [3]: https://en.wikipedia.org/wiki/C_preprocessor#Token_stringification From nobody Fri Jul 10 15:43: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 302763A0BC7 for ; Fri, 10 Jul 2020 15:43:29 -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 kvXuzpVE99Av for ; Fri, 10 Jul 2020 15:43:28 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640126.outbound.protection.outlook.com [40.107.64.126]) (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 2E0E03A0B8F for ; Fri, 10 Jul 2020 15:43:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iRhtQsOrcwcReVHupAsXPwqbglyMm6zpR64Bg+69RwNGzA9kImjZxExwo6xW6m15F6lhqdU7qznT3bN6TLlpVuDBTwAQ2I64zKkU91AKFEgdpbtZr+jIzf+DSNzHswQyBtfP7rg6Ic62niNhdbwiEiFM8HR4AUQQqEPJYTJh1LPhArCPvfB9CYWZXv2ftTh1SFW3aZwGLzASHN9HGtrJDLq7TYOxnj5Z0zAJt2S2OPYOP1sp56zcI//4NNR3c0jjIhKbPFR0mNwFVSzGvgHYuIKQDdjxY/gKEGRl/rn6FjnrybyJCd8xpbbODLyooIRCLF4k68evjKvlsH7HFFcOCg== 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=scZMMlWxUo2ZXo/UCyjtli73lt2fJc/EPA939rkQ7BI=; b=nh+9pERwB3pCLbERTVgW9eziSxB54JjIJ7wRt+oWt7f15YefAhzbgEwo5CwdMPUKUWVeDD+hGV3KvGKWASIcLAZKFKDVri18L/p2Bf4TMAM4XhXF5b4HjKOb2+qkLjHoANxK/urF3DerM+aotb7pYQdV8e0uzivBcW+el3zKSx4hCHoy9kQWJJkUZIIQkPaKMogpsLN8aoIxjltHQYtlPn36lp8sv8CB54YwF6waFm1hooZkh1ZI0flJuGi/m9qjuE2tyRB4OrmsTGMgSqNUBV52muk84MofKkPRf+/omoM/DYJMta09YNo1kkfryE0dtfeMYNjJLXyuKPFHztTqnw== 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=scZMMlWxUo2ZXo/UCyjtli73lt2fJc/EPA939rkQ7BI=; b=R5obBqTVXwx9Y3JfjkuKa3LpzLFix6DDyjAcwKHj6QzOKdizQ3qPHGCHBDbP1ILUtcDhtRfUL/6m+jR7z2H9Vb5wt5S3Xv973AhmSHhjxeMhhe8vfdFEBGLFLfXwel9FnwzkAZvc5SPRz5sU4TS5Hw/gnX0UpXNjfMbHmLEYojM= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0728.namprd00.prod.outlook.com (2603:10b6:610:ad::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3211.0; Fri, 10 Jul 2020 22:43:21 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::5821:2d92:80e8:85d5]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::5821:2d92:80e8:85d5%9]) with mapi id 15.20.3215.000; Fri, 10 Jul 2020 22:43:21 +0000 From: Mike Jones To: Francesca Palombini , "cbor@ietf.org" Thread-Topic: Review of draft-ietf-cbor-date-tag-03 Thread-Index: AQHWVforjATfXTEzb0Ka+jqc+aOJ76kBatLw Date: Fri, 10 Jul 2020 22:43:21 +0000 Message-ID: References: <8919FFEE-2A57-4C0D-975C-5B65B3CC3AE8@ericsson.com> In-Reply-To: <8919FFEE-2A57-4C0D-975C-5B65B3CC3AE8@ericsson.com> 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=379f9d73-d7a1-4f08-ad32-6c92c304dae6; 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-07-10T22:42:30Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 60a8dabc-edc4-4be4-6d36-08d82522a5f3 x-ms-traffictypediagnostic: CH2PR00MB0728: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: M4Vb27mgvUcGKFCjt5r2rJPKQcJ02ZCm6RpSQ17qLCWcfW2JoM60SEQIz0JzoOMkVns4JblVRjAtqwBlD7fgBfydt64sISG04gwe2/anHULXflmK4V+tCLyggGUhrC1ZBkAyPCOTzT2HJiWpDgIi/r4pgtqBrNKvVsBqGSjIIvcBlUGO2e0fGGR436RgPPMpJs5V0vCwVBt9wwmqKKC/6twxHoeZQbTxlsc9ooy9ZBihWGZM0B3vYzlQth8bKQxldVOr/wPh7+dvBNUX94R1XsX30eTbTDxiDzKPQiX2e7PAUPS5MQLqBTSPkfFbOB1Ri60/bEz8FyaDFKRFlN9/dA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0679.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(136003)(39860400002)(396003)(366004)(53546011)(6506007)(8936002)(8990500004)(2906002)(66946007)(26005)(5660300002)(76116006)(8676002)(66476007)(64756008)(66446008)(52536014)(86362001)(66556008)(71200400001)(82950400001)(82960400001)(4744005)(186003)(7696005)(110136005)(316002)(33656002)(10290500003)(9686003)(478600001)(55016002)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: CBLX4CWDa1UY2L3e5lf4t9D3IgrACAQN35EdPylDK15z7AJ7DFZh3XmEaCryipmhj2Np4yUghv4GHvfCG60J1qj0z4LpgY+aDc/isLrPBWy8GvGSphWzIT0QqnrEe2uNQIbDVadtBTBQcXRr8OJY42I+aqDtmsXNGtY8Dy+ztEE0BD3axLdVbfXPe85lSE7wRnMc7+K9DjILRMqlVNWTqsED+7sNNMHiIGrly/sePZk5UuVpDExO63Y/A0mmIsNI5NXkhgffTz6GW9JLZoxV3Lf5OrJC/dA6s6/zQbeIKDMccrWcJR4LBYkDuck9V7TCTT4tmTEJ8AFkm0UEOtG6g5f4JKdY2dz6UAxcosFeuQMCCTkmVgGg7fGTOVwpS8xl184lOak71P33bifRvOVQWIFqd0c98SWrRNTJR/YHHcw7SltStNMO2Jvd0lsAAYtsh8sNFPKnhORYhr1wvt/kLtOSSqomv0g1rjjahN6Xfm8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0679.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 60a8dabc-edc4-4be4-6d36-08d82522a5f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2020 22:43:21.4084 (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: 4ILRnw+tgahy8HrFIYowqKQh6S1WY178NvuCtiPN6g2Kcvde5ydKeWHXNhyLBPv7HKwgpLhIQ0XjlbZ8XDAccQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0728 Archived-At: Subject: Re: [Cbor] Review of draft-ietf-cbor-date-tag-03 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, 10 Jul 2020 22:43:29 -0000 VGhhbmtzLCBGcmFuY2VzY2EuICBJcyB0aGlzIHRoZSBmdWxsIHNoZXBoZXJkIHdyaXRlLXVwIG9y IGlzIHRoZXJlIG1vcmUgdG8gY29tZT8NCg0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJp bmk9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+IA0KU2VudDogVGh1cnNkYXksIEp1bHkg OSwgMjAyMCA3OjA3IEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPjsgY2JvckBpZXRmLm9yZw0KU3ViamVjdDogUmV2aWV3IG9mIGRyYWZ0LWlldGYtY2Jvci1k YXRlLXRhZy0wMw0KDQpIaSBNaWtlLA0KDQpXaGlsZSByZXZpZXdpbmcgZm9yIHRoZSBzaGVwaGVy ZCB3cml0ZXVwIEkgZm91bmQgdGhlIGZvbGxvd2luZyBtaW5vciBpc3N1ZXM6DQoNClNlY3Rpb24g MToNCkkgd291bGQgc3VnZ2VzdCByZW1vdmluZyB0aGUgY29tbWEgZnJvbSB0aGUgbnVtYmVyOiA0 MCw1ODcuIFVzaW5nIHRoZSBjb21tYSBhcyBzZXBhcmF0b3IgaXMgbm90IHRoZSBiZXN0LCBhcyBp biBzb21lIGNvdW50cmllcyBpdCBpcyB1c2VkIGFzIGRlY2ltYWwgc2lnbiAoYWxzbyBub3QgcHJl ZmVycmVkIGJ1dCBhbGxvd2VkIGluIElTTyA4NjAxKS4NCg0KRnJvbSBJLUQgbml0czoNCiAgPT0g VGhlIGRvY3VtZW50IGRvZXNuJ3QgdXNlIGFueSBSRkMgMjExOSBrZXl3b3JkcywgeWV0IHNlZW1z IHRvIGhhdmUgUkZDDQogICAgIDIxMTkgYm9pbGVycGxhdGUgdGV4dC4NCklzIGl0IG5lY2Vzc2Fy eSB0byBoYXZlIHRoZSAyMTE5IC0gODE3NCBib2lsZXJwbGF0ZSB0ZXh0IGV2ZW4gaWYgbm8gbm9y bWF0aXZlIGtleXdvcmRzIGFyZSB1c2VkPyANCg0KW1BPU0lYLjFdIHNlZW1zIG1vcmUgbGlrZSBh IG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gbWUsIGRvbid0IHlvdSB0aGluaz8NCg0KVGhhbmtzLA0K RnJhbmNlc2NhDQoNCg== From nobody Fri Jul 10 15:51:36 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 9E0E03A0BF4 for ; Fri, 10 Jul 2020 15:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-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 Feu9doh58nLp for ; Fri, 10 Jul 2020 15:51:33 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50047.outbound.protection.outlook.com [40.107.5.47]) (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 EE6A23A0BE7 for ; Fri, 10 Jul 2020 15:51:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cqLVtPrssXLnkjPSOFIO7Fh76HpUozq7QahiCHYjj0E5c6oLjXW549eBM8z9HDQ2Nq5sStvrsb4Av+Z6s0HMAXAhUGRY3MarKEbA52qBJmX+YN11aO1/bmjACXiu3PWn272SCZDHYacdOhX8G+FSoyn+buk3obEO46ft5FojbwTQZdttaX5Gw/CjV9F9zP7msOwR0NVkX7RDh5yGMXY8RptBTyrT/omI+XyOILTGCJUVaJXWtUIJFwsnWty0cGl4tFfJ5kNHhkFpu6dTCUzzuld5R/GIkpq+Hv25134cZtEq7tbslL9uFlFZB5FhK0tUonEIXGUOhmSX0VYlic3r3A== 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=f9ANpnuoVwYc74TBadtbY/SzIjcCFbF1Cg/vFlpUWdI=; b=HiU0dMlyNg6k3gylfUHdBSxuLpjjrrB3iB+QsWUNY7X4fBs+uHXSH7oFfC2QJVB9vfrGYBUp2UCUVU2QcisFwvTf3iArLJQcVxyc44l+BzuxuzgM57aYF71/OzvpRHy40oFevG6qjN4WmXe/GX3396czVOeGIJlMhuj6g7RVhiEMOaxPVm3SZDJcQINuZHUJWfjf4pA9NB44pZOoq8w1Ee1DPlWI/2FOT3rDvnVq8QNWVPVeOpKqMXtF6MkA462eAQF4B7TORJ6qKkRiTzJ777otV4T7LMsE4EMd/rMiiweWFBk2TXM6xOtj0IjsVwLj4UDp/zrTix8K3VtuXHSk3Q== 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=f9ANpnuoVwYc74TBadtbY/SzIjcCFbF1Cg/vFlpUWdI=; b=sajwKQOIIFBQrhyTZIuzoMh+7e9sjoECF5cHuCIPwxDs3bqPMa3YEUGmd+7tTBcGf42zEDqfByEvBDgSZY3/CZzl6rNVR3RV9BzBzW/eZvXeeK47y9bBTUXT47F4atvt/A1P2TXqzS36OTa2WHk4U6E2xbDO5nO+QmC0+so0dkI= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR07MB4154.eurprd07.prod.outlook.com (2603:10a6:7:9e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.9; Fri, 10 Jul 2020 22:51:29 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3174.022; Fri, 10 Jul 2020 22:51:29 +0000 From: Francesca Palombini To: Mike Jones , "cbor@ietf.org" Thread-Topic: Review of draft-ietf-cbor-date-tag-03 Thread-Index: AQHWVforjATfXTEzb0Ka+jqc+aOJ76kBatLwgAAkCoA= Date: Fri, 10 Jul 2020 22:51:28 +0000 Message-ID: <945F7FB2-D256-46E0-A380-91F747E196CE@ericsson.com> References: <8919FFEE-2A57-4C0D-975C-5B65B3CC3AE8@ericsson.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=379f9d73-d7a1-4f08-ad32-6c92c304dae6; 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-07-10T22:42:30Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.153.190.14] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4f3dc0e6-d4bb-43fb-5e46-08d82523c8a6 x-ms-traffictypediagnostic: HE1PR07MB4154: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WFIY+LZ4QUyQzuI4w0cQF8GCBkp4kdUmuty56KriSP4AAMiJFq1IOsdc7hPDjE2QunTPmQUcLGUqMik2x6ZRWfnS31vFdDOMbB+mzjTN7lumx4y+dP/f1U8RqCk3N7TidVglKRPejEPNdAEXhZWO5jwSesOlj4uMe8pJwNPxVSZ1G7xrxc/UG6XzaxLB1JkX3Hw9+kHokPab3qFlcI5fFWkCiT+1vraCM2H2iG72L/9RUf4bvmKtbgNX7Bxq/nHWuBDQY/+3yW0yAuf/cvqWdgsMzEVj8TENTFHIZ9VBqVHBxTXYOcOsNh/tMjNDOgpvnQZY7GMrr9X3M9QQqUI2PQGuwebsvpiHZv+0GO/IR3rVbZ3U+Vj6GibGlQOOxIpXJXRjR6s3o5NMCvhHdQOL5w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(396003)(376002)(39860400002)(346002)(478600001)(6506007)(110136005)(36756003)(26005)(86362001)(316002)(83380400001)(6512007)(71200400001)(2906002)(5660300002)(8936002)(33656002)(66556008)(186003)(66446008)(6486002)(66476007)(76116006)(2616005)(64756008)(44832011)(66946007)(91956017)(53546011)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: J3lZE6oWxsDWWe9dsj4HFNlHFcTNdf8jQnkHEbxRmKLG54nUe/X110r5V39t0xtobvpTtjuKV3rTaQmj1gQeBgQIqCLDLOvSIwh5QWYerXpyB5ZFRUT9sHzKxhZADlcHrY5dlXxmBaMz/hV580DiK7pO7EuODb+PvmxWTKR9QDSPC9I/3QwnjyOCKH2JrvH28+eGvRCbooi5N8uzqmHe7cC5G+x4clOgAEpQC7WLTLwI2iW9szqNfCDB9FiHS8icnrdR6AgZL78H7JK+XBoI/QTZfyE5kM7aNrvbAMqze6jftFW+Yfb4IwaaQcTlcx+SdDzuZ3niLplcAKraAGuyXTwXnp0Vasf/Zlfn03dgL0a+go9EmNLwqtftNP0kLrUU9f6dkChymlGpc9ioQFIlpY4heENkEMoNPCOwnO+DmNWT+EDkLoM1flNce5ihXbrEolzxE/a0IIDDsSQJb27Y0nYfu3BQnvs8ZK3m6Z1deCnMDP0n5ykSIQtepYTwZwfm x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <619C898A4462D24E96F55CE1AE246235@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4f3dc0e6-d4bb-43fb-5e46-08d82523c8a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2020 22:51:28.8777 (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: h1xM3ivIyY77aa8CHn9+DWvZpwgh8/NaRn/Is+tIQnN/lRrgYbCZWfaZa035oKgFEiJZb5Tvm+T1EII3jgsq4Q38tm1Pr0BygHg6Aio0iiJFuPWwUnCZOVSCqVfWkU+/ X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4154 Archived-At: Subject: Re: [Cbor] Review of draft-ietf-cbor-date-tag-03 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, 10 Jul 2020 22:51:35 -0000 SGkgTWlrZSwNCg0KTm8sIEkgd2lsbCBwb3N0IHRoZSBmdWxsIHdyaXRlIHVwIGZvbGxvd2luZyB0 aGUgdXN1YWwgdGVtcGxhdGUgKGh0dHBzOi8vd3d3LmlldGYub3JnL2NoYWlycy9kb2N1bWVudC13 cml0ZXVwcy9kb2N1bWVudC13cml0ZXVwLXdvcmtpbmctZ3JvdXAtZG9jdW1lbnRzLyApIGZvciB0 aGUgbmV4dCBzdWJtaXNzaW9uIG9mIHRoZSBkcmFmdCwgYnV0IHRoZXNlIGFyZSBhbGwgdGhlIGNv bW1lbnRzIEkgaGF2ZSwgbm8gbW9yZSB0byBjb21lLg0KDQpGcmFuY2VzY2ENCg0K77u/T24gMTEv MDcvMjAyMCwgMDA6NDMsICJNaWtlIEpvbmVzIiA8TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5j b21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgVGhhbmtzLCBGcmFuY2VzY2EuICBJcyB0 aGlzIHRoZSBmdWxsIHNoZXBoZXJkIHdyaXRlLXVwIG9yIGlzIHRoZXJlIG1vcmUgdG8gY29tZT8N Cg0KICAgIAkJCQktLSBNaWtlDQoNCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAg IEZyb206IEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJpbmk9NDBlcmljc3Nv bi5jb21AZG1hcmMuaWV0Zi5vcmc+IA0KICAgIFNlbnQ6IFRodXJzZGF5LCBKdWx5IDksIDIwMjAg NzowNyBBTQ0KICAgIFRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+ OyBjYm9yQGlldGYub3JnDQogICAgU3ViamVjdDogUmV2aWV3IG9mIGRyYWZ0LWlldGYtY2Jvci1k YXRlLXRhZy0wMw0KDQogICAgSGkgTWlrZSwNCg0KICAgIFdoaWxlIHJldmlld2luZyBmb3IgdGhl IHNoZXBoZXJkIHdyaXRldXAgSSBmb3VuZCB0aGUgZm9sbG93aW5nIG1pbm9yIGlzc3VlczoNCg0K ICAgIFNlY3Rpb24gMToNCiAgICBJIHdvdWxkIHN1Z2dlc3QgcmVtb3ZpbmcgdGhlIGNvbW1hIGZy b20gdGhlIG51bWJlcjogNDAsNTg3LiBVc2luZyB0aGUgY29tbWEgYXMgc2VwYXJhdG9yIGlzIG5v dCB0aGUgYmVzdCwgYXMgaW4gc29tZSBjb3VudHJpZXMgaXQgaXMgdXNlZCBhcyBkZWNpbWFsIHNp Z24gKGFsc28gbm90IHByZWZlcnJlZCBidXQgYWxsb3dlZCBpbiBJU08gODYwMSkuDQoNCiAgICBG cm9tIEktRCBuaXRzOg0KICAgICAgPT0gVGhlIGRvY3VtZW50IGRvZXNuJ3QgdXNlIGFueSBSRkMg MjExOSBrZXl3b3JkcywgeWV0IHNlZW1zIHRvIGhhdmUgUkZDDQogICAgICAgICAyMTE5IGJvaWxl cnBsYXRlIHRleHQuDQogICAgSXMgaXQgbmVjZXNzYXJ5IHRvIGhhdmUgdGhlIDIxMTkgLSA4MTc0 IGJvaWxlcnBsYXRlIHRleHQgZXZlbiBpZiBubyBub3JtYXRpdmUga2V5d29yZHMgYXJlIHVzZWQ/ IA0KDQogICAgW1BPU0lYLjFdIHNlZW1zIG1vcmUgbGlrZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2Ug dG8gbWUsIGRvbid0IHlvdSB0aGluaz8NCg0KICAgIFRoYW5rcywNCiAgICBGcmFuY2VzY2ENCg0K DQo= From nobody Mon Jul 13 11:36: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 AA0463A0775; Mon, 13 Jul 2020 11:36:41 -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 Z-e47AkRNEXi; Mon, 13 Jul 2020 11:36:40 -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 4B5E33A16FC; Mon, 13 Jul 2020 11:36:17 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 13 Jul 2020 11:36:11 -0700 From: Jim Schaad To: CC: Date: Mon, 13 Jul 2020 11:36:08 -0700 Message-ID: <000e01d65944$7b896b60$729c4220$@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: AdZZRFx8lqU+zriIR/aroLtwmbKmAw== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Agenda items for IETF 108 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, 13 Jul 2020 18:36:42 -0000 We are collecting agenda items for IETF 108. We have a 50 minute slot at the meeting. If you want to be on the agenda please let the chairs know. Please include the following data in your agenda request: 1. The document(s) that the presentation applies to 2. Who is giving the presentation 3. How long do you expect the presentation to take. 4. Are there any ordering issues that need to be noted. Jim & Francesca From nobody Mon Jul 13 12:48: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 68C183A0789 for ; Mon, 13 Jul 2020 12:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 jq7-CGDwPR1Z for ; Mon, 13 Jul 2020 12:48:20 -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 8C3243A0743 for ; Mon, 13 Jul 2020 12:48:20 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B5Dhy4Lw9zyhP; Mon, 13 Jul 2020 21:48:18 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann Date: Mon, 13 Jul 2020 21:48:17 +0200 X-Mao-Original-Outgoing-Id: 616362497.868306-5f984b0517570e493e0712a7d25c1ef5 Content-Transfer-Encoding: quoted-printable Message-Id: <341A1839-3F18-4DEC-9D31-37B8B52EE7F5@tzi.org> References: <159466934186.16881.16982303538559791394@ietfa.amsl.com> To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Cbor] Packing CBOR (draft-bormann-cbor-packed-00) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 19:48:23 -0000 This draft may seem a bit unusual, in that it allocates 268439585 tags, = including one of the 12 remaining precious single-byte ones. But if you read it, that will seem perfectly normal. Please see = https://www.ietf.org/id/draft-bormann-cbor-packed-00.html#name-acknowledge= ments for how this came to be. I=E2=80=99m going to ask for WG adoption at IETF 108... Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-bormann-cbor-packed-00.txt > Date: 2020-07-13 at 21:42:21 CEST > To: "Carsten Bormann" >=20 >=20 > A new version of I-D, draft-bormann-cbor-packed-00.txt > has been successfully submitted by Carsten Bormann and posted to the > IETF repository. >=20 > Name: draft-bormann-cbor-packed > Revision: 00 > Title: Packed CBOR > Document date: 2020-07-13 > Group: Individual Submission > Pages: 9 > URL: = https://www.ietf.org/internet-drafts/draft-bormann-cbor-packed-00.txt > Status: = https://datatracker.ietf.org/doc/draft-bormann-cbor-packed/ > Htmlized: = https://tools.ietf.org/html/draft-bormann-cbor-packed-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-bormann-cbor-packed >=20 >=20 > Abstract: > The Concise Binary Object Representation (CBOR, RFC 7049) is a data > format whose design goals include the possibility of extremely small > code size, fairly small message size, and extensibility without the > need for version negotiation. >=20 > CBOR does not provide any forms of data compression. CBOR data > items, in particular when generated from legacy data models often > allow considerable gains in compactness when applying data > compression. While traditional data compression techniques such as > DEFLATE (RFC 1951) work well for CBOR, their disadvantage is that = the > receiver needs to unpack the compressed form to make use of data. >=20 > This specification describes Packed CBOR, a simple transformation of > a CBOR data item into another CBOR data item that is almost as easy > to consume as the original CBOR data item. A separate decompression > step is therefore often not required at the receiver. >=20 >=20 >=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 > The IETF Secretariat >=20 >=20 From nobody Mon Jul 13 22:14: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 D1B3D3A102C; Mon, 13 Jul 2020 22:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 PmrbS4Rsq5Jb; Mon, 13 Jul 2020 22:14:22 -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 ABBFB3A105C; Mon, 13 Jul 2020 22:14:21 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B5TFy2Rqkz17pB; Tue, 14 Jul 2020 07:14:14 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann Date: Tue, 14 Jul 2020 07:14:13 +0200 Cc: json@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 616396453.48809-57f0931c8f541d04c3fe093b442b147f Content-Transfer-Encoding: quoted-printable Reply-To: dispatch@ietf.org Message-Id: <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> References: <159467093010.19477.7181341398452455173@ietfa.amsl.com> To: dispatch@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Cbor] draft-goessner-dispatch-jsonpath-00.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: Tue, 14 Jul 2020 05:14:25 -0000 (Reply-To set to dispatch@ietf.org) I would like to initiate discussion for = draft-goessner-dispatch-jsonpath: https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html It says: > This document picks up the popular JSONPath specification dated > 2007-02-21 and provides a more normative definition for it. > It is intended as a submission to the IETF DISPATCH WG, in order to > find the right way to complete standardization of this specification. > In its current state, it is a strawman document showing what needs to > be covered. (For some reason the abstract landed in the Contributing note; typical = Internet-Draft deadline day botch.) This is a widely implemented specification that has been around for more = than a decade; now may be a good opportunity to finally go ahead and = turn it into a proper Internet standards document. The immediate cause = for writing this up now is that some IoT discovery work (some of which = happens in W3C) can make good use of JSONPath. Clearly, we already have = JSON Pointer (RFC 6901) for a more limited set of applications; the = specification would do good in defining how these two fit together. There is no active WG that immediately fits this work. Eventually CDDL may pick JSONPath up in the form of a predicate = operator; this might make the CBOR WG the right group (which probably = would then go ahead and write up another specification that makes = JSONPath useful for querying CBOR instances that go beyond the JSON = generic data model). Reopening the JSON WG may be another approach, as may be creating a = short-lived targeted WG. Please discuss! Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-goessner-dispatch-jsonpath-00.txt > Date: 2020-07-13 at 22:08:50 CEST > To: "Stefan G=C3=B6ssner" , "Stefan = Gossner" , "Carsten Bormann" = >=20 >=20 > A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt > has been successfully submitted by Carsten Bormann and posted to the > IETF repository. >=20 > Name: draft-goessner-dispatch-jsonpath > Revision: 00 > Title: JSONPath -- XPath for JSON > Document date: 2020-07-12 > Group: Individual Submission > Pages: 14 > URL: = https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.t= xt > Status: = https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/ > Htmlized: = https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath >=20 >=20 > Abstract: > insert abstract here >=20 >=20 >=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 > The IETF Secretariat >=20 >=20 From nobody Mon Jul 13 22:32: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 B231B3A1094 for ; Mon, 13 Jul 2020 22:32:04 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.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 GW4vYgGYYtwj for ; Mon, 13 Jul 2020 22:32:03 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 9938C3A1092 for ; Mon, 13 Jul 2020 22:32:02 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id t74so10635264lff.2 for ; Mon, 13 Jul 2020 22:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pIoIX5AteUHnh6Z2KNOJWVr0y+sNuILejdpxjFr/D5Y=; b=gm8QoWjMi/szV2m9VMrHJmDd+06BeW3auW5Tsbs9dzDUz8KADItH6n6NgaeHEsU706 /KqtbvwOlVXhQ0232ePSeDhWYtunm8goy8akgJoNCR/axT/dW7Uhn28x0wXlkjbRo6Bb +d966OkieUe6uXozHGn9rAh536aC9UI4FM17dNDl43+UV0yMsbkmcuOZwuFNmSIh1bFv LwOttDSx6JYwtugoh5PC66P10WNuKUss7KOZLlVExRQstitV0qBK3yiikdMGKExvntqO ObCtCXJFfgPXb5Ko+V3C2ReWZ0yEFEed2UZRlWn6ydQy1lH3Wuhfnmiu5R05pj0AjJsH zAdw== 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=pIoIX5AteUHnh6Z2KNOJWVr0y+sNuILejdpxjFr/D5Y=; b=XoJ8kt2U/f7LXzwe28edv1+Bj/Di4NLabHgAgVQmPeYbnyhqO5M+e4jcpbp/wPeGrz PGtsCOcOOPuVIWGbTc7LfV2avTgofsbxFr/oE5SowSI7sGSHiBoOKUrmvkOAW2NqABLI rwHy80FuUHvakhCer/QtpROoRg68apUXDN/03QMasRMZjQ9bGrQGywyH02Q1VwV5Lad5 rsG2gZLA7ofz6TCIIpxSJXtJxR3rlTVaPbLvv3Dvt886qX9xqkR8Yh/qcKR51T7iWwIo GW6m5xpp6xjH9NN13oy+MV/9smGzbDI8hcCxWqlJBySptAmIDBX7xzQnKj/rNBSGnjPr KI/g== X-Gm-Message-State: AOAM530QkRowdvBWRw5biqN6YSjdfZoXddUD9eKJQYFrl3ix/BVJwCVI Mi/qqHvjG3KuRSiwRwG3oV99j2oYrzA3GhTuR2YpOg== X-Google-Smtp-Source: ABdhPJzMwFogvX2gUSLErP48dvnn5NQFHMQBQBuXxQ65nob8f7mchla12/LUbVc5gCGf4BVbsvMJI+e34JtIKug42H4= X-Received: by 2002:ac2:4422:: with SMTP id w2mr1281492lfl.152.1594704720671; Mon, 13 Jul 2020 22:32:00 -0700 (PDT) MIME-Version: 1.0 References: <159467093010.19477.7181341398452455173@ietfa.amsl.com> <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> In-Reply-To: <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> From: Tim Bray Date: Mon, 13 Jul 2020 22:31:49 -0700 Message-ID: To: dispatch@ietf.org Cc: cbor@ietf.org, JSON WG Content-Type: multipart/alternative; boundary="00000000000065c69005aa60201d" Archived-At: Subject: Re: [Cbor] [Json] draft-goessner-dispatch-jsonpath-00.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: Tue, 14 Jul 2020 05:32:05 -0000 --00000000000065c69005aa60201d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable During my time at AWS I worked very heavily with JSONPath and lamented a useful referenceable spec. I would be happy to invest cycles into this work. There currently isn't a JSON working group but I suppose it wouldn't be too hard to reconstitute it for this purpose. On Mon, Jul 13, 2020 at 10:14 PM Carsten Bormann wrote: > (Reply-To set to dispatch@ietf.org) > > I would like to initiate discussion for draft-goessner-dispatch-jsonpath: > > https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html > > It says: > > > This document picks up the popular JSONPath specification dated > > 2007-02-21 and provides a more normative definition for it. > > It is intended as a submission to the IETF DISPATCH WG, in order to > > find the right way to complete standardization of this specification. > > In its current state, it is a strawman document showing what needs to > > be covered. > > (For some reason the abstract landed in the Contributing note; typical > Internet-Draft deadline day botch.) > > This is a widely implemented specification that has been around for more > than a decade; now may be a good opportunity to finally go ahead and turn > it into a proper Internet standards document. The immediate cause for > writing this up now is that some IoT discovery work (some of which happen= s > in W3C) can make good use of JSONPath. Clearly, we already have JSON > Pointer (RFC 6901) for a more limited set of applications; the > specification would do good in defining how these two fit together. > > There is no active WG that immediately fits this work. > > Eventually CDDL may pick JSONPath up in the form of a predicate operator; > this might make the CBOR WG the right group (which probably would then go > ahead and write up another specification that makes JSONPath useful for > querying CBOR instances that go beyond the JSON generic data model). > > Reopening the JSON WG may be another approach, as may be creating a > short-lived targeted WG. > > Please discuss! > > Gr=C3=BC=C3=9Fe, Carsten > > > > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > draft-goessner-dispatch-jsonpath-00.txt > > Date: 2020-07-13 at 22:08:50 CEST > > To: "Stefan G=C3=B6ssner" , "Stefan Gos= sner" > , "Carsten Bormann" > > > > > > A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt > > has been successfully submitted by Carsten Bormann and posted to the > > IETF repository. > > > > Name: draft-goessner-dispatch-jsonpath > > Revision: 00 > > Title: JSONPath -- XPath for JSON > > Document date: 2020-07-12 > > Group: Individual Submission > > Pages: 14 > > URL: > https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.= txt > > Status: > https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/ > > Htmlized: > https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath > > > > > > Abstract: > > insert abstract here > > > > > > > > > > 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. > > > > The IETF Secretariat > > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --00000000000065c69005aa60201d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dur= ing my time at AWS I worked very heavily with JSONPath and lamented a usefu= l referenceable spec. I would be happy to invest cycles into this work. The= re currently isn't a JSON working group but I suppose it wouldn't b= e too hard to reconstitute it for this purpose. =C2=A0

On Mon, Jul 13,= 2020 at 10:14 PM Carsten Bormann <cabo@= tzi.org> wrote:
(Reply-To set to dispatch@ietf.org)

I would like to initiate discussion for draft-goessner-dispatch-jsonpath:
https://www.ietf.org/id/draft-goessn= er-dispatch-jsonpath-00.html

It says:

> This document picks up the popular JSONPath specification dated
> 2007-02-21 and provides a more normative definition for it.
> It is intended as a submission to the IETF DISPATCH WG, in order to > find the right way to complete standardization of this specification.<= br> > In its current state, it is a strawman document showing what needs to<= br> > be covered.

(For some reason the abstract landed in the Contributing note; typical Inte= rnet-Draft deadline day botch.)

This is a widely implemented specification that has been around for more th= an a decade; now may be a good opportunity to finally go ahead and turn it = into a proper Internet standards document.=C2=A0 The immediate cause for wr= iting this up now is that some IoT discovery work (some of which happens in= W3C) can make good use of JSONPath.=C2=A0 Clearly, we already have JSON Po= inter (RFC 6901) for a more limited set of applications; the specification = would do good in defining how these two fit together.

There is no active WG that immediately fits this work.

Eventually CDDL may pick JSONPath up in the form of a predicate operator; t= his might make the CBOR WG the right group (which probably would then go ah= ead and write up another specification that makes JSONPath useful for query= ing CBOR instances that go beyond the JSON generic data model).

Reopening the JSON WG may be another approach, as may be creating a short-l= ived targeted WG.

Please discuss!

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



> Begin forwarded message:
>
> From: in= ternet-drafts@ietf.org
> Subject: New Version Notification for draft-goessner-dispatch-jsonpath= -00.txt
> Date: 2020-07-13 at 22:08:50 CEST
> To: "Stefan G=C3=B6ssner" <stefan.goessner@fh-dortmund.de>= ;, "Stefan Gossner" <stefan.goessner@fh-dortmund.de>, "Ca= rsten Bormann" <c= abo@tzi.org>
>
>
> A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt
> has been successfully submitted by Carsten Bormann and posted to the > IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-goessner-dispatch-jsonpat= h
> Revision:=C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 JSONPath= -- XPath for JSON
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2020-07-12
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 14
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-goess= ner-dispatch-jsonpath-00.txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpa= th/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-j= sonpath
>
>
> Abstract:
>=C2=A0 =C2=A0insert abstract here
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>
>

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--00000000000065c69005aa60201d-- From nobody Tue Jul 14 00:37: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 B6FFD3A11D9; Tue, 14 Jul 2020 00:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 ojXb8ROAvs2H; Tue, 14 Jul 2020 00:37:02 -0700 (PDT) Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.98.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753A73A1313; Tue, 14 Jul 2020 00:36:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 52B0FB80272; Tue, 14 Jul 2020 09:36:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4PCMrv_Hk_Y; Tue, 14 Jul 2020 09:36:43 +0200 (CEST) Received: from [192.12.193.108] (pc-loffredo.nic.it [192.12.193.108]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id 1DDBEB80227; Tue, 14 Jul 2020 09:36:43 +0200 (CEST) To: Tim Bray , dispatch@ietf.org Cc: cbor@ietf.org, JSON WG References: <159467093010.19477.7181341398452455173@ietfa.amsl.com> <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> From: Mario Loffredo Message-ID: <467d225e-6dcf-4e5f-1101-27e4c074c6af@iit.cnr.it> Date: Tue, 14 Jul 2020 09:33:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------884645419007A2EC64A0E4E8" Content-Language: it Archived-At: Subject: Re: [Cbor] [Json] draft-goessner-dispatch-jsonpath-00.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: Tue, 14 Jul 2020 07:37:05 -0000 This is a multi-part message in MIME format. --------------884645419007A2EC64A0E4E8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Il 14/07/2020 07:31, Tim Bray ha scritto: > During my time at AWS I worked very heavily with JSONPath and lamented > a useful referenceable spec. I would be happy to invest cycles into > this work. There currently isn't a JSON working group but I suppose it > wouldn't be too hard to reconstitute it for this purpose. +1 Mario > > On Mon, Jul 13, 2020 at 10:14 PM Carsten Bormann > wrote: > > (Reply-To set to dispatch@ietf.org ) > > I would like to initiate discussion for > draft-goessner-dispatch-jsonpath: > > https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html > > It says: > > > This document picks up the popular JSONPath specification dated > > 2007-02-21 and provides a more normative definition for it. > > It is intended as a submission to the IETF DISPATCH WG, in order to > > find the right way to complete standardization of this > specification. > > In its current state, it is a strawman document showing what > needs to > > be covered. > > (For some reason the abstract landed in the Contributing note; > typical Internet-Draft deadline day botch.) > > This is a widely implemented specification that has been around > for more than a decade; now may be a good opportunity to finally > go ahead and turn it into a proper Internet standards document.  > The immediate cause for writing this up now is that some IoT > discovery work (some of which happens in W3C) can make good use of > JSONPath.  Clearly, we already have JSON Pointer (RFC 6901) for a > more limited set of applications; the specification would do good > in defining how these two fit together. > > There is no active WG that immediately fits this work. > > Eventually CDDL may pick JSONPath up in the form of a predicate > operator; this might make the CBOR WG the right group (which > probably would then go ahead and write up another specification > that makes JSONPath useful for querying CBOR instances that go > beyond the JSON generic data model). > > Reopening the JSON WG may be another approach, as may be creating > a short-lived targeted WG. > > Please discuss! > > Grüße, Carsten > > > > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > draft-goessner-dispatch-jsonpath-00.txt > > Date: 2020-07-13 at 22:08:50 CEST > > To: "Stefan Gössner" >, "Stefan Gossner" > >, "Carsten Bormann" > > > > > > > > A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt > > has been successfully submitted by Carsten Bormann and posted to the > > IETF repository. > > > > Name:         draft-goessner-dispatch-jsonpath > > Revision:     00 > > Title:                JSONPath -- XPath for JSON > > Document date:        2020-07-12 > > Group:                Individual Submission > > Pages:                14 > > URL: > https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/ > > Htmlized: > https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath > > > > > > Abstract: > >   insert abstract here > > > > > > > > > > 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 . > > > > The IETF Secretariat > > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Dr. Mario Loffredo Systems and Technological Development Unit Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Mobile: +39.3462122240 Web: http://www.iit.cnr.it/mario.loffredo --------------884645419007A2EC64A0E4E8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Il 14/07/2020 07:31, Tim Bray ha scritto:
During my time at AWS I worked very heavily with JSONPath and lamented a useful referenceable spec. I would be happy to invest cycles into this work. There currently isn't a JSON working group but I suppose it wouldn't be too hard to reconstitute it for this purpose. 

+1

Mario


On Mon, Jul 13, 2020 at 10:14 PM Carsten Bormann <cabo@tzi.org> wrote:
(Reply-To set to dispatch@ietf.org)

I would like to initiate discussion for draft-goessner-dispatch-jsonpath:

https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html

It says:

> This document picks up the popular JSONPath specification dated
> 2007-02-21 and provides a more normative definition for it.
> It is intended as a submission to the IETF DISPATCH WG, in order to
> find the right way to complete standardization of this specification.
> In its current state, it is a strawman document showing what needs to
> be covered.

(For some reason the abstract landed in the Contributing note; typical Internet-Draft deadline day botch.)

This is a widely implemented specification that has been around for more than a decade; now may be a good opportunity to finally go ahead and turn it into a proper Internet standards document.  The immediate cause for writing this up now is that some IoT discovery work (some of which happens in W3C) can make good use of JSONPath.  Clearly, we already have JSON Pointer (RFC 6901) for a more limited set of applications; the specification would do good in defining how these two fit together.

There is no active WG that immediately fits this work.

Eventually CDDL may pick JSONPath up in the form of a predicate operator; this might make the CBOR WG the right group (which probably would then go ahead and write up another specification that makes JSONPath useful for querying CBOR instances that go beyond the JSON generic data model).

Reopening the JSON WG may be another approach, as may be creating a short-lived targeted WG.

Please discuss!

Grüße, Carsten



> Begin forwarded message:
>
> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-goessner-dispatch-jsonpath-00.txt
> Date: 2020-07-13 at 22:08:50 CEST
> To: "Stefan Gössner" <stefan.goessner@fh-dortmund.de>, "Stefan Gossner" <stefan.goessner@fh-dortmund.de>, "Carsten Bormann" <cabo@tzi.org>
>
>
> A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt
> has been successfully submitted by Carsten Bormann and posted to the
> IETF repository.
>
> Name:         draft-goessner-dispatch-jsonpath
> Revision:     00
> Title:                JSONPath -- XPath for JSON
> Document date:        2020-07-12
> Group:                Individual Submission
> Pages:                14
> URL:            https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/
> Htmlized:       https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath
>
>
> Abstract:
>   insert abstract here
>
>
>
>
> 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.
>
> The IETF Secretariat
>
>

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

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

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo
--------------884645419007A2EC64A0E4E8-- From nobody Tue Jul 14 00:37:48 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68163A11DC for ; Tue, 14 Jul 2020 00:37:46 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTw1YOhZOmYi for ; Tue, 14 Jul 2020 00:37:44 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 4DE843A11D9 for ; Tue, 14 Jul 2020 00:37:44 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id k71so1182036pje.0 for ; Tue, 14 Jul 2020 00:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=uTtcfCjUjE/soFS3A0Lc/34hwQl1FmksICeHU7nEnhQ=; b=mrKpblEGzPPU0ZM8M8vf18t9bcipi6EnbaBKM7NW51isHBl1Tf4ukgOV7W2Cb7cJwD FsvGA1BgJzFglEfSKgszE0KZn4Q5sxoNHfP58mbf/XwYNOrBtHA1Qe97ObXbpTDWTOnp OKoRmDOthtZbYGpmjzsHsmRd454prcvrYHtKsndihq9TEufn6jvYjveZW5R0/Q4X504a pKTSIgiVZCLurMlwiKMayOhTS9lRrzR8Tsgv9dReTa+/1osQMKys4UEgxgu2NJsAvfFc OZ3G74Gp5hgi2OHU75A7mlydi6J4x+mskF+Vdfgj3eEX4FfamS4LgFeSUlkZqsjoBoSj 8Qqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=uTtcfCjUjE/soFS3A0Lc/34hwQl1FmksICeHU7nEnhQ=; b=OG1G5IPZFEzMlMW02eVE22XOo9uMYZj1JoL77OqwDBp+WbDM/s4dxB+/gxMGjgH8zN OXUoLroKAxugzjQHzLP618UXE4ySHiVxGxhp3wgPoM5bFAfGnYz2F/Oo/cslsyGeGZDv d+2coa7YL7qhivO1HdfaaOe1Wno28wl7jqMAs9JKKkiH2IgT3i2dKrU9MSi2fLBqeoep s1POy77oSr4dNPgMke5wdcx1MhDyq0WuJLgPvC8slsY1fp2caYNhTmBcmrINDkzxWkZq lkEWhBk1cIihriP7eyHPfuWozooqfPvOCxQdI8VIShVxiQAyCyhTeSsZwU0g4Kg5duQM UaRg== X-Gm-Message-State: AOAM5324ANAya9oyQwA6/POTy7flPbIkk87cmMB/dKes/zuJfPsBA75T RkELebnKya0hPi8/fPsAO0K0Ayin X-Google-Smtp-Source: ABdhPJy/ps4dB/lFkNAlVN4FN5Tw5QUt9WR3PhFioB73XJbNDed77ftuN6dZfIUpA0p43bjy9wwNFQ== X-Received: by 2002:a17:902:b706:: with SMTP id d6mr2868012pls.244.1594712263699; Tue, 14 Jul 2020 00:37:43 -0700 (PDT) Received: from [192.168.42.5] (135-180-96-53.fiber.dynamic.sonic.net. [135.180.96.53]) by smtp.gmail.com with ESMTPSA id s22sm14661143pgv.43.2020.07.14.00.37.42 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Tue, 14 Jul 2020 00:37:43 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3D58D818-B749-49C1-9589-A39FEAAD9272" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Toomim In-Reply-To: Date: Tue, 14 Jul 2020 00:37:42 -0700 Cc: cbor@ietf.org Message-Id: <2D71A54B-73E1-492D-ABCF-EC04A2F52873@gmail.com> References: <159467093010.19477.7181341398452455173@ietfa.amsl.com> <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> To: Tim Bray X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Cbor] [dispatch] [Json] draft-goessner-dispatch-jsonpath-00.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: Tue, 14 Jul 2020 07:37:47 -0000 --Apple-Mail=_3D58D818-B749-49C1-9589-A39FEAAD9272 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I'm replying off-list =E2=80=94 just to say I'd also help with such an = effort. Thanks for spearheading. We could use this in braid =E2=80=94 specifically = for the JSON Range Patch = spec. > On Jul 13, 2020, at 10:31 PM, Tim Bray wrote: >=20 > During my time at AWS I worked very heavily with JSONPath and lamented = a useful referenceable spec. I would be happy to invest cycles into this = work. There currently isn't a JSON working group but I suppose it = wouldn't be too hard to reconstitute it for this purpose. =20 >=20 > On Mon, Jul 13, 2020 at 10:14 PM Carsten Bormann > wrote: > (Reply-To set to dispatch@ietf.org ) >=20 > I would like to initiate discussion for = draft-goessner-dispatch-jsonpath: >=20 > https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html = >=20 > It says: >=20 > > This document picks up the popular JSONPath specification dated > > 2007-02-21 and provides a more normative definition for it. > > It is intended as a submission to the IETF DISPATCH WG, in order to > > find the right way to complete standardization of this = specification. > > In its current state, it is a strawman document showing what needs = to > > be covered. >=20 > (For some reason the abstract landed in the Contributing note; typical = Internet-Draft deadline day botch.) >=20 > This is a widely implemented specification that has been around for = more than a decade; now may be a good opportunity to finally go ahead = and turn it into a proper Internet standards document. The immediate = cause for writing this up now is that some IoT discovery work (some of = which happens in W3C) can make good use of JSONPath. Clearly, we = already have JSON Pointer (RFC 6901) for a more limited set of = applications; the specification would do good in defining how these two = fit together. >=20 > There is no active WG that immediately fits this work. >=20 > Eventually CDDL may pick JSONPath up in the form of a predicate = operator; this might make the CBOR WG the right group (which probably = would then go ahead and write up another specification that makes = JSONPath useful for querying CBOR instances that go beyond the JSON = generic data model). >=20 > Reopening the JSON WG may be another approach, as may be creating a = short-lived targeted WG. >=20 > Please discuss! >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 > > Begin forwarded message: > >=20 > > From: internet-drafts@ietf.org > > Subject: New Version Notification for = draft-goessner-dispatch-jsonpath-00.txt > > Date: 2020-07-13 at 22:08:50 CEST > > To: "Stefan G=C3=B6ssner" >, "Stefan Gossner" = >, "Carsten Bormann" = > > >=20 > >=20 > > A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt > > has been successfully submitted by Carsten Bormann and posted to the > > IETF repository. > >=20 > > Name: draft-goessner-dispatch-jsonpath > > Revision: 00 > > Title: JSONPath -- XPath for JSON > > Document date: 2020-07-12 > > Group: Individual Submission > > Pages: 14 > > URL: = https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.t= xt = > > Status: = https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/ = > > Htmlized: = https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00 = > > Htmlized: = https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath = > >=20 > >=20 > > Abstract: > > insert abstract here > >=20 > >=20 > >=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 > > The IETF Secretariat > >=20 > >=20 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json = > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_3D58D818-B749-49C1-9589-A39FEAAD9272 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I'm replying off-list =E2=80=94 just to say = I'd also help with such an effort. Thanks for spearheading.

We could use this = in braid=E2=80=94 = specifically for the JSON Range = Patch spec.

On Jul 13, 2020, at 10:31 PM, Tim Bray <tbray@textuality.com> wrote:

During my time at AWS I worked very heavily = with JSONPath and lamented a useful referenceable spec. I would be happy = to invest cycles into this work. There currently isn't a JSON working = group but I suppose it wouldn't be too hard to reconstitute it for this = purpose.  

On Mon, Jul 13, 2020 at 10:14 PM Carsten Bormann = <cabo@tzi.org> = wrote:
(Reply-To set to dispatch@ietf.org)

I would = like to initiate discussion for draft-goessner-dispatch-jsonpath:

https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.htm= l

It says:

> This document picks up the popular JSONPath = specification dated
> 2007-02-21 and provides a more = normative definition for it.
> It is intended as a = submission to the IETF DISPATCH WG, in order to
> find = the right way to complete standardization of this specification.
> In its current state, it is a strawman document showing = what needs to
> be covered.

(For some reason the abstract landed in the Contributing = note; typical Internet-Draft deadline day botch.)

This is a widely implemented specification that has been = around for more than a decade; now may be a good opportunity to finally = go ahead and turn it into a proper Internet standards document.  = The immediate cause for writing this up now is that some IoT discovery = work (some of which happens in W3C) can make good use of JSONPath.  = Clearly, we already have JSON Pointer (RFC 6901) for a more limited set = of applications; the specification would do good in defining how these = two fit together.

There is no active WG = that immediately fits this work.

Eventually = CDDL may pick JSONPath up in the form of a predicate operator; this = might make the CBOR WG the right group (which probably would then go = ahead and write up another specification that makes JSONPath useful for = querying CBOR instances that go beyond the JSON generic data model).

Reopening the JSON WG may be another approach, = as may be creating a short-lived targeted WG.

Please discuss!

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



> = Begin forwarded message:
> 
> = From: internet-drafts@ietf.org
> Subject: New = Version Notification for draft-goessner-dispatch-jsonpath-00.txt
> Date: 2020-07-13 at 22:08:50 CEST
> To: = "Stefan G=C3=B6ssner" <stefan.goessner@fh-dortmund.de>, "Stefan Gossner" = <stefan.goessner@fh-dortmund.de>, "Carsten Bormann" = <cabo@tzi.org>
> 
> 
> A new = version of I-D, draft-goessner-dispatch-jsonpath-00.txt
>= has been successfully submitted by Carsten Bormann and posted to the
> IETF repository.
> 
> = Name:        =  draft-goessner-dispatch-jsonpath
> = Revision:     00
> Title:    =             JSONPath -- XPath for JSON
> Document date:        2020-07-12
> Group:              =   Individual Submission
> Pages:    =             14
> = URL:            https://www.ietf.org/internet-drafts/draft-goessner-dispatch-js= onpath-00.txt
> Status:        =  https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpa= th/
> Htmlized:       https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00=
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-j= sonpath
> 
> 
> = Abstract:
>   insert abstract here
> 
> 
> 
> 
> 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.
> 
> The = IETF Secretariat
> 
> 

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
_______________________________________________
dispatch mailing = list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_3D58D818-B749-49C1-9589-A39FEAAD9272-- From nobody Tue Jul 14 05:25: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 EA4703A0B75 for ; Tue, 14 Jul 2020 05:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 LJyawS7aXdAu for ; Tue, 14 Jul 2020 05:25:29 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 1FD373A0B70 for ; Tue, 14 Jul 2020 05:25:29 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id s21so14001005ilk.5 for ; Tue, 14 Jul 2020 05:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WgjgtHl/eLx4zF0CS7LWDxZwlRutT1zcU1sMJ25QQ2U=; b=1o+b3cwsFQPji2bHWdmDtkVToehwhMN7KxyKudWHUh1qswVFzYV8RkEXb3/6hx0wsg CNKfjRON+gFIglR5IaC9JRgfuxzKdPNDK1gPwoBvrW5AS0TynHLyrvdeyN+vBOczEnZp EUb6dy8d74ndBYsEwisVzRFduZ0Vm4dbEQAR2vcuaU/jEMUjjCMATIKwc6y5FIIeYuqX YFc7HKrma4KwQ0nvt+thps2T9sin5hXCOiO/1Onx66f2btmbxK+weInd89HBu7od252N lTufby4sm5P14KBpi9d+HtvSZpmHwi249sJ/WvaSw1Qb+Ezt4izIvz+xWCbyaMxloe7M 6t+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=WgjgtHl/eLx4zF0CS7LWDxZwlRutT1zcU1sMJ25QQ2U=; b=C+dzS6T7imeGkcnDxzYUjov1Ysk76dSFiM6h7kDXi/5O0fZBZa3vQY0P/yxlmutflf 1VodLidKZHaFFuUS2KFVDw4u6o/y8eCZIlcxw+5S64u/TB0e6PR/SjwoAcrGJ//aaWih vLWA0y3hiCMAHXYnsefJGXwsT1k+l14JQbDaDuqSGIvC62y9LbEkXk8Z4sqkKaG0ZCPT DD+R9JjtFASvxDbU/SdUZZ5ePsoi9fo9Zbxi4NPM3uXWJp45Ld7T4/TDnYM2cXX9cf3s 0ZRTZnm5Z4kZSLu7+/qjKdh7xq4TCAuUHsRxQdt2k5GA0zzvisilM6yDqw6dBLOl2Kvn Rjpg== X-Gm-Message-State: AOAM531y6AW4Ya/Y6K8rTT8vUytoF0W2hFYNo3NcuFVLQhYORTCDkThY 1xoRKLFxDfNGd00sqFDCHjFi5LlFcnI= X-Google-Smtp-Source: ABdhPJytzImwYzrtgVlfv2t55uA2xDv/tS68xjbYS5Oi8c7p5Yt5kcu5O0Rx2V2XtBdlnm70kP4wFA== X-Received: by 2002:a92:aad6:: with SMTP id p83mr4160833ill.65.1594729528286; Tue, 14 Jul 2020 05:25:28 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id f18sm9068754ion.47.2020.07.14.05.25.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Jul 2020 05:25:27 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9FCF87D4-63FA-423B-80C1-DF79640D5764" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 14 Jul 2020 08:25:24 -0400 In-Reply-To: <467d225e-6dcf-4e5f-1101-27e4c074c6af@iit.cnr.it> Cc: Tim Bray , dispatch@ietf.org, cbor@ietf.org, JSON WG To: Mario Loffredo References: <159467093010.19477.7181341398452455173@ietfa.amsl.com> <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> <467d225e-6dcf-4e5f-1101-27e4c074c6af@iit.cnr.it> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] [dispatch] [Json] draft-goessner-dispatch-jsonpath-00.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: Tue, 14 Jul 2020 12:25:33 -0000 --Apple-Mail=_9FCF87D4-63FA-423B-80C1-DF79640D5764 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 And I note the discussion of an HTTP API working group, to which this = work would fit in. I=E2=80=99m currently working on a spec for emergency services that uses = jsonpath, and the lack of a referenceable spec was a big concern. =20 Brian > On Jul 14, 2020, at 3:33 AM, Mario Loffredo = wrote: >=20 >=20 >=20 > Il 14/07/2020 07:31, Tim Bray ha scritto: >> During my time at AWS I worked very heavily with JSONPath and = lamented a useful referenceable spec. I would be happy to invest cycles = into this work. There currently isn't a JSON working group but I suppose = it wouldn't be too hard to reconstitute it for this purpose. =20 > +1 >=20 > Mario >=20 >>=20 >> On Mon, Jul 13, 2020 at 10:14 PM Carsten Bormann > wrote: >> (Reply-To set to dispatch@ietf.org ) >>=20 >> I would like to initiate discussion for = draft-goessner-dispatch-jsonpath: >>=20 >> https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html = >>=20 >> It says: >>=20 >> > This document picks up the popular JSONPath specification dated >> > 2007-02-21 and provides a more normative definition for it. >> > It is intended as a submission to the IETF DISPATCH WG, in order to >> > find the right way to complete standardization of this = specification. >> > In its current state, it is a strawman document showing what needs = to >> > be covered. >>=20 >> (For some reason the abstract landed in the Contributing note; = typical Internet-Draft deadline day botch.) >>=20 >> This is a widely implemented specification that has been around for = more than a decade; now may be a good opportunity to finally go ahead = and turn it into a proper Internet standards document. The immediate = cause for writing this up now is that some IoT discovery work (some of = which happens in W3C) can make good use of JSONPath. Clearly, we = already have JSON Pointer (RFC 6901) for a more limited set of = applications; the specification would do good in defining how these two = fit together. >>=20 >> There is no active WG that immediately fits this work. >>=20 >> Eventually CDDL may pick JSONPath up in the form of a predicate = operator; this might make the CBOR WG the right group (which probably = would then go ahead and write up another specification that makes = JSONPath useful for querying CBOR instances that go beyond the JSON = generic data model). >>=20 >> Reopening the JSON WG may be another approach, as may be creating a = short-lived targeted WG. >>=20 >> Please discuss! >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>=20 >> > Begin forwarded message: >> >=20 >> > From: internet-drafts@ietf.org >> > Subject: New Version Notification for = draft-goessner-dispatch-jsonpath-00.txt >> > Date: 2020-07-13 at 22:08:50 CEST >> > To: "Stefan G=C3=B6ssner" >, "Stefan Gossner" = >, "Carsten Bormann" = > >> >=20 >> >=20 >> > A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt >> > has been successfully submitted by Carsten Bormann and posted to = the >> > IETF repository. >> >=20 >> > Name: draft-goessner-dispatch-jsonpath >> > Revision: 00 >> > Title: JSONPath -- XPath for JSON >> > Document date: 2020-07-12 >> > Group: Individual Submission >> > Pages: 14 >> > URL: = https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.t= xt = >> > Status: = https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/ = >> > Htmlized: = https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00 = >> > Htmlized: = https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath = >> >=20 >> >=20 >> > Abstract: >> > insert abstract here >> >=20 >> >=20 >> >=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 >> > The IETF Secretariat >> >=20 >> >=20 >>=20 >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json = >>=20 >>=20 >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json = > --=20 > Dr. Mario Loffredo > Systems and Technological Development Unit > Institute of Informatics and Telematics (IIT) > National Research Council (CNR) > via G. Moruzzi 1, I-56124 PISA, Italy > Phone: +39.0503153497 > Mobile: +39.3462122240 > Web: http://www.iit.cnr.it/mario.loffredo = ____________________________________= ___________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_9FCF87D4-63FA-423B-80C1-DF79640D5764 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

And I = note the discussion of an HTTP API working group, to which this work = would fit in.

I=E2=80=99m currently working on a spec for emergency = services that uses jsonpath, and the lack of a referenceable spec was a = big concern.  

Brian

On Jul 14, 2020, at 3:33 AM, = Mario Loffredo <mario.loffredo@iit.cnr.it> wrote:

=20 =20


Il 14/07/2020 07:31, Tim Bray ha scritto:
During my time at AWS I worked very heavily with JSONPath and lamented a useful referenceable spec. I would be happy to invest cycles into this work. There currently isn't a JSON working group but I suppose it wouldn't be too hard to reconstitute it for this purpose. 

+1

Mario


On Mon, Jul 13, 2020 at = 10:14 PM Carsten Bormann <cabo@tzi.org> wrote:
(Reply-To set to dispatch@ietf.org)

I would like to initiate discussion for draft-goessner-dispatch-jsonpath:

https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.htm= l

It says:

> This document picks up the popular JSONPath specification dated
> 2007-02-21 and provides a more normative definition for it.
> It is intended as a submission to the IETF DISPATCH WG, in order to
> find the right way to complete standardization of this specification.
> In its current state, it is a strawman document showing what needs to
> be covered.

(For some reason the abstract landed in the Contributing note; typical Internet-Draft deadline day botch.)

This is a widely implemented specification that has been around for more than a decade; now may be a good opportunity to finally go ahead and turn it into a proper Internet standards document.  The immediate cause for writing this = up now is that some IoT discovery work (some of which happens in W3C) can make good use of JSONPath.  Clearly, we already = have JSON Pointer (RFC 6901) for a more limited set of applications; the specification would do good in defining how these two fit together.

There is no active WG that immediately fits this work.

Eventually CDDL may pick JSONPath up in the form of a predicate operator; this might make the CBOR WG the right group (which probably would then go ahead and write up another specification that makes JSONPath useful for querying CBOR instances that go beyond the JSON generic data model).

Reopening the JSON WG may be another approach, as may be creating a short-lived targeted WG.

Please discuss!

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



> Begin forwarded message:
>
> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-goessner-dispatch-jsonpath-00.txt
> Date: 2020-07-13 at 22:08:50 CEST
> To: "Stefan G=C3=B6ssner" <stefan.goessner@fh-dortmund.de>, "Stefan Gossner" <stefan.goessner@fh-dortmund.de>, "Carsten Bormann" <cabo@tzi.org>
>
>
> A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt
> has been successfully submitted by Carsten Bormann and posted to the
> IETF repository.
>
> Name:        =  draft-goessner-dispatch-jsonpath
> Revision:     00
> Title:              =   JSONPath -- XPath for JSON
> Document date:        2020-07-12
> Group:              =   Individual Submission
> Pages:              =   14
> URL:            https://www.ietf.org/internet-drafts/draft-goessner-dispatch-js= onpath-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpa= th/
> Htmlized:       https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00=
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-j= sonpath
>
>
> Abstract:
>   insert abstract here
>
>
>
>
> 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.
>
> The IETF Secretariat
>
>

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

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

--=20
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.=
loffredo
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_9FCF87D4-63FA-423B-80C1-DF79640D5764-- From nobody Tue Jul 14 12:29:27 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 817923A098B; Tue, 14 Jul 2020 12:29:21 -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: 7.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159475496142.22914.13996661169024671613@ietfa.amsl.com> Date: Tue, 14 Jul 2020 12:29:21 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-07-15 CHANGED X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 19:29:22 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2020-07-15 from 17:00 to 18:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: CBOR WG Meeting - Interim 20-13 Wednesday, July 15, 2020, 17:00 - 18:00 CEST Chairs: Francesca Palombini, Jim Schaad Webex: https://ietf.webex.com/ietf/j.php?MTID=mf05c47a9a418179e3e810a151dcb25a9 Meeting number (access code): 647 836 420 Meeting password: emHrigC22K4 Jabber: cbor@jabber.ietf.org Agenda: * RFC7049 erratas : https://www.rfc-editor.org/errata_search.php?rfc=7049 * CBOR Tag for Date status : Mike https://tools.ietf.org/html/draft-jones-cbor-date-tag-02 - waiting on update for shepherd write up * CBOR OID draft : Carsten https://tools.ietf.org/html/draft-bormann-cbor-tags-oid-07 - Jim's review: https://github.com/cabo/cbor-oid/pull/1 * CDDL Module design cont. <https://mailarchive.ietf.org/arch/msg/cbor/8iot5AeY46IXdt5HYWORHjxcl28/> * CDDL modules: sockets and features <https://mailarchive.ietf.org/arch/msg/cbor/aHxANFr16iPo4NFqta7e_aT6ADE/> * IETF 108 scheduling https://datatracker.ietf.org/meeting/108/agenda/ we have 50 minutes - draft-bormann-cbor-packed-00 - draft-ietf-cbor-date-tag? - draft-bormann-cbor-tags-oid-07? - cddl? - more? * AoB Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mf05c47a9a418179e3e810a151dcb25a9 Meeting number (access code): 647 836 420 Meeting password: emHrigC22K4 From nobody Tue Jul 14 19:27:08 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 B5CC33A0D0E for ; Tue, 14 Jul 2020 19:27:06 -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 1s1_5BPow5Ll for ; Tue, 14 Jul 2020 19:27:04 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650117.outbound.protection.outlook.com [40.107.65.117]) (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 145833A0D0B for ; Tue, 14 Jul 2020 19:27:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R1knJO624nnPOrveEyQTuVnxXgb7BwzQCgCLJTx8FrzVFqggyPn1MMetpvhJ5JSrRV929xvdQVfsNxVqbQ7K0njbQZt9wxFd7QVFi0Hg3moPHHqdlDTk6/Sk+Yh2elt8He+W5n7D7nc8fX9zWV8MCLT2TBiVhQD8j/ch3CQNEW3cK57rEBEtEpvwSAk9ivM12zJwZ1yKE7QzDwtrBwvnqJ5xefAINC+v4uRBMSO36zcN0t+rTAv5tuZGdCV6jzHN11mYeYR5o3K4XOLgcMcDbsOYprpKWvUxKJpNpQXiu1CnfI/4BIVvVlXkjaXUjFGmy7ZR3WlKYSNtD3utWCjSyQ== 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=Vkzjn705P5v0wDWtficDZI2QsAwDD8k98fxwAXWbLe0=; b=jtzT+PbHxNoLyGX5bYwsI83FHo/pwi5hW5kyJMr3fWVxjpy8DGi4jZEmQb4KXHkuHFEQoW4uw6gVKdlOgNxUDk64hPyI+7TwHOFweAW6T2JprcYaW9D5O3FJKNyKPcGRw3uI+ILYgzkyHVvcAH2TQq2Gz7N5RtcDdLT+8Dxo58qxLEqlbvNXkoOOlyjpUshlUT0ILMeoub/aAGgaA+cO0hmXUe1iMFdnF7SOsLmXvhqEBvY45pCFW1/jRFFZL6HAcbS78jD9XSQ43EG9yg4nPY8LuAr3TFi5w+WgeHaU875Tyh3eOOc8uqPS64yOt93CxPrcbjgCo5d/0moD/vTvpQ== 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=Vkzjn705P5v0wDWtficDZI2QsAwDD8k98fxwAXWbLe0=; b=dO3Mo7M5iv6p8RDHyFn79fxTD+uuD0ME5ehO7KBXUTzKezPPAHOrdKW9U+nB4mTIn5qa6/mhQeoj5pQ+OQq69POrkhqiVEsLRAX9VZpn/Y0WQuaqvfeZV6h6wo+dKslTsr9zl6TCZmIa20OMclKNvDTxUxvkVso8smJ+bWXAFpY= Received: from CH2PR00MB0678.namprd00.prod.outlook.com (20.180.6.215) by CH2PR00MB0855.namprd00.prod.outlook.com (20.180.7.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3231.0; Wed, 15 Jul 2020 02:27:01 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::29f8:dc4a:8aac:e889]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::29f8:dc4a:8aac:e889%8]) with mapi id 15.20.3235.000; Wed, 15 Jul 2020 02:27:01 +0000 From: Mike Jones To: Francesca Palombini , "cbor@ietf.org" , "barryleiba@computer.org" Thread-Topic: Review of draft-ietf-cbor-date-tag-03 Thread-Index: AQHWVforjATfXTEzb0Ka+jqc+aOJ76kH8Xzg Date: Wed, 15 Jul 2020 02:27:01 +0000 Message-ID: References: <8919FFEE-2A57-4C0D-975C-5B65B3CC3AE8@ericsson.com> In-Reply-To: <8919FFEE-2A57-4C0D-975C-5B65B3CC3AE8@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-15T02:22:00Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=d935893d-90cc-4cdb-907c-6520ad795010; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d04add07-4574-4638-d28b-08d828668ead x-ms-traffictypediagnostic: CH2PR00MB0855: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: S3NLm1tt+dyFpnH/hGUJsxQH8ALG5n9ZYaSW9S8NHXUKt3ynBo6zT70f7YPUjoXLRsPt/ta1khoAiO9w52sfpxghLCPaNnOIyxwhgkMdpdzTQ00QZ0b7qD9hX/zE2j2Dz39/JqisJasuMTHDf4sJRe5Lq6HpyjB/NHNqUNBSMmiNda7Ry1XtALc69NODV4HUgA8J5GM0I0YL01dz5a2AgOdF7+C6coeIZYblzaVZL27DRWzxo0HhRIgFG7eQcZfNX/UlrZOOZnVpM+2QEkIsPp0ahzmoZg6ZA+0+au9Ez1riiigayjdf1DFxXBU2u0uE x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(366004)(346002)(376002)(8990500004)(7696005)(86362001)(71200400001)(110136005)(9686003)(316002)(55016002)(52536014)(5660300002)(53546011)(6506007)(8936002)(66576008)(66556008)(76116006)(66946007)(64756008)(66476007)(66446008)(83380400001)(2906002)(82960400001)(478600001)(33656002)(99936003)(186003)(8676002)(10290500003)(26005)(82950400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: sjbxRwXteC/lCks/9sv14/OjksymMfATcPc81uneLtwGn5z4CRLIheHemiEyF/KSd3ZDv5nLnCXfEukWnvbquX/BcORVjQIfyghFMASZOBucbs8qH7SqnmS3AXgYexXikQuZMTU/Lx+7UU/QOQfQrMBKD9Nho3PoNsgYNNi5/FMviKUmevFCEOIUR3GMElqKWHvbxfHIwCzFmzqoYN7ZLrAhZxrUWUeWnwjNDITpQFQdrCQJKH+1mpSA77YX46VpYISY+1UA1CbzcaHhXJJGSD3Y32YNWUTkU8aiz7yQDRMPbABW/nkADXWRP0Y1bMCPBr9ywm5CZ8TaAjcBgBzi1AltzHQuMg3bpG5X5HKLxMbXONeroEGUgbgchT9vhD9a+Ej6voD1O5vFIQTg861wGj5rJiKvKA389+DENuyjzAMDnDJoa1EYWPxyOymqOjTiS0DC4IotmntNvkL66ozzjQdfv4g0Qb4Mdj9//d0Tato= x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_003_CH2PR00MB0678F71646775F42E509F36FF57E0CH2PR00MB0678namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d04add07-4574-4638-d28b-08d828668ead X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2020 02:27:01.1626 (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: wNK5toag/znrPucQboEPycVfhBHBevOyXKxzs8A1pebGwQg24AEZ+bjqO6cACiEmIY1VBZscfnS7gfMmaV3mLA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0855 Archived-At: Subject: Re: [Cbor] Review of draft-ietf-cbor-date-tag-03 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 02:27:07 -0000 --_003_CH2PR00MB0678F71646775F42E509F36FF57E0CH2PR00MB0678namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2hvb3QgLSBJIGZpbmlzaGVkIHByZXBhcmluZyAtMDQgdG8gYWRkcmVzcyB5b3VyIGNvbW1lbnRz IGFuZCB0aG9zZSBvZiBvdGhlcnMsIG9ubHkgdG8gZGlzY292ZXIgdGhhdCBzdWJtaXNzaW9uIGlz IHByZXNlbnRseSBjbG9zZWQgKGFzIGhhcHBlbnMgYmVmb3JlIElFVEYgbWVldGluZ3MpLiAgSSdt IGF0dGFjaGluZyB0aGUgc291cmNlIGFuZCAudHh0IHZlcnNpb24gb2YgLTA0LiAgSWYgdGhlIGNo YWlycyBvciBBRCBjaG9vc2UgdG8sIG1heWJlIHlvdSBjYW4gcHVsbCB3aGF0ZXZlciBzdHJpbmdz IHlvdSBuZWVkIHRvIHdpdGggdGhlIHNlY3JldGFyaWF0IHRvIGdldCBpdCBwb3N0ZWQgYW55d2F5 LiAgKEkga25vdyBLYXRobGVlbiBkaWQgdGhhdCBmb3IgbWUgYXQgbGVhc3Qgb25jZSB3aGlsZSBz aGUgd2FzIGFuIGFyZWEgZGlyZWN0b3IuKQ0KDQoJCQkJVGhhbmtzLA0KCQkJCS0tIE1pa2UNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZy YW5jZXNjYS5wYWxvbWJpbmk9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+IA0KU2VudDog VGh1cnNkYXksIEp1bHkgOSwgMjAyMCA3OjA3IEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPjsgY2JvckBpZXRmLm9yZw0KU3ViamVjdDogW0VYVEVSTkFMXSBS ZXZpZXcgb2YgZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTAzDQoNCkhpIE1pa2UsDQoNCldoaWxl IHJldmlld2luZyBmb3IgdGhlIHNoZXBoZXJkIHdyaXRldXAgSSBmb3VuZCB0aGUgZm9sbG93aW5n IG1pbm9yIGlzc3VlczoNCg0KU2VjdGlvbiAxOg0KSSB3b3VsZCBzdWdnZXN0IHJlbW92aW5nIHRo ZSBjb21tYSBmcm9tIHRoZSBudW1iZXI6IDQwLDU4Ny4gVXNpbmcgdGhlIGNvbW1hIGFzIHNlcGFy YXRvciBpcyBub3QgdGhlIGJlc3QsIGFzIGluIHNvbWUgY291bnRyaWVzIGl0IGlzIHVzZWQgYXMg ZGVjaW1hbCBzaWduIChhbHNvIG5vdCBwcmVmZXJyZWQgYnV0IGFsbG93ZWQgaW4gSVNPIDg2MDEp Lg0KDQpGcm9tIEktRCBuaXRzOg0KICA9PSBUaGUgZG9jdW1lbnQgZG9lc24ndCB1c2UgYW55IFJG QyAyMTE5IGtleXdvcmRzLCB5ZXQgc2VlbXMgdG8gaGF2ZSBSRkMNCiAgICAgMjExOSBib2lsZXJw bGF0ZSB0ZXh0Lg0KSXMgaXQgbmVjZXNzYXJ5IHRvIGhhdmUgdGhlIDIxMTkgLSA4MTc0IGJvaWxl cnBsYXRlIHRleHQgZXZlbiBpZiBubyBub3JtYXRpdmUga2V5d29yZHMgYXJlIHVzZWQ/IA0KDQpb UE9TSVguMV0gc2VlbXMgbW9yZSBsaWtlIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBtZSwgZG9u J3QgeW91IHRoaW5rPw0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg0K --_003_CH2PR00MB0678F71646775F42E509F36FF57E0CH2PR00MB0678namp_ Content-Type: application/xml; name="draft-ietf-cbor-date-tag-04.xml" Content-Description: draft-ietf-cbor-date-tag-04.xml Content-Disposition: attachment; filename="draft-ietf-cbor-date-tag-04.xml"; size=12010; creation-date="Wed, 15 Jul 2020 02:24:00 GMT"; modification-date="Wed, 15 Jul 2020 02:24:00 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz4KCjw/eG1sLXN0eWxlc2hlZXQg dHlwZT0ndGV4dC94c2wnIGhyZWY9J2h0dHA6Ly94bWwycmZjLnRvb2xzLmlldGYub3JnL2F1dGhv cmluZy9yZmMyNjI5LnhzbHQnID8+CjwhRE9DVFlQRSByZmMgU1lTVEVNICJyZmMyNjI5LmR0ZCI+ Cgo8P3JmYyB0b2M9InllcyI/Pgo8P3JmYyB0b2NvbXBhY3Q9InllcyI/Pgo8P3JmYyB0b2NkZXB0 aD0iNCI/Pgo8P3JmYyB0b2NpbmRlbnQ9InllcyI/Pgo8P3JmYyBzeW1yZWZzPSJ5ZXMiPz4KPD9y ZmMgc29ydHJlZnM9InllcyI/Pgo8P3JmYyBjb21wYWN0PSJ5ZXMiPz4KPD9yZmMgc3ViY29tcGFj dD0ibm8iPz4KCjxyZmMgY2F0ZWdvcnk9InN0ZCIgCiAgICAgaXByPSJ0cnVzdDIwMDkwMiIgCiAg ICAgZG9jTmFtZT0iZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTA0Ij4KICA8ZnJvbnQ+CgogICAg PHRpdGxlIGFiYnJldj0iQ0JPUiBUYWcgZm9yIERhdGUiPkNvbmNpc2UgQmluYXJ5IE9iamVjdCBS ZXByZXNlbnRhdGlvbiAoQ0JPUikgVGFncyBmb3IgRGF0ZTwvdGl0bGU+CgogICAgPGF1dGhvciBm dWxsbmFtZT0iTWljaGFlbCBCLiBKb25lcyIgc3VybmFtZT0iSm9uZXMiIGluaXRpYWxzPSJNLkIu Ij4KICAgICAgPG9yZ2FuaXphdGlvbj5NaWNyb3NvZnQ8L29yZ2FuaXphdGlvbj4KICAgICAgPGFk ZHJlc3M+Cgk8ZW1haWw+bWJqQG1pY3Jvc29mdC5jb208L2VtYWlsPgoJPHVyaT5odHRwczovL3Nl bGYtaXNzdWVkLmluZm8vPC91cmk+CiAgICAgIDwvYWRkcmVzcz4KICAgIDwvYXV0aG9yPgoKICAg IDxhdXRob3IgZnVsbG5hbWU9IkFudGhvbnkgTmFkYWxpbiIgaW5pdGlhbHM9IkEuIiBzdXJuYW1l PSJOYWRhbGluIj4KICAgICAgPG9yZ2FuaXphdGlvbj5NaWNyb3NvZnQ8L29yZ2FuaXphdGlvbj4K ICAgICAgPGFkZHJlc3M+CiAgICAgICAgPGVtYWlsPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvZW1h aWw+CiAgICAgIDwvYWRkcmVzcz4KICAgIDwvYXV0aG9yPgoKICAgIDxhdXRob3IgZnVsbG5hbWU9 IkrDtnJnIFJpY2h0ZXIiIGluaXRpYWxzPSJKLiIgc3VybmFtZT0iUmljaHRlciI+CiAgICAgIDxv cmdhbml6YXRpb24+cGR2IEZpbmFuY2lhbCBTb2Z0d2FyZSBHbWJIPC9vcmdhbml6YXRpb24+CiAg ICAgIDxhZGRyZXNzPgoJPGVtYWlsPmpvZXJnLnJpY2h0ZXJAcGR2LWZzLmRlPC9lbWFpbD4KICAg ICAgPC9hZGRyZXNzPgogICAgPC9hdXRob3I+CgogICAgPGRhdGUgZGF5PSIxNCIgbW9udGg9Ikp1 bHkiIHllYXI9IjIwMjAiIC8+CgogICAgPGFyZWE+QXBwbGljYXRpb25zPC9hcmVhPgogICAgPHdv cmtncm91cD5DQk9SIFdvcmtpbmcgR3JvdXA8L3dvcmtncm91cD4KCiAgICA8a2V5d29yZD5Db21w YWN0IEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb248L2tleXdvcmQ+CiAgICA8a2V5d29yZD5D Qk9SPC9rZXl3b3JkPgogICAgPGtleXdvcmQ+VGFnPC9rZXl3b3JkPgogICAgPGtleXdvcmQ+RGF0 ZTwva2V5d29yZD4KICAgIDxrZXl3b3JkPkludGVybmV0LURyYWZ0PC9rZXl3b3JkPgoKICAgIDxh YnN0cmFjdD4KICAgICAgPHQ+CglUaGUgQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0 aW9uIChDQk9SLCBSRkMgNzA0OSkgaXMgYSBkYXRhCglmb3JtYXQgd2hvc2UgZGVzaWduIGdvYWxz IGluY2x1ZGUgdGhlIHBvc3NpYmlsaXR5IG9mIGV4dHJlbWVseSBzbWFsbAoJY29kZSBzaXplLCBm YWlybHkgc21hbGwgbWVzc2FnZSBzaXplLCBhbmQgZXh0ZW5zaWJpbGl0eSB3aXRob3V0IHRoZQoJ bmVlZCBmb3IgdmVyc2lvbiBuZWdvdGlhdGlvbi4KICAgICAgPC90PgogICAgICA8dD4KCUluIENC T1IsIG9uZSBwb2ludCBvZiBleHRlbnNpYmlsaXR5IGlzIHRoZSBkZWZpbml0aW9uIG9mIENCT1Ig dGFncy4KCVJGQyA3MDQ5IGRlZmluZXMgdHdvIHRhZ3MgZm9yIHRpbWU6CglDQk9SIHRhZyAwIChS RkMgMzMzOSBkYXRlL3RpbWUgc3RyaW5nKQoJYW5kIHRhZyAxIChQb3NpeCAic2Vjb25kcyBzaW5j ZSB0aGUgZXBvY2giKS4KCVNpbmNlIHRoZW4sIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIGhhdmUg YmVjb21lIGtub3duLgoJVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSBDQk9SIHRhZyBmb3Ig YW4gUkZDIDMzMzkgZGF0ZSB0ZXh0IHN0cmluZywKCWZvciBhcHBsaWNhdGlvbnMgbmVlZGluZyBh IHRleHR1YWwgZGF0ZSByZXByZXNlbnRhdGlvbgoJd2l0aGluIHRoZSBHcmVnb3JpYW4gY2FsZW5k YXIgd2l0aG91dCBhIHRpbWUuCglJdCBhbHNvIGRlZmluZXMgYSBDQk9SIHRhZyBmb3IgZGF5cyBz aW5jZSB0aGUgZGF0ZSAxOTcwLTAxLTAxIGluIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIKCWZvciBh cHBsaWNhdGlvbnMgbmVlZGluZyBhIG51bWVyaWMgZGF0ZSByZXByZXNlbnRhdGlvbiB3aXRob3V0 IGEgdGltZS4KCUl0IGlzIGludGVuZGVkIGFzIHRoZSByZWZlcmVuY2UgZG9jdW1lbnQgZm9yIHRo ZSBJQU5BIHJlZ2lzdHJhdGlvbgoJb2YgdGhlIENCT1IgdGFncyBkZWZpbmVkLgogICAgICA8L3Q+ CiAgICA8L2Fic3RyYWN0PgogIDwvZnJvbnQ+CiAgPG1pZGRsZT4KICAgIDxzZWN0aW9uIGFuY2hv cj0iSW50cm9kdWN0aW9uIiB0aXRsZT0iSW50cm9kdWN0aW9uIj4KICAgICAgPHQ+CglUaGUgQ29u Y2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIChDQk9SKSA8eHJlZiB0YXJnZXQ9IlJG QzcwNDkiLz4KCXByb3ZpZGVzIGZvciB0aGUgaW50ZXJjaGFuZ2Ugb2Ygc3RydWN0dXJlZCBkYXRh Cgl3aXRob3V0IGEgcmVxdWlyZW1lbnQgZm9yIGEgcHJlLWFncmVlZCBzY2hlbWEuCglSRkMgNzA0 OSBkZWZpbmVzIGEgYmFzaWMgc2V0IG9mIGRhdGEgdHlwZXMsIGFzIHdlbGwgYXMgYSB0YWdnaW5n IG1lY2hhbmlzbQoJdGhhdCBlbmFibGVzIGV4dGVuZGluZyB0aGUgc2V0IG9mIGRhdGEgdHlwZXMg c3VwcG9ydGVkIHZpYSBhbiBJQU5BIHJlZ2lzdHJ5LgogICAgICA8L3Q+CiAgICAgIDx0PgoJVGhp cyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSBDQk9SIHRhZyBmb3IgYSB0ZXh0IHN0cmluZyByZXBy ZXNlbnRpbmcgYSBkYXRlIHdpdGhvdXQgYSB0aW1lLgoJVGhlIHRhZ2dlZCB0ZXh0IHN0cmluZyBp cyByZXByZXNlbnRlZCBhcyBzcGVjaWZpZWQgYnkgdGhlIFJGQyAzMzM5IDx4cmVmIHRhcmdldD0i UkZDMzMzOSIvPgoJPHNwYW54IHN0eWxlPSJ2ZXJiIj5mdWxsLWRhdGU8L3NwYW54PiBwcm9kdWN0 aW9uLgoJUGVyIFJGQyAzMzM5LCB0aGlzIHJlcHJlc2VudHMgYSBkYXRlIHdpdGhpbiB0aGUgR3Jl Z29yaWFuIGNhbGVuZGFyLgogICAgICA8L3Q+CiAgICAgIDx0PgoJVGhpcyBzcGVjaWZpY2F0aW9u IGFsc28gZGVmaW5lcyBhIENCT1IgdGFnIGZvciBhbiBpbnRlZ2VyIHJlcHJlc2VudGluZyBhIGRh dGUgd2l0aG91dCBhIHRpbWUuCglUaGUgdGFnZ2VkIGludGVnZXIgaXMgYW4gdW5zaWduZWQgb3Ig bmVnYXRpdmUgdmFsdWUgaW5kaWNhdGluZyB0aGUgbnVtYmVyIG9mIGRheXMKCXNpbmNlIHRoZSBH cmVnb3JpYW4gY2FsZW5kYXIgZGF0ZSAxOTcwLTAxLTAxLgoJQXMgYW4gaW1wbGVtZW50YXRpb24g bm90ZSwgdGhpcyB2YWx1ZSBoYXMgYSBjb25zdGFudCBvZmZzZXQgZnJvbSB0aGUgTW9kaWZpZWQg SnVsaWFuIERhdGUgdmFsdWUKCSh3aGljaCBpcyBkZWZpbmVkIGJ5IHRoZSBTbWl0aHNvbmlhbiBB c3Ryb3BoeXNpY2FsIE9ic2VydmF0b3J5IGFzIHRoZSBudW1iZXIgb2YgZGF5cyBzaW5jZQoJTm92 ZW1iZXIgMTcsIDE4NTgpOyB0aGlzIHZhbHVlIGlzIHRoZSBNb2RpZmllZCBKdWxpYW4gRGF0ZSBt aW51cyA0MDU4Ny4KICAgICAgPC90PgogICAgICA8dD4KCU5vdGUgdGhhdCBzaW5jZSBib3RoIHRh Z3MgYXJlIGZvciBkYXRlcyB3aXRob3V0IHRpbWVzLAoJdGltZXMgb2YgZGF5LCB0aW1lIHpvbmVz LCBhbmQgbGVhcCBzZWNvbmRzIGFyZSBub3QgYXBwbGljYWJsZSB0byB0aGVzZSB2YWx1ZXMuCglU aGVzZSB0YWdzIGFyZSBib3RoIGZvciByZXByZXNlbnRhdGlvbnMgb2YgR3JlZ29yaWFuIGNhbGVu ZGFyIGRhdGVzLgogICAgICA8L3Q+Cgo8IS0tIE5vIFJGQyAyMTE5IGtleXdvcmRzIGFyZSB1c2Vk IGluIHRoaXMgZG9jdW1lbnQuCiAgICAgIDxzZWN0aW9uIGFuY2hvcj0icm5jIiB0aXRsZT0iUmVx dWlyZW1lbnRzIE5vdGF0aW9uIGFuZCBDb252ZW50aW9ucyI+CiAgICAgICAgPHQ+CgkgIFRoZSBr ZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwg Tk9UIiwKCSAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk5PVCBSRUNP TU1FTkRFRCIsICJNQVkiLCBhbmQKCSAgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0 byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4KCSAgQkNQIDE0IDx4cmVmIHRhcmdldD0i UkZDMjExOSIvPiA8eHJlZiB0YXJnZXQ9IlJGQzgxNzQiLz4gd2hlbiwgYW5kCgkgIG9ubHkgd2hl biwgdGhleSBhcHBlYXIgaW4gYWxsIGNhcGl0YWxzLCBhcyBzaG93biBoZXJlLgoJPC90PgogICAg ICA8L3NlY3Rpb24+Ci0tPgoKICAgICAgPHNlY3Rpb24gYW5jaG9yPSJDYWxlbmRhckRhdGVzIiB0 aXRsZT0iQ2FsZW5kYXIgRGF0ZXMiPgoJPHQ+CgkgIENhbGVuZGFyIGRhdGVzIGFyZSB1c2VkIGZv ciBudW1lcm91cyBodW1hbiB1c2UgY2FzZXMsCgkgIHN1Y2ggYXMgbWFya2luZyB0aGUgZGF0ZXMg b2Ygc2lnbmlmaWNhbnQgZXZlbnRzLgoJICBGb3IgaW5zdGFuY2UsIEpvaG4gTGVubm9uIHdhcyBi b3JuIG9uIE9jdG9iZXIgOSwgMTk0MCBhbmQgZGllZCBvbiBEZWNlbWJlciA4LCAxOTgwLgoJICBP bmUgc3VjaCBjb21tb24gdXNlIGNhc2UgaXMgZHJpdmVyJ3MgbGljZW5zZXMsIHdoaWNoIHR5cGlj YWxseSBpbmNsdWRlIGEgZGF0ZSBvZiBiaXJ0aC4KCSAgVGhlIGRhdGVzIHVzZWQgaW4gdGhpcyBz cGVjaWZpY2F0aW9uIHVzZSB0aGUgR3JlZ29yaWFuIGNhbGVuZGFyLAoJICBhcyBkbyB0aG9zZSBp biBSRkMgMzMzOSA8eHJlZiB0YXJnZXQ9IlJGQzMzMzkiLz4uCgkgIFRoZSB0aW1lIHpvbmVzIGFu ZCBhY3R1YWwgdGltZXMgb2YgdGhlc2UgZXZlbnRzIGFyZSBpbnRlbnRpb25hbGx5IG5vdCByZXBy ZXNlbnRlZCBpbiB0aGUgY2FsZW5kYXIgZGF0ZS4KCTwvdD4KCTx0PgoJICBUaGUgZXBvY2ggY2hv c2VuIGZvciB0aGUgc2Vjb25kIHRhZywgd2hpY2ggcmVwcmVzZW50cyBkYXlzIHNpbmNlIHRoZSBH cmVnb3JpYW4gY2FsZW5kYXIgZGF0ZSAxOTcwLTAxLTAxLAoJICBpcyByZWxhdGVkIHRvIHRoZSA8 eHJlZiB0YXJnZXQ9IlBPU0lYLjEiPklFRUUgU3RkIDEwMDMuMSwgMjAxMyBFZGl0aW9uPC94cmVm PiB0aW1lIGVwb2NoCgkgIDE5NzAtMDEtMDFUMDA6MDA6MDBaIFVUQyBvbmx5IGluc29mYXIgYXMg Ym90aCBjb250YWluIHRoZSBkYXRlIDE5NzAtMDEtMDEuCgkgIFRoaXMgc2hvdWxkIG5vdCBiZSBj b25zdHJ1ZWQgYXMgaW5kaWNhdGluZyB0aGF0IGRhdGVzIHVzaW5nIHRoaXMgdGFnCgkgIHJlcHJl c2VudCBlaXRoZXIgYSBzcGVjaWZpYyB0aW1lIG9mIGRheSBhbmQvb3IgdGltZSB6b25lLgoJPC90 PgoJPHQ+CgkgIFRoZSBkYXkgb2YgdGhlIHdlZWsgKFN1bmRheSwgTW9uZGF5LCBUdWVzZGF5LCBl dGMuKSBpcyBub3QgZXhwbGljaXRseSByZXByZXNlbnRlZAoJICBpbiBlaXRoZXIgb2YgdGhlc2Ug ZGF0ZSBmb3JtYXRzLgoJICBIb3dldmVyLCBkZXRlcm1pbmlzdGljIGFsZ29yaXRobXMgdGhhdCBh cmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24KCSAgY2FuIGJlIHVzZWQg dG8gZGVyaXZlIHRoZSBkYXkgb2YgdGhlIHdlZWsgaW4gdGhlIEdyZWdvcmlhbiBjYWxlbmRhcgoJ ICBmcm9tIGRhdGVzIHJlcHJlc2VudGVkIGluIGJvdGggb2YgdGhlc2UgZm9ybWF0cy4KCTwvdD4K ICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gYW5jaG9yPSJDb21wYXJpbmdEYXRlcyIg dGl0bGU9IkNvbXBhcmluZyBEYXRlcyI+Cgk8dD4KCSAgQ29tcGFyaXNvbiBvZiBkYXRlcyBpbiA8 c3Bhbnggc3R5bGU9InZlcmIiPmZ1bGwtZGF0ZTwvc3Bhbng+IGZvcm1hdCBjYW4gYmUgYWNjb21w bGlzaGVkIGJ5CgkgIG5vcm1hbCBzdHJpbmcgY29tcGFyaXNvbiwgc2luY2UgYnkgZGVzaWduLCB0 aGUgZGlnaXRzIHJlcHJlc2VudGluZyB0aGUgZGF0ZSBhcmUgaW4gZml4ZWQgZm9ybWF0CgkgIGFu ZCBvcmRlcmVkIGZyb20gbW9zdCBzaWduaWZpY2FudCB0byBsZWFzdCBzaWduaWZpY2FudC4KCSAg Q29tcGFyaXNvbiBvZiBudW1lcmljIGRhdGVzIHJlcHJlc2VudGluZyBkYXlzIHNpbmNlIDE5NzAt MDEtMDEgY2FuIGJlIHBlcmZvcm1lZCBieQoJICBub3JtYWwgaW50ZWdlciBjb21wYXJpc29uLgoJ ICBDb21wYXJpc29uIG9mIGRhdGVzIGluIG90aGVyIGZvcm1hdHMgb3IgdXNpbmcgb3RoZXIgY2Fs ZW5kYXJzIHJlcXVpcmUgY29udmVyc2lvbnMKCSAgdGhhdCBhcmUgYmV5b25kIHRoZSBzY29wZSBv ZiB0aGlzIHNwZWNpZmljYXRpb24uCgk8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0 aW9uIGFuY2hvcj0iQ29tcGFyaW5nRGF0ZXNBbmRUaW1lcyIgdGl0bGU9IkNvbXBhcmluZyBEYXRl cyBhbmQgVGltZXMiPgoJPHQ+CgkgIENvbXBhcmluZyBkYXRlcyB3aXRoIHRpbWVzIGlzIGJleW9u ZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLgoJICBUaGF0IHNhaWQsIGlmIGEgZGF0 ZSBpcyBhdWdtZW50ZWQgd2l0aCBhIHRpbWUgem9uZSBhbmQgdGltZSBvZiBkYXksCgkgIGNvbXBh cmluZyB0aGF0IGF1Z21lbnRlZCBkYXRlIHdpdGggb3RoZXIgdGltZXMgYmVjb21lcyBwb3NzaWJs ZS4KCSAgRm9yIGluc3RhbmNlLCBpZiBvbmUgd2VyZSB0byBhdWdtZW50IEpvaG4gTGVubm9uJ3Mg YmlydGggZGF0ZQoJICBvZiBPY3RvYmVyIDksIDE5NDAgd2l0aCB0aGUgdGltZSBvZiBkYXkgYW5k IHRpbWUgem9uZSBvZiBoaXMgYmlydGgsCgkgIHRoZW4gaXQgd291bGQgYmUgcG9zc2libGUgdG8g ZGVyaXZlIGEgdGltZSBhdCB3aGljaCBoZSB3YXMgYm9ybgoJICB0aGF0IGNvdWxkIGJlIGNvbXBh cmVkIHdpdGggb3RoZXIgdGltZXMuCgk8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICA8L3NlY3Rp b24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJJQU5BIiB0aXRsZT0iSUFOQSBDb25zaWRlcmF0aW9u cyI+CgogICAgICA8c2VjdGlvbiBhbmNob3I9ImNvc2UtYWxnb3JpdGhtcy1yZWdpc3RyYXRpb25z IiB0aXRsZT0iQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIChDQk9SKSBUYWdz IFJlZ2lzdHJhdGlvbnMiPgogICAgICAgIDx0PgoJICBUaGlzIHNlY3Rpb24gcmVnaXN0ZXJzIHRo ZSBmb2xsb3dpbmcgdmFsdWVzIGluIHRoZQoJICBJQU5BICJDb25jaXNlIEJpbmFyeSBPYmplY3Qg UmVwcmVzZW50YXRpb24gKENCT1IpIFRhZ3MiIHJlZ2lzdHJ5IDx4cmVmIHRhcmdldD0iSUFOQS5j Ym9yLXRhZ3MiLz4uCgk8L3Q+Cgk8dD4KCSAgPD9yZmMgc3ViY29tcGFjdD0ieWVzIj8+CgkgIDxs aXN0IHN0eWxlPSdzeW1ib2xzJz4KCSAgICA8dD4KCSAgICAgIFRhZzogMTAwNCAodmFsdWUgcmVx dWVzdGVkKQoJICAgIDwvdD4KCSAgICA8dD4KCSAgICAgIERhdGEgSXRlbTogVVRGLTggdGV4dCBz dHJpbmcKCSAgICA8L3Q+CgkgICAgPHQ+CgkgICAgICBTZW1hbnRpY3M6IFJGQyAzMzM5IGZ1bGwt ZGF0ZSBzdHJpbmcKCSAgICA8L3Q+CgkgICAgPHQ+CgkgICAgICBSZWZlcmVuY2U6IFtbIHRoaXMg c3BlY2lmaWNhdGlvbiBdXQoJICAgIDwvdD4KCSAgPC9saXN0PgoJPC90PgoJPHQ+CgkgIDxsaXN0 IHN0eWxlPSdzeW1ib2xzJz4KCSAgICA8dD4KCSAgICAgIFRhZzogMTAwIChBU0NJSSAnZCcpICh2 YWx1ZSByZXF1ZXN0ZWQpCgkgICAgPC90PgoJICAgIDx0PgoJICAgICAgRGF0YSBJdGVtOiBVbnNp Z25lZCBvciBuZWdhdGl2ZSBpbnRlZ2VyCgkgICAgPC90PgoJICAgIDx0PgoJICAgICAgU2VtYW50 aWNzOiBOdW1iZXIgb2YgZGF5cyBzaW5jZSB0aGUgZXBvY2ggZGF0ZSAxOTcwLTAxLTAxCgkgICAg PC90PgoJICAgIDx0PgoJICAgICAgUmVmZXJlbmNlOiBbWyB0aGlzIHNwZWNpZmljYXRpb24gXV0K CSAgICA8L3Q+CgkgIDwvbGlzdD4KCTwvdD4KCTw/cmZjIHN1YmNvbXBhY3Q9Im5vIj8+CiAgICAg IDwvc2VjdGlvbj4KCiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJTZWN1cml0 eSIgdGl0bGU9IlNlY3VyaXR5IENvbnNpZGVyYXRpb25zIj4KICAgICAgPHQ+CglUaGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgb2YgUkZDIDcwNDkgYXBwbHk7IHRoZSB0YWdzIGludHJvZHVjZWQK CWhlcmUgYXJlIG5vdCBleHBlY3RlZCB0byByYWlzZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBi ZXlvbmQgdGhvc2UuCiAgICAgIDwvdD4KICAgICAgPHQ+CglBIGRhdGUsIG9mIGNvdXJzZSwgaGFz IHNpZ25pZmljYW50IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLgoJVGhlc2UgaW5jbHVkZSB0aGUg ZXhwbG9pdGF0aW9uIG9mIGFtYmlndWl0aWVzIHdoZXJlIHRoZSBkYXRlIGlzIHNlY3VyaXR5IHJl bGV2YW50CglvciB3aGVyZSB0aGUgZGF0ZSBpcyB1c2VkIGluIGFjY2VzcyBjb250cm9sIGRlY2lz aW9ucy4KICAgICAgPC90PgogICAgICA8dD4KCVdoZW4gdXNpbmcgYSBjYWxlbmRhciBkYXRlIGZv ciBkZWNpc2lvbiBtYWtpbmcsIGZvciBleGFtcGxlIGFjY2VzcyBjb250cm9sLAoJaXQgbmVlZHMg dG8gYmUgbm90ZWQgdGhhdCBzaW5jZSBjYWxlbmRhciBkYXRlcyBkbyBub3QgcmVwcmVzZW50IGEg c3BlY2lmaWMgcG9pbnQgaW4gdGltZSwKCXRoZSByZXN1bHRzIG9mIHRoZSBldmFsdWF0aW9uIGNh biBkaWZmZXIgZGVwZW5kaW5nIHVwb24gd2hlcmUgdGhlIGRlY2lzaW9uIGlzIG1hZGUuCglGb3Ig aW5zdGFuY2UsIGEgcGVyc29uIG1heSBoYXZlIHJlYWNoZWQgdGhlaXIgMjFzdCBiaXJ0aGRheSBp biBKYXBhbgoJd2hpbGUgc2ltdWx0YW5lb3VzbHkgYmVpbmcgYSBkYXkgc2hvcnQgb2YgdGhlaXIg MjFzdCBiaXJ0aGRheSBpbiBIYXdhaWkuCiAgICAgIDwvdD4KICAgIDwvc2VjdGlvbj4KCiAgPC9t aWRkbGU+CgogIDxiYWNrPgogICAgPHJlZmVyZW5jZXMgdGl0bGU9Ik5vcm1hdGl2ZSBSZWZlcmVu Y2VzIj4KCiAgICAgIDwhLS0gPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy4yMTE5LnhtbCI/ PiAtLT4KICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy4zMzM5LnhtbCI/PgogICAg ICA8P3JmYyBpbmNsdWRlPSJyZWZlcmVuY2UuUkZDLjcwNDkueG1sIj8+CiAgICAgIDwhLS0gPD9y ZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy44MTc0LnhtbCI/PiAtLT4KCiAgICA8L3JlZmVyZW5j ZXM+CgogICAgPHJlZmVyZW5jZXMgdGl0bGU9IkluZm9ybWF0aXZlIFJlZmVyZW5jZXMiPgoKICAg ICAgPHJlZmVyZW5jZSBhbmNob3I9IklBTkEuY2Jvci10YWdzIiB0YXJnZXQ9Imh0dHA6Ly93d3cu aWFuYS5vcmcvYXNzaWdubWVudHMvY2Jvci10YWdzIj4KICAgICAgICA8ZnJvbnQ+CiAgICAgICAg ICA8dGl0bGU+Q29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIChDQk9SKSBUYWdz PC90aXRsZT4KICAgICAgICAgIDxhdXRob3I+CiAgICAgICAgICAgIDxvcmdhbml6YXRpb24+SUFO QTwvb3JnYW5pemF0aW9uPgogICAgICAgICAgPC9hdXRob3I+CgkgIDxkYXRlLz4KICAgICAgICA8 L2Zyb250PgogICAgICA8L3JlZmVyZW5jZT4KCiAgICAgIDxyZWZlcmVuY2UgYW5jaG9yPSJQT1NJ WC4xIiB0YXJnZXQ9Imh0dHA6Ly9wdWJzLm9wZW5ncm91cC5vcmcvb25saW5lcHVicy85Njk5OTE5 Nzk5L2Jhc2VkZWZzL1YxX2NoYXAwNC5odG1sI3RhZ18wNF8xNSI+Cgk8ZnJvbnQ+CgkgIDx0aXRs ZT5UaGUgT3BlbiBHcm91cCBCYXNlIFNwZWNpZmljYXRpb25zIElzc3VlIDc8L3RpdGxlPgoJICA8 YXV0aG9yPgoJICAgIDxvcmdhbml6YXRpb24+SUVFRTwvb3JnYW5pemF0aW9uPgoJICA8L2F1dGhv cj4KCSAgPGRhdGUgeWVhcj0iMjAxMyIvPgoJPC9mcm9udD4KCTxzZXJpZXNJbmZvIG5hbWU9IklF RUUiIHZhbHVlPSJTdGQgMTAwMy4xLCAyMDEzIEVkaXRpb24iLz4KICAgICAgPC9yZWZlcmVuY2U+ CgogICAgPC9yZWZlcmVuY2VzPgoKICAgIDxzZWN0aW9uIHRpdGxlPSJBY2tub3dsZWRnZW1lbnRz IiBhbmNob3I9IkFja25vd2xlZGdlbWVudHMiIG51bWJlcmVkPSJubyI+CgogICAgICA8dD4KCVRo YW5rcyB0byBDYXJzdGVuIEJvcm1hbm4gZm9yIHN1cHBvcnRpbmcgY3JlYXRpb24gb2YgdGhpcyBz cGVjaWZpY2F0aW9uLgoJUGFydHMgb2YgdGhlIGV4cGxhbmF0b3J5IHRleHQgaW4gdGhpcyBzcGVj aWZpY2F0aW9uIGNvbWUgZnJvbSBkcmFmdC1ib3JtYW5uLWNib3ItdGltZS10YWctMDIuCiAgICAg IDwvdD4KICAgICAgPHQ+CglUaGFua3MgdG8gdGhlc2UgcGVvcGxlIGZvciByZXZpZXdzIG9mIHRo ZSBzcGVjaWZpY2F0aW9uOgoJSGVuayBCaXJraG9seiwKCUNhcnN0ZW4gQm9ybWFubiwKCVRoaWFn byBNYWNpZWlyYSwKCUZyYW5jZXNjYSBQYWxvbWJpbmksCglNaWNoYWVsIFJpY2hhcmRzb24sCglK aW0gU2NoYWFkLAoJSnVlcmdlbiBTY2hvZW53YWVsZGVyLAoJYW5kCglEYWxlIFdvcmxleS4KICAg ICAgPC90PgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSJEb2N1bWVudCBIaXN0 b3J5IiBhbmNob3I9Ikhpc3RvcnkiPgogICAgICA8dD4KICAgICAgICBbWyB0byBiZSByZW1vdmVk IGJ5IHRoZSBSRkMgRWRpdG9yIGJlZm9yZSBwdWJsaWNhdGlvbiBhcyBhbiBSRkMgXV0KICAgICAg PC90PgoKICAgICAgPHQ+CiAgICAgICAgLTA0CiAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMn PgogICAgICAgICAgPHQ+CgkgICAgQWRkcmVzc2VkIHNoZXBoZXJkIGNvbW1lbnRzIGJ5IEZyYW5j ZXNjYSBQYWxvbWJpbmkuCgkgIDwvdD4KICAgICAgICAgICA8dD4KCSAgICBBZGRyZXNzZWQgYWRk aXRpb25hbCByZXZpZXcgY29tbWVudHMgYnkgSmltIFNjaGFhZCBhbmQgTWljaGFlbCBSaWNoYXJk c29uLgoJICA8L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8L3Q+CgogICAgICA8dD4KICAgICAg ICAtMDMKICAgICAgICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICA8dD4KCSAgICBB ZGRlZCBzdGF0ZW1lbnQgdGhhdCB0aGVzZSB0YWdzIGFyZSBib3RoIGZvciByZXByZXNlbnRhdGlv bnMgb2YgY2FsZW5kYXIgZGF0ZXMuCgkgIDwvdD4KCSAgPHQ+CgkgICAgRGVzY3JpYmVkIGNvbnNl cXVlbmNlcyBvZiB1c2luZyBjYWxlbmRhciBkYXRlcyBpbiBhY2Nlc3MgY29udHJvbCBkZWNpc2lv bnMuCgkgIDwvdD4KICAgICAgICA8L2xpc3Q+CiAgICAgIDwvdD4KCiAgICAgIDx0PgogICAgICAg IC0wMgogICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgIDx0PgoJICAgIEFk ZHJlc3NlZCB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBjb21tZW50cywKCSAgICBpbmNsdWRpbmcg c3RhdGluZyB0aGF0IHRpbWUgem9uZXMgYXJlIG5vdCBhcHBsaWNhYmxlIHRvIHRoZXNlIHZhbHVl cy4KCSAgPC90PgogICAgICAgIDwvbGlzdD4KICAgICAgPC90PgoKICAgICAgPHQ+CiAgICAgICAg LTAxCiAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgPHQ+CgkgICAgQ2hh bmdlZCAicG9zaXRpdmUgb3IgbmVnYXRpdmUiIHRvICJ1bnNpZ25lZCBvciBuZWdhdGl2ZSIuCiAg ICAgICAgICA8L3Q+CgkgIDx0PgoJICAgIEFkZGVkIGFuIGltcGxlbWVudGF0aW9uIG5vdGUgYWJv dXQgdGhlIHJlbGF0aW9uc2hpcCB0byBNb2RpZmllZCBKdWxpYW4gRGF0ZXMuCgkgIDwvdD4KICAg ICAgICA8L2xpc3Q+CiAgICAgIDwvdD4KCiAgICAgIDx0PgogICAgICAgIC0wMAogICAgICAgIDxs aXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgIDx0PgoJICAgIEluaXRpYWwgd29ya2luZyBn cm91cCB2ZXJzaW9uIGJhc2VkIG9uIGRyYWZ0LWpvbmVzLWNib3ItZGF0ZS10YWctMDEgd2l0aCBu byBub3JtYXRpdmUgY2hhbmdlcy4KICAgICAgICAgIDwvdD4KICAgICAgICA8L2xpc3Q+CiAgICAg IDwvdD4KCiAgICA8L3NlY3Rpb24+CgogIDwvYmFjaz4KPC9yZmM+Cg== --_003_CH2PR00MB0678F71646775F42E509F36FF57E0CH2PR00MB0678namp_ Content-Type: text/plain; name="draft-ietf-cbor-date-tag-04.txt" Content-Description: draft-ietf-cbor-date-tag-04.txt Content-Disposition: attachment; filename="draft-ietf-cbor-date-tag-04.txt"; size=12191; creation-date="Wed, 15 Jul 2020 02:24:00 GMT"; modification-date="Wed, 15 Jul 2020 02:24:00 GMT" Content-Transfer-Encoding: base64 CgoKCkNCT1IgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBNLiBKb25lcwpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEEuIE5hZGFsaW4KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWljcm9zb2Z0CkV4cGly ZXM6IEphbnVhcnkgMTUsIDIwMjEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Si4gUmljaHRlcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBw ZHYgRmluYW5jaWFsIFNvZnR3YXJlIEdtYkgKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdWx5IDE0LCAyMDIwCgoKICAgICAgIENvbmNp c2UgQmluYXJ5IE9iamVjdCBSZXByZXNlbnRhdGlvbiAoQ0JPUikgVGFncyBmb3IgRGF0ZQogICAg ICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTA0CgpBYnN0cmFjdAoK ICAgVGhlIENvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXByZXNlbnRhdGlvbiAoQ0JPUiwgUkZDIDcw NDkpIGlzIGEgZGF0YQogICBmb3JtYXQgd2hvc2UgZGVzaWduIGdvYWxzIGluY2x1ZGUgdGhlIHBv c3NpYmlsaXR5IG9mIGV4dHJlbWVseSBzbWFsbAogICBjb2RlIHNpemUsIGZhaXJseSBzbWFsbCBt ZXNzYWdlIHNpemUsIGFuZCBleHRlbnNpYmlsaXR5IHdpdGhvdXQgdGhlCiAgIG5lZWQgZm9yIHZl cnNpb24gbmVnb3RpYXRpb24uCgogICBJbiBDQk9SLCBvbmUgcG9pbnQgb2YgZXh0ZW5zaWJpbGl0 eSBpcyB0aGUgZGVmaW5pdGlvbiBvZiBDQk9SIHRhZ3MuCiAgIFJGQyA3MDQ5IGRlZmluZXMgdHdv IHRhZ3MgZm9yIHRpbWU6IENCT1IgdGFnIDAgKFJGQyAzMzM5IGRhdGUvdGltZQogICBzdHJpbmcp IGFuZCB0YWcgMSAoUG9zaXggInNlY29uZHMgc2luY2UgdGhlIGVwb2NoIikuICBTaW5jZSB0aGVu LAogICBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBoYXZlIGJlY29tZSBrbm93bi4gIFRoaXMgc3Bl Y2lmaWNhdGlvbgogICBkZWZpbmVzIGEgQ0JPUiB0YWcgZm9yIGFuIFJGQyAzMzM5IGRhdGUgdGV4 dCBzdHJpbmcsIGZvciBhcHBsaWNhdGlvbnMKICAgbmVlZGluZyBhIHRleHR1YWwgZGF0ZSByZXBy ZXNlbnRhdGlvbiB3aXRoaW4gdGhlIEdyZWdvcmlhbiBjYWxlbmRhcgogICB3aXRob3V0IGEgdGlt ZS4gIEl0IGFsc28gZGVmaW5lcyBhIENCT1IgdGFnIGZvciBkYXlzIHNpbmNlIHRoZSBkYXRlCiAg IDE5NzAtMDEtMDEgaW4gdGhlIEdyZWdvcmlhbiBjYWxlbmRhciBmb3IgYXBwbGljYXRpb25zIG5l ZWRpbmcgYQogICBudW1lcmljIGRhdGUgcmVwcmVzZW50YXRpb24gd2l0aG91dCBhIHRpbWUuICBJ dCBpcyBpbnRlbmRlZCBhcyB0aGUKICAgcmVmZXJlbmNlIGRvY3VtZW50IGZvciB0aGUgSUFOQSBy ZWdpc3RyYXRpb24gb2YgdGhlIENCT1IgdGFncwogICBkZWZpbmVkLgoKU3RhdHVzIG9mIFRoaXMg TWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3Jt YW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBh bHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAg VGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFy ZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFu ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVu dHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1E cmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFu IGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBp cmUgb24gSmFudWFyeSAxNSwgMjAyMS4KCgoKCgpKb25lcywgZXQgYWwuICAgICAgICAgICBFeHBp cmVzIEphbnVhcnkgMTUsIDIwMjEgICAgICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgQ0JPUiBUYWcgZm9yIERhdGUgICAgICAgICAgICAgICAgICBKdWx5 IDIwMjAKCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMjAgSUVURiBUcnVz dCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4g IEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQ IDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8g SUVURiBEb2N1bWVudHMKICAgKGh0dHBzOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8p IGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50 LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRl c2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRo aXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVu dCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJl IHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlm aWVkIEJTRCBMaWNlbnNlLgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24g IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMgogICAg IDEuMS4gIENhbGVuZGFyIERhdGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDMKICAgICAxLjIuICBDb21wYXJpbmcgRGF0ZXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgICAgMS4zLiAgQ29tcGFyaW5nIERhdGVzIGFu ZCBUaW1lcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAyLiAgSUFOQSBD b25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDQKICAgICAyLjEuICBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENCT1Ip IFRhZ3MKICAgICAgICAgICBSZWdpc3RyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgIDMuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICA0LiAgUmVmZXJlbmNlcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQKICAg ICA0LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA0CiAgICAgNC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgRG9jdW1lbnQg SGlzdG9yeSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA1CiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgNgoKMS4gIEludHJvZHVjdGlvbgoKICAgVGhlIENvbmNpc2UgQmlu YXJ5IE9iamVjdCBSZXByZXNlbnRhdGlvbiAoQ0JPUikgW1JGQzcwNDldIHByb3ZpZGVzCiAgIGZv ciB0aGUgaW50ZXJjaGFuZ2Ugb2Ygc3RydWN0dXJlZCBkYXRhIHdpdGhvdXQgYSByZXF1aXJlbWVu dCBmb3IgYQogICBwcmUtYWdyZWVkIHNjaGVtYS4gIFJGQyA3MDQ5IGRlZmluZXMgYSBiYXNpYyBz ZXQgb2YgZGF0YSB0eXBlcywgYXMKICAgd2VsbCBhcyBhIHRhZ2dpbmcgbWVjaGFuaXNtIHRoYXQg ZW5hYmxlcyBleHRlbmRpbmcgdGhlIHNldCBvZiBkYXRhCiAgIHR5cGVzIHN1cHBvcnRlZCB2aWEg YW4gSUFOQSByZWdpc3RyeS4KCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgQ0JPUiB0 YWcgZm9yIGEgdGV4dCBzdHJpbmcgcmVwcmVzZW50aW5nCiAgIGEgZGF0ZSB3aXRob3V0IGEgdGlt ZS4gIFRoZSB0YWdnZWQgdGV4dCBzdHJpbmcgaXMgcmVwcmVzZW50ZWQgYXMKICAgc3BlY2lmaWVk IGJ5IHRoZSBSRkMgMzMzOSBbUkZDMzMzOV0gImZ1bGwtZGF0ZSIgcHJvZHVjdGlvbi4gIFBlciBS RkMKICAgMzMzOSwgdGhpcyByZXByZXNlbnRzIGEgZGF0ZSB3aXRoaW4gdGhlIEdyZWdvcmlhbiBj YWxlbmRhci4KCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBhbHNvIGRlZmluZXMgYSBDQk9SIHRhZyBm b3IgYW4gaW50ZWdlcgogICByZXByZXNlbnRpbmcgYSBkYXRlIHdpdGhvdXQgYSB0aW1lLiAgVGhl IHRhZ2dlZCBpbnRlZ2VyIGlzIGFuCiAgIHVuc2lnbmVkIG9yIG5lZ2F0aXZlIHZhbHVlIGluZGlj YXRpbmcgdGhlIG51bWJlciBvZiBkYXlzIHNpbmNlIHRoZQoKCgpKb25lcywgZXQgYWwuICAgICAg ICAgICBFeHBpcmVzIEphbnVhcnkgMTUsIDIwMjEgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQ0JPUiBUYWcgZm9yIERhdGUgICAgICAgICAgICAg ICAgICBKdWx5IDIwMjAKCgogICBHcmVnb3JpYW4gY2FsZW5kYXIgZGF0ZSAxOTcwLTAxLTAxLiAg QXMgYW4gaW1wbGVtZW50YXRpb24gbm90ZSwgdGhpcwogICB2YWx1ZSBoYXMgYSBjb25zdGFudCBv ZmZzZXQgZnJvbSB0aGUgTW9kaWZpZWQgSnVsaWFuIERhdGUgdmFsdWUKICAgKHdoaWNoIGlzIGRl ZmluZWQgYnkgdGhlIFNtaXRoc29uaWFuIEFzdHJvcGh5c2ljYWwgT2JzZXJ2YXRvcnkgYXMgdGhl CiAgIG51bWJlciBvZiBkYXlzIHNpbmNlIE5vdmVtYmVyIDE3LCAxODU4KTsgdGhpcyB2YWx1ZSBp cyB0aGUgTW9kaWZpZWQKICAgSnVsaWFuIERhdGUgbWludXMgNDA1ODcuCgogICBOb3RlIHRoYXQg c2luY2UgYm90aCB0YWdzIGFyZSBmb3IgZGF0ZXMgd2l0aG91dCB0aW1lcywgdGltZXMgb2YgZGF5 LAogICB0aW1lIHpvbmVzLCBhbmQgbGVhcCBzZWNvbmRzIGFyZSBub3QgYXBwbGljYWJsZSB0byB0 aGVzZSB2YWx1ZXMuCiAgIFRoZXNlIHRhZ3MgYXJlIGJvdGggZm9yIHJlcHJlc2VudGF0aW9ucyBv ZiBHcmVnb3JpYW4gY2FsZW5kYXIgZGF0ZXMuCgoxLjEuICBDYWxlbmRhciBEYXRlcwoKICAgQ2Fs ZW5kYXIgZGF0ZXMgYXJlIHVzZWQgZm9yIG51bWVyb3VzIGh1bWFuIHVzZSBjYXNlcywgc3VjaCBh cyBtYXJraW5nCiAgIHRoZSBkYXRlcyBvZiBzaWduaWZpY2FudCBldmVudHMuICBGb3IgaW5zdGFu Y2UsIEpvaG4gTGVubm9uIHdhcyBib3JuCiAgIG9uIE9jdG9iZXIgOSwgMTk0MCBhbmQgZGllZCBv biBEZWNlbWJlciA4LCAxOTgwLiAgT25lIHN1Y2ggY29tbW9uIHVzZQogICBjYXNlIGlzIGRyaXZl cidzIGxpY2Vuc2VzLCB3aGljaCB0eXBpY2FsbHkgaW5jbHVkZSBhIGRhdGUgb2YgYmlydGguCiAg IFRoZSBkYXRlcyB1c2VkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiB1c2UgdGhlIEdyZWdvcmlhbiBj YWxlbmRhciwgYXMKICAgZG8gdGhvc2UgaW4gUkZDIDMzMzkgW1JGQzMzMzldLiAgVGhlIHRpbWUg em9uZXMgYW5kIGFjdHVhbCB0aW1lcyBvZgogICB0aGVzZSBldmVudHMgYXJlIGludGVudGlvbmFs bHkgbm90IHJlcHJlc2VudGVkIGluIHRoZSBjYWxlbmRhciBkYXRlLgoKICAgVGhlIGVwb2NoIGNo b3NlbiBmb3IgdGhlIHNlY29uZCB0YWcsIHdoaWNoIHJlcHJlc2VudHMgZGF5cyBzaW5jZSB0aGUK ICAgR3JlZ29yaWFuIGNhbGVuZGFyIGRhdGUgMTk3MC0wMS0wMSwgaXMgcmVsYXRlZCB0byB0aGUg SUVFRSBTdGQKICAgMTAwMy4xLCAyMDEzIEVkaXRpb24gW1BPU0lYLjFdIHRpbWUgZXBvY2ggMTk3 MC0wMS0wMVQwMDowMDowMFogVVRDCiAgIG9ubHkgaW5zb2ZhciBhcyBib3RoIGNvbnRhaW4gdGhl IGRhdGUgMTk3MC0wMS0wMS4gIFRoaXMgc2hvdWxkIG5vdCBiZQogICBjb25zdHJ1ZWQgYXMgaW5k aWNhdGluZyB0aGF0IGRhdGVzIHVzaW5nIHRoaXMgdGFnIHJlcHJlc2VudCBlaXRoZXIgYQogICBz cGVjaWZpYyB0aW1lIG9mIGRheSBhbmQvb3IgdGltZSB6b25lLgoKICAgVGhlIGRheSBvZiB0aGUg d2VlayAoU3VuZGF5LCBNb25kYXksIFR1ZXNkYXksIGV0Yy4pIGlzIG5vdCBleHBsaWNpdGx5CiAg IHJlcHJlc2VudGVkIGluIGVpdGhlciBvZiB0aGVzZSBkYXRlIGZvcm1hdHMuICBIb3dldmVyLCBk ZXRlcm1pbmlzdGljCiAgIGFsZ29yaXRobXMgdGhhdCBhcmUgYmV5b25kIHRoZSBzY29wZSBvZiB0 aGlzIHNwZWNpZmljYXRpb24gY2FuIGJlCiAgIHVzZWQgdG8gZGVyaXZlIHRoZSBkYXkgb2YgdGhl IHdlZWsgaW4gdGhlIEdyZWdvcmlhbiBjYWxlbmRhciBmcm9tCiAgIGRhdGVzIHJlcHJlc2VudGVk IGluIGJvdGggb2YgdGhlc2UgZm9ybWF0cy4KCjEuMi4gIENvbXBhcmluZyBEYXRlcwoKICAgQ29t cGFyaXNvbiBvZiBkYXRlcyBpbiAiZnVsbC1kYXRlIiBmb3JtYXQgY2FuIGJlIGFjY29tcGxpc2hl ZCBieQogICBub3JtYWwgc3RyaW5nIGNvbXBhcmlzb24sIHNpbmNlIGJ5IGRlc2lnbiwgdGhlIGRp Z2l0cyByZXByZXNlbnRpbmcKICAgdGhlIGRhdGUgYXJlIGluIGZpeGVkIGZvcm1hdCBhbmQgb3Jk ZXJlZCBmcm9tIG1vc3Qgc2lnbmlmaWNhbnQgdG8KICAgbGVhc3Qgc2lnbmlmaWNhbnQuICBDb21w YXJpc29uIG9mIG51bWVyaWMgZGF0ZXMgcmVwcmVzZW50aW5nIGRheXMKICAgc2luY2UgMTk3MC0w MS0wMSBjYW4gYmUgcGVyZm9ybWVkIGJ5IG5vcm1hbCBpbnRlZ2VyIGNvbXBhcmlzb24uCiAgIENv bXBhcmlzb24gb2YgZGF0ZXMgaW4gb3RoZXIgZm9ybWF0cyBvciB1c2luZyBvdGhlciBjYWxlbmRh cnMgcmVxdWlyZQogICBjb252ZXJzaW9ucyB0aGF0IGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRo aXMgc3BlY2lmaWNhdGlvbi4KCjEuMy4gIENvbXBhcmluZyBEYXRlcyBhbmQgVGltZXMKCiAgIENv bXBhcmluZyBkYXRlcyB3aXRoIHRpbWVzIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVj aWZpY2F0aW9uLgogICBUaGF0IHNhaWQsIGlmIGEgZGF0ZSBpcyBhdWdtZW50ZWQgd2l0aCBhIHRp bWUgem9uZSBhbmQgdGltZSBvZiBkYXksCiAgIGNvbXBhcmluZyB0aGF0IGF1Z21lbnRlZCBkYXRl IHdpdGggb3RoZXIgdGltZXMgYmVjb21lcyBwb3NzaWJsZS4gIEZvcgoKCgpKb25lcywgZXQgYWwu ICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTUsIDIwMjEgICAgICAgICAgICAgICAgW1BhZ2Ug M10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQ0JPUiBUYWcgZm9yIERhdGUgICAgICAg ICAgICAgICAgICBKdWx5IDIwMjAKCgogICBpbnN0YW5jZSwgaWYgb25lIHdlcmUgdG8gYXVnbWVu dCBKb2huIExlbm5vbidzIGJpcnRoIGRhdGUgb2YgT2N0b2JlcgogICA5LCAxOTQwIHdpdGggdGhl IHRpbWUgb2YgZGF5IGFuZCB0aW1lIHpvbmUgb2YgaGlzIGJpcnRoLCB0aGVuIGl0CiAgIHdvdWxk IGJlIHBvc3NpYmxlIHRvIGRlcml2ZSBhIHRpbWUgYXQgd2hpY2ggaGUgd2FzIGJvcm4gdGhhdCBj b3VsZCBiZQogICBjb21wYXJlZCB3aXRoIG90aGVyIHRpbWVzLgoKMi4gIElBTkEgQ29uc2lkZXJh dGlvbnMKCjIuMS4gIENvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXByZXNlbnRhdGlvbiAoQ0JPUikg VGFncyBSZWdpc3RyYXRpb25zCgogICBUaGlzIHNlY3Rpb24gcmVnaXN0ZXJzIHRoZSBmb2xsb3dp bmcgdmFsdWVzIGluIHRoZSBJQU5BICJDb25jaXNlCiAgIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50 YXRpb24gKENCT1IpIFRhZ3MiIHJlZ2lzdHJ5IFtJQU5BLmNib3ItdGFnc10uCgogICBvICBUYWc6 IDEwMDQgKHZhbHVlIHJlcXVlc3RlZCkKICAgbyAgRGF0YSBJdGVtOiBVVEYtOCB0ZXh0IHN0cmlu ZwogICBvICBTZW1hbnRpY3M6IFJGQyAzMzM5IGZ1bGwtZGF0ZSBzdHJpbmcKICAgbyAgUmVmZXJl bmNlOiBbWyB0aGlzIHNwZWNpZmljYXRpb24gXV0KCiAgIG8gIFRhZzogMTAwIChBU0NJSSAnZCcp ICh2YWx1ZSByZXF1ZXN0ZWQpCiAgIG8gIERhdGEgSXRlbTogVW5zaWduZWQgb3IgbmVnYXRpdmUg aW50ZWdlcgogICBvICBTZW1hbnRpY3M6IE51bWJlciBvZiBkYXlzIHNpbmNlIHRoZSBlcG9jaCBk YXRlIDE5NzAtMDEtMDEKICAgbyAgUmVmZXJlbmNlOiBbWyB0aGlzIHNwZWNpZmljYXRpb24gXV0K CjMuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIG9mIFJGQyA3MDQ5IGFwcGx5OyB0aGUgdGFncyBpbnRyb2R1Y2VkCiAgIGhlcmUgYXJlIG5v dCBleHBlY3RlZCB0byByYWlzZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBiZXlvbmQgdGhvc2Uu CgogICBBIGRhdGUsIG9mIGNvdXJzZSwgaGFzIHNpZ25pZmljYW50IHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zLiAgVGhlc2UKICAgaW5jbHVkZSB0aGUgZXhwbG9pdGF0aW9uIG9mIGFtYmlndWl0aWVz IHdoZXJlIHRoZSBkYXRlIGlzIHNlY3VyaXR5CiAgIHJlbGV2YW50IG9yIHdoZXJlIHRoZSBkYXRl IGlzIHVzZWQgaW4gYWNjZXNzIGNvbnRyb2wgZGVjaXNpb25zLgoKICAgV2hlbiB1c2luZyBhIGNh bGVuZGFyIGRhdGUgZm9yIGRlY2lzaW9uIG1ha2luZywgZm9yIGV4YW1wbGUgYWNjZXNzCiAgIGNv bnRyb2wsIGl0IG5lZWRzIHRvIGJlIG5vdGVkIHRoYXQgc2luY2UgY2FsZW5kYXIgZGF0ZXMgZG8g bm90CiAgIHJlcHJlc2VudCBhIHNwZWNpZmljIHBvaW50IGluIHRpbWUsIHRoZSByZXN1bHRzIG9m IHRoZSBldmFsdWF0aW9uIGNhbgogICBkaWZmZXIgZGVwZW5kaW5nIHVwb24gd2hlcmUgdGhlIGRl Y2lzaW9uIGlzIG1hZGUuICBGb3IgaW5zdGFuY2UsIGEKICAgcGVyc29uIG1heSBoYXZlIHJlYWNo ZWQgdGhlaXIgMjFzdCBiaXJ0aGRheSBpbiBKYXBhbiB3aGlsZQogICBzaW11bHRhbmVvdXNseSBi ZWluZyBhIGRheSBzaG9ydCBvZiB0aGVpciAyMXN0IGJpcnRoZGF5IGluIEhhd2FpaS4KCjQuICBS ZWZlcmVuY2VzCgo0LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzMzMzldICBLbHlu ZSwgRy4gYW5kIEMuIE5ld21hbiwgIkRhdGUgYW5kIFRpbWUgb24gdGhlIEludGVybmV0OgogICAg ICAgICAgICAgIFRpbWVzdGFtcHMiLCBSRkMgMzMzOSwgRE9JIDEwLjE3NDg3L1JGQzMzMzksIEp1 bHkgMjAwMiwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9y ZmMzMzM5Pi4KCgoKCgoKSm9uZXMsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDE1 LCAyMDIxICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIENCT1IgVGFnIGZvciBEYXRlICAgICAgICAgICAgICAgICAgSnVseSAyMDIwCgoKICAgW1JG QzcwNDldICBCb3JtYW5uLCBDLiBhbmQgUC4gSG9mZm1hbiwgIkNvbmNpc2UgQmluYXJ5IE9iamVj dAogICAgICAgICAgICAgIFJlcHJlc2VudGF0aW9uIChDQk9SKSIsIFJGQyA3MDQ5LCBET0kgMTAu MTc0ODcvUkZDNzA0OSwKICAgICAgICAgICAgICBPY3RvYmVyIDIwMTMsIDxodHRwczovL3d3dy5y ZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzcwNDk+LgoKNC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNl cwoKICAgW0lBTkEuY2Jvci10YWdzXQogICAgICAgICAgICAgIElBTkEsICJDb25jaXNlIEJpbmFy eSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENCT1IpIFRhZ3MiLAogICAgICAgICAgICAgIDxodHRw Oi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2Nib3ItdGFncz4uCgogICBbUE9TSVguMV0gIElF RUUsICJUaGUgT3BlbiBHcm91cCBCYXNlIFNwZWNpZmljYXRpb25zIElzc3VlIDciLAogICAgICAg ICAgICAgIElFRUUgU3RkIDEwMDMuMSwgMjAxMyBFZGl0aW9uLCAyMDEzLAogICAgICAgICAgICAg IDxodHRwOi8vcHVicy5vcGVuZ3JvdXAub3JnL29ubGluZXB1YnMvOTY5OTkxOTc5OS9iYXNlZGVm cy8KICAgICAgICAgICAgICBWMV9jaGFwMDQuaHRtbCN0YWdfMDRfMTU+LgoKQWNrbm93bGVkZ2Vt ZW50cwoKICAgVGhhbmtzIHRvIENhcnN0ZW4gQm9ybWFubiBmb3Igc3VwcG9ydGluZyBjcmVhdGlv biBvZiB0aGlzCiAgIHNwZWNpZmljYXRpb24uICBQYXJ0cyBvZiB0aGUgZXhwbGFuYXRvcnkgdGV4 dCBpbiB0aGlzIHNwZWNpZmljYXRpb24KICAgY29tZSBmcm9tIGRyYWZ0LWJvcm1hbm4tY2Jvci10 aW1lLXRhZy0wMi4KCiAgIFRoYW5rcyB0byB0aGVzZSBwZW9wbGUgZm9yIHJldmlld3Mgb2YgdGhl IHNwZWNpZmljYXRpb246IEhlbmsKICAgQmlya2hvbHosIENhcnN0ZW4gQm9ybWFubiwgVGhpYWdv IE1hY2llaXJhLCBGcmFuY2VzY2EgUGFsb21iaW5pLAogICBNaWNoYWVsIFJpY2hhcmRzb24sIEpp bSBTY2hhYWQsIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciwgYW5kIERhbGUKICAgV29ybGV5LgoKRG9j dW1lbnQgSGlzdG9yeQoKICAgW1sgdG8gYmUgcmVtb3ZlZCBieSB0aGUgUkZDIEVkaXRvciBiZWZv cmUgcHVibGljYXRpb24gYXMgYW4gUkZDIF1dCgogICAtMDQKCiAgIG8gIEFkZHJlc3NlZCBzaGVw aGVyZCBjb21tZW50cyBieSBGcmFuY2VzY2EgUGFsb21iaW5pLgoKICAgbyAgQWRkcmVzc2VkIGFk ZGl0aW9uYWwgcmV2aWV3IGNvbW1lbnRzIGJ5IEppbSBTY2hhYWQgYW5kIE1pY2hhZWwKICAgICAg UmljaGFyZHNvbi4KCiAgIC0wMwoKICAgbyAgQWRkZWQgc3RhdGVtZW50IHRoYXQgdGhlc2UgdGFn cyBhcmUgYm90aCBmb3IgcmVwcmVzZW50YXRpb25zIG9mCiAgICAgIGNhbGVuZGFyIGRhdGVzLgoK ICAgbyAgRGVzY3JpYmVkIGNvbnNlcXVlbmNlcyBvZiB1c2luZyBjYWxlbmRhciBkYXRlcyBpbiBh Y2Nlc3MgY29udHJvbAogICAgICBkZWNpc2lvbnMuCgogICAtMDIKCgoKCgpKb25lcywgZXQgYWwu ICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTUsIDIwMjEgICAgICAgICAgICAgICAgW1BhZ2Ug NV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQ0JPUiBUYWcgZm9yIERhdGUgICAgICAg ICAgICAgICAgICBKdWx5IDIwMjAKCgogICBvICBBZGRyZXNzZWQgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgY29tbWVudHMsIGluY2x1ZGluZyBzdGF0aW5nIHRoYXQKICAgICAgdGltZSB6b25lcyBh cmUgbm90IGFwcGxpY2FibGUgdG8gdGhlc2UgdmFsdWVzLgoKICAgLTAxCgogICBvICBDaGFuZ2Vk ICJwb3NpdGl2ZSBvciBuZWdhdGl2ZSIgdG8gInVuc2lnbmVkIG9yIG5lZ2F0aXZlIi4KCiAgIG8g IEFkZGVkIGFuIGltcGxlbWVudGF0aW9uIG5vdGUgYWJvdXQgdGhlIHJlbGF0aW9uc2hpcCB0byBN b2RpZmllZAogICAgICBKdWxpYW4gRGF0ZXMuCgogICAtMDAKCiAgIG8gIEluaXRpYWwgd29ya2lu ZyBncm91cCB2ZXJzaW9uIGJhc2VkIG9uIGRyYWZ0LWpvbmVzLWNib3ItZGF0ZS0KICAgICAgdGFn LTAxIHdpdGggbm8gbm9ybWF0aXZlIGNoYW5nZXMuCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIE1p Y2hhZWwgQi4gSm9uZXMKICAgTWljcm9zb2Z0CgogICBFbWFpbDogbWJqQG1pY3Jvc29mdC5jb20K ICAgVVJJOiAgIGh0dHBzOi8vc2VsZi1pc3N1ZWQuaW5mby8KCgogICBBbnRob255IE5hZGFsaW4K ICAgTWljcm9zb2Z0CgogICBFbWFpbDogdG9ueW5hZEBtaWNyb3NvZnQuY29tCgoKICAgSm9lcmcg UmljaHRlcgogICBwZHYgRmluYW5jaWFsIFNvZnR3YXJlIEdtYkgKCiAgIEVtYWlsOiBqb2VyZy5y aWNodGVyQHBkdi1mcy5kZQoKCgoKCgoKCgoKCgoKCgoKCkpvbmVzLCBldCBhbC4gICAgICAgICAg IEV4cGlyZXMgSmFudWFyeSAxNSwgMjAyMSAgICAgICAgICAgICAgICBbUGFnZSA2XQo= --_003_CH2PR00MB0678F71646775F42E509F36FF57E0CH2PR00MB0678namp_-- From nobody Tue Jul 14 20:25: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 EED053A0E03 for ; Tue, 14 Jul 2020 20:25:44 -0700 (PDT) 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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 xNWs4DkYRg0H for ; Tue, 14 Jul 2020 20:25:43 -0700 (PDT) Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) (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 46F5E3A0E02 for ; Tue, 14 Jul 2020 20:25:43 -0700 (PDT) Received: by mail-il1-f179.google.com with SMTP id t18so754448ilh.2 for ; Tue, 14 Jul 2020 20:25:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pBQDOku9pnjpqMdqvFPB4j0Qtc17FuHOnPX7Xm0TiUs=; b=A5Yrxg7snDkGmE5JNsIWaZwIYgMvzV4B6EbV0AS1ZqKneWHFOaU9kaU17sTIxnDVMY V9SPqAoK9mOz5cwbf9LMyXEoxT9vyhX7yLCbuxX1yrZIiPPsXZP31JoVKhRbRHrTmDxT cH8cj4qDBcfWg2Wru3b7MU32eNGOnpaM4QZLKw0pXM/KJpe4zGBnFoxsjVebwSw/hvj/ 1tfmFY/LuSY7ZpeiM8jeCSWZp4g/tqzld6VCun7VBwhhcgdjaZno1IqM6Fcawv0VlN0D 5+6wJekhYsY3qFEaYGsv90lJUHvOgKXCXsOdfroVXDNJmNDjfKLdKS/rNywoKZL6wifc 1qxw== X-Gm-Message-State: AOAM531jVZ3vlExK5Mlyv88DTOtR9ydlv3Y8AzK3raHiGtjDVyBfJNF6 NbXCMNdXnWMjtiL36v4CjrX+GZbUiE0YfgXWNOA= X-Google-Smtp-Source: ABdhPJzlwaesLVF7js4K9J0feWRX1HPJxngh7DE90s1Qi9LvnVKNr+FpT4tXMFM8dM27x818jskv8+C+etYsx5KasbI= X-Received: by 2002:a92:4983:: with SMTP id k3mr7611680ilg.275.1594783542345; Tue, 14 Jul 2020 20:25:42 -0700 (PDT) MIME-Version: 1.0 References: <8919FFEE-2A57-4C0D-975C-5B65B3CC3AE8@ericsson.com> In-Reply-To: From: Barry Leiba Date: Tue, 14 Jul 2020 23:25:31 -0400 Message-ID: To: Mike Jones Cc: Francesca Palombini , "cbor@ietf.org" Content-Type: multipart/alternative; boundary="00000000000089094805aa727adc" Archived-At: Subject: Re: [Cbor] Review of draft-ietf-cbor-date-tag-03 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 03:25:45 -0000 --00000000000089094805aa727adc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I can do that, but submissions will re-open on Monday of IETF week anyway. Do we really need it posted before then, or should we just wait for the blackout period to end normally? It=E2=80=99s not long to wait. Personally, I thing we should get rid of the blackout, and let WGCs impose their own deadlines for meetings as appropriate. But every time we suggest that, the chairs, almost en bloc, insist that they want the IESG to impose the deadline. Barry On Tue, Jul 14, 2020 at 10:27 PM Mike Jones wrote: > Shoot - I finished preparing -04 to address your comments and those of > others, only to discover that submission is presently closed (as happens > before IETF meetings). I'm attaching the source and .txt version of -04. > If the chairs or AD choose to, maybe you can pull whatever strings you ne= ed > to with the secretariat to get it posted anyway. (I know Kathleen did th= at > for me at least once while she was an area director.) > > Thanks, > -- Mike > > -----Original Message----- > From: Francesca Palombini 40ericsson.com@dmarc.ietf.org> > Sent: Thursday, July 9, 2020 7:07 AM > To: Mike Jones ; cbor@ietf.org > Subject: [EXTERNAL] Review of draft-ietf-cbor-date-tag-03 > > Hi Mike, > > While reviewing for the shepherd writeup I found the following minor > issues: > > Section 1: > I would suggest removing the comma from the number: 40,587. Using the > comma as separator is not the best, as in some countries it is used as > decimal sign (also not preferred but allowed in ISO 8601). > > From I-D nits: > =3D=3D The document doesn't use any RFC 2119 keywords, yet seems to hav= e RFC > 2119 boilerplate text. > Is it necessary to have the 2119 - 8174 boilerplate text even if no > normative keywords are used? > > [POSIX.1] seems more like a normative reference to me, don't you think? > > Thanks, > Francesca > > --00000000000089094805aa727adc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can do that, but submissions will re-open on Monda= y of IETF week anyway.=C2=A0 Do we really need it posted before then, or sh= ould we just wait for the blackout period to end normally? It=E2=80=99s not= long to wait.

Per= sonally, I thing we should get rid of the blackout, and let WGCs impose the= ir own deadlines for meetings as appropriate. But every time we suggest tha= t, the chairs, almost en bloc, insist that they want the IESG to impose the= deadline.

Barry

On = Tue, Jul 14, 2020 at 10:27 PM Mike Jones <Michael.Jones@microsoft.com> wrote:
Shoot - I finished preparing -04 to address your c= omments and those of others, only to discover that submission is presently = closed (as happens before IETF meetings).=C2=A0 I'm attaching the sourc= e and .txt version of -04.=C2=A0 If the chairs or AD choose to, maybe you c= an pull whatever strings you need to with the secretariat to get it posted = anyway.=C2=A0 (I know Kathleen did that for me at least once while she was = an area director.)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

-----Original Message-----
From: Francesca Palombini <francesca.palombini=3D40ericsson.com@dmarc.ietf.org>
Sent: Thursday, July 9, 2020 7:07 AM
To: Mike Jones <Michael.Jones@microsoft.com>; cbor@ietf.org
Subject: [EXTERNAL] Review of draft-ietf-cbor-date-tag-03

Hi Mike,

While reviewing for the shepherd writeup I found the following minor issues= :

Section 1:
I would suggest removing the comma from the number: 40,587. Using the comma= as separator is not the best, as in some countries it is used as decimal s= ign (also not preferred but allowed in ISO 8601).

>From I-D nits:
=C2=A0 =3D=3D The document doesn't use any RFC 2119 keywords, yet seems= to have RFC
=C2=A0 =C2=A0 =C2=A02119 boilerplate text.
Is it necessary to have the 2119 - 8174 boilerplate text even if no normati= ve keywords are used?

[POSIX.1] seems more like a normative reference to me, don't you think?=

Thanks,
Francesca

--00000000000089094805aa727adc-- From nobody Tue Jul 14 22: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 48FCF3A0544 for ; Tue, 14 Jul 2020 22:31:22 -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 1_MDG-ldKVOc for ; Tue, 14 Jul 2020 22:31:20 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640137.outbound.protection.outlook.com [40.107.64.137]) (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 2F3043A0542 for ; Tue, 14 Jul 2020 22:31:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QYWyOT+HsUAM4p6b8D85cR2ODA2SZ8VwfDNNHj55WS7OlOcxSv9971NueQK2Q8bPxCvFdlAJm79jp5fIlp48yv5/MgLdL/7RqT/06/+sw2W+bMrdG7lQn1lvklsvZZ5kolfJbZdQ4m+4RFlf//nevFLK1ASEke2ZzQ9MkOU/qveYQCbYuwSUEacBQx0r1XN3HMhYSt3qo/BkV1vA/R2dklmYZXuL+PW2Upts6fn/5VFbiAaNixQFzfbkk1FuJEchbrH4cMtUKcfaymYlgqZFton4mcl8RCaGUhsMDNOUL7qxJmlgKrgTrW4iWuVxN1du4BJ9xNYfWppMd9+qvvALDw== 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=DAVqeawaJvL5OUeJoYbRNFc564Z20/vbDjhZcvCcizM=; b=k8wf2CRlA23LgqtokT4jCKxgl4iZq0ScHKA6GbsfCZH6kYHS7Gbm6fotZpPCY82x86xy9vaAMfhq6RMQX2Gzt07vPU9a6Q1tZsJ/fTngZ6YS+8qxCMMDefKkSRmWkSMrwog4Hw2q6XdKDdbxjhVQKHd1XOfaxUh5bds05pUbEufMdKHx6m7xZDyWkbMS26T1nXQYbcTLV+WIozhlslUiDrW9nplKxHmlSs20l/1VfgrUPmmMdo4Wti6RjielFPxrdiJ30x9z7VmtXo7UDKavE8pIk3Ji3alYuOv8buuhtC7xwp+TKa4FnwHnJ/ORRPo6n57k6gOFAorC9d4ddh5R+A== 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=DAVqeawaJvL5OUeJoYbRNFc564Z20/vbDjhZcvCcizM=; b=L5DBq/H9IJHCxN3q/3YAyMAY8nkRoxjI5WcoKEVx+712C4ZB0VaONAr4JlhjrOrnk6V9U+xqIoTQf+JQdGLUcrxw7BFQJrPFyINhH6kXTgmzqLxkF+WsogS5AzLY2Lzl2e/IePkny0UD+PDDZvDI6BIfkiCHY1AkN55NKbCTwe0= Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0795.namprd00.prod.outlook.com (2603:10b6:610:6f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3235.0; Wed, 15 Jul 2020 05:31:08 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::29f8:dc4a:8aac:e889]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::29f8:dc4a:8aac:e889%8]) with mapi id 15.20.3235.000; Wed, 15 Jul 2020 05:31:08 +0000 From: Mike Jones To: Barry Leiba CC: Francesca Palombini , "cbor@ietf.org" Thread-Topic: Review of draft-ietf-cbor-date-tag-03 Thread-Index: AdZaaSIReqHFz/vXSVaacx+7UY+10w== Date: Wed, 15 Jul 2020 05:31:08 +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_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-15T05:29:37Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=709a5f56-38a2-4c70-91e6-d76dcbde9e4a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: computer.org; dkim=none (message not signed) header.d=none; computer.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 83ec3dd1-5054-4014-b135-08d8288046db x-ms-traffictypediagnostic: CH2PR00MB0795: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: i2Kb2zmZI9X9uPkdEESEfDbSabVuNwqpNzsc6BTtwzK4I+gbYEMpjUVyW/Co/fxrOwLEB9K5rJVxOL4yX+M2/bKi66UNqjvrRQLdlQVd6zLDl26ZigFzaoa6PrrrgxD9fkE+tUK+Ec+aSdYl2MT6O+l35UdEcnhSarTAUi7YCqXY4iuUG7wMBSElK9pBbVE+VvyOE79XZzzQAUvt5UoJ3EbblYnjo1hAzuibLCd9DiG9FvBSuA9EWa/BAH054uCLyZUoKVtbKZWX8BKKJNg0CLMoMK8U7yft+6k9VzDHfWhsCXvOKJ2fBo0sgj54A6ZiNqz1I5YGdColKi7WeYby0A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(39860400002)(376002)(136003)(346002)(478600001)(4326008)(55016002)(6916009)(2906002)(66946007)(66446008)(64756008)(66556008)(66476007)(76116006)(10290500003)(54906003)(316002)(9686003)(7696005)(53546011)(6506007)(26005)(186003)(52536014)(8936002)(5660300002)(33656002)(82950400001)(82960400001)(8990500004)(86362001)(83380400001)(8676002)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: nbHFFOuWOuojsow7gNSbsIfjA85EWLLhE3D8kvOaedlM+eU06OoOMle3JfaxOUBDka1qcpSyXlLdsOiCFOMwOeL12tdGdIZF/5+xoPlBWWlDpl7L2Xxbk8x0avFh53riIBPuW/hlTvp4qHksimSAHF+Z8NXI6iy+oUzUBOiLE6GPZzFVss6wal7C3Kd/6Ump2VjpZyEY6Ym3fAlgzfZiMOXSOuyOZO71fbvanJwaZbFASMBfArbG9EIOfpjWC5ASknAGqO4GXgexkXkqsxCiwOSf+Vy5rdAjvGiNdH+2FLZnZlC7v8tSix12IHHpwNk7COQ3Z2GKdRhvATHvmKe6sabo7zWgtyLqltOetMxhH6s4hW4Z+tDmHk/e0cThpiQ+ZqWirJYYPWnvsYpTNu5+tuvZffO9aI1d4o8y0G1LhIK+7Ig4Pkf1AXzVb0hgQjTDKuYIopkTxLfjmVjJ4N2rhM9MffOjKrNVoXlFZPS0Zt6iwNu97hGqXl7Z0xt9OhSdsA+hy/uhqRmz03ea3QhGpuSKkruj4UNzWjxcXH+P8D/1qm4sPFfDjdaRdCflBIY8R+iNcWL/Z+S5MkbKgisiu97X/A+rlhJIzQpqHac8iztv+dD61Xw7qEjHsw/NzlBi/7E+TMv0SkEj/Iae8WNzdQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0678B30369AE8AA831EA3B1CF57E0CH2PR00MB0678namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 83ec3dd1-5054-4014-b135-08d8288046db X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2020 05:31:08.1816 (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: qeHpmIaeD3Vg4QcD3gcJiW1VWHwjFtLmDnGRnObeP3iGCs21qQ4MVW3KB7JlX1R+NaggVpHk5AhI4U5MLuN/nw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0795 Archived-At: Subject: Re: [Cbor] Review of draft-ietf-cbor-date-tag-03 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 05:31:22 -0000 --_000_CH2PR00MB0678B30369AE8AA831EA3B1CF57E0CH2PR00MB0678namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmXigJlzIGEgQ0JPUiB3b3JraW5nIGdyb3VwIG1lZXRpbmcgYXQgOGFtIFBhY2lmaWMgVGlt ZSBpbiB0aGUgbW9ybmluZyAoV2VkbmVzZGF5LCBKdWx5IDE1dGgpLiAgSSB3YXMgd29ya2luZyB0 b2RheSB0b3dhcmRzIGhhdmluZyBpdCBwb3N0ZWQgYmVmb3JlIHRoZW4sIG5vdCByZWFsaXppbmcg d2Ugd2VyZSBpbiB0aGUgYmxhY2tvdXQgcGVyaW9kLiAgSWYgeW91IGNhbiBwb3N0IGl0IGJlZm9y ZSB0aGVuLCB0aGF0IHdvdWxkIGJlIGdyZWF0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmtzLA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogQmFy cnkgTGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPg0KU2VudDogVHVlc2RheSwgSnVseSAx NCwgMjAyMCA4OjI2IFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPg0KQ2M6IEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nz b24uY29tPjsgY2JvckBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFJldmlldyBvZiBkcmFmdC1pZXRm LWNib3ItZGF0ZS10YWctMDMNCg0KSSBjYW4gZG8gdGhhdCwgYnV0IHN1Ym1pc3Npb25zIHdpbGwg cmUtb3BlbiBvbiBNb25kYXkgb2YgSUVURiB3ZWVrIGFueXdheS4gIERvIHdlIHJlYWxseSBuZWVk IGl0IHBvc3RlZCBiZWZvcmUgdGhlbiwgb3Igc2hvdWxkIHdlIGp1c3Qgd2FpdCBmb3IgdGhlIGJs YWNrb3V0IHBlcmlvZCB0byBlbmQgbm9ybWFsbHk/IEl04oCZcyBub3QgbG9uZyB0byB3YWl0Lg0K DQpQZXJzb25hbGx5LCBJIHRoaW5nIHdlIHNob3VsZCBnZXQgcmlkIG9mIHRoZSBibGFja291dCwg YW5kIGxldCBXR0NzIGltcG9zZSB0aGVpciBvd24gZGVhZGxpbmVzIGZvciBtZWV0aW5ncyBhcyBh cHByb3ByaWF0ZS4gQnV0IGV2ZXJ5IHRpbWUgd2Ugc3VnZ2VzdCB0aGF0LCB0aGUgY2hhaXJzLCBh bG1vc3QgZW4gYmxvYywgaW5zaXN0IHRoYXQgdGhleSB3YW50IHRoZSBJRVNHIHRvIGltcG9zZSB0 aGUgZGVhZGxpbmUuDQoNCkJhcnJ5DQoNCk9uIFR1ZSwgSnVsIDE0LCAyMDIwIGF0IDEwOjI3IFBN IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpTaG9vdCAtIEkgZmluaXNoZWQgcHJlcGFyaW5n IC0wNCB0byBhZGRyZXNzIHlvdXIgY29tbWVudHMgYW5kIHRob3NlIG9mIG90aGVycywgb25seSB0 byBkaXNjb3ZlciB0aGF0IHN1Ym1pc3Npb24gaXMgcHJlc2VudGx5IGNsb3NlZCAoYXMgaGFwcGVu cyBiZWZvcmUgSUVURiBtZWV0aW5ncykuICBJJ20gYXR0YWNoaW5nIHRoZSBzb3VyY2UgYW5kIC50 eHQgdmVyc2lvbiBvZiAtMDQuICBJZiB0aGUgY2hhaXJzIG9yIEFEIGNob29zZSB0bywgbWF5YmUg eW91IGNhbiBwdWxsIHdoYXRldmVyIHN0cmluZ3MgeW91IG5lZWQgdG8gd2l0aCB0aGUgc2VjcmV0 YXJpYXQgdG8gZ2V0IGl0IHBvc3RlZCBhbnl3YXkuICAoSSBrbm93IEthdGhsZWVuIGRpZCB0aGF0 IGZvciBtZSBhdCBsZWFzdCBvbmNlIHdoaWxlIHNoZSB3YXMgYW4gYXJlYSBkaXJlY3Rvci4pDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmtzLA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pPTQwZXJpY3Nzb24u Y29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4+ DQpTZW50OiBUaHVyc2RheSwgSnVseSA5LCAyMDIwIDc6MDcgQU0NClRvOiBNaWtlIEpvbmVzIDxN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT4+OyBjYm9yQGlldGYub3JnPG1haWx0bzpjYm9yQGlldGYub3JnPg0KU3ViamVjdDogW0VY VEVSTkFMXSBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTAzDQoNCkhpIE1pa2Us DQoNCldoaWxlIHJldmlld2luZyBmb3IgdGhlIHNoZXBoZXJkIHdyaXRldXAgSSBmb3VuZCB0aGUg Zm9sbG93aW5nIG1pbm9yIGlzc3VlczoNCg0KU2VjdGlvbiAxOg0KSSB3b3VsZCBzdWdnZXN0IHJl bW92aW5nIHRoZSBjb21tYSBmcm9tIHRoZSBudW1iZXI6IDQwLDU4Ny4gVXNpbmcgdGhlIGNvbW1h IGFzIHNlcGFyYXRvciBpcyBub3QgdGhlIGJlc3QsIGFzIGluIHNvbWUgY291bnRyaWVzIGl0IGlz IHVzZWQgYXMgZGVjaW1hbCBzaWduIChhbHNvIG5vdCBwcmVmZXJyZWQgYnV0IGFsbG93ZWQgaW4g SVNPIDg2MDEpLg0KDQpGcm9tIEktRCBuaXRzOg0KICA9PSBUaGUgZG9jdW1lbnQgZG9lc24ndCB1 c2UgYW55IFJGQyAyMTE5IGtleXdvcmRzLCB5ZXQgc2VlbXMgdG8gaGF2ZSBSRkMNCiAgICAgMjEx OSBib2lsZXJwbGF0ZSB0ZXh0Lg0KSXMgaXQgbmVjZXNzYXJ5IHRvIGhhdmUgdGhlIDIxMTkgLSA4 MTc0IGJvaWxlcnBsYXRlIHRleHQgZXZlbiBpZiBubyBub3JtYXRpdmUga2V5d29yZHMgYXJlIHVz ZWQ/DQoNCltQT1NJWC4xXSBzZWVtcyBtb3JlIGxpa2UgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRv IG1lLCBkb24ndCB5b3UgdGhpbms/DQoNClRoYW5rcywNCkZyYW5jZXNjYQ0K --_000_CH2PR00MB0678B30369AE8AA831EA3B1CF57E0CH2PR00MB0678namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAy MDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPlRoZXJl4oCZcyBhIENCT1Igd29ya2luZyBncm91cCBtZWV0aW5nIGF0IDhhbSBQYWNpZmlj IFRpbWUgaW4gdGhlIG1vcm5pbmcgKFdlZG5lc2RheSwgSnVseSAxNTxzdXA+dGg8L3N1cD4pLiZu YnNwOyBJIHdhcyB3b3JraW5nIHRvZGF5IHRvd2FyZHMgaGF2aW5nIGl0IHBvc3RlZCBiZWZvcmUg dGhlbiwgbm90IHJlYWxpemluZyB3ZSB3ZXJlIGluIHRoZSBibGFja291dCBwZXJpb2QuJm5ic3A7 DQogSWYgeW91IGNhbiBwb3N0IGl0IGJlZm9yZSB0aGVuLCB0aGF0IHdvdWxkIGJlIGdyZWF0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEJhcnJ5IExlaWJhICZsdDtiYXJyeWxlaWJhQGNvbXB1 dGVyLm9yZyZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMTQsIDIwMjAgODoy NiBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gRnJhbmNlc2NhIFBhbG9tYmluaSAmbHQ7ZnJhbmNl c2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20mZ3Q7OyBjYm9yQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTAzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGNhbiBkbyB0aGF0LCBi dXQgc3VibWlzc2lvbnMgd2lsbCByZS1vcGVuIG9uIE1vbmRheSBvZiBJRVRGIHdlZWsgYW55d2F5 LiZuYnNwOyBEbyB3ZSByZWFsbHkgbmVlZCBpdCBwb3N0ZWQgYmVmb3JlIHRoZW4sIG9yIHNob3Vs ZCB3ZSBqdXN0IHdhaXQgZm9yIHRoZSBibGFja291dCBwZXJpb2QgdG8gZW5kIG5vcm1hbGx5PyBJ dOKAmXMgbm90IGxvbmcgdG8gd2FpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXJzb25hbGx5LCBJIHRoaW5nIHdlIHNob3Vs ZCBnZXQgcmlkIG9mIHRoZSBibGFja291dCwgYW5kIGxldCBXR0NzIGltcG9zZSB0aGVpciBvd24g ZGVhZGxpbmVzIGZvciBtZWV0aW5ncyBhcyBhcHByb3ByaWF0ZS4gQnV0IGV2ZXJ5IHRpbWUgd2Ug c3VnZ2VzdCB0aGF0LCB0aGUgY2hhaXJzLCBhbG1vc3QgZW4gYmxvYywgaW5zaXN0IHRoYXQgdGhl eSB3YW50IHRoZSBJRVNHIHRvIGltcG9zZSB0aGUgZGVhZGxpbmUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhcnJ5PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKdWwgMTQsIDIw MjAgYXQgMTA6MjcgUE0gTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlNob290IC0gSSBmaW5pc2hlZCBwcmVw YXJpbmcgLTA0IHRvIGFkZHJlc3MgeW91ciBjb21tZW50cyBhbmQgdGhvc2Ugb2Ygb3RoZXJzLCBv bmx5IHRvIGRpc2NvdmVyIHRoYXQgc3VibWlzc2lvbiBpcyBwcmVzZW50bHkgY2xvc2VkIChhcyBo YXBwZW5zIGJlZm9yZSBJRVRGIG1lZXRpbmdzKS4mbmJzcDsgSSdtIGF0dGFjaGluZyB0aGUgc291 cmNlIGFuZCAudHh0IHZlcnNpb24NCiBvZiAtMDQuJm5ic3A7IElmIHRoZSBjaGFpcnMgb3IgQUQg Y2hvb3NlIHRvLCBtYXliZSB5b3UgY2FuIHB1bGwgd2hhdGV2ZXIgc3RyaW5ncyB5b3UgbmVlZCB0 byB3aXRoIHRoZSBzZWNyZXRhcmlhdCB0byBnZXQgaXQgcG9zdGVkIGFueXdheS4mbmJzcDsgKEkg a25vdyBLYXRobGVlbiBkaWQgdGhhdCBmb3IgbWUgYXQgbGVhc3Qgb25jZSB3aGlsZSBzaGUgd2Fz IGFuIGFyZWEgZGlyZWN0b3IuKTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGFua3MsPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tIE1pa2U8YnI+DQo8YnI+ DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IEZyYW5jZXNjYSBQYWxvbWJp bmkgJmx0O2ZyYW5jZXNjYS5wYWxvbWJpbmk9PGEgaHJlZj0ibWFpbHRvOjQwZXJpY3Nzb24uY29t QGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0 Zi5vcmc8L2E+Jmd0Ow0KPGJyPg0KU2VudDogVGh1cnNkYXksIEp1bHkgOSwgMjAyMCA3OjA3IEFN PGJyPg0KVG86IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpjYm9yQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ Y2JvckBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFJldmlldyBvZiBkcmFm dC1pZXRmLWNib3ItZGF0ZS10YWctMDM8YnI+DQo8YnI+DQpIaSBNaWtlLDxicj4NCjxicj4NCldo aWxlIHJldmlld2luZyBmb3IgdGhlIHNoZXBoZXJkIHdyaXRldXAgSSBmb3VuZCB0aGUgZm9sbG93 aW5nIG1pbm9yIGlzc3Vlczo8YnI+DQo8YnI+DQpTZWN0aW9uIDE6PGJyPg0KSSB3b3VsZCBzdWdn ZXN0IHJlbW92aW5nIHRoZSBjb21tYSBmcm9tIHRoZSBudW1iZXI6IDQwLDU4Ny4gVXNpbmcgdGhl IGNvbW1hIGFzIHNlcGFyYXRvciBpcyBub3QgdGhlIGJlc3QsIGFzIGluIHNvbWUgY291bnRyaWVz IGl0IGlzIHVzZWQgYXMgZGVjaW1hbCBzaWduIChhbHNvIG5vdCBwcmVmZXJyZWQgYnV0IGFsbG93 ZWQgaW4gSVNPIDg2MDEpLjxicj4NCjxicj4NCkZyb20gSS1EIG5pdHM6PGJyPg0KJm5ic3A7ID09 IFRoZSBkb2N1bWVudCBkb2Vzbid0IHVzZSBhbnkgUkZDIDIxMTkga2V5d29yZHMsIHlldCBzZWVt cyB0byBoYXZlIFJGQzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7MjExOSBib2lsZXJwbGF0ZSB0 ZXh0Ljxicj4NCklzIGl0IG5lY2Vzc2FyeSB0byBoYXZlIHRoZSAyMTE5IC0gODE3NCBib2lsZXJw bGF0ZSB0ZXh0IGV2ZW4gaWYgbm8gbm9ybWF0aXZlIGtleXdvcmRzIGFyZSB1c2VkPw0KPGJyPg0K PGJyPg0KW1BPU0lYLjFdIHNlZW1zIG1vcmUgbGlrZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8g bWUsIGRvbid0IHlvdSB0aGluaz88YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KRnJhbmNlc2NhPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_CH2PR00MB0678B30369AE8AA831EA3B1CF57E0CH2PR00MB0678namp_-- From nobody Wed Jul 15 04:55: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 28A363A0C98 for ; Wed, 15 Jul 2020 04:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 zUmOpeRltFfU for ; Wed, 15 Jul 2020 04:54:56 -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 AA2163A0C99 for ; Wed, 15 Jul 2020 04:54:55 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B6G5p0jsWzyZ6; Wed, 15 Jul 2020 13:54:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Wed, 15 Jul 2020 13:54:53 +0200 Cc: Francesca Palombini , "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 616506893.379796-fcc88ecf1239ee037ea42f8ef3f6ebc9 Content-Transfer-Encoding: quoted-printable Message-Id: <02CA6845-D665-4AE7-9ACB-12566886CE6C@tzi.org> References: <8919FFEE-2A57-4C0D-975C-5B65B3CC3AE8@ericsson.com> To: Mike Jones X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Review of draft-ietf-cbor-date-tag-03 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 11:54:59 -0000 Hi Mike, (1) I like the John Lennon example. You could complete it by giving the Tag-1004 syntax, as well as the = Tag-100 numbers, both of which are visible in the following lines: >> Date.parse("1940-10-09").mjd-Date.parse("1970-01-01").mjd =3D> -10676 >> Date.parse("1980-12-08").mjd-Date.parse("1970-01-01").mjd =3D> 3994 (2) =E2=80=A6comparing that augmented date=E2=80=A6 Hmm, once you add a time-of-day, it is no longer just a =E2=80=9Cdate=E2=80= =9D, so I would speak about a date-time. Gr=C3=BC=C3=9Fe, Carsten > On 2020-07-15, at 04:27, Mike Jones = wrote: >=20 > Shoot - I finished preparing -04 to address your comments and those of = others, only to discover that submission is presently closed (as happens = before IETF meetings). I'm attaching the source and .txt version of = -04. If the chairs or AD choose to, maybe you can pull whatever strings = you need to with the secretariat to get it posted anyway. (I know = Kathleen did that for me at least once while she was an area director.) >=20 > Thanks, > -- Mike >=20 > -----Original Message----- > From: Francesca Palombini = =20 > Sent: Thursday, July 9, 2020 7:07 AM > To: Mike Jones ; cbor@ietf.org > Subject: [EXTERNAL] Review of draft-ietf-cbor-date-tag-03 >=20 > Hi Mike, >=20 > While reviewing for the shepherd writeup I found the following minor = issues: >=20 > Section 1: > I would suggest removing the comma from the number: 40,587. Using the = comma as separator is not the best, as in some countries it is used as = decimal sign (also not preferred but allowed in ISO 8601). >=20 > =46rom I-D nits: > =3D=3D The document doesn't use any RFC 2119 keywords, yet seems to = have RFC > 2119 boilerplate text. > Is it necessary to have the 2119 - 8174 boilerplate text even if no = normative keywords are used?=20 >=20 > [POSIX.1] seems more like a normative reference to me, don't you = think? >=20 > Thanks, > Francesca >=20 > = ________= _______________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Jul 15 08:01:05 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 456613A0DAC for ; Wed, 15 Jul 2020 08:01:03 -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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-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 TFbpU6031Adm for ; Wed, 15 Jul 2020 08:01:02 -0700 (PDT) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) (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 76DB03A0DA7 for ; Wed, 15 Jul 2020 08:00:59 -0700 (PDT) Received: by mail-io1-f41.google.com with SMTP id v8so2572848iox.2 for ; Wed, 15 Jul 2020 08:00:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EsoorXUmtnPIbfl9J9nz9vH20Ae2H1SkqjLldsXGZlU=; b=ia0ovRBOEwFRTkofTY65IC2RKEFHOJXebGAhAF5yRH4qxmnemUDbchsub3COObRDe3 0zgPIi8tPzViEdmSq4cpglV6/pV3DtdU3VNDeU2r2WYvRXoPN5swbyERspwQL/fBqKcZ rc6E2VuqFGakfOzU32eDP6dAh6aLzz6WcWL212HjL7amRkoaLZXmFU5aLLar9hvv+aND EyEDxy+xMJhv1mTT6J9sgXVNwRJTD4k+dNTcoP+1zSYR8A0cYdjqKAUs+viD7E4yvtaj 4U5IcJlzlN/VYhcBNookhiwLWuHlRCn8fSCdkiXm/VVXkicQxZzssee8wNOch/cF/2Iu zDvw== X-Gm-Message-State: AOAM532/use8w2xtCZTqtrNQEQmLSzhU+pmtzuJ1n2oxR9tNnP+oTlI9 O/crhB4wCmdm8WflVK7op+ak2aH+8EMMFgQFLUA= X-Google-Smtp-Source: ABdhPJyFAKQfnaHTX99ynKYu62ujfykazWSUT/L8WEQJj5zbSUMCzZ79bgBOFJvA1TyL5khuD314hw7SwwnjTTBpKqk= X-Received: by 2002:a6b:9042:: with SMTP id s63mr10700277iod.195.1594825258537; Wed, 15 Jul 2020 08:00:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Wed, 15 Jul 2020 11:00:47 -0400 Message-ID: To: Mike Jones Cc: Francesca Palombini , "cbor@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] Review of draft-ietf-cbor-date-tag-03 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 15:01:03 -0000 I'll ask the Secretariat now to post it, but given that the CBOR session is starting now, it's clearly not happening that quickly. Sorry. Barry On Wed, Jul 15, 2020 at 1:31 AM Mike Jones wr= ote: > > There=E2=80=99s a CBOR working group meeting at 8am Pacific Time in the m= orning (Wednesday, July 15th). I was working today towards having it poste= d before then, not realizing we were in the blackout period. If you can po= st it before then, that would be great. > > > > Thanks, > > -- Mike > > > > From: Barry Leiba > Sent: Tuesday, July 14, 2020 8:26 PM > To: Mike Jones > Cc: Francesca Palombini ; cbor@ietf.org > Subject: Re: Review of draft-ietf-cbor-date-tag-03 > > > > I can do that, but submissions will re-open on Monday of IETF week anyway= . Do we really need it posted before then, or should we just wait for the = blackout period to end normally? It=E2=80=99s not long to wait. > > > > Personally, I thing we should get rid of the blackout, and let WGCs impos= e their own deadlines for meetings as appropriate. But every time we sugges= t that, the chairs, almost en bloc, insist that they want the IESG to impos= e the deadline. > > > > Barry > > > > On Tue, Jul 14, 2020 at 10:27 PM Mike Jones = wrote: > > Shoot - I finished preparing -04 to address your comments and those of ot= hers, only to discover that submission is presently closed (as happens befo= re IETF meetings). I'm attaching the source and .txt version of -04. If t= he chairs or AD choose to, maybe you can pull whatever strings you need to = with the secretariat to get it posted anyway. (I know Kathleen did that fo= r me at least once while she was an area director.) > > Thanks, > -- Mike > > -----Original Message----- > From: Francesca Palombini > Sent: Thursday, July 9, 2020 7:07 AM > To: Mike Jones ; cbor@ietf.org > Subject: [EXTERNAL] Review of draft-ietf-cbor-date-tag-03 > > Hi Mike, > > While reviewing for the shepherd writeup I found the following minor issu= es: > > Section 1: > I would suggest removing the comma from the number: 40,587. Using the com= ma as separator is not the best, as in some countries it is used as decimal= sign (also not preferred but allowed in ISO 8601). > > From I-D nits: > =3D=3D The document doesn't use any RFC 2119 keywords, yet seems to hav= e RFC > 2119 boilerplate text. > Is it necessary to have the 2119 - 8174 boilerplate text even if no norma= tive keywords are used? > > [POSIX.1] seems more like a normative reference to me, don't you think? > > Thanks, > Francesca From nobody Wed Jul 15 08:03:49 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE39C3A0DBA for ; Wed, 15 Jul 2020 08:03:48 -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 UMxvXIk8ezth for ; Wed, 15 Jul 2020 08:03:47 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650122.outbound.protection.outlook.com [40.107.65.122]) (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 7FB4F3A0DAC for ; Wed, 15 Jul 2020 08:03:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n8ZFtcBmZReji7L9qTrRqlKceAgo1wx2LtF3LEehJrGM8YzJkcZPSJvJ5PloyTEUAkq7TnrQ2DQCmQTJMH5EwNLm9MKd5xcAUCo5JRvZiDdCIJ9KRI/P7oH7+bHRTOIIAc4v4lGrn1hrWp6XiImA4CaWsajgg+5y9BmwgadlIwanm2I7R08a+IzX36+EaWJc8R+rhwHWH/H/P+O41Ye0QexNu8X1UC2wiqrsuBJEOQNQzAQITNcP2983DrMQeqEqKA+mtWAlSOFNhL+c3i1CQ3hgNXXZUSvke/A/oohFYjSLaY9ODXfbt++MOHkcsBrAzN6ebBgoMS81MehVFvuPYg== 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=ubbfYEGxNGWF//8nrSmRzfP2j3At04y8h8MW04LDzco=; b=fphHCGzokWIB7ReoPQX+c0NejgcMn1ueX7wioW8teFfotPYa7j/p/Z8bWzxb+yCbsxaNydH48aUnNf21obTVuv2Un+wmr1WfbYE24IkstoIrJCqitcXUoWcQiDT++OcXRIn0FWp6wzfGeRJO53IcETX92LSYaMZNc8kGdt+eMDwjp3dNtKlhClivApN5xl45k+l6QMHT0nXRUSsqbfvCV7TXTUhKBU7PyNYXbIZyhFi8I20lz4KyjlQ+St2Ni/uPD97XqYMS6Qi9ig9ywXSXECSk7xnUHpjhmW5uawZN6f4vDCr07KKbQSnopK3j0YhNnP38ee+9Wxv24EgOCCBdUw== 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=ubbfYEGxNGWF//8nrSmRzfP2j3At04y8h8MW04LDzco=; b=FdPh2L9mYT9X44ysKMIHfPUeaNxFnJKb0EGDxGZwFdOyIrxYissL1vcmQhUCy1ppWBY2LtvCHOK2mqgdpUQGySf7GEATXkMD3hCDyKBM3FzJcaaxKWXafGPcyF2FNPUMVUNBfz1QNWXpupMIn/L8BWd9DIh7O+P7BHbmVPZ2kiI= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0654.namprd00.prod.outlook.com (2603:10b6:208:c7::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3233.0; Wed, 15 Jul 2020 15:03:44 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::2886:ee14:6806:ec4]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::2886:ee14:6806:ec4%4]) with mapi id 15.20.3236.000; Wed, 15 Jul 2020 15:03:44 +0000 From: Mike Jones To: Barry Leiba CC: Francesca Palombini , "cbor@ietf.org" Thread-Topic: Review of draft-ietf-cbor-date-tag-03 Thread-Index: AdZauR8UajovkyKWRh6s4oQhD5oZFA== Date: Wed, 15 Jul 2020 15:03:44 +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_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-15T15:03:18Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=b57b92f4-dd95-456e-9ee6-33aa34e4c7d6; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: computer.org; dkim=none (message not signed) header.d=none; computer.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0b7bc090-f1ec-47a6-09ef-08d828d044a8 x-ms-traffictypediagnostic: MN2PR00MB0654: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SdX5NRbmvhKHqQTYDjcAblgv0C+QJAMbVONKZcUEKAQbBJqZjpCm0lltLmdB0bzsMwy/Nrm5H18cmhC1EbVNai1hgMjIYvRjTPJNcrkwxilViyD49L/rXN65N7AgI8cypqTiVlxkvJGi0F7ITrYdBz/h/ZfjwqTarFHY1wFkpYDUIrI/uwu9sjHyBcyyf8WEH713zzzja2CXEqDnmf+IyoKj7EoSaxw/efMnYh7dYd4Tfrg1JX4QekxXzHanV7Fmtda5GbGRVpf277EjQiIbHbKV1og1bsdEiM1rsn8fJMGNRogZu+EKcsRKjhBjbyPt3cQFjpfkuTifZc9sj9EqVg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(136003)(39860400002)(366004)(346002)(86362001)(186003)(10290500003)(26005)(4326008)(71200400001)(8676002)(6506007)(6916009)(8936002)(82950400001)(53546011)(9686003)(33656002)(66446008)(82960400001)(83380400001)(54906003)(478600001)(7696005)(316002)(55016002)(66476007)(52536014)(66946007)(66556008)(76116006)(2906002)(5660300002)(64756008)(8990500004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: +YWMJYDIQzDoIKTmojjdnPnRofc87THQ1AJjfj3SXtwqY/iD7LPpwMG/yC4bEZHG87UEDxvRZkENg2nOYRw8Uwtv1vOPa3xuuX6E201bZ3+/B2r1L0lEzfJYql7WjVwnTSSZQDJAoQBYR2N3zLqzfIEirX3SZ3GadbOKIOALhLVHD8CdmBbxMbbslvJSnDuo2ZKObFRpxEAFOUF1FneK7dG4vp6iupHKyzs71ioxOq4KVwGltF0IcJnMAPl0YlisBxogYlaVN4CbYzCnIQiVoTX3qmyPJyd8ZbJaOWi4/+SWQ/YbBXTMRrScbpp7hA2DNmLubJPqFkOUqRztF0li6cDCzkiL1a8lM59Ps+JGwQxeewrLLoJAdA7RKrDfpXPaXcKf9A43ZzJel3xwU1XB4RUxn3q9KZTWCcEzEMUGAlRDgimSCUX/lFOwMMpbBdXHjIOoowdKXy138Xg85n8gmpR4i7zuF5TVeVhEyzafVQKWeXGUdLCWhIToNjeRmtGVRhwm2m3l9x2j7TijhbSa7sv5PVjcC6qA4+JHGBf0BkAwF7eT9E1L34x5cQLTLEnS2848UuXjxi9vQjYjt3fN0C2AomYAbXi/gdzIk8IHdbvQLjl8yzoOnhepXLBbAkgtmaic5WyaUn0TAFulVZvI3g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0686.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0b7bc090-f1ec-47a6-09ef-08d828d044a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2020 15:03:44.2151 (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: kBU7j7XbK1gqTtbrNneF27etEBnmI74IWkKqu50Lmo1+LmO9CDOykJLzDD+AcxtIF6MbeZfbuaNnNwo4MamyTw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0654 Archived-At: Subject: Re: [Cbor] Review of draft-ietf-cbor-date-tag-03 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 15:03:49 -0000 QXBwcmVjaWF0ZSBpdCENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJhcnJ5 IExlaWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4gDQpTZW50OiBXZWRuZXNkYXksIEp1bHkg MTUsIDIwMjAgODowMSBBTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT4NCkNjOiBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNz c29uLmNvbT47IGNib3JAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBSZXZpZXcgb2YgZHJhZnQtaWV0 Zi1jYm9yLWRhdGUtdGFnLTAzDQoNCkknbGwgYXNrIHRoZSBTZWNyZXRhcmlhdCBub3cgdG8gcG9z dCBpdCwgYnV0IGdpdmVuIHRoYXQgdGhlIENCT1Igc2Vzc2lvbiBpcyBzdGFydGluZyBub3csIGl0 J3MgY2xlYXJseSBub3QgaGFwcGVuaW5nIHRoYXQgcXVpY2tseS4NClNvcnJ5Lg0KDQpCYXJyeQ0K DQpPbiBXZWQsIEp1bCAxNSwgMjAyMCBhdCAxOjMxIEFNIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+DQo+IFRoZXJl4oCZcyBhIENCT1Igd29ya2luZyBn cm91cCBtZWV0aW5nIGF0IDhhbSBQYWNpZmljIFRpbWUgaW4gdGhlIG1vcm5pbmcgKFdlZG5lc2Rh eSwgSnVseSAxNXRoKS4gIEkgd2FzIHdvcmtpbmcgdG9kYXkgdG93YXJkcyBoYXZpbmcgaXQgcG9z dGVkIGJlZm9yZSB0aGVuLCBub3QgcmVhbGl6aW5nIHdlIHdlcmUgaW4gdGhlIGJsYWNrb3V0IHBl cmlvZC4gIElmIHlvdSBjYW4gcG9zdCBpdCBiZWZvcmUgdGhlbiwgdGhhdCB3b3VsZCBiZSBncmVh dC4NCj4NCj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFRoYW5rcywNCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4NCj4NCj4NCj4gRnJvbTogQmFycnkg TGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPg0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDE0 LCAyMDIwIDg6MjYgUE0NCj4gVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT4NCj4gQ2M6IEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJpbmlAZXJp Y3Nzb24uY29tPjsgDQo+IGNib3JAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFJldmlldyBvZiBk cmFmdC1pZXRmLWNib3ItZGF0ZS10YWctMDMNCj4NCj4NCj4NCj4gSSBjYW4gZG8gdGhhdCwgYnV0 IHN1Ym1pc3Npb25zIHdpbGwgcmUtb3BlbiBvbiBNb25kYXkgb2YgSUVURiB3ZWVrIGFueXdheS4g IERvIHdlIHJlYWxseSBuZWVkIGl0IHBvc3RlZCBiZWZvcmUgdGhlbiwgb3Igc2hvdWxkIHdlIGp1 c3Qgd2FpdCBmb3IgdGhlIGJsYWNrb3V0IHBlcmlvZCB0byBlbmQgbm9ybWFsbHk/IEl04oCZcyBu b3QgbG9uZyB0byB3YWl0Lg0KPg0KPg0KPg0KPiBQZXJzb25hbGx5LCBJIHRoaW5nIHdlIHNob3Vs ZCBnZXQgcmlkIG9mIHRoZSBibGFja291dCwgYW5kIGxldCBXR0NzIGltcG9zZSB0aGVpciBvd24g ZGVhZGxpbmVzIGZvciBtZWV0aW5ncyBhcyBhcHByb3ByaWF0ZS4gQnV0IGV2ZXJ5IHRpbWUgd2Ug c3VnZ2VzdCB0aGF0LCB0aGUgY2hhaXJzLCBhbG1vc3QgZW4gYmxvYywgaW5zaXN0IHRoYXQgdGhl eSB3YW50IHRoZSBJRVNHIHRvIGltcG9zZSB0aGUgZGVhZGxpbmUuDQo+DQo+DQo+DQo+IEJhcnJ5 DQo+DQo+DQo+DQo+IE9uIFR1ZSwgSnVsIDE0LCAyMDIwIGF0IDEwOjI3IFBNIE1pa2UgSm9uZXMg PE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+DQo+IFNob290IC0gSSBmaW5p c2hlZCBwcmVwYXJpbmcgLTA0IHRvIGFkZHJlc3MgeW91ciBjb21tZW50cyBhbmQgdGhvc2Ugb2Yg DQo+IG90aGVycywgb25seSB0byBkaXNjb3ZlciB0aGF0IHN1Ym1pc3Npb24gaXMgcHJlc2VudGx5 IGNsb3NlZCAoYXMgDQo+IGhhcHBlbnMgYmVmb3JlIElFVEYgbWVldGluZ3MpLiAgSSdtIGF0dGFj aGluZyB0aGUgc291cmNlIGFuZCAudHh0IA0KPiB2ZXJzaW9uIG9mIC0wNC4gIElmIHRoZSBjaGFp cnMgb3IgQUQgY2hvb3NlIHRvLCBtYXliZSB5b3UgY2FuIHB1bGwgDQo+IHdoYXRldmVyIHN0cmlu Z3MgeW91IG5lZWQgdG8gd2l0aCB0aGUgc2VjcmV0YXJpYXQgdG8gZ2V0IGl0IHBvc3RlZCANCj4g YW55d2F5LiAgKEkga25vdyBLYXRobGVlbiBkaWQgdGhhdCBmb3IgbWUgYXQgbGVhc3Qgb25jZSB3 aGlsZSBzaGUgd2FzIA0KPiBhbiBhcmVhIGRpcmVjdG9yLikNCj4NCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBUaGFua3MsDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLS0gTWlrZQ0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBGcmFu Y2VzY2EgUGFsb21iaW5pIA0KPiA8ZnJhbmNlc2NhLnBhbG9tYmluaT00MGVyaWNzc29uLmNvbUBk bWFyYy5pZXRmLm9yZz4NCj4gU2VudDogVGh1cnNkYXksIEp1bHkgOSwgMjAyMCA3OjA3IEFNDQo+ IFRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBjYm9yQGlldGYu b3JnDQo+IFN1YmplY3Q6IFtFWFRFUk5BTF0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtY2Jvci1kYXRl LXRhZy0wMw0KPg0KPiBIaSBNaWtlLA0KPg0KPiBXaGlsZSByZXZpZXdpbmcgZm9yIHRoZSBzaGVw aGVyZCB3cml0ZXVwIEkgZm91bmQgdGhlIGZvbGxvd2luZyBtaW5vciBpc3N1ZXM6DQo+DQo+IFNl Y3Rpb24gMToNCj4gSSB3b3VsZCBzdWdnZXN0IHJlbW92aW5nIHRoZSBjb21tYSBmcm9tIHRoZSBu dW1iZXI6IDQwLDU4Ny4gVXNpbmcgdGhlIGNvbW1hIGFzIHNlcGFyYXRvciBpcyBub3QgdGhlIGJl c3QsIGFzIGluIHNvbWUgY291bnRyaWVzIGl0IGlzIHVzZWQgYXMgZGVjaW1hbCBzaWduIChhbHNv IG5vdCBwcmVmZXJyZWQgYnV0IGFsbG93ZWQgaW4gSVNPIDg2MDEpLg0KPg0KPiBGcm9tIEktRCBu aXRzOg0KPiAgID09IFRoZSBkb2N1bWVudCBkb2Vzbid0IHVzZSBhbnkgUkZDIDIxMTkga2V5d29y ZHMsIHlldCBzZWVtcyB0byBoYXZlIFJGQw0KPiAgICAgIDIxMTkgYm9pbGVycGxhdGUgdGV4dC4N Cj4gSXMgaXQgbmVjZXNzYXJ5IHRvIGhhdmUgdGhlIDIxMTkgLSA4MTc0IGJvaWxlcnBsYXRlIHRl eHQgZXZlbiBpZiBubyBub3JtYXRpdmUga2V5d29yZHMgYXJlIHVzZWQ/DQo+DQo+IFtQT1NJWC4x XSBzZWVtcyBtb3JlIGxpa2UgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIG1lLCBkb24ndCB5b3Ug dGhpbms/DQo+DQo+IFRoYW5rcywNCj4gRnJhbmNlc2NhDQo= From nobody Wed Jul 15 08:19: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 59AAF3A0CFF; Wed, 15 Jul 2020 08:19:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <159482639732.32266.16566150560027174579@ietfa.amsl.com> Date: Wed, 15 Jul 2020 08:19:57 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-date-tag-04.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 15:19:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF. Title : Concise Binary Object Representation (CBOR) Tags for Date Authors : Michael B. Jones Anthony Nadalin Jörg Richter Filename : draft-ietf-cbor-date-tag-04.txt Pages : 6 Date : 2020-07-15 Abstract: The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (RFC 3339 date/time string) and tag 1 (Posix "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for an RFC 3339 date text string, for applications needing a textual date representation within the Gregorian calendar without a time. It also defines a CBOR tag for days since the date 1970-01-01 in the Gregorian calendar for applications needing a numeric date representation without a time. It is intended as the reference document for the IANA registration of the CBOR tags defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-date-tag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-date-tag-04 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-date-tag-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-date-tag-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 15 10:20: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 14E7C3A0CFF; Wed, 15 Jul 2020 10:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-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 3mYgWj_htk4F; Wed, 15 Jul 2020 10:19:55 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2058.outbound.protection.outlook.com [40.107.22.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B293A0AD4; Wed, 15 Jul 2020 10:19:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iGuRvtonwR+xE8W6dlmNQlr7LnjPFIydD0VMnaoQ+dQ2aXrdbiGM4LicHkFqvQP9Tg7Ui/aa4Ol017dOvrz0RyrQN01PQon6lKX2Esgk8U+SjuyyIWBJnXHcuO0S2uiiyd/mshAMEHeWnMiDjHhIzf9Hu9/GQ4YFqQ5EgDVEXTUZCcWnCEuauhM77JubvUeqCImD6ohz1f239I0TCrN7eMlLqQoGKF9drAKMLvqgbgcUrLD1sX3HSqMBinc7mHJEMAy+vssOUu6f1EeyeRXIAe/kidhURrml1g4R8A+VfgZ0MEOUDOdSbu7dZp9a/tpeQg3VqSpw552crSYrrdcFDQ== 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=5uFR1mix9RbnMxs+JSGKncX43oCk7PQPL0QXaZ//Ghk=; b=MHgF3sw6ZlTDLYsLvJFnrK86Mu/yocvxD3ZXn6VsSAVZTpDvqTfESS5BgfFFdhmI22QPWdsVl1nOMbGyllMiKVaaURjmzwHWC18xFSayhm3aJFMDl6PzeQrGadGEeolUHoIwbtMbeaxXwDwtxfSPFytUBGlcRmzvDtF/6uXgWlCruwOShvE595v3eTCsZbGmSvyBaKDxbVZN7G+dy7RFHRrfxkfBJ9APNfyDUVLhhR491p/IluSyy1k+Pfj42Xn1mHn5VS5lOLp6WCBtJ/PIZhLtFj35U9WdfI9HlAGhGHDOPn3TPRiQwz2v82MYJIm4+K/6advvcEykd/k7eAGMyg== 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=5uFR1mix9RbnMxs+JSGKncX43oCk7PQPL0QXaZ//Ghk=; b=teFAgYPVd/uMRPX59pBfRRNgk9H9PFgbJ71w35Z/QfwJMmh7YF1gJgcKswkN72v8QSPsHWkKfRNPWjJ2odnElIUoZl5bHxYGoUkn7DEagWfElUT+c9FJq/qAsYZS2X+IPUwJAkC/081tTsa+olRaZmjyMHa07y9Wml3dNNQhVYA= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR07MB3387.eurprd07.prod.outlook.com (2603:10a6:7:2b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.16; Wed, 15 Jul 2020 17:19:52 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3174.022; Wed, 15 Jul 2020 17:19:52 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" , "draft-bormann-cbor-tags-oid@ietf.org" Thread-Topic: =?utf-8?B?8J+UlCBXRyBhZG9wdGlvbiBjYWxsIG9uIGRyYWZ0LWJvcm1hbm4tY2Jvci10?= =?utf-8?Q?ags-oid-07?= Thread-Index: AQHWWswmyp4Atl2Zsk+Vmry3ilT2Sg== Date: Wed, 15 Jul 2020 17:19:52 +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/16.37.20051002 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [79.12.182.121] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ef9e8216-d80f-4015-fda5-08d828e3493b x-ms-traffictypediagnostic: HE1PR07MB3387: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6s67AgtakGR3DP79aR2K4vl/Zvhl6eySBr9nMT3i2xBcZHKsGOtwueKvJzEFIFb8gCZVLVsXQbcngnqI6NK+yiTiYfsg8EkzRYUNz7WyrUEbzATr3D7Ja4nkHPhnyXxw7T/xVsJrot5lKsP+W7+hAKbcoPZf+Puj29j2h7mWj1mueZWKFZviJJlqCA3TJf/759+URQGVeo6XEe/5z6mCe3nLV8QrSJy/yFJXpq2SBgd/Oq3MyyOA1gDoFdiLuQyBxaWkYoAzhPzLF1K1j+mEJoDgiSkLRWoqL89VZl+OW1C3qp0Ejroy9/KJ4oFl8rGOnAg3i+Z9QpAHyJ0sovBhJOi1s2/SnMDTKW7TQRVEL+fNgdG+fAJnaBNPNHQUqukxTiYX5kIAYOmu1HJqD3elt7i1LZEpxkwqhWyKl+5UfSUnQ8hwtWXq9uy+W4UdmvNaC0ZGe9A/fMAPFXO4uaGObQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(396003)(39860400002)(366004)(136003)(450100002)(316002)(6506007)(6486002)(91956017)(86362001)(66446008)(66946007)(4326008)(6512007)(66476007)(8936002)(76116006)(66556008)(64756008)(36756003)(71200400001)(4744005)(5660300002)(2906002)(6916009)(54906003)(33656002)(478600001)(2616005)(186003)(44832011)(966005)(26005)(379964003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: B14qmtTj2adirTiHkGlIFk1YhDsdx79tlqmElOxPNjc1j0pnyTlCDqu3yel08m7411HFQdx4QTcemn0EHZdYMcDKtQL+YDrRllScdkAQWF4ovESXbLKmg1wD/QKM6ohryUFQfsWUrjHUYVCFKqC227NtLtTKLxa6zQfXNcNaLXI1/zCfcPgtFh69tiSl1RQHIYvGPyVtiZ9G3XqRP7y/oJ+BjZSt2CmGry7qN/IpxAmQyq0Zce5bXOiUDWDb7wwZuBkEnbWiAU0hnH1IICjlI0PNgXq8iX98OrgDEmixKpcRowy3/FaqOuOVuu7hrFVE1HSE3QI0PEkZ2qh1LNRG0OgYChPVRSutW4+il1OxHU7PbpdF63LuBV48K3T1c/Av7SLjO8UdiceZP+UDbByNQkCGmNNwDnkGIsNFmdLxkZZfm9p3bzXpoBzFKYsGvNMEFpf0urBbrhKquWy+2dGoFtnwSIPhcquWp6+bop75ZCFLcJMsOr87kA/D/upOaf4H x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <6811BEC483FB514AA1E3208D5A717DEA@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ef9e8216-d80f-4015-fda5-08d828e3493b X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2020 17:19:52.3551 (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: g8jrN263B6miXnxmfSHRI4OT5kO63upN+AOLpIeNCRvBw3AEIstlpEymh2CZdgVw/UVtG9txaWLydwr0y8iG2JYaZ2YPwuFjIwbfuGpbN9NlUAK7Sz5deq7A+sok4eOo X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3387 Archived-At: Subject: [Cbor] =?utf-8?q?=F0=9F=94=94_WG_adoption_call_on_draft-bormann-?= =?utf-8?q?cbor-tags-oid-07?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 17:19:57 -0000 IENCT1Igd2csDQoNClRoaXMgc3RhcnRzIGEgV0cgYWRvcHRpb24gY2FsbCBvbiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvIGRyYWZ0LWJvcm1hbm4tY2Jvci10YWdzLW9pZC0wNywgZW5kaW5n IG9uICpTdW5kYXksIEp1bHkgMjYqLiAgUGxlYXNlIHJlcGx5IHRvIHRoaXMgdGhyZWFkIGJ5IHN0 YXRpbmcgd2hldGhlciB5b3Ugc3VwcG9ydCB0aGUgYWRvcHRpb24sIGFuZCBpbmRpY2F0ZSB5b3Vy IHdpbGxpbmduZXNzIHRvIHJldmlldyB0aGUgZHJhZnQgaWYgaXQgYmVjb21lcyBhIHdvcmtpbmcg Z3JvdXAgZG9jdW1lbnQuDQoNCldlIHdpbGwgYW5ub3VuY2UgdGhlIHJlc3VsdCBvZiB0aGUgYWRv cHRpb24gY2FsbCBhdCBvdXIgSUVURiAxMDggbWVldGluZywgTW9uZGF5LCBKdWx5IDI3Lg0KDQpD Qk9SIENoYWlycw0KSmltICYgRnJhbmNlc2NhDQoNCg== From nobody Wed Jul 15 10:22:02 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 4A5413A0D6C; Wed, 15 Jul 2020 10:22:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159483372028.18798.1973973877887364470@ietfa.amsl.com> Date: Wed, 15 Jul 2020 10:22:00 -0700 Archived-At: Subject: [Cbor] The CBOR WG has placed draft-bormann-cbor-tags-oid in state "Call For Adoption By WG Issued" 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, 15 Jul 2020 17:22:00 -0000 The CBOR WG has placed draft-bormann-cbor-tags-oid in state Call For Adoption By WG Issued (entered by Francesca Palombini) The document is available at https://datatracker.ietf.org/doc/draft-bormann-cbor-tags-oid/ Comment: Adoption call ends July 26, 2020 From nobody Wed Jul 15 10:41:17 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 9A7BD3A0B18; Wed, 15 Jul 2020 10:41:11 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMdUglbiOjh8; Wed, 15 Jul 2020 10:41:10 -0700 (PDT) Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (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 97E143A0873; Wed, 15 Jul 2020 10:41:08 -0700 (PDT) Received: by mail-vs1-xe44.google.com with SMTP id s20so1542180vsq.5; Wed, 15 Jul 2020 10:41:08 -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=YhKoavKWEzRQgZOWPHS4eb+579ObVSrN8KA+yHxKGJg=; b=Ll9QWpzJ2TkUS0T8hAbvPEGNlWs8GIh/rqURwTDS34yfUANzJ0IosrZ0OTFtSIo/fG ZNxgw50TXhIl8RE8cU5LkBZ9lIJgDZHE9NFWZqs33K6jm6TEJCbPwFsYkIIAjKVOJdQy Ed7VqkR7HBlS7UfEmV8XVJMkshj+D2c2P4KnwPfko3/BMFehL+2Z+QF/nlrYcIUcBgzM xofCwyUz4OCDFIl3mUqO6wW5iEKuOL7eIgtVH6yShtOnxpQhV1DD6ZUuwXyZpfG2nXP5 EMD+6Cux7DvSWoz8y7MoPJTdahNBPXiFJcvMZDfo4zVG4qBgmIJzu2+royXy8r9jr1DH YuTA== 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=YhKoavKWEzRQgZOWPHS4eb+579ObVSrN8KA+yHxKGJg=; b=qXwuhTmUu5vVG4Qs2Or6n6Uk2GhVzBYmcjqf1/xxg+R4JIvlrVIoFHwo0TAAM/YDf1 k9iBKP4HoFN1RslMXfabHqDt222cRVvxF5JhuX5KZUYNB05y9+fQdMH5tLvoDYDqRk4r GLznstLSlIyXum3TI5RBKxar0EFwnYBQs2dZEb4yl7bsf5Ikzz9k4/v8GphRAlIhTGNi fy8Xns3R1IqyL4TxhOZFaT3D42oE04SdPgNupwFY+OnDgg2bem/GYmz96+KVHF3A8Pvw 5nmXB/598Z9Z28nfCC8qV+bxBlnIuw2T1CagY/xVq1u/xtrTIHxqvprUmjmc8M5C/SxJ YusQ== X-Gm-Message-State: AOAM533TKKZ/sr9OabXeL62WBAOKkvetxKbHgR6sl8NXyUqFObpl7vXN M2Q7Ds2Hu7fLyxJXCUHkdTCaPUXEl4/GItuzEAU= X-Google-Smtp-Source: ABdhPJz+pzpRJ+bvv39U3+0kZdg6pz6cEfuPUpsPdGAP/LBGgWWZTofcKExARKaRRyz/ch2hsUU8y9J2NfoMQQvkcrE= X-Received: by 2002:a67:bd09:: with SMTP id y9mr253792vsq.13.1594834867549; Wed, 15 Jul 2020 10:41:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ira McDonald Date: Wed, 15 Jul 2020 13:40:55 -0400 Message-ID: To: Francesca Palombini , Ira McDonald Cc: "cbor@ietf.org" , "draft-bormann-cbor-tags-oid@ietf.org" , "cbor-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c177f405aa7e6d9a" Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WG_adoption_call_on_draft-bormann-?= =?utf-8?q?cbor-tags-oid-07?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 17:41:15 -0000 --000000000000c177f405aa7e6d9a Content-Type: text/plain; charset="UTF-8" Hi, Yes, I support CBOR WG adoption of this draft. I've just read most of it and find it important and well-written. 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 WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://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* On Wed, Jul 15, 2020 at 1:20 PM Francesca Palombini wrote: > CBOR wg, > > This starts a WG adoption call on https://tools.ietf.org/html/ > draft-bormann-cbor-tags-oid-07, ending on *Sunday, July 26*. Please reply > to this thread by stating whether you support the adoption, and indicate > your willingness to review the draft if it becomes a working group document. > > We will announce the result of the adoption call at our IETF 108 meeting, > Monday, July 27. > > CBOR Chairs > Jim & Francesca > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > --000000000000c177f405aa7e6d9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Yes, I support CBOR WG a= doption of this draft.=C2=A0 I've just read most of it
and fi= nd it important and well-written.

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 Printin= g WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO= PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Pr= inter 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=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434=


On Wed, Jul 15,= 2020 at 1:20 PM Francesca Palombini <francesca.palombini=3D40ericsson.com@dmarc.ietf.org> = wrote:
=C2=A0CBO= R wg,

This starts a WG adoption call on https://tools.ietf.org/html/ draft= -bormann-cbor-tags-oid-07, ending on *Sunday, July 26*.=C2=A0 Please reply = to this thread by stating whether you support the adoption, and indicate yo= ur willingness to review the draft if it becomes a working group document.<= br>
We will announce the result of the adoption call at our IETF 108 meeting, M= onday, July 27.

CBOR Chairs
Jim & Francesca

_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
--000000000000c177f405aa7e6d9a-- From nobody Wed Jul 15 12:02:49 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BA03A0F6D for ; Wed, 15 Jul 2020 12:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 1IcKrzg5LTHc for ; Wed, 15 Jul 2020 12:02:41 -0700 (PDT) Received: from p3plsmtpa06-01.prod.phx3.secureserver.net (p3plsmtpa06-01.prod.phx3.secureserver.net [173.201.192.102]) (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 3263A3A0F4D for ; Wed, 15 Jul 2020 12:02:39 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id vmdjjxSWuUdEbvmdjjbOXg; Wed, 15 Jul 2020 12:00:23 -0700 X-CMAE-Analysis: v=2.3 cv=McgSRK3f c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=5KLPUuaC_9wA:10 a=pGLkceISAAAA:8 a=y6WFtdQdAAAA:20 a=qlatCZPWAAAA:20 a=48vgC7mUAAAA:8 a=RvLTa3UQHx1oWwm62rEA:9 a=CjuIK1q_8ugA:10 a=MDABLX8d_eUA:10 a=E29ViCccDhVDK5f6Y1MA:9 a=x_EEOhVz5eSSc5kK:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=pHzHmUro8NiASowvMSCR:22 a=nt3jZW36AmriUCFCBwmW:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_92AE21E1-C976-4426-8C9B-03F3B5BDDB75" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 15 Jul 2020 12:00:22 -0700 In-Reply-To: Cc: Francesca Palombini , "cbor@ietf.org" , "cbor-chairs@ietf.org" , "draft-bormann-cbor-tags-oid@ietf.org" To: Ira McDonald References: X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfHiFr5gk2RROSZj3nqj7zsbXYH4eLFxsc2a+9FXp5H2mdR28hRbmowr9PKDLRgyzvk3ak4NvCOPosUl+s0HRn1ht1fuEHmtmBvmcsYguBbK+US2FlfLO lxA3opi0OFeMh77lAOwOFH26lCyW+qrwzC+iqu1XFlrKTvFBJTNt5wkxjaDLonjciX1iMoRuk/W/OgW52FVtjHvMI7ODNJXEZPvLmBKyDakmtPcXot2xm4pN sWwUFOG0sMubotL3XW1APZ0r3449x7ucF6lOQE0q+S6t6ZrAFETPLAJ7pR2XmwQJjfhDbgYoBbtvRb8Pkmt2uECUvXx3OxkEWohtLYuSw3lTJ5TplLHxRsYd tf5N6nXz Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WG_adoption_call_on_draft-bormann-?= =?utf-8?q?cbor-tags-oid-07?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 19:02:47 -0000 --Apple-Mail=_92AE21E1-C976-4426-8C9B-03F3B5BDDB75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 > On Jul 15, 2020, at 10:40 AM, Ira McDonald = wrote: >=20 > Hi, >=20 > Yes, I support CBOR WG adoption of this draft. I've just read most of = it > and find it important and well-written. >=20 > Cheers, > - Ira >=20 > 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 >=20 >=20 > On Wed, Jul 15, 2020 at 1:20 PM Francesca Palombini = > wrote: > CBOR wg, >=20 > This starts a WG adoption call on https://tools.ietf.org/html/ = draft-bormann-cbor-tags-oid-07, ending on = *Sunday, July 26*. Please reply to this thread by stating whether you = support the adoption, and indicate your willingness to review the draft = if it becomes a working group document. >=20 > We will announce the result of the adoption call at our IETF 108 = meeting, Monday, July 27. >=20 > CBOR Chairs > Jim & Francesca >=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 --Apple-Mail=_92AE21E1-C976-4426-8C9B-03F3B5BDDB75 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1

On Jul 15, 2020, at 10:40 AM, Ira McDonald <blueroofmusic@gmail.com> wrote:

Hi,

Yes, I support CBOR WG adoption of this = draft.  I've just read most of it
and find it = important and well-written.

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


On Wed, Jul 15, 2020 at 1:20 PM = Francesca Palombini <francesca.palombini=3D40ericsson.com@dmarc.ietf.org> wrote:
 CBOR wg,

This starts a WG adoption call on https://tools.ietf.org/html/ = draft-bormann-cbor-tags-oid-07, ending on *Sunday, July 26*.  = Please reply to this thread by stating whether you support the adoption, = and indicate your willingness to review the draft if it becomes a = working group document.

We will announce the result of the adoption call at our IETF 108 = meeting, Monday, July 27.

CBOR Chairs
Jim & Francesca

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

= --Apple-Mail=_92AE21E1-C976-4426-8C9B-03F3B5BDDB75-- From nobody Wed Jul 15 12:07: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 7B37A3A0ECF; Wed, 15 Jul 2020 12:07:26 -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 dE6z3S4oe0mJ; Wed, 15 Jul 2020 12:07:25 -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 159183A0EC4; Wed, 15 Jul 2020 12:07:21 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 15 Jul 2020 12:06:56 -0700 From: Jim Schaad To: CC: Date: Wed, 15 Jul 2020 12:06:54 -0700 Message-ID: <00f701d65adb$1c49e1f0$54dda5d0$@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: AdZaxNm7TpnMjDvMS2qkuiEECb/XPg== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Review draft-bormann-cbor-packed-00 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 19:07:26 -0000 Carsten, I am finding this document really hard to follow. I am sure that we can get it to read much better in the future. Some of the issues that I am having are: 1. How the Tag 6 is used is dependent on the type of the embedded content and this is not explained at all. It took me a while to understand why #6.6(0) was not a potential duplicate value between sections 2.1 and 2.2. 2. I am trying to get a handle on where you think this would be used and how much compression is going to give me. Part of this is going to be a question of how much compression is obtained and the difference between optimal and reasonable. For example, Tags 224-255 would end up with 2 bytes for the tag, plus the encoding of the suffixed data. Moving to #6.6([#, suffix]) ends up with 4 bytes plus the encoding of the suffix. This means that you would want to save a minimum of 8 bytes in the prefix rather than 4 bytes. You are also going to have two bytes consumed in the suffix table for strings. 3. It would be really good to expand the example to include a case of prefix compression as well. This would make that concept much easier to understand. 4. I am having a hard time figuring out how you are going to get a reference loop because I was assuming that any shared items that would need to be unpacked would have it's own dictionary defined. This seems to imply that shared items are using the same dictionary. This needs an example. 5. Is there a reason not to switch to using '^' for exponentiation? This is the more mathematical one symbol. 6. As we compose documents nested documents will become more frequent. The question is should the multiple levels be merged into a single compression table. 7. I am not happy about the complete abandonment of providing guidance for a packing algorithm. At a minimum things like doing advance computing on compression, using pre-defined vocabularies (if not dictionaries) is most likely usable. 8. Should we provide an option to use an application defined dictionary as that would pack even more at the penalty that the document could not be unpacked without that dictionary. Jim From nobody Wed Jul 15 12:43: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 96A333A0F52; Wed, 15 Jul 2020 12:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 MeKlwDZkGhBE; Wed, 15 Jul 2020 12:43: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 0315D3A0F51; Wed, 15 Jul 2020 12:43:30 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B6SVT2m2nzyVd; Wed, 15 Jul 2020 21:43:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <00f701d65adb$1c49e1f0$54dda5d0$@augustcellars.com> Date: Wed, 15 Jul 2020 21:43:28 +0200 Cc: draft-bormann-cbor-packed@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 616535008.750273-6a9ba735794ee524f53792f1c7607af0 Content-Transfer-Encoding: quoted-printable Message-Id: <04545D98-A936-4DD0-8446-3634E6C12667@tzi.org> References: <00f701d65adb$1c49e1f0$54dda5d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Review draft-bormann-cbor-packed-00 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 19:43:35 -0000 Hi Jim, Thanks for this lightning feedback. Let me try to answer as quickly... > On 2020-07-15, at 21:06, Jim Schaad wrote: >=20 > Carsten, >=20 > I am finding this document really hard to follow. =20 Yes. It contains the specification, but not yet any tutorial material. Way too few examples. > I am sure that we can get > it to read much better in the future. =20 Absolutely. > Some of the issues that I am having > are: >=20 > 1. How the Tag 6 is used is dependent on the type of the embedded = content > and this is not explained at all. It took me a while to understand = why > #6.6(0) was not a potential duplicate value between sections 2.1 and = 2.2. Yes. Section 3, second paragraph says this, but that may be a little late=E2=80= =A6 (I always read the discussion before the normative part, so I just = didn=E2=80=99t notice.) > 2. I am trying to get a handle on where you think this would be used = and > how much compression is going to give me. =20 Use where? Where simple data models exhibit too much sharing, or where = the strings that go into those have too long common prefixes (which = happens a lot in RDF-derived environments). And the point is that there is no need for decompression at the = consumer. How much compression? One data point: http://www.w3.org/2017/07/wot-f2f/slides/w3c-serialization.pdf =E2=80=94 = slide 6. 1/3 off by sharing, ~ 1/5 more off by prefix compression. 47 % left. (Deflate gives 29 %, so is 57 % of cbor-packed.) A static dictionary would help some more. > Part of this is going to be a > question of how much compression is obtained and the difference = between > optimal and reasonable. =20 I you need optimal compression, go for LZ77 over the whole thing. Cbor-packed is reasonable :-) > For example, Tags 224-255 would end up with 2 > bytes for the tag, plus the encoding of the suffixed data. Moving to > #6.6([#, suffix]) ends up with 4 bytes plus the encoding of the = suffix. > This means that you would want to save a minimum of 8 bytes in the = prefix > rather than 4 bytes. You are also going to have two bytes consumed in = the > suffix table for strings. Right. That=E2=80=99s why the draft is a bit aggressive about obtaining = 1-byte and 2-byte references. > 3. It would be really good to expand the example to include a case of > prefix compression as well. This would make that concept much easier = to > understand. Yes. > 4. I am having a hard time figuring out how you are going to get a = reference > loop because I was assuming that any shared items that would need to = be > unpacked would have it's own dictionary defined. =20 No, only the top level has shared/prefix items. Shared/prefix item 5 could reference Shared/prefix item 5 (insert larger = loop as needed). E.g., shared item 0 could be =E2=80=9Csold out=E2=80=9D, and shared item = 1 could be {=E2=80=9Cprice=E2=80=9D: 9.99, =E2=80=9Cstock=E2=80=9D: = simple(0)}. > This seems to imply that > shared items are using the same dictionary. This needs an example. Right. Half an example above. > 5. Is there a reason not to switch to using '^' for exponentiation? = This is > the more mathematical one symbol. Yes. ^ is XOR in C. In math, we do that differently. Like 2=E2=81=B6=E2=81=B4 :-) But the RFC editor won=E2=80=99t let me do = that, I=E2=80=99m sure... > 6. As we compose documents nested documents will become more = frequent. The > question is should the multiple levels be merged into a single = compression > table. Well, you could try it, and if it gets longer (because the references to = a larger dictionary get larger), you don=E2=80=99t. > 7. I am not happy about the complete abandonment of providing = guidance for > a packing algorithm. At a minimum things like doing advance computing = on > compression, using pre-defined vocabularies (if not dictionaries) is = most > likely usable. Just putting the JSON object labels into a dictionary, sorting by number = of use, and removing those that are not referenced often enough or where = the references get larger than the actual strings, is often 80 % of the = gain. My little toy packer (250 LOC) simply tries to share *all* duplicate = sub-items. The fun comes in if a duplicate sub-item has a sub-item = shared with another sub-item, which may make referencing the duplicate = sub-item less optimal than just copying the sub-item. I=E2=80=99m not = sure my algorithm is very sane, but I like the output, and for the = details that=E2=80=99s what we have BYGS (*) for. > 8. Should we provide an option to use an application defined = dictionary as > that would pack even more at the penalty that the document could not = be > unpacked without that dictionary. Yes. The question is how that is obtained (from context?), and how the = dictionary items are merged with those shared items listed in the item = (the dictionary may or may not have the most frequently used shared = items in the specific data item to be packed). I wouldn=E2=80=99t want = to COSE-sign a packed CBOR data item where it is hackable from where the = dictionary came... Gr=C3=BC=C3=9Fe, Carsten (*) Bright young grad students From nobody Wed Jul 15 12:54: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 4E39E3A0F6F for ; Wed, 15 Jul 2020 12:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 uoCG6XMxqwMl for ; Wed, 15 Jul 2020 12:54:27 -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 E69873A091E for ; Wed, 15 Jul 2020 12:54:26 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B6Sl51DSGzyVx; Wed, 15 Jul 2020 21:54:25 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 616535664.432235-f4e7b16063dbdaabbe6bebfc9dd33a82 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 15 Jul 2020 21:54:24 +0200 Message-Id: <1FA548C9-3CAF-4326-AF9B-F9AFC65547C8@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Cbor] =?utf-8?q?Diagnostic_format_should_be_a_surjection_onto_v?= =?utf-8?q?alid_CBOR_bytes_=C2=B7_Issue_=23204_=C2=B7_cbor-wg/CBORbis?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 19:54:30 -0000 Interesting discussion at: https://github.com/cbor-wg/CBORbis/issues/204#issuecomment-658949427=20 Not sure we can (or should) do anything for 7049bis. But would be nice to have a solution. (Note that the 7049 diagnostic notation was already extended in 8610.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 15 17:21: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 DF53C3A0F09 for ; Wed, 15 Jul 2020 17:21:07 -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 eMDpaj49Thxf for ; Wed, 15 Jul 2020 17:21:06 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4973A0F08 for ; Wed, 15 Jul 2020 17:21:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A450D389E1 for ; Wed, 15 Jul 2020 20:18:02 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Kv-ZUxd63aDr for ; Wed, 15 Jul 2020 20:18:01 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6B929389D5 for ; Wed, 15 Jul 2020 20:18:01 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 35C01430 for ; Wed, 15 Jul 2020 20:21:02 -0400 (EDT) From: Michael Richardson To: "cbor\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] =?utf-8?q?=F0=9F=94=94_WG_adoption_call_on_draft-bormann-?= =?utf-8?q?cbor-tags-oid-07?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 00:21:08 -0000 --=-=-= Content-Type: text/plain Please adopt this document so that we can discuss it more. I would have no objection to going directly to WGLC as is, but we probably need a review from Russ Housley, Sean Turner or ... Minor things I could see improving: 1) I think that the PCRE description in section 2.1 may be more heat than light. For those who speak PCRE, it's great, and for those who don't, it just mystifies. Those who speak PCRE probably already got the english text. 2) I have some concerns about the complexity of the Tag Factoring when it comes to the nesting. Also, as I read it the first time, I thought it meant: "bstr for 1.3.6.1.2.1"[126,127,128,129] => [ "bstr for 1.3.6.1.2.1.126", "bstr for 1.3.6.1.2.1.127", "bstr for 1.3.6.1.2.1.128" "bstr for 1.3.6.1.2.1.129"] but that's *NOT* the intention :-) 3) It would probably be good to have a few use cases. If there is an intention to be able to round trip signed certificates, then this should be explicit. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8PnW0ACgkQgItw+93Q 3WVJdwf9HAqm66K7dyPlxX/u2W07dQ/GHA9PUD8hcfpCR+fI9damEr9SOCJw5+MG 0ycUEszQnq+xasgL4t+3xT2uZHV1aUEs1wzeJ8gle5iLF21RmPhdxgmIUapetMVc NrNKE7KpkQyEWUrGawhB2RODjnT28K4I2qAXPIYw+NYN21IJUmk9MQ+WxJ9Fl35p PXvH3fhY7rHx2Fbqm9nemuatvxoGXwO0iBt1e5t6wgn/Eeyn7PAMtd+pAt+aZMNO PQl51nd/T3VYQhClxanBWvwlrjObXxFK3i5LwqDIoN/Y9W7ivZN1L8jWR1n2yyJg VfctqFUTXGae9aG48/K4OoiaogOH1A== =8gxS -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 15 22:18:17 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 769B33A0E32 for ; Wed, 15 Jul 2020 22:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 TQ1qCkzoKSiL for ; Wed, 15 Jul 2020 22:18: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 E99693A0E31 for ; Wed, 15 Jul 2020 22:18:12 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B6jFY4sQHzyYt; Thu, 16 Jul 2020 07:18:09 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <4305.1594858862@localhost> Date: Thu, 16 Jul 2020 07:18:09 +0200 Cc: "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 616569488.963094-19693791e42f84220fdc30b22e922271 Content-Transfer-Encoding: quoted-printable Message-Id: <342BB6D0-7D23-4925-9AE2-53AB48E37E97@tzi.org> References: <4305.1594858862@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WG_adoption_call_on_draft-bormann-?= =?utf-8?q?cbor-tags-oid-07?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 05:18:15 -0000 > Minor things I could see improving: > 1) I think that the PCRE description in section 2.1 may be more heat = than light. > For those who speak PCRE, it's great, and for those who don't, it = just mystifies. > Those who speak PCRE probably already got the english text. I generally benefit from having a concept explained in different ways. This allows me to verify my nascent understanding. (We need to make sure that it is clear that this is just explanation, an = =E2=80=9Cexample=E2=80=9D in some way, and not the normative part =E2=80=94= that is in RFC 6256.) > 2) I have some concerns about the complexity of the Tag Factoring when = it > comes to the nesting. Indeed. If we want to keep it, we need to find constraints on the = interpretation that are manageable but maintain some usefulness. > Also, as I read it the first time, I thought it meant: >=20 > "bstr for 1.3.6.1.2.1"[126,127,128,129] > =3D> > [ "bstr for 1.3.6.1.2.1.126", > "bstr for 1.3.6.1.2.1.127", > "bstr for 1.3.6.1.2.1.128" > "bstr for 1.3.6.1.2.1.129"] >=20 > but that's *NOT* the intention :-) No. Due to the way OIDs are used, that is also rarely what is needed. > 3) It would probably be good to have a few use cases. > If there is an intention to be able to round trip signed = certificates, > then this should be explicit. You mean as in draft-mattsson-cose-cbor-cert-compress? They get by without OIDs=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 16 05:44:37 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 A4DBF3A08BD; Thu, 16 Jul 2020 05:44:35 -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 uedSWPIqnCX1; Thu, 16 Jul 2020 05:44:33 -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 4DA0D3A03FA; Thu, 16 Jul 2020 05:44:33 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 16 Jul 2020 05:44:08 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: , References: <00f701d65adb$1c49e1f0$54dda5d0$@augustcellars.com> <04545D98-A936-4DD0-8446-3634E6C12667@tzi.org> In-Reply-To: <04545D98-A936-4DD0-8446-3634E6C12667@tzi.org> Date: Thu, 16 Jul 2020 05:44:06 -0700 Message-ID: <000701d65b6e$cd02eee0$6708cca0$@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: AQKslLtd3Pxo54N8Z1yW+xXnZNMlgQEImUjfp1Vu1yA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Review draft-bormann-cbor-packed-00 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 12:44:36 -0000 > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Wednesday, July 15, 2020 12:43 PM > To: Jim Schaad > Cc: cbor@ietf.org; draft-bormann-cbor-packed@ietf.org > Subject: Re: [Cbor] Review draft-bormann-cbor-packed-00 >=20 > Hi Jim, >=20 > Thanks for this lightning feedback. Let me try to answer as = quickly... >=20 > > On 2020-07-15, at 21:06, Jim Schaad wrote: > > > > Carsten, > > > > I am finding this document really hard to follow. >=20 > Yes. It contains the specification, but not yet any tutorial = material. > Way too few examples. >=20 > > I am sure that we can get > > it to read much better in the future. >=20 >=20 > > 5. Is there a reason not to switch to using '^' for exponentiation? > > This is the more mathematical one symbol. >=20 > Yes. ^ is XOR in C. > In math, we do that differently. > Like 2=E2=81=B6=E2=81=B4 :-) But the RFC editor won=E2=80=99t let me = do that, I=E2=80=99m sure... Just the one item. 264 is what you are looking for. >=20 >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > (*) Bright young grad students >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Thu Jul 16 06:32: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 1F2D73A0598; Thu, 16 Jul 2020 06:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 DrzNvj8jc2bS; Thu, 16 Jul 2020 06:32:37 -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 169903A0528; Thu, 16 Jul 2020 06:32:36 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B6wD21Hszzyyr; Thu, 16 Jul 2020 15:32:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <000701d65b6e$cd02eee0$6708cca0$@augustcellars.com> Date: Thu, 16 Jul 2020 15:32:33 +0200 Cc: cbor@ietf.org, draft-bormann-cbor-packed@ietf.org X-Mao-Original-Outgoing-Id: 616599153.503368-ff2e1f789872fd7e387777b2da97b6d4 Content-Transfer-Encoding: quoted-printable Message-Id: <66E8BC1E-D4D2-42DD-B8F6-B43B704468CC@tzi.org> References: <00f701d65adb$1c49e1f0$54dda5d0$@augustcellars.com> <04545D98-A936-4DD0-8446-3634E6C12667@tzi.org> <000701d65b6e$cd02eee0$6708cca0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Review draft-bormann-cbor-packed-00 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 13:32:40 -0000 On 2020-07-16, at 14:44, Jim Schaad wrote: >=20 > Just the one item. 264 is what you are looking for. Ah, right. And the TXT substitution XML2RFC offers is broken. Well, more text in the intro=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 16 06:37: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 01CBD3A07A8; Thu, 16 Jul 2020 06:37:28 -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 WjAjiZzPrcAr; Thu, 16 Jul 2020 06:37:26 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 870393A079E; Thu, 16 Jul 2020 06:37:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id DB830333; Thu, 16 Jul 2020 15:37:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id bKjOC1sR7nIf; Thu, 16 Jul 2020 15:37:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Jul 2020 15:37:22 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82BAC20157; Thu, 16 Jul 2020 15:37:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id HJ0cZbht7ymV; Thu, 16 Jul 2020 15:37:22 +0200 (CEST) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 3C17420154; Thu, 16 Jul 2020 15:37:22 +0200 (CEST) Date: Thu, 16 Jul 2020 15:37:21 +0200 From: Juergen Schoenwaelder To: draft-ietf-cbor-date-tag@ietf.org, cbor@ietf.org Message-ID: <20200716133721.j5xduwghxcv4kok3@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 13:37:28 -0000 Thanks for adding new text to -04. I am, however, not sure the text is already resolving all issues. - I do not understand why you reference IEEE Std 1003.1, 2013 Edition [POSIX.1] time epoch 1970-01-01T00:00:00Z UTC if you then say that the timezone is irrelevant. If the timezone is irrelevant, you can simplify things: OLD The epoch chosen for the second tag, which represents days since the Gregorian calendar date 1970-01-01, is related to the IEEE Std 1003.1, 2013 Edition [POSIX.1] time epoch 1970-01-01T00:00:00Z UTC only insofar as both contain the date 1970-01-01. This should not be construed as indicating that dates using this tag represent either a specific time of day and/or time zone. NEW The epoch chosen for the second tag, which represents days since the Gregorian calendar date 1970-01-01. - In the section Comparing Dates, I like to see a clear statement that dates generated by systems in different timezones for the same event may not compare for equality. - I do not understand section 1.3. Perhaps you wanted to say that the representation of date and time values is already defined in section 2.4.1 of RFC 7049? (Of course, one could ask the question why you now introduce a tag for date values but not at the same time also a tag for time values.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 16 07:02: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 5BA8B3A0878; Thu, 16 Jul 2020 07:02:08 -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 omQcXgfKm17p; Thu, 16 Jul 2020 07:02:06 -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 F395C3A086E; Thu, 16 Jul 2020 07:02:05 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 16 Jul 2020 07:02:00 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: , References: <00f701d65adb$1c49e1f0$54dda5d0$@augustcellars.com> <04545D98-A936-4DD0-8446-3634E6C12667@tzi.org> In-Reply-To: <04545D98-A936-4DD0-8446-3634E6C12667@tzi.org> Date: Thu, 16 Jul 2020 07:01:58 -0700 Message-ID: <000e01d65b79$ad6f6ee0$084e4ca0$@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: AQKslLtd3Pxo54N8Z1yW+xXnZNMlgQEImUjfp1VzXAA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Review draft-bormann-cbor-packed-00 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 14:02:08 -0000 > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Wednesday, July 15, 2020 12:43 PM > To: Jim Schaad > Cc: cbor@ietf.org; draft-bormann-cbor-packed@ietf.org > Subject: Re: [Cbor] Review draft-bormann-cbor-packed-00 >=20 > Hi Jim, >=20 > Thanks for this lightning feedback. Let me try to answer as = quickly... >=20 > > On 2020-07-15, at 21:06, Jim Schaad wrote: > > > > Carsten, > > > > I am finding this document really hard to follow. >=20 > Yes. It contains the specification, but not yet any tutorial = material. > Way too few examples. >=20 > > I am sure that we can get > > it to read much better in the future. >=20 > Absolutely. >=20 > > Some of the issues that I am having > > are: > > > > 1. How the Tag 6 is used is dependent on the type of the embedded > > content and this is not explained at all. It took me a while to > > understand why > > #6.6(0) was not a potential duplicate value between sections 2.1 and = 2.2. >=20 > Yes. >=20 > Section 3, second paragraph says this, but that may be a little = late=E2=80=A6 >=20 > (I always read the discussion before the normative part, so I just = didn=E2=80=99t notice.) [JLS] I tend to read documents from the front to the back. =F0=9F=98=8A >=20 > > 2. I am trying to get a handle on where you think this would be = used > > and how much compression is going to give me. >=20 > Use where? Where simple data models exhibit too much sharing, or = where the > strings that go into those have too long common prefixes (which = happens a lot > in RDF-derived environments). > And the point is that there is no need for decompression at the = consumer. >=20 > How much compression? One data point: > http://www.w3.org/2017/07/wot-f2f/slides/w3c-serialization.pdf = =E2=80=94 slide 6. > 1/3 off by sharing, ~ 1/5 more off by prefix compression. 47 % left. > (Deflate gives 29 %, so is 57 % of cbor-packed.) A static dictionary = would help > some more. Yes, but are you willing to settle for ~30% rather than ~33% when = looking at sharing. >=20 > > Part of this is going to be a > > question of how much compression is obtained and the difference > > between optimal and reasonable. >=20 > I you need optimal compression, go for LZ77 over the whole thing. > Cbor-packed is reasonable :-) >=20 > > For example, Tags 224-255 would end up with 2 bytes for the tag, = plus > > the encoding of the suffixed data. Moving to #6.6([#, suffix]) ends > > up with 4 bytes plus the encoding of the suffix. > > This means that you would want to save a minimum of 8 bytes in the > > prefix rather than 4 bytes. You are also going to have two bytes > > consumed in the suffix table for strings. >=20 > Right. That=E2=80=99s why the draft is a bit aggressive about = obtaining 1-byte and 2- > byte references. [JLS] And I think that good-enough could be less aggressive about this. >=20 > > 4. I am having a hard time figuring out how you are going to get a > > reference loop because I was assuming that any shared items that = would > > need to be unpacked would have it's own dictionary defined. >=20 > No, only the top level has shared/prefix items. > Shared/prefix item 5 could reference Shared/prefix item 5 (insert = larger loop > as needed). >=20 > E.g., shared item 0 could be =E2=80=9Csold out=E2=80=9D, and shared = item 1 could be {=E2=80=9Cprice=E2=80=9D: > 9.99, =E2=80=9Cstock=E2=80=9D: simple(0)}. >=20 > > This seems to imply that > > shared items are using the same dictionary. This needs an example. >=20 > Right. Half an example above. [JLS] Yes this is what I expected after coming across the recursion = problem. But this is now also becoming more complicated than just = looking for common strings when building the compression tables. >=20 > > 5. Is there a reason not to switch to using '^' for exponentiation? > > This is the more mathematical one symbol. >=20 > Yes. ^ is XOR in C. > In math, we do that differently. > Like 2=E2=81=B6=E2=81=B4 :-) But the RFC editor won=E2=80=99t let me = do that, I=E2=80=99m sure... >=20 > > 6. As we compose documents nested documents will become more > > frequent. The question is should the multiple levels be merged into = a > > single compression table. >=20 > Well, you could try it, and if it gets longer (because the references = to a larger > dictionary get larger), you don=E2=80=99t. >=20 > > 7. I am not happy about the complete abandonment of providing > > guidance for a packing algorithm. At a minimum things like doing > > advance computing on compression, using pre-defined vocabularies (if > > not dictionaries) is most likely usable. >=20 > Just putting the JSON object labels into a dictionary, sorting by = number of use, > and removing those that are not referenced often enough or where the > references get larger than the actual strings, is often 80 % of the = gain. > My little toy packer (250 LOC) simply tries to share *all* duplicate = sub-items. > The fun comes in if a duplicate sub-item has a sub-item shared with = another > sub-item, which may make referencing the duplicate sub-item less = optimal > than just copying the sub-item. I=E2=80=99m not sure my algorithm is = very sane, but I > like the output, and for the details that=E2=80=99s what we have BYGS = (*) for. [JLS] Well - you might have BYGS but I don't have such a thing. I = suppose that some of it is also going to drop down to local knowledge of = the space. "We know these things tend to occur a lot - use them." >=20 > > 8. Should we provide an option to use an application defined > > dictionary as that would pack even more at the penalty that the > > document could not be unpacked without that dictionary. >=20 > Yes. The question is how that is obtained (from context?), and how = the > dictionary items are merged with those shared items listed in the item = (the > dictionary may or may not have the most frequently used shared items = in the > specific data item to be packed). I wouldn=E2=80=99t want to = COSE-sign a packed CBOR > data item where it is hackable from where the dictionary came... That raises an interesting question. Should one only sign the unpacked = rather than packed version? At this point in time we do not have a = lossy compression so that is probably not a required thing. I had = briefly be thinking about detached signatures where one might merge = compressions. Jim >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > (*) Bright young grad students >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Thu Jul 16 08:58:48 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90043A0B20; Thu, 16 Jul 2020 08:58:46 -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 TmUIcMmFvP9z; Thu, 16 Jul 2020 08:58:45 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650104.outbound.protection.outlook.com [40.107.65.104]) (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 11DD83A0B1F; Thu, 16 Jul 2020 08:58:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZOLDRSlBUaN0BkKVYQdn/xbvfZrazHbtHRbn5Q+XFbVO/e/kj0RXTMMNtO/QmcvX3A7sAEH1hvHl9IYWrNc7Jv/uW/fQcRP4DTerSHim2YCE4j/M2lpKLz/5O5XZYMc0QSe/Kc1+cr8juKCQ4IriXjaEF4sDAvZj21C6vSrrP6g1J7YxE60TMQGhWfhpP3Hq6Vfx2T+qqJGx9VS1oVS2rxQTEIhMGUcZXIRSCG2oZGpqIJ8psApHdMHREhrd7U4uRvrCAoranZDMrQB5jOXKYasOyRVxTo2MEU7vwOIgConscwkKyg+VDsfdNCvR5QQndGS5Yemc6UR1Kx0ZDI1rgQ== 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=weuCINxE6RJO1LTx2D+w4MQYRWynfQJaJ4vgJd6Qpcg=; b=T5jz1BtFg89Q7jvttAP4Yh0wqZIHOURpUfTtvmsNBYMLddyfzgb7k1HT89uF1lVaXHqAmLd8Kdl8Kuhtcqz3n7kOmEaQUiZF90Uf9RBu68vgSuc4UThkk/R5cElHIIMwnVzmWLCpR+KS3BjBrgrff0Vxiw1RLZPw1FR+jAjOfmbsSnTY8TYfQbqXQHXr8od8vlU0EzvDQJXV4dK21/5HM7795/61UJV04pqt6dNIBBNPJK8t14wTot6skrXLwwKsv+Cbgzu2fYqUg7X2VfzgBUC6gJK31xEeC3+65e+rg1T9ufCCy3y/Rp16QAsmMIcdDYAjYiIk7MW9WitoM2G1Iw== 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=weuCINxE6RJO1LTx2D+w4MQYRWynfQJaJ4vgJd6Qpcg=; b=R9LNAkSehys2/n4fumJUXT+ad6FG98X7hSkzsk57sl3jKxxBMse24SVeWGYGY8SOkVKjORw8E76EaVp68dr0hMel5LuroKwkJt7TPx1pbtR0hKQlrqPDlfXxHu2hJS9Y/Rur5FJMqpnse0u1rTlksxo/ds14hdpzhxlNn3yuJfw= Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0779.namprd00.prod.outlook.com (2603:10b6:610:66::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3238.0; Thu, 16 Jul 2020 15:58:43 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::e9ce:b982:5ae1:959d]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::e9ce:b982:5ae1:959d%9]) with mapi id 15.20.3238.000; Thu, 16 Jul 2020 15:58:43 +0000 From: Mike Jones To: Juergen Schoenwaelder , "draft-ietf-cbor-date-tag@ietf.org" , "cbor@ietf.org" Thread-Topic: [EXTERNAL] Re: draft-ietf-cbor-date-tag-02 - handling of time zone offsets Thread-Index: AQHWW3ZCd4TrjNKNT0KsCDscXE0RLKkKWaqQ Date: Thu, 16 Jul 2020 15:58:43 +0000 Message-ID: References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200716133721.j5xduwghxcv4kok3@anna.jacobs.jacobs-university.de> In-Reply-To: <20200716133721.j5xduwghxcv4kok3@anna.jacobs.jacobs-university.de> 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_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-16T15:46:41Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=26f7db71-1994-43c7-99f6-05a78939a4cb; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2578d02e-efdb-4b65-141c-08d829a11d5f x-ms-traffictypediagnostic: CH2PR00MB0779: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oxRFtSsQNSLFmcRvbzL9AR8cYdOUsISw6CboAp7xJyaHiNliqyjgJ1Ce2f8dJ6UrpOBEzfzxhbrAyNgXMB/VNoXfhWBZJDlm+iPKXI6O2h04tGsT/GDaF42P9xNCywgnygMxNBvV84FfiOJV3XZ9SuBSjPyaBwJgZop1amgIvbwT9gTA1lUfbeYCsdL20/NcnZYIMs+7gup8VJPZQOcMVFM27vg67XGh2eTLAdSEo0yyZZ7y/1nJ0dt1SJABiUXvJy2xLk4ylVxTVKcUaN0et9o6nGNVF7oOlhiLpbPt2tAaLGagMVz5Q0UVf0HiQ8j2+KW0JO1X4tqmiQimYo9dmbfHcZshDUwBZp2Og5pxb3+f/pr33FAvQpqnnutGrra9BsHoFQynYuchBcD8iXUaEQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(136003)(396003)(366004)(39860400002)(83380400001)(5660300002)(83080400001)(10290500003)(2906002)(76116006)(33656002)(6506007)(66446008)(53546011)(66946007)(110136005)(71200400001)(52536014)(8676002)(66476007)(26005)(66556008)(64756008)(7696005)(316002)(86362001)(186003)(8990500004)(55016002)(8936002)(478600001)(82950400001)(9686003)(82960400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: xlVE+q7fvW/5OBl0BTgVVXPJ+Bwdpe6eGrjkSbs8WEQO8kWldP8EHNf79G0pd10Py1AS7RrfLke0l9MN6ZzsNyY84abvytfm5OCBH9d/MQoHP3hPXxL1I05CnrcI/rSnDNvpfSYX7W4U/LjagD75CsshvUZNdbVoMM48TAmDj6C+0fqW7apWOFmjd7u5tRX0k6E+N8YTLX1lV+8sqZEq9/tfqE7aNTMziGHu37G4FKdiNRI5r3X1GR+6A7gSOcBgs1wUWjvSpFb3akdYnkmknCjYC+GSINZ+LvkbTfxj0w/qcIk7t4adTxEDefdTuAz2Whrv4LsqIQFoXuSLUz/e0/h8qsgeou4L4uzgKNKvs6JuavQ1TM2ZOh6B6nC8ayVpWCfUQJN8XrdLNUei8kkvuriIitPsYHwEWrGaEZDhLB6T4+tak+Q9Blh+NcWnOk3yw2GPfRX/ZbDvdmkAi188ctVjDB0Iru51H71trHCMZ/jjFVqpeGiX5IQyYy597oXBgqGPaE//tAQgewWRY9RoB5/S++jh3+CTz4a7KwzRMj4rKQ6PDYvX7newai01ialE1UwT//69yp6uyXR/kTWZQjf4vvFcQJcNTqR7Yw1hN9MN7t3C/dyS72swP4bU4hQ2c329DQoEgELAYyj/BP7Gdg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2578d02e-efdb-4b65-141c-08d829a11d5f X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2020 15:58:43.1113 (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: EPJQoOEmXSUBO/MjqizcLIg6OyIn6WI4A2HggTnntrSjQnCeQ+H/EebR5QdQzmee+yMcH0/CJkuMRsSk5cFnsQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0779 Archived-At: Subject: Re: [Cbor] [EXTERNAL] Re: draft-ietf-cbor-date-tag-02 - handling of time zone offsets X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 15:58:47 -0000 Replies inline, prefixed by "Mike>"... -----Original Message----- From: Juergen Schoenwaelder =20 Sent: Thursday, July 16, 2020 6:37 AM To: draft-ietf-cbor-date-tag@ietf.org; cbor@ietf.org Subject: [EXTERNAL] Re: draft-ietf-cbor-date-tag-02 - handling of time zone= offsets Thanks for adding new text to -04. I am, however, not sure the text is alre= ady resolving all issues. - I do not understand why you reference IEEE Std 1003.1, 2013 Edition [POSIX.1] time epoch 1970-01-01T00:00:00Z UTC if you then say that the timezone is irrelevant. If the timezone is irrelevant, you can simplify things: OLD The epoch chosen for the second tag, which represents days since the Gregorian calendar date 1970-01-01, is related to the IEEE Std 1003.1, 2013 Edition [POSIX.1] time epoch 1970-01-01T00:00:00Z UTC only insofar as both contain the date 1970-01-01. This should not be construed as indicating that dates using this tag represent either a specific time of day and/or time zone. NEW The epoch chosen for the second tag, which represents days since the Gregorian calendar date 1970-01-01. Mike> Given that many developers know that the UNIX/POSIX Epoch is 1970-01-= 01T00:00:00Z, others would think it is odd if we *don't* reference it. I b= elieve the current reference text strikes an appropriate balance, saying ho= w they are and are not related. - In the section Comparing Dates, I like to see a clear statement that dates generated by systems in different timezones for the same event may not compare for equality. Mike> OK - I do not understand section 1.3. Perhaps you wanted to say that the representation of date and time values is already defined in section 2.4.1 of RFC 7049? (Of course, one could ask the question why you now introduce a tag for date values but not at the same time also a tag for time values.) Mike> 1.3 was added in response to comments by Jim Schaad - also with input= from Carsten Bormann and is about comparing dates and times. As to why ta= gs weren't added for time values - there was a present use case for date va= lues and there wasn't for time values. Another spec can always define and = add such tags to the registry in the future. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 16 09:10:54 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 2C57E3A0B63; Thu, 16 Jul 2020 09:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 boLF77IUxN8K; Thu, 16 Jul 2020 09:10:49 -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 A7E343A0B60; Thu, 16 Jul 2020 09:10:48 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B6zkZ29l6zyjR; Thu, 16 Jul 2020 18:10:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Thu, 16 Jul 2020 18:10:45 +0200 Cc: Juergen Schoenwaelder , "draft-ietf-cbor-date-tag@ietf.org" , "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 616608645.20192-3ba50fcb56b85c4ab86ac207cabb25f7 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200716133721.j5xduwghxcv4kok3@anna.jacobs.jacobs-university.de> To: Mike Jones X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] [EXTERNAL] Re: draft-ietf-cbor-date-tag-02 - handling of time zone offsets X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 16:10:52 -0000 On 2020-07-16, at 17:58, Mike Jones = wrote: >=20 > Mike> 1.3 was added in response to comments by Jim Schaad - also with = input from Carsten Bormann and is about comparing dates and times. As to = why tags weren't added for time values - there was a present use case = for date values and there wasn't for time values. Another spec can = always define and add such tags to the registry in the future. Actually, Joerg=E2=80=99s initial proposal included numeric date, = numeric time-of-day, and timezone (using timezone database IDs). Numeric date was extracted from that for this draft, but we certainly = want to come back to the rest of the proposal. .oOo. As a general comment, we really have to work on some terminology here. Date (the new tags): a concept related to calendars Date-time (Tags 0, 1, 1001): anchored on a time scale (which usually = relates to calendars via time zones) Time-of-day (todo, also usually needs time zones) These things are related in complicated ways. They become more = complicated when they don=E2=80=99t just document a past event, but = actually are trying to schedule into the future; recurrent schedules = being even more complicated. (=E2=80=9CTime=E2=80=9D is ambiguous, because some people think it is = time-of-day, others think it is a date-time or time on a timescale that = uses another epoch, such as Posix-time. So let=E2=80=99s use more = specific terms whenever possible.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 16 10:49:03 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 6449F3A09DA; Thu, 16 Jul 2020 10:49:01 -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, NICE_REPLY_A=-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 QcuXwlwbD5Ce; Thu, 16 Jul 2020 10:48:59 -0700 (PDT) Received: from mail-edgeS23.fraunhofer.de (mail-edges23.fraunhofer.de [153.97.7.23]) (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 696AE3A09D3; Thu, 16 Jul 2020 10:48:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EbBgDtkRBf/xwBYJlgHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFKAoF5gR6BMwqEKZEOm34LCwEBAQEBAQEBAQYBARgLCgIEAQEChEo?= =?us-ascii?q?CghUBJDgTAhABAQYBAQEBAQYEAgKGRAxDARABgnyBAwEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEWAkNVEgEBHQEBAQECAQEBIQ8BBTYLBQsJAg4KAgImAgInIBAGAQw?= =?us-ascii?q?BBQIBAYJXSwGCXB8FC487mwR2gTKFUYM4gToGgQ4qAYY+hjMPgUw/gREnD4J?= =?us-ascii?q?aPoJcAQEBAYE0gz+CYASSSqJDKAeBWYEHgQcEC5g+BQoekS0Gjg4rhRqMN55?= =?us-ascii?q?9AgQCCQIVgWpogRNNJE+CaVAXAg2HfoZXiE6FRHICATQCBgEHAQEDCXyBVos?= =?us-ascii?q?QgTUBgRABAQ?= X-IPAS-Result: =?us-ascii?q?A2EbBgDtkRBf/xwBYJlgHQEBAQEJARIBBQUBQIFKAoF5g?= =?us-ascii?q?R6BMwqEKZEOm34LCwEBAQEBAQEBAQYBARgLCgIEAQEChEoCghUBJDgTAhABA?= =?us-ascii?q?QYBAQEBAQYEAgKGRAxDARABgnyBAwEBAQEBAQEBAQEBAQEBAQEBAQEWAkNVE?= =?us-ascii?q?gEBHQEBAQECAQEBIQ8BBTYLBQsJAg4KAgImAgInIBAGAQwBBQIBAYJXSwGCX?= =?us-ascii?q?B8FC487mwR2gTKFUYM4gToGgQ4qAYY+hjMPgUw/gREnD4JaPoJcAQEBAYE0g?= =?us-ascii?q?z+CYASSSqJDKAeBWYEHgQcEC5g+BQoekS0Gjg4rhRqMN559AgQCCQIVgWpog?= =?us-ascii?q?RNNJE+CaVAXAg2HfoZXiE6FRHICATQCBgEHAQEDCXyBVosQgTUBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,360,1589234400"; d="scan'208";a="19115362" Received: from mail-mtaka28.fraunhofer.de ([153.96.1.28]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2020 19:48:54 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEBQCrkhBf/1lIDI1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUoCgXkvbwNUMCwKhCmRD5wJCwEDAQEBAQEGAQEYCwoCBAE?= =?us-ascii?q?BhEwCghMCJDgTAhABAQUBAQECAQYEbYVbDEMBEAGFGgEBAQECAQEBIQ8BBTY?= =?us-ascii?q?LBQsJAg4KAgImAgInIBAGAQwBBQIBAYJXSwGCXCQLjzybBHaBMoVRgzSBOga?= =?us-ascii?q?BDioBhj6GMw+BTD+BEScPglo+glwBAQEBgTSDP4JgBJJKokMoB4FZgQeBBwQ?= =?us-ascii?q?LmD4FCh6RLQaODiuFGow3nn0CBAIJAhWBaiNEgRNNJE+CaVAXAg2HfoZXiE6?= =?us-ascii?q?FREExAgE0AgYBBwEBAwl8gVaLEIE1AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.75,360,1589234400"; d="scan'208";a="30952547" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA28.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2020 19:48:52 +0200 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 06GHmnHu012283 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Thu, 16 Jul 2020 19:48:51 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 16 Jul 2020 19:48:44 +0200 To: Carsten Bormann , Mike Jones CC: "draft-ietf-cbor-date-tag@ietf.org" , "cbor@ietf.org" , Juergen Schoenwaelder References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200716133721.j5xduwghxcv4kok3@anna.jacobs.jacobs-university.de> From: Henk Birkholz Message-ID: <88c9f054-66f5-565c-ed2c-bb8779add10a@sit.fraunhofer.de> Date: Thu, 16 Jul 2020 19:48:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 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.156.41] Archived-At: Subject: Re: [Cbor] [EXTERNAL] Re: draft-ietf-cbor-date-tag-02 - handling of time zone offsets X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 17:49:01 -0000 On 16.07.20 18:10, Carsten Bormann wrote: > On 2020-07-16, at 17:58, Mike Jones wrote: >> >> Mike> 1.3 was added in response to comments by Jim Schaad - also with input from Carsten Bormann and is about comparing dates and times. As to why tags weren't added for time values - there was a present use case for date values and there wasn't for time values. Another spec can always define and add such tags to the registry in the future. > > Actually, Joerg’s initial proposal included numeric date, numeric time-of-day, and timezone (using timezone database IDs). > > Numeric date was extracted from that for this draft, but we certainly want to come back to the rest of the proposal. > > .oOo. > > As a general comment, we really have to work on some terminology here. +1 (to no big surprise, I'd assume) But where would that text go? (or better, to which Appendix) Falso see: https://www.ietf.org/timezones/data/theory.html > > Date (the new tags): a concept related to calendars > Date-time (Tags 0, 1, 1001): anchored on a time scale (which usually relates to calendars via time zones) > Time-of-day (todo, also usually needs time zones) We were already talking about the first two and there were already some questions about the "why" (...someone would want to make a strict differentiation here, how it would look like) and "what" exactly. Time-of-day is adding a bit complexity to the confusion, I am afraid: It always comes with a scope, I think. If the scope is around a single clock instead multiples, the meaning of it changes. Effectively, time-of-day is a relative timescale with 86400 seconds (for a solar day, not sidereal day), its own epoch, and that does not require a time zone, if the scope is limited to a single clock. > These things are related in complicated ways. They become more complicated when they don’t just document a past event, but actually are trying to schedule into the future; recurrent schedules being even more complicated. Multiple timescales use the same epoch, but arrive at different time values at a given point in time (https://www.ietf.org/timezones/data/leap-seconds.list). Some of the complexity could be addressed with some good expositional text. Maybe in time-tag? > > (“Time” is ambiguous, because some people think it is time-of-day, others think it is a date-time or time on a timescale that uses another epoch, such as Posix-time. So let’s use more specific terms whenever possible.) > > Grüße, Carsten > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > From nobody Thu Jul 16 17:19:26 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 3500D3A0E4C for ; Thu, 16 Jul 2020 17:19:25 -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 csM5Iixn378H for ; Thu, 16 Jul 2020 17:19:22 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650138.outbound.protection.outlook.com [40.107.65.138]) (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 E7A963A0A26 for ; Thu, 16 Jul 2020 17:19:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XPb1NU+DM3QIYmSkbcaTj2dik8agE5T6wS5tHqtMSVYoD1u9a5ZU8z3E3ehUfMceNk6ZXU2O7g1ZOLhV6lSI3xLxHWiTRPfikY8NbmMqGdvfRrowiP5jaljPGTmgR+Ha2S0vpwuLri5T/MJ+O1ZpUCY/VSK2Hi4Wc7esF5V8tgb1wPrDwEUQcJHmsZOJ90xEFl6JL7ww4/z2eAbNfozzBslSqWhiwVRW7du6HoQ4azR5YGd9pV6Ex0onU0WfipaA0qvVGSgd+i+q71z5bKU2Bv+pnSIEVnuzYZFG5/tF139U/bqJMqbu3dUZpgfnM4pQEb+LGHIaUizPc9bjXCqDhw== 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=1y8YEM+DmDY1HBZ9Zk65OzIMf1cr8y7AAvQG1IZYbfo=; b=lGowkBcc8UYLsJT3jrxpJMEkh0sFInCu3+qZEr0hQ8QR+sInPy4T9O2/R8TUf1kHb4LFwph824QXkuLW3K1msamT2UGYbW17S7c5KhAxXcbyU3E3oOpyzrjSCVjdv6Q2ZooSEk7Fe3UmK9i4KOdYXgXCBDmKM8wLWZyIvF50byYXlZBq5chD3OdbtwaDwM6Y5NxnrjupujIAprHvhlHOTvlQO2RJHprM414EpHaKzr4F4qanTwnSW7ecWGTnT9wHtZWmut+fEKqxZyU7DVlYr+Gfou77qgXZbzeThH4KXr0L5V8/l6oYeY+9p6QmVoUpbgj++MOJL2I3YzgJsejeAA== 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=1y8YEM+DmDY1HBZ9Zk65OzIMf1cr8y7AAvQG1IZYbfo=; b=dIJbH5EttcJlhJldaSNPuil/rBOxG/Jjz/xmygiD0hRjmD7SXWC8E44BIgviJwHYvb2NQjOpZs4OdnQKUb7VrBOf6Ii4uYVKM+TbSuJ5s+1B02YtFQ3OQsqmDOKvZxLUETpkpZed8aLmWmRynXuvxG1zEvfPdMluWw0ALeES2sc= Received: from BY5PR00MB0676.namprd00.prod.outlook.com (2603:10b6:a03:20c::15) by BY5PR00MB0760.namprd00.prod.outlook.com (2603:10b6:a03:1d1::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3235.0; Fri, 17 Jul 2020 00:19:18 +0000 Received: from BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::69f8:4b45:77f9:5db4]) by BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::69f8:4b45:77f9:5db4%7]) with mapi id 15.20.3240.000; Fri, 17 Jul 2020 00:19:13 +0000 From: Mike Jones To: "barryleiba@computer.org" CC: "cabo@tzi.org" , Juergen Schoenwaelder , "cbor@ietf.org" Thread-Topic: Please post draft-ietf-cbor-date-tag-05 Thread-Index: AdZbzyr7cAysZx4ZRcWuBux45zqADQ== Date: Fri, 17 Jul 2020 00:19:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-17T00:13:08Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=f1041d69-df88-4b97-85fb-9f070cc44820; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: computer.org; dkim=none (message not signed) header.d=none; computer.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6bd90123-6877-45f8-aaca-08d829e708d7 x-ms-traffictypediagnostic: BY5PR00MB0760: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 64RxrIUKaQ/0X21WCbxjiMGG55k8qmMP8peH6Eo5FuLYt8JG3bm3XGSF9UKF4PwyeG51GnUrMUlFu3jGwdOOaQcLN5bJd9FoFUSpf3LcHV6tUYY9epjnX4zHYFdmnQ+gGz10ogv3UG34xpOUz2BFVu9BOUuMx6WITMmjuHLdn1pfKFFGz8kovl8kATvKMJ1JVoSceKmVlxCNPRKHDR1GoQvpMrxs4fwW/DlP9aK6H1NCOlKUDfdKrXAqGbTHdArVxDuUjJ6GbVVLwvHyPWgO7eJKEA+59i04Kj08RK8Ry7/RwGTpfCtI788o6Vq1NTgla+dicKTvVBHGriXSBT8OyQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR00MB0676.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(396003)(366004)(136003)(346002)(4326008)(478600001)(33656002)(55016002)(6916009)(2906002)(64756008)(66446008)(76116006)(66946007)(66576008)(66476007)(66556008)(9686003)(54906003)(7696005)(316002)(186003)(26005)(6506007)(10290500003)(8676002)(9326002)(8936002)(4744005)(82960400001)(8990500004)(52536014)(71200400001)(86362001)(82950400001)(5660300002)(99936003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: sGcOl5tI8paidblyfek9mezmB6lz2N8rcD7NldF/MjjvoXOdNTiY27rE+Twb7FI40pGFeJ1I670nenAA9BM2us2Vq+sCLXIktJr9XRJ3a3yf7210JF+LIVuaeDuPxkEfTqcNxXq64AzvWLdOGxhRqkxuTrHko2Op7X1sPzEcuJZFOSkljv8q3ZF0ok6Ak8ON+iTGdmBSk/nAVOuiOl68M3hmvWom0GuxdEvN1vRSICncqJhGHOfBnn0eCIKh5xNauwd/8Cprj7r3OQ0CMfNPUVanLU21N0ehhwl6h/4Er27SOga1/ua/+IJJ2Jvez/lHELIQE9kRFrv/bB6TrtmVAtPbxz4tP3VVMui/RCb9E7XGAdtvtga80WHl02IjD3QQdKlO69y0X5fd1y4zTTPSE6E04eVO47Iq/Qwa9SeQ9JllAaiWaIFJUR8dnCN7u11HN4HsuzisqtokaLsvMHwp1DsmyRTltN80BUqkr8Hck10JBjP24rGUtDbxdo+iV3E+7PHYBaO4kVUpvkX4ZigAKcCCGyqSEdy9gWldNb0If1Gd3VrJu2LwUonPjZdl6nkerxydNw8bUnJ9p8MlvKfXlgIMshQVrQoMJU8laylSSqTE+3btnYHfkAZPczPQIRqQ+SXoQEmUgAtMLn48umqXMA== x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_005_BY5PR00MB06769A4EE70D2072492AB907F57C0BY5PR00MB0676namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR00MB0676.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6bd90123-6877-45f8-aaca-08d829e708d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2020 00:19:13.3828 (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: OeA2IFJ6vPh92WcMxX13RReZdxs7WEkhNWrUJ/rWV9eXdUNXdyqDr8nNCj5mRn//c8lMk7z/ohMUjpYjR8SrlA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR00MB0760 Archived-At: Subject: [Cbor] Please post draft-ietf-cbor-date-tag-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 00:19:25 -0000 --_005_BY5PR00MB06769A4EE70D2072492AB907F57C0BY5PR00MB0676namp_ Content-Type: multipart/alternative; boundary="_000_BY5PR00MB06769A4EE70D2072492AB907F57C0BY5PR00MB0676namp_" --_000_BY5PR00MB06769A4EE70D2072492AB907F57C0BY5PR00MB0676namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Barry, Can I please ask you to have the secretariat post draft-ietf-cbor-date-tag-= 05 (attached)? It contains the changes discussed during the working group = meeting yesterday, plus adds a clarifying statement suggested by Juergen Sc= hoenwaelder. Carsten, I really like having the table of examples that you suggested! -- Mike --_000_BY5PR00MB06769A4EE70D2072492AB907F57C0BY5PR00MB0676namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Barry,

 

Can I please ask you to have the secretariat post dr= aft-ietf-cbor-date-tag-05 (attached)?  It contains the changes discuss= ed during the working group meeting yesterday, plus adds a clarifying state= ment suggested by Juergen Schoenwaelder.

 

Carsten, I really like having the table of examples = that you suggested!

 

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

 

--_000_BY5PR00MB06769A4EE70D2072492AB907F57C0BY5PR00MB0676namp_-- --_005_BY5PR00MB06769A4EE70D2072492AB907F57C0BY5PR00MB0676namp_ Content-Type: application/xml; name="draft-ietf-cbor-date-tag-05.xml" Content-Description: draft-ietf-cbor-date-tag-05.xml Content-Disposition: attachment; filename="draft-ietf-cbor-date-tag-05.xml"; size=13167; creation-date="Fri, 17 Jul 2020 00:17:00 GMT"; modification-date="Fri, 17 Jul 2020 00:17:00 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz4KCjw/eG1sLXN0eWxlc2hlZXQg dHlwZT0ndGV4dC94c2wnIGhyZWY9J2h0dHA6Ly94bWwycmZjLnRvb2xzLmlldGYub3JnL2F1dGhv cmluZy9yZmMyNjI5LnhzbHQnID8+CjwhRE9DVFlQRSByZmMgU1lTVEVNICJyZmMyNjI5LmR0ZCI+ Cgo8P3JmYyB0b2M9InllcyI/Pgo8P3JmYyB0b2NvbXBhY3Q9InllcyI/Pgo8P3JmYyB0b2NkZXB0 aD0iNCI/Pgo8P3JmYyB0b2NpbmRlbnQ9InllcyI/Pgo8P3JmYyBzeW1yZWZzPSJ5ZXMiPz4KPD9y ZmMgc29ydHJlZnM9InllcyI/Pgo8P3JmYyBjb21wYWN0PSJ5ZXMiPz4KPD9yZmMgc3ViY29tcGFj dD0ibm8iPz4KCjxyZmMgY2F0ZWdvcnk9InN0ZCIgCiAgICAgaXByPSJ0cnVzdDIwMDkwMiIgCiAg ICAgZG9jTmFtZT0iZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTA1Ij4KICA8ZnJvbnQ+CgogICAg PHRpdGxlIGFiYnJldj0iQ0JPUiBUYWcgZm9yIERhdGUiPkNvbmNpc2UgQmluYXJ5IE9iamVjdCBS ZXByZXNlbnRhdGlvbiAoQ0JPUikgVGFncyBmb3IgRGF0ZTwvdGl0bGU+CgogICAgPGF1dGhvciBm dWxsbmFtZT0iTWljaGFlbCBCLiBKb25lcyIgc3VybmFtZT0iSm9uZXMiIGluaXRpYWxzPSJNLkIu Ij4KICAgICAgPG9yZ2FuaXphdGlvbj5NaWNyb3NvZnQ8L29yZ2FuaXphdGlvbj4KICAgICAgPGFk ZHJlc3M+Cgk8ZW1haWw+bWJqQG1pY3Jvc29mdC5jb208L2VtYWlsPgoJPHVyaT5odHRwczovL3Nl bGYtaXNzdWVkLmluZm8vPC91cmk+CiAgICAgIDwvYWRkcmVzcz4KICAgIDwvYXV0aG9yPgoKICAg IDxhdXRob3IgZnVsbG5hbWU9IkFudGhvbnkgTmFkYWxpbiIgaW5pdGlhbHM9IkEuIiBzdXJuYW1l PSJOYWRhbGluIj4KICAgICAgPG9yZ2FuaXphdGlvbj5NaWNyb3NvZnQ8L29yZ2FuaXphdGlvbj4K ICAgICAgPGFkZHJlc3M+CiAgICAgICAgPGVtYWlsPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvZW1h aWw+CiAgICAgIDwvYWRkcmVzcz4KICAgIDwvYXV0aG9yPgoKICAgIDxhdXRob3IgZnVsbG5hbWU9 IkrDtnJnIFJpY2h0ZXIiIGluaXRpYWxzPSJKLiIgc3VybmFtZT0iUmljaHRlciI+CiAgICAgIDxv cmdhbml6YXRpb24+cGR2IEZpbmFuY2lhbCBTb2Z0d2FyZSBHbWJIPC9vcmdhbml6YXRpb24+CiAg ICAgIDxhZGRyZXNzPgoJPGVtYWlsPmpvZXJnLnJpY2h0ZXJAcGR2LWZzLmRlPC9lbWFpbD4KICAg ICAgPC9hZGRyZXNzPgogICAgPC9hdXRob3I+CgogICAgPGRhdGUgZGF5PSIxNiIgbW9udGg9Ikp1 bHkiIHllYXI9IjIwMjAiIC8+CgogICAgPGFyZWE+QXBwbGljYXRpb25zPC9hcmVhPgogICAgPHdv cmtncm91cD5DQk9SIFdvcmtpbmcgR3JvdXA8L3dvcmtncm91cD4KCiAgICA8a2V5d29yZD5Db21w YWN0IEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb248L2tleXdvcmQ+CiAgICA8a2V5d29yZD5D Qk9SPC9rZXl3b3JkPgogICAgPGtleXdvcmQ+VGFnPC9rZXl3b3JkPgogICAgPGtleXdvcmQ+RGF0 ZTwva2V5d29yZD4KICAgIDxrZXl3b3JkPkludGVybmV0LURyYWZ0PC9rZXl3b3JkPgoKICAgIDxh YnN0cmFjdD4KICAgICAgPHQ+CglUaGUgQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0 aW9uIChDQk9SLCBSRkMgNzA0OSkgaXMgYSBkYXRhCglmb3JtYXQgd2hvc2UgZGVzaWduIGdvYWxz IGluY2x1ZGUgdGhlIHBvc3NpYmlsaXR5IG9mIGV4dHJlbWVseSBzbWFsbAoJY29kZSBzaXplLCBm YWlybHkgc21hbGwgbWVzc2FnZSBzaXplLCBhbmQgZXh0ZW5zaWJpbGl0eSB3aXRob3V0IHRoZQoJ bmVlZCBmb3IgdmVyc2lvbiBuZWdvdGlhdGlvbi4KICAgICAgPC90PgogICAgICA8dD4KCUluIENC T1IsIG9uZSBwb2ludCBvZiBleHRlbnNpYmlsaXR5IGlzIHRoZSBkZWZpbml0aW9uIG9mIENCT1Ig dGFncy4KCVJGQyA3MDQ5IGRlZmluZXMgdHdvIHRhZ3MgZm9yIHRpbWU6CglDQk9SIHRhZyAwIChS RkMgMzMzOSBkYXRlL3RpbWUgc3RyaW5nKQoJYW5kIHRhZyAxIChQb3NpeCAic2Vjb25kcyBzaW5j ZSB0aGUgZXBvY2giKS4KCVNpbmNlIHRoZW4sIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIGhhdmUg YmVjb21lIGtub3duLgoJVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSBDQk9SIHRhZyBmb3Ig YW4gUkZDIDMzMzkgZGF0ZSB0ZXh0IHN0cmluZywKCWZvciBhcHBsaWNhdGlvbnMgbmVlZGluZyBh IHRleHR1YWwgZGF0ZSByZXByZXNlbnRhdGlvbgoJd2l0aGluIHRoZSBHcmVnb3JpYW4gY2FsZW5k YXIgd2l0aG91dCBhIHRpbWUuCglJdCBhbHNvIGRlZmluZXMgYSBDQk9SIHRhZyBmb3IgZGF5cyBz aW5jZSB0aGUgZGF0ZSAxOTcwLTAxLTAxIGluIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIKCWZvciBh cHBsaWNhdGlvbnMgbmVlZGluZyBhIG51bWVyaWMgZGF0ZSByZXByZXNlbnRhdGlvbiB3aXRob3V0 IGEgdGltZS4KCVRoaXMgc3BlY2lmaWNhdGlvbiBpcyBpbnRlbmRlZCBhcyB0aGUgcmVmZXJlbmNl IGRvY3VtZW50IGZvciBJQU5BIHJlZ2lzdHJhdGlvbgoJb2YgdGhlIENCT1IgdGFncyBkZWZpbmVk LgogICAgICA8L3Q+CiAgICA8L2Fic3RyYWN0PgogIDwvZnJvbnQ+CiAgPG1pZGRsZT4KICAgIDxz ZWN0aW9uIGFuY2hvcj0iSW50cm9kdWN0aW9uIiB0aXRsZT0iSW50cm9kdWN0aW9uIj4KICAgICAg PHQ+CglUaGUgQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIChDQk9SKSA8eHJl ZiB0YXJnZXQ9IlJGQzcwNDkiLz4KCXByb3ZpZGVzIGZvciB0aGUgaW50ZXJjaGFuZ2Ugb2Ygc3Ry dWN0dXJlZCBkYXRhCgl3aXRob3V0IGEgcmVxdWlyZW1lbnQgZm9yIGEgcHJlLWFncmVlZCBzY2hl bWEuCglSRkMgNzA0OSBkZWZpbmVzIGEgYmFzaWMgc2V0IG9mIGRhdGEgdHlwZXMsIGFzIHdlbGwg YXMgYSB0YWdnaW5nIG1lY2hhbmlzbQoJdGhhdCBlbmFibGVzIGV4dGVuZGluZyB0aGUgc2V0IG9m IGRhdGEgdHlwZXMgc3VwcG9ydGVkIHZpYSBhbiBJQU5BIHJlZ2lzdHJ5LgogICAgICA8L3Q+CiAg ICAgIDx0PgoJVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSBDQk9SIHRhZyBmb3IgYSB0ZXh0 IHN0cmluZyByZXByZXNlbnRpbmcgYSBkYXRlIHdpdGhvdXQgYSB0aW1lLgoJVGhlIHRhZ2dlZCB0 ZXh0IHN0cmluZyBpcyByZXByZXNlbnRlZCBhcyBzcGVjaWZpZWQgYnkgdGhlIFJGQyAzMzM5IDx4 cmVmIHRhcmdldD0iUkZDMzMzOSIvPgoJPHNwYW54IHN0eWxlPSJ2ZXJiIj5mdWxsLWRhdGU8L3Nw YW54PiBwcm9kdWN0aW9uLgoJUGVyIFJGQyAzMzM5LCB0aGlzIHJlcHJlc2VudHMgYSBkYXRlIHdp dGhpbiB0aGUgR3JlZ29yaWFuIGNhbGVuZGFyLgogICAgICA8L3Q+CiAgICAgIDx0PgoJVGhpcyBz cGVjaWZpY2F0aW9uIGFsc28gZGVmaW5lcyBhIENCT1IgdGFnIGZvciBhbiBpbnRlZ2VyIHJlcHJl c2VudGluZyBhIGRhdGUgd2l0aG91dCBhIHRpbWUuCglUaGUgdGFnZ2VkIGludGVnZXIgaXMgYW4g dW5zaWduZWQgb3IgbmVnYXRpdmUgdmFsdWUgaW5kaWNhdGluZyB0aGUgbnVtYmVyIG9mIGRheXMK CXNpbmNlIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIgZGF0ZSAxOTcwLTAxLTAxLgoJQXMgYW4gaW1w bGVtZW50YXRpb24gbm90ZSwgdGhpcyB2YWx1ZSBoYXMgYSBjb25zdGFudCBvZmZzZXQgZnJvbSB0 aGUgTW9kaWZpZWQgSnVsaWFuIERhdGUgdmFsdWUKCSh3aGljaCBpcyBkZWZpbmVkIGJ5IHRoZSBT bWl0aHNvbmlhbiBBc3Ryb3BoeXNpY2FsIE9ic2VydmF0b3J5IGFzIHRoZSBudW1iZXIgb2YgZGF5 cyBzaW5jZQoJTm92ZW1iZXIgMTcsIDE4NTgpOyB0aGlzIHZhbHVlIGlzIHRoZSBNb2RpZmllZCBK dWxpYW4gRGF0ZSBtaW51cyA0MDU4Ny4KICAgICAgPC90PgogICAgICA8dD4KCU5vdGUgdGhhdCBz aW5jZSBib3RoIHRhZ3MgYXJlIGZvciBkYXRlcyB3aXRob3V0IHRpbWVzLAoJdGltZXMgb2YgZGF5 LCB0aW1lIHpvbmVzLCBhbmQgbGVhcCBzZWNvbmRzIGFyZSBub3QgYXBwbGljYWJsZSB0byB0aGVz ZSB2YWx1ZXMuCglUaGVzZSB0YWdzIGFyZSBib3RoIGZvciByZXByZXNlbnRhdGlvbnMgb2YgR3Jl Z29yaWFuIGNhbGVuZGFyIGRhdGVzLgogICAgICA8L3Q+Cgo8IS0tIE5vIFJGQyAyMTE5IGtleXdv cmRzIGFyZSB1c2VkIGluIHRoaXMgZG9jdW1lbnQuCiAgICAgIDxzZWN0aW9uIGFuY2hvcj0icm5j IiB0aXRsZT0iUmVxdWlyZW1lbnRzIE5vdGF0aW9uIGFuZCBDb252ZW50aW9ucyI+CiAgICAgICAg PHQ+CgkgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hB TEwiLCAiU0hBTEwgTk9UIiwKCSAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVE IiwgIk5PVCBSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQKCSAgIk9QVElPTkFMIiBpbiB0aGlzIGRv Y3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4KCSAgQkNQIDE0IDx4 cmVmIHRhcmdldD0iUkZDMjExOSIvPiA8eHJlZiB0YXJnZXQ9IlJGQzgxNzQiLz4gd2hlbiwgYW5k CgkgIG9ubHkgd2hlbiwgdGhleSBhcHBlYXIgaW4gYWxsIGNhcGl0YWxzLCBhcyBzaG93biBoZXJl LgoJPC90PgogICAgICA8L3NlY3Rpb24+Ci0tPgoKICAgICAgPHNlY3Rpb24gYW5jaG9yPSJDYWxl bmRhckRhdGVzIiB0aXRsZT0iQ2FsZW5kYXIgRGF0ZXMiPgoJPHQ+CgkgIENhbGVuZGFyIGRhdGVz IGFyZSB1c2VkIGZvciBudW1lcm91cyBodW1hbiB1c2UgY2FzZXMsCgkgIHN1Y2ggYXMgbWFya2lu ZyB0aGUgZGF0ZXMgb2Ygc2lnbmlmaWNhbnQgZXZlbnRzLgoJICBGb3IgaW5zdGFuY2UsIEpvaG4g TGVubm9uIHdhcyBib3JuIG9uIE9jdG9iZXIgOSwgMTk0MCBhbmQgZGllZCBvbiBEZWNlbWJlciA4 LCAxOTgwLgoJICBPbmUgc3VjaCB1c2UgY2FzZSBpcyBkcml2ZXIncyBsaWNlbnNlcywgd2hpY2gg dHlwaWNhbGx5IGluY2x1ZGUgYSBkYXRlIG9mIGJpcnRoLgoJICBUaGUgZGF0ZXMgdXNlZCBpbiB0 aGlzIHNwZWNpZmljYXRpb24gdXNlIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIsCgkgIGFzIGRvIHRo b3NlIGluIFJGQyAzMzM5IDx4cmVmIHRhcmdldD0iUkZDMzMzOSIvPi4KCSAgVGhlIHRpbWUgem9u ZXMgYW5kIGFjdHVhbCB0aW1lcyBvZiB0aGVzZSBldmVudHMgYXJlIGludGVudGlvbmFsbHkgbm90 IHJlcHJlc2VudGVkIGluIHRoZSBjYWxlbmRhciBkYXRlLgoJPC90PgoJPHQ+CgkgIFRoZSBlcG9j aCBjaG9zZW4gZm9yIHRoZSBzZWNvbmQgdGFnLCB3aGljaCByZXByZXNlbnRzIGRheXMgc2luY2Ug dGhlIEdyZWdvcmlhbiBjYWxlbmRhciBkYXRlIDE5NzAtMDEtMDEsCgkgIGlzIHJlbGF0ZWQgdG8g dGhlIDx4cmVmIHRhcmdldD0iUE9TSVguMSI+SUVFRSBTdGQgMTAwMy4xLCAyMDEzIEVkaXRpb248 L3hyZWY+IHRpbWUgZXBvY2gKCSAgMTk3MC0wMS0wMVQwMDowMDowMFogVVRDIG9ubHkgaW5zb2Zh ciBhcyBib3RoIGNvbnRhaW4gdGhlIGRhdGUgMTk3MC0wMS0wMS4KCSAgVGhpcyBzaG91bGQgbm90 IGJlIGNvbnN0cnVlZCBhcyBpbmRpY2F0aW5nIHRoYXQgZGF0ZXMgdXNpbmcgdGhpcyB0YWcKCSAg cmVwcmVzZW50IGVpdGhlciBhIHNwZWNpZmljIHRpbWUgb2YgZGF5IGFuZC9vciB0aW1lIHpvbmUu Cgk8L3Q+Cgk8dD4KCSAgVGhlIGRheSBvZiB0aGUgd2VlayAoU3VuZGF5LCBNb25kYXksIFR1ZXNk YXksIGV0Yy4pIGlzIG5vdCBleHBsaWNpdGx5IHJlcHJlc2VudGVkCgkgIGluIGVpdGhlciBvZiB0 aGVzZSBkYXRlIGZvcm1hdHMuCgkgIEhvd2V2ZXIsIGRldGVybWluaXN0aWMgYWxnb3JpdGhtcyB0 aGF0IGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbgoJICBjYW4gYmUg dXNlZCB0byBkZXJpdmUgdGhlIGRheSBvZiB0aGUgd2VlayBpbiB0aGUgR3JlZ29yaWFuIGNhbGVu ZGFyCgkgIGZyb20gZGF0ZXMgcmVwcmVzZW50ZWQgaW4gYm90aCBvZiB0aGVzZSBmb3JtYXRzLgoJ PC90PgoKCTxzZWN0aW9uIGFuY2hvcj0iRXhhbXBsZXMiIHRpdGxlPSJFeGFtcGxlIERhdGUgUmVw cmVzZW50YXRpb25zIj4KCSAgPHQ+CgkgICAgVGhpcyB0YWJsZSBjb250YWlucyBleGFtcGxlIHJl cHJlc2VudGF0aW9ucyBmb3IgZGF0ZXMgdXNpbmcgYm90aCB0YWdzLgoJICA8L3Q+CgoJICA8dGV4 dHRhYmxlPgoKCSAgICA8dHRjb2wgYWxpZ249ImxlZnQiPkRhdGU8L3R0Y29sPgoJICAgIDx0dGNv bCBhbGlnbj0ibGVmdCI+VGFnIDEwMDQ8L3R0Y29sPgoJICAgIDx0dGNvbCBhbGlnbj0ibGVmdCI+ VGFnIDEwMDwvdHRjb2w+CgoJICAgIDxjPk9jdG9iZXIgOSwgMTk0MDwvYz4KCSAgICA8Yz4iMTk0 MC0xMC0wOSI8L2M+CgkgICAgPGM+LTEwNjc2PC9jPgoKCSAgICA8Yz5EZWNlbWJlciA4LCAxOTgw PC9jPgoJICAgIDxjPiIxOTgwLTEyLTA4IjwvYz4KCSAgICA8Yz4zOTk0PC9jPgoKCSAgPC90ZXh0 dGFibGU+Cgk8L3NlY3Rpb24+CgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiBhbmNo b3I9IkNvbXBhcmluZ0RhdGVzIiB0aXRsZT0iQ29tcGFyaW5nIERhdGVzIj4KCTx0PgoJICBDb21w YXJpc29uIG9mIGRhdGVzIGluIDxzcGFueCBzdHlsZT0idmVyYiI+ZnVsbC1kYXRlPC9zcGFueD4g Zm9ybWF0IGNhbiBiZSBhY2NvbXBsaXNoZWQgYnkKCSAgbm9ybWFsIHN0cmluZyBjb21wYXJpc29u LCBzaW5jZSBieSBkZXNpZ24sIHRoZSBkaWdpdHMgcmVwcmVzZW50aW5nIHRoZSBkYXRlIGFyZSBp biBmaXhlZCBmb3JtYXQKCSAgYW5kIG9yZGVyZWQgZnJvbSBtb3N0IHNpZ25pZmljYW50IHRvIGxl YXN0IHNpZ25pZmljYW50LgoJICBDb21wYXJpc29uIG9mIG51bWVyaWMgZGF0ZXMgcmVwcmVzZW50 aW5nIGRheXMgc2luY2UgMTk3MC0wMS0wMSBjYW4gYmUgcGVyZm9ybWVkIGJ5CgkgIG5vcm1hbCBp bnRlZ2VyIGNvbXBhcmlzb24uCgkgIENvbXBhcmlzb24gb2YgZGF0ZXMgaW4gb3RoZXIgZm9ybWF0 cyBvciB1c2luZyBvdGhlciBjYWxlbmRhcnMgcmVxdWlyZSBjb252ZXJzaW9ucwoJICB0aGF0IGFy ZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4KCTwvdD4KCTx0PgoJICBO b3RlIHRoYXQgZGlmZmVyZW50IGRhdGVzIG1heSBjb3JyZXNwb25kIHRvIHRoZSBzYW1lIG1vbWVu dCBpbiB0aW1lLAoJICBkZXBlbmRpbmcgdXBvbiB0aGUgdGltZSB6b25lIGluIHdoaWNoIHRoZSBk YXRlIHdhcyBkZXRlcm1pbmVkLgoJICBGb3IgaW5zdGFuY2UsIGF0IG1hbnkgdGltZXMgb2YgdGhl IGRheSwgYSBjb25mZXJlbmNlIGNhbGwgb2NjdXJyaW5nCgkgIG9uIGEgcGFydGljdWxhciBkYXRl IGluIEphcGFuIHdpbGwgc2ltdWx0YW5lb3VzbHkgb2NjdXIKCSAgb24gdGhlIHByZXZpb3VzIGRh dGUgaW4gSGF3YWlpOwoJICBhdCBtYW55IHRpbWVzIG9mIHRoZSBkYXksIEphcGFuJ3MgRnJpZGF5 IGNvcnJlc3BvbmRzIHdpdGggSGF3YWlpJ3MgVGh1cnNkYXkuCgk8L3Q+CiAgICAgIDwvc2VjdGlv bj4KCiAgICAgIDxzZWN0aW9uIGFuY2hvcj0iQ29tcGFyaW5nRGF0ZXNBbmRUaW1lcyIgdGl0bGU9 IkNvbXBhcmluZyBEYXRlcyBhbmQgRGF0ZS9UaW1lIFZhbHVlcyI+Cgk8dD4KCSAgQ29tcGFyaW5n IGRhdGVzIHdpdGggZGF0ZS90aW1lIHZhbHVlcywgd2hpY2ggcmVwcmVzZW50IGEgcGFydGljdWxh ciBtb21lbnQgaW4gdGltZSwKCSAgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmlj YXRpb24uCgkgIFRoYXQgc2FpZCwgaWYgYSBkYXRlIGlzIGF1Z21lbnRlZCB3aXRoIGEgdGltZSB6 b25lIGFuZCB0aW1lIG9mIGRheSwKCSAgYSBzcGVjaWZpYyBkYXRlL3RpbWUgdmFsdWUgY2FuIGJl IGRldGVybWluZWQgYW5kCgkgIGNvbXBhcmluZyB0aGF0IGRhdGUvdGltZSB2YWx1ZSB0byBvdGhl cnMgYmVjb21lcyBwb3NzaWJsZS4KCSAgRm9yIGluc3RhbmNlLCBpZiBvbmUgd2VyZSB0byBhdWdt ZW50IEpvaG4gTGVubm9uJ3MgYmlydGggZGF0ZQoJICBvZiBPY3RvYmVyIDksIDE5NDAgd2l0aCB0 aGUgdGltZSBvZiBkYXkgYW5kIHRpbWUgem9uZSBvZiBoaXMgYmlydGgsCgkgIHRoZW4gaXQgd291 bGQgYmUgcG9zc2libGUgdG8gZGVyaXZlIGEgZGF0ZS90aW1lIGF0IHdoaWNoIGhlIHdhcyBib3Ju CgkgIHRoYXQgY291bGQgYmUgY29tcGFyZWQgd2l0aCBvdGhlciBkYXRlL3RpbWUgdmFsdWVzLgoJ PC90PgogICAgICA8L3NlY3Rpb24+CgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIGFuY2hv cj0iSUFOQSIgdGl0bGU9IklBTkEgQ29uc2lkZXJhdGlvbnMiPgoKICAgICAgPHNlY3Rpb24gYW5j aG9yPSJjb3NlLWFsZ29yaXRobXMtcmVnaXN0cmF0aW9ucyIgdGl0bGU9IkNvbmNpc2UgQmluYXJ5 IE9iamVjdCBSZXByZXNlbnRhdGlvbiAoQ0JPUikgVGFncyBSZWdpc3RyYXRpb25zIj4KICAgICAg ICA8dD4KCSAgVGhpcyBzZWN0aW9uIHJlZ2lzdGVycyB0aGUgZm9sbG93aW5nIHZhbHVlcyBpbiB0 aGUKCSAgSUFOQSAiQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIChDQk9SKSBU YWdzIiByZWdpc3RyeSA8eHJlZiB0YXJnZXQ9IklBTkEuY2Jvci10YWdzIi8+LgoJPC90PgoJPHQ+ CgkgIDw/cmZjIHN1YmNvbXBhY3Q9InllcyI/PgoJICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+Cgkg ICAgPHQ+CgkgICAgICBUYWc6IDEwMDQKCSAgICA8L3Q+CgkgICAgPHQ+CgkgICAgICBEYXRhIEl0 ZW06IFVURi04IHRleHQgc3RyaW5nCgkgICAgPC90PgoJICAgIDx0PgoJICAgICAgU2VtYW50aWNz OiBSRkMgMzMzOSBmdWxsLWRhdGUgc3RyaW5nCgkgICAgPC90PgoJICAgIDx0PgoJICAgICAgUmVm ZXJlbmNlOiBbWyB0aGlzIHNwZWNpZmljYXRpb24gXV0KCSAgICA8L3Q+CgkgIDwvbGlzdD4KCTwv dD4KCTx0PgoJICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CgkgICAgPHQ+CgkgICAgICBUYWc6IDEw MCAoQVNDSUkgJ2QnKQoJICAgIDwvdD4KCSAgICA8dD4KCSAgICAgIERhdGEgSXRlbTogVW5zaWdu ZWQgb3IgbmVnYXRpdmUgaW50ZWdlcgoJICAgIDwvdD4KCSAgICA8dD4KCSAgICAgIFNlbWFudGlj czogTnVtYmVyIG9mIGRheXMgc2luY2UgdGhlIGVwb2NoIGRhdGUgMTk3MC0wMS0wMQoJICAgIDwv dD4KCSAgICA8dD4KCSAgICAgIFJlZmVyZW5jZTogW1sgdGhpcyBzcGVjaWZpY2F0aW9uIF1dCgkg ICAgPC90PgoJICA8L2xpc3Q+Cgk8L3Q+Cgk8P3JmYyBzdWJjb21wYWN0PSJubyI/PgogICAgICA8 L3NlY3Rpb24+CgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIGFuY2hvcj0iU2VjdXJpdHki IHRpdGxlPSJTZWN1cml0eSBDb25zaWRlcmF0aW9ucyI+CiAgICAgIDx0PgoJVGhlIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIG9mIFJGQyA3MDQ5IGFwcGx5OyB0aGUgdGFncyBpbnRyb2R1Y2VkCglo ZXJlIGFyZSBub3QgZXhwZWN0ZWQgdG8gcmFpc2Ugc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYmV5 b25kIHRob3NlLgogICAgICA8L3Q+CiAgICAgIDx0PgoJQSBkYXRlLCBvZiBjb3Vyc2UsIGhhcyBz aWduaWZpY2FudCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4KCVRoZXNlIGluY2x1ZGUgdGhlIGV4 cGxvaXRhdGlvbiBvZiBhbWJpZ3VpdGllcyB3aGVyZSB0aGUgZGF0ZSBpcyBzZWN1cml0eSByZWxl dmFudAoJb3Igd2hlcmUgdGhlIGRhdGUgaXMgdXNlZCBpbiBhY2Nlc3MgY29udHJvbCBkZWNpc2lv bnMuCiAgICAgIDwvdD4KICAgICAgPHQ+CglXaGVuIHVzaW5nIGEgY2FsZW5kYXIgZGF0ZSBmb3Ig ZGVjaXNpb24gbWFraW5nLCBmb3IgZXhhbXBsZSBhY2Nlc3MgY29udHJvbCwKCWl0IG5lZWRzIHRv IGJlIG5vdGVkIHRoYXQgc2luY2UgY2FsZW5kYXIgZGF0ZXMgZG8gbm90IHJlcHJlc2VudCBhIHNw ZWNpZmljIHBvaW50IGluIHRpbWUsCgl0aGUgcmVzdWx0cyBvZiB0aGUgZXZhbHVhdGlvbiBjYW4g ZGlmZmVyIGRlcGVuZGluZyB1cG9uIHdoZXJlIHRoZSBkZWNpc2lvbiBpcyBtYWRlLgoJRm9yIGlu c3RhbmNlLCBhIHBlcnNvbiBtYXkgaGF2ZSByZWFjaGVkIHRoZWlyIDIxc3QgYmlydGhkYXkgaW4g SmFwYW4KCXdoaWxlIHNpbXVsdGFuZW91c2x5IGJlaW5nIGEgZGF5IHNob3J0IG9mIHRoZWlyIDIx c3QgYmlydGhkYXkgaW4gSGF3YWlpLgogICAgICA8L3Q+CiAgICA8L3NlY3Rpb24+CgogIDwvbWlk ZGxlPgoKICA8YmFjaz4KICAgIDxyZWZlcmVuY2VzIHRpdGxlPSJOb3JtYXRpdmUgUmVmZXJlbmNl cyI+CgogICAgICA8IS0tIDw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuMjExOS54bWwiPz4g LS0+CiAgICAgIDw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuMzMzOS54bWwiPz4KICAgICAg PD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy43MDQ5LnhtbCI/PgogICAgICA8IS0tIDw/cmZj IGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuODE3NC54bWwiPz4gLS0+CgogICAgPC9yZWZlcmVuY2Vz PgoKICAgIDxyZWZlcmVuY2VzIHRpdGxlPSJJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIj4KCiAgICAg IDxyZWZlcmVuY2UgYW5jaG9yPSJJQU5BLmNib3ItdGFncyIgdGFyZ2V0PSJodHRwOi8vd3d3Lmlh bmEub3JnL2Fzc2lnbm1lbnRzL2Nib3ItdGFncyI+CiAgICAgICAgPGZyb250PgogICAgICAgICAg PHRpdGxlPkNvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXByZXNlbnRhdGlvbiAoQ0JPUikgVGFnczwv dGl0bGU+CiAgICAgICAgICA8YXV0aG9yPgogICAgICAgICAgICA8b3JnYW5pemF0aW9uPklBTkE8 L29yZ2FuaXphdGlvbj4KICAgICAgICAgIDwvYXV0aG9yPgoJICA8ZGF0ZS8+CiAgICAgICAgPC9m cm9udD4KICAgICAgPC9yZWZlcmVuY2U+CgogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iUE9TSVgu MSIgdGFyZ2V0PSJodHRwOi8vcHVicy5vcGVuZ3JvdXAub3JnL29ubGluZXB1YnMvOTY5OTkxOTc5 OS9iYXNlZGVmcy9WMV9jaGFwMDQuaHRtbCN0YWdfMDRfMTUiPgoJPGZyb250PgoJICA8dGl0bGU+ VGhlIE9wZW4gR3JvdXAgQmFzZSBTcGVjaWZpY2F0aW9ucyBJc3N1ZSA3PC90aXRsZT4KCSAgPGF1 dGhvcj4KCSAgICA8b3JnYW5pemF0aW9uPklFRUU8L29yZ2FuaXphdGlvbj4KCSAgPC9hdXRob3I+ CgkgIDxkYXRlIHllYXI9IjIwMTMiLz4KCTwvZnJvbnQ+Cgk8c2VyaWVzSW5mbyBuYW1lPSJJRUVF IiB2YWx1ZT0iU3RkIDEwMDMuMSwgMjAxMyBFZGl0aW9uIi8+CiAgICAgIDwvcmVmZXJlbmNlPgoK ICAgIDwvcmVmZXJlbmNlcz4KCiAgICA8c2VjdGlvbiB0aXRsZT0iQWNrbm93bGVkZ2VtZW50cyIg YW5jaG9yPSJBY2tub3dsZWRnZW1lbnRzIiBudW1iZXJlZD0ibm8iPgoKICAgICAgPHQ+CglUaGFu a3MgdG8gQ2Fyc3RlbiBCb3JtYW5uIGZvciBzdXBwb3J0aW5nIGNyZWF0aW9uIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbi4KCVBhcnRzIG9mIHRoZSBleHBsYW5hdG9yeSB0ZXh0IGluIHRoaXMgc3BlY2lm aWNhdGlvbiBjb21lIGZyb20gZHJhZnQtYm9ybWFubi1jYm9yLXRpbWUtdGFnLTAyLgogICAgICA8 L3Q+CiAgICAgIDx0PgoJVGhhbmtzIHRvIHRoZXNlIHBlb3BsZSBmb3IgcmV2aWV3cyBvZiB0aGUg c3BlY2lmaWNhdGlvbjoKCUhlbmsgQmlya2hvbHosCglDYXJzdGVuIEJvcm1hbm4sCglUaGlhZ28g TWFjaWVpcmEsCglGcmFuY2VzY2EgUGFsb21iaW5pLAoJTWljaGFlbCBSaWNoYXJkc29uLAoJSmlt IFNjaGFhZCwKCUp1ZXJnZW4gU2Nob2Vud2FlbGRlciwKCWFuZAoJRGFsZSBXb3JsZXkuCiAgICAg IDwvdD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0iRG9jdW1lbnQgSGlzdG9y eSIgYW5jaG9yPSJIaXN0b3J5Ij4KICAgICAgPHQ+CiAgICAgICAgW1sgdG8gYmUgcmVtb3ZlZCBi eSB0aGUgUkZDIEVkaXRvciBiZWZvcmUgcHVibGljYXRpb24gYXMgYW4gUkZDIF1dCiAgICAgIDwv dD4KCiAgICAgIDx0PgogICAgICAgIC0wNQogICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4K ICAgICAgICAgIDx0PgoJICAgIEluY29ycG9yYXRlZCBhZGRpdGlvbmFsIHN1Z2dlc3Rpb25zIGJ5 IENhcnN0ZW4gQm9ybWFubiBhbmQgSnVlcmdlbiBTY2hvZW53YWVsZGVyLgoJICA8L3Q+CiAgICAg ICAgPC9saXN0PgogICAgICA8L3Q+CgogICAgICA8dD4KICAgICAgICAtMDQKICAgICAgICA8bGlz dCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICA8dD4KCSAgICBBZGRyZXNzZWQgc2hlcGhlcmQg Y29tbWVudHMgYnkgRnJhbmNlc2NhIFBhbG9tYmluaS4KCSAgPC90PgogICAgICAgICAgIDx0PgoJ ICAgIEFkZHJlc3NlZCBhZGRpdGlvbmFsIHJldmlldyBjb21tZW50cyBieSBKaW0gU2NoYWFkIGFu ZCBNaWNoYWVsIFJpY2hhcmRzb24uCgkgIDwvdD4KICAgICAgICA8L2xpc3Q+CiAgICAgIDwvdD4K CiAgICAgIDx0PgogICAgICAgIC0wMwogICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAg ICAgICAgIDx0PgoJICAgIEFkZGVkIHN0YXRlbWVudCB0aGF0IHRoZXNlIHRhZ3MgYXJlIGJvdGgg Zm9yIHJlcHJlc2VudGF0aW9ucyBvZiBjYWxlbmRhciBkYXRlcy4KCSAgPC90PgoJICA8dD4KCSAg ICBEZXNjcmliZWQgY29uc2VxdWVuY2VzIG9mIHVzaW5nIGNhbGVuZGFyIGRhdGVzIGluIGFjY2Vz cyBjb250cm9sIGRlY2lzaW9ucy4KCSAgPC90PgogICAgICAgIDwvbGlzdD4KICAgICAgPC90PgoK ICAgICAgPHQ+CiAgICAgICAgLTAyCiAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAg ICAgICAgPHQ+CgkgICAgQWRkcmVzc2VkIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGNvbW1lbnRz LAoJICAgIGluY2x1ZGluZyBzdGF0aW5nIHRoYXQgdGltZSB6b25lcyBhcmUgbm90IGFwcGxpY2Fi bGUgdG8gdGhlc2UgdmFsdWVzLgoJICA8L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8L3Q+Cgog ICAgICA8dD4KICAgICAgICAtMDEKICAgICAgICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAg ICAgICA8dD4KCSAgICBDaGFuZ2VkICJwb3NpdGl2ZSBvciBuZWdhdGl2ZSIgdG8gInVuc2lnbmVk IG9yIG5lZ2F0aXZlIi4KICAgICAgICAgIDwvdD4KCSAgPHQ+CgkgICAgQWRkZWQgYW4gaW1wbGVt ZW50YXRpb24gbm90ZSBhYm91dCB0aGUgcmVsYXRpb25zaGlwIHRvIE1vZGlmaWVkIEp1bGlhbiBE YXRlcy4KCSAgPC90PgogICAgICAgIDwvbGlzdD4KICAgICAgPC90PgoKICAgICAgPHQ+CiAgICAg ICAgLTAwCiAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgPHQ+CgkgICAg SW5pdGlhbCB3b3JraW5nIGdyb3VwIHZlcnNpb24gYmFzZWQgb24gZHJhZnQtam9uZXMtY2Jvci1k YXRlLXRhZy0wMSB3aXRoIG5vIG5vcm1hdGl2ZSBjaGFuZ2VzLgogICAgICAgICAgPC90PgogICAg ICAgIDwvbGlzdD4KICAgICAgPC90PgoKICAgIDwvc2VjdGlvbj4KCiAgPC9iYWNrPgo8L3JmYz4K --_005_BY5PR00MB06769A4EE70D2072492AB907F57C0BY5PR00MB0676namp_ Content-Type: text/plain; name="draft-ietf-cbor-date-tag-05.txt" Content-Description: draft-ietf-cbor-date-tag-05.txt Content-Disposition: attachment; filename="draft-ietf-cbor-date-tag-05.txt"; size=13514; creation-date="Fri, 17 Jul 2020 00:17:00 GMT"; modification-date="Fri, 17 Jul 2020 00:17:00 GMT" Content-Transfer-Encoding: base64 CgoKCkNCT1IgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBNLiBKb25lcwpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEEuIE5hZGFsaW4KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWljcm9zb2Z0CkV4cGly ZXM6IEphbnVhcnkgMTcsIDIwMjEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Si4gUmljaHRlcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBw ZHYgRmluYW5jaWFsIFNvZnR3YXJlIEdtYkgKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdWx5IDE2LCAyMDIwCgoKICAgICAgIENvbmNp c2UgQmluYXJ5IE9iamVjdCBSZXByZXNlbnRhdGlvbiAoQ0JPUikgVGFncyBmb3IgRGF0ZQogICAg ICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTA1CgpBYnN0cmFjdAoK ICAgVGhlIENvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXByZXNlbnRhdGlvbiAoQ0JPUiwgUkZDIDcw NDkpIGlzIGEgZGF0YQogICBmb3JtYXQgd2hvc2UgZGVzaWduIGdvYWxzIGluY2x1ZGUgdGhlIHBv c3NpYmlsaXR5IG9mIGV4dHJlbWVseSBzbWFsbAogICBjb2RlIHNpemUsIGZhaXJseSBzbWFsbCBt ZXNzYWdlIHNpemUsIGFuZCBleHRlbnNpYmlsaXR5IHdpdGhvdXQgdGhlCiAgIG5lZWQgZm9yIHZl cnNpb24gbmVnb3RpYXRpb24uCgogICBJbiBDQk9SLCBvbmUgcG9pbnQgb2YgZXh0ZW5zaWJpbGl0 eSBpcyB0aGUgZGVmaW5pdGlvbiBvZiBDQk9SIHRhZ3MuCiAgIFJGQyA3MDQ5IGRlZmluZXMgdHdv IHRhZ3MgZm9yIHRpbWU6IENCT1IgdGFnIDAgKFJGQyAzMzM5IGRhdGUvdGltZQogICBzdHJpbmcp IGFuZCB0YWcgMSAoUG9zaXggInNlY29uZHMgc2luY2UgdGhlIGVwb2NoIikuICBTaW5jZSB0aGVu LAogICBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBoYXZlIGJlY29tZSBrbm93bi4gIFRoaXMgc3Bl Y2lmaWNhdGlvbgogICBkZWZpbmVzIGEgQ0JPUiB0YWcgZm9yIGFuIFJGQyAzMzM5IGRhdGUgdGV4 dCBzdHJpbmcsIGZvciBhcHBsaWNhdGlvbnMKICAgbmVlZGluZyBhIHRleHR1YWwgZGF0ZSByZXBy ZXNlbnRhdGlvbiB3aXRoaW4gdGhlIEdyZWdvcmlhbiBjYWxlbmRhcgogICB3aXRob3V0IGEgdGlt ZS4gIEl0IGFsc28gZGVmaW5lcyBhIENCT1IgdGFnIGZvciBkYXlzIHNpbmNlIHRoZSBkYXRlCiAg IDE5NzAtMDEtMDEgaW4gdGhlIEdyZWdvcmlhbiBjYWxlbmRhciBmb3IgYXBwbGljYXRpb25zIG5l ZWRpbmcgYQogICBudW1lcmljIGRhdGUgcmVwcmVzZW50YXRpb24gd2l0aG91dCBhIHRpbWUuICBU aGlzIHNwZWNpZmljYXRpb24gaXMKICAgaW50ZW5kZWQgYXMgdGhlIHJlZmVyZW5jZSBkb2N1bWVu dCBmb3IgSUFOQSByZWdpc3RyYXRpb24gb2YgdGhlIENCT1IKICAgdGFncyBkZWZpbmVkLgoKU3Rh dHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4g ZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQ IDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50 ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIg Z3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJu ZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0 IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgg bW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBv dGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVz ZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhl bSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgd2lsbCBleHBpcmUgb24gSmFudWFyeSAxNywgMjAyMS4KCgoKCgpKb25lcywgZXQgYWwuICAg ICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTcsIDIwMjEgICAgICAgICAgICAgICAgW1BhZ2UgMV0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQ0JPUiBUYWcgZm9yIERhdGUgICAgICAgICAg ICAgICAgICBKdWx5IDIwMjAKCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIw MjAgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1l bnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1 YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMg UmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHBzOi8vdHJ1c3RlZS5pZXRmLm9yZy9s aWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0 aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5 LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNw ZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20g dGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0 IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlz aW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGlu IHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJ bnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgMgogICAgIDEuMS4gIENhbGVuZGFyIERhdGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgICAgIDEuMS4xLiAgRXhhbXBsZSBEYXRlIFJlcHJl c2VudGF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgICAgMS4yLiAgQ29tcGFy aW5nIERhdGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAog ICAgIDEuMy4gIENvbXBhcmluZyBEYXRlcyBhbmQgRGF0ZS9UaW1lIFZhbHVlcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDQKICAgMi4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgICAgMi4xLiAgQ29uY2lzZSBCaW5hcnkg T2JqZWN0IFJlcHJlc2VudGF0aW9uIChDQk9SKSBUYWdzCiAgICAgICAgICAgUmVnaXN0cmF0aW9u cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICAzLiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDUKICAgNC4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgICAgNC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICAgIDQuMi4gIEluZm9y bWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUK ICAgQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA1CiAgIERvY3VtZW50IEhpc3RvcnkgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICBBdXRob3JzJyBBZGRyZXNzZXMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKCjEuICBJbnRy b2R1Y3Rpb24KCiAgIFRoZSBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENC T1IpIFtSRkM3MDQ5XSBwcm92aWRlcwogICBmb3IgdGhlIGludGVyY2hhbmdlIG9mIHN0cnVjdHVy ZWQgZGF0YSB3aXRob3V0IGEgcmVxdWlyZW1lbnQgZm9yIGEKICAgcHJlLWFncmVlZCBzY2hlbWEu ICBSRkMgNzA0OSBkZWZpbmVzIGEgYmFzaWMgc2V0IG9mIGRhdGEgdHlwZXMsIGFzCiAgIHdlbGwg YXMgYSB0YWdnaW5nIG1lY2hhbmlzbSB0aGF0IGVuYWJsZXMgZXh0ZW5kaW5nIHRoZSBzZXQgb2Yg ZGF0YQogICB0eXBlcyBzdXBwb3J0ZWQgdmlhIGFuIElBTkEgcmVnaXN0cnkuCgogICBUaGlzIHNw ZWNpZmljYXRpb24gZGVmaW5lcyBhIENCT1IgdGFnIGZvciBhIHRleHQgc3RyaW5nIHJlcHJlc2Vu dGluZwogICBhIGRhdGUgd2l0aG91dCBhIHRpbWUuICBUaGUgdGFnZ2VkIHRleHQgc3RyaW5nIGlz IHJlcHJlc2VudGVkIGFzCiAgIHNwZWNpZmllZCBieSB0aGUgUkZDIDMzMzkgW1JGQzMzMzldICJm dWxsLWRhdGUiIHByb2R1Y3Rpb24uICBQZXIgUkZDCiAgIDMzMzksIHRoaXMgcmVwcmVzZW50cyBh IGRhdGUgd2l0aGluIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIuCgogICBUaGlzIHNwZWNpZmljYXRp b24gYWxzbyBkZWZpbmVzIGEgQ0JPUiB0YWcgZm9yIGFuIGludGVnZXIKICAgcmVwcmVzZW50aW5n IGEgZGF0ZSB3aXRob3V0IGEgdGltZS4gIFRoZSB0YWdnZWQgaW50ZWdlciBpcyBhbgoKCgpKb25l cywgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTcsIDIwMjEgICAgICAgICAgICAg ICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQ0JPUiBUYWcgZm9yIERh dGUgICAgICAgICAgICAgICAgICBKdWx5IDIwMjAKCgogICB1bnNpZ25lZCBvciBuZWdhdGl2ZSB2 YWx1ZSBpbmRpY2F0aW5nIHRoZSBudW1iZXIgb2YgZGF5cyBzaW5jZSB0aGUKICAgR3JlZ29yaWFu IGNhbGVuZGFyIGRhdGUgMTk3MC0wMS0wMS4gIEFzIGFuIGltcGxlbWVudGF0aW9uIG5vdGUsIHRo aXMKICAgdmFsdWUgaGFzIGEgY29uc3RhbnQgb2Zmc2V0IGZyb20gdGhlIE1vZGlmaWVkIEp1bGlh biBEYXRlIHZhbHVlCiAgICh3aGljaCBpcyBkZWZpbmVkIGJ5IHRoZSBTbWl0aHNvbmlhbiBBc3Ry b3BoeXNpY2FsIE9ic2VydmF0b3J5IGFzIHRoZQogICBudW1iZXIgb2YgZGF5cyBzaW5jZSBOb3Zl bWJlciAxNywgMTg1OCk7IHRoaXMgdmFsdWUgaXMgdGhlIE1vZGlmaWVkCiAgIEp1bGlhbiBEYXRl IG1pbnVzIDQwNTg3LgoKICAgTm90ZSB0aGF0IHNpbmNlIGJvdGggdGFncyBhcmUgZm9yIGRhdGVz IHdpdGhvdXQgdGltZXMsIHRpbWVzIG9mIGRheSwKICAgdGltZSB6b25lcywgYW5kIGxlYXAgc2Vj b25kcyBhcmUgbm90IGFwcGxpY2FibGUgdG8gdGhlc2UgdmFsdWVzLgogICBUaGVzZSB0YWdzIGFy ZSBib3RoIGZvciByZXByZXNlbnRhdGlvbnMgb2YgR3JlZ29yaWFuIGNhbGVuZGFyIGRhdGVzLgoK MS4xLiAgQ2FsZW5kYXIgRGF0ZXMKCiAgIENhbGVuZGFyIGRhdGVzIGFyZSB1c2VkIGZvciBudW1l cm91cyBodW1hbiB1c2UgY2FzZXMsIHN1Y2ggYXMgbWFya2luZwogICB0aGUgZGF0ZXMgb2Ygc2ln bmlmaWNhbnQgZXZlbnRzLiAgRm9yIGluc3RhbmNlLCBKb2huIExlbm5vbiB3YXMgYm9ybgogICBv biBPY3RvYmVyIDksIDE5NDAgYW5kIGRpZWQgb24gRGVjZW1iZXIgOCwgMTk4MC4gIE9uZSBzdWNo IHVzZSBjYXNlCiAgIGlzIGRyaXZlcidzIGxpY2Vuc2VzLCB3aGljaCB0eXBpY2FsbHkgaW5jbHVk ZSBhIGRhdGUgb2YgYmlydGguICBUaGUKICAgZGF0ZXMgdXNlZCBpbiB0aGlzIHNwZWNpZmljYXRp b24gdXNlIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIsIGFzIGRvCiAgIHRob3NlIGluIFJGQyAzMzM5 IFtSRkMzMzM5XS4gIFRoZSB0aW1lIHpvbmVzIGFuZCBhY3R1YWwgdGltZXMgb2YKICAgdGhlc2Ug ZXZlbnRzIGFyZSBpbnRlbnRpb25hbGx5IG5vdCByZXByZXNlbnRlZCBpbiB0aGUgY2FsZW5kYXIg ZGF0ZS4KCiAgIFRoZSBlcG9jaCBjaG9zZW4gZm9yIHRoZSBzZWNvbmQgdGFnLCB3aGljaCByZXBy ZXNlbnRzIGRheXMgc2luY2UgdGhlCiAgIEdyZWdvcmlhbiBjYWxlbmRhciBkYXRlIDE5NzAtMDEt MDEsIGlzIHJlbGF0ZWQgdG8gdGhlIElFRUUgU3RkCiAgIDEwMDMuMSwgMjAxMyBFZGl0aW9uIFtQ T1NJWC4xXSB0aW1lIGVwb2NoIDE5NzAtMDEtMDFUMDA6MDA6MDBaIFVUQwogICBvbmx5IGluc29m YXIgYXMgYm90aCBjb250YWluIHRoZSBkYXRlIDE5NzAtMDEtMDEuICBUaGlzIHNob3VsZCBub3Qg YmUKICAgY29uc3RydWVkIGFzIGluZGljYXRpbmcgdGhhdCBkYXRlcyB1c2luZyB0aGlzIHRhZyBy ZXByZXNlbnQgZWl0aGVyIGEKICAgc3BlY2lmaWMgdGltZSBvZiBkYXkgYW5kL29yIHRpbWUgem9u ZS4KCiAgIFRoZSBkYXkgb2YgdGhlIHdlZWsgKFN1bmRheSwgTW9uZGF5LCBUdWVzZGF5LCBldGMu KSBpcyBub3QgZXhwbGljaXRseQogICByZXByZXNlbnRlZCBpbiBlaXRoZXIgb2YgdGhlc2UgZGF0 ZSBmb3JtYXRzLiAgSG93ZXZlciwgZGV0ZXJtaW5pc3RpYwogICBhbGdvcml0aG1zIHRoYXQgYXJl IGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGNhbiBiZQogICB1c2VkIHRv IGRlcml2ZSB0aGUgZGF5IG9mIHRoZSB3ZWVrIGluIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIgZnJv bQogICBkYXRlcyByZXByZXNlbnRlZCBpbiBib3RoIG9mIHRoZXNlIGZvcm1hdHMuCgoxLjEuMS4g IEV4YW1wbGUgRGF0ZSBSZXByZXNlbnRhdGlvbnMKCiAgIFRoaXMgdGFibGUgY29udGFpbnMgZXhh bXBsZSByZXByZXNlbnRhdGlvbnMgZm9yIGRhdGVzIHVzaW5nIGJvdGgKICAgdGFncy4KCiAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tKwog ICAgICAgICAgICAgICB8IERhdGUgICAgICAgICAgICAgfCBUYWcgMTAwNCAgICAgfCBUYWcgMTAw IHwKICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0rCiAgICAgICAgICAgICAgIHwgT2N0b2JlciA5LCAxOTQwICB8ICIxOTQwLTEwLTA5IiB8 IC0xMDY3NiAgfAogICAgICAgICAgICAgICB8IERlY2VtYmVyIDgsIDE5ODAgfCAiMTk4MC0xMi0w OCIgfCAzOTk0ICAgIHwKICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0rCgoKCgoKCkpvbmVzLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMg SmFudWFyeSAxNywgMjAyMSAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBDQk9SIFRhZyBmb3IgRGF0ZSAgICAgICAgICAgICAgICAgIEp1bHkgMjAy MAoKCjEuMi4gIENvbXBhcmluZyBEYXRlcwoKICAgQ29tcGFyaXNvbiBvZiBkYXRlcyBpbiAiZnVs bC1kYXRlIiBmb3JtYXQgY2FuIGJlIGFjY29tcGxpc2hlZCBieQogICBub3JtYWwgc3RyaW5nIGNv bXBhcmlzb24sIHNpbmNlIGJ5IGRlc2lnbiwgdGhlIGRpZ2l0cyByZXByZXNlbnRpbmcKICAgdGhl IGRhdGUgYXJlIGluIGZpeGVkIGZvcm1hdCBhbmQgb3JkZXJlZCBmcm9tIG1vc3Qgc2lnbmlmaWNh bnQgdG8KICAgbGVhc3Qgc2lnbmlmaWNhbnQuICBDb21wYXJpc29uIG9mIG51bWVyaWMgZGF0ZXMg cmVwcmVzZW50aW5nIGRheXMKICAgc2luY2UgMTk3MC0wMS0wMSBjYW4gYmUgcGVyZm9ybWVkIGJ5 IG5vcm1hbCBpbnRlZ2VyIGNvbXBhcmlzb24uCiAgIENvbXBhcmlzb24gb2YgZGF0ZXMgaW4gb3Ro ZXIgZm9ybWF0cyBvciB1c2luZyBvdGhlciBjYWxlbmRhcnMgcmVxdWlyZQogICBjb252ZXJzaW9u cyB0aGF0IGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4KCiAgIE5v dGUgdGhhdCBkaWZmZXJlbnQgZGF0ZXMgbWF5IGNvcnJlc3BvbmQgdG8gdGhlIHNhbWUgbW9tZW50 IGluIHRpbWUsCiAgIGRlcGVuZGluZyB1cG9uIHRoZSB0aW1lIHpvbmUgaW4gd2hpY2ggdGhlIGRh dGUgd2FzIGRldGVybWluZWQuICBGb3IKICAgaW5zdGFuY2UsIGF0IG1hbnkgdGltZXMgb2YgdGhl IGRheSwgYSBjb25mZXJlbmNlIGNhbGwgb2NjdXJyaW5nIG9uIGEKICAgcGFydGljdWxhciBkYXRl IGluIEphcGFuIHdpbGwgc2ltdWx0YW5lb3VzbHkgb2NjdXIgb24gdGhlIHByZXZpb3VzCiAgIGRh dGUgaW4gSGF3YWlpOyBhdCBtYW55IHRpbWVzIG9mIHRoZSBkYXksIEphcGFuJ3MgRnJpZGF5IGNv cnJlc3BvbmRzCiAgIHdpdGggSGF3YWlpJ3MgVGh1cnNkYXkuCgoxLjMuICBDb21wYXJpbmcgRGF0 ZXMgYW5kIERhdGUvVGltZSBWYWx1ZXMKCiAgIENvbXBhcmluZyBkYXRlcyB3aXRoIGRhdGUvdGlt ZSB2YWx1ZXMsIHdoaWNoIHJlcHJlc2VudCBhIHBhcnRpY3VsYXIKICAgbW9tZW50IGluIHRpbWUs IGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLiAgVGhhdAogICBzYWlk LCBpZiBhIGRhdGUgaXMgYXVnbWVudGVkIHdpdGggYSB0aW1lIHpvbmUgYW5kIHRpbWUgb2YgZGF5 LCBhCiAgIHNwZWNpZmljIGRhdGUvdGltZSB2YWx1ZSBjYW4gYmUgZGV0ZXJtaW5lZCBhbmQgY29t cGFyaW5nIHRoYXQgZGF0ZS8KICAgdGltZSB2YWx1ZSB0byBvdGhlcnMgYmVjb21lcyBwb3NzaWJs ZS4gIEZvciBpbnN0YW5jZSwgaWYgb25lIHdlcmUgdG8KICAgYXVnbWVudCBKb2huIExlbm5vbidz IGJpcnRoIGRhdGUgb2YgT2N0b2JlciA5LCAxOTQwIHdpdGggdGhlIHRpbWUgb2YKICAgZGF5IGFu ZCB0aW1lIHpvbmUgb2YgaGlzIGJpcnRoLCB0aGVuIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGRl cml2ZSBhCiAgIGRhdGUvdGltZSBhdCB3aGljaCBoZSB3YXMgYm9ybiB0aGF0IGNvdWxkIGJlIGNv bXBhcmVkIHdpdGggb3RoZXIKICAgZGF0ZS90aW1lIHZhbHVlcy4KCjIuICBJQU5BIENvbnNpZGVy YXRpb25zCgoyLjEuICBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENCT1Ip IFRhZ3MgUmVnaXN0cmF0aW9ucwoKICAgVGhpcyBzZWN0aW9uIHJlZ2lzdGVycyB0aGUgZm9sbG93 aW5nIHZhbHVlcyBpbiB0aGUgSUFOQSAiQ29uY2lzZQogICBCaW5hcnkgT2JqZWN0IFJlcHJlc2Vu dGF0aW9uIChDQk9SKSBUYWdzIiByZWdpc3RyeSBbSUFOQS5jYm9yLXRhZ3NdLgoKICAgbyAgVGFn OiAxMDA0CiAgIG8gIERhdGEgSXRlbTogVVRGLTggdGV4dCBzdHJpbmcKICAgbyAgU2VtYW50aWNz OiBSRkMgMzMzOSBmdWxsLWRhdGUgc3RyaW5nCiAgIG8gIFJlZmVyZW5jZTogW1sgdGhpcyBzcGVj aWZpY2F0aW9uIF1dCgogICBvICBUYWc6IDEwMCAoQVNDSUkgJ2QnKQogICBvICBEYXRhIEl0ZW06 IFVuc2lnbmVkIG9yIG5lZ2F0aXZlIGludGVnZXIKICAgbyAgU2VtYW50aWNzOiBOdW1iZXIgb2Yg ZGF5cyBzaW5jZSB0aGUgZXBvY2ggZGF0ZSAxOTcwLTAxLTAxCiAgIG8gIFJlZmVyZW5jZTogW1sg dGhpcyBzcGVjaWZpY2F0aW9uIF1dCgoKCgoKCkpvbmVzLCBldCBhbC4gICAgICAgICAgIEV4cGly ZXMgSmFudWFyeSAxNywgMjAyMSAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBDQk9SIFRhZyBmb3IgRGF0ZSAgICAgICAgICAgICAgICAgIEp1bHkg MjAyMAoKCjMuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhlIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIG9mIFJGQyA3MDQ5IGFwcGx5OyB0aGUgdGFncyBpbnRyb2R1Y2VkCiAgIGhlcmUg YXJlIG5vdCBleHBlY3RlZCB0byByYWlzZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBiZXlvbmQg dGhvc2UuCgogICBBIGRhdGUsIG9mIGNvdXJzZSwgaGFzIHNpZ25pZmljYW50IHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zLiAgVGhlc2UKICAgaW5jbHVkZSB0aGUgZXhwbG9pdGF0aW9uIG9mIGFtYmln dWl0aWVzIHdoZXJlIHRoZSBkYXRlIGlzIHNlY3VyaXR5CiAgIHJlbGV2YW50IG9yIHdoZXJlIHRo ZSBkYXRlIGlzIHVzZWQgaW4gYWNjZXNzIGNvbnRyb2wgZGVjaXNpb25zLgoKICAgV2hlbiB1c2lu ZyBhIGNhbGVuZGFyIGRhdGUgZm9yIGRlY2lzaW9uIG1ha2luZywgZm9yIGV4YW1wbGUgYWNjZXNz CiAgIGNvbnRyb2wsIGl0IG5lZWRzIHRvIGJlIG5vdGVkIHRoYXQgc2luY2UgY2FsZW5kYXIgZGF0 ZXMgZG8gbm90CiAgIHJlcHJlc2VudCBhIHNwZWNpZmljIHBvaW50IGluIHRpbWUsIHRoZSByZXN1 bHRzIG9mIHRoZSBldmFsdWF0aW9uIGNhbgogICBkaWZmZXIgZGVwZW5kaW5nIHVwb24gd2hlcmUg dGhlIGRlY2lzaW9uIGlzIG1hZGUuICBGb3IgaW5zdGFuY2UsIGEKICAgcGVyc29uIG1heSBoYXZl IHJlYWNoZWQgdGhlaXIgMjFzdCBiaXJ0aGRheSBpbiBKYXBhbiB3aGlsZQogICBzaW11bHRhbmVv dXNseSBiZWluZyBhIGRheSBzaG9ydCBvZiB0aGVpciAyMXN0IGJpcnRoZGF5IGluIEhhd2FpaS4K CjQuICBSZWZlcmVuY2VzCgo0LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzMzMzld ICBLbHluZSwgRy4gYW5kIEMuIE5ld21hbiwgIkRhdGUgYW5kIFRpbWUgb24gdGhlIEludGVybmV0 OgogICAgICAgICAgICAgIFRpbWVzdGFtcHMiLCBSRkMgMzMzOSwgRE9JIDEwLjE3NDg3L1JGQzMz MzksIEp1bHkgMjAwMiwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcv aW5mby9yZmMzMzM5Pi4KCiAgIFtSRkM3MDQ5XSAgQm9ybWFubiwgQy4gYW5kIFAuIEhvZmZtYW4s ICJDb25jaXNlIEJpbmFyeSBPYmplY3QKICAgICAgICAgICAgICBSZXByZXNlbnRhdGlvbiAoQ0JP UikiLCBSRkMgNzA0OSwgRE9JIDEwLjE3NDg3L1JGQzcwNDksCiAgICAgICAgICAgICAgT2N0b2Jl ciAyMDEzLCA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3MDQ5Pi4KCjQuMi4g IEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtJQU5BLmNib3ItdGFnc10KICAgICAgICAgICAg ICBJQU5BLCAiQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIChDQk9SKSBUYWdz IiwKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9jYm9yLXRh Z3M+LgoKICAgW1BPU0lYLjFdICBJRUVFLCAiVGhlIE9wZW4gR3JvdXAgQmFzZSBTcGVjaWZpY2F0 aW9ucyBJc3N1ZSA3IiwKICAgICAgICAgICAgICBJRUVFIFN0ZCAxMDAzLjEsIDIwMTMgRWRpdGlv biwgMjAxMywKICAgICAgICAgICAgICA8aHR0cDovL3B1YnMub3Blbmdyb3VwLm9yZy9vbmxpbmVw dWJzLzk2OTk5MTk3OTkvYmFzZWRlZnMvCiAgICAgICAgICAgICAgVjFfY2hhcDA0Lmh0bWwjdGFn XzA0XzE1Pi4KCkFja25vd2xlZGdlbWVudHMKCiAgIFRoYW5rcyB0byBDYXJzdGVuIEJvcm1hbm4g Zm9yIHN1cHBvcnRpbmcgY3JlYXRpb24gb2YgdGhpcwogICBzcGVjaWZpY2F0aW9uLiAgUGFydHMg b2YgdGhlIGV4cGxhbmF0b3J5IHRleHQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uCiAgIGNvbWUgZnJv bSBkcmFmdC1ib3JtYW5uLWNib3ItdGltZS10YWctMDIuCgogICBUaGFua3MgdG8gdGhlc2UgcGVv cGxlIGZvciByZXZpZXdzIG9mIHRoZSBzcGVjaWZpY2F0aW9uOiBIZW5rCiAgIEJpcmtob2x6LCBD YXJzdGVuIEJvcm1hbm4sIFRoaWFnbyBNYWNpZWlyYSwgRnJhbmNlc2NhIFBhbG9tYmluaSwKCgoK CkpvbmVzLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxNywgMjAyMSAgICAgICAg ICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBDQk9SIFRhZyBm b3IgRGF0ZSAgICAgICAgICAgICAgICAgIEp1bHkgMjAyMAoKCiAgIE1pY2hhZWwgUmljaGFyZHNv biwgSmltIFNjaGFhZCwgSnVlcmdlbiBTY2hvZW53YWVsZGVyLCBhbmQgRGFsZQogICBXb3JsZXku CgpEb2N1bWVudCBIaXN0b3J5CgogICBbWyB0byBiZSByZW1vdmVkIGJ5IHRoZSBSRkMgRWRpdG9y IGJlZm9yZSBwdWJsaWNhdGlvbiBhcyBhbiBSRkMgXV0KCiAgIC0wNQoKICAgbyAgSW5jb3Jwb3Jh dGVkIGFkZGl0aW9uYWwgc3VnZ2VzdGlvbnMgYnkgQ2Fyc3RlbiBCb3JtYW5uIGFuZCBKdWVyZ2Vu CiAgICAgIFNjaG9lbndhZWxkZXIuCgogICAtMDQKCiAgIG8gIEFkZHJlc3NlZCBzaGVwaGVyZCBj b21tZW50cyBieSBGcmFuY2VzY2EgUGFsb21iaW5pLgoKICAgbyAgQWRkcmVzc2VkIGFkZGl0aW9u YWwgcmV2aWV3IGNvbW1lbnRzIGJ5IEppbSBTY2hhYWQgYW5kIE1pY2hhZWwKICAgICAgUmljaGFy ZHNvbi4KCiAgIC0wMwoKICAgbyAgQWRkZWQgc3RhdGVtZW50IHRoYXQgdGhlc2UgdGFncyBhcmUg Ym90aCBmb3IgcmVwcmVzZW50YXRpb25zIG9mCiAgICAgIGNhbGVuZGFyIGRhdGVzLgoKICAgbyAg RGVzY3JpYmVkIGNvbnNlcXVlbmNlcyBvZiB1c2luZyBjYWxlbmRhciBkYXRlcyBpbiBhY2Nlc3Mg Y29udHJvbAogICAgICBkZWNpc2lvbnMuCgogICAtMDIKCiAgIG8gIEFkZHJlc3NlZCB3b3JraW5n IGdyb3VwIGxhc3QgY2FsbCBjb21tZW50cywgaW5jbHVkaW5nIHN0YXRpbmcgdGhhdAogICAgICB0 aW1lIHpvbmVzIGFyZSBub3QgYXBwbGljYWJsZSB0byB0aGVzZSB2YWx1ZXMuCgogICAtMDEKCiAg IG8gIENoYW5nZWQgInBvc2l0aXZlIG9yIG5lZ2F0aXZlIiB0byAidW5zaWduZWQgb3IgbmVnYXRp dmUiLgoKICAgbyAgQWRkZWQgYW4gaW1wbGVtZW50YXRpb24gbm90ZSBhYm91dCB0aGUgcmVsYXRp b25zaGlwIHRvIE1vZGlmaWVkCiAgICAgIEp1bGlhbiBEYXRlcy4KCiAgIC0wMAoKICAgbyAgSW5p dGlhbCB3b3JraW5nIGdyb3VwIHZlcnNpb24gYmFzZWQgb24gZHJhZnQtam9uZXMtY2Jvci1kYXRl LQogICAgICB0YWctMDEgd2l0aCBubyBub3JtYXRpdmUgY2hhbmdlcy4KCgoKCgoKCgpKb25lcywg ZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTcsIDIwMjEgICAgICAgICAgICAgICAg W1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQ0JPUiBUYWcgZm9yIERhdGUg ICAgICAgICAgICAgICAgICBKdWx5IDIwMjAKCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIE1pY2hh ZWwgQi4gSm9uZXMKICAgTWljcm9zb2Z0CgogICBFbWFpbDogbWJqQG1pY3Jvc29mdC5jb20KICAg VVJJOiAgIGh0dHBzOi8vc2VsZi1pc3N1ZWQuaW5mby8KCgogICBBbnRob255IE5hZGFsaW4KICAg TWljcm9zb2Z0CgogICBFbWFpbDogdG9ueW5hZEBtaWNyb3NvZnQuY29tCgoKICAgSm9lcmcgUmlj aHRlcgogICBwZHYgRmluYW5jaWFsIFNvZnR3YXJlIEdtYkgKCiAgIEVtYWlsOiBqb2VyZy5yaWNo dGVyQHBkdi1mcy5kZQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkpvbmVzLCBldCBh bC4gICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxNywgMjAyMSAgICAgICAgICAgICAgICBbUGFn ZSA3XQo= --_005_BY5PR00MB06769A4EE70D2072492AB907F57C0BY5PR00MB0676namp_-- From nobody Thu Jul 16 23:10: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 780CB3A12AA for ; Thu, 16 Jul 2020 23:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 RiYUryPUs9jL for ; Thu, 16 Jul 2020 23:09:58 -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 E551A3A12A8 for ; Thu, 16 Jul 2020 23:09:57 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B7LLh4bbBzyr5; Fri, 17 Jul 2020 08:09:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Fri, 17 Jul 2020 08:09:36 +0200 Cc: "barryleiba@computer.org" , "cbor@ietf.org" , Juergen Schoenwaelder X-Mao-Original-Outgoing-Id: 616658976.5062751-93d88e5d6c978da7e2e9b878a3d8f17c Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mike Jones X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Please post draft-ietf-cbor-date-tag-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 06:10:00 -0000 I believe this is now ready for pushing the =E2=80=9Csubmit to IESG=E2=80=9D= button. (The RFC editor can do the conversion from =E2=80=9CJuergen = Schoenwaelder=E2=80=9D to =E2=80=9CJ=C3=BCrgen Sch=C3=B6nw=C3=A4lder=E2=80= =9D in the Acknowledgements after converting the XML to v3.) Gr=C3=BC=C3=9Fe, Carsten > On 2020-07-17, at 02:19, Mike Jones = wrote: >=20 > Hi Barry, > =20 > Can I please ask you to have the secretariat post = draft-ietf-cbor-date-tag-05 (attached)? It contains the changes = discussed during the working group meeting yesterday, plus adds a = clarifying statement suggested by Juergen Schoenwaelder. > =20 > Carsten, I really like having the table of examples that you = suggested! > =20 > -- Mike > =20 > = ________= _______________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Fri Jul 17 00:03: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 09AB53A0F6A; Fri, 17 Jul 2020 00:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 YxurHGi0Muhi; Fri, 17 Jul 2020 00:02:55 -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 B10543A0FE2; Fri, 17 Jul 2020 00:02:55 -0700 (PDT) Received: from client-0073.vpn.uni-bremen.de (client-0073.vpn.uni-bremen.de [134.102.107.73]) (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 4B7MWw3Lmpz1047; Fri, 17 Jul 2020 09:02:51 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <88c9f054-66f5-565c-ed2c-bb8779add10a@sit.fraunhofer.de> Date: Fri, 17 Jul 2020 09:02:41 +0200 Cc: Mike Jones , "draft-ietf-cbor-date-tag@ietf.org" , "cbor@ietf.org" , Juergen Schoenwaelder X-Mao-Original-Outgoing-Id: 616662161.568982-d481cce2fe8f55a1378c60d6e799dcb0 Content-Transfer-Encoding: quoted-printable Message-Id: <5A6E6F36-0C1E-4763-9093-2A00AE6C00AE@tzi.org> References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <20200716133721.j5xduwghxcv4kok3@anna.jacobs.jacobs-university.de> <88c9f054-66f5-565c-ed2c-bb8779add10a@sit.fraunhofer.de> To: Henk Birkholz X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] [EXTERNAL] Re: draft-ietf-cbor-date-tag-02 - handling of time zone offsets X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 07:02:58 -0000 > On 2020-07-16, at 19:48, Henk Birkholz = wrote: >=20 >> As a general comment, we really have to work on some terminology = here. >=20 > +1 (to no big surprise, I'd assume) > But where would that text go? (or better, to which Appendix) draft-bormann-cbor-time-tag, I=E2=80=99d say. The terminology being used in draft-ietf-cbor-date-tag is = self-explanatory, so no need for a discussion there. This is really more about *not* using the *wrong* terminology. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 17 07:47:07 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 ACDEC3A0C99; Fri, 17 Jul 2020 07:46:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <159499721252.19290.7555832724080487656@ietfa.amsl.com> Date: Fri, 17 Jul 2020 07:46:52 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-date-tag-05.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: Fri, 17 Jul 2020 14:46:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF. Title : Concise Binary Object Representation (CBOR) Tags for Date Authors : Michael B. Jones Anthony Nadalin Jörg Richter Filename : draft-ietf-cbor-date-tag-05.txt Pages : 7 Date : 2020-07-17 Abstract: The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (RFC 3339 date/time string) and tag 1 (Posix "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for an RFC 3339 date text string, for applications needing a textual date representation within the Gregorian calendar without a time. It also defines a CBOR tag for days since the date 1970-01-01 in the Gregorian calendar for applications needing a numeric date representation without a time. This specification is intended as the reference document for IANA registration of the CBOR tags defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-date-tag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-date-tag-05 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-date-tag-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-date-tag-05 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 Fri Jul 17 09:49:40 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 D5B123A094C for ; Fri, 17 Jul 2020 09:49:38 -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 Ydx5pj21Lk7W for ; Fri, 17 Jul 2020 09:49:37 -0700 (PDT) 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 3190E3A094A for ; Fri, 17 Jul 2020 09:49:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LOitnzJ+PBNcny3aQuCK9dC15YG78MbQnjx6g+8wE8fk16m+1VmvYoIK46AeBJ55kR40lQ0H86mpwBG4yp/9HtIpnrCqxa0k4YZbMdawXMS4E40KCzMzRvd3Nu1S7o+AbO+wRRBxGZY7Gj75waRq1eG+53e7uHVuCcR4xAe9LS1Il7p8zJxklDZH1fRno6YJyFhKp/myEQZWpCfaovsTANGDySwaHiM6AccoLZRt5UQlqOEWo0xG75eDAoY4JRVC5ymQvDLZ9tkjAqzwjbZZ7ejW/Bw3xjYVBU4dLGzguaokzHsDezpwuZANxkWNK100PmwAvW7Yf1kcZYxNpsUZsw== 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=9k8N8CvinhALA+qaWttdJybA3Uu/rNYiFjDi1+AYRjo=; b=A9dvMGu+9iEMpa9a+0ZBw+D6WE69lpsYS2PDC1eHxoAdYQSY0yq0e21Ggf3BpOWW+7IkTz+Tk4CKZY9i3Cmijcg7I/wsnuQgE3qJJ6BFtxvVBgrREYw+XlzHYDkVs3PAB8769FFSmsl36mSJ6Yz4GTi26DdLHToity7L0pM6E3XzrCCGpYb7RuWFNTX/VBdNxM4tls1Vjm4kdkbKBWkw9fTDbYJBM3hHq7S94gWkzKHMwYX69W+h/dNsCi8jm/l+zxpOt2yl2rIjZmPVCd4tjoHUSQGqNiFueOljz9qzSbWajcX6O+lR6bAsScP6r411/t3JwJ7zlDWxoWwtqpTwqA== 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=9k8N8CvinhALA+qaWttdJybA3Uu/rNYiFjDi1+AYRjo=; b=JSiYOyEW5/v9fX5Ir1xHH/EOGGFN2wtWSmfjYhCtAflF8M9H5r5WHEv28dSM24fRlmHcA05i6H1tmmugRK0N078K7GtgdWvGl5Gtt6sdVQksdQZ1T/UCZT3ZC7sUgwTdmlgk/1ILwZUzAD115qugmALEq+9txJsowtC7/vIjcNM= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0664.namprd00.prod.outlook.com (2603:10b6:610:ac::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3238.0; Fri, 17 Jul 2020 16:49:35 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::5821:2d92:80e8:85d5]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::5821:2d92:80e8:85d5%9]) with mapi id 15.20.3242.000; Fri, 17 Jul 2020 16:49:35 +0000 From: Mike Jones To: Carsten Bormann CC: "barryleiba@computer.org" , "cbor@ietf.org" , Juergen Schoenwaelder Thread-Topic: [Cbor] Please post draft-ietf-cbor-date-tag-05 Thread-Index: AdZcWj3gmepq5v8uTVOUAVJvPGst8g== Date: Fri, 17 Jul 2020 16:49:34 +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_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-17T16:44:09Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5b3b26ac-3f51-4a35-862f-17ae9e02f874; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6793dc33-f1b2-492e-5042-08d82a7162ca x-ms-traffictypediagnostic: CH2PR00MB0664: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WgrzL69t3ofr0XTWWyH2vY8IDBacA4HMfk1Qt3oMx8hqo8LuCY7LVxBwxobiwIGt3GQ5q1UngKiIMiZoxmTo3DfzPWdOb1Tq/03DhwJH14Yq4T6CShsXVx4rBPrknyiKI0Fj90p5dC5uA3qbD6hAfgc862JiYmdQYoPyPHsapBj3lackVGN0NqnKOn0vqLMxRN5UGl532SCAVeK8lSALBhspM/iXsFltoN3+xiHPz2YAjOtvUMX0uTIgxUXZrQeDGCwp9YuZxDWlrqkN8W7wQdeAj6N8WGy+z+SyGY0mZI/vYc8fj0+1CNylGN2Grto/K6E+9jomYuW0ggX0PaCaiMMPb7koYrj05fbNZIY1S0xaulAtI5kWtTT5LOfCZZ14NbbkLK7G6YDK6E1/w6eezw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0679.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(136003)(396003)(366004)(39860400002)(5660300002)(83380400001)(6506007)(10290500003)(2906002)(66946007)(53546011)(76116006)(33656002)(966005)(66574015)(8676002)(52536014)(71200400001)(64756008)(66556008)(66446008)(26005)(54906003)(66476007)(7696005)(86362001)(6916009)(186003)(316002)(8990500004)(478600001)(8936002)(55016002)(4326008)(82950400001)(82960400001)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: hDDjXtAG1j5vWSegDHge3DjllZfMOGOaMY/6PU/ai1N9XPyhfqM42Wpm2PxLXVTF4VrqMWm/NC/cW5nKjHtDkxZbgLSZj7AzrSFVYZvKaKyHRyrDA7SimmNTOpZyQKeWHe/+AIgFUL1jyMNUckMWc9ijiJVf1xPWdQVOAS/5gzd8NszAJZs9PbRm3lSvT8Y5dp79B+7MHxuA0SlL2/WhM5io6+YULDCAfgToRN5KfbWXMV7m0fViMB1Q59P+Bmk6nWZp3Pzn4EhRyuOKimhgG4D9JWy4mzf3txBBFNuBG3vCkyF5PGcnCkGW0TUu3fNmdJFYs3mLI5io6xNV5pVHiFJtJU0MKeLjarK2v0J6kIUqJy8lmhz19BbPVKqb4zF24wvLywDBam86x/str4viem+Z9usWtngRi5JkwC5ZUUV2OaheLZpeHey5TJ4NkRrMdfWeSfeqpqMQF2ctDQ6egOArmMqzSK+S4eV5kcjazRpu5gNnqRGcEahHC/XqcElWnQRDNG4L2Q9MhbQ9dp2puGh7GXJzHQ85bc7vwSQHlfvMXlvT5GpHq11QtJ1Qkv3cGS0eDl+1uCVQufk7fiaD8j5tUXGDZmQnVBGvrwo1Hv6iLEcbwP44YZVujFO7cWDdlxOyybcAOhjT88jqBx6cNg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0679.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6793dc33-f1b2-492e-5042-08d82a7162ca X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2020 16:49:34.8777 (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: dBzixToOpuatvwf8BZcnWosKbrJPYZ6kAc+6RR6+piRcMYHy2RfSq8dZKprfDC5hdRHlByWQ6ljI3VmtxxYnww== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0664 Archived-At: Subject: Re: [Cbor] Please post draft-ietf-cbor-date-tag-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 16:49:39 -0000 VGhhbmtzIGZvciB5b3VyIGhlbHAgd2l0aCB0aGlzLCBDYXJzdGVuIQ0KDQpJIGxvb2sgZm9yd2Fy ZCB0byBuZXh0IG5hdmlnYXRpbmcgdGhpcyB0aHJvdWdoIHRoZSBJRVNHIHJldmlldyBwcm9jZXNz Lg0KDQoJCQkJTGF0ZXIsDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+IA0KU2VudDogVGh1cnNkYXks IEp1bHkgMTYsIDIwMjAgMTE6MTAgUE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20+DQpDYzogYmFycnlsZWliYUBjb21wdXRlci5vcmc7IGNib3JAaWV0Zi5vcmc7 IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5 LmRlPg0KU3ViamVjdDogUmU6IFtDYm9yXSBQbGVhc2UgcG9zdCBkcmFmdC1pZXRmLWNib3ItZGF0 ZS10YWctMDUNCg0KSSBiZWxpZXZlIHRoaXMgaXMgbm93IHJlYWR5IGZvciBwdXNoaW5nIHRoZSDi gJxzdWJtaXQgdG8gSUVTR+KAnSBidXR0b24uDQoNCihUaGUgUkZDIGVkaXRvciBjYW4gZG8gdGhl IGNvbnZlcnNpb24gZnJvbSDigJxKdWVyZ2VuIFNjaG9lbndhZWxkZXLigJ0gdG8g4oCcSsO8cmdl biBTY2jDtm53w6RsZGVy4oCdIGluIHRoZSBBY2tub3dsZWRnZW1lbnRzIGFmdGVyIGNvbnZlcnRp bmcgdGhlIFhNTCB0byB2My4pDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KDQo+IE9uIDIwMjAtMDct MTcsIGF0IDAyOjE5LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBk bWFyYy5pZXRmLm9yZz4gd3JvdGU6DQo+IA0KPiBIaSBCYXJyeSwNCj4gIA0KPiBDYW4gSSBwbGVh c2UgYXNrIHlvdSB0byBoYXZlIHRoZSBzZWNyZXRhcmlhdCBwb3N0IGRyYWZ0LWlldGYtY2Jvci1k YXRlLXRhZy0wNSAoYXR0YWNoZWQpPyAgSXQgY29udGFpbnMgdGhlIGNoYW5nZXMgZGlzY3Vzc2Vk IGR1cmluZyB0aGUgd29ya2luZyBncm91cCBtZWV0aW5nIHllc3RlcmRheSwgcGx1cyBhZGRzIGEg Y2xhcmlmeWluZyBzdGF0ZW1lbnQgc3VnZ2VzdGVkIGJ5IEp1ZXJnZW4gU2Nob2Vud2FlbGRlci4N Cj4gIA0KPiBDYXJzdGVuLCBJIHJlYWxseSBsaWtlIGhhdmluZyB0aGUgdGFibGUgb2YgZXhhbXBs ZXMgdGhhdCB5b3Ugc3VnZ2VzdGVkIQ0KPiAgDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQo+ICANCj4gPGRyYWZ0LWlldGYt Y2Jvci1kYXRlLXRhZy0wNS54bWw+PGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wNS50eHQ+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0JPUiBtYWls aW5nIGxpc3QNCj4gQ0JPUkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Nib3INCg0K From nobody Tue Jul 21 10:37: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 48DF93A0C88; Tue, 21 Jul 2020 10:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-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 lEMvfvBe-lu9; Tue, 21 Jul 2020 10:37:23 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2063.outbound.protection.outlook.com [40.107.21.63]) (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 755AB3A0C86; Tue, 21 Jul 2020 10:37:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MdKWagWHfRfj3AhW067RiRn5KKB0zbPgML/hLpVFP1cnlY+3DirX7mHK3sUFnRmz4g+7q0ufNyBiEMdWxS929IQA1lxH/KXrU5dtqhFfEd3JdtBohyys/VLwVotIPeeLnrV6oZqMQTEnnhTLZgNT9vsUQGOHDFXKILs/vQGFkXgYAeaq3KoOJVX9hf1n30nym6SKOZObxmUs3Iyv7u2yaPMjOe5CXe4fGCeGgFezYa/oELmvOgMn6gPTEHufToMVpUzcwn4kodDcVJtujtJhi1VzRxdatF6WH75oaMmG1L/5W/pzFMTk6Mdim7DCo4j1CFW3JIyt/1YeARUfCQjsWQ== 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=oFLHs/XzsESJSRvlW3Bi5+hVr/J8PA7QT17hEqk+dy4=; b=JBVi4wMs8zvaCWtAjAc4gO4BfZ9V5Q8vLwF6CYYRI+NExAsJPON5XgEK87+JlSohw3Gz1/is3VuD39UPICQXA7182TCUeWSivv6LPeX5WWyyOq67phcsVvvyz8LRo0FObrNL/MLsGuVnWjxO+P41UuRwuAFl5eFxXL4crrssLHHekDWZqSM7a7m+Yn0Q7AmFeB3+8cClDCDe3ZMZMGZg9dcu6qFbkQU5qNm5/bt0Mb9OFUIq4+Df+rBGLwC/xf1bDPBUkfaFtiADSeRBH/ry+N2CfuDwLV1m2k+/N//ulMi6VUpLCApcHBR+zmZoGQ3lN1CWGCcLcOyFauIYEr06rg== 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=oFLHs/XzsESJSRvlW3Bi5+hVr/J8PA7QT17hEqk+dy4=; b=ghFnV4REkOcw6ypkrM8RxHLh/IUYoSmsWceSEkk+ZLIRqCLwYxTdx5/z0EgdpHDEwt3b4aCEEQSIlKX1p2da7Xf4UqmMkrj0BXEZqkaYb9h2y5WvuPRtQSvereAS7XVl5yiNzujs/effc4pWEYBLrnDL8rov1gDTQDL5uwpE4as= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR07MB4425.eurprd07.prod.outlook.com (2603:10a6:7:96::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.14; Tue, 21 Jul 2020 17:37:20 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3216.015; Tue, 21 Jul 2020 17:37:20 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: [Cbor] Agenda items for IETF 108 Thread-Index: AdZZRFx8lqU+zriIR/aroLtwmbKmAwGUfuAA Date: Tue, 21 Jul 2020 17:37:19 +0000 Message-ID: <5A5E8DD7-6C4E-4CAA-BF2B-A2F66F7BB79D@ericsson.com> References: <000e01d65944$7b896b60$729c4220$@augustcellars.com> In-Reply-To: <000e01d65944$7b896b60$729c4220$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [79.12.182.121] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 773a1541-a0c8-4475-4114-08d82d9cb828 x-ms-traffictypediagnostic: HE1PR07MB4425: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uM8HT+4h/qfXrBTXWnkkGu5OWxuSdiPsw2pMOiOolneV3T6qB2lwfog6NHxjF1cHg2Xuu8med3WN57Ub61fwohcnzZmgfYNcPk2MWjO5wvw6mdxAcfkQHK1Ke6//OzxnwZBXKRhZx9a3OKyecOWtC/h4/SgOt/ZhekSkLT3ZdeRBrXvXFLcAEHNHbg5nGKYOcVu13er49aeJutnESK744IHx4k/vGXsyQwpUMyc209Veo6U8xotwf/30hEv7SS/sr9OOBpPLhkmCulw3fUimvmaUowLE+lem+PnEL8+NhBEfpT82b2B43L1LkVKBDzDMuPPWw5E1IjmxPb1goZ7s7C3pHlKJq34erXHX9rjtx2snsRltPIhk2ZporHDufDgVy5t++5FXkDb9MHUci4eZYw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(136003)(396003)(39860400002)(376002)(316002)(33656002)(2616005)(26005)(66946007)(36756003)(8936002)(44832011)(6512007)(186003)(6486002)(5660300002)(91956017)(6916009)(6506007)(83380400001)(8676002)(4326008)(450100002)(66476007)(71200400001)(66556008)(64756008)(66446008)(2906002)(76116006)(478600001)(86362001)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 4DWHfRNWqy40C4NUUShwab6GMnGVg6eZcwEzqwRKpKqwGb0hMeszT0GUqIqhpwYn2OAIcIVS8txn43Ex152ZhVy/EFu0+1I433hHz8oL7fx7SvonxoEY3Km383C2KXn8xTqnjUFQuwDzlGcIWmJOvtFsx+UTlfQgCXe95J2TOqGJCIDyeZDpi5xvky3mJ4MxTzMRh1GSJkTsg3MfCOP/yZxdAtASnebRbfhUI+H18ehYnHV2RzZswnW/FMUzIrgk1Tg0LIXjlFfNykTza5n+DG2H4cwAPdkSvdStKf77LdYsIkPwlXNY773r6UlnT8cEI4gjCgXBhFP8OfQrmt9P6beFHnB+SE1MTQSSR8cOJ+u8zsIvB+09dSxWAjErDPJHGTcO2ypZky8cdP16vPzqzY6z57snTJOs6+5501faUuvksGc9D7RnQoDP0D/xug4nK44TMey50b9HdF6xZeZJ2P9TY+18StxSIQICOzzaAaI= 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 773a1541-a0c8-4475-4114-08d82d9cb828 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2020 17:37:19.9289 (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: QWOrjKsU9Wii4ay2UruYdvA1zB8XZpBaLnEb5DpdVK3wJzzyZX8ARuzUVqHccbBRGqJvuriKGKdfpV0Bk2PLnKAQEo8BPfwng44k37EypKoJQ/diueZQfk+sjO+5dJ4k X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4425 Archived-At: Subject: Re: [Cbor] Agenda items for IETF 108 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 17:37:24 -0000 SGkgYWxsLA0KDQpXZSBhcmUgbWVldGluZyBpbiBsZXNzIHRoYW4gYSB3ZWVrLiBBbiBhZ2VuZGEg aGFzIGJlZW4gcG9zdGVkOiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy8xMDgvYWdl bmRhL2FnZW5kYS0xMDgtY2Jvci0wMi5odG1sICBQbGVhc2UgbGV0IHlvdXIgY2hhaXJzIGtub3cg aWYgeW91IGhhdmUgYW55IGNvbW1lbnQuIA0KDQpXZSBhcmUgbG9va2luZyBmb3Igb25lIG1pbnV0 ZSB0YWtlciBhbmQgb25lIGphYmJlciBzY3JpYmUuIFBsZWFzZSBjb25zaWRlciB2b2x1bnRlZXJp bmcgaWYgeW91IGFyZSBwbGFubmluZyB0byBqb2luIHRoZSBzZXNzaW9uLg0KDQpQcmVzZW50ZXJz OiBzZW5kIHlvdXIgc2xpZGVzIGFzIHNvb24gYXMgcG9zc2libGUsIGFuZCBzaW5jZSB3ZSBhcmUg bWVldGluZyBvbiBNb25kYXkgbm8gbGF0ZXIgdGhhbiBTdW5kYXkgMjZ0aCBvZiBKdWx5LCAxMzow MCBVVEMuDQoNClRhbGsgdG8geW91IGFsbCBzb29uIQ0KRnJhbmNlc2NhDQoNClBsZWFzZSBzZWU6 IGh0dHBzOi8vd3d3LmlldGYub3JnL2hvdy9tZWV0aW5ncy8xMDgvc2Vzc2lvbi1wYXJ0aWNpcGFu dC1ndWlkZS8gZm9yIHBhcnRpY2lwYXRpb24gZ3VpZGVsaW5lcy4NCg0K77u/T24gMTMvMDcvMjAy MCwgMjA6MzYsICJDQk9SIG9uIGJlaGFsZiBvZiBKaW0gU2NoYWFkIiA8Y2Jvci1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCg0KICAg IFdlIGFyZSBjb2xsZWN0aW5nIGFnZW5kYSBpdGVtcyBmb3IgSUVURiAxMDguICBXZSBoYXZlIGEg NTAgbWludXRlIHNsb3QgYXQNCiAgICB0aGUgbWVldGluZy4gIElmIHlvdSB3YW50IHRvIGJlIG9u IHRoZSBhZ2VuZGEgcGxlYXNlIGxldCB0aGUgY2hhaXJzIGtub3cuDQoNCiAgICBQbGVhc2UgaW5j bHVkZSB0aGUgZm9sbG93aW5nIGRhdGEgaW4geW91ciBhZ2VuZGEgcmVxdWVzdDoNCg0KICAgIDEu IFRoZSBkb2N1bWVudChzKSB0aGF0IHRoZSBwcmVzZW50YXRpb24gYXBwbGllcyB0byAyLiBXaG8g aXMgZ2l2aW5nIHRoZQ0KICAgIHByZXNlbnRhdGlvbiAzLiAgSG93IGxvbmcgZG8geW91IGV4cGVj dCB0aGUgcHJlc2VudGF0aW9uIHRvIHRha2UuDQogICAgNC4gIEFyZSB0aGVyZSBhbnkgb3JkZXJp bmcgaXNzdWVzIHRoYXQgbmVlZCB0byBiZSBub3RlZC4NCg0KICAgIEppbSAmIEZyYW5jZXNjYQ0K DQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ICAgIENCT1IgbWFpbGluZyBsaXN0DQogICAgQ0JPUkBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Jvcg0KDQo= From nobody Fri Jul 24 05:40:23 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 6BA523A09A5; Fri, 24 Jul 2020 05:40:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.10.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-cbor-7049bis@ietf.org, Francesca Palombini , barryleiba@gmail.com, cbor-chairs@ietf.org, francesca.palombini@ericsson.com, cbor@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159559442198.3981.9583805066975200579@ietfa.amsl.com> Date: Fri, 24 Jul 2020 05:40:22 -0700 Archived-At: Subject: [Cbor] Last Call: (Concise Binary Object Representation (CBOR)) to Internet Standard X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 12:40:22 -0000 The IESG has received a request from the Concise Binary Object Representation Maintenance and Extensions WG (cbor) to consider the following document: - 'Concise Binary Object Representation (CBOR)' as Internet Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-08-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-cbor-7049bis/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc4648: The Base16, Base32, and Base64 Data Encodings (Proposed Standard - IETF stream) rfc4287: The Atom Syndication Format (Proposed Standard - IETF stream) rfc3339: Date and Time on the Internet: Timestamps (Proposed Standard - IETF stream) rfc2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies (Draft Standard - IETF stream) From nobody Fri Jul 24 13:40:21 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 8286C3A0B8B; Fri, 24 Jul 2020 13:40:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francesca Palombini via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.10.0 Auto-Submitted: auto-generated Precedence: bulk Cc: francesca.palombini@ericsson.com, cbor-chairs@ietf.org, cbor@ietf.org, iesg-secretary@ietf.org, Francesca Palombini Message-ID: <159562321852.6192.17438988990707843448@ietfa.amsl.com> Date: Fri, 24 Jul 2020 13:40:18 -0700 Archived-At: Subject: [Cbor] Publication has been requested for draft-ietf-cbor-date-tag-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 20:40:19 -0000 Francesca Palombini has requested publication of draft-ietf-cbor-date-tag-05 as Proposed Standard on behalf of the CBOR working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-cbor-date-tag/ From nobody Fri Jul 24 14:37: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 C750B3A0CDC; Fri, 24 Jul 2020 14:37:23 -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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 gzKYCWNuxL8O; Fri, 24 Jul 2020 14:37:22 -0700 (PDT) Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) (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 49EE63A0CD0; Fri, 24 Jul 2020 14:37:18 -0700 (PDT) Received: by mail-il1-f176.google.com with SMTP id i18so8375917ilk.10; Fri, 24 Jul 2020 14:37:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=QSVAgk+oi0xibTo+C2wvpjVYf6fOZ84/I4sr/CYQPlg=; b=cmEYmnjg5ucn7WoEcq5QHrVPgfRxDBNFsZt4ZfxCP+5A8GKHJy6rSD5m1uutDBm4Bo 2Sfdmo+uzNdPhitqv6PwhVfX9BoCfTsMMINb48JEKxwKVFI/R8xMpNGrKstbHMxiQdkl MThZs2KWiXcGz3LnA33gGdR7qsxv10bJvDaRuylsbqWh/Y0G0uuu0e12Ufcc5EDEHj4/ wZ6Lq3cwxzuPKpPuWqRoU0U6ihTbNymV+rP6w08MvtBKvUJHDzV3gadCXnGqPY2fRCPm 74uxGRYvk/D5DWZuQW/aRXJbv3l2kT0gsRYoFs0Gpv4DpMDPtVMn0C+CoyC5lE2t8Xxo 71uA== X-Gm-Message-State: AOAM531JTYu6lGTllldXirx9JFQmdHEXd7h5ElYVL8SGqC48cL9VY/l0 vSlo55VjiKL9Pzq1WeNYoK2pO8XCxGWtRQKxBRScfg== X-Google-Smtp-Source: ABdhPJy5n9WA3SZR/RkNWe9j9G+acWYVZK5hXzEBX8k1jnJrlv4qy6j6tKPy16mfqooKHpzv+0sk/LGSxpOSBhx0drs= X-Received: by 2002:a92:cf42:: with SMTP id c2mr5835275ilr.13.1595626637995; Fri, 24 Jul 2020 14:37:17 -0700 (PDT) MIME-Version: 1.0 From: Barry Leiba Date: Fri, 24 Jul 2020 17:37:07 -0400 Message-ID: To: "draft-ietf-cbor-date-tag.all@ietf.org" Cc: "cbor@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f3b1c705ab36c63b" Archived-At: Subject: [Cbor] AD review of draft-ietf-cbor-date-tag-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 21:37:24 -0000 --000000000000f3b1c705ab36c63b Content-Type: text/plain; charset="UTF-8" Thanks for a short, clear document, which I will request last call on now. Apart from noting that I would have used Jim Morrison rather than John Lennon, my only comment is about whether we should be citing 7049bis (which has just started last call) now. Barry --000000000000f3b1c705ab36c63b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for a short, clear document, which I will request = last call on now.=C2=A0 Apart from noting that I would have used Jim Morris= on rather than John Lennon, my only comment is about whether we should be c= iting 7049bis (which has just started last call) now.

Barry

--000000000000f3b1c705ab36c63b-- From nobody Fri Jul 24 15:03:24 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 39F3C3A0528; Fri, 24 Jul 2020 15:03:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.10.0 Auto-Submitted: auto-generated Precedence: bulk CC: francesca.palombini@ericsson.com, cbor@ietf.org, Francesca Palombini , cbor-chairs@ietf.org, draft-ietf-cbor-date-tag@ietf.org, barryleiba@gmail.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159562820221.26542.5861240436120674880@ietfa.amsl.com> Date: Fri, 24 Jul 2020 15:03:22 -0700 Archived-At: Subject: [Cbor] Last Call: (Concise Binary Object Representation (CBOR) Tags for Date) to Proposed Standard X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 22:03:22 -0000 The IESG has received a request from the Concise Binary Object Representation Maintenance and Extensions WG (cbor) to consider the following document: - 'Concise Binary Object Representation (CBOR) Tags for Date' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-08-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (RFC 3339 date/time string) and tag 1 (Posix "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for an RFC 3339 date text string, for applications needing a textual date representation within the Gregorian calendar without a time. It also defines a CBOR tag for days since the date 1970-01-01 in the Gregorian calendar for applications needing a numeric date representation without a time. This specification is intended as the reference document for IANA registration of the CBOR tags defined. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-cbor-date-tag/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jul 24 15:36:03 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 5CA0D3A09DA; Fri, 24 Jul 2020 15:36:02 -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 c69-U6OMzWFz; Fri, 24 Jul 2020 15:36:00 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650120.outbound.protection.outlook.com [40.107.65.120]) (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 7B97E3A09D7; Fri, 24 Jul 2020 15:36:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hqo1xOFK1GQ6oB+CnrfMJOgKlntKKhwgY025p7WVxiAtO/WTdKzRs2kZQRrgEDDIpQn3lX5/vJpMRxtZznHsa79kqHXD8oh/a35wDlKMVRvNvTRfx9RSeD141K8WWxl/K6bYMmbRBsjQhj+sLEaKxtC/U+L7QU+2rqGLibHgnH9OAPdFo9WzI7PxSkLRI7jCQy42KMk+HFNNB/vjOEEc087wo+B7V4JDUTUqKgSQWGY/5hU3f/OJXuM77QjKl23L9koQlFamitxPxjAz313nIHysvGxNt8Ow6Kw/HwP8zqAFjrtjIoguv5zw8QNrKUeSMe53StKciUVGKAUhY+DPpQ== 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=G+sWrk3QJmzwvVdNQQCqZk7B/OmMyymXBhEznBAhnB8=; b=hfhxqp/I3lPamitVSdgIiaGwXc38orBIaIV4fzpEtfEfZ947h3+aMXQ7flG8MYBbdL8pthyhvWtXZcZqYV3w4HPrZiuGng/eqjoQ25lcdiBORhrjlSGowDnDdSTR+CvsMG2vt7olx86mVhe/2/l2w6YM31D9rcQazbKPbzp4GBelwtwlQLc4t4iUuYtK+xv15g9MnoVpUtZaCMgGMk4cCRtX7abH36YVtxIqkGDE9OE2b8dMqYyb1pjNYigMk4a2CxSiLI5yozoL3MI+ZPWq9KeFY8N3q7w1XC/8EcnmJ8JL/qEtZw9mzS11WzgPsRd5wlOsPGWr5tFecNjtpEB7Iw== 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=G+sWrk3QJmzwvVdNQQCqZk7B/OmMyymXBhEznBAhnB8=; b=Wt2UsFsoiukYhgW8bhcrsY5Wcw8ErKsPw1lG9SiIhJQM3/zcxj37qMMpL1MWpEd/0Knph12ASmSCOoqjAr96GE+4B8fitFzazMQmOShx4cs1qu40jkZ+0X7fxd9a1L8j0T+Bq96ARM7FfKKwKOGsks4aXUpqZpeE7vON6u73+Q4= Received: from BY5PR00MB0676.namprd00.prod.outlook.com (2603:10b6:a03:20c::15) by BYAPR00MB0887.namprd00.prod.outlook.com (2603:10b6:a03:102::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3256.0; Fri, 24 Jul 2020 22:35:57 +0000 Received: from BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::498b:43df:efed:d250]) by BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::498b:43df:efed:d250%7]) with mapi id 15.20.3265.000; Fri, 24 Jul 2020 22:35:57 +0000 From: Mike Jones To: Barry Leiba , "draft-ietf-cbor-date-tag.all@ietf.org" CC: "cbor@ietf.org" Thread-Topic: [EXTERNAL] AD review of draft-ietf-cbor-date-tag-05 Thread-Index: AQHWYgKhuvAW4nlVeEecyAbOcOWV26kXUJWg Date: Fri, 24 Jul 2020 22:35:56 +0000 Message-ID: References: In-Reply-To: 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=029443ea-8358-4cf4-b707-830a4fc78d01; 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-07-24T22:32:25Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: computer.org; dkim=none (message not signed) header.d=none; computer.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.89.111] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 461807ec-d816-49c9-865b-08d83021eed1 x-ms-traffictypediagnostic: BYAPR00MB0887: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ge9pmOB3+6G93GdBUIRrjGFqGKPSr0dlTudIxeg8PaC17rsohQJnMaWTnz8dURKU4O9jeDjlHMhs6avbehfiiAOWm3dl2vI/FfCTAwFsC4NVH2EAk/1E9cV72uJFWMOIhWEonSobFIDsGDS/vg0LmY5ogA17BPLVJQpN4sQWmcwHP9DtXt8V9tMfWIm4IIOBUzCbn0Bg8lZ1H5NKaAFdHlvX/GtFW5/uuwxCwxk33w0OmtmVFM96zvW6l9mEqpZqZ/9hf+z65Phi8DOVZ1uAntvz95Z0JIJ2xbyUCI3F6OANL5hg1im2XvqD3yQ33qXBX1mqruJ+E1xdurjZ17iodw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR00MB0676.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(39860400002)(376002)(346002)(136003)(478600001)(83380400001)(82960400001)(55016002)(82950400001)(66556008)(2906002)(52536014)(33656002)(64756008)(66446008)(66476007)(7696005)(4744005)(9686003)(66946007)(5660300002)(86362001)(76116006)(53546011)(8936002)(6506007)(8676002)(110136005)(71200400001)(8990500004)(26005)(10290500003)(186003)(4326008)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 0E8zBOqY0R2flxpW2LYKEii6cAggCkghhE4ihtCcxHNy7n3kapyA9lGSTgXugJilGUy4zi0u4VR1VsCxF800ncfqfYtG+P3VQuXOWkJmrrQpbR5Bo0Q4OWAaEG/3sF3bBXxuxwrtYH8XoY/G8LKTISUAfm6v1IpIys/Lbcmg5Nox3wNqdNDOT6fmPT0qr6OFlPVkmNDUg+NhHG7OmnxP7zdKz4Sss33QbjmEvYj4Gw3TP8MuMiU4p0gEV37GbKx1O9PFVRPoDBx9pWsKFEkmwHQP/6hEEGZE/vNHej5u+0zDXHIz7RQXk9zn/5C8/pU+sWyg7AG0fpLCGuhilRf/7GdlBnYChIRgHqeAfYSQpwBMfFYktsOrETFwaUMJmwJUa+JsXz49LsVUUwKU8bf4R8aETVJDBIaM9ywlqQcxzmuGYXFW1DgA+Qf7O8RmbPa3lU5k/02l8q5X5kmbt+TaqCkeU7arHPjnfh1BFqGHo00C8huLgTv7d4Y3JOw4tl2nZr9w1XyzhCutPqwllmHmXMUMgJJndrFGXcC7lRGtCYleODyZmrSIKORdlxXnqvwYx2a9oSE3yqQIjf5rcOIRzyfkhE6F0DuMkw0Ugop0asreiES1KZI3JW+7zSQTZ3xfZda9vJ7VGwa0h9VlQrYdfQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR00MB06763267E4808309775ADA0EF5770BY5PR00MB0676namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR00MB0676.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 461807ec-d816-49c9-865b-08d83021eed1 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2020 22:35:57.0095 (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: JF+jJb9wZFXmf98llGOT5G6KcWcywnGv9izsyErUfXjigUPwJfc9bS9Ot+VbIfhtOrw4WA7aoZQO/l5Zvq6MhQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR00MB0887 Archived-At: Subject: Re: [Cbor] [EXTERNAL] AD review of draft-ietf-cbor-date-tag-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 22:36:03 -0000 --_000_BY5PR00MB06763267E4808309775ADA0EF5770BY5PR00MB0676namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IG1hZGUgbWUgc21pbGUgd2l0aCB0aGUgSmltIE1vcnJpc29uIGNvbW1lbnQuDQoNCkluIHJl c3BvbnNlIGFuIGVxdWl2YWxlbnQgcXVlc3Rpb24gaW4gYSB3b3JraW5nIGdyb3VwIHJldmlldyBh Ym91dCA3MDQ5YmlzLCBJ4oCZZCByZXBsaWVkIHRoYXQgSSBkb27igJl0IHdhbnQgdG8gdGFrZSBh IHNjaGVkdWxlIGRlcGVuZGVuY3kgb24gaXQsIGFzIGl0cyByZXZpZXcgaXMgbGlrZWx5IHRvIHRh a2UgbXVjaCBsb25nZXIgdGhhbiB0aGF0IGZvciB0aGlzIGRyYWZ0LiAgQnV0IGlmIGl0IGRvZXMg aGFwcGVuIHRvIHJlc2lkZSBpbiB0aGUgUkZDIEVkaXRvciBxdWV1ZSBhdCB0aGUgc2FtZSB0aW1l LCBJ4oCZZCBiZSBnbGFkIHRvIGRpcmVjdCB0aGUgUkZDIEVkaXRvciB0byB1cGRhdGUgdGhlIHJl ZmVyZW5jZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIENoZWVycywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJh QGNvbXB1dGVyLm9yZz4NClNlbnQ6IEZyaWRheSwgSnVseSAyNCwgMjAyMCAyOjM3IFBNDQpUbzog ZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLmFsbEBpZXRmLm9yZw0KQ2M6IGNib3JAaWV0Zi5vcmcN ClN1YmplY3Q6IFtFWFRFUk5BTF0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRh Zy0wNQ0KDQpUaGFua3MgZm9yIGEgc2hvcnQsIGNsZWFyIGRvY3VtZW50LCB3aGljaCBJIHdpbGwg cmVxdWVzdCBsYXN0IGNhbGwgb24gbm93LiAgQXBhcnQgZnJvbSBub3RpbmcgdGhhdCBJIHdvdWxk IGhhdmUgdXNlZCBKaW0gTW9ycmlzb24gcmF0aGVyIHRoYW4gSm9obiBMZW5ub24sIG15IG9ubHkg Y29tbWVudCBpcyBhYm91dCB3aGV0aGVyIHdlIHNob3VsZCBiZSBjaXRpbmcgNzA0OWJpcyAod2hp Y2ggaGFzIGp1c3Qgc3RhcnRlZCBsYXN0IGNhbGwpIG5vdy4NCg0KQmFycnkNCg0K --_000_BY5PR00MB06763267E4808309775ADA0EF5770BY5PR00MB0676namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3 MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPllvdSBtYWRlIG1lIHNtaWxlIHdpdGggdGhlIEppbSBN b3JyaXNvbiBjb21tZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SW4g cmVzcG9uc2UgYW4gZXF1aXZhbGVudCBxdWVzdGlvbiBpbiBhIHdvcmtpbmcgZ3JvdXAgcmV2aWV3 IGFib3V0IDcwNDliaXMsIEnigJlkIHJlcGxpZWQgdGhhdCBJIGRvbuKAmXQgd2FudCB0byB0YWtl IGEgc2NoZWR1bGUgZGVwZW5kZW5jeSBvbiBpdCwgYXMgaXRzIHJldmlldyBpcyBsaWtlbHkgdG8g dGFrZSBtdWNoIGxvbmdlciB0aGFuIHRoYXQgZm9yIHRoaXMgZHJhZnQuJm5ic3A7DQogQnV0IGlm IGl0IGRvZXMgaGFwcGVuIHRvIHJlc2lkZSBpbiB0aGUgUkZDIEVkaXRvciBxdWV1ZSBhdCB0aGUg c2FtZSB0aW1lLCBJ4oCZZCBiZSBnbGFkIHRvIGRpcmVjdCB0aGUgUkZDIEVkaXRvciB0byB1cGRh dGUgdGhlIHJlZmVyZW5jZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDaGVlcnMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBCYXJyeSBMZWliYSAm bHQ7YmFycnlsZWliYUBjb21wdXRlci5vcmcmZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXks IEp1bHkgMjQsIDIwMjAgMjozNyBQTTxicj4NCjxiPlRvOjwvYj4gZHJhZnQtaWV0Zi1jYm9yLWRh dGUtdGFnLmFsbEBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gY2JvckBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBbRVhURVJOQUxdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWNib3ItZGF0 ZS10YWctMDU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZv ciBhIHNob3J0LCBjbGVhciBkb2N1bWVudCwgd2hpY2ggSSB3aWxsIHJlcXVlc3QgbGFzdCBjYWxs IG9uIG5vdy4mbmJzcDsgQXBhcnQgZnJvbSBub3RpbmcgdGhhdCBJIHdvdWxkIGhhdmUgdXNlZCBK aW0gTW9ycmlzb24gcmF0aGVyIHRoYW4gSm9obiBMZW5ub24sIG15IG9ubHkgY29tbWVudCBpcyBh Ym91dCB3aGV0aGVyIHdlIHNob3VsZCBiZSBjaXRpbmcgNzA0OWJpcyAod2hpY2ggaGFzIGp1c3Qg c3RhcnRlZA0KIGxhc3QgY2FsbCkgbm93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CYXJyeTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY5PR00MB06763267E4808309775ADA0EF5770BY5PR00MB0676namp_-- From nobody Fri Jul 24 16:30:37 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 87D6A3A0B3E; Fri, 24 Jul 2020 16:30:34 -0700 (PDT) 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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 BQ0nlke8XkGo; Fri, 24 Jul 2020 16:30:33 -0700 (PDT) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (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 075723A0B39; Fri, 24 Jul 2020 16:30:32 -0700 (PDT) Received: by mail-io1-f54.google.com with SMTP id t15so2552070iob.3; Fri, 24 Jul 2020 16:30:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fjJYjeY6YuLBC/MlgjV7pytToxIeclGNJumpYaGt8s8=; b=iC7fVAdmG0gZP23Y88BMnQ4BPSKLB+DQ5rzpWx8ie7KqkWKDkXm6AZWis/bLLG/tYu WbKoDrUsrPjhAW8IEZf20K/QzudLhmrslu+c6Uis5DVvBxGXQcpMj6dkKch7WuJ5lxgQ yDDSZXlSV1ts6KLClOWG19INZ5r0nZVucOX8wuvEfsBBNeZ8J7m0W+I74GIuF7lecr9q ZfnPpgrvYB8sUyc+VeXbr4pInlejZJZvs40fDyelt9squVGeabPas4gIQe+Qh575Dc8a qbcLl4X1fsLmIUq6zysOSdNs1BPIC0t7Vbqz2zjHw/j9NMJt5vsOkCY1t/vONT2titLz dgew== X-Gm-Message-State: AOAM532de7wgilkcQLSTv2VKfY/Cn9/QLMGof5nuAtPX6RTmcBKl46Qy ZNeXFNhLsl1DbgckDNiDUXZjMjlkQyWAjSvtZuU= X-Google-Smtp-Source: ABdhPJwUa4YSCOafRzP88R7HmvBiDk+CJ4Ko8I7zQlFcqLpADZrMQHQJ0oesvm8WkuGBBqu150CR5BsU/q0mPIgPX48= X-Received: by 2002:a6b:1885:: with SMTP id 127mr6316136ioy.17.1595633432183; Fri, 24 Jul 2020 16:30:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Fri, 24 Jul 2020 19:30:21 -0400 Message-ID: To: Mike Jones Cc: "cbor@ietf.org" , "draft-ietf-cbor-date-tag.all@ietf.org" Content-Type: multipart/alternative; boundary="000000000000eac87505ab385bdf" Archived-At: Subject: Re: [Cbor] [EXTERNAL] AD review of draft-ietf-cbor-date-tag-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 23:30:35 -0000 --000000000000eac87505ab385bdf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As it happens, I=E2=80=99ve been shuffling my Doors collection on my mornin= g walks for the last couple of days, so... The 7049bis answer is fine... sure, leave it to AUTH48, and we can update the reference then, if it makes sense. I=E2=80=99ll pass that on to the IE= SG in case the question comes up during IESG Evaluation. When the music=E2=80=99s over, turn out the lights, turn out the lights, tu= rn out the lights, Barry On Fri, Jul 24, 2020 at 6:36 PM Mike Jones wrote: > You made me smile with the Jim Morrison comment. > > > > In response an equivalent question in a working group review about > 7049bis, I=E2=80=99d replied that I don=E2=80=99t want to take a schedule= dependency on it, > as its review is likely to take much longer than that for this draft. Bu= t > if it does happen to reside in the RFC Editor queue at the same time, I= =E2=80=99d > be glad to direct the RFC Editor to update the reference. > > > > Cheers, > > -- Mike > > > > *From:* Barry Leiba > *Sent:* Friday, July 24, 2020 2:37 PM > *To:* draft-ietf-cbor-date-tag.all@ietf.org > *Cc:* cbor@ietf.org > *Subject:* [EXTERNAL] AD review of draft-ietf-cbor-date-tag-05 > > > > Thanks for a short, clear document, which I will request last call on > now. Apart from noting that I would have used Jim Morrison rather than > John Lennon, my only comment is about whether we should be citing 7049bis > (which has just started last call) now. > > > > Barry > > > --000000000000eac87505ab385bdf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As it happens, I=E2=80=99ve been shuffling my Doors = collection on my morning walks for the last couple of days, so...

The 7049bis answer is fine.= .. sure, leave it to AUTH48, and we can update the reference then, if it ma= kes sense.=C2=A0 I=E2=80=99ll pass that on to the IESG in case the question= comes up during IESG Evaluation.

When the music=E2=80=99s over, turn out the lights, turn out the = lights, turn out the lights,

Barry

On Fri, Jul 24, 2020 at 6:36 PM Mike Jones <Michael.Jones@microsoft.com> wrot= e:

You made me smile with= the Jim Morrison comment.

=C2=A0

In response an equival= ent question in a working group review about 7049bis, I=E2=80=99d replied t= hat I don=E2=80=99t want to take a schedule dependency on it, as its review= is likely to take much longer than that for this draft.=C2=A0 But if it does happen to reside in the RFC Editor queue at the same time, = I=E2=80=99d be glad to direct the RFC Editor to update the reference.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Cheers,

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 -- Mike

=C2=A0

From: Barry Leiba <barryleiba@computer.org>
Sent: Friday, July 24, 2020 2:37 PM
To: draft-ietf-cbor-date-tag.all@ietf.org
Cc: cbor@ietf.org=
Subject: [EXTERNAL] AD review of draft-ietf-cbor-date-tag-05<= u>

=C2=A0

Thanks for a short, clear document, which I will req= uest last call on now.=C2=A0 Apart from noting that I would have used Jim M= orrison rather than John Lennon, my only comment is about whether we should= be citing 7049bis (which has just started last call) now.

=C2=A0

Barry

=C2=A0

--000000000000eac87505ab385bdf-- From nobody Sat Jul 25 18:00: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 77BDB3A0522; Sat, 25 Jul 2020 18:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 d9cBjwQD8lmU; Sat, 25 Jul 2020 18:00:45 -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 012283A048A; Sat, 25 Jul 2020 18:00:44 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4BDl3t5f32zygQ; Sun, 26 Jul 2020 03:00:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <000e01d65b79$ad6f6ee0$084e4ca0$@augustcellars.com> Date: Sun, 26 Jul 2020 03:00:42 +0200 Cc: cbor@ietf.org, draft-bormann-cbor-packed@ietf.org X-Mao-Original-Outgoing-Id: 617418041.909428-3b308709bec59e55ebab9a6404d46350 Content-Transfer-Encoding: quoted-printable Message-Id: <6FD968BE-B5C0-46B5-AE03-A69A24E850C1@tzi.org> References: <00f701d65adb$1c49e1f0$54dda5d0$@augustcellars.com> <04545D98-A936-4DD0-8446-3634E6C12667@tzi.org> <000e01d65b79$ad6f6ee0$084e4ca0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Review draft-bormann-cbor-packed-00 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 01:00:49 -0000 On 2020-07-16, at 16:01, Jim Schaad wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: CBOR On Behalf Of Carsten Bormann >> Sent: Wednesday, July 15, 2020 12:43 PM >> To: Jim Schaad >> Cc: cbor@ietf.org; draft-bormann-cbor-packed@ietf.org >> Subject: Re: [Cbor] Review draft-bormann-cbor-packed-00 >>=20 >> Hi Jim, >>=20 >> Thanks for this lightning feedback. Let me try to answer as = quickly... >>=20 >>> On 2020-07-15, at 21:06, Jim Schaad wrote: >>>=20 >>> Carsten, >>>=20 >>> I am finding this document really hard to follow. >>=20 >> Yes. It contains the specification, but not yet any tutorial = material. >> Way too few examples. >>=20 >>> I am sure that we can get >>> it to read much better in the future. >>=20 >> Absolutely. >>=20 >>> Some of the issues that I am having >>> are: >>>=20 >>> 1. How the Tag 6 is used is dependent on the type of the embedded >>> content and this is not explained at all. It took me a while to >>> understand why >>> #6.6(0) was not a potential duplicate value between sections 2.1 and = 2.2. >>=20 >> Yes. >>=20 >> Section 3, second paragraph says this, but that may be a little = late=E2=80=A6 >>=20 >> (I always read the discussion before the normative part, so I just = didn=E2=80=99t notice.) >=20 > [JLS] I tend to read documents from the front to the back. =F0=9F=98=8A= OK, moved it to Section 2. >=20 >>=20 >>> 2. I am trying to get a handle on where you think this would be = used >>> and how much compression is going to give me. >>=20 >> Use where? Where simple data models exhibit too much sharing, or = where the >> strings that go into those have too long common prefixes (which = happens a lot >> in RDF-derived environments). >> And the point is that there is no need for decompression at the = consumer. >>=20 >> How much compression? One data point: >> http://www.w3.org/2017/07/wot-f2f/slides/w3c-serialization.pdf =E2=80=94= slide 6. >> 1/3 off by sharing, ~ 1/5 more off by prefix compression. 47 % left. >> (Deflate gives 29 %, so is 57 % of cbor-packed.) A static dictionary = would help >> some more. >=20 > Yes, but are you willing to settle for ~30% rather than ~33% when = looking at sharing. These are approximate numbers, so I=E2=80=99m not sure what you are = aiming at here. >=20 >>=20 >>> Part of this is going to be a >>> question of how much compression is obtained and the difference >>> between optimal and reasonable. >>=20 >> I you need optimal compression, go for LZ77 over the whole thing. >> Cbor-packed is reasonable :-) >>=20 >>> For example, Tags 224-255 would end up with 2 bytes for the tag, = plus >>> the encoding of the suffixed data. Moving to #6.6([#, suffix]) ends >>> up with 4 bytes plus the encoding of the suffix. >>> This means that you would want to save a minimum of 8 bytes in the >>> prefix rather than 4 bytes. You are also going to have two bytes >>> consumed in the suffix table for strings. >>=20 >> Right. That=E2=80=99s why the draft is a bit aggressive about = obtaining 1-byte and 2- >> byte references. >=20 > [JLS] And I think that good-enough could be less aggressive about = this. The main reason to be a bit aggressive is that we should be avoiding = artificial limitations. On the other end of the spectrum, going for a = 1+0 tag and a good number of 1+0 simple values is really worth it. >=20 >>=20 >>> 4. I am having a hard time figuring out how you are going to get a >>> reference loop because I was assuming that any shared items that = would >>> need to be unpacked would have it's own dictionary defined. >>=20 >> No, only the top level has shared/prefix items. >> Shared/prefix item 5 could reference Shared/prefix item 5 (insert = larger loop >> as needed). >>=20 >> E.g., shared item 0 could be =E2=80=9Csold out=E2=80=9D, and shared = item 1 could be {=E2=80=9Cprice=E2=80=9D: >> 9.99, =E2=80=9Cstock=E2=80=9D: simple(0)}. >>=20 >>> This seems to imply that >>> shared items are using the same dictionary. This needs an example. >>=20 >> Right. Half an example above. >=20 > [JLS] Yes this is what I expected after coming across the recursion = problem. But this is now also becoming more complicated than just = looking for common strings when building the compression tables. You get some good compression from just doing sharing of strings. It = gets better by sharing some structures and some prefixes. (I haven=E2=80=99t made a proposal how to share a =E2=80=9Cprefix=E2=80=9D= (subset) of a map. That should help some more.) >=20 >>=20 >>> 5. Is there a reason not to switch to using '^' for exponentiation? >>> This is the more mathematical one symbol. >>=20 >> Yes. ^ is XOR in C. >> In math, we do that differently. >> Like 2=E2=81=B6=E2=81=B4 :-) But the RFC editor won=E2=80=99t let me = do that, I=E2=80=99m sure... Went for and the inevitable text fallback. >>> 6. As we compose documents nested documents will become more >>> frequent. The question is should the multiple levels be merged into = a >>> single compression table. >>=20 >> Well, you could try it, and if it gets longer (because the references = to a larger >> dictionary get larger), you don=E2=80=99t. >>=20 >>> 7. I am not happy about the complete abandonment of providing >>> guidance for a packing algorithm. At a minimum things like doing >>> advance computing on compression, using pre-defined vocabularies (if >>> not dictionaries) is most likely usable. >>=20 >> Just putting the JSON object labels into a dictionary, sorting by = number of use, >> and removing those that are not referenced often enough or where the >> references get larger than the actual strings, is often 80 % of the = gain. >> My little toy packer (250 LOC) simply tries to share *all* duplicate = sub-items. >> The fun comes in if a duplicate sub-item has a sub-item shared with = another >> sub-item, which may make referencing the duplicate sub-item less = optimal >> than just copying the sub-item. I=E2=80=99m not sure my algorithm is = very sane, but I >> like the output, and for the details that=E2=80=99s what we have BYGS = (*) for. >=20 > [JLS] Well - you might have BYGS but I don't have such a thing. I = suppose that some of it is also going to drop down to local knowledge of = the space. "We know these things tend to occur a lot - use them." OK, give me some time to polish my compressor so I don=E2=80=99t = terminally turn myself into a clown in the data compression community = :-) But the basic idea is to look for sharing and prefix opportunities, and = then strike those that don=E2=80=99t actually improve the representation = size. Sort by frequency of use, build the tables, and then build the = rump from the tables. =20 < 250 LOC if done at the level of aptitude I have for compression = algorithms :-). >>> 8. Should we provide an option to use an application defined >>> dictionary as that would pack even more at the penalty that the >>> document could not be unpacked without that dictionary. >>=20 >> Yes. The question is how that is obtained (from context?), and how = the >> dictionary items are merged with those shared items listed in the = item (the >> dictionary may or may not have the most frequently used shared items = in the >> specific data item to be packed). I wouldn=E2=80=99t want to = COSE-sign a packed CBOR >> data item where it is hackable from where the dictionary came... >=20 > That raises an interesting question. Should one only sign the = unpacked rather than packed version? At this point in time we do not = have a lossy compression so that is probably not a required thing. I = had briefly be thinking about detached signatures where one might merge = compressions. Whatever is being signed needs to include the referenced dictionaries. I think the building of these signing inputs needs to be part of the = cbor-packed specification if we add referenced dictionaries to it. Added a short note to the security considerations. The small updates discussed are now in Html: https://www.ietf.org/id/draft-bormann-cbor-packed-01.html Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-cbor-packed-01 Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 26 23:08: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 496553A0A12 for ; Sun, 26 Jul 2020 23:08:28 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_NONE=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=mxes.net 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 LTuvVwRenxEv for ; Sun, 26 Jul 2020 23:08:25 -0700 (PDT) Received: from smtp-out-3.mxes.net (smtp-out-3.mxes.net [IPv6:2605:d100:2f:10::314]) (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 3E9F53A16F3 for ; Sun, 26 Jul 2020 23:08:25 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4446D75998 for ; Mon, 27 Jul 2020 02:08:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mxes.net; s=mta; t=1595830103; bh=gZa6ZW3bQDrVuvukIYjUTFLYMakPgOl8pzlYCmxjsJQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=weHp7J08dHQDSR70+otGhn+gtfQfyprkhcCeWQchu2Ke66faOVcddVEKs/WcYpSv+ o0DcEEZbItbxemFfBrPy/79jAY5yzO1UmpGEMQGM5H5+1ZLNXQLOoDafcqlwRUvwRI cTWD2biXaxEFIwNcurhBYnk2/fj9GvIYnrWxpY68= To: cbor@ietf.org References: From: Sean Leonard Message-ID: <1dca532e-9bcc-0649-282a-29b95def0e8a@seantek.com> Date: Sun, 26 Jul 2020 23:07:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sent-To: Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WG_adoption_call_on_draft-bormann-?= =?utf-8?q?cbor-tags-oid-07?= 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, 27 Jul 2020 06:08:28 -0000 Hello CBOR wg: Between COVID-19 and other personal/professional responsibilities, I had to take a few months off the mailing lists. That being said, I saw this pass by, and yes, I support adoption of this draft. :-) Best regards, Sean On 7/15/2020 10:19 AM, Francesca Palombini wrote: > CBOR wg, > > This starts a WG adoption call on https://tools.ietf.org/html/ draft-bormann-cbor-tags-oid-07, ending on *Sunday, July 26*. Please reply to this thread by stating whether you support the adoption, and indicate your willingness to review the draft if it becomes a working group document. > > We will announce the result of the adoption call at our IETF 108 meeting, Monday, July 27. > > CBOR Chairs > Jim & Francesca > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Mon Jul 27 07:13: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 751183A1A07 for ; Mon, 27 Jul 2020 07:13: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_NONE=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=mxes.net 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 1hY1S1M7-80T for ; Mon, 27 Jul 2020 07:13:24 -0700 (PDT) Received: from smtp-out-3.mxes.net (smtp-out-3.mxes.net [198.205.123.68]) (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 422173A1AEF for ; Mon, 27 Jul 2020 07:13:09 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E38C87599E for ; Mon, 27 Jul 2020 10:13:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mxes.net; s=mta; t=1595859187; bh=lgxKBe01dXCJZaA1FqbkilvWDGyxdRWhI+UGwpaUiO8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=iTKbMcUV1rSe/9viBGGSGsmUNd+gcQIgOiP0bsFJcBrDOfQ1klAdxb2KvrKu66JL/ 8il1EqPyUIlHEKWc8V8Mw5jwTeI7U4if+zIbfeFQZT/R11iHHPFS52rK8owTE6ihMT urJq0IHIsPMmMzUK+pROSpO5yDia37mZxGbiZC7o= To: cbor@ietf.org References: <000801d65169$5915dfb0$0b419f10$@augustcellars.com> <5E9374BB-8893-4CB5-9548-672BC9556E55@tzi.org> From: Sean Leonard Message-ID: <1b9f6063-60a8-84f3-78cf-a189385341cd@seantek.com> Date: Mon, 27 Jul 2020 07:11:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5E9374BB-8893-4CB5-9548-672BC9556E55@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Sent-To: Archived-At: Subject: Re: [Cbor] Review draft-bormann-cbor-tags-oid-07 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, 27 Jul 2020 14:13:27 -0000 On 7/3/2020 3:47 PM, Carsten Bormann wrote: > Hi Jim, > > thank you for this flash override review :-) > >> On 2020-07-03, at 20:39, Jim Schaad wrote: >> >> * Section 2 - What is a "primary integer"? Is this one that has not y= et >> gone to high school? > I have no idea. ASN.1 term? Ah right, X.660. Since arcs can be ident= ified both by its actual integer value and (not necessarily unambiguous) = secondary identifiers, the integer value is called =E2=80=9Cprimary=E2=80= =9D integer value. Fixed this by adding explanation and getting rid of t= he =E2=80=9Cprimary=E2=80=9D elsewhere. On this point specifically: X.660 (2011) defines: 3.5.13 primary integer value: A primary value of type integer used to=20 unambiguously identify an arc of the international object identifier tree. NOTE =E2=80=93 An arc of the international object identifier tree has pre= cisely=20 one primary integer value, apart from long arcs, which have only Unicode labels. When I wrote the draft, I used that term specifically since it was=20 defined in X.660. I think we should continue to use "primary integer=20 value" as defined in X.660 but as Carsten said, I am okay with the term=20 only being used once and thereafter referring to it as a simpler term. To my knowledge, OIDs represented in X.660 string formats such as IRIs=20 simply have not taken off for purposes of interchange, and when used in=20 technical documentation, the {iso(1) identified-organization(3) ... }=20 style (which is X.680, or X.660) or dotted-decimal OID style seem to=20 predominate. The most authoritative dotted-decimal OID style definition that I could=20 find is in the LDAP specs, namely in RFC 4512. X.680 (2015)=20 defines dotted-decimal style as well, see XMLObjectIdentifierValue=20 (Section 32.3; see https://www.itu.int/rec/T-REC-X.680-201508-I/en), but=20 the X.680 definition is unwieldy and allows for the names to appear in=20 the identifiers as well. -Sean From nobody Mon Jul 27 07:49:48 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7123A1A38 for ; Mon, 27 Jul 2020 07:49:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NONE=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=mxes.net 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 MKuorU9TwfDR for ; Mon, 27 Jul 2020 07:49:42 -0700 (PDT) Received: from smtp-out-3.mxes.net (smtp-out-3.mxes.net [198.205.123.68]) (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 C724F3A1BD3 for ; Mon, 27 Jul 2020 07:45:03 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D365275968 for ; Mon, 27 Jul 2020 10:44:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mxes.net; s=mta; t=1595861102; bh=QsPqH3nV1E7DGHs8vnEi9aKNeIML7+uuDRDB3vq7MD4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=rONAqOMS/d1ztZSXYYMEgfG7BhvS1A8pLjau2hCpA1FD+mC7Zqoxhb5MCm5Vo+hmm 9J5VPGiXjeKQhnOSHUC+IaVGik/FRsVggvMl0cOIBxixVkUmFOlD/tloZ2BW6XsqTV uZMkU5lENomfiWEfp6ZsOVLP7M2+x9vzULx2JW0U= To: cbor@ietf.org References: <000801d65169$5915dfb0$0b419f10$@augustcellars.com> <5E9374BB-8893-4CB5-9548-672BC9556E55@tzi.org> <001701d651a5$ef08e6c0$cd1ab440$@augustcellars.com> From: Sean Leonard Message-ID: Date: Mon, 27 Jul 2020 07:43:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sent-To: Archived-At: Subject: [Cbor] Donation of short arcs 1.3.179.x Re: Prefix compression (Re: Review draft-bormann-cbor-tags-oid-07) 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, 27 Jul 2020 14:49:47 -0000 On 7/4/2020 4:48 AM, Carsten Bormann wrote: > Hi Jim, > > On 2020-07-04, at 03:53, Jim Schaad wrote: >> An array of two hash functions which could be parsed into the two rooted OID values > Prefix compression is applicable to other data than OIDs (most prominently URIs). > I think we should handle that in a more generic way than specifically for OIDs. I control a very short OID arc, 1.3.179 {iso(1) identified-organization(3) penango(179)} and would be happy to donate a block of 16 one-byte identifiers for CBOR/CBOR working group (or IETF) use. The binary encoding of this prefix is h'2B8133'. If I assign the block of 96-111 to CBOR (h'60' through h'6F'), then that yields four bytes, 2048 unique numbers that are just five bytes long and 16 unique numbers that are four bytes long as a bonus. I could probably donate 32 one-byte identifiers without losing sleep over it. OIDs are just a way to generate globally unique, language-agnostic identifiers. A unique identifier that is five bytes long is clearly superior to a web URI (which depends on perpetual domain name registration) or even a UUID (fixed 16 bytes long), and obviates any need for compression. I think the reason why OIDs get such a bad wrap is because they are unnecessarily long when politics are laid over them, like 1.3.6.1.4.1.9.9.179.1.3.3.1.13. If you want a short and globally unique one, you can't get better than OIDs. Notably, I am not the only one to figure out how to get a short OID: looks like Amazon picked up #187 in 2015: . If you can convince anybody who has registered OIDs 1-127 to slice off a piece of their namespace, you can make them one byte shorter. And I just discovered that IANA itself has a registration under 1.3.90: which is h'2B5A'--just two bytes! I'm surprised that nobody has made use of it. While there are a lot of approaches to prefix compression, this assures that you can use OIDs instead of other identifiers in CBOR for *globally unique* identifiers. It has another modern advantage in that www.oid-info.com is a publicly accessible wiki-style list of all the OIDs ever minted, so you can write a tool to retrieve the human-readable meaning of any OID with a simple HTTP GET request. Sean From nobody Tue Jul 28 08:25:04 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 865F03A0D84 for ; Tue, 28 Jul 2020 08:25:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=Z8ikhWCq; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=Z8ikhWCq 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 9llcQ8I5M9FC for ; Tue, 28 Jul 2020 08:24:59 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70054.outbound.protection.outlook.com [40.107.7.54]) (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 1BCCC3A0D4E for ; Tue, 28 Jul 2020 08:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gniwxON+Fjz5oB7A03HYYlgzOJtOh/X2FRGCk2uU8O8=; b=Z8ikhWCqLMD8l8nqzlfEcYTarCLa7YLwmMsnqlmBVUPJdnO1frH26P9Gr54yRxi4PCBODdKVhiGQvvIGyMrs7PJuiarsYdGwV/5EHDFxbEoF5eQojctt3kWKJQyw7GOl7uq8e6AYRzwp/PfzhLVKkP/tb/lCSzc6bwrFkMKWLps= Received: from DB6PR07CA0016.eurprd07.prod.outlook.com (2603:10a6:6:2d::26) by AM6PR08MB4535.eurprd08.prod.outlook.com (2603:10a6:20b:74::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Tue, 28 Jul 2020 15:24:55 +0000 Received: from DB5EUR03FT044.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:2d:cafe::8e) by DB6PR07CA0016.outlook.office365.com (2603:10a6:6:2d::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9 via Frontend Transport; Tue, 28 Jul 2020 15:24:55 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT044.mail.protection.outlook.com (10.152.21.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.10 via Frontend Transport; Tue, 28 Jul 2020 15:24:55 +0000 Received: ("Tessian outbound c4059ed8d7bf:v62"); Tue, 28 Jul 2020 15:24:55 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 98c74295591d1c4e X-CR-MTA-TID: 64aa7808 Received: from 21df720a3adc.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 3D98A1AE-942C-4587-BAFD-05737087FC89.1; Tue, 28 Jul 2020 15:24:49 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 21df720a3adc.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 28 Jul 2020 15:24:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZN4bdfnR/OIPETnhGwQqhJrvQmMunPISrBXTqzA4Wf7ZoaFcDI51O13ewtobGuqFizNKoyuvsOmo+AzO5LWiYr9WOd7nsLVQ9EcqGNqoCd9R1naH74g6sK2+3b/xCjtm+62gSnOIT41jzicRr9qlqUq4IzvHHPFDW2u3+DWhkBTYBmuNvtv5NMQDelnCzWLUbYbkgL2t50H+MNMUA307WPuS5md1HglwkviJG89CylTaoxFOeskXmNpUj6rClfp95sur06nDHgGWsyFE3C+VfUNhC6WY58KmBK6AAbtXihhhiI/WwH1hWVnOKeUJar8gjJ9LJJgm096fdbzo0XbKVA== 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=gniwxON+Fjz5oB7A03HYYlgzOJtOh/X2FRGCk2uU8O8=; b=TBIOZ+4JXOm0QDU+t0mUCgYDFBdF5BfDd61637BVqzSGTZp9UL+K327fWJ8hROg1CclB8mjC0QIwZmxjfDH4OPxxoPigbrh6voUcF5dSRO6qsc8xtOyrnrgju2QAPtm5XjD0QMAPLwHQbw0UhcGOAmod3BnJSVehVW6ZxawKCPzEUrvD2Z33AlhQz7HIfWKZ5BoISZyGEZn2QBEzC2YlBf8j7s5KHjfy0iCJoZMt4tdSACPQRBYZ7rO9w3im2V0e0wONIfiJhfZmtTuAGdeKKkdrMqh1jkE/Bf/tTcAk5+W8qD/d5u4HPNrEWNmVqlCMp0UPppY+z+bZzeJBJshLTA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gniwxON+Fjz5oB7A03HYYlgzOJtOh/X2FRGCk2uU8O8=; b=Z8ikhWCqLMD8l8nqzlfEcYTarCLa7YLwmMsnqlmBVUPJdnO1frH26P9Gr54yRxi4PCBODdKVhiGQvvIGyMrs7PJuiarsYdGwV/5EHDFxbEoF5eQojctt3kWKJQyw7GOl7uq8e6AYRzwp/PfzhLVKkP/tb/lCSzc6bwrFkMKWLps= Received: from AM6PR08MB4738.eurprd08.prod.outlook.com (2603:10a6:20b:cf::10) by AM6PR08MB3400.eurprd08.prod.outlook.com (2603:10a6:20b:42::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21; Tue, 28 Jul 2020 15:24:48 +0000 Received: from AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56]) by AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56%3]) with mapi id 15.20.3216.034; Tue, 28 Jul 2020 15:24:48 +0000 From: Brendan Moran To: "cbor@ietf.org" Thread-Topic: Review: draft-bormann-cbor-packed-00 & SUIT Thread-Index: AQHWZPM60qihXvrkZ0asN5pzHoB6sw== Date: Tue, 28 Jul 2020 15:24:48 +0000 Message-ID: <5E28C6E2-DFEC-4AF5-96CE-75E8F0927818@arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.20.19.206] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 15bc81b7-2803-48ae-d48f-08d8330a61e7 x-ms-traffictypediagnostic: AM6PR08MB3400:|AM6PR08MB4535: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: QDBP3FUQQsZEcUm9MhrzhqOOLT5Gxn6oHU+EhN+AyHu3Wx60HoZBO6AShysWQJ0E+qha6FXdKLZK/YsyX2q5e0P35YSB/TOebLknbVeIXc87an3pAkdzZYxBmyfE+RE+Ybv/WPBTNF82eS/NWF/EcYVZjXZMJU0xDt4l3hMk3+71vc5gf1A/V3aknwUzr8SmGu0QpGC195QIAms9ChDQWHbHW1rBrXyepxiM+uHO7KgptrB8lNl3ooqCM04qLs6BBITHeuDwTFsWuB1wF89nmtOBlDyfDu1rjRzLWLfzJuKYQM/8r/e9HyqNXV49BUPa6C9cpgqJ+0qe1ibnTEpPUw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4738.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(136003)(366004)(346002)(376002)(86362001)(6506007)(71200400001)(6916009)(478600001)(33656002)(2616005)(8676002)(8936002)(6486002)(6512007)(316002)(2906002)(5660300002)(36756003)(83380400001)(26005)(66946007)(91956017)(76116006)(66556008)(66446008)(186003)(66476007)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: XepFDIZb7LFA8xCDVQg6pPBWzzs7pcHPYxIGVSwzweky0yVzIP+C3Od8LwRFrVt9/Fp9QjnfLvlAs//TOp0jVKPagXLmTfyCva6FFRV+F/cIxwg9zCEEZ4/UR7nh3vlqP4wYXVV0dyD9TLJwqY9npIblccnErFhgKiw7SZyD08zDKwzKvKQh0BApGCKSZ6PLKd4tmw58cAIefY2ImvMacOlD1Ysw/YWTXk4S//yPwyQN6kiUdhT3QhMWCn+LuzZVP4EdCsLIvwgxgHr/+leNNYrC7tN71R/9ObwVmzmm3VVj2Sqj7n6/MNBZhbqb4cvdxFuDyswSdd/AlBe9sFz3JWluWk2D4k3T2d6nLWvAQZXOfOywb4eDQrOKTvy+mLZRZb0OFfB2dwDLcAGqvasvVQGkCUUL8/+bQ8uqWXHDIGnlHoSefccaNCWyb58gEM4kCsdTUhgw9mwhdMtP2U/S9BHVCUCOFhEOF30+/ruV/fc= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_5E28C6E2DFEC4AF596CE75E8F0927818armcom_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3400 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT044.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 58bca215-f553-499b-cadb-08d8330a5d79 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Z5BmgQ4PSX65rdsLt1jyQDtgR9rREUWR4MSUh1vOanZ8YN14zFq2xUQdpNs79B2tTfyL+s79XSASaeqBc6BAzhZVjJon85ODUBUqOlC7z4w1nmEcBK9KnY625WB9+YMdWC7VLOkHHWTQYEJZnhXruZeF7URwjjHqzda+Ig4/svMLtjNAHxDeTcK+KdQu8H8Wpjtd7o0qnF1c+aUvvb6SK+ef2fE2Fpq88HNd+nqG5HKCJGrSiW05us+7vuXkkL7yz6eBwHWJKAO8OPiGDt4tpAbg2wJPAgZSXvXul62uSnb4liYI85tgVs6cVUU8Rf7FUvLh1TiUIrQ3xe1cnMIysaOdSvjo7d3FtvKjvHY0OdudY4SLdgZfOpELhxPaoVN/noOqIs+o5a5exHiOc4iEwQ== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(39860400002)(136003)(396003)(46966005)(81166007)(356005)(45080400002)(186003)(26005)(82310400002)(83380400001)(86362001)(47076004)(36756003)(478600001)(6506007)(82740400003)(6916009)(33964004)(8676002)(70206006)(2616005)(8936002)(33656002)(336012)(5660300002)(70586007)(6486002)(6512007)(2906002)(316002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2020 15:24:55.8128 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 15bc81b7-2803-48ae-d48f-08d8330a61e7 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT044.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4535 Archived-At: Subject: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT 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, 28 Jul 2020 15:25:03 -0000 --_000_5E28C6E2DFEC4AF596CE75E8F0927818armcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IHBhY2tlZCBDQk9SIGlzIGEgZmVhdHVyZSB0aGF04oCZcyB2ZXJ5IG11Y2gg bmVlZGVkLiBJbiBmYWN0LCB0aGVyZeKAmXMgYSBzaW1pbGFyIGZlYXR1cmUgaW4gU1VJVC4gSeKA mWQgcmF0aGVyIGdldCByaWQgb2YgU1VJVOKAmXMgZGVkdXBsaWNhdGlvbiBzeXN0ZW0gYW5kIHVz ZSBwYWNrZWQgQ0JPUiBpbnN0ZWFkLCBidXQgdGhlIHRpbWluZyBtYXkgbm90IHdvcmsgb3V0Lg0K DQpJ4oCZZCBsaWtlIHRvIHJlaXRlcmF0ZSBzb21lIG9mIHRoaW5ncyB0aGF0IHdlcmUgc2FpZCBp biB0aGUgZGlzY3Vzc2lvbiBkdXJpbmcgdGhlIGNib3IgbWVldGluZywgYW5kIGFkZCBzb21lIGFk ZGl0aW9uYWwgcG9pbnRzLg0KDQpUaGUgY3VycmVudCBlbmNvZGluZyBvZiAjNi42KFtdKSBpcyBu b3QgZnJpZW5kbHkgdG8gc3RyZWFtIHByb2Nlc3NpbmcsIG5vciB0byBwdWxsIHBhcnNlcnMuIEl0 IGlzIGVhc2llciBmb3IgdGhpcyBzdHlsZSBvZiBwYXJzZXIgdG8gaGF2ZSBhIGRpY3Rpb25hcnkg Zmlyc3QsIGZvbGxvd2VkIGJ5IHRoZSBydW1wLiBXZSBjb3VsZCBhcnJhbmdlIHRvIHJlc29sdmUg dGhpcyBieSByZXBsYWNpbmcgdGhlIHJ1bXAgaW4gaXRzIGVudGlyZXR5IHdpdGggYSBzaGFyZWQg b2JqZWN0IHJlZmVyZW5jZSwgYW5kIGVuY29kaW5nIHRoZSBhY3R1YWwgcnVtcCBhcyBhIHNoYXJl ZCBvYmplY3QuIFRoaXMgYWxsb3dzIGEgcHVsbCBwYXJzZXIgdG8gZGlyZWN0bHkganVtcCB0byB0 aGUgZGljdGlvbmFyeS4gSWYgdGhlIOKAnHJ1bXDigJ0gaXMgcGxhY2VkIGFzIHRoZSBsYXN0IHNo YXJlZCBvYmplY3QsIGEgc3RyZWFtIHByb2Nlc3NvciBjYW4gdXNlIHRoaXMgYWJzdHJhY3Rpb24g dG8gZW5zdXJlIHRoYXQgdGhlIHJ1bXAgaXMgZW5jb3VudGVyZWQgb25seSBvbmNlIHRoZSBkaWN0 aW9uYXJ5IGlzIHJlY2VpdmVkLiBTbywgdGhpcyDigJxjb25jZXJu4oCdIG1heSBiZSBhIG5vLW9w IGFuZCBtYXkganVzdCByZXF1aXJlIGFuIGltcGxlbWVudGF0aW9uIGhpbnQgZm9yIGFkZHJlc3Np bmcgcHVsbCBwYXJzZXJzLg0KDQoNClNVSVQgaGFzIHNvbWUgcGVjdWxpYXIgcmVxdWlyZW1lbnRz IHRoYXQgbWlnaHQgYmUgcmVsZXZhbnQgdG8gdGhlIGRlc2lnbiBvZiBwYWNrZWQgQ0JPUjoNCg0K MS4gU1VJVCBtYW5pZmVzdHMgd291bGQgYWJzb2x1dGVseSBiZW5lZml0IGZyb20gYSBtZWNoYW5p c20gdG8gY29tcHJlc3MgQ0JPUiBzZXF1ZW5jZXMuIFNVSVTigJlzIGJhc2ljIGJ1aWxkaW5nIGJs b2NrIGlzIGFycmF5cyB0aGF0IGFyZSBlZmZlY3RpdmVseSBtdWx0aS1tYXBzLiBTb21lIG9mIHRo ZXNlIG11bHRpLW1hcHMgY29udGFpbiBzaW1pbGFyIHNlcXVlbmNlcyBvZiBvYmplY3RzLiBJdCB3 b3VsZCBiZSBiZW5lZmljaWFsIHRvIGJlIGFibGUgdG8gZGVkdXBsaWNhdGUgdGhlIGlkZW50aWNh bCBwYXJ0cy4NCg0KMi4gU1VJVCB3b3VsZCBiZW5lZml0IGZyb20gbmVzdGVkIHBhY2tlZCBDQk9S IGl0ZW1zLiBTVUlUIGZlYXR1cmVzIGVsZW1lbnRzIHRoYXQgY2FuIGJlIGRldGFjaGVkIGZyb20g ZWFjaCBvdGhlciBpbiBtdWNoIHRoZSBzYW1lIHdheSBhcyBDT1NFIHN1cHBvcnRzIGRldGFjaGVk IHBheWxvYWRzLiBBIFNVSVQgZW52ZWxvcGUgY29udGFpbnMgYSBtYW5pZmVzdCBhbmQgemVybyBv ciBtb3JlIHNldmVyYWJsZSAoZGV0YWNoZWQpIGVsZW1lbnRzLiBJdCB3b3VsZCBiZSBwcmVmZXJh YmxlIGZvciBwYWNraW5nIHRvIHdvcmsgbGlrZSB0aGlzOiBhbnkgZWxlbWVudCBvciBzZXF1ZW5j ZSB0aGF0IGFwcGVhcnMgYXQgbGVhc3Qgb25jZSBpbiB0aGUgbWFuaWZlc3QgYW5kIHR3byBvciBt b3JlIHRpbWVzIGluIHRoZSB1bmlvbiBvZiBtYW5pZmVzdCBhbmQgc2V2ZXJhYmxlIGVsZW1lbnRz LCBzaG91bGQgYmUgcGxhY2VkIGluIHRoZSBkaWN0aW9uYXJ5IGZvciB0aGUgbWFuaWZlc3QuIEFu eSBlbGVtZW50IG9yIHNlcXVlbmNlIHRoYXQgYXBwZWFycyB0d28gb3IgbW9yZSB0aW1lcyBpbiBh IHNldmVyYWJsZSBlbGVtZW50LCBidXQgbm90IGluIHRoZSBtYW5pZmVzdCwgc2hvdWxkIGJlIHBs YWNlZCBpbiB0aGUgc2V2ZXJhYmxlIGVsZW1lbnTigJlzIGRpY3Rpb25hcnkuDQoNCkkgYmVsaWV2 ZSB0aGF0IGEgc3VpdC1zcGVjaWZpYyBjYm9yIHBhY2tlciBjb3VsZCBhY2hpZXZlIHRoaXMgbWVj aGFuaXNtIGlmIG5lc3RlZCBwYWNrZWQgQ0JPUiBkYXRhIGl0ZW1zIHdlcmUgc3VwcG9ydGVkLiBT VUlUIGRvZXMgbm90IGFwcGVhciB0byByZXF1aXJlIG1vcmUgdGhhbiBhDQoNCjMuIEkgc3VzcGVj dCB0aGF0IFNVSVQgd291bGQgYWxzbyBiZW5lZml0IGZyb20gZG9tYWluLXNwZWNpZmljIHByZS1z aGFyZWQgZGljdGlvbmFyaWVzLiBJ4oCZZCBsaWtlIHRvIHNlZSBzb21lIHdheSBvZiBkZWZpbmlu ZyBjYW5vbmljYWwgZGljdGlvbmFyeSBtZXJnaW5nOiBBcmUgZGljdGlvbmFyaWVzIGNvbmNhdGVu YXRlZD8gSW4gd2hpY2ggb3JkZXIgYXJlIHRoZXkgY29uY2F0ZW5hdGVkPyBIb3cgc2hvdWxkIGEg ZG9tYWluLXNwZWNpZmljIHByZS1zaGFyZWQgZGljdGlvbmFyeSBiZSBpbmNsdWRlZCBpbiBhIHNp Z25lZCBjb250ZXh0PyBCeSBkaWdlc3Q/DQoNCg0KQmVzdCBSZWdhcmRzLA0KQnJlbmRhbg0KSU1Q T1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVy IHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5m b3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_5E28C6E2DFEC4AF596CE75E8F0927818armcom_ Content-Type: text/html; charset="utf-8" Content-ID: <0261CC19F898204B97772D47B8886764@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSSB0aGluayB0aGF0IHBhY2tlZCBD Qk9SIGlzIGEgZmVhdHVyZSB0aGF04oCZcyB2ZXJ5IG11Y2ggbmVlZGVkLiBJbiBmYWN0LCB0aGVy ZeKAmXMgYSBzaW1pbGFyIGZlYXR1cmUgaW4gU1VJVC4gSeKAmWQgcmF0aGVyIGdldCByaWQgb2Yg U1VJVOKAmXMgZGVkdXBsaWNhdGlvbiBzeXN0ZW0gYW5kIHVzZSBwYWNrZWQgQ0JPUiBpbnN0ZWFk LCBidXQgdGhlIHRpbWluZyBtYXkgbm90IHdvcmsgb3V0Lg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SeKAmWQgbGlrZSB0byByZWl0ZXJhdGUgc29t ZSBvZiB0aGluZ3MgdGhhdCB3ZXJlIHNhaWQgaW4gdGhlIGRpc2N1c3Npb24gZHVyaW5nIHRoZSBj Ym9yIG1lZXRpbmcsIGFuZCBhZGQgc29tZSBhZGRpdGlvbmFsIHBvaW50cy48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBjdXJyZW50 IGVuY29kaW5nIG9mICM2LjYoW10pIGlzIG5vdCBmcmllbmRseSB0byBzdHJlYW0gcHJvY2Vzc2lu Zywgbm9yIHRvIHB1bGwgcGFyc2Vycy4gSXQgaXMgZWFzaWVyIGZvciB0aGlzIHN0eWxlIG9mIHBh cnNlciB0byBoYXZlIGEgZGljdGlvbmFyeSBmaXJzdCwgZm9sbG93ZWQgYnkgdGhlIHJ1bXAuIFdl IGNvdWxkIGFycmFuZ2UgdG8gcmVzb2x2ZSB0aGlzIGJ5IHJlcGxhY2luZyB0aGUgcnVtcCBpbiBp dHMgZW50aXJldHkNCiB3aXRoIGEgc2hhcmVkIG9iamVjdCByZWZlcmVuY2UsIGFuZCBlbmNvZGlu ZyB0aGUgYWN0dWFsIHJ1bXAgYXMgYSBzaGFyZWQgb2JqZWN0LiBUaGlzIGFsbG93cyBhIHB1bGwg cGFyc2VyIHRvIGRpcmVjdGx5IGp1bXAgdG8gdGhlIGRpY3Rpb25hcnkuIElmIHRoZSDigJxydW1w 4oCdIGlzIHBsYWNlZCBhcyB0aGUgbGFzdCBzaGFyZWQgb2JqZWN0LDxzcGFuIHN0eWxlPSJjYXJl dC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyIgY2xhc3M9IiI+Jm5i c3A7YQ0KIHN0cmVhbSBwcm9jZXNzb3IgY2FuIHVzZSB0aGlzIGFic3RyYWN0aW9uIHRvIGVuc3Vy ZSB0aGF0IHRoZSBydW1wIGlzIGVuY291bnRlcmVkIG9ubHkgb25jZSB0aGUgZGljdGlvbmFyeSBp cyByZWNlaXZlZDwvc3Bhbj4uIFNvLCB0aGlzIOKAnGNvbmNlcm7igJ0gbWF5IGJlIGEgbm8tb3Ag YW5kIG1heSBqdXN0IHJlcXVpcmUgYW4gaW1wbGVtZW50YXRpb24gaGludCBmb3IgYWRkcmVzc2lu ZyBwdWxsIHBhcnNlcnMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U1VJ VCBoYXMgc29tZSBwZWN1bGlhciByZXF1aXJlbWVudHMgdGhhdCBtaWdodCBiZSByZWxldmFudCB0 byB0aGUgZGVzaWduIG9mIHBhY2tlZCBDQk9SOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MS4gU1VJVCBtYW5pZmVzdHMgd291bGQgYWJz b2x1dGVseSBiZW5lZml0IGZyb20gYSBtZWNoYW5pc20gdG8gY29tcHJlc3MgQ0JPUiBzZXF1ZW5j ZXMuIFNVSVTigJlzIGJhc2ljIGJ1aWxkaW5nIGJsb2NrIGlzIGFycmF5cyB0aGF0IGFyZSBlZmZl Y3RpdmVseSBtdWx0aS1tYXBzLiBTb21lIG9mIHRoZXNlIG11bHRpLW1hcHMgY29udGFpbiBzaW1p bGFyIHNlcXVlbmNlcyBvZiBvYmplY3RzLiBJdCB3b3VsZCBiZSBiZW5lZmljaWFsDQogdG8gYmUg YWJsZSB0byBkZWR1cGxpY2F0ZSB0aGUgaWRlbnRpY2FsIHBhcnRzLiZuYnNwOzwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Mi4gU1VJVCB3 b3VsZCBiZW5lZml0IGZyb20gbmVzdGVkIHBhY2tlZCBDQk9SIGl0ZW1zLiZuYnNwOzxmb250IGNv bG9yPSIjMDAwMDAwIiBjbGFzcz0iIj5TVUlUIGZlYXR1cmVzIGVsZW1lbnRzIHRoYXQgY2FuIGJl IGRldGFjaGVkIGZyb20gZWFjaCBvdGhlciBpbiBtdWNoIHRoZSBzYW1lIHdheSBhcyBDT1NFIHN1 cHBvcnRzIGRldGFjaGVkIHBheWxvYWRzLiBBIFNVSVQgZW52ZWxvcGUgY29udGFpbnMgYSBtYW5p ZmVzdCBhbmQgemVybw0KIG9yIG1vcmUgc2V2ZXJhYmxlIChkZXRhY2hlZCkgZWxlbWVudHMuIEl0 IHdvdWxkIGJlIHByZWZlcmFibGUgZm9yIHBhY2tpbmcgdG8gd29yayBsaWtlIHRoaXM6IGFueSBl bGVtZW50IG9yIHNlcXVlbmNlIHRoYXQgYXBwZWFycyBhdCBsZWFzdCBvbmNlIGluIHRoZSBtYW5p ZmVzdCBhbmQgdHdvIG9yIG1vcmUgdGltZXMgaW4gdGhlIHVuaW9uIG9mIG1hbmlmZXN0IGFuZCBz ZXZlcmFibGUmbmJzcDtlbGVtZW50cywgc2hvdWxkIGJlIHBsYWNlZCBpbiB0aGUgZGljdGlvbmFy eQ0KIGZvciB0aGUgbWFuaWZlc3QuIEFueSBlbGVtZW50IG9yIHNlcXVlbmNlIHRoYXQgYXBwZWFy cyB0d28gb3IgbW9yZSB0aW1lcyBpbiBhIHNldmVyYWJsZSBlbGVtZW50LCBidXQgbm90IGluIHRo ZSBtYW5pZmVzdCwgc2hvdWxkIGJlIHBsYWNlZCBpbiB0aGUgc2V2ZXJhYmxlIGVsZW1lbnTigJlz IGRpY3Rpb25hcnkuPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY29sb3I9IiMwMDAwMDAiIGNsYXNzPSIiPkkgYmVs aWV2ZSZuYnNwO3RoYXQgYSBzdWl0LXNwZWNpZmljIGNib3IgcGFja2VyIGNvdWxkJm5ic3A7YWNo aWV2ZSB0aGlzIG1lY2hhbmlzbSBpZiBuZXN0ZWQgcGFja2VkIENCT1IgZGF0YSBpdGVtcyB3ZXJl IHN1cHBvcnRlZC4gU1VJVCBkb2VzIG5vdCBhcHBlYXIgdG8gcmVxdWlyZSBtb3JlIHRoYW4gYSZu YnNwOzwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjMuIEkgc3VzcGVjdCB0aGF0IFNVSVQg d291bGQgYWxzbyBiZW5lZml0IGZyb20gZG9tYWluLXNwZWNpZmljIHByZS1zaGFyZWQgZGljdGlv bmFyaWVzLiBJ4oCZZCBsaWtlIHRvIHNlZSBzb21lIHdheSBvZiBkZWZpbmluZyBjYW5vbmljYWwg ZGljdGlvbmFyeSBtZXJnaW5nOiBBcmUgZGljdGlvbmFyaWVzIGNvbmNhdGVuYXRlZD8gSW4gd2hp Y2ggb3JkZXIgYXJlIHRoZXkgY29uY2F0ZW5hdGVkPyBIb3cgc2hvdWxkIGEgZG9tYWluLXNwZWNp ZmljDQogcHJlLXNoYXJlZCBkaWN0aW9uYXJ5IGJlIGluY2x1ZGVkIGluIGEgc2lnbmVkIGNvbnRl eHQ/IEJ5IGRpZ2VzdD88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CZXN0 IFJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJyZW5kYW48L2Rpdj4NCklNUE9SVEFOVCBO T1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJl IGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24s IHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRp b24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5E28C6E2DFEC4AF596CE75E8F0927818armcom_-- From nobody Tue Jul 28 10:19:08 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 A45BF3A0D79 for ; Tue, 28 Jul 2020 10:19:05 -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 OXvEOw-mh2Gf for ; Tue, 28 Jul 2020 10:19:03 -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 03B3C3A0D61 for ; Tue, 28 Jul 2020 10:19:02 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 28 Jul 2020 10:18:53 -0700 From: Jim Schaad To: 'Brendan Moran' , References: <5E28C6E2-DFEC-4AF5-96CE-75E8F0927818@arm.com> In-Reply-To: <5E28C6E2-DFEC-4AF5-96CE-75E8F0927818@arm.com> Date: Tue, 28 Jul 2020 10:18:51 -0700 Message-ID: <01d901d66503$2bbd93c0$8338bb40$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DA_01D664C8.7F5F7F10" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQKsAEWUoN/uCeZIyHWSgfhWse+x66dyBRBw X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT 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, 28 Jul 2020 17:19:06 -0000 ------=_NextPart_000_01DA_01D664C8.7F5F7F10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: CBOR On Behalf Of Brendan Moran Sent: Tuesday, July 28, 2020 8:25 AM To: cbor@ietf.org Subject: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT =20 I think that packed CBOR is a feature that=E2=80=99s very much needed. = In fact, there=E2=80=99s a similar feature in SUIT. I=E2=80=99d rather = get rid of SUIT=E2=80=99s deduplication system and use packed CBOR = instead, but the timing may not work out.=20 =20 I=E2=80=99d like to reiterate some of things that were said in the = discussion during the cbor meeting, and add some additional points. =20 The current encoding of #6.6([]) is not friendly to stream processing, = nor to pull parsers. It is easier for this style of parser to have a = dictionary first, followed by the rump. We could arrange to resolve this = by replacing the rump in its entirety with a shared object reference, = and encoding the actual rump as a shared object. This allows a pull = parser to directly jump to the dictionary. If the =E2=80=9Crump=E2=80=9D = is placed as the last shared object, a stream processor can use this = abstraction to ensure that the rump is encountered only once the = dictionary is received. So, this =E2=80=9Cconcern=E2=80=9D may be a = no-op and may just require an implementation hint for addressing pull = parsers. =20 =20 SUIT has some peculiar requirements that might be relevant to the design = of packed CBOR: =20 1. SUIT manifests would absolutely benefit from a mechanism to compress = CBOR sequences. SUIT=E2=80=99s basic building block is arrays that are = effectively multi-maps. Some of these multi-maps contain similar = sequences of objects. It would be beneficial to be able to deduplicate = the identical parts.=20 =20 2. SUIT would benefit from nested packed CBOR items. SUIT features = elements that can be detached from each other in much the same way as = COSE supports detached payloads. A SUIT envelope contains a manifest and = zero or more severable (detached) elements. It would be preferable for = packing to work like this: any element or sequence that appears at least = once in the manifest and two or more times in the union of manifest and = severable elements, should be placed in the dictionary for the manifest. = Any element or sequence that appears two or more times in a severable = element, but not in the manifest, should be placed in the severable = element=E2=80=99s dictionary. =20 I believe that a suit-specific cbor packer could achieve this mechanism = if nested packed CBOR data items were supported. SUIT does not appear to = require more than a=20 3. I suspect that SUIT would also benefit from domain-specific = pre-shared dictionaries. I=E2=80=99d like to see some way of defining = canonical dictionary merging: Are dictionaries concatenated? In which = order are they concatenated? How should a domain-specific pre-shared = dictionary be included in a signed context? By digest? =20 [Brendan] One of the questions that I have is the order of compressing = and applying security operations. If you are using a pull parser do you = think it is going to be easier (we can talk about more secure later) to = do the hashing on the compressed or uncompressed version. This could be = an even harder question to ask with the use of an external dictionary. = There is one potential benefit w/ COSE in that the hash of the = dictionary could be included as external data. =20 Jim =20 =20 =20 Best Regards, Brendan IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you.=20 ------=_NextPart_000_01DA_01D664C8.7F5F7F10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: CBOR = <cbor-bounces@ietf.org> On Behalf Of Brendan = Moran
Sent: Tuesday, July 28, 2020 8:25 AM
To: = cbor@ietf.org
Subject: [Cbor] Review: = draft-bormann-cbor-packed-00 & SUIT

 

I think that = packed CBOR is a feature that=E2=80=99s very much needed. In fact, = there=E2=80=99s a similar feature in SUIT. I=E2=80=99d rather get rid of = SUIT=E2=80=99s deduplication system and use packed CBOR instead, but the = timing may not work out.

 

I=E2=80=99d like to reiterate some of things that were = said in the discussion during the cbor meeting, and add some additional = points.

 

The current encoding of #6.6([]) is not friendly to = stream processing, nor to pull parsers. It is easier for this style of = parser to have a dictionary first, followed by the rump. We could = arrange to resolve this by replacing the rump in its entirety with a = shared object reference, and encoding the actual rump as a shared = object. This allows a pull parser to directly jump to the dictionary. If = the =E2=80=9Crump=E2=80=9D is placed as the last shared object, a stream processor can use this abstraction = to ensure that the rump is encountered only once the dictionary is = received. So, this =E2=80=9Cconcern=E2=80=9D may be a no-op and = may just require an implementation hint for addressing pull = parsers.

 

 

SUIT has some peculiar requirements that might be = relevant to the design of packed CBOR:

 

1. SUIT manifests would absolutely benefit from a = mechanism to compress CBOR sequences. SUIT=E2=80=99s basic building = block is arrays that are effectively multi-maps. Some of these = multi-maps contain similar sequences of objects. It would be beneficial = to be able to deduplicate the identical = parts. 

 

2. SUIT would benefit from nested packed CBOR = items. SUIT features elements that can = be detached from each other in much the same way as COSE supports = detached payloads. A SUIT envelope contains a manifest and zero or more = severable (detached) elements. It would be preferable for packing to = work like this: any element or sequence that appears at least once in = the manifest and two or more times in the union of manifest and = severable elements, should be placed in the dictionary for the = manifest. Any element or sequence that appears two or more times in a = severable element, but not in the manifest, should be placed in the = severable element=E2=80=99s = dictionary.

 

I believe that a = suit-specific cbor packer could achieve this mechanism if nested = packed CBOR data items were supported. SUIT does not appear to require = more than a 



3. I suspect that SUIT would also benefit from = domain-specific pre-shared dictionaries. I=E2=80=99d like to see some = way of defining canonical dictionary merging: Are dictionaries = concatenated? In which order are they concatenated? How should a = domain-specific pre-shared dictionary be included in a signed context? = By digest?

 

[Brendan] One of the questions that I have is the = order of compressing and applying security operations.=C2=A0 If you are = using a pull parser do you think it is going to be easier (we can talk = about more secure later) to do the hashing on the compressed or = uncompressed version.=C2=A0 This could be an even harder question to ask = with the use of an external dictionary.=C2=A0 There is one potential = benefit w/ COSE in that the hash of the dictionary could be included as = external data.

 

Jim

 

 

 

Best Regards,

Brendan

IMPORTANT NOTICE: The contents of this email and any = attachments are confidential and may also be privileged. If you are not = the intended recipient, please notify the sender immediately and do not = disclose the contents to any other person, use it for any purpose, or = store or copy the information in any medium. Thank you. =

------=_NextPart_000_01DA_01D664C8.7F5F7F10-- From nobody Tue Jul 28 14:14:04 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 2903D3A07FC for ; Tue, 28 Jul 2020 14:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 A2nJXbF57bTB for ; Tue, 28 Jul 2020 14:13:59 -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 59D0F3A07EE for ; Tue, 28 Jul 2020 14:13:59 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4BGTts6SsXzyWb; Tue, 28 Jul 2020 23:13:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <01d901d66503$2bbd93c0$8338bb40$@augustcellars.com> Date: Tue, 28 Jul 2020 23:13:57 +0200 Cc: Brendan Moran , cbor@ietf.org X-Mao-Original-Outgoing-Id: 617663637.328707-b3fa56c40a1872201397e42e19a92290 Content-Transfer-Encoding: quoted-printable Message-Id: <7216D806-3473-463E-B6F2-AD8724AC56C6@tzi.org> References: <5E28C6E2-DFEC-4AF5-96CE-75E8F0927818@arm.com> <01d901d66503$2bbd93c0$8338bb40$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT 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, 28 Jul 2020 21:14:02 -0000 > On 2020-07-28, at 19:18, Jim Schaad wrote: >=20 > [Brendan] One of the questions that I have is the order of compressing = and applying security operations. If you are using a pull parser do you = think it is going to be easier (we can talk about more secure later) to = do the hashing on the compressed or uncompressed version. =20 Whoa. We normally hash byte strings. So are you proposing that, say, a compressed version is received, it is = uncompressed, re-serialized in deterministic encoding, and then hashed? > This could be an even harder question to ask with the use of an = external dictionary. There is one potential benefit w/ COSE in that the = hash of the dictionary could be included as external data. There are two aspects here: =E2=80=94 how do we make sure the external dictionary cannot be = surreptitiously exchanged by an attacker =E2=80=94 how do we make sure there is an unambiguous way to integrate = the external dictionary/-ies into the prefix and sharing tables? I have a design for the latter that I still need to write up. For the former, a COSE hash algorithm + the hash would do; the = dictionary would be hashed as an encoded CBOR data item. There is a = question whether there should be a way to put in a (compact!) identifier = for the dictionary as well, so the hash in the external data isn=E2=80=99t= a trapdoor function. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 28 16:18:14 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 EA0943A0A9B for ; Tue, 28 Jul 2020 16:18:13 -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 FSWyPh_SMQD4 for ; Tue, 28 Jul 2020 16:18:07 -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 892163A0A92 for ; Tue, 28 Jul 2020 16:18:07 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 28 Jul 2020 16:18:01 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: 'Brendan Moran' , References: <5E28C6E2-DFEC-4AF5-96CE-75E8F0927818@arm.com> <01d901d66503$2bbd93c0$8338bb40$@augustcellars.com> <7216D806-3473-463E-B6F2-AD8724AC56C6@tzi.org> In-Reply-To: <7216D806-3473-463E-B6F2-AD8724AC56C6@tzi.org> Date: Tue, 28 Jul 2020 16:17:59 -0700 Message-ID: <021e01d66535$57827d90$068778b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQKsAEWUoN/uCeZIyHWSgfhWse+x6wJ7AQ/pAQhIolWnVk5s4A== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT 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, 28 Jul 2020 23:18:14 -0000 > -----Original Message----- > From: Carsten Bormann > Sent: Tuesday, July 28, 2020 2:14 PM > To: Jim Schaad > Cc: Brendan Moran ; cbor@ietf.org > Subject: Re: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT >=20 >=20 > > On 2020-07-28, at 19:18, Jim Schaad wrote: > > > > [Brendan] One of the questions that I have is the order of = compressing and > applying security operations. If you are using a pull parser do you = think it is > going to be easier (we can talk about more secure later) to do the = hashing on > the compressed or uncompressed version. >=20 > Whoa. We normally hash byte strings. > So are you proposing that, say, a compressed version is received, it = is > uncompressed, re-serialized in deterministic encoding, and then = hashed? Both yes and no. I was thinking that the only thing that was going to = need to be re-encoded would be prefixes so that strings are fully there = and have the correct value. For doing things like substructure = substitution, I was just replacing the tag with that substructure and = passing in the data of that substructure as I was doing the decoding. = This has the advantage that an entity can sign a single representation, = the uncompressed version and it can later be compressed, with some = restrictions around maps, and both versions would verify. With = attention to doing maps, that is you are the both signing and = compressing, you could get "optimal" compression while still having a = signature that works on both versions. >=20 > > This could be an even harder question to ask with the use of an = external > dictionary. There is one potential benefit w/ COSE in that the hash = of the > dictionary could be included as external data. >=20 > There are two aspects here: > =E2=80=94 how do we make sure the external dictionary cannot be = surreptitiously > exchanged by an attacker =E2=80=94 how do we make sure there is an = unambiguous > way to integrate the external dictionary/-ies into the prefix and = sharing tables? >=20 > I have a design for the latter that I still need to write up. >=20 > For the former, a COSE hash algorithm + the hash would do; the = dictionary > would be hashed as an encoded CBOR data item. There is a question = whether > there should be a way to put in a (compact!) identifier for the = dictionary as > well, so the hash in the external data isn=E2=80=99t a trapdoor = function. Part of this includes the question of how you are going to identify the = dictionaries so that you get the right one if there are multiple = possibilities. The hash would be something that can be unique but would = need to be validated by the decoder. Jim >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 28 19:53: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 5CE443A0F26 for ; Tue, 28 Jul 2020 19:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net header.b=E4vxufiJ; dkim=pass (2048-bit key) header.d=comcastmailservice.net header.b=XLLm99O6 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 78uYkP4WLZOV for ; Tue, 28 Jul 2020 19:53:32 -0700 (PDT) Received: from resdmta-ch2-02v.sys.comcast.net (resdmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:82]) (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 803F43A0F25 for ; Tue, 28 Jul 2020 19:53:32 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net ([69.252.207.38]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id 0aKokIEHDVfJG0cDjkf7G1; Wed, 29 Jul 2020 02:53:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1595991211; bh=xvwNdXNMEJfS/k6bWlQxS7wbwRR+/qdZiH0aDEaQptg=; h=Received:Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=E4vxufiJj8PwuUcVqnUV63RmjkQHxAoZkVT390guxktvhFaF6QrCax100FXYoJUgE 1wJ/3X1o5FZeP76LPJLoDRctKrUq55PGaLJzLD4fwkGWQw7Jw4pZkWJ7UHxkVoiCRl EOhc8lfxG5P+6UJ+mLYbahy1qBK/guTIO9XtH9eSxgjQ0uNkxTnVUqQjLUXn8AvQHh EYcGY6p7zY9a9nKxn2NLJODcQzA9KKbpk614MFm64MFIxNIowH1SPeIvDNZ6/H/F5F CjvJ9AKaYHCY1niCMTNZwjrf+3beroIEOZe4yYBzWfroIqKJlGjBWOdPCv+CIQ1NJv A9JR5w/k2vxwg== Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id 0c52kYPst0Dff0cDjkjUhJ; Wed, 29 Jul 2020 02:53:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1595991211; bh=xvwNdXNMEJfS/k6bWlQxS7wbwRR+/qdZiH0aDEaQptg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=XLLm99O65rBu+yWFvQ9fVQ4/yVKzngWwOvfxZxEAW2WA7AonwMgd/Aj/k4y0unLO4 HLbTv/9lda2c1iiGvo1BdW8HW9+qY8IhuRyNnQXynXcs5B4NRKQWr7u+/RwS1wt9+w 9N1F26MvcIvVz/t0ultlb+T63tTjfDOFG9he0Um3PbU09tOsmVWRZeMyz7WEV36a6r oO/7cn8tnZgwGdI70VVwzr9l/L4YDCLgJhQPSlCezuGu3jI2aYgTWr1x8Xw+gOvbt2 A0OQ+FYnJPS5K2nlzAn/G3a9P2MxbwrekK5X+25W0MAtOOCAldGJ+aQOtnu1TUptzJ QSxPISR7FByEw== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-19v.sys.comcast.net with ESMTPA id 0cDfk8Pj2a3JB0cDgkeSWC; Wed, 29 Jul 2020 02:53:29 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 06T6rGoe006913; Wed, 29 Jul 2020 02:53:16 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 06T6rEEK006908; Wed, 29 Jul 2020 02:53:14 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Carsten Bormann Cc: cbor@ietf.org In-Reply-To: <341A1839-3F18-4DEC-9D31-37B8B52EE7F5@tzi.org> (cabo@tzi.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 29 Jul 2020 02:53:14 -0400 Message-ID: <87bljyzuat.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [Cbor] Packing CBOR (draft-bormann-cbor-packed-00) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 02:53:34 -0000 After a very quick look, these points about the draft stand out. The abstract contains: While traditional data compression techniques such as DEFLATE (RFC 1951) work well for CBOR, their disadvantage is that the receiver needs to unpack the compressed form to make use of data. This specification describes Packed CBOR, a simple transformation of a CBOR data item into another CBOR data item that is almost as easy to consume as the original CBOR data item. The first sentence is probably not exactly what you want to say, because of course, in order to make use of the content of any "compressed form" you first have to "unpack" it, in that you have to reverse whatever the compression was. I *think* what you mean is that in order to make use of even a small portion of the data, the entire prefix from the start to that portion of the data must be unpacked. The second sentence seems also to not state what you care about. I can define "a simple transformation of a CBOR data item into another CBOR data item" that is *just as easy* to consume as the original: the identity transformation. I *think* what you mean is that the packed form can (in many cases) be significantly smaller than the original form, and yet "random access" of individual items in the packed form is only constant-factor-slower than it is in the original form. Note that I'm depending on "random access" to mean extracting an item when the indexes into the nested arrays and keys of the nestd maps are provided. Note that this isn't just nit-picking, you're explaining the characteristics that differentiate Packed CBOR, that is, the reason for this work. The other thing that stands out is that the document is very terse. It promises to define the unpacking operation, but that definition is largely implicit. E.g., 2.1 says: Shared items are stored in the third to last element of the array used as tag content for tag number 6, numbered starting by 2. The shared data items are referenced by using the data items in Table 1. When reconstructing the original data item, such a reference is replaced by the referenced data item, which is then recursively unpacked. I *think* what this means is, "Unpacking a packed-CBOR object is done by starting with the rump structure and replacing references within it copies of the referenced structure. Within the rump structure, tag 6 (which I think is CDDL #6.6) is used not to designate a packed-CBOR structure but rather a reference to one of the shared structures. The tagged value in such a reference is either a simple value or an integer, interpreted according to Table 1. Implicitly, each reference is replaced by a copy of the referended shared value. The shared structures may themselves contain uses of tag 6, whose values are packed-CBOR structures." The difference in the above description is that it is explicit about the operations that convert the packed-CBOR structure into its unpacked form. Also, it's not clear to me whether a packed-CBOR (a value tagged with 6) can appear anywhere other than the top level of the CBOR structure. I would expect by the nature of CBOR it can be, but section 2 isn't clear about it. Dale From nobody Tue Jul 28 19:59: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 1DA8D3A0F11 for ; Tue, 28 Jul 2020 19:59:27 -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 lkDDEj3zG4j5 for ; Tue, 28 Jul 2020 19:59:25 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650112.outbound.protection.outlook.com [40.107.65.112]) (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 56C353A0EE2 for ; Tue, 28 Jul 2020 19:59:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cIj7IRzuBMCtGsjjYIpV9vQ9UXFjN1inRn8tSo1OngvO9iiHbdTVeK25XTrgdWnke6ae47U3ZYsK3AivN2Mr1pqwp7Ehzzn/dgqMXbT32Qe+zEw6bzEefvF0kEVn7GvbaSB3ECjXEAbzKt8TkbfuLe3xseoFKH8jjgoew2xeDHluXXxkkDj+3flxWApAwVAuRxqJCySkbD95DBl7uJoOZ64GsaZ6EHhq4QPQ18MUQwzmdBDi3ti1YeUuV/6SbRESikcNlLa8XyPHPOiKGsm6GJSm5diBn9GEOK4TsJOxBfvvi45HzMeA4+dwis0ExAUdDyRTa+8PQpKngwe00FgZIw== 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=K+Nn/fzMyE14OfmBdh4Xd4zVFz/yTn+m1xn6Dp47isE=; b=INlivJViaYxGysvu7JScs4GCIZq8xR2qNxH2tqQPAoseE7LHK+bKuqtmfIen6KI5zcFT5mDMiYYMuWgD944I8Iqxm5UodfkGDl/VOD2TPwrnM+TQ2XPEyCrmU5E8Xda1nq1aLzJwBlgwFGmWcfQGdeN8MNtx9RbbQbi6pLZnPlUHXGERh/b7LL7F4a2Psi8Vu2RYpDnH/Kcn8WSz1AF+cT8lZBBZY8KNoNLJLNCNSuihM5i9SYW2txQtt1YzqwH6JMB59glieemi/LWVH7VTphg3yg4osgbUxRVRu7jBoHNLgzw6pwXFrfMLgzrco4hrSWTz5+3rqB+dcrksr6AD+w== 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=K+Nn/fzMyE14OfmBdh4Xd4zVFz/yTn+m1xn6Dp47isE=; b=fMxU5Q2cCu2pmWH8RPBsCWACA31YM2zrbGIcjRmoslqvnseU7oU7NQZ7L/VNRic9MncJjRI2b6WN3xcIXD+szCUF7ESqrVq9x7LeRGDIiMVduKE1oUNhU3Xw1vk1a4E4ZZkrsg9jYLNYY103djqVXai9tpjbF/9ooEREnfQTemU= Received: from BY5PR00MB0676.namprd00.prod.outlook.com (2603:10b6:a03:20c::15) by BY5PR00MB0791.namprd00.prod.outlook.com (2603:10b6:a03:1d8::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3278.0; Wed, 29 Jul 2020 02:59:18 +0000 Received: from BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::2d3c:d0da:bc85:4e0f]) by BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::2d3c:d0da:bc85:4e0f%7]) with mapi id 15.20.3278.000; Wed, 29 Jul 2020 02:59:18 +0000 From: Mike Jones To: Carsten Bormann , "cbor@ietf.org" Thread-Topic: [Cbor] Packing CBOR (draft-bormann-cbor-packed-00) Thread-Index: AdZlVD2iKwHnZ/QRRCWfZ1kUDxHDlg== Date: Wed, 29 Jul 2020 02:59:18 +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=d24857bd-14d3-4b7a-8ef2-9231ef5aa1bf; 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-07-29T02:57:22Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.89.111] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f542a134-68e1-462d-6940-08d8336b62ca x-ms-traffictypediagnostic: BY5PR00MB0791: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Zuv6UbSccJS92xVE1ZIzoUPOT35sxewJwwRRPzb1qshWrGf8XlOY72kYOsJBfXLIrZ9vJxW08Tj6vkqHX76rYFaxgnU4pRZwVrA9QIEENyzl3U+qAbPmPVNhPGz0sm3mXpV14YxyHkXmwj7A5dOicsW9IYRuTArInpILhM/HRGbLTjDaPV9hIGhyvtIPiVfg3QO0x6JRRnhU91tZ42bzT0sjNrYC6BYuwwUZEA7AHOqi7GfSRWq2Mxtbj9b0EiAmT7L6OdX7VPNZa341/3sboHFLtGAL5BxmeFtghit0xQtxqsgKko36K9jWYW1HVsKVYjQu8KZa0Ol9oUBKbFLmlb/tGdOeqi1k3eJJFpyvnN/p09cRMYM+WNWBau/LSG7vBO3DNVvCYSHtjlQqpDjWzA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR00MB0676.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(376002)(136003)(396003)(346002)(33656002)(966005)(66946007)(478600001)(76116006)(64756008)(66574015)(66446008)(10290500003)(83380400001)(66556008)(66476007)(82960400001)(82950400001)(8990500004)(5660300002)(52536014)(2906002)(110136005)(86362001)(8936002)(71200400001)(8676002)(316002)(7696005)(53546011)(6506007)(186003)(55016002)(9686003)(26005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: g9y72sA6CX5BYziWqCPRktKDQY1Dim2nRYJCyau5lAtAOsfodRGiAFAZdYw9XsefzjYC3pj6VscVfrF1HuCAOQw+uP3qqu0QQVn1vJdDnGD06PF36Jsi7xHu5tsIKxzRxSp2Rg02GoZhsfLXmuouLz4Rkh8B7WtaeoDp7XgnRTn/j5eesKk3mhdIU/cAyJ7BsMapdm/SRJ7UM/xjqOmtMniKRyXnDFCeGbffNUbYUoBT8eacanOznkT5qosQyr+uxsCDD1iwOa2A+bChqw+8THnEcJF7v9oUp3paucGjCWyXjJRNettPSCKwBnhBVENZigdOI6W2uCnN2eo4wgFmzhexo1udr9F8VtmoKVMJirhDm4fWEVUGx4gDL/ftZHuShltzTBXLuAGKV1lH0xv81B9neKEchIBO4K9RpqGRfTeB/5rvuLXPKdgvSYwtYvHAj49MyB9GP3ujXvBEfDmiLKBjObjJ2jvo4HDV0xWpoJtM/KPEJ/IqRqpc3pMWe0/OQizwOJx6dP29C+6ZliftNUcuyZcsAsSeucLLZyt+qpBU8UQr5Si2Q+A5nqOFij/MOWGWIuQ/DxJFt7wfCH1pceRopAEmdXjOIhus19GgEZ/F8pBacEgMY+F39VkOBjS/0xbL5WJkixMamUu/KKcNUw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR00MB0676.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f542a134-68e1-462d-6940-08d8336b62ca X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2020 02:59:18.3381 (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: G3EUqIbi9Ssi6SHQ4eNFWW29Da3bE9H/6LWzRMJN5JiAcdTJbgX1nBr7w8wAvygRy5hjUBNGGoqEHgtNsF8Stw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR00MB0791 Archived-At: Subject: Re: [Cbor] Packing CBOR (draft-bormann-cbor-packed-00) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 02:59:27 -0000 SSBhbSBjb25jZXJuZWQgdGhhdCB0aGlzIHdpbGwgYmlmdXJjYXRlIENCT1IgaW50byBpbXBsZW1l bnRhdGlvbnMgdGhhdCBkbyBhbmQgZG9uJ3Qgc3VwcG9ydCB0aGlzIGV4dHJhIGZlYXR1cmUgc2V0 LiAgSWYgYSBjYWxsIGZvciBhZG9wdGlvbiB3ZXJlIGhlbGQgdG9kYXksIGhhdmluZyB0aG91Z2h0 IGFib3V0IGl0LCBJIHdvdWxkIG9wcG9zZSBhZG9wdGlvbiBvbiB0aGlzIGJhc2lzLiAgSSdkIHJh dGhlciB0aGF0IGFsbCBDQk9SIGltcGxlbWVudGF0aW9ucyBiZSBpbnRlcm9wZXJhYmxlIHRoYW4g Zm9yIHNvbWUgdG8gYWRkIHRoaXMgZmFpcmx5IGNvbXBsaWNhdGVkIGNvbXByZXNzaW9uIGZlYXR1 cmUuDQoNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBD Qk9SIDxjYm9yLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJvcm1hbm4N ClNlbnQ6IE1vbmRheSwgSnVseSAxMywgMjAyMCAxMjo0OCBQTQ0KVG86IGNib3JAaWV0Zi5vcmcN ClN1YmplY3Q6IFtDYm9yXSBQYWNraW5nIENCT1IgKGRyYWZ0LWJvcm1hbm4tY2Jvci1wYWNrZWQt MDApDQoNClRoaXMgZHJhZnQgbWF5IHNlZW0gYSBiaXQgdW51c3VhbCwgaW4gdGhhdCBpdCBhbGxv Y2F0ZXMgMjY4NDM5NTg1IHRhZ3MsIGluY2x1ZGluZyBvbmUgb2YgdGhlIDEyIHJlbWFpbmluZyBw cmVjaW91cyBzaW5nbGUtYnl0ZSBvbmVzLg0KQnV0IGlmIHlvdSByZWFkIGl0LCB0aGF0IHdpbGwg c2VlbSBwZXJmZWN0bHkgbm9ybWFsLg0KDQpQbGVhc2Ugc2VlDQpodHRwczovL3d3dy5pZXRmLm9y Zy9pZC9kcmFmdC1ib3JtYW5uLWNib3ItcGFja2VkLTAwLmh0bWwjbmFtZS1hY2tub3dsZWRnZW1l bnRzDQpmb3IgaG93IHRoaXMgY2FtZSB0byBiZS4NCg0KSeKAmW0gZ29pbmcgdG8gYXNrIGZvciBX RyBhZG9wdGlvbiBhdCBJRVRGIDEwOC4uLg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNCg0KPiBCZWdp biBmb3J3YXJkZWQgbWVzc2FnZToNCj4gDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zw0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJvcm1hbm4t Y2Jvci1wYWNrZWQtMDAudHh0DQo+IERhdGU6IDIwMjAtMDctMTMgYXQgMjE6NDI6MjEgQ0VTVA0K PiBUbzogIkNhcnN0ZW4gQm9ybWFubiIgPGNhYm9AdHppLm9yZz4NCj4gDQo+IA0KPiBBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtYm9ybWFubi1jYm9yLXBhY2tlZC0wMC50eHQgaGFzIGJlZW4g DQo+IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQ2Fyc3RlbiBCb3JtYW5uIGFuZCBwb3N0ZWQg dG8gdGhlIElFVEYgDQo+IHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtYm9ybWFubi1j Ym9yLXBhY2tlZA0KPiBSZXZpc2lvbjoJMDANCj4gVGl0bGU6CQlQYWNrZWQgQ0JPUg0KPiBEb2N1 bWVudCBkYXRlOgkyMDIwLTA3LTEzDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ IFBhZ2VzOgkJOQ0KPiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWJvcm1hbm4tY2Jvci1wYWNrZWQtMDAudHh0DQo+IFN0YXR1czogICAg ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3JtYW5uLWNib3It cGFja2VkLw0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWJvcm1hbm4tY2Jvci1wYWNrZWQtMDANCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYm9ybWFubi1jYm9yLXBhY2tlZA0KPiAN Cj4gDQo+IEFic3RyYWN0Og0KPiAgIFRoZSBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50 YXRpb24gKENCT1IsIFJGQyA3MDQ5KSBpcyBhIGRhdGENCj4gICBmb3JtYXQgd2hvc2UgZGVzaWdu IGdvYWxzIGluY2x1ZGUgdGhlIHBvc3NpYmlsaXR5IG9mIGV4dHJlbWVseSBzbWFsbA0KPiAgIGNv ZGUgc2l6ZSwgZmFpcmx5IHNtYWxsIG1lc3NhZ2Ugc2l6ZSwgYW5kIGV4dGVuc2liaWxpdHkgd2l0 aG91dCB0aGUNCj4gICBuZWVkIGZvciB2ZXJzaW9uIG5lZ290aWF0aW9uLg0KPiANCj4gICBDQk9S IGRvZXMgbm90IHByb3ZpZGUgYW55IGZvcm1zIG9mIGRhdGEgY29tcHJlc3Npb24uICBDQk9SIGRh dGENCj4gICBpdGVtcywgaW4gcGFydGljdWxhciB3aGVuIGdlbmVyYXRlZCBmcm9tIGxlZ2FjeSBk YXRhIG1vZGVscyBvZnRlbg0KPiAgIGFsbG93IGNvbnNpZGVyYWJsZSBnYWlucyBpbiBjb21wYWN0 bmVzcyB3aGVuIGFwcGx5aW5nIGRhdGENCj4gICBjb21wcmVzc2lvbi4gIFdoaWxlIHRyYWRpdGlv bmFsIGRhdGEgY29tcHJlc3Npb24gdGVjaG5pcXVlcyBzdWNoIGFzDQo+ICAgREVGTEFURSAoUkZD IDE5NTEpIHdvcmsgd2VsbCBmb3IgQ0JPUiwgdGhlaXIgZGlzYWR2YW50YWdlIGlzIHRoYXQgdGhl DQo+ICAgcmVjZWl2ZXIgbmVlZHMgdG8gdW5wYWNrIHRoZSBjb21wcmVzc2VkIGZvcm0gdG8gbWFr ZSB1c2Ugb2YgZGF0YS4NCj4gDQo+ICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlc2NyaWJlcyBQYWNr ZWQgQ0JPUiwgYSBzaW1wbGUgdHJhbnNmb3JtYXRpb24gb2YNCj4gICBhIENCT1IgZGF0YSBpdGVt IGludG8gYW5vdGhlciBDQk9SIGRhdGEgaXRlbSB0aGF0IGlzIGFsbW9zdCBhcyBlYXN5DQo+ICAg dG8gY29uc3VtZSBhcyB0aGUgb3JpZ2luYWwgQ0JPUiBkYXRhIGl0ZW0uICBBIHNlcGFyYXRlIGRl Y29tcHJlc3Npb24NCj4gICBzdGVwIGlzIHRoZXJlZm9yZSBvZnRlbiBub3QgcmVxdWlyZWQgYXQg dGhlIHJlY2VpdmVyLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+IHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+IA0KPiANCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNCT1IgbWFpbGluZyBs aXN0DQpDQk9SQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Nib3INCg== From nobody Tue Jul 28 22:12: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 DCDFF3A0F7D for ; Tue, 28 Jul 2020 22:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QGaW3sm0jMeJ for ; Tue, 28 Jul 2020 22:12:03 -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 C94A43A0F7C for ; Tue, 28 Jul 2020 22:12:02 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4BGhVS2xsgzyVN; Wed, 29 Jul 2020 07:12:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 29 Jul 2020 07:11:59 +0200 Cc: "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 617692319.801819-7bc2e15877003002ad6896ebc1fe1ee7 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mike Jones X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Packing CBOR (draft-bormann-cbor-packed-00) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 05:12:07 -0000 On 2020-07-29, at 04:59, Mike Jones wrote: >=20 > I am concerned that this will bifurcate CBOR into implementations that = do and don't support this extra feature set. =20 Hi Mike, that is of course true for any new tag. When we designed CBOR, one main issue was whether the feature set should = be static (as with JSON) or allow extensibility (using the tag concept); = we chose the latter. > If a call for adoption were held today, having thought about it, I = would oppose adoption on this basis. I'd rather that all CBOR = implementations be interoperable than for some to add this fairly = complicated compression feature. Packing has been designed so that it can be used with =E2=80=9Call CBOR = implementations=E2=80=9D (that do send unknown tags to the application); = if a CBOR-based protocol opts for allowing the use packing, that is the = same kind of decision as for allowing date tags. Gr=C3=BC=C3=9Fe, Carsten >=20 > -- Mike >=20 > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Monday, July 13, 2020 12:48 PM > To: cbor@ietf.org > Subject: [Cbor] Packing CBOR (draft-bormann-cbor-packed-00) >=20 > This draft may seem a bit unusual, in that it allocates 268439585 = tags, including one of the 12 remaining precious single-byte ones. > But if you read it, that will seem perfectly normal. >=20 > Please see > = https://www.ietf.org/id/draft-bormann-cbor-packed-00.html#name-acknowledge= ments > for how this came to be. >=20 > I=E2=80=99m going to ask for WG adoption at IETF 108... >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-bormann-cbor-packed-00.txt >> Date: 2020-07-13 at 21:42:21 CEST >> To: "Carsten Bormann" >>=20 >>=20 >> A new version of I-D, draft-bormann-cbor-packed-00.txt has been=20 >> successfully submitted by Carsten Bormann and posted to the IETF=20 >> repository. >>=20 >> Name: draft-bormann-cbor-packed >> Revision: 00 >> Title: Packed CBOR >> Document date: 2020-07-13 >> Group: Individual Submission >> Pages: 9 >> URL: = https://www.ietf.org/internet-drafts/draft-bormann-cbor-packed-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-bormann-cbor-packed/ >> Htmlized: = https://tools.ietf.org/html/draft-bormann-cbor-packed-00 >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-bormann-cbor-packed >>=20 >>=20 >> Abstract: >> The Concise Binary Object Representation (CBOR, RFC 7049) is a data >> format whose design goals include the possibility of extremely small >> code size, fairly small message size, and extensibility without the >> need for version negotiation. >>=20 >> CBOR does not provide any forms of data compression. CBOR data >> items, in particular when generated from legacy data models often >> allow considerable gains in compactness when applying data >> compression. While traditional data compression techniques such as >> DEFLATE (RFC 1951) work well for CBOR, their disadvantage is that = the >> receiver needs to unpack the compressed form to make use of data. >>=20 >> This specification describes Packed CBOR, a simple transformation of >> a CBOR data item into another CBOR data item that is almost as easy >> to consume as the original CBOR data item. A separate decompression >> step is therefore often not required at the receiver. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at = tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >>=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Tue Jul 28 22:19: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 7475D3A0F97 for ; Tue, 28 Jul 2020 22:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QuZw3eKbqzPw for ; Tue, 28 Jul 2020 22:19:03 -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 678D13A0F95 for ; Tue, 28 Jul 2020 22:19:03 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4BGhfY6B85zyVN; Wed, 29 Jul 2020 07:19:01 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <87bljyzuat.fsf@hobgoblin.ariadne.com> Date: Wed, 29 Jul 2020 07:19:01 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 617692741.29136-1ba2835b5bcc714cb29845ddd86c55a1 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87bljyzuat.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Packing CBOR (draft-bormann-cbor-packed-00) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 05:19:08 -0000 Hi Dale, +1 to all your editorial points; this sure was written up quickly. To the technical point: Yes, there is no reason tag 6 cannot be used = deeper within the structure. The interesting technical question is what = happens if there are two or more packed structures: Do they sail like = ships in the night, or is there interaction (e.g., for nested = compression, do the tables get merged in some way?)? We don=E2=80=99t have an answer for that (but probably should). A related question is how to support CBOR sequences: is there a way for = one of the data items to use a prefix/sharing table entry in another = data item in the sequence? Gr=C3=BC=C3=9Fe, Carsten > On 2020-07-29, at 08:53, Dale R. Worley wrote: >=20 > After a very quick look, these points about the draft stand out. The > abstract contains: >=20 > While traditional data compression techniques such as > DEFLATE (RFC 1951) work well for CBOR, their disadvantage is that = the > receiver needs to unpack the compressed form to make use of data. >=20 > This specification describes Packed CBOR, a simple transformation of > a CBOR data item into another CBOR data item that is almost as easy > to consume as the original CBOR data item. >=20 > The first sentence is probably not exactly what you want to say, = because > of course, in order to make use of the content of any "compressed = form" > you first have to "unpack" it, in that you have to reverse whatever = the > compression was. I *think* what you mean is that in order to make use > of even a small portion of the data, the entire prefix from the start = to > that portion of the data must be unpacked. >=20 > The second sentence seems also to not state what you care about. I = can > define "a simple transformation of a CBOR data item into another CBOR > data item" that is *just as easy* to consume as the original: the > identity transformation. I *think* what you mean is that the packed > form can (in many cases) be significantly smaller than the original > form, and yet "random access" of individual items in the packed form = is > only constant-factor-slower than it is in the original form. >=20 > Note that I'm depending on "random access" to mean extracting an item > when the indexes into the nested arrays and keys of the nestd maps are > provided. >=20 > Note that this isn't just nit-picking, you're explaining the > characteristics that differentiate Packed CBOR, that is, the reason = for > this work. >=20 > The other thing that stands out is that the document is very terse. > It promises to define the unpacking operation, but that definition is > largely implicit. E.g., 2.1 says: >=20 > Shared items are stored in the third to last element of the array > used as tag content for tag number 6, numbered starting by 2. >=20 > The shared data items are referenced by using the data items in > Table 1. When reconstructing the original data item, such a > reference is replaced by the referenced data item, which is then > recursively unpacked. >=20 > I *think* what this means is, "Unpacking a packed-CBOR object is done = by > starting with the rump structure and replacing references within it > copies of the referenced structure. Within the rump structure, tag 6 > (which I think is CDDL #6.6) is used not to designate a packed-CBOR > structure but rather a reference to one of the shared structures. The > tagged value in such a reference is either a simple value or an = integer, > interpreted according to Table 1. Implicitly, each reference is > replaced by a copy of the referended shared value. The shared > structures may themselves contain uses of tag 6, whose values are > packed-CBOR structures." >=20 > The difference in the above description is that it is explicit about = the > operations that convert the packed-CBOR structure into its unpacked > form. >=20 > Also, it's not clear to me whether a packed-CBOR (a value tagged with = 6) > can appear anywhere other than the top level of the CBOR structure. I > would expect by the nature of CBOR it can be, but section 2 isn't = clear > about it. >=20 > Dale >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Jul 29 05:37:26 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 AC4F63A0A4E for ; Wed, 29 Jul 2020 05:37:24 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=j7uj3kgW; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=j7uj3kgW 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 6yqZeNryKrZc for ; Wed, 29 Jul 2020 05:37:21 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80052.outbound.protection.outlook.com [40.107.8.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377903A0A49 for ; Wed, 29 Jul 2020 05:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lQVy8DEn+SbmBUrLiWsjFerEMuEwvJmleC5s8qPCo+8=; b=j7uj3kgWmdo0GhRD1odM+Sub9gVh3RM7O0lv8Iqos6VQjsF/fxrPJQ1rOLYVUpKHerJrJaTBDWu36leKdj+uHkevLgAlW/V/leuSlQX5y3jbL1SMOnPyJuYw/7i9Vy8wPoQLiGRZcpN/7o8ED2wUbD/wyfh3rdm15iXLDIYmGu0= Received: from AM6P195CA0003.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:81::16) by HE1PR0801MB1643.eurprd08.prod.outlook.com (2603:10a6:3:83::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Wed, 29 Jul 2020 12:37:17 +0000 Received: from VE1EUR03FT012.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:81:cafe::f5) by AM6P195CA0003.outlook.office365.com (2603:10a6:209:81::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Wed, 29 Jul 2020 12:37:17 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT012.mail.protection.outlook.com (10.152.18.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.10 via Frontend Transport; Wed, 29 Jul 2020 12:37:17 +0000 Received: ("Tessian outbound c4059ed8d7bf:v62"); Wed, 29 Jul 2020 12:37:16 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 950c619479832728 X-CR-MTA-TID: 64aa7808 Received: from e1f2e0d5653f.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 7AADEF15-AFEE-4BFD-B529-8499F2D4E075.1; Wed, 29 Jul 2020 12:37:11 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e1f2e0d5653f.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 29 Jul 2020 12:37:11 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ORclQtIJ0+H8yzUlAMhODb5rfFdmf9R/0viU8Qdnj3ztTpFH9b9mi0DXSNelF4shWyNKiXo5cCXqhz1V7+wnf/hcMVtaeJtku5QSNmZciDBaO8wvjVdzR2U0+sqkOltwrrEMiDj0bjRvKqe0SQbaCWpl/RL6YGR0RTjFoRyIwsYaAWiYTnZqMyksGuxBUoxzG56NgpgLG/pdfDzhEhFnBg1LC5M5XoF/KLlxY2+hZmjRkw2g/oir8RsRe19u2S58P7TNigENw0a7dnKTegBmdt9tUwIKRVRGlYWhfhcnLfJcFKGgDibuHrENux/4b0zu0TYlKzzi+40PkfnVh2iI3w== 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=lQVy8DEn+SbmBUrLiWsjFerEMuEwvJmleC5s8qPCo+8=; b=VmBuaFm1RL1Vmyb0x4wfOr5gAVJdzs8mLg6OuCS73M5k8+VN7vWV0Cklpkhg1ohHLXS8h9DuOSZDQi07smEJ5MW3YBCE2r0Z7e0Mwzog6+CNNtNNM6yUShcfO9M+GgI1FhxlRFfy6IN+Q4ITbmnc3pZSKE7ShVGwM8u7y9hblj2kKCG6oQfk6r9tP8xTbYNhpVItptls1DS+FGCE0DfVzAUAI+xQSUgRi9Nmg+TlKJjQms9H1x+MB4ZjVS7eN4hd9ST35XdNsKQe0QtOA73zaL8H6jutzF2nADo7pEbMScdMrXrELeTf7f8VvgUvmfMe92byLJq7KtKUDNHRLDtl1w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lQVy8DEn+SbmBUrLiWsjFerEMuEwvJmleC5s8qPCo+8=; b=j7uj3kgWmdo0GhRD1odM+Sub9gVh3RM7O0lv8Iqos6VQjsF/fxrPJQ1rOLYVUpKHerJrJaTBDWu36leKdj+uHkevLgAlW/V/leuSlQX5y3jbL1SMOnPyJuYw/7i9Vy8wPoQLiGRZcpN/7o8ED2wUbD/wyfh3rdm15iXLDIYmGu0= Received: from AM6PR08MB4738.eurprd08.prod.outlook.com (2603:10a6:20b:cf::10) by AM5PR0802MB2385.eurprd08.prod.outlook.com (2603:10a6:203:9e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Wed, 29 Jul 2020 12:37:10 +0000 Received: from AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56]) by AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56%3]) with mapi id 15.20.3216.034; Wed, 29 Jul 2020 12:37:10 +0000 From: Brendan Moran To: Jim Schaad CC: Carsten Bormann , "cbor@ietf.org" Thread-Topic: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT Thread-Index: AQHWZPM7PSkNaZ82xkeO03LjqC3Ah6kdPGyAgABBsICAACKngIAA30mA Date: Wed, 29 Jul 2020 12:37:09 +0000 Message-ID: <406B6702-3045-4490-8CD0-8E352F924714@arm.com> References: <5E28C6E2-DFEC-4AF5-96CE-75E8F0927818@arm.com> <01d901d66503$2bbd93c0$8338bb40$@augustcellars.com> <7216D806-3473-463E-B6F2-AD8724AC56C6@tzi.org> <021e01d66535$57827d90$068778b0$@augustcellars.com> In-Reply-To: <021e01d66535$57827d90$068778b0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) Authentication-Results-Original: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.20.19.206] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: b10cc66d-20a3-42d7-bd28-08d833bc20f0 x-ms-traffictypediagnostic: AM5PR0802MB2385:|HE1PR0801MB1643: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: DwKIdOPKWCiN/Ht/E7TJgk1FBuAuwBjLFyhLuvDYT0bMoIZlBxUJG0c+1hgf5Zk/nZ4LqgdzOoW4FeQyPEsmQfgLgqqE4eZdlPeJkfG9YW+fEulW3U7TMnZR9/wgiuCi+1ZfQmOXh5lz9ghJRCV6hz5+QTXrh/m5vEZXc7KeTO5cByoEpGjc3qer6RAnbBQhqwztQD+JS+fb+9V0HH5YlXVJsSa9qZHmS/IpunLuQE31A+1iiIBTumy3ZnMxQRV+M2eIdpsYQ2v7eSNfD7CS2+3MhehuU8OL0smn656JPvIqz/BpP6KfvQQ2QjvKWD/bmTUok08xwn3khCGzQuLMBdAiZtKwX7HptD66HbvIaC5X+EhJKitwLlhpC3AQa3u6fR1X8u/5FHq7eJQ7XQYITQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4738.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(346002)(366004)(396003)(376002)(6916009)(2906002)(8676002)(71200400001)(86362001)(6512007)(26005)(316002)(53546011)(91956017)(8936002)(186003)(478600001)(54906003)(2616005)(6506007)(66476007)(966005)(6486002)(33656002)(5660300002)(76116006)(64756008)(83380400001)(36756003)(4326008)(66446008)(66556008)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 9GGBh4KUUoTA4FZWcDx1KMdX3Lt2CZNU54lnbV6BXOYm5341iL8dwaiDQINvcMaj39A7vCQI54esBn3koxgh+8ZITVNl1EYk134pXquFpLBTKR5Fk4bCoHzIzCNw3ubw8NyHlon9lRs7I90j7arV1HKVk+a5SQQ2C4vGgwFh3jh0YxERx0ScoWQIWLWMHd/bdnEqgYeHrIHfOHFIHe3wu+0n/mBtveLvSnMmBurQSgfNC0NhZzvvmR++C8Y6b32r1AL6WGBuTZat70EnF8/gvQrysxBc6SH9FnZuG6z3s7wg7Dj6z0vnzHsjFXYv0zqUEnmuV0Q2fy1XdtwEc3BRHXPif2JRyAiE78E7/HMxZ7lqBDoB1dkLLhZUT2diAav+2uyBoRF2UVqhLuPkNeOS2lu7+gSs4c/mOQDy1JZOzjiEHjdrBEK6JdDSgQKzLrUTo74Vcz2FqtOKJ7OZB+0NSUrE0QcbJc61+9vuJN5GGLM= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_406B6702304544908CD08E352F924714armcom_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0802MB2385 Original-Authentication-Results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT012.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: c83837ee-f96d-4244-b421-08d833bc1cc6 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /ZV2XlyomPmvsuL1oq1LDFXkL+ADmKS1JaSAHJQkzGsiIgCUeEolitUyUizTmNI3QvF3vdez5ziBb3DdSO1dTXdYIvJos5PuVg3Xs/x8H/wDeV3eYBFJLaD6ruOUiQi/HhwpjjlLe3G5OkwT+DUB2yBCQRi28ii/1VKoduX7aXxN9aLwhU1EGSJ2HIEAWitGiDWEyckwFEzRXnJnGWS6BnGpsJVs5pVYzw4sUjFAj2CDgpZ6eAuxKk2MapswPI5grnZ63KZiBRWG6pHKglR6jOFR/VQrIvLQDHZHktDy0W5GxNWdHN/gL5VXIcV8xA0tMlqAniCMgZoauWJtEMYqIfRkYoj5AQ7khA5ODV4EMNUGlkC4JSG8Bcy4fAdUkPeTq50OLKHohnGNSWTJI+9Ue543taw8aThQEtA6uOEWpfh7SC5HS1oGwuG7QZQAcgLAG32L7RpRNTawbtpv0FHn5Ikv1yZfPwrTNnxb35bw+lI= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(346002)(39860400002)(376002)(46966005)(70206006)(2906002)(70586007)(33964004)(966005)(478600001)(356005)(82310400002)(6506007)(186003)(53546011)(26005)(36906005)(81166007)(54906003)(36756003)(316002)(2616005)(8936002)(4326008)(82740400003)(47076004)(336012)(6512007)(86362001)(6862004)(5660300002)(30864003)(83380400001)(6486002)(8676002)(45080400002)(33656002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2020 12:37:17.0952 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b10cc66d-20a3-42d7-bd28-08d833bc20f0 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT012.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1643 Archived-At: Subject: Re: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 12:37:25 -0000 --_000_406B6702304544908CD08E352F924714armcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIDI5IEp1bCAyMDIwLCBhdCAwMDoxNywgSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxs YXJzLmNvbTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4+IHdyb3RlOg0KDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emku b3JnPG1haWx0bzpjYWJvQHR6aS5vcmc+Pg0KU2VudDogVHVlc2RheSwgSnVseSAyOCwgMjAyMCAy OjE0IFBNDQpUbzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTxtYWlsdG86aWV0 ZkBhdWd1c3RjZWxsYXJzLmNvbT4+DQpDYzogQnJlbmRhbiBNb3JhbiA8QnJlbmRhbi5Nb3JhbkBh cm0uY29tPG1haWx0bzpCcmVuZGFuLk1vcmFuQGFybS5jb20+PjsgY2JvckBpZXRmLm9yZzxtYWls dG86Y2JvckBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ2Jvcl0gUmV2aWV3OiBkcmFmdC1ib3Jt YW5uLWNib3ItcGFja2VkLTAwICYgU1VJVA0KDQoNCk9uIDIwMjAtMDctMjgsIGF0IDE5OjE4LCBK aW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPG1haWx0bzppZXRmQGF1Z3VzdGNlbGxh cnMuY29tPj4gd3JvdGU6DQoNCltCcmVuZGFuXSBPbmUgb2YgdGhlIHF1ZXN0aW9ucyB0aGF0IEkg aGF2ZSBpcyB0aGUgb3JkZXIgb2YgY29tcHJlc3NpbmcgYW5kDQphcHBseWluZyBzZWN1cml0eSBv cGVyYXRpb25zLiAgSWYgeW91IGFyZSB1c2luZyBhIHB1bGwgcGFyc2VyIGRvIHlvdSB0aGluayBp dCBpcw0KZ29pbmcgdG8gYmUgZWFzaWVyICh3ZSBjYW4gdGFsayBhYm91dCBtb3JlIHNlY3VyZSBs YXRlcikgdG8gZG8gdGhlIGhhc2hpbmcgb24NCnRoZSBjb21wcmVzc2VkIG9yIHVuY29tcHJlc3Nl ZCB2ZXJzaW9uLg0KDQpXaG9hLiAgV2Ugbm9ybWFsbHkgaGFzaCBieXRlIHN0cmluZ3MuDQpTbyBh cmUgeW91IHByb3Bvc2luZyB0aGF0LCBzYXksIGEgY29tcHJlc3NlZCB2ZXJzaW9uIGlzIHJlY2Vp dmVkLCBpdCBpcw0KdW5jb21wcmVzc2VkLCByZS1zZXJpYWxpemVkIGluIGRldGVybWluaXN0aWMg ZW5jb2RpbmcsIGFuZCB0aGVuIGhhc2hlZD8NCg0KQm90aCB5ZXMgYW5kIG5vLiAgSSB3YXMgdGhp bmtpbmcgdGhhdCB0aGUgb25seSB0aGluZyB0aGF0IHdhcyBnb2luZyB0byBuZWVkIHRvIGJlIHJl LWVuY29kZWQgd291bGQgYmUgcHJlZml4ZXMgc28gdGhhdCBzdHJpbmdzIGFyZSBmdWxseSB0aGVy ZSBhbmQgaGF2ZSB0aGUgY29ycmVjdCB2YWx1ZS4gIEZvciBkb2luZyB0aGluZ3MgbGlrZSBzdWJz dHJ1Y3R1cmUgc3Vic3RpdHV0aW9uLCBJIHdhcyBqdXN0IHJlcGxhY2luZyB0aGUgdGFnIHdpdGgg dGhhdCBzdWJzdHJ1Y3R1cmUgYW5kIHBhc3NpbmcgaW4gdGhlIGRhdGEgb2YgdGhhdCBzdWJzdHJ1 Y3R1cmUgYXMgSSB3YXMgZG9pbmcgdGhlIGRlY29kaW5nLiAgVGhpcyBoYXMgdGhlIGFkdmFudGFn ZSB0aGF0IGFuIGVudGl0eSBjYW4gc2lnbiBhIHNpbmdsZSByZXByZXNlbnRhdGlvbiwgdGhlIHVu Y29tcHJlc3NlZCB2ZXJzaW9uIGFuZCBpdCBjYW4gbGF0ZXIgYmUgY29tcHJlc3NlZCwgd2l0aCBz b21lIHJlc3RyaWN0aW9ucyBhcm91bmQgbWFwcywgYW5kIGJvdGggdmVyc2lvbnMgd291bGQgdmVy aWZ5LiAgV2l0aCBhdHRlbnRpb24gdG8gZG9pbmcgbWFwcywgdGhhdCBpcyB5b3UgYXJlIHRoZSBi b3RoIHNpZ25pbmcgYW5kIGNvbXByZXNzaW5nLCB5b3UgY291bGQgZ2V0ICJvcHRpbWFsIiBjb21w cmVzc2lvbiB3aGlsZSBzdGlsbCBoYXZpbmcgYSBzaWduYXR1cmUgdGhhdCB3b3JrcyBvbiBib3Ro IHZlcnNpb25zLg0KDQpNeSBpbnRlbnQgd2FzIHRvIHZlcmlmeSBmaXJzdCwgdGhlbiB1bnBhY2su IFRoaXMgaXMgYmVjYXVzZSB0aGUgdW5wYWNrZWQgc3RydWN0dXJlIG5ldmVyIGV4aXN0cywgaW4g aXRzIGVudGlyZXR5LCBpbiBtZW1vcnkuIElmIHlvdSBoYXZlIHRvIHVucGFjayBzdHJhaWdodCBp bnRvIHRoZSBkaWdlc3QgYWxnb3JpdGhtIGluIG9yZGVyIHRvIHZlcmlmeSwgeW91IGludHJvZHVj ZSBhIFRPQ1RPVSBwcm9ibGVtLiBJZiB5b3UgdmVyaWZ5IGZpcnN0LCB5b3UgYXQgbGVhc3QgaGF2 ZSBhIHN0YXRpYywgdmVyaWZpZWQgb2JqZWN0Lg0KDQoNClRoaXMgY291bGQgYmUgYW4gZXZlbiBo YXJkZXIgcXVlc3Rpb24gdG8gYXNrIHdpdGggdGhlIHVzZSBvZiBhbiBleHRlcm5hbA0KZGljdGlv bmFyeS4gIFRoZXJlIGlzIG9uZSBwb3RlbnRpYWwgYmVuZWZpdCB3LyBDT1NFIGluIHRoYXQgdGhl IGhhc2ggb2YgdGhlDQpkaWN0aW9uYXJ5IGNvdWxkIGJlIGluY2x1ZGVkIGFzIGV4dGVybmFsIGRh dGEuDQoNClRoZSBwcm9ibGVtIHdpdGggdGhpcyBhcHByb2FjaCBpcyBkaWN0aW9uYXJ5IHNlbGVj dGlvbi4gV2UgbmVlZCBzb21lIHdheSB0byBoaW50IGEgZGljdGlvbmFyeSBpZGVudGlmaWVyIGlm IGl04oCZcyBub3Qgb2J2aW91cy4gVGhpcyBjb3VsZCBiZSBhIHRhZywgYW4gZWxlbWVudCBpbiB0 aGUgVGFnIDYgYXJyYXksIHNvbWUga2luZCBvZiBPT0Igc2lnbmFsLCBvciBzb21ldGhpbmcgZWxz ZS4NCg0KVGhlcmUgYXJlIHR3byBhc3BlY3RzIGhlcmU6DQrigJQgaG93IGRvIHdlIG1ha2Ugc3Vy ZSB0aGUgZXh0ZXJuYWwgZGljdGlvbmFyeSBjYW5ub3QgYmUgc3VycmVwdGl0aW91c2x5DQpleGNo YW5nZWQgYnkgYW4gYXR0YWNrZXINCg0KVGhpcyByZXF1aXJlcyBzb21lIHNvcnQgb2Ygc2VjdXJp dHkgbWVjaGFuaXNtLiBVc2luZyBhIENPU0UgZmVhdHVyZSB0aGF0IGluY2x1ZGVzIGFkZGl0aW9u YWwgZGF0YSBpcyBub3QgaWRlYWwgaW4gU1VJVCBiZWNhdXNlIHdlIHN1cHBvcnQgQ09TRV9TaWdu LCBDT1NFX1NpZ24xLCBDT1NFX01BQywgb3IgQ09TRV9NQUMwLCBvciBhbnkgY29tYmluYXRpb24g dGhlcmVvZi4gVGhpcyB3b3VsZCBtZWFuIHRoYXQgYSBDT1NFIGZlYXR1cmUgdGhhdCBpbmNsdWRl cyBleHRyYSBkYXRhIHdvdWxkIGJlIGR1cGxpY2F0ZWQgZm9yIGFzIG1hbnkgQ09TRSBvYmplY3Rz IGFzIGFyZSBpbmNsdWRlZC4gT2YgY291cnNlLCB0aGF04oCZcyBub3QgcGFydGljdWxhcmx5IHJl bGV2YW50IGlmIHRoZSBsaXN0IG9mIENPU0Ugb2JqZWN0cyBpcyBhbHNvIHVzaW5nIHBhY2tlZCBD Qk9SLCBzbyBtYXliZSBpdOKAmXMgZmluZS4NCg0KSW5jbHVkaW5nIGEgZGljdGlvbmFyeSByZWZl cmVuY2UgYXMgQUFEIHNlZW1zIGZpbmUgdG8gbWUuIEluIHRoZSBTVUlUIGNhc2UsIEkgdGhpbmsg SSB3b3VsZCBtYWtlIGl0IG1vcmUgZXhwbGljaXQgYmVjYXVzZSB3ZSBuZWVkIHRvIGlkZW50aWZ5 IHdoaWNoIGV4dGVybmFsIGRpY3Rpb25hcnkgdG8gZGlnZXN0Lg0KDQoNCuKAlCBob3cgZG8gd2Ug bWFrZSBzdXJlIHRoZXJlIGlzIGFuIHVuYW1iaWd1b3VzDQp3YXkgdG8gaW50ZWdyYXRlIHRoZSBl eHRlcm5hbCBkaWN0aW9uYXJ5Ly1pZXMgaW50byB0aGUgcHJlZml4IGFuZCBzaGFyaW5nIHRhYmxl cz8NCg0KV2UgbmVlZCB0byAobG9naWNhbGx5KSBjb25jYXRlbmF0ZSB0aGUgZGljdGlvbmFyaWVz IHRvZ2V0aGVyLiBUaGUgcXVlc3Rpb24gaXM6IHdoaWNoIG9yZGVyPw0KDQpGcm9tIGEgcHVsbCBw YXJzZXIgcGVyc3BlY3RpdmUsIEkgdGhpbmsgSSB3b3VsZCBzdWdnZXN0IGEgc3RhY2stYmFzZWQg bW9kZWw6DQotIEVhY2ggZGljdGlvbmFyeSBpcyBhbiBlbGVtZW50IGluIGEgc2luZ2x5IGxpbmtl ZCBsaXN0Lg0KLSBXaGVuIHlvdSBlbmNvdW50ZXIgYSBuZXcgZGljdGlvbmFyeSwgeW91IHB1c2gg aXQgb250byB0aGUgaGVhZCBvZiB0aGUgbGlzdA0KLSBXaGVuIHlvdSBmaW5pc2ggYSBydW1wIGVs ZW1lbnQsIHlvdSBwb3AgdGhlIGRpY3Rpb25hcnkgYXNzb2NpYXRlZCB3aXRoIGl0IGZyb20gdGhl IGhlYWQgb2YgdGhlIGxpc3QuDQotIFdoZW4geW91IGZpbmQgYSBkaWN0aW9uYXJ5IHJlZmVyZW5j ZSBpbiB0aGUgcnVtcCwgeW91IHRyYXZlcnNlIHRoZSBkaWN0aW9uYXJ5IGxpc3QsIHN0YXJ0aW5n IGF0IHRoZSBtb3N0IHJlY2VudC4NCi0gV2hlbiB5b3UgZmluZCBhIGRpY3Rpb25hcnkgcmVmZXJl bmNlIGluIGEgZGljdGlvbmFyeSBlbGVtZW50LCB5b3UgdHJhdmVyc2UgdGhlIGRpY3Rpb25hcnkg bGlzdCwgc3RhcnRpbmcgYXQgdGhlIGN1cnJlbnQgZGljdGlvbmFyeS4NCg0KVGhpcyBoYXMgc2V2 ZXJhbCBhZHZhbnRhZ2VzOg0KLSBJdOKAmXMgY29tcGF0aWJsZSB3aXRoIGluY2x1ZGluZyBhIHBh Y2tlZCBDQk9SIG9iamVjdCBpbnNpZGUgYSBwYWNrZWQgQ0JPUiBvYmplY3Qgd2l0aG91dCByZXdy aXRpbmcgYW55IHJlZmVyZW5jZXMuDQotIFRoZSBkYXRhIG1vZGVsIGZvciBkaWN0aW9uYXJ5IHRy YXZlcnNhbCBpcyBmYWlybHkgc2ltcGxlDQoNCkl0IGhhcyBzZXZlcmFsIGRpc2FkdmFudGFnZXM6 DQotIFJlZmVyZW5jZXMgaGF2ZSBpbmNvbnNpc3RlbnQgbWVhbmluZ3MgKFRhZyA2ICgxKSBkb2Vz buKAmXQgbWVhbiB0aGUgc2FtZSBkaWN0aW9uYXJ5IGVudHJ5IGV2ZXJ5d2hlcmUuIEl0IHBvaW50 cyB0byBkaWZmZXJlbnQgZGljdGlvbmFyaWVzIGluIGRpZmZlcmVudCBwbGFjZXMpDQotIFRoZSBz dGFjayBtb2RlbCByZXF1aXJlcyBzb21lIGtpbmQgb2YgYWxsb2NhdGlvbiBzdHJhdGVneSB0byBr ZWVwIHRyYWNrIG9mIHRoZSBkaWN0aW9uYXJpZXMuDQotIFRoZSBjb21wcmVzc29yIGhhcyB0byBi ZSBhd2FyZSBvZiB0aGUgZGljdGlvbmFyaWVzIG9mIHBhY2tlZCBDQk9SIG9iamVjdHMgaXQgdHJh dmVyc2VzIGluIG9yZGVyIHRvIHBhY2sgYW55dGhpbmcgdGhhdCBhcHBlYXJzIHdpdGhpbiBhbiBh bHJlYWR5IHBhY2tlZCBDQk9SIG9iamVjdC4NCg0KSG93ZXZlciwgdGhpcyBtYXkgYmUgbmFpdmUg YXMgd2VsbC4gSXQgaW1wbGllcyB0aGF0IHRoZXJlIGlzIG9ubHkgYSBsaXN0IG9mIGRpY3Rpb25h cmllcyB0aGF0IGFwcGxpZXMgYXQgYW55IHBvaW50LCByYXRoZXIgdGhhbiBhIHRyZWUuIFRoaXMg aXMgcHJvYmFibHkgYWNjdXJhdGUgd2hlbiBsb29raW5nIGF0IG5lc3RlZCBwYWNrZWQgb2JqZWN0 cy4gSXQgbWlnaHQgYmUgbW9yZSBvZiBhIHByb2JsZW0gd2l0aCBleHRlcm5hbCBkaWN0aW9uYXJp ZXMuDQoNCkkgaGF2ZSBhIGRlc2lnbiBmb3IgdGhlIGxhdHRlciB0aGF0IEkgc3RpbGwgbmVlZCB0 byB3cml0ZSB1cC4NCg0KRm9yIHRoZSBmb3JtZXIsIGEgQ09TRSBoYXNoIGFsZ29yaXRobSArIHRo ZSBoYXNoIHdvdWxkIGRvOyB0aGUgZGljdGlvbmFyeQ0Kd291bGQgYmUgaGFzaGVkIGFzIGFuIGVu Y29kZWQgQ0JPUiBkYXRhIGl0ZW0uICBUaGVyZSBpcyBhIHF1ZXN0aW9uIHdoZXRoZXINCnRoZXJl IHNob3VsZCBiZSBhIHdheSB0byBwdXQgaW4gYSAoY29tcGFjdCEpIGlkZW50aWZpZXIgZm9yIHRo ZSBkaWN0aW9uYXJ5IGFzDQp3ZWxsLCBzbyB0aGUgaGFzaCBpbiB0aGUgZXh0ZXJuYWwgZGF0YSBp c27igJl0IGEgdHJhcGRvb3IgZnVuY3Rpb24uDQoNClBhcnQgb2YgdGhpcyBpbmNsdWRlcyB0aGUg cXVlc3Rpb24gb2YgaG93IHlvdSBhcmUgZ29pbmcgdG8gaWRlbnRpZnkgdGhlIGRpY3Rpb25hcmll cyBzbyB0aGF0IHlvdSBnZXQgdGhlIHJpZ2h0IG9uZSBpZiB0aGVyZSBhcmUgbXVsdGlwbGUgcG9z c2liaWxpdGllcy4gIFRoZSBoYXNoIHdvdWxkIGJlIHNvbWV0aGluZyB0aGF0IGNhbiBiZSB1bmlx dWUgYnV0IHdvdWxkIG5lZWQgdG8gYmUgdmFsaWRhdGVkIGJ5IHRoZSBkZWNvZGVyLg0KDQpUaGUg cmVxdWlyZW1lbnQgZm9yIGEgaGFzaCBkZXBlbmRzIG9uIGNvbnRleHQuIFdoZXJlIGl0IGlzIHJl cXVpcmVkLCB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciBpdOKAmXMgZXhwbGljaXQgb3IgaW1wbGlj aXQuIE5vdywgd2hhdOKAmXMgcmVhbGx5IGludGVyZXN0aW5nIGhlcmUgaXMgdGhhdCBpdCBjb3Vs ZCBiZSBwYWNrZWQgdG9vLiBFZmZlY3RpdmVseSwgd2hhdCBJIG1lYW4gaGVyZSBpcyB0aGF0IGl0 4oCZcyBsZWdpdGltYXRlIHRvIHVzZSBwYWNrZWQgQ0JPUiB0byBjb21wcmVzcyBhIENPU0Ugb2Jq ZWN0LiBJZiB3ZSB1c2UgYW4gZXh0ZXJuYWwgZGljdGlvbmFyeSB0byBjb21wcmVzcyB0aGUgQ09T RSBvYmplY3QsIGl0IHNlZW1zIHBsYXVzaWJsZSB0byBhZGQgaW4gYSBkaWN0aW9uYXJ5IHZhbHVl IGZvciB0aGUgaGFzaCAmIGhhc2ggYWxnb3JpdGhtIHVzZWQgdG8gcmVwcmVzZW50IGEgc2Vjb25k LCBub24tQ09TRSBleHRlcm5hbCBkaWN0aW9uYXJ5Lg0KDQpJIHRoaW5rIHRoYXQgZXh0ZXJuYWwg ZGljdGlvbmFyaWVzICpvdXRzaWRlKiBhbiBhdXRoZW50aWNhdGlvbiBvYmplY3QgcHJvYmFibHkg ZG9u4oCZdCByZXF1aXJlIGF1dGhlbnRpY2F0aW9uLCBzaW5jZSB0aGUgYXV0aGVudGljYXRpb24g b2JqZWN0IGl0c2VsZiB3aWxsIG5hdHVyYWxseSB2ZXJpZnkgdGhlc2UgZGF0YS4gSG93ZXZlciwg YW55IGV4dGVybmFsIGRpY3Rpb25hcnkgcmVwcmVzZW50ZWQgKmluc2lkZSogYW4gYXV0aGVudGlj YXRpb24gb2JqZWN0IE1VU1QgYWxzbyBiZSBhdXRoZW50aWNhdGVkLg0KDQpJIGNhbiBwcm92aWRl IGEgd29ya2VkLXVwIGV4YW1wbGUgaWYgdGhhdCBtYWtlcyBpdCBjbGVhcmVyLg0KDQoNCkJyZW5k YW4NCg0KSmltDQoNCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0JPUiBtYWlsaW5nIGxpc3QNCkNCT1JAaWV0Zi5v cmc8bWFpbHRvOkNCT1JAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Nib3INCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBw cml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29u dGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3Rv cmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_406B6702304544908CD08E352F924714armcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IDI5IEp1bCAyMDIwLCBhdCAwMDoxNywgSmltIFNjaGFhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmll dGZAYXVndXN0Y2VsbGFycy5jb20iIGNsYXNzPSIiPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+ Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxiciBjbGFzcz0iIj4NCkZyb206IENhcnN0ZW4gQm9ybWFubiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmNhYm9AdHppLm9yZyIgY2xhc3M9IiI+Y2Fib0B0emkub3JnPC9hPiZndDs8YnIgY2xh c3M9IiI+DQpTZW50OiBUdWVzZGF5LCBKdWx5IDI4LCAyMDIwIDI6MTQgUE08YnIgY2xhc3M9IiI+ DQpUbzogSmltIFNjaGFhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5j b20iIGNsYXNzPSIiPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4N CkNjOiBCcmVuZGFuIE1vcmFuICZsdDs8YSBocmVmPSJtYWlsdG86QnJlbmRhbi5Nb3JhbkBhcm0u Y29tIiBjbGFzcz0iIj5CcmVuZGFuLk1vcmFuQGFybS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1h aWx0bzpjYm9yQGlldGYub3JnIiBjbGFzcz0iIj5jYm9yQGlldGYub3JnPC9hPjxiciBjbGFzcz0i Ij4NClN1YmplY3Q6IFJlOiBbQ2Jvcl0gUmV2aWV3OiBkcmFmdC1ib3JtYW5uLWNib3ItcGFja2Vk LTAwICZhbXA7IFNVSVQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiAyMDIwLTA3LTI4LCBhdCAxOTox OCwgSmltIFNjaGFhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20i IGNsYXNzPSIiPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpbQnJlbmRhbl0gT25lIG9mIHRoZSBxdWVzdGlvbnMgdGhhdCBJ IGhhdmUgaXMgdGhlIG9yZGVyIG9mIGNvbXByZXNzaW5nIGFuZDxiciBjbGFzcz0iIj4NCjwvYmxv Y2txdW90ZT4NCmFwcGx5aW5nIHNlY3VyaXR5IG9wZXJhdGlvbnMuICZuYnNwO0lmIHlvdSBhcmUg dXNpbmcgYSBwdWxsIHBhcnNlciBkbyB5b3UgdGhpbmsgaXQgaXM8YnIgY2xhc3M9IiI+DQpnb2lu ZyB0byBiZSBlYXNpZXIgKHdlIGNhbiB0YWxrIGFib3V0IG1vcmUgc2VjdXJlIGxhdGVyKSB0byBk byB0aGUgaGFzaGluZyBvbjxiciBjbGFzcz0iIj4NCnRoZSBjb21wcmVzc2VkIG9yIHVuY29tcHJl c3NlZCB2ZXJzaW9uLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldob2EuICZuYnNwO1dl IG5vcm1hbGx5IGhhc2ggYnl0ZSBzdHJpbmdzLjxiciBjbGFzcz0iIj4NClNvIGFyZSB5b3UgcHJv cG9zaW5nIHRoYXQsIHNheSwgYSBjb21wcmVzc2VkIHZlcnNpb24gaXMgcmVjZWl2ZWQsIGl0IGlz PGJyIGNsYXNzPSIiPg0KdW5jb21wcmVzc2VkLCByZS1zZXJpYWxpemVkIGluIGRldGVybWluaXN0 aWMgZW5jb2RpbmcsIGFuZCB0aGVuIGhhc2hlZD88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQo8YnIgY2xhc3M9IiI+DQpCb3RoIHllcyBhbmQgbm8uICZuYnNwO0kgd2FzIHRoaW5raW5nIHRo YXQgdGhlIG9ubHkgdGhpbmcgdGhhdCB3YXMgZ29pbmcgdG8gbmVlZCB0byBiZSByZS1lbmNvZGVk IHdvdWxkIGJlIHByZWZpeGVzIHNvIHRoYXQgc3RyaW5ncyBhcmUgZnVsbHkgdGhlcmUgYW5kIGhh dmUgdGhlIGNvcnJlY3QgdmFsdWUuICZuYnNwO0ZvciBkb2luZyB0aGluZ3MgbGlrZSBzdWJzdHJ1 Y3R1cmUgc3Vic3RpdHV0aW9uLCBJIHdhcyBqdXN0IHJlcGxhY2luZyB0aGUgdGFnIHdpdGggdGhh dA0KIHN1YnN0cnVjdHVyZSBhbmQgcGFzc2luZyBpbiB0aGUgZGF0YSBvZiB0aGF0IHN1YnN0cnVj dHVyZSBhcyBJIHdhcyBkb2luZyB0aGUgZGVjb2RpbmcuICZuYnNwO1RoaXMgaGFzIHRoZSBhZHZh bnRhZ2UgdGhhdCBhbiBlbnRpdHkgY2FuIHNpZ24gYSBzaW5nbGUgcmVwcmVzZW50YXRpb24sIHRo ZSB1bmNvbXByZXNzZWQgdmVyc2lvbiBhbmQgaXQgY2FuIGxhdGVyIGJlIGNvbXByZXNzZWQsIHdp dGggc29tZSByZXN0cmljdGlvbnMgYXJvdW5kIG1hcHMsIGFuZA0KIGJvdGggdmVyc2lvbnMgd291 bGQgdmVyaWZ5LiAmbmJzcDtXaXRoIGF0dGVudGlvbiB0byBkb2luZyBtYXBzLCB0aGF0IGlzIHlv dSBhcmUgdGhlIGJvdGggc2lnbmluZyBhbmQgY29tcHJlc3NpbmcsIHlvdSBjb3VsZCBnZXQgJnF1 b3Q7b3B0aW1hbCZxdW90OyBjb21wcmVzc2lvbiB3aGlsZSBzdGlsbCBoYXZpbmcgYSBzaWduYXR1 cmUgdGhhdCB3b3JrcyBvbiBib3RoIHZlcnNpb25zLjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5NeSBp bnRlbnQgd2FzIHRvJm5ic3A7PGZvbnQgY29sb3I9IiMwMDAwMDAiIGNsYXNzPSIiPnZlcmlmeSBm aXJzdCwgdGhlbiB1bnBhY2suIFRoaXMgaXMgYmVjYXVzZSB0aGUgdW5wYWNrZWQgc3RydWN0dXJl IG5ldmVyIGV4aXN0cywgaW4gaXRzIGVudGlyZXR5LCBpbiBtZW1vcnkuIElmIHlvdSBoYXZlIHRv IHVucGFjayBzdHJhaWdodCBpbnRvIHRoZSZuYnNwO2RpZ2VzdCBhbGdvcml0aG0gaW4gb3JkZXIg dG8gdmVyaWZ5LCB5b3UgaW50cm9kdWNlIGEgVE9DVE9VDQogcHJvYmxlbS4gSWYgeW91IHZlcmlm eSBmaXJzdCwgeW91IGF0IGxlYXN0IGhhdmUgYSZuYnNwO3N0YXRpYywgdmVyaWZpZWQgb2JqZWN0 LjwvZm9udD48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj5UaGlzIGNvdWxkIGJlIGFuIGV2ZW4gaGFyZGVyIHF1ZXN0aW9uIHRvIGFzayB3aXRo IHRoZSB1c2Ugb2YgYW4gZXh0ZXJuYWw8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpkaWN0 aW9uYXJ5LiAmbmJzcDtUaGVyZSBpcyBvbmUgcG90ZW50aWFsIGJlbmVmaXQgdy8gQ09TRSBpbiB0 aGF0IHRoZSBoYXNoIG9mIHRoZTxiciBjbGFzcz0iIj4NCmRpY3Rpb25hcnkgY291bGQgYmUgaW5j bHVkZWQgYXMgZXh0ZXJuYWwgZGF0YS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXY+VGhlIHByb2JsZW0gd2l0aCB0aGlzIGFwcHJvYWNoIGlzIGRpY3Rpb25hcnkgc2VsZWN0aW9u LiBXZSBuZWVkIHNvbWUgd2F5IHRvIGhpbnQgYSBkaWN0aW9uYXJ5IGlkZW50aWZpZXIgaWYgaXTi gJlzIG5vdCBvYnZpb3VzLiBUaGlzIGNvdWxkIGJlIGEgdGFnLCBhbiBlbGVtZW50IGluIHRoZSBU YWcgNiBhcnJheSwgc29tZSBraW5kIG9mIE9PQiBzaWduYWwsIG9yIHNvbWV0aGluZyBlbHNlLjwv ZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPlRoZXJlIGFyZSB0d28gYXNwZWN0cyBoZXJlOjxiciBjbGFzcz0iIj4NCuKAlCBob3cg ZG8gd2UgbWFrZSBzdXJlIHRoZSBleHRlcm5hbCBkaWN0aW9uYXJ5IGNhbm5vdCBiZSBzdXJyZXB0 aXRpb3VzbHk8YnIgY2xhc3M9IiI+DQpleGNoYW5nZWQgYnkgYW4gYXR0YWNrZXIgPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2PlRoaXMgcmVxdWlyZXMgc29tZSBzb3J0IG9mIHNlY3VyaXR5IG1lY2hhbmlz bS4gVXNpbmcgYSBDT1NFIGZlYXR1cmUgdGhhdCBpbmNsdWRlcyBhZGRpdGlvbmFsIGRhdGEgaXMg bm90IGlkZWFsIGluIFNVSVQgYmVjYXVzZSB3ZSBzdXBwb3J0IENPU0VfU2lnbiwgQ09TRV9TaWdu MSwgQ09TRV9NQUMsIG9yIENPU0VfTUFDMCwgb3IgYW55IGNvbWJpbmF0aW9uIHRoZXJlb2YuIFRo aXMgd291bGQgbWVhbiB0aGF0IGEgQ09TRSBmZWF0dXJlIHRoYXQNCiBpbmNsdWRlcyBleHRyYSBk YXRhIHdvdWxkIGJlIGR1cGxpY2F0ZWQgZm9yIGFzIG1hbnkgQ09TRSBvYmplY3RzIGFzIGFyZSBp bmNsdWRlZC4gT2YgY291cnNlLCB0aGF04oCZcyBub3QgcGFydGljdWxhcmx5IHJlbGV2YW50IGlm IHRoZSBsaXN0IG9mIENPU0Ugb2JqZWN0cyBpcyBhbHNvIHVzaW5nIHBhY2tlZCBDQk9SLCBzbyBt YXliZSBpdOKAmXMgZmluZS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 PkluY2x1ZGluZyBhIGRpY3Rpb25hcnkgcmVmZXJlbmNlIGFzIEFBRCBzZWVtcyBmaW5lIHRvIG1l LiBJbiB0aGUgU1VJVCBjYXNlLCBJIHRoaW5rIEkgd291bGQgbWFrZSBpdCBtb3JlIGV4cGxpY2l0 IGJlY2F1c2Ugd2UgbmVlZCB0byBpZGVudGlmeSB3aGljaCBleHRlcm5hbCBkaWN0aW9uYXJ5IHRv IGRpZ2VzdC48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+4oCUIGhvdyBkbyB3 ZSBtYWtlIHN1cmUgdGhlcmUgaXMgYW4gdW5hbWJpZ3VvdXM8YnIgY2xhc3M9IiI+DQp3YXkgdG8g aW50ZWdyYXRlIHRoZSBleHRlcm5hbCBkaWN0aW9uYXJ5Ly1pZXMgaW50byB0aGUgcHJlZml4IGFu ZCBzaGFyaW5nIHRhYmxlcz88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+V2Ug bmVlZCB0byAobG9naWNhbGx5KSBjb25jYXRlbmF0ZSB0aGUgZGljdGlvbmFyaWVzIHRvZ2V0aGVy LiBUaGUgcXVlc3Rpb24gaXM6IHdoaWNoIG9yZGVyPzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXY+RnJvbSBhIHB1bGwgcGFyc2VyIHBlcnNwZWN0aXZlLCBJIHRoaW5rIEkg d291bGQgc3VnZ2VzdCBhIHN0YWNrLWJhc2VkIG1vZGVsOjwvZGl2Pg0KPGRpdj4tIEVhY2ggZGlj dGlvbmFyeSBpcyBhbiBlbGVtZW50IGluIGEgc2luZ2x5IGxpbmtlZCBsaXN0LjwvZGl2Pg0KPGRp dj4tIFdoZW4geW91IGVuY291bnRlciBhIG5ldyBkaWN0aW9uYXJ5LCB5b3UgcHVzaCBpdCBvbnRv IHRoZSBoZWFkIG9mIHRoZSBsaXN0PC9kaXY+DQo8ZGl2Pi0gV2hlbiB5b3UgZmluaXNoIGEgcnVt cCBlbGVtZW50LCB5b3UgcG9wIHRoZSBkaWN0aW9uYXJ5IGFzc29jaWF0ZWQgd2l0aCBpdCBmcm9t IHRoZSBoZWFkIG9mIHRoZSBsaXN0LjwvZGl2Pg0KPGRpdj4tIFdoZW4geW91IGZpbmQgYSBkaWN0 aW9uYXJ5IHJlZmVyZW5jZSBpbiB0aGUgcnVtcCwgeW91IHRyYXZlcnNlIHRoZSBkaWN0aW9uYXJ5 IGxpc3QsIHN0YXJ0aW5nIGF0IHRoZSBtb3N0IHJlY2VudC48L2Rpdj4NCjxkaXY+LSBXaGVuIHlv dSBmaW5kIGEgZGljdGlvbmFyeSByZWZlcmVuY2UgaW4gYSBkaWN0aW9uYXJ5IGVsZW1lbnQsIHlv dSB0cmF2ZXJzZSB0aGUgZGljdGlvbmFyeSBsaXN0LCBzdGFydGluZyBhdCB0aGUgY3VycmVudCBk aWN0aW9uYXJ5LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBo YXMgc2V2ZXJhbCBhZHZhbnRhZ2VzOjwvZGl2Pg0KPGRpdj4tIEl04oCZcyBjb21wYXRpYmxlIHdp dGggaW5jbHVkaW5nIGEgcGFja2VkIENCT1Igb2JqZWN0IGluc2lkZSBhIHBhY2tlZCBDQk9SIG9i amVjdCB3aXRob3V0IHJld3JpdGluZyBhbnkgcmVmZXJlbmNlcy48L2Rpdj4NCjxkaXY+LSBUaGUg ZGF0YSBtb2RlbCBmb3IgZGljdGlvbmFyeSB0cmF2ZXJzYWwgaXMgZmFpcmx5IHNpbXBsZTwvZGl2 Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SXQgaGFzIHNldmVyYWwgZGlzYWR2 YW50YWdlczo8L2Rpdj4NCjxkaXY+LSBSZWZlcmVuY2VzIGhhdmUgaW5jb25zaXN0ZW50IG1lYW5p bmdzIChUYWcgNiAoMSkgZG9lc27igJl0IG1lYW4gdGhlIHNhbWUgZGljdGlvbmFyeSBlbnRyeSBl dmVyeXdoZXJlLiBJdCBwb2ludHMgdG8gZGlmZmVyZW50IGRpY3Rpb25hcmllcyBpbiBkaWZmZXJl bnQgcGxhY2VzKTwvZGl2Pg0KPGRpdj4tIFRoZSBzdGFjayBtb2RlbCByZXF1aXJlcyBzb21lIGtp bmQgb2YgYWxsb2NhdGlvbiBzdHJhdGVneSB0byBrZWVwIHRyYWNrIG9mIHRoZSBkaWN0aW9uYXJp ZXMuPC9kaXY+DQo8ZGl2Pi0gVGhlIGNvbXByZXNzb3IgaGFzIHRvIGJlIGF3YXJlIG9mIHRoZSBk aWN0aW9uYXJpZXMgb2YgcGFja2VkIENCT1Igb2JqZWN0cyBpdCB0cmF2ZXJzZXMgaW4gb3JkZXIg dG8gcGFjayBhbnl0aGluZyB0aGF0IGFwcGVhcnMgd2l0aGluIGFuIGFscmVhZHkgcGFja2VkIENC T1Igb2JqZWN0LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj5Ib3dldmVyLCB0aGlzIG1heSBiZSBuYWl2ZSBhcyB3ZWxsLiBJdCBpbXBsaWVzIHRoYXQgdGhl cmUgaXMgb25seSBhIGxpc3Qgb2YgZGljdGlvbmFyaWVzIHRoYXQgYXBwbGllcyBhdCBhbnkgcG9p bnQsIHJhdGhlciB0aGFuIGEgdHJlZS4gVGhpcyBpcyBwcm9iYWJseSBhY2N1cmF0ZSB3aGVuIGxv b2tpbmcgYXQgbmVzdGVkIHBhY2tlZCBvYmplY3RzLiBJdCBtaWdodCBiZSBtb3JlIG9mIGEgcHJv YmxlbSB3aXRoIGV4dGVybmFsIGRpY3Rpb25hcmllcy48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkkgaGF2ZSBhIGRl c2lnbiBmb3IgdGhlIGxhdHRlciB0aGF0IEkgc3RpbGwgbmVlZCB0byB3cml0ZSB1cC48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpGb3IgdGhlIGZvcm1lciwgYSBDT1NFIGhhc2ggYWxnb3Jp dGhtICsgdGhlIGhhc2ggd291bGQgZG87IHRoZSBkaWN0aW9uYXJ5PGJyIGNsYXNzPSIiPg0Kd291 bGQgYmUgaGFzaGVkIGFzIGFuIGVuY29kZWQgQ0JPUiBkYXRhIGl0ZW0uICZuYnNwO1RoZXJlIGlz IGEgcXVlc3Rpb24gd2hldGhlcjxiciBjbGFzcz0iIj4NCnRoZXJlIHNob3VsZCBiZSBhIHdheSB0 byBwdXQgaW4gYSAoY29tcGFjdCEpIGlkZW50aWZpZXIgZm9yIHRoZSBkaWN0aW9uYXJ5IGFzPGJy IGNsYXNzPSIiPg0Kd2VsbCwgc28gdGhlIGhhc2ggaW4gdGhlIGV4dGVybmFsIGRhdGEgaXNu4oCZ dCBhIHRyYXBkb29yIGZ1bmN0aW9uLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBj bGFzcz0iIj4NClBhcnQgb2YgdGhpcyBpbmNsdWRlcyB0aGUgcXVlc3Rpb24gb2YgaG93IHlvdSBh cmUgZ29pbmcgdG8gaWRlbnRpZnkgdGhlIGRpY3Rpb25hcmllcyBzbyB0aGF0IHlvdSBnZXQgdGhl IHJpZ2h0IG9uZSBpZiB0aGVyZSBhcmUgbXVsdGlwbGUgcG9zc2liaWxpdGllcy4gJm5ic3A7VGhl IGhhc2ggd291bGQgYmUgc29tZXRoaW5nIHRoYXQgY2FuIGJlIHVuaXF1ZSBidXQgd291bGQgbmVl ZCB0byBiZSB2YWxpZGF0ZWQgYnkgdGhlIGRlY29kZXIuPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRo ZSByZXF1aXJlbWVudCBmb3IgYSBoYXNoIGRlcGVuZHMgb24gY29udGV4dC4gV2hlcmUgaXQgaXMg cmVxdWlyZWQsIHRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIGl04oCZcyBleHBsaWNpdCBvciBpbXBs aWNpdC4gTm93LCB3aGF04oCZcyByZWFsbHkgaW50ZXJlc3RpbmcgaGVyZSBpcyB0aGF0IGl0IGNv dWxkIGJlIHBhY2tlZCB0b28uIEVmZmVjdGl2ZWx5LCB3aGF0IEkgbWVhbiBoZXJlIGlzIHRoYXQg aXTigJlzIGxlZ2l0aW1hdGUgdG8gdXNlIHBhY2tlZA0KIENCT1IgdG8gY29tcHJlc3MgYSBDT1NF IG9iamVjdC4gSWYgd2UgdXNlIGFuIGV4dGVybmFsIGRpY3Rpb25hcnkgdG8gY29tcHJlc3MgdGhl IENPU0Ugb2JqZWN0LCBpdCBzZWVtcyBwbGF1c2libGUgdG8gYWRkIGluIGEgZGljdGlvbmFyeSB2 YWx1ZSBmb3IgdGhlIGhhc2ggJmFtcDsgaGFzaCBhbGdvcml0aG0gdXNlZCB0byByZXByZXNlbnQg YSBzZWNvbmQsIG5vbi1DT1NFIGV4dGVybmFsIGRpY3Rpb25hcnkuPC9kaXY+DQo8ZGl2PjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JIHRoaW5rIHRoYXQgZXh0ZXJuYWwgZGljdGlvbmFyaWVz ICpvdXRzaWRlKiBhbiBhdXRoZW50aWNhdGlvbiBvYmplY3QgcHJvYmFibHkgZG9u4oCZdCByZXF1 aXJlIGF1dGhlbnRpY2F0aW9uLCBzaW5jZSB0aGUgYXV0aGVudGljYXRpb24gb2JqZWN0IGl0c2Vs ZiB3aWxsIG5hdHVyYWxseSB2ZXJpZnkgdGhlc2UgZGF0YS4gSG93ZXZlciwgYW55IGV4dGVybmFs IGRpY3Rpb25hcnkgcmVwcmVzZW50ZWQgKmluc2lkZSogYW4gYXV0aGVudGljYXRpb24NCiBvYmpl Y3QgTVVTVCBhbHNvIGJlIGF1dGhlbnRpY2F0ZWQuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdj5JIGNhbiBwcm92aWRlIGEgd29ya2VkLXVwIGV4YW1wbGUgaWYgdGhhdCBt YWtlcyBpdCBjbGVhcmVyLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkJyZW5kYW48L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+SmltPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KR3LDvMOfZSwgQ2Fyc3RlbjxiciBjbGFz cz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KQ0JPUiBtYWlsaW5nIGxp c3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86Q0JPUkBpZXRmLm9yZyIgY2xhc3M9IiI+ Q0JPUkBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Nib3I8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVu dHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRp c2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBw dXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0u IFRoYW5rIHlvdS4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_406B6702304544908CD08E352F924714armcom_-- From nobody Wed Jul 29 10:08:37 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 249953A0D52 for ; Wed, 29 Jul 2020 10:08:34 -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 Wo-A3XUgtual for ; Wed, 29 Jul 2020 10:08:30 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650099.outbound.protection.outlook.com [40.107.65.99]) (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 69EA53A0CE3 for ; Wed, 29 Jul 2020 10:08:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oYUyJznGCd6pLV/k2eyfTzbCf6Sra3X403Al6mtnAv3ErKAcV5WWS1xqL25HBii7Leg8PDjUwSVYBsN/xdZCxNmENAswOtU5Ex6VcgBPe62YwyGRD2IJW3NsI/djRVovgFQ5AOKmXA+GAwJXLgQT9t2dlwkPtE9j2Qhi6AiiNDIgWTjRV0fEOjXbhxsyGRwcY9dDfOVw1VK9Lg8tpIuGgStylLvGDYLfcey/l+8UXRgx+aU2+SrLlnx/A53U54uNjb2pnoIA+qZ38OtIgDJ/pFAbeo4LWbzaHx1tP2dF6t1vRJy2cRhEtL0sZqIgnzL6qBq6Q+hRz55RrfxmjzDhNA== 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=ezw8tng809Vqb5yK78oePqgZSsYtjZAQFDtTZK2E5xM=; b=DvicIgpNzKygRSjkHlxW181R/h6YMRYTkB5N/dx8un+IRGstPVyMGOr2aHRtdXmlz0ABcL7Fz+5jqWQ+t7WUdhcG8tcHSIS/RvedPgdC8JcZH5FScEOgQnQ6I9j22VhYyicM2lLPTG3YLTvrzRmMpLn6BytuizsN6p1OfrKm6XlIFX+gkAGX+arYkua9gh1Nq2jVA+WjKLs7tASd85pfCoZkA5H/2uejC0hnht5quEA54sDKS239xQXjkZNag8C1IJho9CAfAhXSkTeM9HYySjigVO/Ka7nlikaciFyzLi6R3Hy97m6hqcOCECcjbJX9Z6A5sIal9EXmPqKqHpg8RA== 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=ezw8tng809Vqb5yK78oePqgZSsYtjZAQFDtTZK2E5xM=; b=ZmQY7OCkSZs+3aHAyO+vjlbqjRXIFPJTZytqSg1hnGRU5UOUE4hUNdpjMLYrX5lpEJ9bEV2UoOecj5fa8dBYnZ7tBiDWJQZQZimzY1JJtONVlPQhW9NoGNFKgP4BGDhymfaux5PCcsJmCffja3ZXAJx2r8nqJwRaWYfiC5GZDec= 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.3278.0; Wed, 29 Jul 2020 17:08:28 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::e9ce:b982:5ae1:959d]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::e9ce:b982:5ae1:959d%9]) with mapi id 15.20.3281.000; Wed, 29 Jul 2020 17:08:28 +0000 From: Mike Jones To: Carsten Bormann CC: "cbor@ietf.org" Thread-Topic: [EXTERNAL] Re: [Cbor] Packing CBOR (draft-bormann-cbor-packed-00) Thread-Index: AdZlVD2iKwHnZ/QRRCWfZ1kUDxHDlgAEouGAABj4hsA= Date: Wed, 29 Jul 2020 17:08:27 +0000 Message-ID: References: In-Reply-To: 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=0b9a55e6-d6b2-4521-a790-41eaa03c70d7; 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-07-29T17:06:59Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.88.234] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b0641a2f-5f66-4a9f-8e28-08d833e2031d x-ms-traffictypediagnostic: CH2PR00MB0762: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KJhaqfx164sTxN5aVppTUwEEvvmgjDJZXUSht8MZnyn076j0EUU5LTkRjtPgOYC3DsFXidESK2wCgUiFliCF8bzL7eUKYtDA41nIjgBdEuK1Tfz3T5zItLFvX7LIhHUlCmDEa+ICb0QW1Y863hdh30oLE0uZO0FGMvLXFqw2uisuL3i1xSQiNy5bFpw9TxnixRifLIg2GH4tzHfi4RqRCVpe6s1ktFZb9vbzRPJql9Rjg3sB7W24Z4Qrgcrxe4Yjrdw0OAV26KrmPpCC5FAykEQJPoaVxC1ynaS5pI57FteEl8g+sYmxeWcxY6lnvfXdT3sLQFrgOaFjQ011tPmtO9DLV7vaD51+ufuvb4hHVOmwMwLvY/ikixHFuwzOZ5kabBfO8DPOkU/E7WZJAcZu0A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(136003)(39860400002)(396003)(376002)(4326008)(186003)(478600001)(6506007)(53546011)(55016002)(8990500004)(9686003)(10290500003)(7696005)(5660300002)(52536014)(26005)(71200400001)(33656002)(316002)(966005)(82950400001)(82960400001)(66476007)(66556008)(64756008)(66446008)(2906002)(66574015)(83380400001)(76116006)(6916009)(8936002)(86362001)(8676002)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: NCVweb+bPC7dOMfFtc0QciAH6/F30o2KCwa/ClVwnnt/elxSuaO56lq8X/QI3aQLr6PwXMsRVfdTULL2KMHY+nNI+MZ8YFiWeuOH/0FMn7Z2EkJhTnY/9pqC6Lfm78HWIenP/KTu+zyPDOfqB3JrHwfqk9T4e9FU7Dj8P1Uzzf636mteqNZA5Aa2PqWKJlUmC1USC/XxbN99tR1WTSgqxz5YoRASjimk0yGBOWEoegAujBsdgvpfYlLetNbyEuh0e2MH+F+YWNXe5HxfbVhK/SuUQs9nNgl9ma3w1/LUdZL/I7JEcoBiGJaQprdVKijEWiAFHCY5mV4Ao5q1mkmgzrRsbslqDT5Lt0Kw+Ccn34t4tcgyozEKdPg27OdKwDDPa2mtxRAz9ybWvwbvrB/AupKic/D2FZR5kPaO/awM1hlM2CSt1cB64+lnD52SZOhdiKXOa7gRzMcyoMXoFaktpomFetrNXlR3paX4vd0tgmUhcuOp7nL38GzISOFEz4GpnBV6lqoUWmHU91hcxF9MMrsVlYcqvnXjk+voQGe/aEQU6wqsBKRXoB/6f8wLz+DQ+7TyeHAtG/6wluBEsch7Bfv9LYc5xmngaX8gchnyHLYOOus/LQHDkxV8nxRUoevnU2lwVquaE7rwEijwkNrvng== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b0641a2f-5f66-4a9f-8e28-08d833e2031d X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2020 17:08:27.9415 (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: towMpymcDrb/zntw5MNyofQpYZ2MDc6csCCmZ0rdubQha/AcvW6w7tWNnvOFy6YKXO6pwLi2LitLhg7KP6ZGTg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0762 Archived-At: Subject: Re: [Cbor] [EXTERNAL] Re: Packing CBOR (draft-bormann-cbor-packed-00) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 17:08:34 -0000 VGhhbmtzIGZvciB5b3VyIHJlcGx5LCBDYXJzdGVuLiAgSSBoYWRuJ3QgbG9va2VkIGF0IGl0IHRo YXQgd2F5LiAgQXQgc29tZSBwb2ludCBJJ2xsIHRyeSB0byBkbyBhIGZ1bGwgcmV2aWV3IG9mIHRo ZSBkb2N1bWVudC4NCg0KCQkJCUNoZWVycywNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4gDQpTZW50 OiBUdWVzZGF5LCBKdWx5IDI4LCAyMDIwIDEwOjEyIFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KQ2M6IGNib3JAaWV0Zi5vcmcNClN1YmplY3Q6IFtFWFRF Uk5BTF0gUmU6IFtDYm9yXSBQYWNraW5nIENCT1IgKGRyYWZ0LWJvcm1hbm4tY2Jvci1wYWNrZWQt MDApDQoNCk9uIDIwMjAtMDctMjksIGF0IDA0OjU5LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPiANCj4gSSBhbSBjb25jZXJuZWQgdGhhdCB0aGlzIHdp bGwgYmlmdXJjYXRlIENCT1IgaW50byBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBhbmQgZG9uJ3Qg c3VwcG9ydCB0aGlzIGV4dHJhIGZlYXR1cmUgc2V0LiAgDQoNCkhpIE1pa2UsDQoNCnRoYXQgaXMg b2YgY291cnNlIHRydWUgZm9yIGFueSBuZXcgdGFnLg0KV2hlbiB3ZSBkZXNpZ25lZCBDQk9SLCBv bmUgbWFpbiBpc3N1ZSB3YXMgd2hldGhlciB0aGUgZmVhdHVyZSBzZXQgc2hvdWxkIGJlIHN0YXRp YyAoYXMgd2l0aCBKU09OKSBvciBhbGxvdyBleHRlbnNpYmlsaXR5ICh1c2luZyB0aGUgdGFnIGNv bmNlcHQpOyB3ZSBjaG9zZSB0aGUgbGF0dGVyLg0KDQo+IElmIGEgY2FsbCBmb3IgYWRvcHRpb24g d2VyZSBoZWxkIHRvZGF5LCBoYXZpbmcgdGhvdWdodCBhYm91dCBpdCwgSSB3b3VsZCBvcHBvc2Ug YWRvcHRpb24gb24gdGhpcyBiYXNpcy4gIEknZCByYXRoZXIgdGhhdCBhbGwgQ0JPUiBpbXBsZW1l bnRhdGlvbnMgYmUgaW50ZXJvcGVyYWJsZSB0aGFuIGZvciBzb21lIHRvIGFkZCB0aGlzIGZhaXJs eSBjb21wbGljYXRlZCBjb21wcmVzc2lvbiBmZWF0dXJlLg0KDQpQYWNraW5nIGhhcyBiZWVuIGRl c2lnbmVkIHNvIHRoYXQgaXQgY2FuIGJlIHVzZWQgd2l0aCDigJxhbGwgQ0JPUiBpbXBsZW1lbnRh dGlvbnPigJ0gKHRoYXQgZG8gc2VuZCB1bmtub3duIHRhZ3MgdG8gdGhlIGFwcGxpY2F0aW9uKTsg aWYgYSBDQk9SLWJhc2VkIHByb3RvY29sIG9wdHMgZm9yIGFsbG93aW5nIHRoZSB1c2UgcGFja2lu ZywgdGhhdCBpcyB0aGUgc2FtZSBraW5kIG9mIGRlY2lzaW9uIGFzIGZvciBhbGxvd2luZyBkYXRl IHRhZ3MuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KDQoNCj4gDQo+IAkJCQktLSBNaWtlDQo+IA0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDQk9SIDxjYm9yLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJvcm1hbm4NCj4gU2VudDogTW9uZGF5LCBK dWx5IDEzLCAyMDIwIDEyOjQ4IFBNDQo+IFRvOiBjYm9yQGlldGYub3JnDQo+IFN1YmplY3Q6IFtD Ym9yXSBQYWNraW5nIENCT1IgKGRyYWZ0LWJvcm1hbm4tY2Jvci1wYWNrZWQtMDApDQo+IA0KPiBU aGlzIGRyYWZ0IG1heSBzZWVtIGEgYml0IHVudXN1YWwsIGluIHRoYXQgaXQgYWxsb2NhdGVzIDI2 ODQzOTU4NSB0YWdzLCBpbmNsdWRpbmcgb25lIG9mIHRoZSAxMiByZW1haW5pbmcgcHJlY2lvdXMg c2luZ2xlLWJ5dGUgb25lcy4NCj4gQnV0IGlmIHlvdSByZWFkIGl0LCB0aGF0IHdpbGwgc2VlbSBw ZXJmZWN0bHkgbm9ybWFsLg0KPiANCj4gUGxlYXNlIHNlZQ0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9pZC9kcmFmdC1ib3JtYW5uLWNib3ItcGFja2VkLTAwLmh0bWwjbmFtZS1hY2tub3dsDQo+IGVk Z2VtZW50cw0KPiBmb3IgaG93IHRoaXMgY2FtZSB0byBiZS4NCj4gDQo+IEnigJltIGdvaW5nIHRv IGFzayBmb3IgV0cgYWRvcHRpb24gYXQgSUVURiAxMDguLi4NCj4gDQo+IEdyw7zDn2UsIENhcnN0 ZW4NCj4gDQo+IA0KPj4gQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQo+PiANCj4+IEZyb206IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciANCj4+IGRyYWZ0LWJvcm1hbm4tY2Jvci1wYWNrZWQtMDAudHh0DQo+PiBEYXRlOiAy MDIwLTA3LTEzIGF0IDIxOjQyOjIxIENFU1QNCj4+IFRvOiAiQ2Fyc3RlbiBCb3JtYW5uIiA8Y2Fi b0B0emkub3JnPg0KPj4gDQo+PiANCj4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ib3Jt YW5uLWNib3ItcGFja2VkLTAwLnR4dCBoYXMgYmVlbiANCj4+IHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgQ2Fyc3RlbiBCb3JtYW5uIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgDQo+PiByZXBvc2l0 b3J5Lg0KPj4gDQo+PiBOYW1lOgkJZHJhZnQtYm9ybWFubi1jYm9yLXBhY2tlZA0KPj4gUmV2aXNp b246CTAwDQo+PiBUaXRsZToJCVBhY2tlZCBDQk9SDQo+PiBEb2N1bWVudCBkYXRlOgkyMDIwLTA3 LTEzDQo+PiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPj4gUGFnZXM6CQk5DQo+PiBV Ukw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWJvcm1hbm4tY2Jvci1wYWNrZWQtMDAudHh0DQo+PiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm9ybWFubi1jYm9yLXBhY2tlZC8NCj4+IEh0 bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm9ybWFubi1j Ym9yLXBhY2tlZC0wMA0KPj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYm9ybWFubi1jYm9yLXBhY2tlZA0KPj4gDQo+PiANCj4+IEFi c3RyYWN0Og0KPj4gIFRoZSBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENC T1IsIFJGQyA3MDQ5KSBpcyBhIGRhdGEgIA0KPj4gZm9ybWF0IHdob3NlIGRlc2lnbiBnb2FscyBp bmNsdWRlIHRoZSBwb3NzaWJpbGl0eSBvZiBleHRyZW1lbHkgc21hbGwgIA0KPj4gY29kZSBzaXpl LCBmYWlybHkgc21hbGwgbWVzc2FnZSBzaXplLCBhbmQgZXh0ZW5zaWJpbGl0eSB3aXRob3V0IHRo ZSAgDQo+PiBuZWVkIGZvciB2ZXJzaW9uIG5lZ290aWF0aW9uLg0KPj4gDQo+PiAgQ0JPUiBkb2Vz IG5vdCBwcm92aWRlIGFueSBmb3JtcyBvZiBkYXRhIGNvbXByZXNzaW9uLiAgQ0JPUiBkYXRhICAN Cj4+IGl0ZW1zLCBpbiBwYXJ0aWN1bGFyIHdoZW4gZ2VuZXJhdGVkIGZyb20gbGVnYWN5IGRhdGEg bW9kZWxzIG9mdGVuICANCj4+IGFsbG93IGNvbnNpZGVyYWJsZSBnYWlucyBpbiBjb21wYWN0bmVz cyB3aGVuIGFwcGx5aW5nIGRhdGEgIA0KPj4gY29tcHJlc3Npb24uICBXaGlsZSB0cmFkaXRpb25h bCBkYXRhIGNvbXByZXNzaW9uIHRlY2huaXF1ZXMgc3VjaCBhcyAgDQo+PiBERUZMQVRFIChSRkMg MTk1MSkgd29yayB3ZWxsIGZvciBDQk9SLCB0aGVpciBkaXNhZHZhbnRhZ2UgaXMgdGhhdCB0aGUg IA0KPj4gcmVjZWl2ZXIgbmVlZHMgdG8gdW5wYWNrIHRoZSBjb21wcmVzc2VkIGZvcm0gdG8gbWFr ZSB1c2Ugb2YgZGF0YS4NCj4+IA0KPj4gIFRoaXMgc3BlY2lmaWNhdGlvbiBkZXNjcmliZXMgUGFj a2VkIENCT1IsIGEgc2ltcGxlIHRyYW5zZm9ybWF0aW9uIG9mICANCj4+IGEgQ0JPUiBkYXRhIGl0 ZW0gaW50byBhbm90aGVyIENCT1IgZGF0YSBpdGVtIHRoYXQgaXMgYWxtb3N0IGFzIGVhc3kgIA0K Pj4gdG8gY29uc3VtZSBhcyB0aGUgb3JpZ2luYWwgQ0JPUiBkYXRhIGl0ZW0uICBBIHNlcGFyYXRl IGRlY29tcHJlc3Npb24gIA0KPj4gc3RlcCBpcyB0aGVyZWZvcmUgb2Z0ZW4gbm90IHJlcXVpcmVk IGF0IHRoZSByZWNlaXZlci4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+PiBz dWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+PiANCj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+PiAN Cj4+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gQ0JPUiBtYWlsaW5nIGxpc3QNCj4gQ0JPUkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3INCg0K From nobody Wed Jul 29 10:53:45 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C1E3A0D7F for ; Wed, 29 Jul 2020 10:53:43 -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 XiVQqE5jXjt4 for ; Wed, 29 Jul 2020 10:53:40 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17DB73A0D23 for ; Wed, 29 Jul 2020 10:53:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7E65938A16; Wed, 29 Jul 2020 13:33:05 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8WIu1Cc6ySk1; Wed, 29 Jul 2020 13:33:04 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 244A638A14; Wed, 29 Jul 2020 13:33:04 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CEF7535C; Wed, 29 Jul 2020 13:53:36 -0400 (EDT) From: Michael Richardson To: Brendan Moran , Jim Schaad , "cbor\@ietf.org" , Carsten Bormann In-Reply-To: <406B6702-3045-4490-8CD0-8E352F924714@arm.com> References: <5E28C6E2-DFEC-4AF5-96CE-75E8F0927818@arm.com> <01d901d66503$2bbd93c0$8338bb40$@augustcellars.com> <7216D806-3473-463E-B6F2-AD8724AC56C6@tzi.org> <021e01d66535$57827d90$068778b0$@augustcellars.com> <406B6702-3045-4490-8CD0-8E352F924714@arm.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] Review: draft-bormann-cbor-packed-00 & SUIT X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 17:53:44 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable {please note that this converation is incomprehensible unless you render the HTML, so the archives are be useless. I feel that this thread should be in the SUIT WG too, but I won't CC because catching up will be hard} Brendan Moran wrote: > My intent was to verify first, then unpack. This is because the > unpacked structure never exists, in its entirety, in memory. If you > have to unpack straight into the digest algorithm in order to verify, > you introduce a TOCTOU problem. If you verify first, you at least have > a static, verified object. I agree. I would write the encoder "sign the packed structure" (so decoder we verify first, then unpack...) I like this because it means: a) a third party can verify the signature without having the dictionaries. Clearly it can't audit the contents without the external dictionar(y/ies= ). b) at this point in the specification I'm unclear if multiple passes of the unpacked content is required. But, if we did want to permit such self-referential things, the decoder could wind up decoding infinite things. Such a thing ight be a desireable feature! We could accomodate such a thing if with sign the packed structure, because the decoder would know it's authentic before it tried to expand. > This could be an even harder question to ask with the use of an exter= nal > dictionary. There is one potential benefit w/ COSE in that the hash = of the > dictionary could be included as external data. i.e. it could go into the protected bucket. > The problem with this approach is dictionary selection. We need some > way to hint a dictionary identifier if it=E2=80=99s not obvious. This= could be > a tag, an element in the Tag 6 array, some kind of OOB signal, or > something else. I think it needs to be in the tag 6 array. cabo> There are two aspects here: cabo> =E2=80=94 how do we make sure the external dictionary cannot be s= urreptitiously cabo> exchanged by an attacker > This requires some sort of security mechanism. Using a COSE feature > that includes additional data is not ideal in SUIT because we support > COSE_Sign, COSE_Sign1, COSE_MAC, or COSE_MAC0, or any combination > thereof. This would mean that a COSE feature that includes extra data > would be duplicated for as many COSE objects as are included. Of > course, that=E2=80=99s not particularly relevant if the list of COSE = objects is > also using packed CBOR, so maybe it=E2=80=99s fine. > Including a dictionary reference as AAD seems fine to me. In the SUIT > case, I think I would make it more explicit because we need to identi= fy > which external dictionary to digest. cabo> =E2=80=94 how do we make sure there is an unambiguous cabo> way to integrate the external dictionary/-ies into the prefix and= sharing tables? > We need to (logically) concatenate the dictionaries together. The que= stion is: which order? > From a pull parser perspective, I think I would suggest a stack-based= model: > - Each dictionary is an element in a singly linked list. > - When you encounter a new dictionary, you push it onto the head of t= he list > - When you finish a rump element, you pop the dictionary associated > with it from the head of the list. > - When you find a dictionary reference in the rump, you traverse the > dictionary list, starting at the most recent. > - When you find a dictionary reference in a dictionary element, you > traverse the dictionary list, starting at the current dictionary. Implying that dictionaries can be created that are self-referential, and can blow up to infinite data streams :-) Unless you mean that dictionaries should be sorted so that they always (can= only) reference forward, and you can start at the current location in the current dictionary. > This has several advantages: > - It=E2=80=99s compatible with including a packed CBOR object inside = a packed > CBOR object without rewriting any references. > - The data model for dictionary traversal is fairly simple I agree. > It has several disadvantages: > - References have inconsistent meanings (Tag 6 (1) doesn=E2=80=99t me= an the > same dictionary entry everywhere. It points to different dictionaries > in different places) > - The stack model requires some kind of allocation strategy to keep > track of the dictionaries. It's a stack of pointers. It can point at the in-band dictionary which can be processed by a pull-parser. Or at an out-of-band dictionary which is probably in "ROM" in some convenient format (probably CBOR map) > - The compressor has to be aware of the dictionaries of packed CBOR > objects it traverses in order to pack anything that appears within an > already packed CBOR object. In the SUIT case, the compressor is "cloud" :-) > However, this may be naive as well. It implies that there is only a > list of dictionaries that applies at any point, rather than a > tree. This is probably accurate when looking at nested packed > objects. It might be more of a problem with external dictionaries. > I think that external dictionaries *outside* an authentication object > probably don=E2=80=99t require authentication, since the authenticati= on object > itself will naturally verify these data. However, any external > dictionary represented *inside* an authentication object MUST also be > authenticated. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8ht6AACgkQgItw+93Q 3WXEnAf8CNprLgNIGQdwshrjgnDeoFxXTvks1+W3qjQli55WpUo9xMyVAxoYoa5W w65Hqkb/bUcWlRtwk18uIBr4apJDM54BXxbNYfx3zYHMk4qblacZY5jO+qe+Pfe8 JdkmIXrFvFgPqEJDgXg7H7iUBogcvjezwvX0QIQSVfbfkuH5bs7mw5eg2XPz8Fbj NL915tsBZ6MO608QiJVQzw9WDvkLxVyCftuz+IStniSBwoY1VlcQdD0PhABk5R91 O1Vo6egzp5vj8juiP/cxheBI5XhS09K2Xc3dm67+Qmd4nyir0pDRTqQJO8BPWSeU c+lF8lTJYOJeLY/FmkugP6FmPiezkw== =TwTl -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 29 10:56:21 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 4B12E3A0DAF for ; Wed, 29 Jul 2020 10:56:20 -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 OqhvSB-WRHj9 for ; Wed, 29 Jul 2020 10:56:19 -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 BA62D3A0DAC for ; Wed, 29 Jul 2020 10:56:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8A6FB38A16 for ; Wed, 29 Jul 2020 13:35:44 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hMQ_uo_xHEoO for ; Wed, 29 Jul 2020 13:35:43 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4E1E338A14 for ; Wed, 29 Jul 2020 13:35:43 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0799E35C for ; Wed, 29 Jul 2020 13:56:16 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cbor] "ordered hash" X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 17:56:20 -0000 --=-=-= Content-Type: text/plain Do we have a canonical term for an array of tuples that behaves like a map, but isn't, because it's an ordered array of 2*n elements? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8huD8ACgkQgItw+93Q 3WVOKAf6Ao1d9w/2CBmBSNfF+5V/OLEKZwMbbWQwUealJzDX5R7hvdlmHXTVT05c FoRsSKeTN999NL6jFCE8j5dgo4IpdyPodoHYA6a3y+PrfX/2vtU017pMkdE+tSzd Xa3QWwUCBWMwPq7gFHJXOCxrhjJy9zpMmPyjZ86fyTUHG2rawT5fKYH7SlTdfmTO ECvxGo7YwG3WEewbRkMAQrJYx4MgOSY94Yr+RYeusQ9xjo1f7oB9/hPehK8xt2Mw IZtt1ehuFWZKMEHnQvICFuBvXPGuuHxtuaNu/bCxvjhg55sU7cGF5qjwmOp8APu3 W9G6zO4UVgXRnQwxtD1n6GwA/fCLmg== =V5ww -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 29 15:38: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 B569C3A08CF for ; Wed, 29 Jul 2020 15:37:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=u2TDE0Ys; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=u2TDE0Ys 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 0ZSNFhCGq5tz for ; Wed, 29 Jul 2020 15:37:56 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60087.outbound.protection.outlook.com [40.107.6.87]) (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 CCF243A08CD for ; Wed, 29 Jul 2020 15:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2I+Bys42cesnfvgd820sx53Vx1c89eC97gNxCg27RXE=; b=u2TDE0Ys7Bti+DO9AetBhIU2qfJVMioRLMpmR7RH/64REtqACOYAX6GVHKJYXrzFtt5JOA1TEQnlnqUpof+YJfcL1zRh6hIjxQxWDR9/0wZhxnLE/crmvly9NtdpRronGZrLS5NvGTxpHhGxcwHbx8mzFtwbXZjHbKgVa3N9Smw= Received: from AM5PR0601CA0064.eurprd06.prod.outlook.com (2603:10a6:206::29) by DB8PR08MB4185.eurprd08.prod.outlook.com (2603:10a6:10:aa::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Wed, 29 Jul 2020 22:37:53 +0000 Received: from AM5EUR03FT029.eop-EUR03.prod.protection.outlook.com (2603:10a6:206:0:cafe::ac) by AM5PR0601CA0064.outlook.office365.com (2603:10a6:206::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Wed, 29 Jul 2020 22:37:53 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT029.mail.protection.outlook.com (10.152.16.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.10 via Frontend Transport; Wed, 29 Jul 2020 22:37:53 +0000 Received: ("Tessian outbound 73b502bf693a:v62"); Wed, 29 Jul 2020 22:37:53 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: a2972b1345164701 X-CR-MTA-TID: 64aa7808 Received: from efe2d45e26c5.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 0E3934EA-2999-4392-9815-30344BC0FC50.1; Wed, 29 Jul 2020 22:37:48 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id efe2d45e26c5.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 29 Jul 2020 22:37:48 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UrUYW+ojRzbNZjN67ECvJHmZETcVodnL6d/xdnCw6O2P+nNrdun9E+HBj37BI9Yj4Fj8XvtEIQTme/y6rXfUci95FRFoWHVCuZphhFej3344HihItS57zb2JNohOSgaWX/ieSZRaFrFCxE6eD7a2IySugjmGWISf3fXB08hnmmDRrS3E1FMX5Ay6jJNC97tjyW70PlqIzOQnRBz7vdXtoYptesY4NCadboNspyJYC2N0QYi5BJpki1wCKwNM804ZbQg8zEZfQgujDV17FtaJSTMN1KrAZNMMhGG9vJwZc5YGohPKB4uOefLBQEEiLknsSdrcyE1zPwukn5u2v9sJhQ== 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=2I+Bys42cesnfvgd820sx53Vx1c89eC97gNxCg27RXE=; b=iajZ1uU7ui2/cNauJvxf4w4mi1JiPh1UsWjh5icucOcQRe6DaMrwffS2Jsp12blFGKY0YBHzO2kozHZWeye+/s/SnFIJQ68To/4OPiwNAPU9hDHUnyiOw+gtfnnIaKVbjlt+7QsisO/Iap+NsIYG6Y8gSx9T/yh/l+zqnEOCMwlxNdKrFXeQ6nVIeolPRFs9c26hpLpZCXRgfCDBAzsK7VuziZRgrxRnoioOk76kqkUcxWCuIxri62lVtVz2XiRCnokxn4w6L3hya+Dpeg4zMLb1I31xV9dQOO9wYSh7BpJ2w49EHkHi4s4w1Pzusj+rqAsxEdQuHUNa6tJHAe6jcQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2I+Bys42cesnfvgd820sx53Vx1c89eC97gNxCg27RXE=; b=u2TDE0Ys7Bti+DO9AetBhIU2qfJVMioRLMpmR7RH/64REtqACOYAX6GVHKJYXrzFtt5JOA1TEQnlnqUpof+YJfcL1zRh6hIjxQxWDR9/0wZhxnLE/crmvly9NtdpRronGZrLS5NvGTxpHhGxcwHbx8mzFtwbXZjHbKgVa3N9Smw= Received: from VE1PR08MB4749.eurprd08.prod.outlook.com (2603:10a6:802:b1::21) by VE1PR08MB4975.eurprd08.prod.outlook.com (2603:10a6:803:10d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Wed, 29 Jul 2020 22:37:46 +0000 Received: from VE1PR08MB4749.eurprd08.prod.outlook.com ([fe80::f40a:a75b:87e1:f1c4]) by VE1PR08MB4749.eurprd08.prod.outlook.com ([fe80::f40a:a75b:87e1:f1c4%6]) with mapi id 15.20.3216.034; Wed, 29 Jul 2020 22:37:46 +0000 From: Brendan Moran To: Michael Richardson CC: "cbor@ietf.org" Thread-Topic: [Cbor] "ordered hash" Thread-Index: AQHWZdGZtxe2BYNBXkebVxN3x4o0LakfJh6A Date: Wed, 29 Jul 2020 22:37:46 +0000 Message-ID: References: <25163.1596045376@localhost> In-Reply-To: <25163.1596045376@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) Authentication-Results-Original: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.20.19.206] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: f5744dd9-e192-4b26-cb91-08d83410082b x-ms-traffictypediagnostic: VE1PR08MB4975:|DB8PR08MB4185: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:4303;OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: UV4lxevbJtPSFU9YRwgnOeQA5pYdDhmmRd+wHSPd/yV7bUffeqhgnbeu82G+Fucb5siACug49bsLmPHokkDIo/wxivBW55F5Jf/wY9jzsbEZvROPBxyIHrD89BNpniRkiqdWF6LcCQHhFlCm7o2hQS4x8kbJVZWlUU5ybpJ0p0EXCHg033jJreqKbC1Vh2tqk02e+0gY467xHgmsaw6CMw41JcqrXrnKFdxKTH+Z9V4M/nv/H8ZZFGDQtHbPEm4ve87rPiRP7JwHfuM3ISYmzZSlDfaTcEzOwLfndqB7+IeZy5O0SIuX21lYdlENYXFNYEnqOsQ4hBzJsBqSGoHkZ4AC5d6u4V6ENg73P4Rs9aGc2tfaSWH3Jl4+fwG1CV84bIta5PS78U329h8IeSfeGw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VE1PR08MB4749.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(366004)(376002)(136003)(396003)(6512007)(8676002)(8936002)(6486002)(86362001)(83380400001)(33656002)(4326008)(2616005)(5660300002)(4744005)(71200400001)(91956017)(6506007)(53546011)(2906002)(66476007)(66946007)(966005)(26005)(316002)(186003)(36756003)(64756008)(66446008)(66556008)(76116006)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ueZABDLTi8pEuXuVlMx6TWK4Cdvmqjo++oHOYckHExQY9MB1Ql0Zg2j2MmKbUWZX1XCMRXubN57P1wgV0la0G9KOL7EdZjMn6EwS4L6IQLvVHK+UL8HJHr3BKaT5lXINy1xXObgn1D2VLYj0fudvwhW0d97+tgRP8FlNHBfl+gAagTZMr8lWog8eOvOKcldgL3Ng/wGSvCB9LSVPzXlSt1kA7FZWmWDfuyoUqhY6PME7e5rOwE7XmognfZQwEjK8eYRgJ6HlC3PEeThbYCBSWiQy1+YGT7/pIX1NgtbpMI769GV3chE1d0Kg1Od1ezaIuizhkQPVT0Y+6lAxn0ntXFht8KHBADOXZ4bZqCjhdcXwETnhUhvk9VMy3SobiQLJyiNB3Ino6YiJ9B6W4eFKQrEmjId7FpizDf9pwMBEexY/V5fJ3IgYVkJHW6unKsybkzV83jyJ5o5Hzjx3ycQjOs0Ys28VMkF4Rjs5Zo6MwOeuuNfEOgg2AULXYP4+IPgZJg5mMcjuRoD09WupliQpLh0fApuXYhNL5CrqeK2WGsDu5uAeUsBYU9sfgvhGWeR2Q3v+Dz2wR0uW68kYacsQ0s/nGcGkQI2npM1f6MM1Ct2BY7zaP0c5o91lvLhYynQMfbNjKROFDgX3a1nb2uQSww== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <543CF220F99764449A504BA48D2A4AB0@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB4975 Original-Authentication-Results: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT029.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: bb29fe3d-3972-42b3-cbaa-08d834100400 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MfEqtxOErI2oov86tMY3ePXb+WYq3nbCXpxDLPVFoLEwaUH5T1SKQjwRGOWGWXAafGYWQYqtp83UEIqUbPs2Kwr7ve/tuj2z6PoOAmASwJN8HjLUPHUlVd1acH5t24iCbFe4Kd3BQigBFqD3oyLDhgUQ2FmVqsNlxyiASC6nE62i1xoPUq/YBKGDGvljb80qYdBc10h3NEj0hmOhsGKEuKpoCsT0gXq7BrAI47izfQhQ7/KcL3M3PLMonOdgy/4flR+v48s12k3vKnkB7iQ6VL2VlhLYyzCTuu+9ISPierGWeMnkqBvyfdHB8ctHaI54uOdk00xQiqRnRyVhKd78HrZDIUCzh//68LblW5tPrqEiFufl9VrThfd0mqNwCVP9C1gWzHBMCoXIC8hngdL7vSbLZY5zDZ/wtpkxWekkXgrvAF1tYHCEV3mmbAW3JVEn6JongMezqmicPUhfbgnTRvXNKQn4Wt8QUIMVbMyDB1s= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(136003)(39860400002)(396003)(46966005)(33656002)(36756003)(70586007)(26005)(70206006)(6862004)(2616005)(186003)(6512007)(478600001)(53546011)(6506007)(82740400003)(47076004)(82310400002)(86362001)(316002)(36906005)(5660300002)(81166007)(966005)(356005)(336012)(6486002)(2906002)(4326008)(8676002)(8936002)(83380400001)(4744005); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2020 22:37:53.3594 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f5744dd9-e192-4b26-cb91-08d83410082b X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT029.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB4185 Archived-At: Subject: Re: [Cbor] "ordered hash" X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 22:37:59 -0000 SeKAmWQgcHJvYmFibHkgY2FsbCBpdCBhIG11bHRpLW1hcCBpZiBpdCB3ZXJlIHNvcnRlZC4gUGVy aGFwcyBpdOKAmXMgYW4gb3JkZXJlZCBtdWx0aS1tYXA/DQoNCkJyZW5kYW4NCg0KPiBPbiAyOSBK dWwgMjAyMCwgYXQgMTg6NTYsIE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFu LmNhPiB3cm90ZToNCj4NCj4NCj4gRG8gd2UgaGF2ZSBhIGNhbm9uaWNhbCB0ZXJtIGZvciBhbiBh cnJheSBvZiB0dXBsZXMgdGhhdCBiZWhhdmVzIGxpa2UgYSBtYXAsIGJ1dA0KPiBpc24ndCwgYmVj YXVzZSBpdCdzIGFuIG9yZGVyZWQgYXJyYXkgb2YgMipuIGVsZW1lbnRzPw0KPg0KPiAtLQ0KPiBN aWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0 d2FyZSBXb3Jrcw0KPiAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQo+DQo+DQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENCT1IgbWFpbGlu ZyBsaXN0DQo+IENCT1JAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jYm9yDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVt YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUg cHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0 b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Wed Jul 29 15:46: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 E1B153A08FA for ; Wed, 29 Jul 2020 15:46:10 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=88Fuhq3D; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=88Fuhq3D 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 KwBBKJqeQS9D for ; Wed, 29 Jul 2020 15:45:57 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2062.outbound.protection.outlook.com [40.107.20.62]) (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 164283A08E6 for ; Wed, 29 Jul 2020 15:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yKfFjmL1tRKNGJ/krV2btjSgOT4yaDBVnOfOcT5jFW0=; b=88Fuhq3DS0ULbBrH0uEvRmwAXISwY2IQqWG7tcd8lfcjH8xAMYt6ZgZwHJoyTiKEClWEyJMjqwWnKlX2O94fsuy3ooX16ENkQmKxNviftmvQ/c2PMN4/9lztLrnP/BDpgl1DP3OoUv/rreNkOYlShaBDJwwmypdclfouJqk/JX8= Received: from AM5PR0201CA0012.eurprd02.prod.outlook.com (2603:10a6:203:3d::22) by DB7PR08MB3049.eurprd08.prod.outlook.com (2603:10a6:5:1d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Wed, 29 Jul 2020 22:45:53 +0000 Received: from VE1EUR03FT010.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:3d:cafe::95) by AM5PR0201CA0012.outlook.office365.com (2603:10a6:203:3d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Wed, 29 Jul 2020 22:45:53 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT010.mail.protection.outlook.com (10.152.18.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.10 via Frontend Transport; Wed, 29 Jul 2020 22:45:52 +0000 Received: ("Tessian outbound c4059ed8d7bf:v62"); Wed, 29 Jul 2020 22:45:52 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 4182083ce3df85da X-CR-MTA-TID: 64aa7808 Received: from 91f5372b1b76.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 053BA45D-8C20-44F4-B132-708885204EA2.1; Wed, 29 Jul 2020 22:45:47 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 91f5372b1b76.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 29 Jul 2020 22:45:47 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e6K7XeiSgpq20JJ4Ht1IgSFAHZ9ViiSqVI2y5Dz0DTLponGOzTyJ9PgVK3XvigvQ6GUDLld09X8vR2KRWFRgpLKeoWvspKrBosVg3c1E1goB6gf0MRz0OgEHzo58GddAwiS+Rl52iW6fDg0jsE3+dX3RZgpYyJHHBTcOv9k/vBYfIP/K4E2/1hR/+M7bP+IuanJ2QJkOCzs+bh1M/TrP0BWD8x63CxtEZz8QU4/GC9qxE1spmcdYx5UyWdeZSJ9CqnEIFv5lV+XqqbiNygIZgim1uuw+Q15lW8ZZNOv3dNFfoxBf9uo1L7NxFVmZLDQGAmZOpAEMrh5MpS4dtlID/w== 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=yKfFjmL1tRKNGJ/krV2btjSgOT4yaDBVnOfOcT5jFW0=; b=ICOprZEpferpTnhYuxyalFYy81uuDbQ8m9jt3j2QfbKkTY+IiETbAPOzabEuZl2WPA8YHfBAB4T2OEQMy3qy//PYA50lbXiRJip2Xp1xMhqdnsq+nzCy6kBzTUGJwjDlNtb07Gbi74n8m/yZk4r3npX5+W6yG1Myv1mqYawI7w3nucjAZiaZ4ZWFjTsDgFndbz9Oj3tPqJgahq+kFJpQv2axDNXPL5FKz/3BcXd5rcs86dL03kQlI9k3J5wIWxPKL/Yns1D1nwqS/R8VMkqxeu3Bv8aov/RpXE6ctCL2Q6E5sM11iA4cA0HIoxYa3GpHP8zx64sW7QGFIg++TG7qcQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yKfFjmL1tRKNGJ/krV2btjSgOT4yaDBVnOfOcT5jFW0=; b=88Fuhq3DS0ULbBrH0uEvRmwAXISwY2IQqWG7tcd8lfcjH8xAMYt6ZgZwHJoyTiKEClWEyJMjqwWnKlX2O94fsuy3ooX16ENkQmKxNviftmvQ/c2PMN4/9lztLrnP/BDpgl1DP3OoUv/rreNkOYlShaBDJwwmypdclfouJqk/JX8= Received: from VE1PR08MB4749.eurprd08.prod.outlook.com (2603:10a6:802:b1::21) by VI1PR08MB3584.eurprd08.prod.outlook.com (2603:10a6:803:88::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Wed, 29 Jul 2020 22:45:45 +0000 Received: from VE1PR08MB4749.eurprd08.prod.outlook.com ([fe80::f40a:a75b:87e1:f1c4]) by VE1PR08MB4749.eurprd08.prod.outlook.com ([fe80::f40a:a75b:87e1:f1c4%6]) with mapi id 15.20.3216.034; Wed, 29 Jul 2020 22:45:45 +0000 From: Brendan Moran To: Michael Richardson CC: "cbor@ietf.org" , Jim Schaad , Carsten Bormann Thread-Topic: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT Thread-Index: AQHWZPM7PSkNaZ82xkeO03LjqC3Ah6kdPGyAgABBsICAACKngIAA30mAgABYagCAAFGhgA== Date: Wed, 29 Jul 2020 22:45:45 +0000 Message-ID: References: <5E28C6E2-DFEC-4AF5-96CE-75E8F0927818@arm.com> <01d901d66503$2bbd93c0$8338bb40$@augustcellars.com> <7216D806-3473-463E-B6F2-AD8724AC56C6@tzi.org> <021e01d66535$57827d90$068778b0$@augustcellars.com> <406B6702-3045-4490-8CD0-8E352F924714@arm.com> <24543.1596045216@localhost> In-Reply-To: <24543.1596045216@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) Authentication-Results-Original: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.20.19.206] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: de26b6ac-83eb-4e0c-0f13-08d834112618 x-ms-traffictypediagnostic: VI1PR08MB3584:|DB7PR08MB3049: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: zKzPLoUj02xLD4A75DHI3ScIMJ9vNO8rS5RgRRLMvnTIZFhzO8RbSYKsRzLdZ0/TRp5iY+7fQw8/QhwlcZ6wTjhVJPKWeRNAbDF5m/TICO1csT+rN1LZCmJxnZO8iLUjI2ip34sb3ruj8LezUdcH9nlxJevwP4UzgHoxcPUak5Ln94x06IB3lzJTk6Gd0Dz75b095zl7Y6w+/ZphuB6Hq/8GzLazrIX03jSmcN5KCibuTHLeICN11gIgw+D3JT1UFtC/6jn/33oSXadx2ya1w8j90ggF1dxBbaa2eFEMDZB5PhZxCV2PY5b90Jk1F7MhZnewWWYn89kp1gzeMCoBUawBojgGKLtReJD1ytjFjx+mUZ+4aYzCtWqOH0ARSOj3e/vee6ay0tu7qUmDfq8YpA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VE1PR08MB4749.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(376002)(346002)(366004)(39860400002)(478600001)(66556008)(66446008)(66476007)(186003)(8676002)(6486002)(66946007)(64756008)(8936002)(33656002)(4326008)(76116006)(91956017)(2906002)(26005)(5660300002)(6506007)(53546011)(36756003)(83380400001)(54906003)(6512007)(2616005)(71200400001)(966005)(86362001)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 8MzoOaJLuWO9nRltW2O6LLvZoWhiEQ76tESUsHQ7Fd2hzT6Pug7SXuK8tUTy/nGXYgJ50t61Paa40LYvzCwcoeXlMm9+kOeGZnxbWfOAgFanCWgrKI/PPT6efuV9rvOPGB9r4ZDmjKqQ9p2OQngm4f+BjiOGVD3eIUJ7lAihutVRcpNWDzKswoPhtz3YAvbek4uJObjV728dksNGUkO9UHhT2dzIiC7zl7Ps7oMliRlSxOjPIBZDlbatar4bm2QBsGhqv1QAEsIg3RB3jA+Ob6f0FixdLzuyH043/IJ8rHDCydRxoDpB6xf/SMkfjepu+fWslGqbyflSFBPMF5ai1TPu8wKqJJOMesWS1XnidyyWHeixToYeWDxrU/gE8ytQvCHwLF9Np9GP5R8XcYtfd6LUqh8yLvbiRMnHfPBEsDpKDqvM2En+qtjzBQqLY2CKfQasY+0YLScXgEc7oBFol2F1VjWK5CAhUYG4DsuGN0U= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7701804DD5A742408AA3D811BF502A99@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3584 Original-Authentication-Results: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT010.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: d85103d1-3c08-4fff-5a92-08d8341121b5 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IiTXBvIeei5b8UeYfZYTAJUr4uvS5H6d6k0WB5psH1te25YQoNVWFB76npdvf22CpF3z9SQ8XrynmP4RiavGqKO/lFfUyPN74IDAhGYpIuJ/WUjXMElWZR8DoNWnuPqBKLv6c/suXb4D+ZzTCuadyFH4ZE2aTDc6t/aTyF8NZDcGT+YNDskArM0xHwmaAcmDMLANHWdmAV51JrTt8CSLpRmOLEQYvfZZdWeSgDfGsOCxkPBudVEljOOmu986j6I8Bfb3q8SLLjsfY9A+omjPOtoJaD0dJcB1F3OuqxQqa+Q5XUw0sNswOKfodNeqY9G1VjSxSR67TjLALa0kWBdTkko87DPbhDTDjXyvBnDZj3474+0IHXLcVXvDXz+AfXyTICtaT3W8sxGFDWxFeRsy4Ct65zTc8zM8woca5oT07p9FV61yEcrj0XH7t8Ec84fAV37OVHi1djJ3kLHx/vaJlGWh+W+kxCvtBIrweMNvg2Q= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(376002)(136003)(396003)(46966005)(336012)(83380400001)(2616005)(36756003)(6486002)(4326008)(6512007)(53546011)(6506007)(26005)(186003)(54906003)(966005)(6862004)(2906002)(478600001)(36906005)(316002)(8936002)(81166007)(8676002)(70206006)(70586007)(356005)(86362001)(82310400002)(47076004)(82740400003)(33656002)(5660300002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2020 22:45:52.9645 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: de26b6ac-83eb-4e0c-0f13-08d834112618 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT010.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3049 Archived-At: Subject: Re: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 22:46:11 -0000 DQoNCj4gT24gMjkgSnVsIDIwMjAsIGF0IDE4OjUzLCBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitp ZXRmQHNhbmRlbG1hbi5jYT4gd3JvdGU6DQo+DQo+DQo+IEJyZW5kYW4gTW9yYW4gPEJyZW5kYW4u TW9yYW5AYXJtLmNvbT4gd3JvdGU6DQo+PiBNeSBpbnRlbnQgd2FzIHRvIHZlcmlmeSBmaXJzdCwg dGhlbiB1bnBhY2suIFRoaXMgaXMgYmVjYXVzZSB0aGUNCj4+IHVucGFja2VkIHN0cnVjdHVyZSBu ZXZlciBleGlzdHMsIGluIGl0cyBlbnRpcmV0eSwgaW4gbWVtb3J5LiBJZiB5b3UNCj4+IGhhdmUg dG8gdW5wYWNrIHN0cmFpZ2h0IGludG8gdGhlIGRpZ2VzdCBhbGdvcml0aG0gaW4gb3JkZXIgdG8g dmVyaWZ5LA0KPj4geW91IGludHJvZHVjZSBhIFRPQ1RPVSBwcm9ibGVtLiBJZiB5b3UgdmVyaWZ5 IGZpcnN0LCB5b3UgYXQgbGVhc3QgaGF2ZQ0KPj4gYSBzdGF0aWMsIHZlcmlmaWVkIG9iamVjdC4N Cj4NCj4gSSBhZ3JlZS4gIEkgd291bGQgd3JpdGUgdGhlIGVuY29kZXIgInNpZ24gdGhlIHBhY2tl ZCBzdHJ1Y3R1cmUiDQo+IChzbyBkZWNvZGVyIHdlIHZlcmlmeSBmaXJzdCwgdGhlbiB1bnBhY2su Li4pDQo+DQo+IEkgbGlrZSB0aGlzIGJlY2F1c2UgaXQgbWVhbnM6DQo+IGEpIGEgdGhpcmQgcGFy dHkgY2FuIHZlcmlmeSB0aGUgc2lnbmF0dXJlIHdpdGhvdXQgaGF2aW5nIHRoZSBkaWN0aW9uYXJp ZXMuDQo+ICBDbGVhcmx5IGl0IGNhbid0IGF1ZGl0IHRoZSBjb250ZW50cyB3aXRob3V0IHRoZSBl eHRlcm5hbCBkaWN0aW9uYXIoeS9pZXMpLg0KPg0KPiBiKSBhdCB0aGlzIHBvaW50IGluIHRoZSBz cGVjaWZpY2F0aW9uIEknbSB1bmNsZWFyIGlmIG11bHRpcGxlIHBhc3NlcyBvZiB0aGUNCj4gIHVu cGFja2VkIGNvbnRlbnQgaXMgcmVxdWlyZWQuICBCdXQsIGlmIHdlIGRpZCB3YW50IHRvIHBlcm1p dCBzdWNoDQo+ICBzZWxmLXJlZmVyZW50aWFsIHRoaW5ncywgdGhlIGRlY29kZXIgY291bGQgd2lu ZCB1cCBkZWNvZGluZyBpbmZpbml0ZQ0KPiAgdGhpbmdzLiAgU3VjaCBhIHRoaW5nIGlnaHQgYmUg YSBkZXNpcmVhYmxlIGZlYXR1cmUhDQo+ICBXZSBjb3VsZCBhY2NvbW9kYXRlIHN1Y2ggYSB0aGlu ZyBpZiB3aXRoIHNpZ24gdGhlIHBhY2tlZCBzdHJ1Y3R1cmUsDQo+ICBiZWNhdXNlIHRoZSBkZWNv ZGVyIHdvdWxkIGtub3cgaXQncyBhdXRoZW50aWMgYmVmb3JlIGl0IHRyaWVkIHRvDQo+ICBleHBh bmQuDQoNClRoZSBvcmlnaW5hbCBzcGVjaWZpY2F0aW9uIHByb2hpYml0cyBsb29wcywgYnV0IGxl YXZlcyB0aGUgaW1wbGVtZW50YXRpb24gdXAgdG8gdGhlIHJlYWRlci4NCg0KPj4gVGhlIHByb2Js ZW0gd2l0aCB0aGlzIGFwcHJvYWNoIGlzIGRpY3Rpb25hcnkgc2VsZWN0aW9uLiBXZSBuZWVkIHNv bWUNCj4+IHdheSB0byBoaW50IGEgZGljdGlvbmFyeSBpZGVudGlmaWVyIGlmIGl04oCZcyBub3Qg b2J2aW91cy4gVGhpcyBjb3VsZCBiZQ0KPj4gYSB0YWcsIGFuIGVsZW1lbnQgaW4gdGhlIFRhZyA2 IGFycmF5LCBzb21lIGtpbmQgb2YgT09CIHNpZ25hbCwgb3INCj4+IHNvbWV0aGluZyBlbHNlLg0K Pg0KPiBJIHRoaW5rIGl0IG5lZWRzIHRvIGJlIGluIHRoZSB0YWcgNiBhcnJheS4NCg0KUG9zc2li bHksIGJ1dCB0aGlzIG9wZW5zIHRoZSBxdWVzdGlvbiBvZiB3aGVyZSBpdCBnb2VzLiBNYXliZSBp dCBuZWVkcyB0byBiZSBleHBsaWNpdGx5IGluY2x1ZGVkLiBTdXBwb3NlIHRoYXQgd2UgdXNlIGEg c3BlY2lhbCBjYXNlOg0KDQpUYWcgNihbcnVtcCwgVGFnIDYoZGljdGlvbmFyeS1pZCldKS4NCg0K VGhlIGNvbnRleHQgb2YgdGhlIHNlY29uZCBUYWcgNiAobm9ybWFsbHksIHRoZXJlIHdvdWxkIGJl IGFuIGFycmF5IHRoZXJlKSBtYWtlcyBpdCBjbGVhciB0aGF0IHRoaXMgaXMgYW4gZXh0ZXJuYWwg cmVmZXJlbmNlIGRpY3Rpb25hcnkuIFdlIGNvdWxkIHNwZWNpZnkgYSByZWZlcmVuY2UgZGlnZXN0 IGluIHRoZSB0YWcgYXMgd2VsbDoNCg0KVGFnIDYoW3J1bXAsIFRhZyA2KFtkaWdlc3QtYWxnLCBk aWdlc3QtYnl0ZXMsIGRpY3Rpb25hcnktaWRdKV0pDQoNCknigJltIG5vdCBzdXJlIHRoaXMgaXMg dGhlIHJpZ2h0IGFwcHJvYWNoLCBidXQgSSBsaWtlIHRoYXQgaXQga2VlcHMgVGFnIDYgaW5mb3Jt YXRpb24gaW4gVGFnIDYNCg0KPg0KPiAgIGNhYm8+IFRoZXJlIGFyZSB0d28gYXNwZWN0cyBoZXJl Og0KPiAgIGNhYm8+IOKAlCBob3cgZG8gd2UgbWFrZSBzdXJlIHRoZSBleHRlcm5hbCBkaWN0aW9u YXJ5IGNhbm5vdCBiZSBzdXJyZXB0aXRpb3VzbHkNCj4gICBjYWJvPiBleGNoYW5nZWQgYnkgYW4g YXR0YWNrZXINCj4NCj4+IFRoaXMgcmVxdWlyZXMgc29tZSBzb3J0IG9mIHNlY3VyaXR5IG1lY2hh bmlzbS4gVXNpbmcgYSBDT1NFIGZlYXR1cmUNCj4+IHRoYXQgaW5jbHVkZXMgYWRkaXRpb25hbCBk YXRhIGlzIG5vdCBpZGVhbCBpbiBTVUlUIGJlY2F1c2Ugd2Ugc3VwcG9ydA0KPj4gQ09TRV9TaWdu LCBDT1NFX1NpZ24xLCBDT1NFX01BQywgb3IgQ09TRV9NQUMwLCBvciBhbnkgY29tYmluYXRpb24N Cj4+IHRoZXJlb2YuIFRoaXMgd291bGQgbWVhbiB0aGF0IGEgQ09TRSBmZWF0dXJlIHRoYXQgaW5j bHVkZXMgZXh0cmEgZGF0YQ0KPj4gd291bGQgYmUgZHVwbGljYXRlZCBmb3IgYXMgbWFueSBDT1NF IG9iamVjdHMgYXMgYXJlIGluY2x1ZGVkLiBPZg0KPj4gY291cnNlLCB0aGF04oCZcyBub3QgcGFy dGljdWxhcmx5IHJlbGV2YW50IGlmIHRoZSBsaXN0IG9mIENPU0Ugb2JqZWN0cyBpcw0KPj4gYWxz byB1c2luZyBwYWNrZWQgQ0JPUiwgc28gbWF5YmUgaXTigJlzIGZpbmUuDQo+DQo+PiBJbmNsdWRp bmcgYSBkaWN0aW9uYXJ5IHJlZmVyZW5jZSBhcyBBQUQgc2VlbXMgZmluZSB0byBtZS4gSW4gdGhl IFNVSVQNCj4+IGNhc2UsIEkgdGhpbmsgSSB3b3VsZCBtYWtlIGl0IG1vcmUgZXhwbGljaXQgYmVj YXVzZSB3ZSBuZWVkIHRvIGlkZW50aWZ5DQo+PiB3aGljaCBleHRlcm5hbCBkaWN0aW9uYXJ5IHRv IGRpZ2VzdC4NCj4NCj4gICBjYWJvPiDigJQgaG93IGRvIHdlIG1ha2Ugc3VyZSB0aGVyZSBpcyBh biB1bmFtYmlndW91cw0KPiAgIGNhYm8+IHdheSB0byBpbnRlZ3JhdGUgdGhlIGV4dGVybmFsIGRp Y3Rpb25hcnkvLWllcyBpbnRvIHRoZSBwcmVmaXggYW5kIHNoYXJpbmcgdGFibGVzPw0KPg0KPj4g V2UgbmVlZCB0byAobG9naWNhbGx5KSBjb25jYXRlbmF0ZSB0aGUgZGljdGlvbmFyaWVzIHRvZ2V0 aGVyLiBUaGUgcXVlc3Rpb24gaXM6IHdoaWNoIG9yZGVyPw0KPg0KPj4gRnJvbSBhIHB1bGwgcGFy c2VyIHBlcnNwZWN0aXZlLCBJIHRoaW5rIEkgd291bGQgc3VnZ2VzdCBhIHN0YWNrLWJhc2VkIG1v ZGVsOg0KPj4gLSBFYWNoIGRpY3Rpb25hcnkgaXMgYW4gZWxlbWVudCBpbiBhIHNpbmdseSBsaW5r ZWQgbGlzdC4NCj4+IC0gV2hlbiB5b3UgZW5jb3VudGVyIGEgbmV3IGRpY3Rpb25hcnksIHlvdSBw dXNoIGl0IG9udG8gdGhlIGhlYWQgb2YgdGhlIGxpc3QNCj4+IC0gV2hlbiB5b3UgZmluaXNoIGEg cnVtcCBlbGVtZW50LCB5b3UgcG9wIHRoZSBkaWN0aW9uYXJ5IGFzc29jaWF0ZWQNCj4+IHdpdGgg aXQgZnJvbSB0aGUgaGVhZCBvZiB0aGUgbGlzdC4NCj4NCj4+IC0gV2hlbiB5b3UgZmluZCBhIGRp Y3Rpb25hcnkgcmVmZXJlbmNlIGluIHRoZSBydW1wLCB5b3UgdHJhdmVyc2UgdGhlDQo+PiBkaWN0 aW9uYXJ5IGxpc3QsIHN0YXJ0aW5nIGF0IHRoZSBtb3N0IHJlY2VudC4NCj4NCj4+IC0gV2hlbiB5 b3UgZmluZCBhIGRpY3Rpb25hcnkgcmVmZXJlbmNlIGluIGEgZGljdGlvbmFyeSBlbGVtZW50LCB5 b3UNCj4+IHRyYXZlcnNlIHRoZSBkaWN0aW9uYXJ5IGxpc3QsIHN0YXJ0aW5nIGF0IHRoZSBjdXJy ZW50IGRpY3Rpb25hcnkuDQo+DQo+IEltcGx5aW5nIHRoYXQgZGljdGlvbmFyaWVzIGNhbiBiZSBj cmVhdGVkIHRoYXQgYXJlIHNlbGYtcmVmZXJlbnRpYWwsIGFuZCBjYW4NCj4gYmxvdyB1cCB0byBp bmZpbml0ZSBkYXRhIHN0cmVhbXMgOi0pDQoNCkFzIGFib3ZlLCB0aGUgb3JpZ2luYWwgc3BlY2lm aWNhdGlvbiBwcm9oaWJpdHMgbG9vcHMsIGJ1dCBsZWF2ZXMgdGhlIGltcGxlbWVudGF0aW9uIHVw IHRvIHRoZSByZWFkZXIuDQoNCj4NCj4gVW5sZXNzIHlvdSBtZWFuIHRoYXQgZGljdGlvbmFyaWVz IHNob3VsZCBiZSBzb3J0ZWQgc28gdGhhdCB0aGV5IGFsd2F5cyAoY2FuIG9ubHkpDQo+IHJlZmVy ZW5jZSBmb3J3YXJkLCBhbmQgeW91IGNhbiBzdGFydCBhdCB0aGUgY3VycmVudCBsb2NhdGlvbiBp biB0aGUgY3VycmVudA0KPiBkaWN0aW9uYXJ5Lg0KDQpQb3NzaWJseSwgYnV0IEnigJltIG5vdCBz dXJlIHRoYXTigJlzIHVuaXZlcnNhbGx5IGFkdmFudGFnZW91cy4gUmVtZW1iZXIgdGhhdCB3ZSB3 YW50IGhpZ2ggcmVmZXJlbmNlIGZyZXF1ZW5jeSBpdGVtcyB0byBiZSBhdCB0aGUgc3RhcnQuIFN1 cHBvc2UgdGhhdCBJIGhhdmUgdGhlIHByZWZpeGVzIFvigJxodHRwczovL+KAnCwg4oCcd3d3LuKA nSwg4oCcZmlsZXMu4oCdLCDigJxkb21haW4uY29t4oCdXS4gQ2xlYXJseSwgSSB3YW50IHRvIGJl IGFibGUgdG8gY29tcG9zZSB0aGVzZSBpbiBvbmUgb2YgdHdvIHdheXM6DQoNCmh0dHBzOi8vd3d3 LmRvbWFpbi5jb20NCmh0dHBzOi8vZmlsZXMuZG9tYWluLmNvbQ0KDQpPbmx5IHRoZXNlIHR3byBw cmVmaXhlcyB3aWxsIGFwcGVhciBpbiBteSBvYmplY3QsIHRoZSBvdGhlcnMgd2lsbCBub3QsIHdo aWNoIHJlbmRlcnMgdGhlaXIgY29tcHJlc3Npb24gbGVzcyBpbXBvcnRhbnQuIEkgd291bGQgZXhw ZWN0IHNvbWV0aGluZyBsaWtlOg0KDQpbW1RhZyAyMjUoc2ltcGxlKDApKSwgVGFnIDIyNihzaW1w bGUoMCksIFRhZyAyMjco4oCcd3d3LuKAnSksIFRhZyAyMjco4oCcZmlsZXPigJ0pLCDigJxodHRw czovL+KAnF0sIOKAnGRvbWFpbi5jb20iXQ0KDQpOb3RlIHRoYXQgdGhlIHNvcnRpbmcgaXMgdGhl IG9wcG9zaXRlIG9mIHdoYXTigJlzIGltcGxpZWQuDQoNCkJ1dCB3aGF0IGlmIOKAnGh0dHBzOi8v IiBpcyB1c2VkIGV4dGVuc2l2ZWx5PyBUaGVuIHdlIG5lZWQgdG8gY2hhbmdlIG91ciBzb3J0IG9y ZGVyIHNvIHRoYXQgaXQgY2FuIGJlIHJlZmVyZW5jZWQgd2l0aCBUYWcgNigpLg0KDQpJIHRoaW5r IHdlIG5lZWQgdG8gYmUgdmVyeSBjbGVhciBhYm91dCB3aGF04oCZcyBhbGxvd2VkIGJlY2F1c2Ug b3RoZXJ3aXNlLCB0aGVyZSB3aWxsIGJlIGEgbG90IG9mIHZhcmllZCBpbXBsZW1lbnRhdGlvbnMg d2l0aCB2YXJpZWQgbGltaXRhdGlvbnMuDQoNCj4+IEl0IGhhcyBzZXZlcmFsIGRpc2FkdmFudGFn ZXM6DQo+PiAtIFJlZmVyZW5jZXMgaGF2ZSBpbmNvbnNpc3RlbnQgbWVhbmluZ3MgKFRhZyA2ICgx KSBkb2VzbuKAmXQgbWVhbiB0aGUNCj4+IHNhbWUgZGljdGlvbmFyeSBlbnRyeSBldmVyeXdoZXJl LiBJdCBwb2ludHMgdG8gZGlmZmVyZW50IGRpY3Rpb25hcmllcw0KPj4gaW4gZGlmZmVyZW50IHBs YWNlcykNCj4NCj4+IC0gVGhlIHN0YWNrIG1vZGVsIHJlcXVpcmVzIHNvbWUga2luZCBvZiBhbGxv Y2F0aW9uIHN0cmF0ZWd5IHRvIGtlZXANCj4+IHRyYWNrIG9mIHRoZSBkaWN0aW9uYXJpZXMuDQo+ DQo+IEl0J3MgYSBzdGFjayBvZiBwb2ludGVycy4gIEl0IGNhbiBwb2ludCBhdCB0aGUgaW4tYmFu ZCBkaWN0aW9uYXJ5IHdoaWNoIGNhbg0KPiBiZSBwcm9jZXNzZWQgYnkgYSBwdWxsLXBhcnNlci4g IE9yIGF0IGFuIG91dC1vZi1iYW5kIGRpY3Rpb25hcnkgd2hpY2ggaXMNCj4gcHJvYmFibHkgaW4g IlJPTSIgaW4gc29tZSBjb252ZW5pZW50IGZvcm1hdCAocHJvYmFibHkgQ0JPUiBtYXApDQoNCklu ZGVlZC4gTm90IHRvbyBiYWQsIEkgdGhpbmsuDQoNCj4NCj4+IC0gVGhlIGNvbXByZXNzb3IgaGFz IHRvIGJlIGF3YXJlIG9mIHRoZSBkaWN0aW9uYXJpZXMgb2YgcGFja2VkIENCT1INCj4+IG9iamVj dHMgaXQgdHJhdmVyc2VzIGluIG9yZGVyIHRvIHBhY2sgYW55dGhpbmcgdGhhdCBhcHBlYXJzIHdp dGhpbiBhbg0KPj4gYWxyZWFkeSBwYWNrZWQgQ0JPUiBvYmplY3QuDQo+DQo+IEluIHRoZSBTVUlU IGNhc2UsIHRoZSBjb21wcmVzc29yIGlzICJjbG91ZCIgOi0pDQoNCll1cC4gTGV04oCZcyBub3Qg bWFrZSB0aGluZ3MgaGFyZCBmb3IgY29uc3RyYWluZWQgbm9kZXMgYmVjYXVzZSBpdOKAmXMgZWFz aWVyIGZvciB1bmNvbnN0cmFpbmVkIG9uZXMuDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250 ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBh bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3Qg ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55 IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0u IFRoYW5rIHlvdS4NCg== From nobody Wed Jul 29 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 3F3E33A09D7 for ; Wed, 29 Jul 2020 16:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_Os4bXptowA for ; Wed, 29 Jul 2020 16:44:44 -0700 (PDT) Received: from authenticated.a-painless.mh.aa.net.uk (a-painless.mh.aa.net.uk [IPv6:2001:8b0:0:30::51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 380833A0915 for ; Wed, 29 Jul 2020 16:44:44 -0700 (PDT) Received: from cpc104502-sgyl40-2-0-cust104.18-2.cable.virginm.net ([82.34.80.105] helo=Galaxy-S10e.lan) by a-painless.mh.aa.net.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k0vkY-0006oN-Hk; Thu, 30 Jul 2020 00:44:42 +0100 Date: Thu, 30 Jul 2020 00:44:30 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: <25163.1596045376@localhost> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----3MI81UD8MS1JFJLRMNKGKJNIFOFTRV" Content-Transfer-Encoding: 7bit To: cbor@ietf.org, Brendan Moran , Michael Richardson CC: "cbor@ietf.org" From: Kio Smallwood Message-ID: <0A0FEABF-ADF2-4342-9AC3-42F768F14CCF@mothers-arms.co.uk> Archived-At: Subject: Re: [Cbor] "ordered hash" X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 23:44:46 -0000 ------3MI81UD8MS1JFJLRMNKGKJNIFOFTRV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I wrote a proposal for tag 272 ordered map=2E https://github=2Ecom/Sekenre/cbor-ordered-map-spec Unfortunately no one has approved the tag allocation or given me any guida= nce on how to proceed=2E I'm probably doing something wrong but i haven't had time to do any follow= up=2E Hope its useful for you anyway=2E Cheers, Kio On 29 July 2020 23:37:46 BST, Brendan Moran wr= ote: >I=E2=80=99d probably call it a multi-map if it were sorted=2E Perhaps it= =E2=80=99s an >ordered multi-map? > >Brendan > >> On 29 Jul 2020, at 18:56, Michael Richardson >wrote: >> >> >> Do we have a canonical term for an array of tuples that behaves like >a map, but >> isn't, because it's an ordered array of 2*n elements? >> >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >> >> >> >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/cbor > >IMPORTANT NOTICE: The contents of this email and any attachments are >confidential and may also be privileged=2E If you are not the intended >recipient, please notify the sender immediately and do not disclose the >contents to any other person, use it for any purpose, or store or copy >the information in any medium=2E Thank you=2E >_______________________________________________ >CBOR mailing list >CBOR@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/cbor --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------3MI81UD8MS1JFJLRMNKGKJNIFOFTRV Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I wrote a proposal for tag 272 ordered map=2E
<= br>https://g= ithub=2Ecom/Sekenre/cbor-ordered-map-spec

Unfortunately no one h= as approved the tag allocation or given me any guidance on how to proceed= =2E

I'm probably doing something wrong but i haven't had time to do = any follow up=2E

Hope its useful for you anyway=2E

Cheers,Kio

On 29 July 2020 23:37:46 BST, Brenda= n Moran <Brendan=2EMoran@arm=2Ecom> wrote:
I=E2=80=99d probably call it a multi-map if it were =
sorted=2E Perhaps it=E2=80=99s an ordered multi-map?

Brendan

=

 On 29 Jul 2020, at 18:56,=
 Michael Richardson <mcr+ietf@sandelman=2Eca> wrote:


 Do w=
e have a canonical term for an array of tuples that behaves like a map, but=

 isn't, because it's an ordered array of 2*n elements?

 --
 M=
ichael Richardson <mcr+IETF@sandelman=2Eca>, Sandelman Software Works=

 -=3D IPv6 IoT consulting =3D-
 CBOR mailing list
 CBOR@ietf=2Eor=
g
 https://ww=
w=2Eietf=2Eorg/mailman/listinfo/cbor

IMPORTANT NOTI=
CE: The contents of this email and any attachments are confidential and may=
 also be privileged=2E If you are not the intended recipient, please notify=
 the sender immediately and do not disclose the contents to any other perso=
n, use it for any purpose, or store or copy the information in any medium=
=2E Thank you=2E
CBOR mailing list
CBOR@ietf=2Eorg
https://www=2Eietf=2Eorg/mailma=
n/listinfo/cbor

--
Sent from my And= roid device with K-9 Mail=2E Please excuse my brevity=2E ------3MI81UD8MS1JFJLRMNKGKJNIFOFTRV-- From nobody Wed Jul 29 21:08:36 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 0E7633A0CBB for ; Wed, 29 Jul 2020 21:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 HT6UUbc6WcCP for ; Wed, 29 Jul 2020 21:08: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 333F73A0CB9 for ; Wed, 29 Jul 2020 21:08:31 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4BHH2h4MFYzyYv; Thu, 30 Jul 2020 06:08:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <0A0FEABF-ADF2-4342-9AC3-42F768F14CCF@mothers-arms.co.uk> Date: Thu, 30 Jul 2020 06:08:26 +0200 Cc: cbor@ietf.org, Brendan Moran , Michael Richardson X-Mao-Original-Outgoing-Id: 617774906.826647-fb17c0cafc449f1f01479df25a87ec2c Content-Transfer-Encoding: quoted-printable Message-Id: References: <25163.1596045376@localhost> <0A0FEABF-ADF2-4342-9AC3-42F768F14CCF@mothers-arms.co.uk> To: Kio Smallwood X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] "ordered hash" 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, 30 Jul 2020 04:08:34 -0000 On 2020-07-30, at 01:44, Kio Smallwood wrote: >=20 > I wrote a proposal for tag 272 ordered map. >=20 > https://github.com/Sekenre/cbor-ordered-map-spec (272 is already taken: Non-UTF-8 CESU-8 string.) > Unfortunately no one has approved the tag allocation or given me any = guidance on how to proceed. Let=E2=80=99s look into this. I think this idiom is frequent enough that it should get a 1+1 tag. The difference from a map is that this is both order-preserving and = allowing duplicate keys; whether you want one or two of these properties = on the application data model level may differ between applications. The traditional alist (association list) is AList =3D [* [K, V]] By using the exact structure of a map (except that the array head will = have double the argument that the map head has), we can save 1 byte per = k/v pair (=E2=80=9Cflattened alist=E2=80=9D): FAList =3D [* (K, V)] So [[=E2=80=9Ca=E2=80=9D, 1], [=E2=80=9Cb=E2=80=9D, 2]] becomes = [=E2=80=9Ca=E2=80=9D, 1, =E2=80=9Cb=E2=80=9D, 2] I=E2=80=99m not sure which of these MCR was inquiring on. The first is = definitely an alist, and there is no need for a new term. The second = can be called an ordered multimap, but there are other structures that = also deserve this name. =20 If adjacent duplicate keys of non-trivial size are likely in an ordered = multimap, a better version of the multimap is: MList =3D [* (K, [* V])] So [[=E2=80=9Caaa=E2=80=9D, 1], [=E2=80=9Caaa=E2=80=9D, 2], [=E2=80=9Cbbb=E2= =80=9D, 3]] becomes [=E2=80=9Caaa=E2=80=9D, [1, 2], =E2=80=9Cbbb=E2=80=9D,= [3]] If V can never be an array (*), this can be further optimized into: OMList =3D [* (K, [2* V] / V)] So [[=E2=80=9Caaa=E2=80=9D, 1], [=E2=80=9Caaa=E2=80=9D, 2], [=E2=80=9Cbbb=E2= =80=9D, 3]] becomes [=E2=80=9Caaa=E2=80=9D, [1, 2], =E2=80=9Cbbb=E2=80=9D,= 3] Further refine by using delta coding for the keys (works best with = sorted keys), etc. Also, a map can be used for the outer structure if = order preservation is not actually needed: MMap =3D {* K =3D> [* V]} OMMap =3D {* K =3D> [2* V] / V} There are many idioms to choose from; it would probably be best to = define tags for at least each of the ones listed here. I think FAList = (what Kio proposed) is the one that will see the most use. Gr=C3=BC=C3=9Fe, Carsten (*) Or extra-wrap just arrays: OEMList =3D [* (K, [2* V] / [V .and [* any]] / V)] From nobody Thu Jul 30 00:46: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 6AE283A0F5D for ; Thu, 30 Jul 2020 00:46:53 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.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 R23Pbj7MyDiw for ; Thu, 30 Jul 2020 00:46:51 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 D79463A0F59 for ; Thu, 30 Jul 2020 00:46:50 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id j8so14943636ioe.9 for ; Thu, 30 Jul 2020 00:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2sxUXaAC1tvzKwNFw++OdWTE63FePth/UOoVNC6FJi8=; b=Y8JQf2DUW8UM0eSjUATU59KQFtbP1bLcLgaHr8Q6KFSxxpp0O91OQB8kZp4o1Gh5DB oBlCrLa5QA+LR/JoLdTW9GqtbVSWAZqw+caFXK8W6mJz1Inkdg5zCWxFETm6Hit3ZDN8 b9WniJL0fM4FbYesZ+RWv5LGaPujQDeF3chYi/fZayXPIDeeqp0e9WoOwIIVQVMHbfBi uhMtgb14vVx5x0WhfX2NVJfx6WXRMqGQHC8jJv4RbrhI3jf45LswZfFUSYmTLNz009I0 5BN/oJHmmgDR0k+84x70V9AFuxoDqa/rjAEiC9WFE/LNLj+Vhjodavnqb8pKgOV01bSa UQYQ== 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=2sxUXaAC1tvzKwNFw++OdWTE63FePth/UOoVNC6FJi8=; b=SYe1zXvOtOaNElom1ys3GUFTLuZtMLAGNnonD6y96ubP6DBt6Ysd+Pp4C6ma90vMuB X12Y+lHkvhp8mxRg4BjTvuO+OMoUXW6unyoGRiEsXW34wBAN64LeodZuEiut/3hkUtG4 N/J2ZnWYfsD8AsLKk+bIKSYsHSeUwBGhCjOaB/odEO5Ell+EUIoIE2WaqrvZki0lvM/t 5ntFvqVRcdj10GGIxRuvyBMozL1mC+SD+4o9c3TOt2O//myOvA1+tUKsgyxHvIJA9XvA LpGMhsSqW6h5BsCZQQuMVtVsh3yk+TGYG3wkJly2ZjF67HYRZ2U95QPI85B6djouDIKs vvDQ== X-Gm-Message-State: AOAM533I9tXof4I4zuhtZa2JYJTlkqjv+wnTcBX8fAHKYc5siij6w9Rw niHHwPMg4vgfIu/RVg6kfG0qnEP/6anq2FLYLBijrQ== X-Google-Smtp-Source: ABdhPJz1PpuKRS8pKIA9cVZDyaPJmzBqk1pgE/nz5+BeY+jldsOhieMlOjnfrzaUltopv/UVfxpBoitmtm5vF46ughU= X-Received: by 2002:a6b:fe0f:: with SMTP id x15mr31214005ioh.173.1596095209438; Thu, 30 Jul 2020 00:46:49 -0700 (PDT) MIME-Version: 1.0 References: <25163.1596045376@localhost> <0A0FEABF-ADF2-4342-9AC3-42F768F14CCF@mothers-arms.co.uk> In-Reply-To: From: Alexander Pelov Date: Thu, 30 Jul 2020 09:46:16 +0200 Message-ID: To: Carsten Bormann Cc: Kio Smallwood , cbor@ietf.org, Brendan Moran , Michael Richardson Content-Type: multipart/mixed; boundary="000000000000fd0d9405aba3dfd0" Archived-At: Subject: Re: [Cbor] "ordered hash" 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, 30 Jul 2020 07:46:54 -0000 --000000000000fd0d9405aba3dfd0 Content-Type: multipart/alternative; boundary="000000000000fd0d9205aba3dfce" --000000000000fd0d9205aba3dfce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Several years ago we had this type of discussion for the use of COMI/CORECONF. We called it in a couple of different ways: - DeterministicMultimaps - COMAP (CBOR Order-preserving Multimap) - Order-Keeping Multimap (OKMM) Unfortunately, I don't think we published any open specs outside the Task Force (although we did have quite some discussion at CORE WG). One of the latest specs we had is attached (sorry for the PDF). Cheers, Alexander On Thu, Jul 30, 2020 at 6:08 AM Carsten Bormann wrote: > On 2020-07-30, at 01:44, Kio Smallwood wrote: > > > > I wrote a proposal for tag 272 ordered map. > > > > https://github.com/Sekenre/cbor-ordered-map-spec > > (272 is already taken: Non-UTF-8 CESU-8 string.) > > > Unfortunately no one has approved the tag allocation or given me any > guidance on how to proceed. > > Let=E2=80=99s look into this. > > I think this idiom is frequent enough that it should get a 1+1 tag. > > The difference from a map is that this is both order-preserving and > allowing duplicate keys; whether you want one or two of these properties = on > the application data model level may differ between applications. > > The traditional alist (association list) is > > AList =3D [* [K, V]] > > By using the exact structure of a map (except that the array head will > have double the argument that the map head has), we can save 1 byte per k= /v > pair (=E2=80=9Cflattened alist=E2=80=9D): > > FAList =3D [* (K, V)] > > So [[=E2=80=9Ca=E2=80=9D, 1], [=E2=80=9Cb=E2=80=9D, 2]] becomes [=E2=80= =9Ca=E2=80=9D, 1, =E2=80=9Cb=E2=80=9D, 2] > > I=E2=80=99m not sure which of these MCR was inquiring on. The first is d= efinitely > an alist, and there is no need for a new term. The second can be called = an > ordered multimap, but there are other structures that also deserve this > name. > > If adjacent duplicate keys of non-trivial size are likely in an ordered > multimap, a better version of the multimap is: > > MList =3D [* (K, [* V])] > > So [[=E2=80=9Caaa=E2=80=9D, 1], [=E2=80=9Caaa=E2=80=9D, 2], [=E2=80=9Cbbb= =E2=80=9D, 3]] becomes [=E2=80=9Caaa=E2=80=9D, [1, 2], =E2=80=9Cbbb=E2=80= =9D, [3]] > > If V can never be an array (*), this can be further optimized into: > > OMList =3D [* (K, [2* V] / V)] > > So [[=E2=80=9Caaa=E2=80=9D, 1], [=E2=80=9Caaa=E2=80=9D, 2], [=E2=80=9Cbbb= =E2=80=9D, 3]] becomes [=E2=80=9Caaa=E2=80=9D, [1, 2], =E2=80=9Cbbb=E2=80= =9D, 3] > > Further refine by using delta coding for the keys (works best with sorted > keys), etc. Also, a map can be used for the outer structure if order > preservation is not actually needed: > > MMap =3D {* K =3D> [* V]} > OMMap =3D {* K =3D> [2* V] / V} > > There are many idioms to choose from; it would probably be best to define > tags for at least each of the ones listed here. I think FAList (what Kio > proposed) is the one that will see the most use. > > Gr=C3=BC=C3=9Fe, Carsten > > (*) Or extra-wrap just arrays: > OEMList =3D [* (K, [2* V] / [V .and [* any]] / V)] > > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > --000000000000fd0d9205aba3dfce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Several years ago we had this t= ype of discussion for the use of COMI/CORECONF. We called it in a couple of= different ways:=C2=A0
-=C2=A0DeterministicMultimaps
- = COMAP (CBOR Order-preserving Multimap)
- Order-Keeping Multimap (= OKMM)

Unfortunately, I don't think we publishe= d any open specs outside the Task Force (although we did have quite some di= scussion at CORE WG).

One of the latest specs we h= ad is attached (sorry for the PDF).=C2=A0

Cheers,<= /div>
Alexander



On Thu, Jul 30, 2020= at 6:08 AM Carsten Bormann <cabo@tzi.or= g> wrote:
On 2020-07-30, at 01:44, Kio Smallwood <kio@mothers-arms.co.uk> wrote:
>
> I wrote a proposal for tag 272 ordered map.
>
> https://github.com/Sekenre/cbor-ordered-map-spe= c

(272 is already taken: Non-UTF-8 CESU-8 string.)

> Unfortunately no one has approved the tag allocation or given me any g= uidance on how to proceed.

Let=E2=80=99s look into this.

I think this idiom is frequent enough that it should get a 1+1 tag.

The difference from a map is that this is both order-preserving and allowin= g duplicate keys; whether you want one or two of these properties on the ap= plication data model level may differ between applications.

The traditional alist (association list) is

AList<K, V> =3D [* [K, V]]

By using the exact structure of a map (except that the array head will have= double the argument that the map head has), we can save 1 byte per k/v pai= r (=E2=80=9Cflattened alist=E2=80=9D):

FAList<K, V> =3D [* (K, V)]

So [[=E2=80=9Ca=E2=80=9D, 1], [=E2=80=9Cb=E2=80=9D, 2]] becomes [=E2=80=9Ca= =E2=80=9D, 1, =E2=80=9Cb=E2=80=9D, 2]

I=E2=80=99m not sure which of these MCR was inquiring on.=C2=A0 The first i= s definitely an alist, and there is no need for a new term.=C2=A0 The secon= d can be called an ordered multimap, but there are other structures that al= so deserve this name.=C2=A0

If adjacent duplicate keys of non-trivial size are likely in an ordered mul= timap, a better version of the multimap is:

MList<K, V> =3D [* (K, [* V])]

So [[=E2=80=9Caaa=E2=80=9D, 1], [=E2=80=9Caaa=E2=80=9D, 2], [=E2=80=9Cbbb= =E2=80=9D, 3]] becomes [=E2=80=9Caaa=E2=80=9D, [1, 2], =E2=80=9Cbbb=E2=80= =9D, [3]]

If V can never be an array (*), this can be further optimized into:

OMList<K, V> =3D [* (K, [2* V] / V)]

So [[=E2=80=9Caaa=E2=80=9D, 1], [=E2=80=9Caaa=E2=80=9D, 2], [=E2=80=9Cbbb= =E2=80=9D, 3]] becomes [=E2=80=9Caaa=E2=80=9D, [1, 2], =E2=80=9Cbbb=E2=80= =9D, 3]

Further refine by using delta coding for the keys (works best with sorted k= eys), etc.=C2=A0 Also, a map can be used for the outer structure if order p= reservation is not actually needed:

MMap<K, V> =3D {* K =3D> [* V]}
OMMap<K, V> =3D {* K =3D> [2* V] / V}

There are many idioms to choose from; it would probably be best to define t= ags for at least each of the ones listed here.=C2=A0 I think FAList (what K= io proposed) is the one that will see the most use.

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

(*) Or extra-wrap just arrays:
OEMList<K, V> =3D [* (K, [2* V] / [V .and [* any]] / V)]


_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
--000000000000fd0d9205aba3dfce-- --000000000000fd0d9405aba3dfd0 Content-Type: application/pdf; name="draft-pelov-core-comap.pdf" Content-Disposition: attachment; filename="draft-pelov-core-comap.pdf" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kd8hsz7k1 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1XNty3MYRfcdXwCJNcrlcEIM75EtsXShHsh07YZyHrJ9c yUOqnCrH/1+V091nBjMAqN2V1qUyQQzm0tfT3TND/5b/mP+W37/83eW//J6X+u/3X9BUFlVj7/KL q/Cz7fN2GIvRNXX+y6/5i8e86bQLHlVb5ruqLsvs8df8/vGxyl3++O/85pNN/vif/PWjLnPinK4c XdF1/aGJhYPe5X1Z51WHhdv8f//K/5H/93S2MmNrVxZlCa4ff8mbyjislMNmAFfKH0Qi/P0THD7b 5FV+c3Gpj083+HDzbJOhyVourjb5Dm3X+t0672+0235jr9YxnsB/QccMYznF7Sav85utjr3Tnzv9 yc+FrnAf0VHqZ0z8c/74FlrIRFTHaSHwPVRN0XdgPGE+E+ViXa9cmbiuayrBnUsJzThTQlXWRYV1 EmKoCVdB0hCQiAOP+nKTieAbe71vTQ9d0glakT49hlJGsNRVZrIPsijvKEGcVeMGNWpwQF+hLc3F CZPuhtZMuvvjTLqEiE816VhYJxtUPXZFOfZD3pTjTALDZFBHTquu2nawkmxyVUxcjHXVygoL5ka4 6A7eCTeSx3Mzh4uIpezItacF29IV/Vg2iwWzuVLFR0yr8JHzaHXhI3XZF+Ifa9w7QIIYPIDDfCMT V9lvTArAjqUXnI/cSWCTF8w1NBeYeEE3TMD+UW74JLDXdZ+a4gLYDal7BVdDavud2GtwfGHYfPGZ 4r+1fc4ejBPPY3z+YpM3HtAv9hv7ZCvZTMCunzOF7hMCaMCafmwKVw0NkLn3foBw8gR0m5jPBt3i k3H4dE1buLKPaQkx9EtB7taQG48/iXFmEj/FQ9U4ISbB8enBj/BbaeSDjQLx02zXCAOYBuoSi18F +vOxvmLikfCZFM3ipph4685p4s1K7lJ17cLEr78yoXytMoaQBBshpEuYrjw/xwOtDKgv7O0zDajZ zUs2v3qdhtSH16/exDhyCE2ZdE2S6+q+GMahh0Rab7brklM0VdHRbD8eHRZoWrq+KHtkuCvyu6W8 PH4y1eDDt0qkgTDh1/IQU601LgjyfuMztPApv/mztt1zbiI1NUKZI62W0TpldkNMXzftWDwflRVP CgrofVBBYtqIeJqWS7T7KP1MBLi6GosWwFa5OjXqefhQC1EKzhZvYZMpsJVd0bZ17sY6tVbEkLfU PXWpSszMBLQ+iOxCNAske2dWglAg3zgOcQJumNoRdD+FBp+xmrDPweok7KDtBYNzYYu2kdSEIuzc 2nbNgZRZta0UnC2MtVWqbjf2Y9GXKDOrZS34LX3ce35rFYiEJSoTahQjwMP3UTwI6Si7sjG2iUyN AQPZBTaBOfnCddn/9jtbECixks4F+WQfWiY/XdRAKO/3R5hIO46TiZwJkQIgdLOEf26iYiFGwPki xiLTATj12LZoZuUN8OB7+vBnk0VEShStQ8HE+Nt79tLmzLu/2g16if9bVR9VrAlrT8g2O3EDIPi/ hMa4UgShWVz/i25RdgSwf2L9AxsQi3Qg6BYRb77+Yv/BCCAAfhT+aK2wzAakeK1b6KlJDR3KvaUz MvzzjcH53jCcun1HYGefC+AEwjmNQ3aHosCAPiuKVkGvAn0mu3gn7OGFciEoGsx5Sa+XC6LpDtH3 LLttU6SZNN0fkfgZBedw44mCSQRjl+p3DiQigkZS1HNsOE4ETCJwmP2wuSsJIoM/AMx3rhsOC6Eu /0AhVG6JOUufVxLOIQTbHxjS3aTKubaoh1p8vkxVAqd/AacFhAONgckAbPxuLfBw/P4y3r99rZ3+ oj+lZsJ3wQM8HrTNvr/S35MSyqd37dk4nSxuMnmw9351h2OCwvb9jwCZeEfdiWBzRGgBKDxaYOnQ 4Zdd03to7yC0aV8dkkHww09gIDYECJrWRMld70WGE0AeqjYtd8kmKsa2LrpyqFao0BzNR7hDE8ec Yusx4XTsS2xIrqwgUYOMeNTfWs7oX/mV5Z8Ug7CzQotD/GIb/LrxDSnVZkzshDAEmXHXWyrVU4UU qcp12HfvGsQ9qIpGQlWdJCRmjpP0XVdBNHLGs5wYJB8rfM6r/qtmFinYdXVbDMDrdTODI0J0ECTE iT0i/I5d6EhUx6VLEUcDDAowvlxODdhzhCRMEiH97wg/IoNyMIVjLux247xN/uExov7sqw78SRVq IWOI3EhOpsDVSQZAY54WcaVrimpsVhaJI+MpToLtcjhJvEQFPBghuDU+4Odm3fvNLQB2Kn0PLUnJ RevITmSP9IXrZDiupLxOYWWukZgT1w5FjcxAVqC3TBq5wzEe9PFMGIrs7EBajOUynLhGbFSwM5zE LqV1ChdLRVcdMtxqWJkXYCUwVBZIVcFDWWC7YifFidgxzjezk7iR8+OIm8Zh3nMpRXEANXpqX01V AWrMTxZa2W8uPt3f4AiVlfrES3lytIvAoG1wXtkHW5OjcY+bEbx5IJDnEWBApQkYwAAk0hgY4KHn 8N2IklQrNVdGQKBmF+IpVPapT05gjjgIxc+k1rBJj6DHXCGbqGgQ7xAxwPaSlBuxe4+Ch5w3Caq2 qR2uHNSwnt0QdmEcrxzASj95JlZp7FCdO1d22HSNUMR6mC9u0/AKzUh/ZGdbCERm8OBD+5B6Da3c pPOdwjCWfOH9ig0MzOlnO+fAbD62c0U5kotW5let/tFMQrZYI1jqseeWFiVn0nTY2CpqSFNESu+I ROrMPrAsFjfGcMIiROEdyS9+hrQ3EHTwskGiXttXDep1dQOCOgDcqo6ra+rMVGObqqCCCgMxQllQ AVMj2gWHUhGUpZTtOgS6FeUzc6KSJV+Hy3Bebw/USlim53ekEDJXYXbCxpS01ORSCyGZnkUqOTvl Go0peSZTc5nBp/mRfkccHoDgGkzjYXnQc2FrQFVjrzgMwifrZ5uPX6Ilk9M6tOMkCT+/jszxoPYZ QQ2sUeziCD9ov0daWA7YqtwNgy+6PLk3L0DYORCkr3FPoMSZ5MoigJGXHka8iT0TgYyT8wUtq7I9 DMzAhFrnUNVzpnEU4mLjNS3wauvd+opfvJ1dvzLz42Pr23cwMFjl0l6EzGtnVsi5SC0tjUO4oBJp BdZy4JPwdbKjT/p1AxQ8IMtYUe/rk7Ubz1vL7ZL1iSGIDzKbmRe5ocGJj3vKbCpiDfGjR5QVbfA1 qNp0g9fjpcgccOK2KgdczpLa9SxiNMzAjgvOt4InKmaMYefDOyH8Yyi2l9viwWPqG7EzN7QZDzX3 G7FWWDmjBPtZxC3TIutA8ss4MRHVd9hiH3Aqu1tSJl71IWrGvcGE8X5AEl9XEO5yDXBPxLS4+I1m UnZw+1aR8Pm7yfkgFL0JCVnEobJAXCAIaI+LyyDBO5uW78i7Sy/Eh9mgy/1mGBic2SeMQtCW24NF aGAHIyIsFzTUDLPJbV4XyNozTaRi+bBB+6BnG3Un3Bxv23EqIJt+CxN0qHx9VjulendbmpVnbQtu s11TweO8YQr52vDtd+33KvIXk270w921ymhtVMaIV7f9u9koHK+JRiUHs/n32Aspiu1dpAed8lIb cE5/d1UWV6plbX9WPkyDOeilTnod5rwvL8nHXsOFDoQeXllq4VUwSd+IvL47t/RbvxMbIUCxVQzw DJuRhlTs+u4yEjSKIpgx822S3Xw4kTNnHRpXVF2NvURXrlFaFkXZqORxmUwUoZ4hUpZ3UIUoWg6X kYql/RtVBtp9x6Ew436QW71QvveXTKcpfTc/33Bxp6goczkOtW++535zd4ENYUy136ST/WCvE9E0 ECMA48/pW8j+l771UFJNIG3SJBIO1P1mps+2hRqwtJA8cwdpuC6Qzwif+hLlIqF3RueRhq23ZFqI tykVvXSgF4T3u2uuaEtkPhxtryIlykC66Xy81ILYSzI1+tX8XCj8sBnAIffbsKho+Hi5M15rWK20 UJ8iWCUbajVuP+7cqvDjpAvWUZq7n7q8bLI8HdWd6/0BT+TUhlYIG/tNQBXgmipaLtWK94ic9HeK SFWBSja0+3IC2Q97bu+AWlfsb26hM7xUDUypNoLTyZt7k1idQ9R2EDbEiivGj7/K7p5n7pTMIC5O 7OAiWgTXjnCXEdsb6xKEUxPo7snvm/3mer+5jGDPxBcBqJjVSRVeRE9fu6LGtQrPtGwzuYpnt5fH p0NkOp65dUinKc7ZtsAHi1OwO6r1XN8jZ8cRUEo+QNFOgjwSnuJ6i4wRSXtbtLInS8MwGdkiN6+P l9H7EhU3dCXy0tU1kDLGgEq/AGyVtJFiwtjTMCY4udxJWOZNVS1+ELOrtW2oNYWSCkCkCI4wSATH 5fybH/BJohy3RmBJtkPCAb4KZUnJHY0wn98ek4RMF2Dts2UlusW4k8AUjGa2W6AniZOZjrDSccDf J+3g+ivc7iyWWsw2+nq9NgnmQDV+Jp8gCkuRbdgF6EYXjvNbpdYo4/RqDjrMuk3nLuC+12Ol0Mkm hjzRYr/b4AdNS2Jq34VlEcdEOzpmPreNtnGQrq4jqf9yHWN3B9Hj8+6Cubq+hZWm2ame4/9uyIKN 3YhKS0hXoSpP8Rh2iPR2O8m+7SEnkiTU6PuUutkrcjdTR8bvRFU+bLhFFY1HOiouoMLMoXbKbooo mdABF5JA2wIhlgUpaQ9b4sLnPZ6oUy3a4rPdMgwScz3OKmo5FhWxzXAXYtsyneKDCLL3SZKWIMcT sgKWgyta2UWh1mL0OAX23wuWI/4SCuF6dRHwOMtDdMedecjxrCVhfLWsrNsV+UZxWRAvVN8GgNd3 705BroV4cdsfjDfYa3dYfQbOsXjn50LHnUXLuVCtLjidyOi5kGuigyHLDiBn5CVqu1f2uL0QWAfS yD4meOfbrgCco9V/FczHq149qBQBJ6WceHAUHV/1Q1m0tZZxoNXbPQ+xTjo5ihW/Hhe7Y4+OwOaP pniNcJkPlD6CaivkBSSYZHDoZMvoi7KgrmyLbpATUNyJ8FeLQ+b6+sMSFJzjJhmB3rYo5R7HyiKw hb8ikKjB28NZ1SEQByEIIIoF2APWEpKBcOzij6cY+m/ZVyeY5GYjAePRBOxJWXIpwpufVRAeBMjW x0SOT0KA+zIdJ+BINpKr2zRRsZHhYi3XfBnTrPE2opKSQBCWRkTX6NtgwuJaXPnBuqQy41tKcSpP +aMlrEA2SBo3lqu3ybo4i5GufwuNxxthAs+zHRWHo/LCybWZdVORPRSLw2r1J5Uu7ylJ8ZfG3u2n Xb7aQvBbkQNY/eKrj8PftgRE9lpwyB82p8lxjL+HnDiRX+ppum3ues154ugJJ/sRNgoumJRa6nYX JX4fgCPRfn2LixS9/MHSTlafyfKUQidBUMGRCKzaqi3GShPuVRYXOKJ6o/fw77Jp1PRJuk3qUi9T //3B1B9DRXbzJti9gAJBheM8NngAkZtDYkAEiUCPNmqZounn0vPe5/cSG7ByOidv8ZErfuPqnIz8 PyYkkZuYRcEZBQMO55xpl1QKn1CoxBTKTRfM9I/6IAOKiLN5SaXyH402ckhKP5G/CsQEz42qd8Y+ Jj8ed95nWuY4wyIvguN8T5opwJTWoCKVFQWQijodnoI45UClUJw8v+c4b0UsX1PA9rEl3CJQoyAZ GrjCRQ9Ox6VosVQnJyXdqaoZVEGGsrgqhcMekyceY3+IOJmDtwPP6wGPiZlM3foJr1DLIVsLr4gM 6LhMd9oBcEOJk1DU/nICOUups49CvQha3eBwYUBRD4vMoHUte1JuqSdqdnIXAQ35o3D5U+fJlCMZ HDgUjZ2onAVvcyIUWEsiX8HSoG+Qg5+7T2GMoAN5Bt5wAU6fony8Qk3hJyDIME4HQbl4Qn/yBtrx yTpbk7WA7+OZWdRI/dAVTSO39RzYmMfo1+dJhwf8fxu6Dnfh1xZZU2jseFQo3Tj1XzauohBxh1c3 aB3ElL8btP6UPIgQ6WTpG4GKjd6Jf7BpaFz0undohL5IL7+RCpiBWCO7EKc47s0aTfzGdXU4LMJW IB6QF6HpeHOIbdvuc0eurneDdLd7aRlQWnIG+xN4OX7ZhRW6ocf/rQXF9JqBxJnij/8HatUB/wpl bmRzdHJlYW0KZW5kb2JqCjUgMCBvYmoKNDUzNwplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvUGFn ZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNiAwIFIgL0NvbnRlbnRzIDQgMCBSIC9NZWRpYUJv eCBbMCAwIDYxMiA3OTJdCj4+CmVuZG9iago2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4 dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUOCAxNSAwIFIKL1RU MTIgMTkgMCBSIC9UVDYgMTMgMCBSIC9UVDQgMTEgMCBSIC9UVDIgOSAwIFIgL1RUMTAgMTcgMCBS ID4+ID4+CmVuZG9iagoyMCAwIG9iago8PCAvTGVuZ3RoIDIxIDAgUiAvTiAzIC9BbHRlcm5hdGUg L0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdlndUU9kWh8+9N73Q EiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji1wnyEFDGwVFEReXd jGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE9wIYEAEOWAHA4WZm BEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX5QKUU7PFGTL/BMr0 lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjAShXJgl4GejfAdlvVRJ mgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHimZ+SKBIlJYqYR15hp 5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW5mj5v9nfHn5T/T3I evtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC03pzzHoZsXpLE4gwn C4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TMzAwOl89k/fcQ/+PA OWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRodV8AfYU5ULhJB8hv PQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9kciWiLBmj34RswQIS kAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2g2pwANSBetAEToI2 cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQOBQDxUOJkBCSQPnQ JqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhHwsvgRHgVnAcXwNvh SrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQDqQbuY1IkXHkAwaH oWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJNhGbjS3EVmCPYFuw l7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/Bc/BifCG+Cn8cfx7f jx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7YQbxJHCZOkxRJhiQX UiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxFQtlOOUq5QHlAeUOl Ug2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6fJ18hf0r+pvy4AlHB QMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIlpSEaQtOledK4tE20 Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyTjLuMj/M05rnP48/b Nq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uuq43Pp893ns+dXzT/ 5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoLtQRa5VrntV4wlZnu zFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0svWC9fr1HvoT5Rn62f pL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+41smsImdSZJJjclN U9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIudFt0WXyztLFMt6ywf WSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtOu8/2DvYi+yb7MQc9 h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX1C0YctFx4bgccpEu ZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrPC16Il69XkVevt5L3 Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARGBFYHPgsyCRIFdQTD wQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJFREPEu0iPyNLIR4uN FksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH4+ziCuPuLjNclrPs 2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN8V34ZfyRBJeEsoTR RJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqwK10zPSe9L8M0ozBD uspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTkmuRuyx3J88n7fjVm NXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99uit7UUaBRsL5gaLPv 5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/ndzPaE7b2l9qX7d+B2 CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqvakfVp+qk6oEaj5rm vep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/Z39ff0TtSPGRz0eF R6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4H++eDDzZeYp9qukn /Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HOFZybOZ93fvJCxoXx i4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9jdYeu56WX+x+aem1 72296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3RB6kPXj/Mejj9aP1j 7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0RupHrUfPjPmM3Xqx 9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk03dp76anit6rvj/2 gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/sKZW5kc3RyZWFtCmVuZG9iagoyMSAwIG9i agoyNjEyCmVuZG9iago3IDAgb2JqClsgL0lDQ0Jhc2VkIDIwIDAgUiBdCmVuZG9iagoyMyAwIG9i ago8PCAvTGVuZ3RoIDI0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtWVtv 1EYUfvevGJLN2huvHd8vqKUSCaCSIhW6LaVsnqKiqoJKlP8v9TtzvvF6vA7ZDRUis3Nm5txvM/5s XpvP5uLyS25uv5jM/vtyC1CWFpXO5Ude4G/dmrrr0z6vSnP7yTzdmKqxWzAUdWaSosyyYPPJXGw2 hcnN5oOJHq3M5m/zbGPJHIkzz/o8bZr2f0KcZGmWgavbYMd2CbarHkDLdE6u35vo9XoFCaIktkNq /ypIIcnK3JjNy+BhktV5lrZZ23i0A9XYs6M1ZgUrOkg2Mkhd1GlfwGQQjzYZifcGEiWQL9Mh1wFC JYWJFjo70xm38EC8CuQc15a682vI/J2hHthGMgbRdqXzcyhV0ELDMszy8VzXyM4VZmD1VIelxxWl IS0y50vD2TmxvVXcFlsQnQ9scRsxES+B1BI5IAaH154IJvKcKJVZ9VJyKtShIXuVJ96FoqHKsFUc 8eAQCxC2GgkTh7GhUBb7obBddctMTALLxMun+kM4hAHTuBNLYCXbThZNFKZ2F35cLEJuiwdEXLuo iCrkyknsji3DLTzk3MZevObyguccR266VjziPNZDxS5gi6evR1wjuHVGjMTAAw6/ncKCWdelYZdy 1VGNeYgoQk63q4WsHG6QQPPokJpGASz2KNsZe8ynJmSPyEtNB3uEn8iH1ATak7wRPfuG1DRKukNq mhXv/tQUuPTD8PADakhU1v6MWQaLv7ZWT9FkZLUnHiOmRGZxqUEsjKmPQLwBwHEuGpiaTTvEwjWS cISJbaA0zrAEMnWQi3MiILrZPVbUgSl/C/lmziGyWWX+rpFyGaqqqL+fFcqDYP9wh0fjsMtAvV+y 8rZr07Zv591+LeRgH4TjizReLK5lGkTg8CjqvrcXWVGiK2iE5NTbQe/I1kULcbXfYhQ1gNMW49EJ k4rvv0xOQykMrPtR84RKFv0GqZusTpuuqdC1VVOpnz1Qaqkmoxhviizts6oWEvuifzXGrVsF0SXD QgoHYo2DXRzCkVW3U8/gAT/Iz+C5OM5Q8V3+Jz3nyj1JVAolpXc6eyJDEEn1Azau/TFaMxF3vlcg 3PNwC7EM7PrSvGjrtK7zGfUJceeXaKilUbf/D+jaSUb64EoaYdNow49B+vc8r52pMJH2HY1wiZyD qINS8LcGbQwXqwBKaFI4LkZJY6WJWt2oMPQoqnTsRgreaeLgGwZ53XHY4OqBaO1n2LQsOJ3cd3UZ l9wCAo+bZqm5CbLSNFSLkC5G36CLnWpWfKEWP2GSpXP0CnVJ/rFOnec8efeePyXeoauN4nr0HcGP SMM5J/Qq2c+n4SfyJY9KBwSMJzDIqKBRAgKJnVhDxgWnxGPTUxAteYR7yAFzF+srZ9zpGJmWFMsW z0+4k15P2XUCs3NToE+bMU307oBDHPqyXQMDtEGZfrzSKQdg2vnmfZ7DS682a5PaZT2n6SfZFPHj OscX1j1gQddgoobF4PRw8mPHzSfk67bFBb0wSTP13uh5vIQKjoyOXSZq6jat87aeQw2dHol3VyEn nW6Sd+1+3M2WSHjkXc4ydRNrefqm79t2truA8k7VqHPEzhf9aOPMNvvwqFJds3hpXSuIvv+FPnZX VFpuTuzVAcdZ5zeKZRz3tv9zXk22SXu71e2+MDcxUxApX6kYDJOXjIeQN2hfH5zNZ4A2JqpMsxO5 4Blqm7Qp/ERJM1LeBEdcV6VdU6eZua4mRdXuR9wb1npnRKfJ+x8ZgohJm+02ZeHABPqrWuA3b+AW ahoUrQ192zE5cmBaElXCGQgkGiZVbvF7b2qb5GkeYnESExvtQy4AlFzzwBerPO+qtMHzmeh8CNRv e7LCe5RXffO879MOqW3erqeQR9oJmBfDY/E3jIRyBiFlS66j6APTRAIBox5ULNyfwNJY0e2E4Q0G oIxPfwTq2ZyY4ArYIo6F4UKMgPGU5LLkdIbSgGCX8YNjCk425/8lbi6uWVFboOJQplPYHVydqThK nhyScVRYdT1sU60k12cvcSqIrlQjyCdYU0TUEVwcIJ0goeD3qU4uLbYzT6OL1e5Z4jhGyLxTqWVq TBohAtIU5OpK29OnZ2OGfVZ0h2UiIPtKgyQU+SkKgYp3dF3elcy8RTXu8SCbjO0DvPIgDn96SM2c FnzclTu0w4jHfRrwgSrcrtwzGjoQ6/57HUi2lkbtcEG1/wnu7n/KZueOKq40QPFC0hq06lqhre1i xXMYl2vXE8GHLNhu56kTRiDwdCjMhBLIGUqyFdEdkXwIRA7t7EPite4hosJSDpeozhYT59qEduF6 7/0x5t2TJFO8f/JnbNtfkM8VVRoqFp/l4fIP8OEmGPeARemnT9uCVnKlmV5fxv2S8iLiWDmFKSQB heL5kjIQTD2uJUZEoVe6e7sSPdmDr2QhsO/wWKe6uI2nWc04U+2AZGmPmuiN1TzR3dAlHMF4bR9U hUWnXV/vPMfGxxoce5fxAhisgM7p3Ku5u5s40cZyIK85wqTGXSEen+zl5QfxGhBw4ocUjlh4yvZ4 DzSqvB5Ne+OqmzHq7AUxsGoCg06fd3WGVoqvdYaDTec7QyqcLYZTKqFsg5ySOlpCXAVV2G9Dl4ND 2AcfbBAlQoITpDA9QYAVCe9CPhHS8vnhCd7WqQtuQdYXNmhQeIrOneGJj4a/y2scDsspQulwY48v kcW0AeryDg+gpUlg8f3Gdrg6vFLy5PHeoEO9e0ii52eiyU3TZpm6mmGvfLULZSgYoWwVje9CCGLE zeE6YpbbVdS6R7Hre1RUUJ7ktwdUVLzyyD8MRZHhxadpM4cUn7qn363lA3mCL6lN32WFfOWWn21R F6bO67JvMjykDr+Cf/80b80/+1/UW35Br0o8ONdVZz6ZupIP4vKJ1sE+jmF52mNf8NHsjirIfDR/ mQ/m9X8v8bqxCmVuZHN0cmVhbQplbmRvYmoKMjQgMCBvYmoKMjE4MQplbmRvYmoKMjIgMCBvYmoK PDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDI1IDAgUiAvQ29udGVudHMg MjMgMCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iagoyNSAwIG9iago8PCAvUHJv Y1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8 IC9UVDEyIDE5IDAgUgovVFQxNCAyNyAwIFIgL1RUMiA5IDAgUiAvVFQxMCAxNyAwIFIgPj4gPj4K ZW5kb2JqCjI5IDAgb2JqCjw8IC9MZW5ndGggMzAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ CnN0cmVhbQp4AbVc23Lcthm+51OspZV2Ze5SAM+Mmza1fIhzcJyOmk5bubXjTi86k4tMnqnv2e8/ AARAKiJX6XgsLkkA//mAHwB/3ny/+XlzffOL3Xz6ZWP43y+f8MgUZS339MOW+Nt0m6YfisHW1ebT T5vnt5u65Sa4lI3ZHMvKmOz2p8317W25sZvbf2/2T642t//ZvLxlMCvHtGawRdt2Dw2MYQld/r8M 9wy4m8KYst/cftq0QjYuREVty43QYI0S0Q8jFYtZlAmLgsH7pqjLYZiDcLcPIKwjR+EQObZLyBn6 ogGNU5L+vtl/9uwKjN3st7jYzf6CLtk+l4e/k8tTuezkoi2vtQ36v9/cfiXCPZ0tbVkXZWfaGSz3 IVseUknlw5EZ0RAjRu2sINeyB3dYNyFgVk4w4Ztvmyvc7N/yX+ZB2WT7M741W32w2RPNaCZ/D/4x +AMOgj14dxm0eAGGcfPMv/B9TCHt764O0sW/OUovAS6g/LvD7orG0ibnMsRhRFAeWN/+G/PKfHu3 L8577fJcBtcG2f6G0T2PYPrexv/qi3Mh0hS1f/haoBkmMxPVKRvHiBEJ5dr54TW6jrqySpLDjCTJ bFNJbs+FQGALPvVOAhdX2bGtPeN2RAPd96bY5u7GHC7dz35XKEvM9TiG9DHg524LnsuQwsH82nW9 LnbyaJsX269HdhM4uEFgdaY4stjo8Vn+AoMRvrnHQNsoFr5pv+vvrhQjU8SNai9cwew6v9vvhBHa cKUE4N7JRbItlXCHqS3ZdkYCuwMzFEEAmmBH+vEgc4p7Nja5hIYv14lJwGmrqihNaTfARWOOs+v9 y9GZPqRrOq54jRqUZqPXaOseDtvAW8yRa6EOKiQxB9KDshzYo7KpsmTNgUUvpm6K4GbLv30vK6NI C/9U+x1FTdguGYYzSh5DRlKnpTpyLnDJ8gQr0l5uLZ5E+iQ4XLsWpK03wdjijeSt9PEKnq0WoqgV MTtw0bZr26Js2zl5PmG1OT2P6FvkEf3cyOVpmsI2EWiK7fuuqFtWxqlr2h22qiiFEbNwVslWT/zL TsuQKK5Zk9hitq9Oo4oSn1AkVdcXxg7Qf5OaGEKnKpiqdO2Uebk2aMAe7a0xtrAWckop2uwRpZeK P8oD2piiprKFaWdBgKLrVqQD78ny4si2nJ6pi6rbouuaaoZ/+245QaGLIgkFetd2DfJycoITloGe vC/ybX5Q3VPV0zvWwGy/g5d4BIUDPKTp7CyFcDxLRRZSyEoYkDi05ISbZp7EZ+AjXBXSVfyFMePv 5/z39/z3D5w0fcG//3gCpeypDGfVo5pCRU3Rd4xRGnmen0h1FcvVltYULdKcWbk+JVEi7yRR4kJJ MuUQ8P90IcmW2R6CpbvXcpEo0I6NKUpUnLFRK7h0usDL00XfwaTpjtKdskRXBadgtK0fWOEhiFEn bcu4eCgHCWIKzPekVEGyaOqJGEMXR6PiogP9Q14y7IwybkEQ/QnBa7n3eK/Q7MhpzEwe6sTHbiZz hyAFA/oaiyU/99MHZGWsihK8QQVaEhtwUbOUfu4NJxCSAcgj5BwuB9QO2t2nCTyYpO/gpfSCG2A7 2Mqtdwg6hJtM6FAuD9EMI4aDlzQNKbStIygIcOcHgSIYRejJi1fndzqPQpK8PnkI7HCo6qLqqw0L J0PRwSeAAHuK7yErDFISiq7HdkhsHJL/p2r5TaCOm/2r6E71mNQCys18qDUPxj3kTFIHR5wG2xpp s5qGavvTXl7HNiDmnomde0sblf7IIymGalsK3rcOwev8jcCrAal7iZFxXsYPBQET7qEvytydb0Ta A3IVO6VHqdbxfdsQ5QCpb2SIbwUcEgGC+tb3UvjqfhQp/7YUl4OEiHppZ8SMiOsqKkXrO3l7dyVX lQW34fLI6nApc4tkHmv7xiKutfMKJn6jwlxCzU/mTZaeGNC4HIdJklUaWxdD0xPgJFVdM28KHWY6 QyxNZQrk8zMgYDxnu0CViJBVue8sM9lQbTljqdseyRyJENLXKaneERKr2SjQk/hQD11RGTDhCBQS loJeoyIc3SzcOoqaGgukWkL36nAPUmehJ3dX6rKtd/vQ7ADrbFFFdZZnQ4XUsaxqh3XoP4G1n7Hc Xflp7t0V8klyaGAmWxjmVDpLPMsLntnTTBk6y4FLdZaemN4VZDz3PVtkPMyR/JDXygF0RIA5vKIU lkfUzjspwNHAh1wKJwqXUaMaT8CjByrZoSLbRLKiV/1M7H+HehxF7xsfw+velQ2nb7wZyysiFDEL MyhVDQmMBcVpGlSpdc2cC+B30sK9uk9K3JQZSmj5SqPCcb3h6QDt7koeu7Gcnn59AheD4FyboegR nI+YGydGQcqzNDyH4kmmp7Yuy8JWWB6YgoAGN1KOIkaj8kFqfC5aRBEDdFNU1chMbS71sXJb7xyr HHN4HG5CbBWdp96wXQyp+rl1tciVVbeQVpuUR1gVS4CaFD4tQhNgi2qJD6GUvTJj1RPhHi1G1eF3 CCP+4Xxeyc2oQk4p31tu/oPMsRBP8UhK5zIDI0aFIAUd+UucRvN3KDazGfu250gB8AL3y+01mis2 WZSwYWZWFUM/QLBznDLsNxhLQawIeVA8LhmtUL5CscSBDt3pmrgakZfmDFVvi5IUHuRNs1Ke7Rev VAlZ9yASlOVFOU0fuG5+Ls4LRWmWyt3+TASDHlLZFxuBgFxd279/l5OLXi60SLMTqlizq7n6RZH3 uZqjEpXGgVU+Slk7+qimoUwIcRvQE3aucVGhyLBUGhVomDiUL6Zm+8QvBoh1EG+hPvtLnx4hA2XB iPhyzXCJIeK2lrMfGI7l/GSS0zZV0dgBSjWL5mUep02HfPsoO+mGpmhqg7gg4CI7AQ+WxoWQ6WnY 7k1b1JW1DCMRLCVkzGo4bdF/I9kG7lXXxDecrt9JmBp6rJ1TuWiewbq8hqkRDE1Xg8RTiy+X3xA+ XgPB5UJXmxvV3Vrwnpa8ZxBZo++hMZPZhlNmW5oGGwRmYYD1xzgSQb0p8jJtCLhEoVychCQ+HCXC 0YwMTShxp5Z6K++kwOG6iQShuMu5NXEOtjUo6YvUEh1aw6xIT8nzBaVNi0p0UdWip1MPgSpj7P3u kHJoLDWowIB78BfqGcVJBKuXB1RZmB/jJPIRiXFSAhW31s+4tbmKkLixQy6CJqTaGi5Mg68LWMB3 +2f/Mg7QELKKMqPtKotmPaPiDyVS0ZZlGaCMpIY2qLw80eckUWyoYVs9zefrHllJujqdxmZPz4J9 MTOG3LQIXAwqUZs1qhnacRIU4Cpa7BwhzQw4BrMjjj0ly1vqp0MgyEUSZ9FgNxHt75lCgbN4cYRu w9Kh2qhUG85CxU36tBGKhAbYnYO/4jleyDuoj+b23OIdtxAnSq94+wMayBNROj9EMjrUFC3hhvH3 KBfxOYIXsif0lIEEX+mvyKu3AojlvijkWSIYNrwGqjzRMJaKm9eAX5wn+CqhK6drBQ4oukk8qAJH 6A5UBQ9dkUZfUmTCqC/QBhewgZq6NgxLVx78cGAJtZkBlXEpBoCJ8RP44Df1UxCKlN7pO+3Xi2OB 4GkUcoS4aAcF+5k8/Fou2g+bMQgCYlEAiJc5/HqJUq1DK9UzpEhVSUgJBLyiLkO5YRRB6xpbbWrU ZUTMUYJU7r588xXQWGp9c1EN2QilXxg9cVNrfEcU1oiCOKwBBmWUs4pqtMpBwoAUNMSNiYGWfsFZ CAENiPnjRZ7d8BvsK/rzCXY1BgYkRCiC9XDaU0zXcGPioSm3PbYtMkEJBFgrZNf53+Wim46J1WTT I9cNB+504BXbLEPvQhupQuVrDK14jHiPG+XeqkWoCT3lW78Ep7YXTBVgEs47kBGpoEcz1eHUSajx qR+JQZWzxfvYoj+oabKbEAUCKHUafxH4iqO2jF2WovFaWiqNl6N7GdFXYrSJjvLQ8gZwQfgiJih0 7a7rLRRP6aViSAqPHurr9GGIoSdQ+2sHZZtj+zsZVCGCX4F/eiCDmuie7VFqM5RyTJXj8YbS0QLC /8NQgoEfayjJpI4NJRh+NJSvip3LaC85AR+Fr1LnNYlR4hB8YDe4cwIM7EaVAxeqfWM9npZRbgIl xJsz7PXQJ/fXMtFRHW7d5ygQ81Ayd8Big76KtdMNSooIML5mTeVq7ZBfPnIlt+vaoseu8qOwNIp5 wObkcMd+uOtLF+lO8MOTEFp7PxwMfIJ6TQYWnRqRVZ3af1jNgHHBJwjLDWZB7dAhLANvZ2+j3ory QMBcJV3tKxhkYiRthXnXUN8H0VWWvPazh/TLdbxxaTkeE3Z2w1DYksp7gZwcT9cr1SxPeyxylCg6 38NTFDCjHVhqLmpJYspk08oBsjvcaitdPrt/KS526ctSziD3qcuqwORuqg0cXlaanIg/SWV5stIP M8uyaUxnyqkWpCv0msTTFmHiCG5VEU6Z/jcDdgq3OBtxBC5e8X/b6X9rsEutG1D3mqU3nf4LvVjh /ZITWV/WiRXkKU8tTS8royBgP8jyy066YSrwmR8JabX/rQqmNSFKD+hkh9z6/YC6cErD6kEH+qnr O03nB3tTFKaOln1t5/dzm9ev/R7WVad8RGHmquVDMwpJslvUAm6UJGIQBT/CTmMZ3UqMyvY8P/LK sqC2MvEabVujdkxFUuDhwsYjvUa6KNB2NYorIJNgeIX0tD7RwK/ZKK3agEalmN/53X18aAAvXWwm SevUH+mvWpHO+fWOYza6iPhRCVFomicqmFyTZu2rGaY2jaHpQJTFiAPXbFbhOYk5bBRAPEYiTl2R ilGKFkaYTqfQEdWxVzwh0UXhC4uvM6I5IdEdtTzdVmYNIvGkiCMb3bEzB1JkXaYMje+UX2rSQrFK xRt2xAeVlbKfu8t2X9IQ4jcPO1nekTFEpiFgP1HjjmL/ZHmKVyAqGTdcxbpfWJ48xVYp0svuJh1W A+VOdcuTwe3g4r5zU6lktUyxjKGg9/L0Ipo1x5NmDnOWNiJM5JmjCr+7VOiH1z8QdzFppuM541Oi wqIIEecB9EDDgWYC9MQNxYyAPAtRiEDYkK422h3Idai0GUAO46AHr/XqIavBKbzgMTeX+EPgD7u0 yQG05NutIkBnxOAEqKkXlR9N2/h7bE0fmcCsQaSn4RR/TKPYoazcRaEufczXJqaH1c7EsyPCHHYy XQN7lEY+K4bbM/NKQqt/41OzdGeSxuA0jEK06dmClbseQvWzyaEGa1pkcrSMhLL9jBJe525Lr5CR 4TSjHMkjXYiPuQXUc2bCwsLxNHdmkWStz9xujlUOdxJvbdtiryCVOwn5RCyhx3UHfOm64JCvMowO g1Zc5ArO4dK2XltVvojujvl+PnvMd1liHQw/1IUdqE43hYFNQ1i9dLn1SpKUd0wSb3wZYVZYqyz7 AYXMKUzaqn6kXYaQLbI7yiVQN8LfZzkOSVAm0DbAKsOvy2d07hftCEvc60ZZLPlT50u5SOf8Nzr9 i906Rd3THHEG84hbDy37hSbCGdfE7mswbOKiNeSC2ndCe16L2yE1x9MbF2yIfOdN8fyjvP7yw7fy +MmP8iBO1z5iLDQeW+mob5v72jPQ7lYG/fThe/khD7L9n+6Bwr0Uk3+ytN68f//rbdm3+rbL8Iog NB/eCzrZfiR6eUQN/bRJVlMlpGJbSuIQoMofgQOUEYiDr7IDDQUS/H7Pz//Evy/eBq9RG8frH59f fOx4QgXeiin4ATCdwm/5K2+lvwwmT+Q3jSLt3vBY/+Kx8BTBDYMiSyJD4b8XHwW7r/hOkPheHsno b/gFoZ3tf7zQ43QXukXCbY2TsVDaxbhklXRBgo0LIj+Qzvm3wD0CC1qMRHaEv/Lm4ih9L2C248NT M5/JCUF2pU03M4tRemjF1KOEBTv/W57ra+WY6LoRP0MaidbySlrLC2UD9uvh9bmeMY9GINirFJF2 R42lkR7nHm1FlSM7JS2KSfj6hV0RjSQnSapkfd9jIzbvlJ1Cg8InR9yI6L8xT/8a/J054rb2iwwj /dYanD6jSuEc/V+PAWyhSw5Hxrk2mvnMjgyJ3xcalwVhDo2UnI+Rkb9LYjvUltTzGzCQdjH8YTbY PzBfVJ8VDI/aEjIYCvaA4byVSyhIUx1FD/EqjO6UsGQjkAr72boGSTUD8YRA9UAINOQLSqOhFhKZ eeaFNfrqiz+KBT0HGhke7PJnMCD4jEuN/5oUEJZ4DZshfwIhYCh6NlpQnKhkK0hBVhqJY8Au2bak bbIz/AIplRg6TRWAzJObEIuHwGoCMPLNQn2x2RC1nEgBhG9RbrHWVkIYHWwFGv4gjIXoS8kg8RES D2mFJM5f9m8Cm1kDAKW+aOG3ghNqa1rgs1MokIvb1vVCVMrtU/RHQ9yUk5Xncd63gfft+hY19RlU Qu+7ht70iFIDevtuoGnHLL1hSR6K2OvyrZJZcDkUzylG4XLjjr/g91E4pCVJPw/2PYM98GidE0Pp KvN4X5zVgbUXT7lmxn4nmWrO3//Ae+2lE235qMlMty0m2YLljtuooS+vrc/GMdtVZdHgqybMUucK Xen05cvVrjAIG51Th3RYULzSwTLuvG01WBuzXVdhfftedUj2rQaucY0SToyOs6cBHxiJrTqwtwLr R71kcPhaECc8IjnZ3g9P/crt1cc5HkrD8YjUABd81YbNUW9Vl+TslPv+zxm30Fc4ARB2cJrMz1wF RHBxBydkFypCC7eRo2yjCUQde+NNIEbI1xNEmcUQlGa3Ada4VWftOsxWsrBUJgTIIWW/qhKx4Zoo GUPbQ/JDWPZb5xG2Yqcp8pvbLqMLPvmlLNBoTS7bO2Lv0iMWUnFlqSmNu+KSaubLUdX4N5rNQF9t o+93YKPwBMn9y+WmE06tUyYMJbZJVx256ykQaHK69PWo0wOosg44a0lhCsB+I2dAWyxDX2BrwKCl vHmCZjdaioDha7HRkmf8unCCZJncO4kUF0wCyTChpHQhe8BD5GTOaHEHXaU7GBRdKHPjq66pPEV6 RPeIsHQhCx1H167ahOqveKdAuIN83Q39YpCabCmOLjToU4Wk+OgdFWYxdtKUQhnySIyzXGcfNC98 fil1jygSQ6l+G+2tG0z1kCaCV1NA0N7g8ynsDmVDLVioZ1BZUqvIpc8mSvys48NrLfbAlIYqofOo OO+qHpidq3g2OfywylfobGP0FT0mZnZAHYahp5a1wlfoyEIiOczAtPoSX0A0fD5vltupryCVBK8l JJA7Z2PQuKThRF66RXK/lj0twRtexyaDxJC8TDH7WTYyD4UwHvaEruthT7xWwJErZ8TIAPCeXflp OsGbgQOGcd5f4lxBkiHI4iBoWZr8TGIDfWupxgfOSN5+eJeswU+dPrC1Bc5BYEL06wN//z+WXtlM CmVuZHN0cmVhbQplbmRvYmoKMzAgMCBvYmoKNTUyMQplbmRvYmoKMjggMCBvYmoKPDwgL1R5cGUg L1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDMxIDAgUiAvQ29udGVudHMgMjkgMCBSIC9N ZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iagozMSAwIG9iago8PCAvUHJvY1NldCBbIC9Q REYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEyIDE5 IDAgUgovVFQxNSAzMiAwIFIgL1RUMTcgMzQgMCBSIC9UVDIgOSAwIFIgL1RUMTAgMTcgMCBSID4+ ID4+CmVuZG9iagozNiAwIG9iago8PCAvTGVuZ3RoIDM3IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAGtXNuO3DYSfe+v0Fy7J92tIXXXZoEFxo6dsYEkBmafMgEWcDY3OA9Bvmn/ c09dSJEUPSP1GEFaI0oii1XFUxcW/VfxofiruH31ty0+/l0Y/u/vj2gyZdXIPf1hK/y2fdEOYzna pi4+/lncPRRNx6/gUrWmOFa1MZuHP4vbh4eqsMXDL8Xu7KZ4+KP45oGHWdmnNaMtu67/4h3XILYZ rZJqHa33L6C17oeybbs61+/V6n6PpjSmaouHj5uJxfUwlF0ztjREIVz2pFfbb+/fLR9mk4qvrU3Z 22zXK6jXbpl6kPbwMVCQtjHlYAabof7HYndxeQOF2WGsIy4XX91sqmI3cNtradvzzVc3BR7I3wdu OcrNdfi9iXozh5vN1DeEjJsy+DVN+O0rvrk4noeNekdDbYjIn4qHd6uUehJowBJbtVCajrme6uJK gc7Wo22MKbua2Z32vUKi2u9EfqCPtrFQGoDDXB8h0aoWubVy6Um0EN2Zkfu3N5vVTJyWgu1MW1ZY IDL0BoDjl8KJs4PyR/pqO9uWtR1oiISBmN34QaYh2vQd64r8TfOEgsnN4+4otxdbfuXwjxOmzcw3 fULeMJqyGfsMebv3J7KAVmwgX0bJGo0M6I6/mHw7uFnJ5LYHFSotVchYL83dzYZYoRy5kJetXLRR Ozrf6/23zCZlrtw88KON42QzuHe3cVdKg3ZUcUfb+3d6X+6/f7zZX2K8nzYr126gdrByJTQiYAqQ hcwcRllp5mRJJSBpqw4DjLAidTVXum1JkwGDy/3lsD1cMiNw++39z2sgaQb+th2bchiwmoKJqf1e MbGn0B8LtinHPuadDEHoL1AuGH7xuGO8NorsKkCFYHOM7wX9tU0MhuI5aSG0byudefuwGnVYUKk1 o7VR9xkZxYbMKGGqjayTotWCDzDZboFsYquG1XIapWbYRDjWtXVZ14BKkDtfykexfe+vPogIrpTN bhpOFkznJf+C4ydS1seUjRV8yco2ecrursACMAeLnFhEdEHVVdyWhSoviCkX2o5X4DReg+3BRzA9 +O255Uq+fC2X2I0g7+Cow0k/VwATNCpPICtadNwkv/JYeHd39YqfEzVAKaHzSj4F6uPLK7lEU5B+ Pk/uqXYC5jgSPyuqzSjqZIh5mWDetFruBGBIbUE4pkSNBNI0DdfIqK4faCP0RFYb5k2f6FPt4HqP 6VLz/lrf1y63VzAR6PpWH+vTAMrxkF2h92u0bo5wBrjaw1rWtJAje7YGukOEyzHajuB+1DvA7UyM Gyai9mr7GrOtNs5Mbl8pl5R1b4UXygrvRs0dKOYoXltt0LKINtR12XRtV2ASielh73yleZuM5tC1 ZNKyHYP6lf0K7WPsqQx9W45DNxDtcwEc9o+7/eUl3CXiKbTQyYHNKes3a7R3Qh5327LER+qc6FdO Stq6L4dyr38bvfIrm932oJ+kHoo2qzVQQ/Du3y9T7QHGuzV1Zu4nqPYktgYmo+8cN1vAIfk5/1su sNkibJquRAAYdttrtyuyBE+twdaYgOZROuclCMlMqAQxkAXbnJaV6Oqu7GBLJ+ZUL3QCk8ijA5/6 rrUYIVmImIrHA1FlhwpQwOVGOWRhGvb0A7QJP+H0PB/NW9XgUczoe3Hw3wKcaV3pwzeGAA73cLiZ 7dp+eLwRu3srzW75/agvvSggrJoeTBuE7Cge/O9ylZ1H0VWPKBqe8UwUa9ZWGETbBLpsNcAywTEO 1Mnz+7B1YKMs5ChGgQhBAFlP8PmDsPv+O2bkPd5drgsRbW3soFnk3krk+nKkGQ+PU2gbDrtZm+sb ENF3ToCUQXQBJzi9WWkkJhTjtGQz2fz5SgWdlOvk/5cnPik/VxO3OkmZ4oKEC7R+MA4yjRfjv0YW DKKT5XLRNRp039UlTFyVG2OHARyLFqdw5yP0Y2lG02RHIAfPD5GwbJmsiWUNrEjEs7EqLUWeyjhe uBPjagEKcgfhPp29YjYSJXWx+yd8RjRed1/LSx7h0UiPYIbD1/Ut+KX0kVykB/n86xcJx9pxRD6q dvNg/dV57CLWLU2whxidczWPtYHZWOJrsoPNLieC4Sd9TXVAGXTAJfXCCYJwx6hDvo2ADQGSa/Xu vjY+3sg74DLBU+r0n3MwgK7ce+rxnvsGHVK707tzxT3tVR9eb8FeRkHXG2wMDap0xl15zy+axLV7 GTNnbulIWYc8E5u80IEbrS0rZIEzIg2tzO1b7NH8+jcmZwFWA2x0bZsNIMuaDpl12pxByrceAdh/ Fm2DnZMhbPs0tTUDwTre+zR969o2n4rfil9k46dA5xi1olFXbwgxHDYWJoWVtCKykw2h7IxoUD8j R1Uwo41vC2fUN2XTJzOa2vIzWgZb2TydTK6DLdfJqV05Pz+7gFX2SLmaa21rSztiG+nYdOMTrFvf cd9BN6AQuY6RHHPYvrrjztiyxaZUrt8Vbn3oh1SUFQ0S0V0Fh3hsYJjAFM9y1Sesf/iVl2d74PjS SSi4Tm7CUA1lPegs0hGCWWQ1NlqD0ELRxGAN+rZQYztb9m2isdr2ZddgW7nsz7NrkNZe1dQldlew sYAwRNGkauGbhW2gcGqjxIGgyfTt1EZrr64VjYI+8QWyf22/8W2fCteGRLTvc/p2anvxeq7nSbJj N3MTEW79gnQe2zC5uDTWZD4sAiiXIIvfJQOFp5sdwn3qAu4IXRD10wU5RbogAUwXfdcbUrVa6vjo qGqcAvvHg7+SLshmwSA7Y+n7Xe1yCuAlHAIklR35NyGXdAX++usLVp41tsHSy3a8AkhDdykNaa1B orkDcmSIh4jNwe8NQF6Nz8NLK6E5NRc78BmSuiAG4wpZi9y+DH9tjQ34cczz4bffVjOYhTjbM6wH Ah1g9VyKYMSdTBW+NfQOk5Ntc7ABauUfRUls3/qD+Fz8i6z4ap5MSGw74IJpsjTuvjmNDxxzh/vu HfbdKzKyWT6E+QuZIZRiMOoUljONEIVweqGvSQqQ9MaUtE/nWbJZaGGnRGdAOWXzj71J41kI73KP PILLQ4rHDRGqzsYU8pyQndlxIhpvbQ/v6Y0XVDakHO5BjK2RwiJikyTW7vc9VGSpqZ6lZIYWBrZu EQdnul6hIKHDkSZlhg6A0dZQkJDXAnfg9UxBUKoSqgeHIyJ2goq8aG5dNhpykJBFfk0YTSxVlmD9 tAPSk1g+M8pZvI7tWUcmdr2RjwHuRcFEo20w/z7AqCmETxyZoC1vqp+pLpv5Z+xvD37v5llHxoVH mNHGBxOeqsA1823hjJAHScOjWtte6Jp9PpjALknq7p8YTOgYcSpviiswUOrgHs5WBAAz2Uzeeabr wHd+DvdCE84RQIB7yIbDOpKbkBlDI4AAU14Q2fV9j5FgOXUkykh5dTscKbwrz67PdMySG26nBqSU 3BJbON9w6bZjabGzkJvkF2KkbZHfr3sAc4aRLwqhbFc3SGRnOw6IzwJPFEG5pRbE/KgQ8EtyAp6u m8X8tba9cJlOMmHgGe0XCMVlWQ5xZMv23JraRbUu5w0j853GC+rQI7p1gUIFcyV+/obcUGrWpJS+ G7obCxM3GyEv8frbDtg+Iil/DGhEFKCZnHOqElmp7jxO6ph22CK2FWee57xgv/SUUUBoVArR0Ubp YKD7n5kN+LZynElRUFxAu7DQ/6BzJ84wjbcQFphPaSQzWAzSQVtyg0BnglCG/M1VG5xZBaDUpDFU gU2zcgYqUIAVhmPmySH0QwoATlbQ9ykcizw5KpMMUkfoGmN8lmGPYBm5wxXqPHe3Uk9Hf6oTf81l RvuD+vbaio9eBw79qhWWaj6cZNp0oV2dueZDou+Fup4TBojDXmPFwVEHNuCGA7bK4mEUlYFMH208 S1xodVMv3mIjGDmaz9Em1YjErm2JCh8u5QmYx3ESMxaFEpf78o3uAwSvTLynQrmA6DUGPNk9V0hF KO12RyQ3C2ZyIdEdidsFtABSBVaKgND8VvBU74j52Nrx+qAZmLQ5ysjgbe3EbUgoOGsWR+8QXBNw x+iutHCRFI+rj89n+B6RhWo4Zxv4q1c6lOqrdhIPFWzjhDNUsvwMnyFgqyNdK+V663kMuryxQs5E 30L4F9OrhGJVkQz04mmAT0XBqX6M5kBRngkkImignffAp7Q9asJwbIPUe0TRZLqXVu7NJAilUKN6 tb+Qn9YM0SQvje48YSGcRmHq9Yoqw2VLiJP19n65tZpBL/LoZWN7wt5M92DxUjs465lKcI62erJe wm230xUZ54UWkbfc2aRPm+K8vY9zCC6ksW7P9XV2R3wZrATdw6gjH4UJzYbYxNu6yY74MrWUHfG4 iqCmMxWNJSdlNmYBDPvsljip3CqDT6NXvCamCbdIxqL0iEoApq07x1SMfqUbqG4F6+2FXrGJTgub bBQ22cObW7Gk0hTttS+uV1BVm4gdTUWZQnJO5sRG4nlOw0KYoN2SECZkEeL0krcnPg9ElTYEWGxX VuFSZHVptyvAJX9Q6oi0SmZUV5otvIThZPCXmsKk7hlSIBJxkXJzwDP+lt/PnXqCtXQfkVeBOwCv tK1FNQ0qkopkODoVXGXyyYL5PVWsR+hP2gRWw/FZS0Uhnm3MZJilFn4X6Q6IcPiqREB3yHavxECN bGLtsbQlZhEmRJPVA4fs3yE2xrzAafwqp+WCUnWSBYyKfwKjjZajrC+tKsfSI+lEHuAVxL2cTZEy pkayQzrRUr4gFJY7MFli/YXGYhm+ZuXRI8Knmkc3TlTCR/UZp0gDrnEcDQwVAqiBTH6gepM0kIpl bkLZwFMOB3D9Yd9ckkfzJRPkiiqji6lc3AOVCLPLkPRqOU4xaYOyaJQX8nQRA8UezqkxaeqkNAOO yfUck7bzQfjI0lLRPaWIbT3ALnIwMh8GXLscULCtXhrCs8khhhzJoSR5qn/mwjkRqke7Vyx0V2X0 uDtX6Cz3HL/gq6hT6ex2f329h7osl5LYmjBEbSyFgGRz5zM7WUpJVGQb7IHagfFuLiU2YNA1L6gV C3kW0bY4mDgK4vFI4UqGoO4Ut8QKXQm8EdxCQq+PkOByVqq+TAoPlx7Z22DsqI70m2CCzzhoT2mi 7QdAOm2xZOSVrN+TQ4E0FBe86NoMXkz6yVru9gB1LeCY4ItY2qEmpelZcTB6iiErYpCZsDqUVqOK jSA/03NoVlYIKy2V7LAROfaWXPj5IBDWdDhHnTiu/7vXOFYvGn07p/cEfrLJA8ZHjp41OBJvelr4 WdomR4+WxCrfXkxskv+0ZoDjRUVONJ7zeSbrdw0EFaTcAtMI/eB4XPK5WQeZDmDlNcJVvEJoiwuO +/Kt+5BSB1jTLvuht9rDQXMk+rLGDyV2Qp3/iR71Xf1S8kn+9I4+LOlIL42DnlYjR84TkZXW0wJM MwJsSEBXaEhWH76a0Ko1MGk1V3TLcCFS7lYsrXkQbgdsv6Ns/wjXLZX0GpMSB0axM9WiZg7/4Ad5 F1lu3R94h5v4pYoS8k29KVIcsaRukalGJKimrfqS3v3+8DPrHO9sU0/x4z/Yptz/9J+HWDP9MWqX VnsjiV/6nk28pCW9/jnlj058idLFSi3nvkAHN2NzRumZNJSIdCXYfvW4VXOa+uYtBZ0omenvUG6v H29wGI74hyVzuX+zLxNnCTxFAQI99exjNj7oN0GhAzRUFx5dEMfgF+4Ts1CKZJAE2A/7w7W7Ywad OM0UPOuuwWkyArPsXC9clCREDowr4t3DIILSi6M7uMK3Oj09ia53aQDMTHOZDPTxPX+qzotEbRqi XUD0p02UyvrDdIAd6Z+6oIKozER3r0Gp99pW2MnUFgnqDdhhn2mNskRP44vbJuyUv2XeR5Plp3Dc PsHPKpAMaiPBVclVvOO/Jx1bzc0JaHHIXGPY+QTXoGHoFaaOhjBwxPnZGQMnH0ONHsJZXiTuVLTC hAIC8QowAS0ldSPswJ16Im5LwRlqfopUJNxnelnfcnCmJlJ70n61w9MOJYe1SUvztpMckGdHrMhB /pxRoSCeLxKA7yRVR0Etj28LannwD0jhTDDSnMFRB9f2ZYsEKtO545q+XuS5uoeo4MqRFdQ9bHxb MCXsyaGgPJ5S0JYvuFoW0E2i4rqHijZvRJ39lGAil+LNzHkIkpw4XQzBUNBLg6gv6gc55QyF+HJJ 8pZOxGBnHuCZmwsZ9qWTmYUvU0VVrutA8s8lnyNUSaxc609t5AZJC5+WVgsqq2I7g3pBlPtX8Blz EtHKp2NS+OTvb+HBn8xK26Aet6ZAKDfLgJUf/g+yJExVCmVuZHN0cmVhbQplbmRvYmoKMzcgMCBv YmoKNDY5NQplbmRvYmoKMzUgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVz b3VyY2VzIDM4IDAgUiAvQ29udGVudHMgMzYgMCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+ CmVuZG9iagozOCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8 PCAvQ3MxIDcgMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dzMQo0NSAwIFIgL0dzMiA0NiAwIFIgPj4g L0ZvbnQgPDwgL1RUMTIgMTkgMCBSIC9UVDIxIDQyIDAgUiAvVFQxOSA0MCAwIFIgL1RUMTUKMzIg MCBSIC9UVDE3IDM0IDAgUiAvVFQxMCAxNyAwIFIgL1RUMiA5IDAgUiAvVFQyMyA0NCAwIFIgPj4g Pj4KZW5kb2JqCjQ1IDAgb2JqCjw8IC9UeXBlIC9FeHRHU3RhdGUgL0FBUEw6QUEgZmFsc2UgPj4K ZW5kb2JqCjQ2IDAgb2JqCjw8IC9UeXBlIC9FeHRHU3RhdGUgL0FBUEw6QUEgdHJ1ZSA+PgplbmRv YmoKNDggMCBvYmoKPDwgL0xlbmd0aCA0OSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3Ry ZWFtCngBtVptj9s2Ev6uX6Fd22s7thRS72oPFzTZZLsJ2rsULg5JnDZAit412XwI8v+BPvNCiZS1 WcubwwKiOSSHw3kfcj/HL+PP8cMnX2z8/kts+O/Le4BMmhXSpx82w7es47Jp09YWefz+U/x4FxcV T0GTlSZOstyYaPcpfrjbZbGNd3/Gq7N1vPsQP93xNhNxWtPatKrquxA/vAL1//2CHS3IbuqmyG0R 4xTWVGljQHZt27QuQfanuCyAsynrqIPddLC4xoK6xbwbb20P+1/8Z88i7JrRrp+jiccqjImLto2V UUR1x6loCqcSkxqDxe89OeSQQ14T8ghSsCqGN/HqpV0k52vstdrwdyHN5TpOOtiDdZy58S3PShbJ ch1hwuKhv7bhTsrfJX/3K298zr/lK9tcMGTxE+P6nbcpGfSOv2/5+wvDw52MLPyLmx1//+DvY8wj wvZr7iaLmey30BUZI8t5ULaq+ffimhuhXb60IloVDH8cckm4sJglC+GdIA93Wsdv493z43Q8ErsR yUFKB6KzTi880c2bzX41E0GZS2kX64jkptBtomJMm3Sjv422OmW5/fUEQnsDr5syLSrYVX5A4mrR G/moLUa+LValSXOysd4W4w7m2WKV12mRh7boYNFNPG6LU90W2WJmO6cV2KJIdPRAgXNxRHkHijqY f6CsSIt6cKAeNn6gU5yLLauhc4He7j5Mdy5ZFqpokZWpbVvEg7Jyjt7xbDb31ODI+MF2kGVRYAel MXDCdUmbDM9Bin5sPFFb61W4LC2or/IxxBPilG/DQwaVdQXlRsQZoX25h7N6AN/RHeA44SqTQknU JsNGWaUbkbPPnCS2yVmW51mRnJX0Z70d77aPKAjr1poyLZu7WDZqJKHVO0X3rd7BfCOxViK1F4Er hX1Tq7cmH2rwBB3Q/EdE00A0Ua9mFIITW6vqen78F8RCctqInhpzqUGIoQYRkpoZ/DpisAKvBAjD IiAirbdAgeTlMYbwRGO6g47N+yCBKb+NTVGc0BFa/nWcTBnCJ81E5PQauBfqIYRS8xgN9lNkFH/Q UzoViHSB45duT0GcVlJww1zlhc7Vo+kez2Smf9DIIdeZSptO8WdKwMQOyl8lSqekQpOKJ8SiM5UI 7enRQrnAwOkov66j49OCg3Ta1lmTZkDUqxGSHUoTwZTOf9xtzZSki5Lmof+AJwf2vFQbcFq6evVi Mv5e84sSaXZdNwFm+MI+vz0uS/Kti7IN37oQHRj9oXntkL6C8Q0JB21B6oPWpKlxv9s52ReAv210 9J/fIS0iiPZ/ZhyQ6PHCO4gzbd2keWFQt4DBAzpXT4/n79cCTdvmaVk2wurBHsj2l80m9XQV6W2X BtJBYQGtHHv+b2l1uNFR5eG5gim006LNJdhHrbB64/LO76bw61DZywqZEVR9TCGx88n67jll0ff2 QByvJ+j7gaA9fe8xn6DvXxO06HuPvq/orqHYIjxWb4hlaUW7VVpQdlZtUXaMv/J0Hd2XMqyy9mQs sn7A9VUnY0U60AinKGxPwPnX7g9wlHRE57+bby6oWAFEg8wy1aFzJf+Z4txeCUED8tWsNTZgI4lD /ekd5YrOdUHKPKTl7JzI9Cx7QgLGfsgrtFkuWVl0tif+Gba33fwnYCwdBw4GtiPtwHZ02OcrzDXg K1Y/c4Xffr0JjnBHDDjQ2RZ1XNMgcUx84tVHg5ZjjS3Q2bHgQncwcsXRBZeP38bYPMz/D2Pz0N/H 2F6HxvbjCVLjyG0pvfQUrylM2tZFGyejhO7XqmeqQRrwGoW6SDjUL6v6l851ZExro1XgDaCWOnmp s4dY57i4WG5h/6z5y+2G7JGDLUdh8ASdLjo36fJiv96v2JdgYL55hiimhAOHZ7jHab3wb3DNwoab 10PlhOHCYajMPjBh12/fsQvcKf2N6ZjUnYOP8w9xaSDZmb7xnBaBKSWGVSsiReMl3Zgz5J2Odlv6 coEgJngTsHirO1PMcCqAaOET9VGn3IaZ3SrobK/5MF3GlHfd6QmvpKYIyr6Cs4CK3JVnzntAQBny DFIf2rGPMOr2XR1Fx8AgsQvNObyl4zy6c+pBHtLQpSV1l4O1OkwsxhrtqduWCBvWD7qlikr3UGBI nQKvubiIXBWlc7R80jkini6OvlHwLbTRVagOhbSF1GjW9yrk4Gu/G60++t149Sjs3oTdN6MyYe5H qy5/FD7rEZ4oo5S/2mDwGxp40SIm8UuEpz9DB8M8hVnC8KdsfpDA1k2Ttk2Neg3bDiuqp8fHVL/u yVD5+XVPY4o0M2XOexwe7YPW5W/f4ZJcXCwrrxazRtSWGA+NhvYdz2qfqGExhksU3NXl9hai5l4I hH5ea5e1D329w84VzFrIYD4ALvDR0TFWyX7MYWLVPMTEKtrPDjC9mXJ2P8lBPRe4KVui2sUNJcl8 II/VCyjzxESqr6JtWbfpLZKmCDIRsQTBoY/F9WpSlrjeDWxkZV5Mxt8TXtFLGd6efMT3TNAGr1t4 Jwiw9/kZnrdQtEPm8H74whWS/OXtavjylTzhUZl/5DsYrtIIoXtkkl0mXRP4dmSa8MrbZtAla4pb Dpfoo5bsOnjBIroQQPB1L1izBE6fqMVdWTd4qQ9lyhl3EEQ1OAQdu0xmDZ/zcibTcBFHeOTtT9CH 72MnO+3hxTlLtoKvDhWSrjK6xMjVjVz4cgJZhLFoA+0l/6Z1pPZAIwG/F784CH0MjVYO6iKhC4Eu 9t38IKu1UZRjgUySPOzngo0s5JwW0BtdOpJrcppJCzUd0Mw99b0ohl0R70hWhA7sTgCw5+MnFLrZ oJgTySC4Ocl0ha7b0jFrQInj3QB84xEWTXknGjrgpq7TEk/8cVLVeEIKHdkUD3wQz5u2xst6jng+ ghnHOdYD+ybPbB1eSFHoHBD+CFp7LP6D4r6/kPIw39MFDy2V03MPfe+Dp19IwbFQrqL5oJqtNhtn 7t190eZf+7UmMn3OSKatHoKrUHQ/9mmHZwITSsbhka2FezZ0rz1+bq6usLFei+IfE7jIuLigqy92 Ptnyx+vnoT+Syygi/yuVXqaVXo88qMABVt65S6/OWWLj0w4/etFVt0NFlXqZ/C9FCGkMlfp8dp8M mpAqa1wFvVWyt1e69GITcmELhzmKSZK5pVwdXD8PCZDA7qqO/epcsasrdSXskLq+3KdwhwR6Muf6 JMjWtkZKjCzokGenZm/4B6wg9eQXxtaM/KvImTs7MgAnGOiQUxIP6FXIp6vKMKusUA0UeC1ORolz VzlXyJtIJ2aJiPicu5KJjMqTx2cQ570k09B/k4G8MepOlQwlLP7dRWvwfF2NbgGDcUmXiAFJF+Vu kqtt+Iyab8k4/vOKsy/pyZBM03+2knE3wPmpzDWq9morjEYNhn8/5y+85H30HDc0KYl5RNY+N1/+ DX7Io+8KZW5kc3RyZWFtCmVuZG9iago0OSAwIG9iagoyNTY2CmVuZG9iago0NyAwIG9iago8PCAv VHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNTAgMCBSIC9Db250ZW50cyA0OCAw IFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjUwIDAgb2JqCjw8IC9Qcm9jU2V0 IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0V4dEdTdGF0ZSA8 PCAvR3MxCjQ1IDAgUiAvR3MyIDQ2IDAgUiA+PiAvRm9udCA8PCAvVFQyMSA0MiAwIFIgL1RUMTIg MTkgMCBSIC9UVDE3IDM0IDAgUiAvVFQyCjkgMCBSID4+ID4+CmVuZG9iago1MiAwIG9iago8PCAv TGVuZ3RoIDUzIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHVXVmPHLcRfp9f MdauvLNaTavZdydObOuwbCl2omANI8n6SYAfEtiA4f8P5CuexWOtJtlrJzCw45keFYusr04WOT8f 3x1/Pj578Ys4vv/l2Mr/fnmPj9qmG9R7+h/R4e84H8dlbVYx9Mf3Px6f3x6HSX4FL93YHs9d37aH 2x+Pz25vu6M43v5wPH10fbz99/HVrRwmk6ZoV9FM07wT4XPbtG3XH2/fHxzfQzc2U4f3wwqGJevC 8P6Pt9uZP4QLMkxtM7TdyAnP+Yui6UreweB7tuRj23Lihut34nE224r8GtDvl2bpltTS/Ot4enqF Yc7ieHpyjVmdrpqbx9cHen/zUn1+ox7cPD2r95f4/vfH2zfbwODNu/MZW1vRdF07p2Z/8TR78g4M a782Yz94MjPLWrioAIAntHVYgbeZ8w5ISl3Bol7dndRi2ddrtagXOWsXKado57aZRilJo596UBJf hYIubTPL5QrJXtWQFQLsdpxdq5MZYtDLoLBNYmBqPxLXPXDla3xbo/FTOzXzvHK6lQrfLT54JhjZ mGvg5u83Pmyw+mdxOH2sPgV4zh00Vr17rV5Ie/GhAZr8F1DmRT0lHcZTTfYMELp3+l++0GRJvfHw kfqHeFio5IH1EaLvm7kfEhM+Xd5d34Hzm8tLi7JDtscSHcC7tl08wOFUirJAXoSyfu5C3bjJsFGR Lk9wxXMvVk54zPcrXDmkjWLKQTAD21o5jHk6nZtndrk/GCBE/nCGbV3WZU5RzrBB3C9IX84cInz5 sRdw8L5S/7NGqYdxhVLPCydcrtXO1ZDzdrzaNb67rljisRuaETYjQdcpSr7kxhFR2DwMjG6JOeaS IyF5ocwkmnmap8QQsG7f/ihDDGdaDhSzbgomVcw3+KNN7dr03SBoNK2bZkIY7acbbdG0nYOyllm0 IGqZ4dSWCfbGiYeNevOdsp86WOKxFFneIJZyS7EhrvYWPlgKCkeWduKYYUyJRsV28i9Y+P6wNXyL zJZoh7FpV5gtpqAHlSMUWtswtBLtODZilQscmNx7QisZv2aFVpFZE2KeEIxKLIUGM9+sOfsgxDI1 veBKZ41ERmwV89uJCYvE+TUCz/F6HFMpM9yNkRn+zy5mmBEuN8P3ZVOMuAn734kqg7zAV48DsmOz HFaINeAYTWaWoFvgQdLZ39Q3/ThRZh/yDm26BPuU7LXqRTxRacrddWdsBT0FUPHXhJj29bpO5ZZu bYZhHRlntRAWQZZGgZtYzbwt9V3SA0a3FsFz4NcQtznqBmmQVj8oMWmhCSm1w2lEzA75TPrpTNDZ 7up4BCnWg+fPl3FuWgRNSW4udY6huVlX/T9/UKMfSotFLaKfcWVjiq7OwUDu3qzmoW36CSoh+iGI G04XGdYtco7z1DUAnKNaAAwuDpk3soB+QbAJ6mFg/E2NI1ngbMeuB6cx4VfZNlPFacF6L6hazIMA jKIhyKEvN402PzJoOpwoISWr8xSyoJRUB3Bfq4//pl70lxb9UMdbj/THVKQ6dwdVxEoEXqCcpSEH r0gqhm6B6UrMp9T3RhDt5mbqUTqZI2lf5EA0ihsURB3VAoTymAH5q6dahFBLnFmuP37yp0+0eUAK Y5c+P9tfkcehbri6UbRVL0/2J38K0meMoV14VmMXKFEZlgk2zdItWHduGaiEzAwDZfrk+/yEubyC HDqkRVeQ7RhMtMoLHZkXkuXjKi/kS2QZh2YZWuGWjw0feKE/M3R9MLmMtGPt52btEShFE82pr8Zk h6VpqQIfk4Wd2lq2jcnOyJPmgWAVij6frAoeA8ttPeUZxfQAXTuYIUa1QB+4HQorrGSHHHUDl9On 588q1ntZxmboOuxjxatRuuCITXkBZVnhjQWin3gIuMq9Cyjr0CO8Q/6N0QKDh9E+eoStIOmAkTuR Q9a+FcUEegc7Ti/keJ2PlptG5Hdh7PGQKqTxl640PVC3niBfV1FXHpsVJQ+3VFbOBckTS9l72vJb pxThmvqb6Bc49aFjdG1GUgqfUF9N2HBGnSZS2D00ltGtVdkA+aSxjroRJXD4uUo/n78A1CxeCiKH gTahCexuFFr/A21vZ6y/54YD9V1RYp1H7K/TGLFGOf0lpZiVisi/UBcoUUu7nniiX16T+uHt1TXy nxNtB9vpf1BdotxEdNOCQpSavmbNLPIpR18SlNcO/rnnk7aUMxSGLyw2hb0AR2CnpFkX2EVfeNSb AIg8f4wtMgrz5fJRgUIuG31kHtASqv9/jGwDb8AZ/j5GoQPfAsTw90v59yv5903OakeuWcyyNg0b EvObAzbu46IcQSAsop2Ys5gSyr6LtjvCtdoeWCrpoGO+Ics3zdXHtC+osK9c0OG06BTR+KBv1eMC nTioHDXY4sPW+oCUTvDFNCAGUzJwIF18iXGBlM9p+MPp6rli44V64QaqQENRJm56hHMkz8B45GDm 1/RoFn0jemjXuUM3kIro2DTbVxL7JVslzn+qFJMPULCv6QE/kWRy8qYFgpLMivBu7TpyEENqberC /x5bvSPaNlJMZxjIyMrYZDhFGC4lM7NI149RQj13i6mhGrCcvgBIMuk7iEzt3AgxEAwd5VqU+PEE pcSMuo209k+K2ShmdWAxfsO0mBgIPDoYCBJjW57NMpkR5ARa77DpCjvJJGcUsBBy0tmz/f8ZWTia FBFQ9IgqfCN1amtwp00TI1sJOlTo/PyNolhG3qzM68KlCTfYF+wYDcOC5XeDGGhD5n6A+ZGMG9Xm gIqMIHtyYuJCbQirEEiXTvUz9UVyc/iiegPeKaWT8ZIKUP1/ouLzvPg0BlY3Lw18n5uXUaas6DSm 27c9snakiQnKNcYX+WfbULEwRbhQ3JEmdEjQIW+kjGg4CDVhD1VgdMtVwRl2VXeJea0quyCpnVtZ E7GEDeZz4iINDeXlgsRtgcmZV2yns4U2Y2zXK6VPSlHu9K6pUhhkHpRscK2yKkaZCamYUbeHUzGq mLRkV5nUjYXKSQETSoay/IQKbYpynZKhfWKmQCHB8l5K1i6014K4b5gSSraLljnC5VqmgJvwN45t A9lTVbsDmsVVu0NqQQoXPXKUpvUhMQYUjvwl5VmU9eFFqLYE/WE3KT1Cuk4P9acEYPJZnX6f6sGW X7i4PtTUUaihZ8YGlGb8QIckjBJh6K0xMc/Sog4osU7NAmHSGHFkd0UNnMpo0PxhW2neicVxn6rF OWxZnIwiU2wHYAOwPZdWpYzF8Ux1mP2Ryx27SFMvawLDlbpx0bnoUa5U1XBPYqWMJGYcaLfVBS1D cg2IuFZPsK9zClJxkU4glFix/04cBJDKSW45bOXmL9uFXKRkEJwGgcrjnSTjKNdKxjeiSjCOutZm CIaXnrUy4eWlskam3wX6V2VPZhxWobL0uKAWLXdwa+1JUjATilsB+Y/3EQyjXCuYoEooJePIG/cG yfxOVUJUzVSV0DFlhMX1WCrwA1UJh0lXCcHCQ+JlRiob4OWrffDCKFfiRQKdVQ4kXhh5p8nJBpTt /ecuw8GZJupAgW/m4+gGtQwXxw1plPbZKu082YOYbi4lVVo1HDPWuhSCAYyUa2XhG1WZCTrqRnUR mSIL2hok8Tjg/gjSjcJ08f8hglSM7xJBhvksueKF2jn9lqCco7BRDLEC+fIMDadcsC/EoR+2OEoN BuMGlCayruvcEC0y3wHoIM41aYvIQjyGpTls9FHvBqr88RjwDa40p4OFIuPTrtSx4c2j67XxQYC4 Va8i0QrRCSwQ4t8EaDIWyBMtYZJZHBkeLjhYGWCy6lwXw6SjXIBJz9IEyqQw6cjrMwUQ6idXDdV0 kITdfHHToP+aZFva+CxQg1pwlvXM10jLtlQEvk2mLZdmpVgTQwSmAbNRzTt4hRtDmGtPfGPw7QFu nBP2OKky0+6Xm5ex09RStBWzCcLo6Gixf5QiXFd0QqtE1yHFdxxXW4sgsoWw0Y6BLDYxBkShO0Dc ym+3Fmp7OzgIgY5lCEFPKYgaMdz9tRKdkWblOLGkRnTOybaYHRc02sAnXOPkf+g57q5rolbRohlM jKjAM9KVkVIIBeypeeRdpJfKPw+yBwH6afJP6NB29YwtP7rMG4GGRppggAzqkdmqngnCY990OMaX IlwYKOMMgedSBF3McV5XfOwnzjlHs2O4tjjHMZMlZpRrZZ4WuuXc2Bco4++U2vamAYZN2iHRlqge MrWdTAMMWAihWIoY2IMoCMEJ0wgxO9VCOOlKyCSTW07fSecBsltvoLr0NpzIjI3TtpWNTjh2G8Qh py/eVhgdndUKRrcgGORRbHDSQvWtgXwYxRbntUTKawG3OyM0i8CwwTx8Ri4Z5l83xJkjm+rA5kR7 Iniov7P9HKf6NzUHw2nPQkyIxjTblNYaq5azTcsXH3GivzaU1mJVItDslNdy0pW4IXvPkh+ZQxD5 WKDcyW935AmvJW/ZkgKww5QIQFNO7pOj+kUdztTX6uZiBgE4/Sy3OBPCbQY9qPJBbJqb0UoQxyRg umkRRSRBVJpkpfJcbLcYUZvlOe2U6HLSBSDl4g31S6E0Zh2SfZhUl8+l8pRvFGCZXJfGCJwM5vPQ yS6bmc1232z3bLF69zi1jDYVQNfJx1LOCNQTlCdUBSiPZpQtaDOUgiML/96z3DLfbXEzTGoQiMNP eLMMx/0J72AmFQSTGO+DGW/Wdmu8ppTx0hGiPZc0mfGKDsME2c9eKS+nXRnMhpvhcCRIevkALpq1 uQZFMait0X4rXtx2+HYvGXsAXH+Jrj1qssfCBbg4ZShogvKEHihqU0tRzlDQBGVqB2klmmKesUiZ Obry7MlUWuCqkBBNO+XSnHQtmELjosDkeDfWC4r+e2fTfNoJiP8m6TTxEEK9FDbJfHqwJ5CtR9or n2akK1ETpqEq2GH0nXgeIp/mA9Xl09T7xDNGd6gH9X1zkNcIAirwSnfRoQ6aZTn9Sy9Mao0hjIWo FEiY3EmP4MgzJf5B30pJp7+kQ0DTtexIp1wXEQp9SD3peNHfRBMuPdNnlfU7/U29HPaZvK9AP3uC ZvZ7/6EmQzrbI4JU33yiX7G6dCRMswF7z3jTfMuvSIa3y4EHVSh2eoIX1AsiS6wkeCMVB+MgyDnI Tnpi60J71qyyfuyXJvSUQUrnBOx27SkTuMw3mN1pp3Y/TroSztA4TzrKvjjWGZ6DZEpi7/7LavB4 O14gJdJb5eNDvNitOD5tjZfTm4wYJQ54e5tExDPOKf94eA8MHUsiEoPQtQJbI6GY/wG7lDiCAjA7 0saG5oA5QRkbLP2M3vgU5YxN+wRlXIwyoy8mSTnDwfM1l1ssrKVKbbHgSopIA3fLMhjtShWkYi3n XcWFjr5Rwbr+eDRLyAZ5Wne7LJY0tDUThUpXKbDyeJd1YEonEoM8hZvKHIW3sOE+H9xnmCZdyH9g /IRY5Z1ByTEQk0R+ljvhD/tZ6+4TfvZAN2RnGUz/JxCgpnR9vF6eneJm6bpZPViM8gJ5aW8shoy9 +XB94kBd/zVznHHoZRj3naNsY+RzFLjwhH5tAgfacXlmUKSoOleDdiW6as8jXGs7QgWUP4WR4BzS 4fkB7CwJIr9kFTWQDXTHBe7DlLMKcIdBZ6gFYjd1nvOt/H+9B6T2ftRf7yP1LX2p5zRQ1AcKdBgE L39RT6c7s5X05dfy82/kWTRc7rgdX7FrWmG9RtwE50nIRBqlrik4bKtdE9IfjS1rg3Nua4t5x1lD XNdGsGWkayvtYSijXJMbwOj+6aIqDBO4gWagBkHOu7kEt9C0R0AVuOabrpRNDQKguk0gQttP8hSy wq5/bhhmGs/Vk+/8R+rDlwqv6g1A86unkMNLrpELZgXOPAiKEi3YL6gmxXCxxGJrvXuitaAhfJHb VhheWwYL9gyp6hTOBRzcWsteGmyQGW2yiKy66gF9BHTXA1k1RrrSVt9TTWYDuCT4g9Vkqhq8UUiD 6m03ejrTYnEVKsq6ThtzUpBDSDGFdkNJifpEA3/6V6hTeUjYyp17RrZWQmE0K4s7jL4TEN//hj2Q TipucssVTRDT4VJHXSkBD4FvzREN1yBZh4s1aEHPWyCbR3WyoTtPZRjFSNfKJ8SV8kduAGNeYN02 l9CzdCcUkDzWRE4XPOwloHCPw/a40SCBkDBRayrI8cAqyFuesFf4XFmHF+rcHzxVzURtk9ueEyVp MiROSL5mIXc/1zExUVMRLikMR/GSKQyzkSrBGVbqVdMVo++MR20k7qz3iu07RN/k4/lIlaV63wzK 60K6VkQH93KMtzZBjvMJ0UHbtnCxnHSBDLhxC/re1HVK4DwMtatuGpjQBC9/WEFyHihkjlnmwVvY UDeZ24tTg0Dr77upCXoOd3S5SIeE7WfTb53liSJtgZ1FzZ6uLSVh7TTl6AChvUEJP68XDVKVeWtt 53QLkMblFQbbUts5fZM2nrHyxRHOggBg6vBDLFh3uyTGyZUWqMPMaMGPbczYlUkOAqi5zIg8SH7J gO7s40XCVeAXFGfMQk4qSAww3v/kFb4qrI22JqAWQv5GqBOPyUAwk1/dysp2x2kWBhwS7OiOUUJI GILkgC+y0GKADaL0MUUZ9mUrqrmBxuJ4Pp9+Ne3c4XLH0EJ/+nb7AJG5sr+b5pGuLIaQb2GlbvoN NY+8O2CHrmpVJUC9G8b4MdYKRQD1Rt1hpooDj+8pGJjygiJCMiQqttks/yKYJHLsj4HKWQTIicGr KnB8HxYT2o7hSEZouFa/s5laRG7a3v0X0ocbKAplbmRzdHJlYW0KZW5kb2JqCjUzIDAgb2JqCjUw NTYKZW5kb2JqCjUxIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNl cyA1NCAwIFIgL0NvbnRlbnRzIDUyIDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRv YmoKNTQgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0Nz MSA3IDAgUiA+PiAvRm9udCA8PCAvVFQyNSA1NiAwIFIKL1RUMTIgMTkgMCBSIC9UVDE3IDM0IDAg UiAvVFQyIDkgMCBSIC9UVDIzIDQ0IDAgUiA+PiA+PgplbmRvYmoKNTggMCBvYmoKPDwgL0xlbmd0 aCA1OSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVxtc9zGkf6OXwGKFLnU LiEM3uE4d4klm5ZVV4kSunQ5M1epUpK7OFKqcvr/Vff0TPd0DwCKwJI6XbkscBsz3T09/T6z+8/8 Tf7P/PmLjy5/9zEv/X8f3wFUFlUTPtMfrsK/bZ+3w1iMrqnzdx/yb27ypvND8KjaMr+q6rLMbj7k z29uqtzlN3/NdyeX+c3P+bc3nsxGnK4cXdF1/SMhviqLsnRtfvMuU77bvs2bEbx6rp2wXb5ez3c2 lUVXdkXfjxZvv10cjNZzXQ3g2ki7g7TnXP+U7363v8yvXL673YXnBT2y3Xn4dIpHle8O4dN1eDwN wGRGvns2hLcvw1tGe3WZEQL+xDNfMNqrMPRJmCgvy/CxCA8m7WdkhpE/5jc/HKsl1dgXrvTbyMoX txFMbNS+RSVxdQkS47As8/EAKUPmtGI8/nbz58t8/Xpm2uOarivKZonY7tv160nUp0/VxzWDK6qu W17Pz6/CQv74p5vwx9Ow66wRvKG86byvvNs8hIFe+fLd+e1lwBNULBP1OedJqVYyMFUmHnIm/Ih8 M3Jeq7xK2NcxlYM3o7qKxp8Fn1Vc3F4ezr9aL+uZN+yHvijHvsqbunosnSQXMHFcNSiwu63Zwexh YWtVfqZ6Hdx8X7sxN4jbB3ou8rcTz2WwC9tXxfMH8N3XYzGMQ2/5FszPNuMNHrdO+W6qNq8dgGmc eP+QONG0I+JEP1jEDw0UE3G3ZWmwVyKUK1jZ0VrStnXRVa4xiI9xuNZBkWCtlrRdXfRwhAskEOR+ /GD97T8uYbbkU/AveQ31xDCF+OZt+ioMp+AWR0BRKu+bAAkz0ykOXg2vgq/H4Ie4+LKBf0iWF7fm WH2dbDwCIkJWDVOOSiskIMELifbxeQkfj9XB0a5f18ztOdcPheu8QkseKCq3YV0LeIcB8crRYqZ4 sR9rNXmOt3Lgt7b8HqPJjFf9hnHT5DeqduY3fnoUv2EQP9RvTBJM8huKXTRn969Xv1ov7ll4aYe2 aKqqN5iPEfcnHcfYFq1rxwUSieNgJd+YP2AvEzfVNXVR9mGHp3p5hWTlaMXsxq7oRlgv9uCR8gfs YZI/kGK6caaYv3wUxTSIH6qYqcRJLxW56CW29tfBL3/zAk7beLBsVXKo5WDXUMVZdYYIq2hG+f3G DQ1J5yS2da0r+ha1NNYx2dslFV1dOGfB/0xVdByL2pGg4l6L1HYPygL6tirGGr5TET/UmL2KmlzR q2jdTHOu3z+Oiirih6ookvAkeSEdVezSUvihuEAZvlaD5s5zbJCbw3kuoKYCayPioJqTurCr0CJp 4HbmNKCat7s9FWfIEoaSCjL0FYofATHmtqEWm7Y0+r4pmqaE5dXNxJeCtg88RJpSNnQgfh0Yufgm PF+ER2r79zAzk7ArXVPUzdLqt9h+Ep4mBSdpdC8KHe3wtw+p2ZoONVuPJpnifWDJhvpvps+KnPM5 7Mkvvv7l18jqaFcQ66IWZCsrcuN0UQeNJchOqWS77Vlj8IKQsTXJmrqTjehV9FMnT1AHrDWcWfbY VE0xoJWyhPnYWEHe22aPdQPJDI5ITNwgNqDk+uU6xL7ilAsWdOCwJxAd6hm22NMz/gMLxru34XG7 u73kOQEAB4W3PPQswH7jYbeXe19nHXj8qRBnHhqehM6JjOA3/CLhLeBKWDoktMOK3PJcwyNaVeSG 4LVeB03kGW/Cp3UIco/Az8ykhAxrL0iIqIoOZSImEmbU93s7UIlDmOTZXjFdubC5EOT+7bC/jQyd vwwlmkh63POSr9Oll054LVgYJT/RmfyKHSa19LDTsini2HnLyjN+oRP5r++9MvzJ//tv6O17bfGo ngsOHxry3fXhotifg7X1goKFZcmhgmvboehKWNhcRMe65GoSrf0OVNX0BADm9YrWjN2vLr5/9QP/ jXrZr5aboAcFez94IcpvmqQQkQyTWX4LgZna6XjdDF52APAAb6z6kYlg+/ivC7+zOiCMz2Q6j/rZ b88rtHFJQTAa8PWbkWht6k1dU6EDVNO5zJLc3rinWActO+jHhXccoXsSjPw0vAmjwosmjCV7hjma f8Mgfj2aXs/raz/q9VMEf8w5vQpuL3gOyogApAz3yCVP8uigJvDEaQOQvPBBLLLyNOsWj2zX+w+0 FeAjWEp5/dUmfkLE4bx+orYdmnAVzuGuqiWenkwUic0ZO7FeGrN41/dl0dZKM8MxXwylWNjGQBoy 0C5VrX4o0VtEHkDrmldH0cncXp7tk4BRHuWTNQcZR8jTkauZC5Tsau3ilrJKtCTGRbwbhJaY4yRB c2XVFt0QhDZXUPiN6PWhjRk1+YzzZxVd9Ox+nBf6er2xnE6UFqn9WDQ90pm5kGFJ+8OtuLDh7PaS 4p36OAlq/tSI7D0swrtWfGSFl4+vkBKEAcE4s92FC595uWc8/z8lbP1Bo+jmtaoaVWWFwzscyyys 8NiIBZ8zy2XrETqQHEVAfm/Y4eIULkgE/xbeY16dUqMXH9kvSpz3sOBtv3kK9wVxB/8JbcDfwRv/ 4Eed4V+kk4wHwgU2poejG3zY+3+fMgUaLjA21DAnvHj6N88XDhgx6s/+X34xmonRxSfklmIEHQFw jEA4WL+B7OSCL5pqa4NmYlUizEHac18kAYcVisMPSyHoWggIUaLgkXjPdkGiPFFig1+35mfe9MLU sEE8vISc4vq211o4xR6KoQ+LMiqU0WUNkFjr52bRwY3jUIyLwtriP2d4YVGuqNulTTiC31AdUtvD VFmhOoSPnlnU7ChcMylyTVRl4HEIaRxtED6Ro8ID2Qg5WegDPfjdy/COXROP5AePhMGaCXI+wzOw 9wYpeXVQuptuKP8wpIIi0cTvoX/0hAIaIs/IZukzo2eGGC+sm4JGuhD+9AwvozLeWwiFveV8JnVq rq6Goh/hN3EoOt+H/fm5ryWYaSa5vnuvDhqHiiOOkhCPLSE++MeKRf/RN6b+kf9//X0oumFUo6v7 Lu/CVSo8/M2oFpdHWLvQHPQ3o17C00Vqa+9dcXA12HH5BccQ+dUCBVKeSGHbepgOrafx8Ucp1q4s +sYhiM9JIgjVUA2oEiksFO/khffzxEmd79y353CJBA+++l98lHEIxapEq6+gzUTRoxPWtOUiY/5C lMjivgZVksEsdZJ6KiKn0ffkCacUbEXefDKxKRTywcbYuHjsBUKoscTJ/Znvwks/Fpe49hZztNY9 j9ojTBAqdhUv8UmdA5PzwEyaqMtmn6JJ2RVS7Br2b4OzYpLP/M7zGpj+hGfmI121L7AfVJq4tu6L oYP7CFvzGKXJ9DTCtTi0H1tEItCYpwPnvDSWxXXYjMOFtFL4tagBS/BwwT0Ankbixh7y4IvD3MXj 7RPKWdVitqizm3T8fejrhwV1vuVMsCj2Z0PIQ9CiozxL9vCa1oDPUvYmFW/I+UQmaAZ53UiEkcEo GQW/5tVLs02k4Kd6UYAazyhtvzB27RB0MURSenIsxOBBepWfYpiKj9CpSFg/UHdtvaxn6YvrK9xN wmnQFaQ80Rpai/gkusiGEzo6UBtwL6/J/+cv+dv8H9tv5lrn5abdRhzA4wwpvxrpjXdgcghB5UP3 Oy++sFW/93sNk968+JBjpfG9xqFnW1GvfOwHFoMh/RtW/9vL10GbOocKxHiz7zYxYmWAE7O0fEIX o25wlwQ9RbSwZlKoukCY6MN/wkf6fIw/Ep+A8hjwukk6aXezbZFg4P5XwslSQ8Xf0L7GDe3/+ij6 ADt0yE2GthwHdI+Robh+RBccx8o17nbWLVKCDzn+LerOwt4bWI3eKto52Xszl2H5+/y/87/6o2fg 9VoJPFYtU3bAjGEnI3aGpigHS5rYodN4CyN2BNbRFVuwDXbiXIaBRWInpgbPrz9WJIz7PB9bY1DI SXXXOxTqyG7IGDrRyHgSfAJPIqa5jQolf5pu9rjBjjQJQQNURNmECg5lzi9On9g07T5arNlKgPpW OIHvFglsWERiMhNR4WB0KGp4p8VF3F4+2x+eYh1XcN9eZkfl5RXd3IHrszRqzsth/LIZC7agekGl Le69wQTa8C2FD/CphasMCKqkIDaU97lOjCBSOAWvxdcGDdaJtP1eqQmfUo746MYc20mAeXOMsDhd p0YQYUzsLriBKIMwMPsAe0JiHOQSJycw7y7IDZi5DLN2lxlmGRGQ20m81gRmkCcOgY3a4FShKMMM I6ewsAgWXkY+z8jZjI04yRd2iXIEX8gwmZ+ZuQLzzmcu6RlDweEmCLFIQzgqV0JkQdJ2kqwg8/mn 1WW4SgOLyJcI0jYaeMAJ1TDzo6QNLErAzI0wwsmK7jfAr8NaXOQoKq+Gl2ghCvL6bHeUEd6lTcHU db5qksKAE3KLO88cJeuOXOq6db7OZRhrLadrcFqfMV1rSlc43GakBCH2e03W9Obm6x99xsbJUbbl a1afztIc7lBKUNQbH18mTcMlXYmcysoXSdOUk0dI06BQKCnTNE1gwWv41I3iIuVFPi5wiiewSZpG 2nh0miakbZomMGJH0jQc/fbEtk3TGMa28bA0bXJbUtM0soFJAYWi5Sd00ahO+EV4/Ht4/DY89s0f GJDW0R6Y7b7jqoNbFbjiIsP5ehm+ArQ+v5+lZg6JB5oSifWu1Zsow5mfNA4W20MJPLbCOlivVDGl yVBRBj0LObQd6SeHCB4isyJMfGnAmNmpTMS6bKoSAj82KRCYzS6YI6/RkukwjDVaXb7Mt7FVYBpb 7SqTuYbPmSv3BRJaOj6kRpwmzCpPyVyD0+6OB6e7QyCsUgRnzFYmGpAJp3kEKz4BJfhQAfZeARRf BH0OfLOVGO0xDEbtqcbIjk6NoJn2sAhlBxd3VciQA+JkQcUVdHwO/6BpnZ0vGZxh08xN+dSx7I+N RhqcUVMsTp2b4JSxuk6bmFjtYy1dphP4CZajyU4ca3BGmEkcDZ/CD+QZ+GSHbuBMazvOTHCyhW8s 4bXg9ccp+M7O9O78QjMNYdNnZ/XnbaYhRZMjK5uc/Z9001zbS1A0tL9Mntbh4vj/j3aacrI23s6r O2mnVThZcPSLB8HeQ04mMJOnQdl8nPVRjfM0gbHOU9FA7TTSS5+nqWKubqcl7HBOFmEmT6sqfD0D hktuUtppAmOzjjnGRlu8p50Gc+ildJBO18lJ6HVtaXUlp8WTjtTY4NL7SO1koiZaJ9ROpSWlbaOV fbXFpWH38b0AnBgv0Sq299jUlzlSkH64AzVOL6Tr9SD2K4fr9cMdskILEmf4j0KnxrdHep/vLu4J nRs9Dh18Oa6m225L+xG2Xpd0xA0Z6gO0c3H5GzIb1vCp5jPcNn1rgzd+ai1bdGp+4NShGkMWE8Qz Rf0Q/s2NGdc16Aj7o4uFvYZOPdJW91jL2FMJtUCmxKU2NnX6PtLNz0f0PyZ+pcIPxOALzHfsS2xw r/5OnjkJqEo6AqMfs6G1yL5wQ8N+z2VVh7ui7ylS6v8hlmURZAoOjVOxQFBQUiAwPrQEY6IuJFJ8 3K20+EwDczqZus8xS1eECgM7PD1OVZAvEGYnS8DnW38U9qRFGDNsgVHY44axCY9EN86lqD4NhXPG TDEbCZpiVpFrd1xhoXM8EwBwRuaMUCKMF+FTCS6QDW0vlThW5of0xDefjSZI6p6Z+UpbhTWTtD9L iERkoBKxCIVIbhaeEPH50+QMTyfxCmw3OlmBFD9gghHpXIXRCgSexfm2UBFJ2eJHFhYSuSA9hQFn ZhXdkzcWotRFeU3GJxMFxKqWaBgjnKklZW2iqjKfYdSpyQzMrls3wK5buYwdbp2vBaPC4tkvjvwc vjn3+S4kmA53j2/NzqqHz9nh7rv4W2XaVv4yldOwVEB+kQ63cvLwygnH0hyjvGH6yinCbOWEexBU qnh3J5UTw6aVE7Tx2A53JE22wZVThJnKiS5StFTwmcpJYNNwcVTldHeHGzbAiYFIf3OHm/vdaG37 ayvz1vZCJzzfxX75f6T98juxTcbRxSpci+HhEdvfV2KTcY/Tdu9xw7f29Zr6FJHntEuEDYzXajL7 A4hT743yf8HHK4hVXfvuRrXIRevI0CYAvhgJjOc1MMEYE7wJRjM0QenzmwlKhgWUNq1YwJnO14hP bQs5SYiB1sw3AUtY94FExup8E5wUp/bdDU4zN8Gpu8NguztxlVHm6kziRAXR7szABp96p4ivwa+z hIOXOFFBnwNfpCxsW+1RBlUllJ04VUHEoQ7FgFBJxJQD6UWUtu6qkA6piT8wQnIgTaYUp8BN392M jbkhLuOLIJUfhXmckoPKfJ8mgj26yiEwuGrVFJ2/RIdwylhdZ6KRce2aLsl6LB2FAadJowRucQqM 5nM6a9Yu/OQC4zCjcJm/HWcmODmSIvDZ7zVsCGB0eVG/BRDa8CNaACFpc/K1Btvi41sSaEYghcQ9 BnOnNXG297W3bCvlzjutlavkG6OmFT691IpqkoptPdZdKrfRDcYPBy1drhwrOnGrRtsNjrCgHT7P QfLe+HFkLSGnyQyMtFC6wfT7f7hbacRjYhL9KO+8N80N3SxSJr3glCbCiBuGGcqxGWxgpL+fqRlc ocUpvQ5pz56c+J+fW9sLnHW4Btzc7Edqni1hf6QO14BqcRx7+oI1liCViSzBVebq9n3aO7sYMDo0 GJHxLuPesIBPXdrUFvnSAoon2IPTQ3Uqfzj89RygupG/2qeHDsDLTDZqyVKi2kggxNeRmjoYiESe CHofUxmjpHGiWFboE0Tw3fjgJSMJtDzxqwQjnFycqCCytjhS8cWQIwzaxIjGM8Y4VUGEcW6WMCmf PMlcan5J+BKYryq4MWWkEMOsgRERka82lyKikAIkBAl5ZELlqQtlGMcXhRuhRIYFRmWQMKwSkLl+ S1lQXipxrMwn38TxWgQNPhUWceoZfVwjn+fbFmDSmIoDLRFGiEUqESOMyKDCrKTNpLgCzU2TFXAk N1u2RJCQK5xx2mbXIs4oFTNXYYSTFd0GARIH3WYxHAkIaoEfVE0sxIAsvgjWHDiC1OLwa101XIy1 OAP6HPh4JRRGw0pMDhxhJjk17EQhKNPg0NiUqIK1KYEZm1okw+xMbSqONU4gwoxNGTajTRkYSTLa X5xv1D3CjLrrfLUphaVVWdQVwrmk0QwTOtasBAZ7Jj6jlke4wRlhxGfAmRmedG6yR2txqoWuwPnm fwEyl1q4CmVuZHN0cmVhbQplbmRvYmoKNTkgMCBvYmoKNTM4MQplbmRvYmoKNTcgMCBvYmoKPDwg L1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDYwIDAgUiAvQ29udGVudHMgNTgg MCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iago2MCAwIG9iago8PCAvUHJvY1Nl dCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9FeHRHU3RhdGUg PDwgL0dzMQo0NSAwIFIgL0dzMiA0NiAwIFIgPj4gL0ZvbnQgPDwgL1RUMTIgMTkgMCBSIC9UVDI1 IDU2IDAgUiAvVFQxNyAzNCAwIFIgL1RUMTAKMTcgMCBSIC9UVDIgOSAwIFIgL1RUMjcgNjIgMCBS IC9UVDIzIDQ0IDAgUiA+PiA+PgplbmRvYmoKNjQgMCBvYmoKPDwgL0xlbmd0aCA2NSAwIFIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzV1bjx23kX7vX9HSWPYZWafd7Htbym4kIxck DwvvzsJKojwZSRYbaQGv/j+Qr0jWhWyemdNnzjhBHI1UalYVi0Xyq0u3fqq/r3+qv/nus6t//Fy3 /n+ffwSpbboh/Jl+4zr8Os71uKzN6oa+/vFT/e6uHib/CH50Y1sfu75tq7tP9Td3d13t6ru/1odn t/Xd/9a/uvNidvJ07eqaaZofYkwzWPt6WqYa//Vt/f9/qX+o/2//rKowq2PbtG1X3/1o5tePrhm7 YamHua/jFPswxz/Vh/9ob+ujqw8fbn/f3YJ6mNxvbyuixL/49cvb+s/13e92WSLoMUORSg3dz23T D5OrB1dQpJuCIr/Fj470Sf5IynTVIT4DTXerpHqMI1ZznmfSI66540V/oYvuves38K6/fZb1cLBQ 2yxjuy7tUMPb3Lw2LbnX7MbGrUNffarHoW/6ydDqj0rDUjdTDzf8qGMN7X/qv3p/A1/vFeADt6jY LR5UZxmadrGiSR1yXkOrSB2mta5pozoyVmmkjuysb37zuSNjPLTDEl/MnHF2EzwUthvmkZ1xjhvu mw+Hm/HVixtdgp+qs/Zd8LZM0rJ2Tb+St3lJFe1slnQ8Ghl7z4t16Jp59ftp5CMj7qcD9gqfGSX3 EVMuS7O0fknWZoa/1J+qtW9cZ0kfcTIwKfgWfEYHConWSMmBH7xQB0cRKb8hLLoOHJtIIn75YPBz 88KuJQwNTYbrUCERx2TnVH7niA3ig5CxdM0Q7CKDExrtML9zzFi/6z7WiatuFQsTiEZX5piU0ALz KhkbBfoZbAyQKKxGySeB/ZbwNHY2k4vjw/ExJc4Rjg+iVXTMxPFmrNA2lvZnVK5QrUIsQzq3omBx rkSIMYZ4shkUZuAPwLlZM18eB6EJczNWaDQDpkM5YxUZL5ZOeEar8Fh/IKulK+vofh52h4h0dl5z IvNAJmE1M2+IozMPi8ailfcexuOj+9IpXRmanbdcJn6hZN6ipcxbx1cyb6V5PRlhYN8AYQzDVRCG W1KIMeDGcKPDVTUCOwUUpRDj+7s3/+2hRUQS1R5MdS+i6dYuO4FPIRqPcS5CNMltRojGQitGNF2P 2yef9xbReFwVAY5HNIBbAebsRTRVAmEF0ageZyOa6hSiIUdycKt4WnhEIzSLaHBsBGfH0RnR0CQ0 cUKPaMCNEI1xw/sQjb8mGJWIaINohGYQzTS7cKXi1JWxkRb3rhxe5yKaGDMEXwR2tT4giAa+n6FJ OOOf1rC+r8OPP7wjHFsf3oc/fvXq6/i7SAf8pL/GY5V57MPtq1OPWW547KvNc4STL9hw2SRdNwxN 12L1SpP8YzorgCuKH77bKkNzSh6uDl9+/eH2hzBgo/vm8frw5YdbNtnbMOrbEAvsmqPGAm6eu2bx 84ob2HXYERT/PRAKiBPlFwT2S36NwO8sye8qxXLGi+kWsE/6SCFcLB7W06NEs5DCDLdDo5DkruLh UJHvJXsHMY0ij7D1DXIxNOaZ3mufindQci9FnUpykvuP9bRYgmm4P5P7L/IsySGecXX8NP2j6erE 0WI4PbdkWZWU8GOy4ccks9o9bv/ZY1bhp6Sn4BdnUskJbL1HFaQlCB6l6ogRlAQNFQ+LB6j35J4S PKIkJtJy9GTVZJgqNDrBY0AwqU6semVoZEl9luUrzK0NT/UU4VnpWKH5i0uf5R1BPCMiE3tYj9R5 6ljWJyDHLd3y1GdZjp2njj2lJ48v8sQOZd11/CmeCL0pNPb/R7x27l0Z8dIUzkf8oPzaPPDp2sZg /8MhDZWRBRuHLsGo1aW5PX9P5xi1X8ZmBkw7TusWM34//adHqF/5X//LotXz8l4JSkwBguTfjq5b tyjxn5GAO7oFCP5hvOrvccGrHpJciFfTlKvgVVIkA00P3btJIiFJwY1Y4R7e7G+NmIJjmr81mIYE Ts+JhAhY4XtMo7OEoiYCrOSSAbDuT8GJaNqKMd3GNByDSkMQsUJtCgwZsI5KI3UEa+zchMXEmADW I/LT0Qk4Mfbs2VcfDs9n3ZpnZuAUUC3TjGiAMt859+pgM3vnZd2KE5DMHkTwVuYJuM7AtocSlZtS APRu1nVwpHzOeb/yapSVrta1n0p8G2PsvUYxyXXXugUe3G/tXh9uXnU3O8QkZ1mWVXUOgUC/npDi bpbmOdK44kEVbaTLc7gQNjXzQof2dj36wd00N+OLV9OeyWHNKXYuOhaCAUwOd9XGd2FDykwv56/V vUZEcqwZZ+9m+Q7ck5qOMtTP3DqPzToly3NearqSI4ZxKtXLJoKuCnCFpACXDjT4BB1ejLQNic6u /fzoDM/4RRLxY5QqyhiAKzQTt/CRW3+UFLuSQipvW9SJOTt5EDIYiTKNQjBLi1aQ2Iaei7TkCGf4 ioJkuK6Q+08GxbkmNMPco/aMueEZFo3y9apcXMhMYSNHeBo78/hKjEr3WMwQC43uMaHF+ZTlwAgI rPNkkyrJxigyTISQMU5YP7G0GSSuLABYZ6Cg2FjVjE2W0dBP8/S3ewTassplS5HCukOiKLvjAgkc xe8VqchAJRE/4w3CcONNZEBOTRvwo2NTnmbewpNtCQ+JNBMIGZ46NuUZU9PDugjsry4qftv0XA77 JTV9RBzCd/rp3PR5aD+5RE6h/b79V0H7PW6Efwm0D0Wuh/YH5/s5ErQfaRbtw70EXnN62tBowzDa J0+8GO2zaIv2WUWL9ru5GcOFqWhfackBdhHazzK3ivYpDg9ewLWBYn7aR3kxDx2z1jExu8lWR/qp 9PT70Edi0tJI2e7u2/BIrQX8s0l355YZTQ3UX1Oa1bsXf7ytkWt+h3mcL9BCNpgoFdihiwbNBGV5 r98fvzP5g/eUvkcGnKyIH++/9H/3tf+V+lpA+wHP+L/kZy5VtMvW242IYboVoUbRMmn+/M/Vzr4e AzWBDZthTMVsM+d70P/G5hPCYVweXkZ+brxF3p9bLc4UYpSfESzheDZ3Au+Jh9IPW5zMl5q2cJi7 T2/tcFoprgXOERLten0yZCIIwnGS1jA0NBmuQ4VkcQAATkxuBJY+SSu0BAfI+JIY8DRIVXmW7ndD S3hG2YEGDEJ6mmdFT8YW+EtJzBia8OSxmKPQiKdCo0g2mEqfZMOZ+yAOrAzJ8hOy8hOSYrRhHbjJ S/kJ6Sn4bWZivMcoKMuqGkpUpKQQFanziQlpeLKCcGehsZiILH1MwTQ8R7M24uOlbOIU86zEHkYn MzaxJD9by3gTpwjtIxwkximWJ4cfhkZ6yrPiVcSTEb291SNN5ehYQ0t4Cl15Wm8TOUYn0cfQTvDU aEbkGFRuxp/iySl//KT6+7kYJGLwNO1/HNFyFzFHGy8Hm/g/8+DOmE6ztG3eU03op7SaID2ccoI/ JD3BA1nHi1QTFjdtsXVeTsDUqTXwfChiI5oMiWg5YZmnbUBTLCd4pPF03S/HtZdmTg2t/gntL0aR c+9zh7Upd/SiERGdAT4BRnvF978ILUTzntZPSO56RK/9L0rz5x4HGOSTIcCQNqyz+19EtAkwhGYC jJ46z0PJWQIMpsULV3bAzs1dTJpqgLG4gf2R0/HP9jfRRyEp3p+nCVnnFYlgCOH9xkJQsjgfC25y ptjAaOdFrafEekfS354WXbZnF7oyVrTfl2TsKlls1F8d4kmUj4qsr6S+dDyX1G+e7zZ+0Y+0RlJY YtQUriPFtdjK4wlHuvElBTufR/Sfuw7NqyvqrNFoSQN6u2c+yWVAnmXLPh21IC4IhAtWu+nXb18k /fQP1GI23qUFmAL7/SUlE4ENaMlbqbJTYGxX4DyNix7lhhW1yAVBe0HGJYdGWQoBtlGW2b9BxCeT L7xdazYTElnzjMC+MBv/6oSvhLE0VN5wuvuXVwpZ9/iWCN8LvsUzlqiFpndK1c/IKeR3itIIiu6+ U+47L82dIp0j8vIG9s5N/617/eameY5VhI1RB/RVx/D2SLUzLVBe1aHDW1NoDDyifSu/1ZrnQQfk bnbKMhtg6gAbZvKbrYAd5/a9h8M0oCaMF51IRn5rPq7QqM6onC+tNA4ORxj1Y5iYmkkmpmY4ppVG A3/IBTnmP5cf3kRKWvOqoRUS8ZOYmpWxMTXTQgAcgl0ZrjG1kEL8u6l/cUAtom1AHAdTQC2BqlpB A2+lJTtRI2bWwlQaRaCN4JWRGRtRcB7BRwPYSqMYPlFYbGp4Co0U5slVMt5G8GpojVh5PmU54AlQ n8N6tWAUboUoQyMkTPyE9RNL6yDWVmN7vGUY3ZtyEJwvUEvrWKURc6Xz+AJPKGd4ilV1rE6MeMoO YVFmx0USOLLfmyCGBxoS8TMrKrES0XyOiHcnGZBpZryMNbR03qokzxE7VLyRaQioOP5Smxka8YyV xt6tP0ulEVCfrwwNh/O3YK5YaXT0ttimwFfMBDzxm71H50r5kG0q4GfoLIQmcRXOzgVsDg0uGCJw D3334dCIcX+g2WIjPEyCbxmrNPZFai0kZwy5gP2thaxOgttYRcVtdY/7v8ve7jU0UudxuC0rPilu W1fOCLHx02Lj7tdSFDlRk5Z/u/BohcTs4mMg2Yw2BnTRIRMAxve4zkN5QwvJMPskXptXapXoEJNY 5eF3eOMEFnr9+g++PPguFAdRxUTmMP7h7/hDdXgb/xTrhvEHCrV7k4tVEfeuS98gI4K6nuoHbcMb MdO8fIH+33Mx7zaaxGcRwB2gusB8xyvZ94UOzvW0imUZ0/rtPB2fTevrN198Qb95udCvv/ji5b95 8pv533+J39xKCHFGCMVbjE4GDqGYplux6nsYNt+KSnv8VsxSTroVcTvwXtSVfInkMc38ZVjQXW9P FR1H+09JHl9/7Dmw6dluY7dPh/c7k7p/OyEIpvRNcVbrmwv800/H71PzZqfDG43oPMVZYASZo+zt W92Au8+yskS0MzQtNU4bA7LEw+PK3d3SonkBOcISa3NkEk5il9+8fLHBgFrwNnBLwaPcjjpQSOTu +mTAb7bgbRganCjDdaiQiCM/WsnwELF5OCq0BI7KeB6LO1lo4KkFbxkfIIB/UV5otNFjedGMJ55R duAJKEx6mmcjdDXQPuEZwwXDk8dijlZPgfZCVmgvJAPtFZPE1akMdCEdZdH4ScOPSZaf9H4qPyE9 BT9xAVbGBOdmKrqs+HBC6G6V4LwXUlqcFnsl3iPW1lWNomOA43MARjTN2oiXdlEOdwkBCliM0SlW gdW0Y4XmeXIkK+OtRwpPLXhbnjo24clepd6feKR4rwZdIsd4s9JIT+XJdOVpvc3wFJ3MWKGd4KlB tdjDBMVm7qd4XrXg7ZAmjaGYu17F2w0d9666e0reDvnKp/vIg5S80WIG3J+/Pfbz1Lwd0qYMLjS2 Loa6uO0u/IhVgi9PffLh6CaULzZm2Ia6T/7RB6uJAIb7b/VCfozD1a6bmhF7xceWsewttHDP+fAX zuYBrT/94lt0TIvtPlz2Jr+8tOwtounwiPhaaIqv6w7feeOX+vgtOqbFa3d3qJsi0bQh1ODrceIP P0iNwr9HtxvyaoyrRWlstg33K5UHtCpNQtiVuXZ1rbJ0ifeOCSR7MYtxtC5dEnL9wnRJSqhAJaUo DR/3ZAryngGc+bECRWL5zOPVoYLfplr9QK00uHM57ndSKipN0pQX8dtdJUbegzZVJTTdvxVeXaNX L5O3YA2NLv/d+/c+3zH7d0JYHM9xNq+vJBoHqh6zkvq+Km6vzUr6UqKv03NZMZQ2Y4nxSluF7s1Q biQd8uk+shY4o6WCqoyW9RnFwMp+tpPjja7Hp6Som0rjDSFpvGFuAI43DImcZT8/fNPPvnZI/CKJ +HG8IcqYeENoIbT0gYAOl3hDSQ8UA+VByGDAzjS6bi3NX9UmpKXnIi3ZMxKJMCP72qHQyoySsYa5 0uOi2WKgNYpVONpUx6Z25slVMt5EN0ILOMTH4Fb3ghwYoQB2Ng9aIaqQhAxs1RPWTyytg9SVJcbR GWjcwsxjIUFmZSx9Fk8op3JOTMJ4tOwQ9hiz4yIJHNnvDbTjgYZEBkhW1Otu4meeIxmQsyJmvIw1 NOKp81YleY4V8/R2i5kSM17GGhrxjMVAN7QSLD3la4duHqSBRCOWp6wG0qdpN3FJMUR68mrgUooU tyGSD9We+DsjE8eNZ4ZIqHnkLQQcIpFDUS4Jxx05mYRD8e1ppSFg4ZhExiqNnZGqgeSNl1YDWR0L sZjmz4QYNiFglTchOUQyNFLncRDrZDUQe4BDZbZ+Wg4Mb8tVe2tYJmGvxTsS9uTVu8KMDlS721kb 85WANksxLD2u8N5XArZ2wzuNL1Dtu0ROHmEsuAWx/ugoNLPRElFW7DuvFVZDWNe2C9ijkrjlXh12 VPtiFG45o25Gm8Vz5siIS037K02W87g040SFEnUitcj5Zt9kDmzLbovjY2YhfFKz+i+v9Y0R1w8w P1XK1Il0Kqj9nT+b++Ioh/4CfHKkLAZVxt1SzGr06HwaqbW2OIXdnMtltx714hn9M1YIH1KHt3hj eedWs/rjVdyluAHqPRsgmt8yBiprBypOFtZ2xwawC4s5p6XWAe/IdpkQMcxrtCbsNEzxrHPDSEUQ lOvNVETKRWedsdOIdrG+PbEC19oAYw8vBeSyM5CNhoaD3YYyE5jQv+fw2dUi72tNYEKc0uNfjSgK 2VO53zrqtOBjvC26Xczqim2upf8MI53YC9TZsdv+3lHzy9It7dyg6/nEVK53nq64Ngd0TxVNhn6N 3dMx7rQS7KNvhF1xOfJzo2vR5IMPcydCZEc/6kDtWrxHhTJUwlrcaQek2Dhq1+IFs3E5sYnNicrd EUlwkHynWhC1KVgITROeNb48y4kaeU+PaUDtF6FxCzvydTEJz6XdAOTX6C479zy3UvIPc+AmbYZw a0BKBDey+o88z5cW195InzfDbmTmsv5XOk6WDtfe6IFTQYjvHDOm2ouK8aYeuNNnSLdT8P+8zSWL kJ9VeJsRn+boaJ/oUoud9pzoBezdoYUPX/kvst6xBNaJvP4JQh7Rw8dCcoS8UpeeWYIHqh4W4+SG wmdk8M/f0GdktquBT/Nf71DvIGehr6WU5KBrbfd0zKHe05ZD6rrIe8eKWEPlh4frESviG8qJENnW jzrU3eDQaYcXyK3+wtqUsR8qwdyrP86kBju7LGRPc93m6gCCpZesHtY/b64rlj8kV6nJWCGlydiY bOLyByd8Yul9k7Y15QrDMMm7Zu1RGcfk0fhe/KlUrm964/Ex5eurIkyLWm7Hmzy8UZNTufhOd8i8 YXwyNhqDLk1+FmWS2HFLPDfpYU2/G57JWMPTZrw9OV0dImGWYnNN8clAJZGOG7LhF5+0/JAPSt9U q52SnoLfZibWe1RBdQlVR4YqiTTUR3kFtThQXlW1mI5VWsqT6Xi/jSs7SKhK7lVoqpPyVJrnKc/G 8THH64syhqd6io5X2UojnvyszjPzyOhp6qWqO4+lBDHPBzy1uU/olqc+qzxVJ+UZaRFuKp3H7+dZ ZZ75/T8AnR9HLgplbmRzdHJlYW0KZW5kb2JqCjY1IDAgb2JqCjU2MjUKZW5kb2JqCjYzIDAgb2Jq Cjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA2NiAwIFIgL0NvbnRlbnRz IDY0IDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKNjYgMCBvYmoKPDwgL1By b2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRXh0R1N0 YXRlIDw8IC9HczEKNDUgMCBSIC9HczIgNDYgMCBSID4+IC9Gb250IDw8IC9UVDEyIDE5IDAgUiAv VFQyNyA2MiAwIFIgL1RUMjEgNDIgMCBSIC9UVDIzCjQ0IDAgUiAvVFQyIDkgMCBSIC9UVDEwIDE3 IDAgUiA+PiA+PgplbmRvYmoKNjkgMCBvYmoKPDwgL0xlbmd0aCA3MCAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBxVzrkxxHkf/ef0XL0tqzsrbV1e+2jAmJAwO+OzAsYEB8cvCI O4sIn///iPtlVeWjump2pmd2AcK7UqorMyszK1+V3d/XX9ff169/8oOrv/2hbv3/f/gWoLbphvB3 +oPr8HOc63FZm9UNff3th/rdfT1M/hH86sa2vuv6tq3uP9Sv7++72tX3f6sPz27r+/+pf3rvyezE 6drVNdM0n0IMtMSu/+883ivwPoXN4hfxPsxtHTh3bWT9/eF83qsgjxRnD8E9Nk43L4+Os+8eQkn2 sfYQ0FQvU+3atv6/v9Z/qP9ZXWo0d23Ttg7b+NbYT7+MzQxG7pxzbEJ9UMSf68PX029u8ZfDJ/7n b/3Pl7f1X+r7X55nW1E/njR2m1AeXTN2wwLSYgOdkv5Ve4t/qQ/vb7/qPN3J/fy2Ikj8h5/tYiQe nMDIDE4qPUP93Db9MDlv71ElhpNuCpz8HL86Yij5awumAI3PgNXzhZMd5nHEcZrncPCiNhyf6Bs9 Fd51fAnX8fcfxIU46KltlrFdl3aocRzdvDat9x3zCKxDX32ox6Fv+on8SYTV3ykMltY4PAGYrDWw f9R/884E/+aNEnjIKqtglfXrk/wsQ9MuljbxQ67JwCrih2HD1KyRH1mrMOJH/CaodySNU/4zsceN Qc5uwgGB8O7gANkM5uiUnu1wqJGIGtg8TU2/rnTKcswfqV5ZhokuK9Jltn8rO5WJys4tzdQHXcra CIOML5JdcoSOyq7rZvYjLLtP3h8+evbM7POUlrKDsUxz41YfkXL0z1WAZyIOXoC2YLzAsnZQkvcC HRxEiKa8hRsc7HPjaab+deiaeSVPB+FsMe/gPkcMsazrQI4rR3xBGFWLXdceAu+nIub9LKvATehx CEaQeF+k4Trj706pNRMMjlkPyZQF81jsO7dCRkXumx3GnjPvprVBwlfE/GjMr0MzH6Hxo8+uMHYH f964hWJYbpOPxX1HEfsIjfeH56+6543ZQkUBZUdO7YYOqclSMszqsEOzmRtzA1z1vCAOFLzkDtlk nti4MTfMrlkjja2zedMbsZwoNXK7HDt4yMfyYmWXMA4zJF+0Ha9Xt5v/Mp1p7pvRJ1oFI/3o7i45 wLvtZ+lwuOaT9lMM9z5124bs2oZ7DeMS7ocV54HKQ6RuvNbALgr3Uf9F+Wmq1A/j1she+3BvFLVX fssAC15Jfhn26nDNMTHBRzMK0NgmLHuifXbIVwcTRt7qud9ivoZ7c8g1o8gkhALl8Lwf3PPEhHef dbgqxOaCBuo9GnjIhpyEucIergxBiMzrAjdSwLxDAw9yL2GuQAMaGG9eTSYIVadSmMyMNFakBCrq 7lwXhDhAAPET2acbViTsC/KvlHnfmroyCMUIUUD8WKodZ+TrqHJLzJNqX91YSud5t6IbdXOHNBUN nkipogYelxx3d8aFnji/ufXMM87vXHZCxnpOhyAJIxqCKoGZat10CjQEaUehHIKukJ2GoGFCJffh 8WSn1Towbw+IkV2pCyMNiWVpltY3NtZmoUL8Q0UlVWdB36G/x6DQokH81oUCItkpOOBDM0cXRxIp vjHkA7pwbCKI8G0XAx9anNygEYQGJst1qYAIY960AL4og/ggaCxdMwS5yOIERo0q34Aya33zatO0 yBkLG0gJUidrg6j+rkrWRoJ+B5kAEoZVKNtNoKOS4DRyNpuL6+kc9c2UGEfowhGsos5cXG/WCiyT dMgXt1JVIhahISzGlRAxwhBLNovCDnwfEY2HjS1T6h5hgtysFRjtgOFgzkhF1oukE5xRKrzW9zBV 0pU1dL8Pe0KEOhuvcVe8kEGxP5ZoNCIsWJNaGK+P5ku9zsrA7L61/0qKkn0LlwLT9ZXsW2G+jxfv CfrtPYF0hkWTp3IQm+9s7wmG1qE57Mb6buwmzvi1W//1/ee/s7cD1Z6bpxAbj90OjMvETljpFW8H /H3BRbcDdudUECb3FHI7MGmto5zktwP+kiJeFhA3l98O0HWZ9uT0dkAZOft2oHJHbgcG+JvBByh/ Kv3tgMDM7QDsK5aY8J/xZkFhYol0O0CmGG8H4p3Vw7cDSYdbaGu+geuGyKPNN3BsepyJpOSNsEfp cPepGWi+MUoLmqWPm7I/r+FW6M3OC6BUxZS1eR+KU8adYiZyMA3RYtqWipHFY8XIMCtGlErt5qJg iLDHECO4T06TinEaOLniHUKMb/7ovci7IEzs+PzbtOQMb6nCeFGXw3uBKnsvSliomJpeLLi9u7i7 v8xzM8M1FnHvyOEf4n9tO7r+Rzpf4n9eXkx3z6a3n/M2KooJe5uebmkb16JotiTgNkhEO7aR9SaN B3NdOzZ9i96wKr8TNbxcaBc/XnkXZ48umMaIw2UiKDypMtyA/O+IKb1c5h3sW5VvD4qb2qVBGW31 wQfl8BYH5GKDdVOPqhOe02haMO9zMuw8rJNhmHEyPdqT86Y9ybCndTLzxIMxvENyMn9iJ3O+dwlm bSyNqkT0eSFF0IguhWlYV33qIFob6I66LaWh5wVu625aP5vj2b+bfvTi5RfxCOEvL19Mt9W5RpI3 EKYRhdOK1kQgTeW1bO/t+dZXQEwxDl6YEMfEThCfsr6kOc4WZJrjlcCs9Unmos3xTeYiKTICa5gj 2NGZAPdHQtyykGWkottxt5bJbh5wMThQYxyYH5DdWZ0JKSO0MyEg7SRQ6jWFmlzrJAFRTbOtqGwn wSCUcspg1KUJRn5UqydT229Q+nrfoOS1PmeMjINLX/PHZ+OUC/msWIcbnAYmPEnVx3SizzLPGpyx mktwCkxw8lrsUWAkzUzIWsWaJ1lwxozjwsqALD4BKz4BqbZ7ag1TaJA+FPAJ6CnwZTsJqvaDQoZB UauyI/00BfkqRB4VeSXWI9IWrTIZaFXWMgyCoF3ncNMZMs9yM8VKzaxNJMnPUrkUKitjkQL7Tut+ s0+zNsHJVqXWTzg31od9Ckzp6GkwMNq74BS44rTWZnAKT2atwI7gxD4jn0In4VPWH8OJfJdyXvqP KiHx5OclwukEKea0cNHNM6QxCbYDNbHp0qGkwHAmEnOegts70GvD/7bnYmYzcZUSJ5K087AdzgSb h8tnItMY1utwZjcUBkP/Lf0XhzHnXAz/jgaM4aSUuxTiL5RzrAPT40K/23RgBEZnIM5swth8Z9j7 qdiBYVj0U0SYOjBkl9SBMYb50Hhm0jkQ0nTMqYjElYXAbFrVYp4zdut55qCPsBgg87TqvMNYvCzT zoHDFrklyLdl180Xzhh4H9cFRV0J93xFurtgqHRe6TLRYo6H+PD73ZhVNKYWWXrKP3AN5onwEWHR vLj5+BP4hXNLgeiRtO+4Th2w96ipaQuM/YItWF+3LXXWBRpwjoZvDRHewnWzDG2P4PHI7G+6g66F w+ymqOatjJ599PzFp0YD5xUXqgGHq/SmWzfCCRqoLjAig7lr22Yao+VsD9VieN57co15uq4bMZm+ 0QDrFtNC55PJjNN1yJ66eHBZ7ox6x8HNEaOL1KDhn9jjIxu96zuM7FPPrWT0729ffvrqxhzdS4ZI MIfR+ZF2c6qwCz9Fco33sV29ET5OvM/WhvYc3azghVND45Zmsp/QezrcMCEB35xdtqGohS+usdEZ HhQt4lTNl9uSOb4YJkUQRkOgZEA7jm9u/ksLy5mPhJT9J1bjlrWcpcfF9TEiewZgCvxDMjQhbAXD IjfRsJSqSdrCxXiPwVcM8GOIQ7odAjLFM+dxpnhWUFI8n41vSFovFeVhEUT4pHhWfFptMsxWtbJc i2cBhUI3z1Lj/ISQtpVvXEwZKc9EmFSRePE9FwMjtkW+yixz8UEbNUIwbGCLKFnr0+dtqR4FQP0o Yc4IRWBMuyioIJX4bCVat6W64tTS1OAs0IEQCvVA9qAloggTIrTxI9JPJK2LmFst4mvZFTUbuAgH wShVXaswQq7wB3CCuQRntF5dqxsjnHLimJQ5cREEjGz3pvrhhQZE+HIrMc0gNksSIJuqWS9rDSzd tzLJe/QnVOQWZWnWy74NjHByPwFZNvcTKrzruX+GI4ZQ7263/QSd4XC9TrZFp0hve26GOM57xRMU 6RI7OPijXYSBEv7wTpUSLHYRnvodT1zfFZopeRcBoaM+yBjHU7zkSZzs7OIf7yKQQdFFvp/OMh2D eLlPhudnOzqEXC7beY7DwNgYKV3sYI2hi7D/JU9mx1zOUFcisGi6CN2E+mMzf2BgxI6Ei3NbejEZ CBa5KdRMFwFnIJok93DyOY5dc0yal+kcB500oRIbieaW69TtYHKct/dMeHUbr9BR3qrH2WzlzZtv fo2qE1Y8+J9htKL9RocryMLzZ6rD62/e4opv7+VocAG43U9uw5B/wQ2OR7l8d4ORGeLD//yZ/4mp KUD+g960xu+wB3CPQarwL/RsdXh3c96a1x5LeHbXtvKkcupb3MnjUjRRK5ikIYkdarUWur0+dBO6 bv71vxKRtzvuDwv84+4VWE/yv82KK/uNiizUaow2Uc3G6OiD4sKK/UBsWton/TxnCNH+CsggTMJx wChZ7AZj8qhB6XPIDUqBeedpcsACTnk24ixFc4bZXSbZRRRGkkkITyYrE5jJygxPTEe8apSm1Y4n lWon7lJkrtFAFiqIeMzABl980mZkHYahwBqYkYUKegp82U6s9SiDahLKjixVEHGoj8Z4hRjGGixr VSWmaxWW4mQ4Kh1O+E34VZjypDgV5nFu18fQ70fLDU61FF1fokM4+Vnd58Yio/VyvoscQdIJXmth wKkXmPKsxWnXc76sfCrOCIOtWT6V1n6cFV7CZWMlnOYCkeZMzs02Yv7rP67iY9/2KnHCe3R8lRhC BfKMzxD1/NdEDi/CrCNeWKa/u/A5kfeHVwGM4EfgL76If0CAvOvrw+u4HMNmAQtejKU//DT8+jj8 6oBs8OHf44jPfPk+oxmRULYL5L8Iq38Zfr0/vMbrTnddhRcLbVIgadmeHMa3/W1r2OGrC91K2YGK SV6Bmq9q4Hb47MK0UnPVoOYW0I7epw3W22sL16G1144UUQ0R7h1+dvNj02o6Jac8XCOtQ9+c2v4G +WPvoIcb6ZCEJER4B3u6tzn/Aw735Kh7+3j8Z/nlgJuX1d+85ERw0Fp8uYMSx/Drq9tqd1qrab0b R7xY6i8yQIs73RcoxKb12ZGgd2J6fCcmkRorZFmuaURP3drM/r7ByIpRm6buxhV+f96FFblAJJdI /9UFumnEuB+N/EYb8NNw8VNfUM/Hbz4ntwINwQ8i2W9c/OtX+OAO1Sf/+V/h9y/+2z9lfBCmnPf6 IFWl/26aoy9fxa7EHIuzHS7HahHXB0nZQ5mawygV9gAiG1PBvl/8IWzrJv6Gxz7fMLOT1qPGWsIH huyWYmFiTOYyxao6h7Zv8IUpuspQQvHLbSFA8DVz7Gg5/CN1tPonnpBZSt8Q+xdNyKzd1hdAwcXe lrfoJ3xDya1oB2Rttry39fSvKBlOuCVhC+RtgYmPIBY64tyfwvRBg9kAun+hhND3sQRmJmRgbP4L Zr6hGydkGLaZkCG79L0tNcyzJ2SENLETJ2QEZnpbrl+ysXeGxTxWHNiObJM+AFm8TjO9rWVa2Oew e79kQiaSqRLXZoZlQIbNjclclbPplz+cQX1BgH0oZ1smhzfHfM5miDD/V+ZsZljGIH/kHZhhGUOE d3BdzibDMgbzlexnKZsOy+REHjtlc0jZ/HxIIOU/E3DBfmysz4oAqtDxug68O4hsz92ejC2lkh47 TNHApflMykiNlX71FM2K9/KpjCng3pES2XO3TYkwNDnQe+8pkaiLLCWqDrtSoig5TfDcgAGGnqll Sjk/iy5gRlkz+qGagrpNFn2q4Eu1jfzRFsb0ItvMRLZO9rrRiBFvlrmWKj6jbD4TpmDdBuliF9iB z/j+MPfTBKQ3tW6kaQzbF6wMiLov3C6UxdpnFJDFFzMC6TMCn4AIX8aM6QsahNJc0+XSVVbQidkI eRA0uCnHMMpFFCZSILq+nbwRgyQEOWNmNoKRI6kpITJrhSDJxMCD0uxshBWKMiwyNWsF5nHGZyF/ MQTp2gksJGm+M2l5L9ABzkImmD0YMsEtQkM4bPyI9IlxkbRZZHYQe5G6A52NMCozaxNJG/hxnGBO +qhGKmZtImk9IZGUPSGyXbH7mAubTvwmFTYaFYQES8ySBCgwRalrFUZCNbwLTt6jPfEMqw1PujbF GStJvEuHQrKnz2A/5WgEXlHmS3nzDegnHI3oqBTJarZi+Xh8NGLrqumj8sdnBfB5VP9Sn50VYBjs hRThayxMHaPs6lbvZmI9ZWCkcCJMswLQDpVT/QXfgxbKtpxiDk05tfrPowRu+IUDA0vO9LnllM1X oO60zpHvQZNNRBVxMYt8ZfPJh6tHBRIqF48KaAY0y3yAsWnm/4ALBG7V7MlTsD7JUxZMSbcTtUQT 9mPnCSMI55Oxutjmjpgeb/C1NDRFC2Sgi+ZT5C3oFqK3Qm20XbrwRS7ePEiUvyJhWfG/QDCmjyw8 EDRTFOf37ZDwpd/7WPFiPLKxI9K7VHabORF8pH2hL+0fk91zXDVBdPHXlxd0yIsShFtDBntEgodv rnqH3OELoSjji8o5XIcZWYxvV5fOzH7MXjK+/rW5PXqnuEbA1HbZmHkkJoy8vMPXCtAef/e/0iG+ 6PMeVHwN+HRTSjO6mf0bUzfjX2LwQ9wlke0YirHl0NbNuB6TNyMCTMp+dDPXDcX0E4ZiQLCI2vC/ jbHlcohzF5OcMciULzG8aXJWSRQMF9xZGmfLF0WoeZhg1PJFQKF8QRrnZ2ok5dKxBpuGabqnMbhA RnCGdJFZsnk5wzT5t7vM6EAYaQrJ6wknp+MMM0MxRnKaQqZ7l9SZwUY7ukuWuUlxeKEBEY8ZWPHx k0icGR/eUMLbAz5x4YUG9BT4mDIzEydYvPoZFjN7DzPs8FIDIg5zC1DrKWqVyfjcMVqegSU4BW6G YgRm6mfDk/BjYB4nV4q83g7FMAw8iaWY9VKnGxjh5Gd1n9Yi2aQIZ7TSEh0DA04dihG4wSkwg9Pw xPzUDIMqLZ+1rN+Ps2Kc8TR+/f+5EtluCmVuZHN0cmVhbQplbmRvYmoKNzAgMCBvYmoKNTMwNgpl bmRvYmoKNjcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA2OCAwIFIgL1Jlc291cmNlcyA3 MSAwIFIgL0NvbnRlbnRzIDY5IDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoK NzEgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3 IDAgUiA+PiAvRXh0R1N0YXRlIDw8IC9HczEKNDUgMCBSIC9HczIgNDYgMCBSID4+IC9Gb250IDw8 IC9UVDEyIDE5IDAgUiAvVFQyNyA2MiAwIFIgL1RUMjEgNDIgMCBSIC9UVDIzCjQ0IDAgUiAvVFQy IDkgMCBSIC9UVDEwIDE3IDAgUiA+PiA+PgplbmRvYmoKNzMgMCBvYmoKPDwgL0xlbmd0aCA3NCAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBxVxpk9y2Ef3OX0FbUjwrayiCNyVf WseRE1cOJZt4HSuVD6o4qURKlaP/X5XXAPoAwdkdzuyWKpVdb4toNBqNxuuD/Ll8Vf5cPv36vSvf vC9r/7/3b0Cqq6YLf9N/uAY/+7Hsp7maXdeWb96Vl1dlN/hH8Kvp63LftHVdXL0rn15dNaUrr34q dx9dlFf/Lr+58tNs5Onq2VXDMN7GmFYwt+VY1+U0lG4o//eP8vvyv9tXVYRV7euqrpuxvHpjFtiO ddV2gyu7sS3jGtuwyB/LXTNclHtX7r7Fr6bcvb64KMyfdaDGZ5qL8m/l1W+OVkqRKLrvocVxHI0c jpX9SJXtd/UldvWf70UPrnDY1qmv56nuSuyyG+eqpm0dXV+5Gdv6ruy7tmoHS3traLWr6hbPvS10 rNDKf5U/qQlNUzXVns9cjeAK3nNbucaS3jKpEAneljowCvXWM1bysfw6L2nCL5JI0EyYd9DHVNVT KiDTvIRxuA7tK8PRwRwW+hUdxAcxx9RUHfRi+TFN9+GtlyXqL1GDHFEWzA8iKYqwABkUJaPnhOY3 OTCPC02YM08IJ0o2wkUaxsdFyNzlgqdqpTDPCk8ysiExjmBkkSZaNWMDrQi2kGs6EyhY8pKhmTgs HAyTSaKCEks2g8wKxmpObbnoO6GJVs1YoRFzQz/ME8IlPKNWzVjRFPHUExKnsidOlivGq+dWBiop 4cdkwy+SICHzG+ahGulq0BNsSPfBj2ceVT42YFwGwVPR/vKpNuLwUEMiCeVRcUd6pqyLoufCmeKp zTQ8NRSR8uRn35kzwTRjhkYmkcfQPE8xd16mNXflKZZixou5Gxrx5Gd1ncRzzaKZtjJPunacCD7n /KzlyTRj5UYmGcs0bKWVU7bYX1prMkUaj8d+MM/C0IgnrlT5P+7Fpy/fN3RxHoGC6HIegk/GL0JB resjPnB1BEGvd+nFDLDSu86DlWa2aKU4AYN5tOKmBVqZ+mpsgQtGx4BMwcqr4Y8XkGz3if/5J//z 8RZQkuCkxcS9q/qmm0oHVJLBpN8TEsLMry++AwrCfwzu24CU4j/8apMcEYUqXisUkApe61fkyOGa RW8erhW7E+FaiosFrvVN3Iij0VqOJiJaG7qmmmHKuPDJoD1aY1o0ck/rgeoCWoMdxLGGRoZPMBH/ 5s0RY4Dz54LR8xI9ZvJMXUBLMjfJQxgfCIpp/gpjmuuqIWAyJ2OV5g8iByDHHsHEFLHTFrKPbgCQ B9R1CtlHrMLHJR99rGfytnMeJ1HjGhGY9PMEfeWcDV8swgPwBK4UBLyz5VvVqUpUnTV0uFRdpEW/ KMDwWNVlMZzoq+/ZabC6xuOVlbPtHIKLeSqVbfRFu79sZhvOOm20OevjUFd9TxOwy2G5v3r8rD1+ jmyfp8FVbd8PhvMJoudspxpQqcWxywSuzpB2rnsE5y0uF2F7urThWlkEwUC8CD4RYWczIAa+jj78 d96z/+CG5qLYFOimntO5eqjcEOcqKKdwwmoya8S91NMNhSUsjXw6XvfJzbOwRucQoo8QVpXE5vh6 9/FHGzIimeFAdrpenWF9gk4iWz1KJs3hGuQ5JroRxIZY+McvTH5hs8t0SJ5UHfIWyvh00dUTO9xa 1dRai2R5Leo6QVy4+LrtV8T96/Fmkm9g56bKTXYDWdxzTr7rCAckbE9X7rpddEMDRLlmF/Oj5y/m c7ysG1xbzau63nBB5Loe2rZqZjrpy2vhBNMI/nBOEYYb+qnqCM7LFFHv8Ie/fhLA7rPvw+/H57nD sesqBA1mJqTzCMps0FHmtuzJH4cWa7HXNJtmt3GHc6eLnHE1+K1gp3uCfWbSGwjg5hZoFFhf9cPS v95dfn3GkW3qeq6Gfu3IboN6DOEs1GMahaYRJfdjUzngeiB5gYlMOxPqrZ5sQX377ELc7yuzxNt8 aLbrE/D3OOMuyTkbtqsg2WenGSTz6n2gH7RUCM1qrh9DptlqTmnr8UVBDDcUOlRdrpHIMphasbsT mLwH43s6JQyUaYqlT/yl+/LRszPOyTQNAOEddtswP+GUZ35cYK1lzIf7nFtzbhGYuGa4I4nDDbFE zMCC3ejWprgPyIwVURgfNXWHoDlCWmLMtslbcGeweUT4Ati8ts3nA+cRvqhJeJ9um6t+FKkTpBvG KZmDdXQudh5RCAV2tqo5XXyLniPKtYxZ5jsDSR3uASQvVqX/xR/OcDmuQ7DSo1K7Jv45nsF1M/Kn C8anK3zdXnwqDjmkNeEzTL31mkLgDKUjIrDcwwqKExCjMZkBqeUBgQAxXrqCLSZj0ZybiyRzh7Q1 otA4CV9UUf9wmz9GZP3w4alZ63oJ5KcaOdU6Pby84d8jKc1NDBGtAHq7Ra1X0AojDoPzeqZZtNLM vngMTKc4L9Ji6WhzSi+7Ow1ameTG53VtCBwi41VDHtseSTJ0XuxRWuLNYieShQ5bDdnACuV+uiGv rsAgjGnFpp/W33y836sNbAbCrka9roXNkYaWZ2YbFGYDUeMqeqZZ4zKpfzFMpZ0DhVc1qHaGFiDY gEcebANn6W6EH2vnGVe3aS5iCzYHc63hRc4PF7gH1DNReUMvSiEVYCaZSnasr+AU6sBQcokHU8mB HyoxN/JD3wt111h+QqK9WA6OrRy+RUNkhp+QSjbSPZGjDhUScUz8ky85cMl64LHai4JqjQzW8rBq QcrdpqqTmFAumNbNE+YqBOsTjUSx6YaZRx0bOm+atmpYpXAtnBdBDlV5ysK8VvRZ4ck1YcgZaXSO Qt26YJ6QySgm5ZnfBKHDRxdOhzVnyDQ8x8qwkwgt0bQZJKYnVfpkBVz9VuZmbMKc6Vit0YqMN1oR mmiAx+pifZW+0BMSp7InRGZn4zVVSR7IpJjyMDsqDInmuzCsApnG42nnojUUhkZKNbILT6NLkVJo Ol47G5TmuxNiL2KHJgDqRYQz5HLq1hZLe+Uuy/sdWiccZoZTHFa6EV9dffZnW9UvtvRfBv+e5jlb rurvu6blCyw6YeCx1bI+Lrtyd1JZ3678YBvmvlvCgRKS5IX9e+/DNIIcXdo/2IiJy4mSKEkjptCC X/KlfdhX7DzURkyliSVSaZ9M0Zf2jS3eVNpP6tMyt+IN6hUIMhq80SH5s6xPM+1Okpaw8tXSPg5A Fw2StU8BwhxS7s/DL9Stji9E5hgaAU/tJqA3zBXxLc+1MyWx1URmok3WiElklkKz2kRVYZkC7iLt TG1qIKeQDSdpocIdFMcRz2a0i74jdBVTFmqFsdHXkYy9P4K+04o/bjUU0BH5qxvgPcH+P79GPYrc D5IA+LW/vgyGcP1b//cDlGLQpY3EFf4RMSR+hl4oxJX47+sXJ9iLF7NeZP9Qw56rpkfqIxdzd7lB F9YlogiUnAWkMKdq7A7p4rp++WlYlldCsQsNX6wRhB9YcnjiwcvwF2Idct6stS/9I98F4hf+j8jq GoWV20aH6d6eoFK1VTd2iDFXV2hP4G0WlWiRLCopf/VwqTjgK1sFi3oR9RVdyaYb1a6D8m01ghlr D7GOZ8xh1ZUkNRF2B4krURch1aQOweG0aBwytARbYtaj2h5vUqN6lX5GjsW/C8IHc/fcLPGcvRrl 9OeT+NP/94sS5zuc6XDWg4EHd8B2rd6Anj7KGxS3iW2zWrk36FFJRII7SE0xMqsGUl8+uvaHCZAJ R+qlOViBfvkfv6iv/M/LQMNxheSfXsCCdg/MuEDfx4E4e3jqux/8r/Azjsfx9eNpRh5PvNLxaHjA UzL9GVepm5DIngDcogroTSFWwQkH2RysaXLVPOLOyS1iB3d+7GWWXf649xGeouNmjbEx59UTm17+ fBINlDInUU+sQDvNCzK0O/Py16vUOD49saMblzjgxYaKYFb/Hbu5QuwEg1/hbHR3VOpG4ixN3QhJ UzcGm2ogKXCVvN0y5LSpFsOQY0aLdnVowpEf1fDSJD8WLH24aoTksXYaSOmTIvHZ2MOrOQQ8K329 EsIueCbzRKsxzxqeMaRPeApN1sljsUahkTYzJWuYb55kxbEZayKsMCTLT8jKT0i6252jAq5NrIGf kO6DX7aSsNU+UWcElG1VcSThqKT09RDRV2I9om1i6XeVp8Gummk4HEx58rNACZK+EpqmtKzWDM9E k/l4Y5HKUxMjZp1mbMKTrUqtn3gurA/rFJrOo8kbQ6MdF55CV57W2gxPkcmMFdoBnvqyl8yTyCnj D/FE2wm/ckLXxLHYKzrZ9JWT/YSbL2KtOqLJE0pxC6YO1x7fBze8ydKgZH+Pqa42vsmyd06ib24E BmpavstC6OX0d0jSkECzXih1cpbBzP1B0l4I9lYyfh8i72UkWcNwK7c6Nsctqqb8XkrbNFniS2h0 suJ7LrA2X/nw3i++08K0WDigiSnxRYZ5cuJL5ibvETvzhGZSNegvzRJfTIv3rlShNp7xkIhdhKmK 1nAeOG2DJCm/1XI81M3hmlTa1lgjJGAQvYp1k+iUNWCi00JoVnto3vafE6C7KL5N1CiNfG+uveMq yLdpr5myOuUnvsvILPTIYE/DkGkYYZ30xQIcDvkUAu8OIixW4ZGcdRGm1XWaUUye8SUCP0n0+2IC j/Bi3bGzZNHOjMB6nPH23irrDfLnnKGZee4OCL3lsspZEyib8QrAHQmtSjdRkkMGGFr33WnecvxH LnhnXWPCmdv2NlsAkoTof58P6Ga71tcX4PBKv/NtO7n8W9p8c/HdgDiP8uNk9Et7vDPx4WjHQ5N8 viFMzeXHC4t4JyMe2vuSn96raQ9N8nr34EnzwOzCsXkmdT14BQQdjpRaWexCQe8IbNgFm8GiLuEk SYpW1mrmSSI4FNfzfMNLINnt43oggDZ6niXnc8Q3nhM1FRSzD3g3vwfuATp9zD7c+gp4bk1TA0Ol pMdiH/y7GuZyWb1Fk4yR3IQGgwjN3qItVhX6S/QWjbR7xiDtPC336unGXt3MEia8LzrPXoMr7O/I FMxNjUmWh/68S9TRdlDRBxWqjPUG+aNtrbpzc1OvTAJbbjunDqUgTLzxRQckVjrceItVxOhywypu 9Cd6daxs9RavnlmRa3DfzRMd9hXW58hvHYpeHeu70D96Mug2HPERrNyfqMtdmWLDOm6yJvQ7A7j6 buGVSbb49Vx+8bkrnO9KfHobaKQXjdZOHA5D/+SRTnXs3bp67hxe7EWhgcAm1rP0fWd1OrpxxIEb o99Ysr7t5kjjL74R9OYoGqbZmyNG0769jeMvpd1n/NXjLfL76RNFY9Rwg/ZW8hIaZHI+u20GvAWd NIoKSfPPlBBok/xzaUikvSU/0yh6gJ/v/tFGUZNzIH6cf+bBtnrBNNPx5sWJHHVozLSsfErLww9O NMvUJnksNE0e2yVLkprVsIQfkl0WRibbLbSQ2fbZbmbkvzgXG0WVlma7RQGJwHEjFwKTUnwOyfCM iiI9S8ba8JRMrtDoJMW+Tis7N5kamueZJb+yB+m45gyZlmjajo02SJNIusQMChqAqUjOO1lBzLcb rZqxYuDEnOmFjD+CZ9Qqj7UmCZ7SKCrTa8VHSHriTKqPjxaToqklFuYVs7CwqCwxVR5vjk1haHbd ugHJukVHol8dr/UQpUl7HtIJ7n6z59oo6nrcj9kHme6xU9ThJSF2wx+4VRQoc2XtHyRnrpKcnzNv cP34L+4Ft+EbQ4UWfJOnwcZ8fOj9XcyZM22RMydzPDlnLnOTPDFnLjSDOvDmAgILX7aVeJVpywvj pJz5wWZR10tWltWPGpLpFj2+twUBR/phVkJv/ouQe5olHjWexTa33B74szJM+rwUmlUkMvY1oRST PseLf552F4qE9En6xxQf8AG9eLh5idR4heYi1N8uT++6XcXcI97dnR019+AgE2r0uVeqJVFqa3g4 DWekvKcRHw0AZFxnvuGtr5viq5neLkQ8vT7JME4Ph/1Hw4vPeCGnxev4qhTeNFvMEQP2DQu5MWBv 8I2pFo1tfivYvctWPJ5oHV/OvI4jAt4wm42p8fk4THG/G+LQf1kdMqjH07hhAXbflwfGDTV9Hyaq a+kTqKf05FINrlcEojj79lDwWdzobtiNGL/NbgSuRXy5QwTpv+Rs3U2k3bO7mRzX33mJ5G7QmBjc zSa3jc+MGXOj9wuRsiU9YpLlFm0v69zmwXQSNBWqB9sP87MxOoH98PnDx1/Ek4Q/Hj8cLopjDcWe 3twc0SE8wYX6tS78t29x3jiLKT8MqN8i57jO2qhx9fZLkhdiZmqOhdCsOUZYk9x+SkuiIYERG4rH S+2Z22/GR/ZC8oLNcXdHnZIoZPILVsLaaO+o5IVEGtoqKSQbSkX0qMkGA9ZIe5wx4ME22cA0Un58 vQ4NF8JRhwqJOPKjGmCZ4GzB0of/hiWPtdOAp7ZKyvgAh/2nv4VGdhMiazveBIFBzujGzLPxTUfi GQPlhKfQZJ08FmsUGq1d49VI1kDXPMmKM/g8DiwMyfITsvITku42VX+bABWFn5Lug1+2krDVvlXS CCjbqhJKq6SS0kSP6CuxHtG27CpPg13VaVIPkdPBk3MrPN57mPjZfiOTjk01mY83Fqk8NTVgecrc KU+2KrXexCLD2rFOsVKdRy3f0GjHhafQlae1NuWpMulYpR3gqa2SMo+VU8cf4vnq//xsn8MKZW5k c3RyZWFtCmVuZG9iago3NCAwIG9iago0OTc4CmVuZG9iago3MiAwIG9iago8PCAvVHlwZSAvUGFn ZSAvUGFyZW50IDY4IDAgUiAvUmVzb3VyY2VzIDc1IDAgUiAvQ29udGVudHMgNzMgMCBSIC9NZWRp YUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iago3NSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYg L1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dzMQo0 NSAwIFIgL0dzMiA0NiAwIFIgPj4gL0ZvbnQgPDwgL1RUMTIgMTkgMCBSIC9UVDI3IDYyIDAgUiAv VFQyMSA0MiAwIFIgL1RUMjMKNDQgMCBSIC9UVDIgOSAwIFIgL1RUMTAgMTcgMCBSID4+ID4+CmVu ZG9iago3NyAwIG9iago8PCAvTGVuZ3RoIDc4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pgpz dHJlYW0KeAG1XN1zFLkRf5+/Ymzj89rnHY/mQ5oBLingDjjyQHxxKg84T9RdUilIFeH/r8qv9dka ybsj7xoKr7d31d3qb3Vr+Fbf1t/qmzffRf35e93qv98/A9Q23WDe0y+iw89R1eM0N7MY+vrz1/r1 XT1I/RW8dGNbb7u+bau7r/XN3V1Xi/ruj3pzclnf/af+5U6TKcQp2lk0Uqp9iIGW2NX/1vFegXdp NosX4n1QbW04F61l/X6znvfKyCPG2UNwx8Yp1LQLJylz7uthHOpJ1gIa+9/v9T+q/z5aw9u2aVsB mp+ZsvtpbFTf1f3otN0bmX2qN7fyt0u82Vzon3/TP68u63/Wdx/WmYEVpSbcLeiOohm7YYJBOMl2 gfLH9rLegvL95V86TVaK95cVQewHb4v4sCZu+FBgpArW3qu26Qcp6u2UYaSThpH3eOmIn+gtMdNV G/sdcLpeNInXjSPsXil4yDRYVQjneefBerWLv4OL/+u7NwQBJbXNNLbz1A413EaouWnJx6XA5uDj 1dd6HPqmlwxWfwkwGFkz4huA+bUM9u/6D+30+EzbI/CQQVZkkDUMci8/09C0E6dN/FAIYbCK+LGw cRLNPBt+3FoGI358fAP1jqSxL85FxriwRiUkfAPC62EdJugpGzpOCsKeJRGMS0nZ9PMM90rwngad OvlFeqxIj8nemdyYPILcxr6RaiE3C4N8HyW3yHkektt2Ei5+BMGxLe5TTuIOCvlinKcR7pBgPgui W4nXeD4xzzx/gtLVDJMGiaXWz+HMa5NdovVJqkbMlOxSxAW8p3jnDtakQ1XC8CMyXDDTWSgIG4nm KAwHYbM8Mw8dhE3xPpWJ6FiA26fRRCoCOQ1i6XOYy6WdZV60CJ4j3DjDfFNg5Rne5x6BjpJPotFj 8S7EDGvMUfjp+QFGLoScG9SQOcRHY30eGpUncb85u+7OIuFXlDwK6lzRK9EgxKY7qDYFO9gVHwXc tekNiWV8fNGvl34SHsUwIHhN2iKXiA/hnYVHMUA8syGxDI9a+uLsdLs9vd8c5ABKDU2vMjqoOd4V GdJlPp4hHYxXFt3Y9LbS8dnVwp42Q4p5Xmrq9LRAdrGdVVEVH7IlqCyVdXJyenGk9JDBXmBtSfgL SSGDGKeOR2dgJF+qHxFXM4jLOc4mhRmhW8y9zNJoSORnF2/fIUTRb+/e/oI/5DAIWdXafaVuLwfk OjokmH1VdDx3BRezpay/6JPB0ubr4C/VGHzDV5TDrJq2jytKBstXlOsicVaqvhLf9oJq5miHJbV4 IjtfixPmpScW2ETsh3FJGfzQcK/bJ04/h9WUA52IFKqcDOYC7q0PZmUf6tYMDRhxPwiecat9pVqi AtHKCVUgslZMoKL2UsEmEhWwQhOdJltSgcZSzSUVT8o9ki4KTc38EvEhzPOc64uqWEC6/wYNjOfX kqtg7aE3lPqhIslQKNjFLjsSQ4fD25S31ZKyJ0kYoSZ5Su4R8gTq8YWReh1cn3M5HRDrhI/mZjdR rNtu1+e/1FTlDEdTyE3AvLRVlidWenCIFtxWVQdHszSWNcexqsKMmhn72TQXNU58qgpprvYwVhYO FJioGY4GmEuRDva0ZeEQOq8uUTxBWQgqSxWhLLw5UlmYwc5dZM8AIvHyUBZmEN+sd4sUsS8LM4jL OQ5uwfJPKAszNBoS+dmNLgvptwtfFh5SFI4IWLqPZShGYWSft0RFobN4XhR6GPcW1i723hJgT1gU jiOaeHFReFCgDEUhMO8IlLm2u+9AT1MztbqTPTSSauWvFZ0NOg76glmOA2EOY3q0YaEHkewC2OBD 9z4stiRifNTjR+gKC03bHyDCt1wMfJg9uY68R8hgfnlY6kGEMe1UA5+Vgf0iaExdMxi5+MURzEqB 6Pq1BFsG3JQxswG/yG4/QVR/qaK1lqDeQSKAiOEglOUmwFyE09LWOMN37XrKOujIR8ZBfmRglRvP 6KyTCiuRtHHW5RcDEY7QEdEzICfpwGBkcN6S2SKzAz04QnRZ2PI4eJhHxNZ6GO3AwcEck4pf7yUd 4bRSdWv9IMtYdMUNXe+Ne4in7oyXTbLcQgeyphZp1CLMWJPWvLY6t540Zy2pYjC+76AAUpTft+fS w8L6yu87wLQn25lwNys+E6YRXOnUn9fvy5nw0KIvOgrMXqSQrmwIw9nbu5d/57PgquRKgMmZD82C pZIuCAd62WGwHg8/ahjMd47eSdRHC8NgFQqmwEk6DdYzaTsc1tPg+rHTYLrHEI5pYRocGFk9Dq7E A+PgAQ3RSSco7ZV6HOxhJi5pWIfTgwkZiJ92lBxg3hJpHEymaMfB+n7CvnFwXJ1zfuzoN+LHwdCY UvAJHSftKHmwsGWywJlg1Tg46iH0sRmEJpT0xycnfdyL+DSbWwAvCgf+sYqp863jKrzMTYcdkQ0b iK045Djx8EOOg7GyrUedOCx6eQ52DDGC+8ibghhxw8T6tdshxPgCm6QrHZ90MIFM19+eSCp7hWss mAOiOUOXWexNHXd9Anpa23GNgsNiOxPCYitHNAYCjY4qIepeyWcTroEUkgn+PgP3JDuE3Azugk7A Lv7nDq1cieZbhoRU0zO5PZGvXrpdVJRrSidqXTs03bjYBcIRSahgF5FvLrQgum5uBkvDJQuvhauJ dvHn2e1i9V013tgYcPtkoFF1RlAFu9ilCzG2skH7J0tDXk2qYAOJMwjZd0AeqcH53ebVAVaqG1aS xtVBMh7xQcNkiYsyghrDGcSvD+JYjZjc5zlmQXafqWdkjIgjabKb4Zgh3h+9XQRmh+7aw3j0xrxd LFpUvYUdI3q3KPX4zcAQvXGzbBG9N+f4s14tSX9SjRiLqx5qCbh9KL0+BDFcd1QURzOIC3w3iUAs PkxwXaX0lQrcNrXXxXwEukYAWr+BXTFihhcrOdGVmZTOdcFmdhKZ0JaQyggs3cz4Ot7OId1uMeLC iKR7Ono7uk3lxHZdIrRdyhFdP2JDxrKS/bwe3+DPQbF16KH9EZ31oBQfAg+KrcPYoQ1CNzq8tj3i g0LgIHHj+wHEzIlXRCoXgVid6SIQSnM/M+5xjRN3vaJy3cGOEakglgci1SynRaR6sjoTpJ68zgw0 fHCkOnMr5+fKVmtb+dOzqz/Zogdvrp7JQ1rJEuEAl93qrSFNPuqNsMC6uYeijxBpCyNOHCmpVE+1 tXleYOlJVhEI/BiSZxHvM/SoD+6MlaXkysO4oeNZimFx3bYPMOoC+daaP5cWhNCHU7Jo8UyAaYR7 /RwtJxPyZWXdrM9piV6UT8o5zAWJjJtVR0Egm5WtbPTdC5dfUGyXZJidGdOn5RyhpmA7O6n4vJyj Ips4Ma+9ipGdWAmfmHPqKdlQrJ/4iproWjxvRMfP7Iauj5CZBWo/zFw4Ae8cBcHLqiUcznGfQaGJ j6jIWPeY90WWqOPlowNPoSFi+BTKum1+Hu1gT5tCoSfn/H6LrwrOdqn3Dyj7Brq5lEPNpLdqxuYb 4mHG5kFhJkYgO/PgHX8Lori8nA3wmRhD6Jr79NiLw8iXMozuq2EOwKZUC5R+hmDXu7WcDLjU0yv/ Xf2ADtmNnSgxnBGM4fRrCWbtJvqux2nnEhFOBrM43Vq9RwsjaSZCDvOYjODIkOOJZcVAHJ8HB3we FLTdQSP2aSHLCPB50FPgcybgmTGq1s84eVgYDaFL7tjxk+EA0v301AIW1rPUqiMDrfq1DmamZBk4 m3Gy77qhLJcaw+lYN3y6EaJfzyzSw76ECRbbp6PDxKFxOqsK1k84F9aHfXpYoBO8gcFI4x6nhwec 3NoYTr9PttbDHsCJfVo+PZ2IT7/+IZzosFKXlf5RovBV4rrWa/yQ6lb0OF67x1Rt27Xkio+N3Uus o/D9n8c8UGuxYuDZ4vYkirYlfoluruPattM/Yhzgmum+hF7ZpGPoMfCQApO8rcjQ4JJhaqCTwLd1 Rbrekm6bBZo9HrlUAhMdR1OfoazccBq9vxQXV8h6GHzgKhOeKX2mfx+Jm+IBCDGAW+44XwUGRjRA lGgDA1QIuyehwUD/oyb4AvedNA8VeHgpDEc/gBm8NYyF7xXzFbiZO3Q1MHTy4uDcbLgKVmpXy1wf KQMR/cS6wHxmaUZ/zZrROuUy9HQhFMXQNiVRFW2BeQKN/LjWyGw6QV0aIuKaGMFsnqOpuO3rjTIv 9t39Bg8R0YPJ0BW9YNJFL1Atvdy8pNdqI8xbqJjGbT+Yd9A0vbtJVh6gbCgapZ6kRyIyyniEss15 Bc9l88Z0j/4Ynn/o3NUEV6bCtk9Of6RdYu/2asDPeGoc7342QP0YDHuKHGc1Jy6I4gKNZ/rQYrgg sZm3ViTrR2Ka72XjQ9LEoNMnIDDvVGyHlGC+tQq6No73RvunhZmn4PtRw2ADlk28nFwi0G/adyXR I6nRRYuetsDTc1quC9b4MHqfk1rMZv+LEzoe1JSwcf3wSk55ZyYS2h2j4YB9GVF81L/j4Xva6hn/ BMYMkF0izH9UYD6PBGc+wD0NfPlX/fODxmUo4jbLeqNPZUfjQlR+R5UdJhhRd0PbPKar7r8ocDa/ 6S7e//oBe3XJcp+CksPt2Ha47INu0jaH/vdDMKMb16oRB78c5nKeTTBYdBMp2wl4VpYInKqjAAmt w3PoRZ2bgHBi4wPchrn8Ld4hWvxGtoNXXExYbxeJYKeubQZBT0Hs2f7t/wEKpT5ECmVuZHN0cmVh bQplbmRvYmoKNzggMCBvYmoKMzUxOQplbmRvYmoKNzYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1Bh cmVudCA2OCAwIFIgL1Jlc291cmNlcyA3OSAwIFIgL0NvbnRlbnRzIDc3IDAgUiAvTWVkaWFCb3gK WzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKNzkgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRXh0R1N0YXRlIDw8IC9HczEKNDUgMCBS IC9HczIgNDYgMCBSID4+IC9Gb250IDw8IC9UVDEyIDE5IDAgUiAvVFQyNyA2MiAwIFIgL1RUMjEg NDIgMCBSIC9UVDIzCjQ0IDAgUiAvVFQyIDkgMCBSIC9UVDEwIDE3IDAgUiA+PiA+PgplbmRvYmoK ODEgMCBvYmoKPDwgL0xlbmd0aCA4MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFt CngBrU47CoVADOw9xdhp8dYk7udtq3gAITdYsHhgIXt/cF3rVwgSSGbCMDMHVhwY5sxIGVQnp/Ii I/bmF2Ap2wW4bzSR7Yi0Y1JYXyXliCN8ZCRqdMegKmDohq7toT8sWmMeejJFNt6H142vsjaG/1XX E+GoOgUKZW5kc3RyZWFtCmVuZG9iago4MiAwIG9iagoxMTgKZW5kb2JqCjgwIDAgb2JqCjw8IC9U eXBlIC9QYWdlIC9QYXJlbnQgNjggMCBSIC9SZXNvdXJjZXMgODMgMCBSIC9Db250ZW50cyA4MSAw IFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjgzIDAgb2JqCjw8IC9Qcm9jU2V0 IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RU MiA5IDAgUgo+PiA+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL1BhcmVudCA4NCAw IFIgL0NvdW50IDggL0tpZHMgWyAyIDAgUiAyMiAwIFIgMjggMCBSIDM1IDAgUgo0NyAwIFIgNTEg MCBSIDU3IDAgUiA2MyAwIFIgXSA+PgplbmRvYmoKNjggMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9Q YXJlbnQgODQgMCBSIC9Db3VudCA0IC9LaWRzIFsgNjcgMCBSIDcyIDAgUiA3NiAwIFIgODAgMCBS Cl0gPj4KZW5kb2JqCjg0IDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvTWVkaWFCb3ggWzAgMCA2MTIg NzkyXSAvQ291bnQgMTIgL0tpZHMgWyAzIDAgUiA2OCAwIFIgXSA+PgplbmRvYmoKODUgMCBvYmoK PDwgL1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDg0IDAgUiA+PgplbmRvYmoKMTcgMCBvYmoKPDwgL1R5 cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvV1BTV1ZSK0NhbmRhcmEtQm9s ZCAvRm9udERlc2NyaXB0b3IKODYgMCBSIC9Ub1VuaWNvZGUgODcgMCBSIC9GaXJzdENoYXIgMzMg L0xhc3RDaGFyIDgwIC9XaWR0aHMgWyA2MzAgNTU1IDQxOQozNjMgMzg1IDQ5MSA0NDUgMjE3IDUy MyA1NDEgNTU5IDM2MiA1MjYgNTUwIDI0OSA4NjQgNTEyIDgzMiA1NTIgNTYwIDQ4OSA1NTEKNjY1 IDMzNCAyNTIgMjc5IDU1MCA1NTAgNDc5IDI1OCA0NzEgNTk4IDY5NyA1OTYgNTU2IDUzNyA1MTUg Nzg4IDI1MiA1ODkgNTI3CjU1MiA1NzQgNDg1IDY1OCAyNTIgNTM2IDUyOCBdID4+CmVuZG9iago4 NyAwIG9iago8PCAvTGVuZ3RoIDg4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAFdk8tu2zAQRff6Ci7TRWBapOwEEAQEKQJ40Qfq9gP0oAwBtSTI8sJ/33PHaQp0cRdHM0PxUOLm 9fD5MA6r23xfpvaYVtcPY7eky3Rd2uSadBrGbJu7bmjXd7Jn7bmesw3Dx9tlTefD2E+uLDPnNj8Y uazLzT28dFOTPunZt6VLyzCe3MOv16M9OV7n+Xc6p3F1Pqsq16We5b7U89f6nNzGRh8PHfVhvT0y 9a/j521Ojh0xsb1vqZ26dJnrNi31eEpZ6X1Vvr1VWRq7/0qxuE80/Xtrvq1Kxfu4rbIyz0Hi/S4X BjAK90FYgAS06g4kNNvsHiSgNT+BxPvca/YZJN4XVq1BwlKFqg1ImO2FLUjAnbADCbNRmMDeqk9g wFZBoRNiozCrlQM2CmhVjAKhWdsIyClsQ5sMyCngsxA5hdm9EDmF2SRETvGe14HIKfhaFblggtGW Qi7cBa2KXLgLyiggp7CUDjYgqPDeVoirQlV7jrgqbEPNfDcLqKPjmYWzsiqumNJcSDDiqrCU3htx VfDVSUZcFVC+EVcFI20j4qrwokaIqwLqnCOuCi+SLy0WUF8w4qrQbEvhysdSs83iypGCnBjNuLJb IbviJ/77t+p/1r37uCftdVm4InY57fboVgxj+ri/8zRrAcsfr9H/bwplbmRzdHJlYW0KZW5kb2Jq Cjg4IDAgb2JqCjQ5NgplbmRvYmoKODYgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9G b250TmFtZSAvV1BTV1ZSK0NhbmRhcmEtQm9sZCAvRmxhZ3MgNCAvRm9udEJCb3gKWy00OTYgLTI3 OCAxMTYwIDk1Ml0gL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA3MjUgL0Rlc2NlbnQgLTI3NSAvQ2Fw SGVpZ2h0IDYzOQovU3RlbVYgMCAvTGVhZGluZyAyMjEgL1hIZWlnaHQgNDY0IC9BdmdXaWR0aCA1 MjggL01heFdpZHRoIDExOTQgL0ZvbnRGaWxlMgo4OSAwIFIgPj4KZW5kb2JqCjg5IDAgb2JqCjw8 IC9MZW5ndGggOTAgMCBSIC9MZW5ndGgxIDUyNzIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3Ry ZWFtCngBlVh5WBPXFr9nZjITlqwkwQWBEEkQV7IK1bagKIi4YC0KKiKLiixClaoF9dmq1BWrz+1p S11fVaxa61K1onWr0sW9Lq2tVVtBxD6faIHcvDNJ6PP73l9v8s1yJ/ee/fzOuTOtZHoOkZK5hCUk qyBzKnEfTBDeZkzMn5nrHb8gRFU6KScz2zMmrXi3T8IXnjFY8d55UsG0Gd7xKLyfyi/K8v7PrMJx dkHmDC99chvHoYWZBTme+RrxfcQ3Al5hPIk5KlWA54//4wr/u0R8E0UKUL83iYQwREl6krZZLD6J z5INXQZllJMMRZ9npL3Uze9o/6YF4sM3w64mtUqdZ30ShA9xrg9S8By4TlLrrIVTPktbpTTFJ+Ev qt4JJIrdgqocxXm+xI87Ryq5KSSZ600qmVfw+SCpZO+SSv4hyZIMJ5WSlfhfCb4/hWdPfLYRnaQf mcWtwbV5xI99TBK5qWQUW0niuYl4tifxzH0SxU0iwVwuGQWU5DFKMpP/J0nAcQI3A+fMIimslgxm 08nrzG84dwQZyScTPRdCwtg6YmA4EoDncPdZTczsNZLNniIRXBIxc4NIGhdN0lAZj40I8Sc8ycOx nvRCK2hIGDHgcwDR4gw56UxCSDuiIB1IR7RSIOlEOBJKTKQ98SVdSSSuDSY60o0Eke4YZ35EhvR6 ECMJJxFEQM+oiQp9pCRd0D+93CZMIkmkhOwnt4GB9jAE8mATXGekTAwznalmapkmVsfGsjPZPexV zpezc9ncKe6ppIPELJku2ST5hud4E5/GL+G/4J8IXYWRQrFQLqwUqoWLUl5ql86RHkEJ8WC3SIJQ IgH16YHKqvQq92my2h12u81qNITxgslut5h1Wg0v8LxWsHoHhjAju6V1DJvoVMOrTHJwtH6EI2a4 X5r/+1nj5nWP7x84ydgxyGgM6miUBDXfkwS1vMbltqyHoSFluUExffRx6Slp8nkz5k+JHhPXN3nM evfU8HC0rR8hnEuiQxsFoLn1VlbPaPVWYtNrCDA2g4blXLQmnZrH0ctwGWbBdmreqdwbB1Z6caCJ 29c3umU0uBgu0uT8EzWrdDVz76COAeiBCNRQqQ8zqVVK1mK2W0JVGkGr00ms+jBBE6jDV6zVECbo tDpLKPeOc3pxo0y2qceNvnDk15n76b/o5nizT1j/w7sSf544zM8YCX2ggpbw0APegXwAnv78U4Ii YE3VWcnFPdLRzIefKXKaMGGAJLvuc1ZJBMYKCRd4QyhRKYneHCigdRmtRm0xc1bVskX0E7oOymHw rAJDaf6FM/VXyhoehCFpBfq/Kug3I3UdOkofifQq0W/1aCGNSE8vaqMXOht0WrNDazRoAkPZemlr tUzGdvOjV/7te/Fx3VUpqG/fbhP0lnLxMb+Lvhf2emnBTqTlI9raTYpXKWEnvS+TQUcZ2OEtKADS SpfThR7O3C6cHezxDGMwaAI8qxitxeywo5MEHm0aoOZ20cOf7E8K9qMPkFIHP123fdUQefBYau6t 2h6ok/4eXdAmEK1/2tRo0P9wp6/CRnfQk206XkdO/m06mvQomBDKXpe2nvD3h/b+MtDcvImU1sOM Z7/SUnrZrU8WIXwRrtO7JWRMBp5htAYrYxSfMI7UKKJaa3HHk5ovoj9GgsL3zYYffx2gVUBP+mIF vPtMAYEwd+wO1pTdhx51vv/q68wsWl7een5eMFc6b6qTm5LPtBZ913LDKyd3Avl1Qn4GKxAT+kET YHBbUhNAAi1GGwYbis6deE4b6M8RyvbyJoUCujwHwaRoJ2+Wd4EK2Lj21t7ndGObuW10GX17yZ29 qF2nF3QxrSCYF8mu25IBEivmRyAyxgjyxFEoASvTFkhqyQBaQevpC7oBZoAWpJBNH13b+EHt9Q0f 1DKb6Tc0Hx0aDBZYhSxOXQSONp/7nrYAFh5GjCtuAOaKGnGKgIbDVPG6V8wWM+dOFE92DKAbKe2p 8aO/yWS7wy8lf4nhT+m9gUP92uuhgD3ReI85SmtBj7pNAgm/68E1xbFGxstjN/Joh4iDEcdgDghK Twx5U1Ki1alZMSU9nHbTH6aVLYqx+dA6maw6+PhwuECbc9Y2uci4BD+HEV6FCduAumhzWzTx9Myf ExRB1Mm8dlb+jz+9GXibvSvpipjtQQCHmOw2q8ko/mwipLmzUYsoIP7Yu85vj2+J2lRZtSQueveH yZmuxlPzwxdufOTo9fHOkcWQRWf2uNP71cTB1h6D+g/LWbXrpP6nqNn9IjvHxo8oQhaI9YQLwahQ 4ADTnNe6VbSawgQHFyKc28v40d9l3NImqUR3XXHsd7qWHkdFptw7ofwBV89y/cR9jasxv4FRKd2O RhRUKUWpMdu5r32cP9On9IkPpuiSD9ZVyCQ6uofucU4CIyLIMIinu+kZ2lB7AXQQBaNFiURUXeKV SEPaANWdCNwS6sDQTIe+4K8CpJXSsmRYMjc3MbF1QZ8YNm1K2/oMXN8eBxqBEXi0ld5rQm9KqW1c RsmnxhJ/es9vctTKyRDTonwm0XXZTxv6XZhw++atn3K/G/98b2hn58MhCQyJxWhIdP3GbmSvY/aE i3lutBl4rCs2a+dwT/ERHOgasfRoNeinUK3GYmY3PlLKCo+UbwWAOGbS4jWVuooXn58W6nm6c3Up SCPDxi1+a+1JXq3Mj4841HPtl5E/hX83eOGE6reR3yjXr1xXyTK0bKioB+aNySC4kzWcV1mQl1oi 1jxB6a4GXNcXN6riZJp6mR5CfP1zdtX8QpvmFC16XfFa9vy/MdwNeqi/CTIwxovBqHxIb46m9TfK Dw6nO6qjTqPN412/stnsD//FfZuVeCMNFUJnstmq9A2YN/UQ1vrO+LAxJTOXbFs7+tLxXhB6/hJE B9Uad5ZXHEW5kRLHShYgJcS1NjsxNivWjkCL1YTCKwWlCSX30OXYBkFRuLPmbtOtZQPlgdBReV8R P/69uWWFK0FqMGaA7vgtiLc9apQ+pEk0PhFeu9jr1LLZBz2c2CvsHayX7dyeluhQToe7arml1wli iWSv8M4y+baFqz/RLKpFBRpA8vuVb+tOHTEwsZYUv+LV3U+aIaz2KkQ/+PTBYxFbovDyi2QDUhUj SCx9PNYrvLszA/NCZ1HqzcD80jm6T4J99AbphuEK+kLxyjRpXl9IyaGnJIv3yd/7UnqWpwvpUiiE 2fwZAZ7TDljjg50t3EguFTstB+knUg/DEoRBg9512wPrPGcIVWFPY8PYcl/Q1YGiv1nR3eIsvVj8 /zKgnRup22B65fLF3FjbnN9hBd3XSLtNjn/jrU13Hn6UJe+0NfZR8aKpJaOALN9WOi0pqXhacmIx 9/oX3WVJY5efV7Yz9Y2ijTV3wZg+R66wFRQOkg/ftfJMn2PNrYPifK0Ta/LZyrRx6aNGj3HnJu4V 2OcYlYi6ejGnUIw2TAzHuopielKAfU6bdGkTCyb70ia/EOiokL234+ODEmfjvqJEmkrvY/nYC8tB qqRfPp75waGA6QHb0fLYtcJhyQys8Nh/IH2V0h0vAaJ9PNing8X0qTwMQmV9xo4YMHTsGwOTvwN/ 8D3X6SS9TF2cb//cUa/2z05FQmQmXtajrH/1C+GIS7CeNipCQK+AVKiEBaBS0vt0Gi3E+QlYj6Mx w7u9pBuaW0R8t55qlV6NQBzu9ob74tGVj6bPtWNyhqdxPP23Lqm0IEFCn6qjAHuneZtrRyhXrdhR zTkbPyt8pTxrO/0c1MAuKElEpueg9/66G0F5paWlK08ETEETeKRgn6MUHT0W+F/OLxl4bEZJ7l+8 3t+3/rDECezGqUPoLHoWoj9rvIK0V3zVKdOyUIzreNcNzoJ7GU9V1hBDGHHnCVbll6LJQs9fOkfv Qu9LZ6ETbakoyJsvnvBHK70HbL0TgmkLbVpx+tAiPJFqCnVwVkSOl3EK8Ra7Cq+lvDilxlbVbOes L65X9fEX6BM1diAK5ZRDNT/TptleoJrrAapnLRACb8M9GvRmFsLU7APD6W91CFNoncEYfyxaB/tt d2Yi/Lmd4tC5g49lYwYNXtmTp00qs0ulHLMugT1QF/weLb4O3Y8/vhpUGLBUpPK66z4byN50I6vY Zb9UY1+usJ4CG0j7b5oZVl42Y+w/V/Ybc+bY3pyw4ner+k9eETcOVPSK4XT3iJ6JcTG9hxTP3xRy pltKpMVk6z1MxBFXPVPD3cCKgT2o2E2LMexw44fd4fBiigcFgalRDcjbtIWxpArJcSA0KN7YLl2b wSSkO+iZI/uC97SsOc6f5m13O50tQFyZ/8G+mSy2m0BGIm43sIfEfGzDWiOihximHsoOdwpp2IY6 pfLdT7duZwMgUJk4ZfpIf5D7gtQeml8NbMjUyKKnvjW7nu3ozciP+hyjl+8gbcRvvjt7QLwD1mGD 1ST2qCyPT+IWR2xN1TaL9853p589TMkNUnaYMLSOfgWhnyrO1X8l38seiG49P7BHA0RMmUhv1Nn7 siOMXZybo+OZfg6jc72lNxM9BHlhh8W6kBd2PbiPwlbH0wITRECspnqx2bHYxYaYIF5i1+OiZ1OG dJHrV9M60Ef3mr0AHP1iDf4h74A/fRYZvXxVx3UrYrrT80HtYEuMwlp9OLDD38p7mkDSMYCuNile +/66aD0DjWfPIVexS9Ww2Cmgk0xit/Vf/dhzyzcbYwvzrmjKquhasB2Qb2UPxNKttHhFc8aYE0tL 32YNAQZnVf8YJvoNMcsCaDHsgmTcDcjQJ0ow2UUkF4FRgF20ZnTF4Ny0QSOObsAsujl4zZ4eExPy 8+tdLjLc1QS72WOMEffgBHe5eGWmoozu90gPu6Lwl3Fwd87opDdy0gan7E4sGt8vccpYnGvGNTIu VNyJ4A4Jg0AwgQX3bYyMPvMTqqyQUeYHzIcfHxwwHuQ0+946XINfidgSLsK7Q3N0ton9rLeXQWOb 2RKtU9DCNtqYmBKQWlV7jT7c8OO1a1/XN5yWf6Hbvfoo/dcAGdKJoMVsHtIRqz7urCSmzrjHsuod ojmxSIgUAxG63HsuHZt34kf6dkcQ1n1E47RbLzZPTVUP+OFY7riBsePmb1954e87A7er0sasePxx 8agq9eH2yYllE1KSghW6L9DCZnqA/QO/jSg99Vnc1+FuzmQlDmw8zWDAWMV6rWb/0H7kT1/4OJ1a hmVALRtNv5HTT+ZcFSDtxhH6xPntMTVzoD12o/PgmZb2ksskgI0ES9Jcv7NPJKn4hSQcv3FgZHCe zPXWZE+NE/XgWKsJvzOI7dFfFTnQzj6hzbVft/RLWHCmpHjn9kuW3tkQ0NwyNLssM700JDM5KeP7 Cpi++87FbTMyJ9uVb9UsSUvdPHfc0FFdlEvpnyendtqYNrm8iJUOHTs09u9Z8WJMpdE89g7aNlDs PUEpWhc/ejjEDhSzw+qxLQqDMO7udlEg9s6XJ+nKIFrxlto3fdv+yRlF5Ze/KF/eNPCVjHS7OSau aDo8oRkPHym3KnZUPsgrK976+ZxlC9bRc9eLxibFZ+UPHolRKOaIGk/x4EXMTR02IvXNlK79Mguz M0syu8cV5WP4kP8AORGbEgplbmRzdHJlYW0KZW5kb2JqCjkwIDAgb2JqCjQxNzMKZW5kb2JqCjkg MCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvVkdPT1ZJ K0NhbGlicmkgL0ZvbnREZXNjcmlwdG9yCjkxIDAgUiAvVG9Vbmljb2RlIDkyIDAgUiAvRmlyc3RD aGFyIDMzIC9MYXN0Q2hhciAzMyAvV2lkdGhzIFsgMjI2IF0gPj4KZW5kb2JqCjkyIDAgb2JqCjw8 IC9MZW5ndGggOTMgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AV2QwW7DIBBE 73zFHpNDBPYZIVWpIvnQNqqTD8CwtpBqQGt88N8XiJNKPeyBmXkwLD937513CfiVgukxwei8JVzC SgZhwMl51rRgnUn7qWpm1pHxDPfbknDu/BhASgbAvzOyJNrg8GbDgMeifZFFcn6Cw/3cV6VfY/zB GX0CwZQCi2O+7kPHTz0j8IqeOpt9l7ZTpv4Sty0i5EaZaB6VTLC4RG2QtJ+QSSGUvFwUQ2//WTsw jHuybZQsI0Qrav7pFLR88VXJrES5Td1DLVoKOI+vVcUQy4N1fgFuNHASCmVuZHN0cmVhbQplbmRv YmoKOTMgMCBvYmoKMjIzCmVuZG9iago5MSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3Ig L0ZvbnROYW1lIC9WR09PVkkrQ2FsaWJyaSAvRmxhZ3MgNCAvRm9udEJCb3ggWy01MDMgLTMxMyAx MjQwIDEwMjZdCi9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgOTUyIC9EZXNjZW50IC0yNjkgL0NhcEhl aWdodCA2MzIgL1N0ZW1WIDAgL1hIZWlnaHQKNDY0IC9BdmdXaWR0aCA1MjEgL01heFdpZHRoIDEz MjggL0ZvbnRGaWxlMiA5NCAwIFIgPj4KZW5kb2JqCjk0IDAgb2JqCjw8IC9MZW5ndGggOTUgMCBS IC9MZW5ndGgxIDE1MDk2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AdWbd1yT59rH 7ydhhBEICIhGTfARqg046iiOSgQSQRwgxCa4EpaooMhwo1RrtWntrt3WTtvS8RBtRTu0e9vW7m3X Oaentbs9PbbI+7ufi4tqz+l5/3g/7+fTk+Sb3++67vHc9/2smGBzY0u1iBFtwihGVtYHGoT+GD8G 0r9yZbOd4ox8IcIfqmlYVE9xJsTsWFS3pobi8V4hlA211YEqisWv0HG1SFCsyP6G1NY3r6Z4vOzA VLe8sqd8fDHiiPrA6p7ti/cQ25cF6qup/oS3ZNzQWN1TrmB7Q76YRIWiu+fRE/4mCqwhbILoq5iE SRiERYwQW4VIHGcYK8KEgie2Onr0TVE3dC2Mn/Sj6GfS2z74xfoXpHl9R7Dml+NdbVFfmsYhjEIP 9EC7yJ1d7wgRveuX48d3RX2p99RTqIuhI8o4pdTwjOEpkS1shqd79H2RbXhHeAxvQ9+EvtWjb0Bf R/wa9FXoEegr0IPQR6APQx8SHhFmeFeMAWXA2OuqEN0KXgPhYil6UkQM2isiyfCYyAdVoBlcAcJR 9xGU3YoeFWE3nLs3KlWZZu80bGazic05bNrYbGSzgU0rm/Vs1rFZy2YNm9VsVrFZyaaFTTObJjYr 2DSwWc5mGZt6NnVslrJZwmYxm1o2i9jUsKlmU8Wmkk0FmwAbP5uFbBawmc9mHpu5bMrZ+Nh42ZzN Zg4bD5syNqVsZrMpYVPMZhabmWxmsJnOpojNNDaFbArYTGXjZuNik88mj00umylsnGxy2Exmcxab SWwmspnAZjybbDZnshnHZiybMWxGszmDzSg2I9mMYDOcTRabTDYONqezGcZmKJvT2GSwSWczhI3K ZjCbNDZ2NjY2g9gMZDOAjZVNfzb92KSy6csmhU0ymyQ2fdgksklgY2ETzyaOjZlNLJsYNtFsotiY 2ESyiWATziaMjZGNgY3CRvQYpZvNCTZdbH5l8wub42z+yeZnNv9g8xObH9n8wOZ7Nt+x+ZbNN2y+ ZvMVm2NsvmTzBZu/s/mczd/Y/JXNX9h8xuZTNp+w+ZjNR2yOsvmQzQds3mfzHpt32bzD5m02b7F5 k80bbF5n8xqbV9kcYfMKm5fZvMTmMJsX2bzA5nk2z7F5ls0zbJ5m8xSbJ9k8weZxNo+xeZTNITYH 2TzC5mE2D7F5kM0BNvvZdLLZx+YBNvez2ctmD5sQmw42Gpv72NzL5h42d7NpZ3MXmzvZ3MFmN5vb 2dzG5lY2t7C5mc1NbHaxuZHNTjY3sLmezXVsrmVzDZur2VzFZgebK9lcweZyNpexuZTNJWwuZnMR m+1sLmRzAZsgm/PZbGOzlc15bLawOZfNZjab2JzDpo3NRjYb2LSyWc9mHZu1bNawWc1mFZuVbFrY NLNpYtPIZgWbBjbL2SxjU8+mjs1SNkvYLGZTy2YRmxo21Wyq2FSyqWATYONns5DNAjbz2cxjM5dN ORsfGy+bs9nMYeNhU8amlM1sNsVsZrGZyWY6myI209gUsilgM5WNm42LTT6bvD3y03Kn4dzQoMk2 fGYODUqGbKLonNCgCYjaKNpIsiE0KBbJVorWk6wjWUuyJjRwCqqsDg3Mg6wiWUnSQmXNFDWRNFJy RWhgLho0kCwnWUZV6knqSJaGBrhQcwnJYpJakkUkNaEB+ahSTVEVSSVJBUmAxE+ykGQBtZtP0TyS uSTlJD4SL8nZJHNIPCRlJKUks0lKSIpJZpHMJJlBMp2kiGRayFqIORSSFISs0xBNJXGHrEWIXCHr dEg+SR5JLpVNoXZOkhxqN5nkLJJJVHMiyQRqPp4km+RMknEkY6mzMSSjqZczSEaRjKTORpAMp3ZZ JJkkDpLTSYaRDCU5jbrOIEmnPoeQqCSDqes0Eju1s5EMIhlIMoDEStI/1H8mFqsfSWqo/yxEfUlS KJlMkkTJPiSJJAlUZiGJp2QciZkklspiSKJJoqjMRBJJEhHqV4yth4f6lUDCSIyUNFCkkAhdlG6S E3oVpYuiX0l+ITlOZf+k6GeSf5D8RPJjKLXM1qn8EEothXxP0Xck35J8Q2VfU/QVyTGSL6nsC5K/ U/Jzkr+R/JXkL1TlM4o+pegTij4m+YjkKJV9SPIBJd8neY/kXZJ3qMrbFL1F8mao79mYyhuhvnMg r5O8RslXSY6QvELyMlV5ieQwJV8keYHkeZLnqMqzJM9Q8mmSp0ieJHmC5HGq+RhFj5IcIjlIZY+Q PEzJh0geJDlAsp+kk2ruo+gBkvtJ9pLsCaXkYNKhUMpcSAeJRnIfyb0k95DcTdJOclcoBVd95U7q 5Q6S3VR2O8ltJLeS3EJyM8lNJLtIbqTOdlIvN5BcT2XXkVxLcg3J1dTgKop2kFxJcgWVXU69XEZy KZVdQnIxyUUk20kupJoXUBQkOZ9kG8lWkvNCyQHMfUsouQJyLsnmUHINok0k54SSPYjaQsm42Sgb Q8njIBtIWqn5emq3jmRtKLkKVdZQ89Ukq0hWkrSQNJM0UdeN1HwFSUMouRK9LKfOllHNepI6kqUk S0gWU7takkU0shpqXk1SRTUrSSpIAiR+koUkC2jS82lk80jm0qTLqWsfbchLcjYNdw5tyEO9lJGU kswmKQklOTGx4lCSXNZZoSR5ws4MJW2GzAglZUGmU5UikmmhJHyQUAopKiCZSkl3KGkDylyhpK2Q /FDSRkheKKkNkhtKdEOmkDhJckgmhxLxuUA5i6JJoQQfookkE0IJ8jwaT5IdSpiK6MxQghcyLpRQ DhlLZWNIRocSMpE8g2qOCiXIiY0MJcgL0giS4dQ8i7aQSeKgzk4nGUadDSU5jSSDJD2UIFdpCIlK fQ6mPtOoMzv1YiMZRO0GkgwgsZL0J+kXssxHn6khywJI35BlISSFJJkkiaQPSSI1SKAGFkrGk8SR mEliqWYM1YymZBSJiSSSJIJqhlPNMEoaSQwkColwdsdX2CQn4ittXfFVtl/hfwHHwT+R+xm5f4Cf wI/gB+S/B9+h7FvE34CvwVfgGPJfgi9Q9nfEn4O/gb+Cv8Qtsn0WV2v7FHwCPgYfIXcU+iH4ALyP +D3ou+Ad8DZ4y7zU9qZ5lO0N6OvmOttr5gzbq+AI/Ctmh+1l8BI4jPIXkXvBXG97Hv45+GfhnzEv sT1tXmx7ylxre9K8yPYE2j6O/h4DjwJn9yG8HwSPgIdjV9geim20PRjbZDsQ22zbDzrBPuQfAPej bC/K9iAXAh1AA/fFrLHdG7PWdk/MetvdMa229pgNtrvAneAOsBvcDm6LybLdCr0F3Iw2N0F3xSy1 3Qi/E/4GcD38dejrWvR1Dfq6GrmrwA5wJbgCXA4uQ7tL0d8l0TNtF0fPsl0Uvci2Pfo224XRu21b jOm2c43Zts1Ktm2Tp81zTnubZ6On1bOhvdUT06rEtFpbi1rXtba3vtvqTIyIXu9Z61nXvtazxrPK s7p9leeA4TxRY9jinORZ2d7iCWtJamluMf7QorS3KPktysgWxSBaLC32FmNss6fR09Te6BGNxY1t jVpj2ESt8WijQTQq0Z3dh/Y0Wge5oc71jWaLe4VnuaehfblnWU29ZwkGuDh7kae2fZGnJrvKU91e 5anMrvAEsv2ehdnzPQva53vmZZd75raXe3zZXs/ZqD8nu8zjaS/zlGaXeGa3l3hmZc/0zER+RnaR Z3p7kWdadoGnsL3AMzXb7XFh8mKAZYB9gNEiBzBzAEYirEruSKvTetT6jTVMWDXrIasxMb6/rb9h WHw/JW9WP2V5v439Lu5njE99KdXgTB2W6Y7v+1LfD/t+3Tesj7PvsOFukWJJsacYk+XcUmaUybnt ScnJJx01Vp+rLUXNcMcnK/HJtmSD6+tk5TxhVOwKfkOyQIwmtNmrJNvcxof1n5XChaJcIsocRZ0m MbtIMxXP1ZRtWnqpfHeWlGsR2zThKZ/r7VCUi3wdiiGvTEsqKimneMv27WJgbpE2sNQbMu7aNTDX V6S1Se906r5beoEqPseCppYmh9d5lkg4mvBNgjH5oOUliyE+XomP7443OOMx+Pg4W5xBvnXHGZ1x o850x5ttZoN86zYbU5xmZORSnhZbXOaOj7HFGDw5MbNiDM6YnDy3MyZrpPtf5rlHzpO27Ghe0OSA bXboL0Q+pUWGeKAEr6ZmxPIJQSxkyR8/qBrqLWzCQ++Guv/jJv8FJcp/wRj/5EPsEDhFvFO6Defi t8zNYBM4B7SBjWADaAXrwTqwFqwBq8EqsBK0gGbQBFaABrAcLAP1oA4sBUvAYlALFoEaUA2qQCWo AAHgBwvBAjAfzANzQTnwAS84G8wBHlAGSsFsUAKKwSwwE8wA00ERmAYKQQGYCtzABfJBHsgFU4AT 5IDJ4CwwCUwEE8B4kA3OBOPAWDAGjAZngFFgJBgBhoMskAkc4HQwDAwFp4EMkA6GABUMBmnADmxg EBgIBgAr6A/6gVTQF6SAZJAE+oBEkAAsIB7EATOIBTEgGkQBE4gEESAchE3pxrsRGIAChKhSkFNO gC7wK/gFHAf/BD+Df4CfwI/gB/A9+A58C74BX4OvwDHwJfgC/B18Dv4G/gr+Aj4Dn4JPwMfgI3AU fAg+AO+D98C74B3wNngLvAneAK+D18Cr4Ah4BbwMXgKHwYvgBfA8eA48C54BT4OnwJPgCfA4eAw8 Cg6Bg+AR8DB4CDwIDoD9oBPsAw+A+8FesAeEQAfQwH3gXnAPuBu0g7vAneAOsBvcDm4Dt4JbwM3g JrAL3Ah2ghvA9eA6cC24BlwNrgI7wJXgCnA5uAxcCi4BF4OLwHZwIbgABMH5YBvYCs4DW0TVlDbl XLjNYBM4B7SBjWADaAXrwTqwFqwBq8EqsBK0gGbQBBrBCtAAloNloB7UgaVgCVgMasEiUAOqQRWo BBUgAPxgIVgA5oN5YC4oBz7gBWeDOcADykApmA2KwSwwE0wHRWAaKAQFYCpwAxfIB3mi6k9+mf6z D8/3Zx/gn3x8Qn4s6/1gJgebunAB/uApcqcQJy4/+Q+gRLFYIppEG57nie3icnFQvCsqxGa4a8Qu cbu4U2jiUfGsePOUVv/H4MSa8HoRa9wnIkQfIbqPdx87cTvoDI87KXM5oj5h9t8y3Zbur36X++rE 5d2WE50RiSJab2s2HEFv3ytd3cdxy40Q5u5xMjZshY/Xt/Rt5M4T953YfcoEikWJKBdzxTwxX/hF APOvErViMVZmqagT9WKZHi1D2SL4GkQLUQuXF93/Vmu5aBDLRaNoFi1iJZ4N8E09kSxbocctYhWe q8UasVasE+tFa8/7Kj2zHiVr9exqlGwQG7FnzhGbdMdKmc3iXLEFe22r2CbOxx774+j83lpBcYG4 EPv5InGx+CO//ZSSS8Ql4lJxGY6HK8SVYoe4GsfFdeL632Wv0vPXip3iRhwzssWVyNyoux3iKvGQ eErcL+4V94kH9LWsxNrSivC61Ogr3YA1WI85bz5pxLSaq3pXawNWQ8472DPv1Vi/TSe1WNmzjnL1 NqOmXJ1gz36QvbT2ZHglLsHMyP82T7lGcg4XnzJPbvG/ZeWM5Tpdj/XilZFrtgO5a/8le3KNk/0O cQPOwJvwLldVupvhyd2o+5PzO3vr7tLLbhG3ituwL3YL6Vgpcztyu8UdOLfvEu3ibjx/8yc7Kr1X 3KPvOU10iJDYI/ZiTz4g9olOPf+fyu7DteP3bfb09BXq7WW/OCAexBHyiDiEK81jeHLmYeQO9mSf 0GtR/Jh4XDyh15Klj+HYehpXqOfE8+IF8ZJ4EtFh/f0ZRC+LI+JV8aZihntFfI73LvFy+KciTkzB 38oewN64XizA8//xEd5fJItd3T93r+r+2VggapQyfIC8G3tpr7gQ30ws+23Tik1Eh30sksTe7p+M 86BDu94Jrz1xc/fXzvLztjQ3Na5oWL6svm7pksW1i2qqqyoWLpg/b265z+spK51dUjxr5ozpRdMK C6a6Xfl5uVOcOZPPmjRxwvjsM8eNHTE8K3NoRvoQdbAtNSnBEm+OiY4yRUaEhxnx+TzTpbr9di3D r4VlqAUFWTJWA0gETkr4NTtS7lPraHbZLoCiU2o6UbPmdzWdVNPZW1Ox2CeJSVmZdpdq117MV+2d SnmJF357vuqza8d0P0P3YRl6YEaQloYWdldqbb5dU/x2l+ZeWRt0+fOzMpWOmOg8Na86OitTdETH wMbAaUPVhg5l6GRFN4ahrgkdBmEyy81qxnRXoEorLvG68q1paT49J/L0vrSIPC1S78u+WMOYxQX2 jsxDwQs7LaLC74itUqsC87yaMYBGQaMrGNyqJTi0YWq+Nmztp6lYwGotU813aQ4VAyua3bsBRQtP t6j24I8Cg1ePfYlRn5QJ9GQi0i0/Clkop9i7TJoSYC8wNowQ80tLk2O5oNMpKhBobSVeiu2iwhoS zhEOn2bwy5JDXJLskSVtXNLb3K9iZV2qy9/zWlmbqrVV2LMysWf1V7oWlo5yu2bM8FdU1koNVAfV fMwQaynKvJozH8YZ6FlMV8fIEagf8GMSi+UylHi1EWqDlqTm0mojgU7SXYtLvXoTyrq0pDxN+Ct7 WmkjXGiLQ8QVlDtGDlD2pZZ494vR3Uc7xtite0aLMcInx6Gl5GGnZLiC3qoazea3VuH4rLF7rWma 04fl86neap/cS6pFG3YUm8MDO1Bvhbn9rjZXxrS1yHST3WuwGn1ybyFhd+NNzZ2EAosWQaHco7mT 7F7FKrgattJTQ7pT+kFgTM8rQGMomuYVWNNwcOuP/zAkK00Aw9BMvWMKwyDCfxsTbecPh0a15YCG 2V3V+ScN8JROEegD7Ont34/TINeiZzEwBJPcnQVyDlmZBng7ik2aAfPUU3Ivpto1UWz3qtWqT8Ux 5Cz2yp0j11rfv0Wlqvx6Vd/bPUdJ2SkRlWdTmSbSisq8HMhvnjS3Q9+vcrfq8VQ97g0LfldcyMW4 7ojiYLCqQxjT5aFs7VB0E553gU+b5fCpWoVDTZPjzMrsMInYtDJ/Hs5eN66cqjug2i12dzDQ2d1W EexwOoMNLn/tBJwXQbWwKqiWeidh5+oXglbrWjmWRFGkFJXloiuDyO1QlW0lHU5lW2m5d79FCPu2 Mm/IgO+a/bm+jiEo8+63C+HUswaZlUlZxS4D2dNsBCa9vnW/U4g2vTRMT+hxZaci9BxVQk4RlZ0G yln0eh0Z+oac+L8TlZ1hVOLkHsKQM1GujWoP7altQolFlhwQuJHgyz+MmR70TaAzOtxpckY5Yw1m A5ZU7pIQMgdQN0oRe2IVs2LtQJ+YAdL4Sbojymndr/dEqQNKG2rKXBt676lmELLaSR1hkzRxD6Rn Bp5y755Ygf71d9TIlQ9cQlJrcYzhRuOyV8njb72vNuj3yauHSMGxipeiKepkoRnUyRhxRKwWrVbn ajFqrsznyHwO5SNkPlLN1ZQUBTu7ExfdoF/FhRjnlBc/d/hw+Fvk6W1It3d2d5d50160HvOl4Zyf B8q9WpQDN7rw9GmoN1XiR3qq1lYZkOMQHlzL5KWnsNKHk507RJVCLQo9RPX0gBpuvY0839CoEsca Dki9fRsCrc2n+Rxyo97FckR2u0UTBeoELSKD+gzPkBsa4QsmqmfIMxdVtej0rVKiMDZR6qWMFSE2 hjuKnFFkLEZeqaKo0m/HquMYKcW5TDeLaHkcIlONa35YRrVOtLWnUMhpGdNjzNFa1HB0iJf0McPR IV6RPiyKnLwebe2pgG1btBiMKOOkpexpgNVBUaEcC15bMXhZ9VHZTUmnmK2uxrVfDlrfVCSKNXN6 YQB3N2ofg4yazY3RlyldpmQfT1A2Us48FuuOS0Jn9251jbzE8SMrU5V3P3n8Cet+nKjCF/x9Qpvr yMo0/T5r1tPBoMn87xvQepnMvSp7wUQq5W0NKg84/Xizu+QNVp3WYZiJGlBF1+A0FTc1Q7oEH3SM OH3S7FU+WQtDLtavZeofVUIXvZXkbVrvPGiZKD+VyAjleoQAr6C26NSwtjd0o9iND4Ppw4H+ysCO kdf9JVatDkcmivUqco/Yg3aLOkGVb5iqEWcD8GM/9Z4WOPxx1MmTpq3S7q3AwY7lcfuD7iA2Yq8M oJk8Bnu2pC1znNIlzgsF5yEWRK6C1lZs9/vsfnw0VUq8aWlWnI1Qe01Ac6oBeSsoxvbxKsYtCRII ykNc+LBRqxaJG1NNoFpNww0HOZ++rvr+wdbptBHWYFANavqFwI3K6D4Dp12hFLwaHGqgWn6Exvbs gWq9rRvD1VdHjs/qUnEuV2O0ct0xL/zvL1Eh3yqDKnqb73dgJRKCiUH7+CAuwfNx9wjLqJzjx61K 3pHs+q4OWBFhXQtl5ENHVDEqXVakU0COpt7RMT8y/beMPBe15Q6qbNJ7xchme7VibqSfT7LWCodm 6JuNQoxUU2bjyob1l9cpLF54eiGW14lDzypb2zUDbq+0e/T2hbIpLg20w6gZMvpNRD/FcJPkuw3f h+ZZsaZ/mBdhcULg63r50H/khcbi+59YaFpvRuBflgeRCcc3Yk3GI/j2yCgixXgxQ8wUV2lbHN6H cO+YLVLEBOX++5Pz801ZkY8oebi52PHdsAk/G+c548MM5n39++eo+8ZGbDcmFHYqWXtzIrfjV4+c rg+6Do/o+uBY4vgRx5QR73/0wUeWbw8njB8x+qPXPhqFX8GT+pv31aHpWHVf3VhjxPY6Y0KObO+M qstxGiK316GT1BxH/8OOwyMchx3oxjFylE9JSEvQSYozREYmRaiDhxvGnpYxbvToMyYbxo7JUAfH GfTcmHFnTjaOPmOQwYialJlskLFiPPJruXFWV4Rhg5ozZ3T4oP7xSeaIcMOA1MSsSemW0rnpk4YP jDRGRhjDTZFDz8wdXFTnGvxOZMLA5JSBiSZT4sCU5IEJkV3vhscd/y487pe8sLpfrjBGTJyXM8R4 dbTJEBYR0Tkotd/pE9MK58T3sYTF9LEkpJgiExNih+bP6zoveYDsY0ByMvXVNQPrL/dRIpCPCPyr XMyZOmvWnEJHXqBucUXj4v8Btpb1/QplbmRzdHJlYW0KZW5kb2JqCjk1IDAgb2JqCjY3NTgKZW5k b2JqCjEzIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQg L0dLRFFBUytDYW5kYXJhLUJvbGQgL0ZvbnREZXNjcmlwdG9yCjk2IDAgUiAvVG9Vbmljb2RlIDk3 IDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciA1NiAvV2lkdGhzIFsgNTUyIDU5OCA2OTcKNTk2 IDIxNyAzODUgNTUwIDUxMiAyNTIgNTYwIDQxOSA0ODkgMjQ5IDU1MCA1NTEgODY0IDU0MSAyNTgg MzYzIDgzMiA0OTEgNTU5CjYzMCA1NTYgXSA+PgplbmRvYmoKOTcgMCBvYmoKPDwgL0xlbmd0aCA5 OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBXZLNboMwEITvPIWP6SHC2IE0 EkKqUkXi0B+V9gHAXiKkYixDDrx9Z500lXqYw+fZtXdsp8f6uXbDItL3MJmGFtEPzgaap0swJDo6 Dy7JlLCDWW4U18zY+iRFc7POC4216ydRlokQ6Qda5iWsYvNkp44eeO0tWAqDO4vN17GJK83F+28a yS1CJlUlLPXY7qX1r+1IIo2t29rCH5Z1i66/is/Vk8BE6MiuI5nJ0uxbQ6F1Z0pKKavydKoScvaf pfS1o+tvpSqrSpaUO10lpVJACKgYNRAC9ow7ICRlHt0cCEmpJLsFEJJyH9098JGx2LF7AEIotowt EEJx7O2AEDCOYYAQsOBiC4Sw1YGRgBCQGHsgBNwDNcKzMDMfpBGOha1yRoRjodgwIhwLLg+pEY4F N/YinI4Bi4xdhGPB5dvQCMjCQdFFVh3z5kiEq/+9Y34F/i331zWXEPCw8UvFN+e3HBzdf52fPG8Q 9QPUorcWCmVuZHN0cmVhbQplbmRvYmoKOTggMCBvYmoKMzY4CmVuZG9iago5NiAwIG9iago8PCAv VHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9HS0RRQVMrQ2FuZGFyYS1Cb2xkIC9GbGFn cyA0IC9Gb250QkJveApbLTQ5NiAtMjc4IDExNjAgOTUyXSAvSXRhbGljQW5nbGUgMCAvQXNjZW50 IDcyNSAvRGVzY2VudCAtMjc1IC9DYXBIZWlnaHQgNjM5Ci9TdGVtViAwIC9MZWFkaW5nIDIyMSAv WEhlaWdodCA0NjQgL0F2Z1dpZHRoIDUyOCAvTWF4V2lkdGggMTE5NCAvRm9udEZpbGUyCjk5IDAg UiA+PgplbmRvYmoKOTkgMCBvYmoKPDwgL0xlbmd0aCAxMDAgMCBSIC9MZW5ndGgxIDI5NzYgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBdVYJUFRXFn33v7+w90IvWiLS3dJtiGjshRaC iggIInHfQQdZJMoiqARUjKXBtWJAU2oYzViuiVsSNY6OqMRRsQwZ9ygTEy3XCCIz44gL9Ou5vxt1 qqbmd7//lv/+Xc49974/t2ReDvEhiwklJKsgczbxXFCLXfKM/PJc75zrT4hvXF5OZrZ3Tjqwj8rD Be8c7Nj3zCuYW9Y5n4h9dn5RVudzjse5vSCzrFM+uYnzsMLMghzvfn/5vV7//3nMDXn/7JKc1/ah /J7Nsd6Xibvz6py+7QCHXUkB+jeeCIQjStKXyGvyRXEkj4VN7wybVkGmKWKfka4+nke1CW3L5MFP I6+ldvi46n2TpS9xry9K8F74ntDgaoDTvp92+LDRvslvpHZuIF3pdkJkFAU/4s+fI1X8LJImPiJZ wjqSxpfg/DSpok9ICj+DJPJdseWRUGBkJqck5eJXJJnPxVaG6/PJaKolw+kUEsc9JP34MWQcbSLd EFELKvP6QEgAEUkMzg2kC+HRNxF9BhJMUDuuqImG6Ekg+h+AOOhIENESBfqjQo8kj8mpJJWUkEPk JmggET6CA9DE9eBSuT3cZa6JRtLJtJLW0lu8mk/gS/hqfgtqwYtuF0JQm0SMpA8aozKoPM1ij3JG RTnsZpNRlCxRUTarTqsRJVHUSvbOiclopts70mmKSw0DubTQaMMYZ8wo/8kBK7OmLolMTNDnmbuF mM0h3cxCyKt7Qkj7ID63vQZG9FiYGxITa4ifMnpy0JKyylnR6fED0tJrPFvDw9Eff0J4t6BDb4MR DoOdGjitwU4cBg0BzmHSUN7N6qYw61R2Ba7AfNjFrHuU38WDnV0aauEPDIhunwRujo+wuF6iZ1Xu V/wC9DGYhJJe6KHSYLSoVUpqs0bZwlQaSavTCXaDUdLodbhE7SajpNPqbGH8Ate84tbAwK19GgfA sbvlh9i/2LZEq68x4ejelNszRvqbIyAWVrASEfrAAsgHENnt35IVwRu21AuXvvWZxH15UJHThoQD kua+z9uFXhgzEi6JpjCiUhKDVS8hupxWo7ZZebtqzSr2NfsCKmD4/AJTaf6PZ5uvLmx5YETRCugK W0Iempn7SC17LMvLIkQsQoQMHnw4i0nkOK3JzpnlEWKlRqzUWpsHM7VYxH6NAIXf+JZf7yZpFdCX vaiGpc8UoIfFGbupJTuW1bpWDozj5rOKio7zS0L50iWzXfysfK6j6EJ7I8GIpLlvCkmCHSOjlxEk Bq8HYQTs3GsX1EISW8Ga2Qu2CcpACz6QzR7/vHltw/VNaxu4bewnlg9zIBRs8Dlbw05fAp69OneR tQPSlyNVGPMkjJKahKAGDY9B0gQbXsfJyntC5I1LEtvMWF+NP3sYGLg//HLaCQSesXtDR/h3NUAB /aH1HlfLGsAAKyAPBHHvg58Vx1u5Th37UUcX5DryikP0JeVbJUgGQatTU5kMXk372Y25C1fFOHxZ U2DgvtCTo+BH9ipnY5ubTE32d5phIEzfCczNXr1lwNmX0xUhzMUNqg/640uMPUdS3A/pZnqddCfh cvTNDpOImeOw9wz3ppfk7MwnrcZidoRpNTYr3fxYGVh4rGIHAMRzeas3VOlWvPj+jNQssj3rS8En wjh19ZyNp0S1Mj+x15G+G09E/BZ+Yfjy6fs+Qn2J7rs8FZYh15Adr/VxDjuyTG+zW8JFlVJSWuS8 1mqQ8TxtkRSFe+rutP2yZmiQHrop7ysS//DJ4oWF68DHZJ4GupO/QKLjcavPI5bKElNg0KX3Tq9Z 9GevJnqV3sLM6iLHTBJ0KM/p4bfDTrBiSHIy0auia2HQzuXrv9asasBAtYDw+9W/NZ0+ZuIG20b7 F6+PPGUFY8M1iH7wzYMnclUPdbXz4/gJ5F3iJENQsmTEJMXqYzJaPDZjoHhTmAorlANx9NwQQr0N b1QuWPIug5zKb5yM4sfpNlnev3Ipd7Dj49+hmh1oZb0/TBw7Z+utR3/KCuq+Y/Dj4lWzSyYC+Wxn 6dzU1OK5aSnFfNxfIgNTMz47r+xiGdCPtdbdAfOUj4MUjoLCYUGj9q47G3v8VceweD/7jLp8WjV5 6pSJk9InyRGfiTYfFcqwOmO+GwxRKqUH9WDZAzQYzdTBavY0yAhhgbEZY5JGZIwdmnYBAsDvXPdT 7Apz834JuRMHJmRPQEGkHG81whqUhrLkhAjnVEqoYa2KHmBQwASogmWgUrL7bC4rxP3JWBuikW+9 Pbo9FVxCQGSey4BIapVB7UAeePDy3GRs8R/NnmvTc0ZN5kX2b11qaUGywJ6q+wHWqiXbGsYoP6/e vY93tR4sfL8iaxf7HtRAl5WkoNJz0P9QU2PIzNLS0nU/BM8K3iVbjVbQ52hFNy8C/6vZq5Q+Z226 jGkluW90rTxQc1RwAd08+wM2n9VD9MHWqyi7+q/dM23LZXQT3Y28jd7prEUaYjISD9uwFv1XvG3s /OVz7A70v1wP3Vn7ioKZlXKDf3awe0CbXRDK2llb9Zkjq7Ch1NHMydvpDTxlw9B8DVY1i0mjl/Hu REoteH3Ao8EaxdtfXN8SGyCxf6jtQBTKWUfqbrO2RUWr4hSDsisXc3wjO5LwrB164Dl8j4WMz2LN jYsOj2IPm/qdkdEZjuhQRAfPN5APAUmJqjAoTp3Ww2IaM2z4ur4ia1NZ3Spl+hfJ9HBT6Ces+DpE nnxyLaQw+FNZSpz7PtXTv3sslk81p2waSjFjHZFZ5jlfMMn1+KN6lrC13FixsCzjq3VD0s8e/y7H WLx0S8KH1fFTQcWums5E9uqbEh/T/4Piyq09zvYeHWGzOPqPRGT6uZu5Or4R61eo9/SSOew0Sqgt yukUtZjxZpMnL63A1amSZm7dztkmSGnxILUoxu7y2TiNS57iZGePHQj9tn3DSfGM6LjTvb7Ap16s XHugnAbInoxz36Ut9Ihc+19XLDPmt0xTr2SnJ4U0tKVJqVz6zY5dNBj0ypRZ88YFQJAf+ESF5e8D 2mN2RNFTv7q9z3b354JqfY+zK7dQNjKQXqSH8WsJ40o6PyTkw1HtoBcZ5hE7BT3PBNbSwzEdJ2Li aNo7ka5tjve4uBGyZRaogVtcBlYljJTghFsBbKwvl3FIcUj+eAI8r0Ae4NcaxnJoasKowWPeHZJZ mJ1ZkhkZX5SfjY/+A42VFgQKZW5kc3RyZWFtCmVuZG9iagoxMDAgMCBvYmoKMjM4MwplbmRvYmoK NDQgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvS01a U0JMK0NhbWJyaWEtQm9sZCAvRm9udERlc2NyaXB0b3IKMTAxIDAgUiAvVG9Vbmljb2RlIDEwMiAw IFIgL0ZpcnN0Q2hhciAzMyAvTGFzdENoYXIgOTEgL1dpZHRocyBbIDU5MiA1MzEgNTMxCjU5MiA1 OTIgNTkyIDY1MiA0NjEgNTM1IDIyMCA1OTEgMjMyIDU3OCA2NzkgNzA1IDMxNCA0NTkgNjA0IDM1 MCAzMjYgNDc5IDU2OQo0MDggNDA4IDU5MiA1OTIgNjQ2IDY5NSA2MzkgNTkyIDY4MiA2MDQgNjM0 IDU1MSA2NzYgMjgwIDUzMSA0NjkgNjE5IDM2NSA1OTIKNTI1IDUyMCAzMDggNTk3IDg5MCA1OTcg NTkyIDU3MyA4NDYgNjE0IDY1MSA2NjIgNDIyIDIzMiA1MTMgNTk3IDU5MiA1OTIgXQo+PgplbmRv YmoKMTAyIDAgb2JqCjw8IC9MZW5ndGggMTAzIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pgpz dHJlYW0KeAFdlMuOm0AQRfd8RS8nixFtoHFGQkjRRCN5kYfi5AN4NBZSDAjjhf8+55Ynk2gWx9J1 PahbTZM+Hz4fpnFz6fd17o5xc8M49Wu8zNe1i66Np3FKdpnrx257VfZfd26WJKX4eLts8XyYhtlV VeJc+oOSy7be3MOnfm7jB/33be3jOk4n9/Dr+Wj/HK/L8jue47Q5n9S16+NAuy/N8rU5R5da6eOh Jz5ut0eq/mX8vC3RMREVu/tI3dzHy9J0cW2mU0wq7+vq5aVO4tS/CwV/r2iH19RsV1fC+7KtkyrL kIAMkjkSvN8/SRbIUjLfSe6R4H1h8iMSSM4UfUICrSzaIMF7b61aJBC15A4J3mdRtT0S6GxjRCQg LTogAVmQnONW0EqdGc1gjFwSN4KoanPcCGotGUc5EC0VDUigtpHEqyA6SOI1N4PYRGJOsI1eEnMC 6SUxJ3jQXhJzAmmtMEcVMpgFzOVmkF+SMSdI1qEUmBMka2aWbSA1c4E5QXIniTlBVKtjQwZTyRHr NDBotZgr7ga1KyY1qJXBAq+CZA3JwgxamcRrYX73loxXpiW5lF9mMZA2FV4L81taMl45SiVrdazE QKpzwKvgQfIb8CswqCEDXgVStQGvgpm1dtZpENV7xQ4Mokjuw98Xv3x3D1hlJXgBrY5NBHu1eStp wxYEbWwENsFRIPf2TLYQ7icvc4EtCMbnBP57pq6jPhtv17y7ris33L4tdvl1qccpvn1+lnlRA+MP A7sstQplbmRzdHJlYW0KZW5kb2JqCjEwMyAwIG9iago1NjgKZW5kb2JqCjEwMSAwIG9iago8PCAv VHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9LTVpTQkwrQ2FtYnJpYS1Cb2xkIC9GbGFn cyA0IC9Gb250QkJveApbLTExMTAgLTI5OSAxMzcyIDEwNDddIC9JdGFsaWNBbmdsZSAwIC9Bc2Nl bnQgOTUwIC9EZXNjZW50IC0yMjIgL0NhcEhlaWdodAo2NjcgL1N0ZW1WIDAgL1hIZWlnaHQgNDg0 IC9BdmdXaWR0aCA2MDAgL01heFdpZHRoIDEzODAgL0ZvbnRGaWxlMiAxMDQgMCBSCj4+CmVuZG9i agoxMDQgMCBvYmoKPDwgL0xlbmd0aCAxMDUgMCBSIC9MZW5ndGgxIDgxODggL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBfVkJfFNV1r/3LQlZ2zRb26Rp9r1J2yRNm6Zpm5YutKW0tIW2 lC7QBShg2UupKCBQN0BEERAGkXEGEWcUdNTBGR2XGcXvg3F3RMV1FGdQUUehef3Oe0kRnJkv+d28 3OTl3nP+Z/ufmxXLVvaiKegGRCI0b3H3dYh7EFVwub1/cLgvPiebENJeP9DbPT8+R+NwzRuAD+Jz 7IereWDxijWJ+Wy4fjW4dF7ie+ItmK9d3L0msT56F+b6Jd2Le+P3Z74GV/t//z7E/l5/3bLexO8x rG8+H47/GE0kHonpTxcMb8NoK+g3hniIQMnIi0Aj8q/iJtAXwxMh3qd9N3fe/V1nUvg7JJrC/faJ T3cXsW/O3IZP/ysztk94eUoX3CuAFeIP+B1/D1OAkEgI3+8UXuZWSnzJXcJ0OXoa/wkhOjjxA52H uqi7UD99CK4HUBftRv3EKbiugPkA6uI9jzropTC2o4XU5/B5DXyuQU10BorSC1AtLUdK6iKMN5CM qkJh6inkIf+I2qkX4b5i1E7sQxHKgczUCyhEbELV1O/huhqF+Jnw/jUYt3P3hsnfomryKGogvkQW +J2c8qNk9kq+jqL4byiVKEK74dpPlqMjMFxkNxqlTqIhGPthDMJYD8MP414YXTA6YIzBWANax/FE SAxY3wBzAypEmSgdOZEP+VEA0LMgFdylRh64Q4xopENWZATraJALmcA22SiEchEfSZAMfitASiRH QpSCspAdpSIFsqE85EBapEcZsHoaKkAUEiEp2DIJ5SA32NeM8lGQswBCM+B5M3ofy3Er3oc/IMTE UuJe4lsyQq4kH6UkVDO1hTpFI3oefZT+gZfH6+U9xPuIn86/mf/eFPGUniljAlLQJNgkOCXkC2uE a4RHRZSoWjQo2io6KHpY9KFYKXaL54u3iV+WiCVlklHJaWmq1C0tht0p9DS8bKabQG43aAXRgQP+ CBGMkAG/1WSUEnxTIIJ9uTpCqYCJlMzAaqUpgGUGGTuIIE/lNKutmqTSiD7bnCboCo+VVcyLaJPM YbfequSnbMfjMR7ZPZ6PP1OpLM6ALc3rKzDVNCrMuboNOk+Gr8JhjRRVZBncNruWt+TgQeZjas/l Pupfl46CVMTED+CZRnoOWMAAshn4UqxUqJWGAMiIDVhHcO9BZqvNYiBJG9NskKYMMM2WfE86PohF eJpKl+2KveXPlSYzXXjgF/iBTnuNs4cfjVLu2kpq1uVf1BTbBNEoz+PMrA29SfjARl2Aybt0M1jP DZZDWAd7SgkTbEoGZH4PYQsYctUqNfsxbcmNwO4ebDLy07DKF58RLkyevHVn2dgT22K7LS4lj1a6 rMS26yrnTo1UMF8xf5m/rLBk1eyKaGFd50i5uWp+zS3Ey+4HVs6/s9MdFaodxdnkXG+JPU0YFSVZ DGubPhxyhRbNndntpBlzbJj0ruyr6i/OAA/tn/iKKqV7AR2EZSZWCkKWnMJKEfTJpDA1EwF/itmX q6JKt6YONO2/785t1XOCirElj/WcZn4c3Yl1L/beT+cx7w0tYs4wbzDnmY9yelqZM+mpd2Hv39/G pcdUCOIBEKHDgIgWPBzhXB2pVPDAFHze1aCw6gfz2GcCEGLggQ+OLfJXV5eeHFl4kAlNIoEPplQv qcm3lRrMfU/cGNHQzf7r9r5y474fZtf3KVOuBeCymdSnOqcuWfPQ05dXQ1rDnHWmgSyeuM6AtSyh sMmTmFBBH3mVtaiSMYOnpO6dTe5cQ9LQkNTo9W5625RtNWl0KWPyccekXHQz82xnmY3Rp4WKmIWh ovTYFwKV1V1VzOy8VqgE8t8A8u6EFCYjD0IkBSDIK8JxH1FKCaWMb+OZ9EjmT2GjiBoeUxd2VM/b PbtwuHV2k1BpdBEo1yzZXr56D/Muc67vxEcb/kZnMx83tWcNM/96+WFm4vYFy621pXqFJBpNshYX MFt0VdW4Gbc9hhUP1cfRIBZzlkEWhY7kwuGKlyqlpJLAlFhtz4hdnNSSkDhsiimXTWFruhzCIO5u ndkRR6owGhWlmUP5CZTpjbBuBUwSy3J+7sUcyP9xK9YOFBuKAQPozsfU72wBu00f+9CYKjD679E6 HGbFvwnjtMmnKD15BYeqNV4XnrDmVeQxr2FhuNKuFJRGabU8OTM840tXtpJZfq3IiQiJitLN+QXM PoX/D/1lBpMdR8v52uIi5jcJLSgvaJEBExYMVkLiWucgFpudav6zoQqfRTSmGq+chIluBmjsxdnj WnPNcIAZjApT2bjsiMclIN8BJXk+rM3CxVpaoYPUmPC6vKAJogObsNVmUl37lQcDPAJs4M0PWJPE loLYhNsoF/BIpVhjYb79DfNpmjxFKHX6mc0Wl4qWWPPx11iJ3fh1Wp5kKqwZP1BUaUmKRsUpGYXl +IuGdz32unkxD+maWn74HOOfFrKCpwhT7ZFssrs235wcHX+ZDMSlpbUgbfYkEv9VNkh3ap9VBjEM iY7W2g1qMcNE2l0CYZItj5VKyZM4AngX7jEsdCSLhEqTA7CSpOiKii//khTub3vzAvN0TdgkZeVw RLxkd02BVRqN3RN6YfYFrHmyNKRTiKNsVlk48RVthRiSsvahuSgx++CiIKQYc2kMshcBZYggHmfe Yd7ehlV/xC7sbr3/E2b+jl11g2UZxevn7bgtGc/Gs87h4l8yv2aOnWS+PtZIvMT8lXl75q5Ta1/E kjHmfCKHUfsBAR3UeTZW4qXjSqzkqiDJQ8a0BdhsMpnBsFDtyop9OukUxNTY+KoPftUdaZm/qqBg SUuF9VI0aFBNmQyjhE+e+P1Nz/VSQwXrFgyM+IlE/pwOe+cg4GsOfHUhgTrC1lbMV+pwJou90mC9 EmRYTXIuyxVjYvFVQVy56nDEX2WburJnWret2DmzgFkfqp5uyg0EQ1J73uC8GQNF6huub7k2bxmM 2uahmp5bOxxC/aLGre3twuiM/Q/WlqSyBjNLqX2x11x1A5GtW9nYaZr4inwVrJODkFwHySsOis0D zIDNZSo1FBwCKAJUQZA6roTJaLXJzqatHCqcW+Dpa59+fWvO2s92t943MCYvnF1W0ObPWtg7clvZ sne29Z3txg2rV9pbyyLtjR5bU++ampGjrfJU5r36Dre9Pj/U3OAvGdnRNXKiW60C1o4RuAz1N8DQ CISNAzBOT4CFmDw0FAEuJeERZ04qryFc4jWKxqh7xuQqjc7oc1TxktUOU5SvdpZmk59ow71ZuJM5 WF6SpUsRjGsCQaNSRkdhj1rwyMxElEBR5xIZZA2FlDQZPcRk8ecyCTgQhwl5RmIN4t+ZnSqevWl0 X/ftz40UcuWeS7OKwNxpffMdVFtNoRmilku2sW3rHlhWoStcfWQzsSWeTuJ5NzZYv6Ejt3HnHSCJ cuJHGgojV9lZ5K8kVRMkYE4uwF2llpPHk2S+AH7YGnBlMB2fMY+xfIdw+HPF8hcoiXOaI8dPAbux TJ1++X6q6wrXMRRPjeWyVlYCqu/BPoAuZEjOlpk4ePWOJNZRkyzLQ3gxH5Id7JzgYKSHtAWIOV6b VG/tGLZr3DZ8b4a/vOYtXCEzGdJSJbHX3E6+TJZ+yyF5utBlZ3oMwdICTI87Cu2ZSkgctMEoc4VL 9j5SWGzW26ho2RRTwyLmVOxTTcChEJHRKK03ibX2TPcnX2dk2zUaO6gjdExvxKvwofI2r4Ji7SYD Lc6BFl7QIu4IcReB/BtHi8eKrME/6UXyiUucU8TecuSk8pmvTQq1QZtGKOvStL9+XKN0WPAOjckZ shIS5p8JB4nyVc7SHJxChKtNDrMUZBNG06vCzFa8NFhtNjsIAFqZ1QYtKYHCwMySya+AV/sg29jY zOIBM5ot8cwC8Q7EmgRijdnywNZtkkU/ziCJw0mNe2e1rC8Fimt1Rj2esjzJyTlrV8/1Du+o4kkU GXbm1tS9u8rDnsbsjfSMquLrqnf+WtXZ0evQt9Y/5nBniEu2r2fWRqtMSokwit+iBgcipTmNHpDL A3K107uh27FDXPtZ61l8MnUEnHkyAfJtmJUDWBzbAWDlAUIIzB2rR3C4rS/0yCMLTu/ev3HaDdjQ 3Dqnu6Xd3ZJPFVfV5usVgqg09iccDJsuX3ro85UFBSm4YmTlM48+/6ynGUDAqB0yyr2ACctW1Swi 1slUouS4K+tYbKbJI2fU9Tw++PbHo1/c3XAw+kJSON9S5tO5e2aE+qHuds2cuHj/hRG14uu5LZb2 e1auPDgrl82xoNnNoJme8wIuv9OmIIf8lX3iRc3iwwnVEnhTWjrF7mW+GhYkVR2ofuzEkrfvcTeH eHJrLlaOMu83Nkdas1raXc0hbK6tcGqEZYLtuLr+0uUjn68RJbcvavWmC8ukMbR2Veuvlj//rKs1 xHoAq+2PoG0aSIQsV6kL2VIFTwOnapD0ABA8Pvl+3583fH5++L2d7WM9eqtcgWOb8foNtWsrT1JV M+raBY8Ntk1cvu/8sLMmUNwwc9WJBwuqcM09d+3bySIbgbMCK70P+lYUjECeYn0LgtiXC80au74U Z2Cf0pTgKE1eS/JaryVVSiaff7OlbKvMYXB5ZM88k+zwM9Ko1FhUSwxM5csyPObjT0hPBf0FCzpr R2O7ayJmtm6TyMyUUBmgmQ8Vo3rY3sZnWyEe1E4IMx0uxJOuBCnTnxdk/R4aEu7CupnacJV/8Sbd nmsaXNhIZTxIaS2vvjKvODctHPzhgV8Of7h36HcbKqtKnVZbqX/6jLKVB+b4plvwglhHZe3U6srq aZVms2V0y/UbUytKjlaTbXKRtrv82PGULL9OL9swtmhPgyIwp7Kgy6ibXuBtLLO7t3V13NRkE/KY P1w/smzlyI3Lx49oo66qqU21xmw9oAnmo7aAJxWCbiyIP8UotJ1cEeDiAtCMJ0aK/SweSPh0+7aa JWuCpFhp1TAar0kiycyxW2cGSZ4oxahlVDqjXEqRQoXVCa5Fzmkoa9g9zOx013kyFEDGRc5pnZie v7RI523wMOvyiwzpqhT4nC9Ps00tIcUtDUGDYgqE2fOsh1XDSxGcx5BwLgHZ2xAgE+JxMR2XDp9h /rkwxyIRpLmMWD6aECOVXvrdd5delTirOvGZnLBZzi+fEiuY3A4W4zA4DRjA0ZUg0WazCSHOTLiK zxaAqzSHYgjcP16Z+GQaJgry7DpGnWXy1aXrM7XZYovvGu1V64Csu9o8ybPwt7aufmI1s6G5RAO6 CqzplTUrbKaUU51VLiCzP9d9/IQ0s6HYq5oqLinhhbvishLZIKsaBJ9k4T9Jhk9dtbVAyQGPDf95 bVZzQJX3AXh3K0zUcfPHLxzHj3dYV7yAYrN3nElyn1GTnhHvBeL3sebAL4nb76id1lOu7N3VMGNB eWbcQ3RZRonY6LWmu7P0cj6dbLIwZo9JTIuVGovW0hAUmbMYQ7ZFQstt2TjlenI22VxhrS6cW+uc vWnOz/xG3DZUok02GJ3+QubJ8ip3BtvPOau7sDjanu9Ml3oavczo3BqXKBrlDL93WqVLIyyfEteZ 2gU6w2kHy07/f1X4XLUAwscVLmoXo/GYJTyJWmvWWhvzxRYvk/GTxEniyNz+gkag6pzCUZGruhOL KttDtjSxd6aXWd857d8E2k4Giy3etg0tzB3xwIhnU8oHEiax1YPmaumVmsWlExA6ntSJwp2vr5m2 6fFF33y/9kPmeGdXoNKV0tlR3mhN7v/o4c3P3VA08f2x88uIpNdezevb1vrm6y1HYf0w00j1w/om lu/Sk17EAcFFNijNkt5EjyC7pkDiU1zmhKxKihQ2K1aOJIlbdtVzlbJ/HlslZ83Jas57lEugXH4l F1WGnRrFlPIpO8iZ1Vy5TMcRtli++EdPM9uvgReSrEWsk17I0m02k5Ms7P/mXS9Lqve0FZWdkAU9 qkCWnCd15jLyn6xANpAttRLmy1BEk+Pz+5lnOmtdcOh1rRvArg1Qs9pgV+BRHOfnkvJVlB+qCVB+ LsvHGT/MbIE3Uwdm1dSZGnqC3VXOgWfWVd+6dJM6GPVEp2ur+ueuioQH724//BKWtreXlzpCAVdq qLot2LapQqz4vKRCE86z5vlctual0xpW1lq8F9gYtIAcBPUOnDdNVs54SfMpDUoDqz9LvYMkMXv7 jF07R4tCejl9AWcwHylzLVp3jmZNTdHBQ4R3qtBeNthwaZQpGhr0CdNT2ZXlE99TU8kPOA7C8d2f sULo2VnGSPC87vTtBxSKbDe+KcOU6bYyfz7J/KAxOnTkB1GB2Zxdx9Tg9dnVJmeQHy0TpDtnNsXq iB/rCzN5LJWGE15E6WEfqCVYHs8QHJgsf+aYO5s+cTEmPRSbM1l+eg3vxnzizi8MvpwMJi3CE6cM LTDKzDZmvWtW5Mx5ld6oUYvwx8Upiv6+VLnDhEezaqsIM3PcW2SEXpSfJVYq0++70WFNTTUCXRZU VP4D1+odFqUAg9FdMot253qdQ6U1EZAhimdxuDA1HC5wvkfDWSfbBidQvrrh+BlYxPTS5TfNqym9 TmIzWYvq4Bjmstbg0OGLPwcva8fhRvknXpNz+TLiAofRf8EQkGMpxp2AnBxsz5nZJzMEOA7DN8kM Srzz1axin3Lt+DECvZgd8mauJacttM5tYp6Okn59bRvO5vBPZc7i67EHzhYS57eYb2NThA0vEgjz Vg/WuXKUYuxxzLfPvGG0dpa1qb+2bTlU0t1w/2HYnYTTffiTZfKgW44PMxexhLl4F3mY+Sv2xMbY V+IRkLcf7loBO5GJu1fAjR72W/juCFNHptF7ufMnyFns4SykESXwPXgC2+WIIJBBH5l28sLmoqIt Xz9Z0mV2pem0EokuzZLpzpnB1PX9L56O9diIG870L0k3u+rbmb+cf/uugz0NWRa5EnZxMXXEnvgu ciArKbJkQopNgVzuLDYFdLbGnybXkxe2Rv7TJvTe+a8wv2XOMu8xD09ugoNXbQIZcpT8DfE9VFkW GYRJE0nDwJvrdziI4el32OndTBr+DLMvLDcZAjZeC6cHEvbcnjZaAfqUPF8uyAY1mj0mhbN0OGGC hEYQjfteXbbi3P7vv2EmmBZbU4W1IEsv1eSWZwWq3fLkMZx78RNcdBjke4DZz+wiXn6XGR+x1G/8 05pHv92UX3H7GyAO2g/xVgD7pcMk3k8BBQZeBi0MDxoaH09JGiWGyNy68YNLO3PVmZq09oEiQngD D6tDhRaliGhvp2XGSAXxqsPsqVyIC7qOwKqDsKoaVrWBL7IZhztWhvY4Xmt4bA8HjJZlv9DQsWc4 xDelJRbxcvX4oPPAssGh/J7mGQtSj6+9eUv9zidnFu44WrdZ/53c62X2RLs+3Lz+/jumLxkdWvtl jk1Rv6Wtfuux+2rucQlh3/WAngr2hWiUBwC2xA7Kn05Z4uEJ+rmgXrPnAyzx4N8R+5+Rk/3lIz2z tjUPfXr/0DsNxzMWtry2a3f9seNtLTkzS5Mo8T8Gyzd2NN/Y5REktWzvXHGi32G5vKwf8267eRl/ 121Lh1yLWsB+8E8QtR7+d9Gw5y2WCFmEIQh9iZN2vgkYIMt64JTdHzRhfM7sUvFifyc6zwHbzZAs EE8IU516Bp/HLUIhcwTOPWwR765Bcv74MYnZc3ZXoNgiF0QJ4SfbD8RioO+9oG+QvputdsG4ZizZ 5EwnMySAl7EFOA4EdI73nkhbMmvxwOb1OUPuNqLeYlRJlihie8Kj7eue6l/3xaEF70QuLV605bZb 7kiR5BMPClP1zDPM7hTZnIdX3fxUhxO8uGviAjUXMNZCJwz/xMERFmfGeJ8OtrZNdo3Q2lzTsCSa Ru5PHykmh4gVq6//x4G7z60r7q8mzq7/YvvFH4ZiT/TP6+7u7ZzXK14wUNqekzu3uGaOnTgjyTqy atVvu1sfXNF8Y4tB0vV+36E5jxwavA/zNt6ycXjdxjUxYtv28LqW2TdWVK5h46gDkKkHKXVsTbYE 8qCrA/eLt7XxxioOCkHx5fHTdzaklMm4ojQn1G/LLrEIhHW7BlYdbhz94hcHzy4+wjz16XOWkoKc ZNGC3sIGn8pVhUXigM07vH06FcjuPTF805nrbmKOX2Z2vyQjDkszHOm5rufOeJpWVjBnQZ4xTFJ+ cls8C8ihcmEYY+SD483kg8QfTp9myk+fZuNxDZpJTaUi8P8pWFSAA1i5hqTGx8lXZr6B9TjzDWb1 W4h9YPjXFHPveGzGr6lrmxmtdZV1L+5ZtqA7K7p0cD58+X/6EFfACmVuZHN0cmVhbQplbmRvYmoK MTA1IDAgb2JqCjYxNzYKZW5kb2JqCjM0IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9U cnVlVHlwZSAvQmFzZUZvbnQgL0RYRFdGWStBcmlhbE1UIC9Gb250RGVzY3JpcHRvcgoxMDYgMCBS IC9Ub1VuaWNvZGUgMTA3IDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciAzMyAvV2lkdGhzIFsg Mjc4IF0gPj4KZW5kb2JqCjEwNyAwIG9iago8PCAvTGVuZ3RoIDEwOCAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBXZDBbsMgEETvfMUek0ME9hkhVaki+dA2qpMPwLC2kGpAa3zw 3xeIk0o97IGZeTAsP3fvnXcJ+JWC6THB6LwlXMJKBmHAyXnWtGCdSfupambWkfEM99uScO78GEBK BsC/M7Ik2uDwZsOAx6J9kUVyfoLD/dxXpV9j/MEZfQLBlAKLY77uQ8dPPSPwip46m32XtlOm/hK3 LSLkRploHpVMsLhEbZC0n5BJIZS8XBRDb/9ZOzCMe7JtlCwjRCtq/ukUtHzxVcmsRLlN3UMtWgo4 j69VxRDLg3V+AW40cBIKZW5kc3RyZWFtCmVuZG9iagoxMDggMCBvYmoKMjIzCmVuZG9iagoxMDYg MCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvRFhEV0ZZK0FyaWFsTVQg L0ZsYWdzIDQgL0ZvbnRCQm94IFstNjY1IC0zMjUgMjAwMCAxMDM5XQovSXRhbGljQW5nbGUgMCAv QXNjZW50IDkwNSAvRGVzY2VudCAtMjEyIC9DYXBIZWlnaHQgNzE2IC9TdGVtViAwIC9MZWFkaW5n CjMzIC9YSGVpZ2h0IDUxOSAvQXZnV2lkdGggNDQxIC9NYXhXaWR0aCAyMDAwIC9Gb250RmlsZTIg MTA5IDAgUiA+PgplbmRvYmoKMTA5IDAgb2JqCjw8IC9MZW5ndGggMTEwIDAgUiAvTGVuZ3RoMSA0 NjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBKykqTWXgYGhgYGZgSM5NLGAAA8YE ICWVnlOZBuW3AGmtjNTEFAif4Q+QNssACkDlTYC0SkZuSQWUHwGkOXLyk2HyNUA+W25iBdR8hjtA vkJeYm4qVP0GEB+3vNUNkHxBUSrMfUDzVV7bQDQz/IcCKBdBMQKZTExbGWwYTjGwMzAxCDDoM4DE QIAVyAex2c6cfRjDXh/Pb/OVQ5oDLLXosboWiHE24KrYr/V/0wUYOAKBXE64XqA+drt/fgzOAgy/ 1v+qEmCAy4D1AwkmNqAQkyWYywiV5WFgY+ABiigC+TBXiDKIglSDuKxACIwFdqACQUVBVSDByMDC 8EeB+cAfB1aG3wwKLAeAqoCAkUEIqp+NgY+BwSXCJdwtUtuxKDMxxzcEAJ5DRMUKZW5kc3RyZWFt CmVuZG9iagoxMTAgMCBvYmoKMjk4CmVuZG9iagozMiAwIG9iago8PCAvVHlwZSAvRm9udCAvU3Vi dHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9IWk5CVlcrU3ltYm9sTVQgL0ZvbnREZXNjcmlwdG9y CjExMSAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMTY1IC9MYXN0 Q2hhciAxNjUgL1dpZHRocyBbCjQ2MCBdID4+CmVuZG9iagoxMTEgMCBvYmoKPDwgL1R5cGUgL0Zv bnREZXNjcmlwdG9yIC9Gb250TmFtZSAvSFpOQlZXK1N5bWJvbE1UIC9GbGFncyAzMiAvRm9udEJC b3ggWzAgLTIyMCAxMTEzIDEwMDVdCi9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgMTAwNSAvRGVzY2Vu dCAtMjIwIC9DYXBIZWlnaHQgNjY5IC9TdGVtViAwIC9YSGVpZ2h0CjU3NyAvQXZnV2lkdGggNjAw IC9NYXhXaWR0aCAxMDQyIC9Gb250RmlsZTIgMTEyIDAgUiA+PgplbmRvYmoKMTEyIDAgb2JqCjw8 IC9MZW5ndGggMTEzIDAgUiAvTGVuZ3RoMSA0MjYwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4AYUXDVRUVfq797437/EnAyICo/GmJ7AwIGrmDxAMMIPmJIKgzqDVDAOCJsIqmqxuy8lj 2Zg0Wx5tq00r+9Oz9QajHdpSqu3nnLXNUyfOblqr5pqnzfK0Zesm8/a7b0aUtrP77tzvfn/3fj/3 u2/u6163oRUSoRcY2P0dvi4wnuRNOGT5N3YrUVo4CiAKK7vaOqJ03DGk97at6VkZpZMfw7G/vdXX EqXhMo6z2pERpclMHKe0d3TzdfFJ5nbkNZ3+mDx5F9KmDt+mmH04gbSy1tfRiiM+5l4EU7o613dz Cuk6BNO61rXG9IkbgK03RDFA+MgBhTYQDSYFMxTDEsS/EvcaHC5HWaRHUm9PLvtOniwb7Kfmv1rK kfcjf23S9Ui5/LmcgGSCsR4X4Dw5IVKOcGnk4OWp8uejEi7lDw01plam0TxsuTQXOkk6qtxuwEUG rDBgMYe0uL84OztMp/bv40Nh/+R8HKbYE05lZU/PS80uy+P0RHvpmvzskwcys09hP5g3I3t72Yzs rdiLsW9EmuvlHcjP7szr7Oi8p/NeYTakp6MvqSmyPUw+e3lJWlxa3OxgmByxz5WCr0nBQ1KwTQq2 SMFlUrBGCs6SglOloE0K5kjBKVKanCqb5XFyohwvy7JJFmQqg5wW1k/abTwDaSYzH0wCh4KBmynH ESAESmQKC0Abz1zU1VBFXNqQH1zNinaxQQ2T+PomTVSriJbqAldjVYY2x+YKS/pibbbNpUl1y90h Qvo8yNXo9jCBRneY6Jy1zaKlVrsHgRB9205LbPR4IH1jRUZFannK3BrHTwCvwfQ6bFefjKsoYq66 nlchm2wACWH3ISn7IYlzG5AbNLhBzg0a3IzJ2m5Xg1s7MNmjzeCIPtlDDlUO2Dc7W1WnV3W2Yvdq Oza2Z2i9zYoSsg9wgaKxXG+zv52PvlZtQG11aHbVoYQqjXk/Em/m4krVEYLNzkZ3aLO91dFfaa90 qj6HZxBqSXOooG+MufuumBuEAtL83wbDpJkvWcAt1hpTf2Sxj4trucU+brGPW6y11xoWnav4Bta5 QzJUeapXRMdDNCEe98JrsXqq0s1d5cbGlFoz7rK8IgB5DhJsHi1RrdKSsPM9K6osquQiLBguGofs 5Jgo465Sq+UV8lxMZEZ2iloFtg1jNgmJ9fyBDOcqB+/oyaA+RHv7U7Nn2Dw2EG+F6eItkI19EtsF FgD9VKyfiXj08+IdoEZW6yfykrFEX4p1HPDxQQ7cBvlYsG/ABThMCqAOhvRj4Ac3vROKkP8A/B6G 4FNwQAuWeBbZAor+GNwPubAV9sFcIUsfgFvgnJwM6TAFSkgnmGACvnseJyfgZnDhGqUwD+6DdQjr kf89mYMSAvFwK1rfBY/CYfgz/A0yccWpMEwk8r3+B6iGBvRhMwzCp2KVuAPGw6/hWXgeXoe/k6lk P/mCfaUP6Ef1f+CsfJgOs2A5NGN7EJ5AvWfhT1RlT+lZ+mb9Of1dmITeH8TIX4e30NZFopClxE+f YT2Rf+tr9YOYh0T0Gb3HVonR1EI3PI2aw/ADicN2N1VoBfVHUvSJ/KSAAjb0bwl0wF2wHXZiFI/A XngRzpEK0k7eI1/RJNpLj4h1Uq1UG3dk5CN9nn4RbSSCFb1dBnfAJpz5IDwEu3HmE2jrj9guwAiZ RUpJObmZLCYPkHvI0+Rf1EaP0x/YOJbMCpmHedkWdppdksWRRZE9kWN6nb4Jc4mvI8xnDmbNAY2w ArpgPdwJW6AXvevDFsTsHcSmYT6PYHsTPoHPsJ2Fc/AloUTEGONJAbZp2EqJnSwgS8jtpI2sJ3vI yyRMDpO3yBfkWzqTzqJz6SK6mLbRLtpNg1SjIXqEnqH/RC9LmJOtZ79iB9kb7F32AfsYq36B4BNW CRuEXYImfCRcEL4VIiKIKrapok/cN/JkxBVZrufqpXqzvlMPYjuHOb4Oo8mFPIynDnfVDyuxcrqw /RxbD+ZuG0a0Gx7H3PHsvQxheBWr9A3c37fhGHyM8X0Cp+F7uITJ4fFNIFZSRKZjfm8i87A14T5t JFtIL+kjj2CeQ2QA2xA5gVFGMMKl1ENvoxvpFrqT7qGP0kE6RIdxJ3Rmwp3IYPOYiy1jy9ltrJvt Zg+z37DH2V4WZkPsbYEKJUKdsE7YKgSFJ4UXhXeED4UT4jSxVAxg08QB8TXxrCnVZDHNNDWYwpJJ 7sF/2ggcgncgBAPGubwGkO3ETELwO/I5E1gvPUrdNIEOk7uF90ke7kAZAbEP1sI36OFk8gGdTZYx P2nC/N1NVpLl8Fs2iT3JFsBRcS1pYHWkBRqEPXBZfBN8YoD2MyoG2Ai5RA9CO/TRO0ae1z1kHDSQ /fQZrJhfQhnkC1kwTOcKgySH5tMj0gskDOWSic1lJXIyUvvZZ+hug5xMvgAfO43n5xSercX0GXwn nCUnpEXo3Qh7EXV+CeVkfyQFnhc91Esm0f3klpGtI39hj+p7SSY9DTCSMlJJq7HilugH6GH4GvZE Lgkn4TA9DkvwreE3Ts43ePbuxDfNUrhMk/A8NeB7pMtub6wov6mstGTunNk3zrxhxvRpxVOLCm0F +T/Ly82Zol5vVbKvmzzJkpWZMTF9Qtr41BRz8rikxIT4OFkyiQKjBAqdao1X0XK9mpCrzp9fxGnV hwzfNQyvpiCrZqyOpvB5PhSN0bSj5sofadqjmvZRTWJWyqCsqFBxqor2nkNVwqSp3o34TofqUbTz Br7QwIVcg0hCwmrFGYozo92haMSrOLWaje0Bp9dRVEhCCfHVanVrfFEhhOITEE1ATJuodoXIxHJi IHSisyREQU7CGLUs1eHUMlWcisuwHKevRaurdzsdFqvVU1SokWq/2qwB/9OyGSpQbZjRTNWaZJhR VmkYDuxQQoVDgfvDZmj22hJb1BbfCrfGfLiGU0uxoV2HNvEXZzKukrg4/j3ee63UwgLOjFUKVw4E 7lW0ffXua+ZarHwFjwfXwLk0p8YbqEHT9+NWuRoUtEa3edwa2YYm8T8+x4gqGl/0GpLjXa1ocWqV 2h5Y7cW9yQposLjH2p+VZR/UT0KWUwk0ulWrVmFRPT7HpFAaBBb3HMq0K5ljJUWFIXNKNLGhcckx JDHpWqQVkx6VGZihzjHX4tHMEu6jerNmx5LyK+iJW8WY5nDQOgcC/jm4Afh4CM7SWnBHVmlx1d6A uYTzMUSiiTlmVQl8B1gB6vkvx3J8MY4px/wdcCGvk9Fa04jvCq7ZbFpBAS8RqRr3FH0sN+gbiwo3 hmml2mVWcMBbHNRhbn2ekmJMv9XKN3hH2A7NSGi99e4orUCzpR/sxXjNoV4uGboimbCES3qvSEan e1Ws5Jf4vRkmaHLu6C/ZnD7e2V6ikfT/IW6Nyl0Nqqu+ya04A95Y1boax1BROU8o5g1lMUwbX+1m Foo8jlELM6RYlCuaRlWQcCdqQg7+TEZRt4QlGavS4BClRjN750ehJ95qjZ2Z/zcprF/gs4zh6rRY GFqJLeZo1G2tdAw9xr3EAHM14juHuhqbAoH4MTI84FUhlWyvD9nJ9oYm9yB+qijbG939lNBqb5Un NAVl7kEFwG5w6SiX6yicAhfBgu2nsiGyDNoBeg1dwWAYtB+/UgxeVAl5BPxhGuWZDT2Px1MEwnvQ xl6A1QCowLeb37lM2AH/v69wAGaABzn82xWENvxEZXgXKLVfZ5L8+IYWBT+DeJPoZ4xmxUmCn0Cm nD8nw1Zr/rZs4UhZrfli2ULzSBlUlI2U8T592g0p1pQca4q1TYDLChu6bBfhB1CEIe4FwIf0OPqU ANZBYOQl+7g4CbKSTJmJSV9b+bK22jPms1Cx8Pz0aSTNpF6fe+PMWTfMSKfHh/c8PDz88J5hWhkd hw2fEeCt24r35J968POQUFPzhjVrWmMf8wRSY5kwAd7M5zfVVi1dZmvo6WjuXLOwEdf4D03vQtwK ZW5kc3RyZWFtCmVuZG9iagoxMTMgMCBvYmoKMjk1OAplbmRvYmoKMTUgMCBvYmoKPDwgL1R5cGUg L0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvU01ESkdYK0NhbmRhcmEtQm9sZCAv Rm9udERlc2NyaXB0b3IKMTE0IDAgUiAvVG9Vbmljb2RlIDExNSAwIFIgL0ZpcnN0Q2hhciAzMyAv TGFzdENoYXIgNDYgL1dpZHRocyBbIDU1MCAzODUgNDkxCjM2MiAzNjMgMjUyIDU2MCA1MTIgMjU4 IDU1OSA0ODkgNDQ1IDgzMiA0MTkgXSA+PgplbmRvYmoKMTE1IDAgb2JqCjw8IC9MZW5ndGggMTE2 IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdkctqwzAQRff6Ci3TRbDsvBow hpIS8KIP6vYDbGlsBLUsZGXhv+8dJU2hi7M4mrl6jLJT/Vw7G2X2HibdUJS9dSbQPF2CJtnRYJ3I C2msjjdLa3psvcgQbpY50li7fpJlKaTMPhCZY1jk6slMHT3w2lswFKwb5Orr1KSV5uL9N43kolSi qqShHtu9tP61HUlmKbquDeo2Lmuk/jo+F08SN0Iiv15JT4Zm32oKrRtIlEpV5flcCXLmXynfXhNd f2st8qpklNpvK1EWBRQodShYN1CAas66hQLonnUHBWhO2T0UKFUYrh6gAFXF+ggFyO5Yj1AA1awt FEB71g4KkE0HaShAdcNVAwXQdBBBAZpRxZt/H8fP52+6j1VfQsBE01+mYfMQraP7d/vJ8waJH0SQ mq4KZW5kc3RyZWFtCmVuZG9iagoxMTYgMCBvYmoKMzA4CmVuZG9iagoxMTQgMCBvYmoKPDwgL1R5 cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvU01ESkdYK0NhbmRhcmEtQm9sZCAvRmxhZ3Mg NCAvRm9udEJCb3gKWy00OTYgLTI3OCAxMTYwIDk1Ml0gL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA3 MjUgL0Rlc2NlbnQgLTI3NSAvQ2FwSGVpZ2h0IDYzOQovU3RlbVYgMCAvTGVhZGluZyAyMjEgL1hI ZWlnaHQgNDY0IC9BdmdXaWR0aCA1MjggL01heFdpZHRoIDExOTQgL0ZvbnRGaWxlMgoxMTcgMCBS ID4+CmVuZG9iagoxMTcgMCBvYmoKPDwgL0xlbmd0aCAxMTggMCBSIC9MZW5ndGgxIDE4OTIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBdVV7UFRVGD/nnr33Lons3WUfGSuyu7CrJiHs CxCTkE0ekoKOL1AkQAlhFSKEAsdRUdN0fI0aYeOoqek4lSkx4wNyeDgOlTE4SlYmiRr4qEnRCTj0 nd1V+6dv99xzvnO+8/t+5zvfd29Z6Xv5SI5WI4JQbnHOCuQRvAs629KiyiU+/S5C/OyC/Jw8r44G oXcUwIRv3QZ9aEFxWYVPnwd9XNHy3GfrF0EPKc6p8OGjn5nuzinO99qLcdCP/f/12GvMfkVp/jN+ gB/axzYxGfaJV/vPE8NYgYrhfHMQjzgkoQjE5pgQGLExXzcuJbsaZSviHqNRcs/S2cT+9Wzw3cwr qYPyoTa/JPFTsPUDBK/APr59qB03+20ZlNMMv6TnqD4DpCCHwMUDlEy2IZdsKbRRyMX1oEhOQpXC UZQkq4C591EG0aDpJBPFc3dQJOlFQZwMWQDEyw0hfyQgM+gGFACMX4J5HuYCgIsMVuRoJHAS0QiP 21S0Fh1Fv2A/7MQz8A58Dj/idFwKV8V9wh0DexByiNcDjoiM6DVwojQoPc1iczgdDrvNbDIKosXh sEZpNWpBFASNaPMpJqOZHBrMIslDKvw6lxYcY5jljE0fscD/w9xFa8JdiboCc5DebNYHmXn9P7d4 /cAU2ZKBWjxjTNUSfWycISEzY0HAmoqaZTFZCZPTsmo9pmFhwD55+A7ZR66i0SgMoTDRbDcJ4Mtu Cw3zEhKdPgYatcVsD9GorVFk3z1ppPtM9WcY4wSuYPOebdqNT0+3iH0CPb67HMvHGxdtfnfvBUEl FbnGNkTsPT/+17Afpm94+8RKiJ9r+HeSR64hDfMmmEKQ3YasUTqRnV2j1gJ6njKzjlLah42DHyw2 ZpVWfnR47/yOxok45FIHjtG3m49XbzwLzAFJRvj1gGR4wZyz21QAZ7VZwgSlJEqW57gycl9UuI83 dfdf3zotQIeDpB6Fa/G61VXunVhuMmdjbeN17LLfeyj/g6ZSVzKe8uPE5q2rvvF6Ip3kBgpEL8Ot qUVeCzydL9hrRZvJKJJOYagq4PCG3Z+rN7XDAe5j/m7n973NZ0zcG9aMESW7wy9EYWP7FRxz+4vb DxDgRsLjJl8HqKMA1xsCwDWbpECDSmkUnVqrZIjC3M3QmLgkx/w6eV26gj5VTCqTF07GGfm0md98 MmDdeXmbQDfQLdiNVwmtIn5CX4E4VwJiLb8VMhUZAEwiYZxSwrX0oWIMNijwXLwNr8dKifbQMuoG +ySEhBjIgwnM3nf1cCGMCMtLUaU0qOwQVZ0V8sHzYDkK/xj6RJOVn75AJtBH2tTy4iSe/q2KxEgp rTnYPkvatf3YCdnQw6/dk6pzj9DTWIXJ+tJkcHoRR5/q7dIXlpeX7/w2cFngERYR13CXzEq6oaJ0 LNLIZPTmB8Ke4vAkiENmpZc6LtJuHN3RhkfTgY3FhTWs4b8G6S1M+oZwMB2g/dtbGjZBA9QM6pTZ IOfUKIShciajxaTWsaj4zqPivWfUwL06ZLanV/fH+Yv0T5UNI4W0rKHpN9q/avmmeMWUvJrVnKyL NiQ+HsBj8Ep8i+rn5NK+rlX16fROb2QLwKPpUOcEIhkICrtTUQJXEDqnVsNiR0hsyvSdEQLtV0YN K6Wsj5NIfW/wOlpyFYc3PriidwduYSjxwz1ER37yMJYMRtgN1ADFDFXIXgqeioF46OBHdDTxQKWx uqpi4dGdU7Naz32VbyxZuz/xne0Ji7CSdppawsdGJCfERr9VUnNgTOuEjPFWiz16JsvA4T6uSdYF 1R/srUdW+k5P5jmcTkHjyUZvXWKuSflm4YFDnHWumJaAxfuK2Ufke7O5pEwnbT1zMvjLgT2NQotg 7x7dVgwZWbPjZCXxZycJgnhcJvXwJWA3qjHYkN2gVmmsNpWdXKaQkfQCDm0ZeZbUxw6ej40naePC hw7aJ3LxM9huC67FN7iF7PuIRd6Jb/jT2X7cwlOKU+yFipEKGhOBxXtWWmLKtHmvTs1x5+WU5oQn LC9iH8x/AU2+3ugKZW5kc3RyZWFtCmVuZG9iagoxMTggMCBvYmoKMTUyMgplbmRvYmoKMjcgMCBv YmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvVUxTSUxFK1Rp bWVzTmV3Um9tYW5QU01UIC9Gb250RGVzY3JpcHRvcgoxMTkgMCBSIC9Ub1VuaWNvZGUgMTIwIDAg UiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciAzMyAvV2lkdGhzIFsgMjUwIF0gPj4KZW5kb2JqCjEy MCAwIG9iago8PCAvTGVuZ3RoIDEyMSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFt CngBXZDBbsMgEETvfMUek0ME9hkhVaki+dA2qpMPwLC2kGpAa3zw3xeIk0o97IGZeTAsP3fvnXcJ +JWC6THB6LwlXMJKBmHAyXnWtGCdSfupambWkfEM99uScO78GEBKBsC/M7Ik2uDwZsOAx6J9kUVy foLD/dxXpV9j/MEZfQLBlAKLY77uQ8dPPSPwip46m32XtlOm/hK3LSLkRploHpVMsLhEbZC0n5BJ IZS8XBRDb/9ZOzCMe7JtlCwjRCtq/ukUtHzxVcmsRLlN3UMtWgo4j69VxRDLg3V+AW40cBIKZW5k c3RyZWFtCmVuZG9iagoxMjEgMCBvYmoKMjIzCmVuZG9iagoxMTkgMCBvYmoKPDwgL1R5cGUgL0Zv bnREZXNjcmlwdG9yIC9Gb250TmFtZSAvVUxTSUxFK1RpbWVzTmV3Um9tYW5QU01UIC9GbGFncyA0 IC9Gb250QkJveApbLTU2OCAtMzA3IDIwNDYgMTAzOV0gL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA4 OTEgL0Rlc2NlbnQgLTIxNiAvQ2FwSGVpZ2h0CjY2MiAvU3RlbVYgMCAvWEhlaWdodCA0NDcgL0F2 Z1dpZHRoIDQwMSAvTWF4V2lkdGggMjAwMCAvRm9udEZpbGUyIDEyMiAwIFIKPj4KZW5kb2JqCjEy MiAwIG9iago8PCAvTGVuZ3RoIDEyMyAwIFIgL0xlbmd0aDEgMTE0NTIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngB7Vp9eFTFuX9n5pzdTcKS5TuwwJ7NyYbAbkyIIBC2ZPOxEViEQALs UjS7+eAbE0zAalFilUoXFVSK2lrAWtQKlrMbsRu0Er21vX60YLV+1Qpeta1WW2rV214he39zdgHp 03vvc5/7130ez+R933k/Zuad98zMmZlN91Ub2ymPekhQeev6WCeZj/dlkDGtm7q1DO/4kMhx04rO leszvBt2uZGV665ZkeG9fwPdvao91pbh6TToJasgyPBsCmjRqvXdX8vw3hdAbes6WrN67ynwlvWx r2XbpzfBa1fG1rdn7H07QX2dV7Vn9SxMlH+nP6OkdPbJsucJQ5bzw+SnF8lKnBwUoG8Sqe8rfyQV vNRbiVZPOJNszvd/ahttM8t+/51xT8vMKze9Fv28+8wtjitsC8HmmPZSgXJW90AQMaHPu//+K8cV 5zRSKx9enUtN4s/8ERpHLvEn8RF8cImPkpZxrpT4sFdMclVVjxDvUlS8T3vFe3QCoJADEgdyVYBO 5NMANd0v3u4NBisCKVDvRSZNlkys6JOK5JixFT8Rb/ODNIFcEJxIjnSamreSNTXZzCXTM5neSaUV J6pzxVv0ZwAXb4kTVJIp1VtyUcWpajsETFxP+YyRi/aJ35IB4BQQb/QWFVfsPSpegP458Sy1mcWe TdqHVKDCn4sf01B07zFxOKs53Dt4SAVVd4lbEZl+4OOAk4BTAIU6xIO0BbADcAigUD6wC1AGWCAl 4oA4AD/3o3w+cBmgA7ADoCCyD0O+VmLxkFhDhSh7i9hFI0C3iztN+gPQMeC/D/l40PvAS7o3y38X VOq/k5XfA34k+Luz9C7IneB3g5f021l+k9holuvO0n2iKzne5ageD70GKAcI5HYhtwuh2wWOgJm4 UawzPUiAVqDG9RmKt3Zd0q2b7+i63lGjK/YhpNch9NchctchcteRApvNZ202Z2xKxWbYbIbNZths RlTKRRfa68ILI2AHQAMIxL0LcZdyA7gfcBwg6CbgnYB9khNXI44T4dW3xJpkiQuDbWXvjEBF1eNi BUIdECt6R4+r2HGey8mVA3FFb87gLM2Xtu2mbXtvziApbe8dMy5DYbW2erBopa8DOA0HLgJMAdQB FNGaLCpzHRHzab2NAoNdW/gWsUXZoirldWzoUVFBDZiZLhoqSslvo8dczX42beu+6q2iBQ0SsAPQ CdgJUNDbZsg1cQWgGXFpRgeugJyACZwDcBz5k6AquHzY5cMuH9J8SPMhJWCpaQBEAZ0AqbWc05wt I+1PSQ1gArSDUdNg4qhnMOTIAeaCs4Ozg7PD6jg/DQ8dwBqgASBM2Unk8P6Az+rKs/ooqIWk/hSA m+WkLgAQ/HTAN6F/IjMmsn0T2c6JLOCvqq4IFAINHTp06455h+YdnXdsntI8r2PelnliWird35v0 lleYtNAj6eHk6DEV0/KrZ/JD8KwZeC/gBECQC7gMUAXoACj8ELCLPwLpI5A+QgsAzQAVJR5B+Xxg qZc6Kd8LUM3cCeT4BXqBPhxMVl68oPoyrGPNgL0AgboPovxB0zqTO2TKDeCTpnwBsLTfB5BeHjxX RqCFg9IPsSyLXchVAZoBnQCVjomlWHeXyvqBXYBOwCGAIpYhLRVL+SNIB/lB4QvYJ49w0ciRWNuH DrE5qh18EF6qnT1k4rtN/C0TV5m4KDB4rv2zufYn59q/Odc+ARleQtUosMvE7kBetf3RavuCavvE ajtqG0VusvMRJrZIzP5o4vkm9gWGu+1/d9v/6rb/xW3/ntu+wW3/iluWG4tpYefDTZwnMdtt4rkm Lg7kuew/c9mXuuzTXPZqO9vD4APVmHi8iZ0Ss48fza/Lp5zH2cdUh/pY0j/RleJkEpZO+qtdKTaQ 9F8Kcibp3wPyH0n/na4n2N+Z+bVgnyWL3nVVj2CfsDkKvh7sr1n6FzaHDoA/BboS9AHyMw/oD5L+ G6T9/Sj/HfDfp0KbLHcfNZjl97I5pvx72XL3Jn0taPW7Sd81aPU75GPS+q6k711I70z6vgVyR9K3 DmRH0iMdXJP0T3JVD2ErqYhL21bycOnJvGyLs1HzOvCXZgoHkz5Zqk42kGK1SX0yyATp5RNMpwaz OVdSNzs5jnTTubGkm047yWPSwSzfdN5OhSa1JfUbUIvlUc+7rn/3Py47Tp+y/OQe1ztPoH9LwP4b m5M84HqxT4Yr6TrmSzHPY65f6o+7nilKsSVJV78vZYPiqC/F2WFXAkE2YMvZY65DvpWuR3RTu1+H Fq96r7/U9V19meseD/ik6wbfE9INWo8eL4E64pvlmuc/4Kr3pBjUAT8aC+S6KvWrXDMgnp5ic3oP uCYXpaQr5ajjwGOuSWixWIcrj7qmLl487QifSla2MeCzdltbrEusC60zrRdbS62adZx1rHW4bajN YRtsG2TLtdlsFpti4zayDU+lTwa8ctc03OKQxIKVmJFi5h1Y7RimoMTEmY1j9hjDRIiHGmuYMTRE oaYaY5o3lLKmFxnTvSHD1vDVcIKx2yLgDL4txagpnGJpKdrqNIbWhvuIsbKttzol3bz11kiEhYz+ Vgq1aMZnjehJ7sJlhqrXFNDITVUFVUNnDZlRX/dPUNQURuu855+C81nkCsbVGLtDjeHk1IcfHlcT MSrMfDqNfMi4tFFbHu7jG3hHsK6Pd0oSCfexa/mG4CIpZ9fWRc6ZUSHvhBn5JZFmvVQozaiQ9Zpm 88zaMF4Lg3WJQiBp9DSbI40wjp42jVaaRhjsG2RdDZLAjI+nIrOuIj5emmFgZCrL/2Jlg4jlm5Xl DyKzsrHSKOHxoD0fUCScmOaBQcIzzVQfOK/WTXUfi5A06CMPi5jtMLOdTBUlGRsMhqwNt8Hmgmj+ X5n2mv9FDaw39mZba7BdD0b1YDsgamzftKrA6GnRtETbm1KhGaI42tK6StJYu/Gm3l5ntOl1WiJm lvsHdatUx/S6BLUGm8KJ1kB7XTIWiAX1WF2k94EttaEL2vrWubZqt/yTtrbIymplWw+Y5f6hrZBU PyDbCsm2QrKtBwIPmG2FFtWwUEM4YaOaSC1eoKS9PC8X0yLqdEdqRjo6Z5lzZKa74HrnEYXw/crz RoxBeo1hB8jpU1pdWi1VmKRSNRji/Kyq4PqZbucR9lBW5YB4iF5DXioIrq4799fV1dUN6OreuNEL 3L1RapHB5HU3hoz6hcvCht/wB41AtC7C5GuDYThwSbPe7Gkuad6vdOgdno6Sjv3KAn2BZ0HJgv1K lV7lqSqp2q+U6WWespKy/YpLd3lcJa79ykbzidSGA46j/mN+3uHf4t/h3+s/5Fc3bpTioUcLjxXy 5sKOwi2FOwr3Fh4qtEjF8vBjAf/ewj8Xio0YiawbT1B6Ca9B8SfZ7o2yI13wriia05nTkyMcOVpO eU4gpyFH7RBbxA4hXKJMVIkFolmo2EYlrZUXgwTqLZUX78zbl2fk9ecdz1MNS7/luOWk5ZRF1Szl loClwRK1dFp6LDst+yw5Oy07rTya15nXkycceVpeeV4gryFPdVkZoXddABmjjRudAYfVUufKy61z CV7nyrHVuWT4It6N3tpwdSG1Yn/MsJcvpWEAHXAxoBGg0r8AvwR4B/BXgEI3At8JuB/QKyWiVJQG C1bXyRhEUGMfFYiK3vKpFdNToLEVGdq4LEOD8zPUX11RAH2y6uLc6nxs1RkdAX4O8AbgA8B/AFRR ISrMytEX0+ku6vIydIvAdUvU5e1mXmSYHDvdXV4vDCQPATgMFHOsyLKZh1jXRurqIowuEBiZ4i5Z DG2gbPaBQtbiJfU2nP3nkQswFicyJ1H6bcC7gD8MzE2fVteSPrAmfVIMw+fokSwQeWg37aUiOsUm 09PUjw/UA9jDNdAuupSO0SEaTNew5xFPHVunh7D+ufA5q6dRTKV76HVaTlfRe3QSJ+0QvcWGop4g deKkOSP9PnCItqX7YJVLtfQjOsLWsUYqQ3429yEWHtqR7qdRVJL+Rfo1cN+j91hROkGzkfsdDcE5 YgvdjqP3GnouLW9ciqiFHmSb2fvYNEZpuzJFiafX0kw6TL9mIeQuo2vU13IOY9tzO93PRrH+9In0 7+lJbBLaUdM3aBs8TlI/v0jUqvtIo2L6Cs2nGLRfp9fZMDZZBNIT0jXpeyB9kD7mXv4zYYUfXppD zXQr3YdovELvYo+Tx6ay77EDSC+yP6mvwbcQbaRrqQeeP4CyB6mPTWaT+ShsfDl6OJEWQ7eD9qP9 XjrOQizC+tlTYr9aPlCVHp4ekf59Ok2TKAwP99JTaOMTVg4btCAKRbcyXulWK87cgB620b10HPc9 r9BbiPun9Dc2Celtfj3fkl6afij9HnyxYVM0nRbSMuqgTXQ1fR9v9Wn6Kf2Ffc5zYHlMeUa9Vj2V vgOxLaYa+L4A1o2oezveUpJSSK+gl0OYhl5MZ/PZIraS7WC7WYq9zl7nFu7Gp/8DYYjnxZvKJaqa rkRNI+XpH6NkKa3CG7ge0b4D/X2InqFn2QhWzErRo1dQ/jM+k9ch3c+P8bfEVrFDOa1+c+DkwB8H Pk/HcV9Vh3EXRjQfRhT+zEbCh4lsDeti78DznfxRMVg4hC6mimrRJCJim9gl/lX8UrlKOaC8oc5R Y+oBa2zgyoEX06H0TYgFtmPwawL5aApNw/hZgdG0Fv51Il1Fm+kGitNtGC930D5s5FN0lJ6lX9Nv 6UO8AWJu+Lwara/HqNvKbkO6hx1kT7Fn2LPsbfaZTLwQqYRfwqt4La/nK/lWpF38OH+F/0GMFa1Y RXuQ9uD66HV8dRQlrVYgzVa3qw9anreWWGdbW2wvnP7ozKQzkTNvDdDAmIGvDuweeGrg9+kl6Wvg v4dK6SJ4ejO8vAdjcD/SwxiJj9HP6AV61fT1Y8aZihFfwHSMBh/eWhW7FFunOewythBpMdJStgwp xlrYKqQtrId9g93IbmK3sm+b6W70bT/7IXsM6cfsCNKv2Qn2O/YB+5hjEHOB0ezhE3gZn4Ge1vJL +QK+CGkl70Dq5FfxTXhDD/Je3sdfEcOEB+ttTGwQ94gfiafFy+LvCld8SpniV5YoK5UblWPKi8pr yueqSw2qq9Q96tMWp2WKZbFljeVuyyHLHyynrRZrA3bhm60vW9M2D1asn6Pfh/FOzz9llmOsSx2u fI2fwLwoEJ3qzWwxImbhTWKduE38Sl3BTgmNvcHiYrVYm75f1PO/iQ62hB9lhcKlVuL65xZKswP8 bf4J/70ygjXx91mJcjv7Me8QtRy3IVhTX1JGKDeqf8AG/lWq5Nexfv4MbrtuTP+EKtU97IS6h79I mnKSD6MTmNU387tQ6Jd8Nd9OYWWK+jmtRtx/qH4N8Z7Ft7FJ4mVlD70ndP5XHBt3Y9X4BZurFPEr +Ax2ACvuGTaePmIbqJN9mwLscfZblsJW/yHxIJvHB+FtGdzOpuE08QvhZi+LXIpIH1kxH8Ea+Cm+ WDxhOS6m4jx3nH5F1zLByjF2zj4DdCVmwC4+AWtaEKvJS6yCCugurPefDDwhV2z1NXU7xtl9wkeL qJwu589TJebGe0hh3C1X0BGMwW1Uzu+mzeke1oZ1/zKsn5xwIKUylofVchR824LvxUheiLWwGU3/ Dev/c1j1Q+xPdDXTMLP6qUSRmluUIFamKNbf7UhtdDm4e+kOy2H1JVrARhEp2sAejPI36Qp8c95B +2Nw03w7Vrb7FB+81rAyb0CJewdmUwDpm/Q843QdfJ6Fed6gzMbKuzu9Bj1cjW/UPHwTn6XV6buo Fu9uUfrG9HZqTt+XXo6je2P6Iay/m9JJuoRuViN8iepVpmCNfZb9FN+j37DtWLdn0xtYjzysgD5A +hH8n6U+TnHlVaydVelb0r/GzWwJbmvvwTozF6vXevoT4jZb9NPFA/N5Il0vOvGFOkEL0w+mXSyX VqXXYeV9gvZbVaw9PTRe3Y+xu11Zwcvh70QaycogXa7uFa+KvyjZ3wbQ6pfPlxH4MgJfRuDLCHwZ gS8j8P8nAiNxRhqF/VYBdjFOnGEnYscxCScTub8vw95mCvYe03Bym4H9y0zsc76CXUwN9j312E3M wz5rAVIj0mKcsSI4eS/Hfuly7IyacYZtwy5sJU5eq5HWYpfXgX3RJvP0dzX2Q9djR9aDs843sEO6 GSmO0+xtOPfvxs7oLuyf9uGMeD92awexy+nFySJFffQkzkJPmefGZ3DS+Dl2cM/R89iLvUC/xPnz V/QSzh5v0G+wN3uLTmB3dRL7s98Flm7t7rpqQ2fHlevXrV2zetXKFe0tly9uWjA/UDXrK/6ZlTOm T7tk6pSLKyaXl11U6vNOmlgyodhTpBe6Ndf4cWOdY0YXjBo5fNjQIY78wfZBebk5NqtFVQR+4PAF 9fqoZhRHDaVYnz27VPJ6DILYFwRRQ4Oo/kIbQ5PlYlBdYBmA5Yp/sAxkLAPnLJlD85O/1KcFdc34 RZ2updiyhWHkb63TI5rxkZm/zMzvNPN25N1uFNCCBavqNINFtaBRv2lVPBitK/WxRF5urV7bnlvq o0RuHrJ5yBmj9M4EGzWLmRk+KliZ4GSzo4vGGL0uaIzWURTVCE8w1mY0LAwH65xud6TUZ7DaVr3F IHmF6TVNqNZsxrDUGlazGW21gd7Qdi3h64/fknJQS9Q7qE1viy0PGyKGOoLGEC/arTNGXftuwXkW leOy9OYvap0ijgsuTRrH4zdrxr6F4S+UdbplDZEI6jC4pz4ar0fDt+A9heRdusG3RsIG24oGcd3r MfuU6V3mLtoTXaMZOXqNviq+JooXMyZu0KJr3MkxYwJ96ZM0JqjFm8K626hy6pFY3djEcIovuqZ3 dEAbfaGm1JdwDMmENTE4P5sZZP9iph0hz+jMnGkuc6FF5+LKpI/6HFzgGlqrBk/COvo0XaL26RRv nY7w44kwlDLa8D5WGzm10bijEnIHusgM1ePQtfinhPevf/ThhZJYVmLxOD4lqZSj5NxAM3BCzw46 w+s1Jk2SA8RaizcKH2eZ/NRS36YUN/ROhwaCq3xqQGxjkcoyBN/tlq93eypALWCMnoXhDK9RizNJ gTJcefOo1PSf1YxYLDU9ZzXnikd1jONHcQFBNMKwFZ/7y3eMHBZcVWmwkf+Nuj2jDzXqIdyHa8F4 NDtmQ00XcBm9DCjiBl02xzIFEXBD8RgWzxwdQ28RLtYhwJ/qqdeDq6OzMdXgozGsNiycHBXIHHcK syqM3+XLztYnmfAgWZfisZjjvy1ltWEAmxKm1RuO6OwMjuS63dnp9T8VSqVPyVImOV8s22ej0pvt VaaPxswL+AvcGxQXoSasTjzUtCwez71AV491Lx6v17X6eDQeS6V7WnTNocf7RFiE451BrFiZ159K H9nuNOpviaArq1hlqQ+rFDXE420JEp6msBFwJpiZmVa7PWIs8EZ0o8Wru/VwO8KVqKRB7qZoLXKc ahI627YwEWDbGpeF+/AzpratKZzkjNdGayKJIujCfRpRwJRyKZVCaaJJBsd8zKUkt5n2zr4AUY+p VUyBybfid01TljGCjFErfpA3ZQ7TLlFsNhTA3UJrSsloAmdrUCCzZWQ9GeuSrLUNGofUHMHPrbix kT5nngSYpnAgd1qgMjAzMAv3dYiIFCUhOQLbmYx6Z+HizJlAnegBxCnWk5gZcPaZNWVER1gPLKWs BxVmzThJsy9UhCYzHV8Mku3B4mXh3lmE+k0Mixr5yPUSTmRHjTn+MW7M+YD1BaO9FR+wFaApTOGo jlmtz03w+VjvQZlJ43P1YBssJOALMRVeubW2iLTS5eiQb1j/r4xQxTkjue6ZlccdMzMrtdmEyUGF v7ix0nsBu+ocWw+1/PR6LsrMKoxnc2y6jTVOY13EK9WmSUz+EBnHIK6UIxkjFdJLJUQxsS81elpj 6Iec9K06BHMh0MIt+HkPFcrvShyNaK0xFFOKz7VkXOm9oEoMftYUdqMiGQWjp0GLRrQoJgtbGMb8 1gwVVFsRMwJ6TE6QBrSPvwasVSCxeCPKUgSNOg0rVqwVsXZdrgqQRcy4mm8Grc81qDFskDMe1+MG g4ueehij+mLDUjxHEvx1evVYu9yGoD0t1m6WrYe78t24pX/OoO6OwIR7ZNxl4DAXWiRqjeuo7fKo F5EYEh8a12bEMbIvx6RUiluXRDGBNYdWr5mvOuYEh7jOkVwEFWUMczzSEOXNv2JjvTdxudVzXmLK O7wZY5tZKzxbFDYazhayegz8oYIN+JeEUdOhlC+IyfU4szrL4KmeOQhvAEPPKUtrBseiYy6vsrDV M0cWdWYl2WKQmHNTjncs5AkP29YQPj9hmpYbw0KLvupEYEsJ/0A7g43loHhwNW/SQbjdH4Sc+5xE /hITgoSzsbi5HasS/nPKSuuMrd5wgrPH+ZMoYeVHk6QqKf7ko4JyrTJzmNFom0U9Cj0nwSZSDlvL rqACr+Mz/xn/fMcn/svO+KkKecdpoMnlzgQpKeurveuIWUET6xgVlHnLvOWTI+4h7iEeIDZWodOa 6D8dUOlzXBD3my7D06FZ7y04CdDieY1z5gW9TavXt3fNb796Ucf62JUNjZc1Ef0nMyWKCQplbmRz dHJlYW0KZW5kb2JqCjEyMyAwIG9iago2NDIwCmVuZG9iago0MCAwIG9iago8PCAvVHlwZSAvRm9u dCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9VRVhPUlorQ2FtYnJpYS1JdGFsaWMgL0Zv bnREZXNjcmlwdG9yCjEyNCAwIFIgL1RvVW5pY29kZSAxMjUgMCBSIC9GaXJzdENoYXIgMzMgL0xh c3RDaGFyIDQxIC9XaWR0aHMgWyA1NDAgNTA3IDc5Mgo1ODggNTU1IDIyMCAzNDUgNTI2IDUyMiBd ID4+CmVuZG9iagoxMjUgMCBvYmoKPDwgL0xlbmd0aCAxMjYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp4AV2RzWrDMBCE73oKHdND8Npx4gaMoaQEfOgPdfsAjrQOgloWsnLw23ek pCn0MIdvVyNGo+zQPrfWBJm9+0l1HORgrPY8TxevWJ74bKzIC6mNCjdKMzX2TmQwd8sceGztMMm6 FlJmH7DMwS9y9aSnEz/E2ZvX7I09y9XXoUuT7uLcN49sgyTRNFLzgOteevfajyyzZF23GnsTljVc fyc+F8cSieDIr5HUpHl2vWLf2zOLmqipj8dGsNX/Vvur4TTcThZ5U0cRlZtG1EUBhIh2Q8QNEMJW RyyBEDCPuAVCRFuKuANCRLSPWAEhoqqM+AiEcHPy7oEQsEo5fxPFyLHaexXq4j1aSP2nguLDjeX7 F7nJxYcm/QDDSoj9CmVuZHN0cmVhbQplbmRvYmoKMTI2IDAgb2JqCjI4MwplbmRvYmoKMTI0IDAg b2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL1VFWE9SWitDYW1icmlhLUl0 YWxpYyAvRmxhZ3MgNjggL0ZvbnRCQm94ClstMTEwNSAtMjc5IDEyMjIgMTA0N10gL0l0YWxpY0Fu Z2xlIC02IC9Bc2NlbnQgOTUwIC9EZXNjZW50IC0yMjIgL0NhcEhlaWdodAo2NjcgL1N0ZW1WIDAg L1hIZWlnaHQgNDY3IC9BdmdXaWR0aCA1NDIgL01heFdpZHRoIDEyMjQgL0ZvbnRGaWxlMiAxMjcg MCBSCj4+CmVuZG9iagoxMjcgMCBvYmoKPDwgL0xlbmd0aCAxMjggMCBSIC9MZW5ndGgxIDE4MTYg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBdVVrTBxVFD53ZnaGZenyXgQWynYfLLAP 9jnQLstzgQqFQqGBgnaXZWERliLFtthH2tK31tY+KJQ/LWiNbSVqY3ymiVZtYrRRExM1jSZNrTEx to0xGIFZzyyLjSbem5kz55577/nOd869MzL8TABiYC/QAP6QbwgijexFkd87MNoT1T8GkOQHA77u JR0WUDqDOBC121FqgqGRHVG9DaV+YIt/2X4VdUXItyO6P9xGPWfQFwoszWcfiPP/3244iXbD0HBg GR/uH3/atbQYwtEWVR8Jgp+xMInxvQocUJAAZjgEQN1PuAYMEOwA7L2eyZ/Guc3xrj9AFhNZ++69 iRLx46vj5Lu5vMVPpDdjfLhais9Sw3XceaEYQPrZXN7CuPQmjEB6+FzUKopYSRVcJzcAmLfCM0wT 7GY3gp55GvIZB7QwpvAJRg4bqBuwB+cu4QCIAxaUqKvQE42YGfQnQasUxzlxU2zrsZ+Ar4md7CW3 KCPVTZ3FUQau4+uQpAX0YIBCwGwQh91N8W7aYdepV8kpTu1wE5s1m0pNQUVOZ5G0VLWDJKoSxYfi WUW+Jk2XGV/uzinUpEu9rqOV1X63Ml7jMuToUrmkk2RhkaV9C0XkZ4VCm+/ITTfbitV1zSkaa/b+ bFOWrTpP5y6pNqoMuXolO3jxonCXOT/fw8z9dRVRUeEZxNckCUA2aDFA3k057Gai4uQkNSWNE3We 2JKzqTSOqGgTcaipSzKjLZXmhFo+VxOQCb2ylby7iNp3rlaSYSyQLdaRw4k0I7MwhoayXNO+Lo9f 15JgsTB5G7xMy/zLje0FrIVSkoqKTw3I4O7wA+YCes9HXmi1iYiMIBMKm9VNeBstxwF0aued0S5S pWAuuLwxHYGWMwe67P3DdUNdhd6Snuvdu2bbYuMyVFanp7y+erqjY0piFR7uDPnfnxfm+2Ymjf1e 4a7ysd4bR2urWvw7A/3N9TazXSFmWY/FdljSClhbYug0h44RRCR+mk928mo54YhaRtTsf0xuBKfL 5VXJknqyRqZTZWamXlkRY3TIhCGZTpehUBzM0MuziouE4pA3M0Wn8ybGisbpJePl2LhCq4wEhiWt lpgUfat34c81HqVRy1gsbGahx091bD/i9D+xmEj9RlbMzwr19Y/nPLLSVEGD3qylLQtOrEdkkDmO MaixyoAs1ROyl0vLkc9s8k8sEbzEKuZZpJujqV+2T/otL/x+uaeqTMpJUvQWmRCI4lOY7DJCRs9u trsGW91VRySt2nXbGsZvBxnh+zyDLWWlOmEZK011r7boaMtijbXv5MbWrjx6cRoPNLSEH9I/0F9A JtgQF5/2iNpcMbs6PA005pSOMInpZ5azjwVAV3SWTcpjTeVS4U7pCu9V7+CooX3XjNc9pJSyFevy 6xtqVucUV66sbLab+ST6uYqExXZXeWqeVmKZZ57ff2nc++FrBxqyhDfyXOqGmszSnlOvNAZ7lXVr K8faEVv4hFBO30FsZqgASBOJEguP4v+FLA0xs/GE5VhOTqlzHHYnr7UuH18RbU9yhmwg5D/Q6dHI fZe8odHVwbFTjaVDxZ1lQVlchlm5ylSwbapPOFRVR3ptga1lxmXoro1pxvysOk/1i9+8SR989qWJ Ld/Obi3K1lQkCAXW0rFf23s9pa2m20WdtrHqiWO3MNzlGERmN4Tv0+/Rn0MKrMJ/gMgkHhI3hXcJ Fi9iJWI0zqTIPcNSZHLqSnyy2nj87b6tpyvSNce+FH7s6OyaaGtpD061J87OuJr6mgKn17Wd87cH ztzqJ7rBvtdJyY6B0KzwAZ6RPeEHtJy5hvcEaKOJ45PVeI/xNk7FqWg2Qp6Tp2aaL2x6Kpi066xs jceszz7GkxKF8JFX77CZAq53/IGB3tIGirNx2pKuJ+cCwq7p9SWlNbWRO5RAEnoSGwupAK2etsbm TQWVvlDXcJ/PuHbEN9Dnh78Bxe+X3wplbmRzdHJlYW0KZW5kb2JqCjEyOCAwIG9iagoxNDczCmVu ZG9iago0MiAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250 IC9ZTEtBT0krQ29uc29sYXMgL0ZvbnREZXNjcmlwdG9yCjEyOSAwIFIgL1RvVW5pY29kZSAxMzAg MCBSIC9GaXJzdENoYXIgMzMgL0xhc3RDaGFyIDY3IC9XaWR0aHMgWyA1NTAgNTUwIDU1MAo1NTAg NTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1 NTAgNTUwIDU1MCA1NTAKNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1 MCA1NTAgNTUwIF0gPj4KZW5kb2JqCjEzMCAwIG9iago8PCAvTGVuZ3RoIDEzMSAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBXZPBbptAFEX3fMUs00XkMYNxIiGkKFEkL9JWdfsB wAwWUg0I44X/vue+pKnUxVkc3nvDXPy8eT68HMZhdZvvy9Qd0+r6YYxLukzXpUuuTadhzLa5i0O3 fpg9687NnG0YPt4uazofxn5yVZU5t/nByGVdbu7uKU5t+qJn35aYlmE8ubtfz0d7crzO8+90TuPq fFbXLqae496a+WtzTm5jo/eHSH1Yb/dM/ev4eZuT40ZMbN+v1E0xXeamS0sznlJWeV9Xr691lsb4 XykU7xNt/9Gab+tKeJ/7OqvyHAXvQycNKHhfttICBXQn3aHg/f5RWqLAbCPdo0C1lD6gwOxW+ogC ai9qUKDZTm5R4Kik5g4F1GYjCtzZZhPaWzWnORBeeL/TnZkw0CglnPC+0FGBcIKqzRIuWMCdEgXC CV6kawTCCdSaCRcsYNmrSjhBImsmXLCA+0JVwgkC7qWEEzQ/SAknqNrJhAsWsLRZAvIdVLVmsgbL W+qSBVkF1SAlr+BkffaCrIJPp9+3IKtAmWU//i6CVkUr/bmC3XVZ2D7be1tMLdwwps+/xjzNOsD4 A6pV22AKZW5kc3RyZWFtCmVuZG9iagoxMzEgMCBvYmoKNDM2CmVuZG9iagoxMjkgMCBvYmoKPDwg L1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvWUxLQU9JK0NvbnNvbGFzIC9GbGFncyA1 IC9Gb250QkJveCBbLTQzMiAtMzAyIDY3NyAxMDExXQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDc0 MyAvRGVzY2VudCAtMjU3IC9DYXBIZWlnaHQgNjM4IC9TdGVtViAwIC9MZWFkaW5nCjE3MSAvWEhl aWdodCA0OTAgL0F2Z1dpZHRoIDU1MCAvTWF4V2lkdGggNTUwIC9Gb250RmlsZTIgMTMyIDAgUiA+ PgplbmRvYmoKMTMyIDAgb2JqCjw8IC9MZW5ndGggMTMzIDAgUiAvTGVuZ3RoMSAzNjc2IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AaVXfVBTVxa/990XggqBkIQAMZDwCJFAEPJIIkL4 CAiI8inFUIHyGaGAqIjit2hZ66JFtLV+UEpddLpoqdpqqbZV1plStuN07W6X2Wmd1nGt7dS6dsd1 u5U899wkuq77577JyXnn5t5zfufcc869WbO6sxH5om2IIFTfVrsSuR/8HbDq5a3rnR6ZeRmhWcNN jbUNHhlNA7c0wYBHxknAo5ra1nR5ZQfwva3t9d7fmTyQ89tqu7z60Vcga1bUtjV65kvmAY+6IvZI 8z/wDcCe1//vmyqJwimoEK1FYsSgQDQXPVJM4I2+i0puX35wvfC5gNR/oBm+bnsXbqgM9OVK8RfN 072uV0QtvkoQfUGD54F1op9cP+Fq1jndK5SIWh5r9U5AUawTOYAQ0EygEe97D/A2oE6vPAT8JNA5 L6dyJdCkdywdOB2zA+mAcoBSgO6wTnwYCPThCiANEAPj1OZOoP1Aw0ANQLuArgIwj78I+SEfVAyy FnEwFolmQWyCUQiSIRH8FgSj4UiJIpAGhSEV+EwQi0LRbCRB/kiK5GgGCgANCjQT4umL1KDH8xSg AtSEhtAHYMiM1+BD+BK+y8xgIpgFzFbmDeY2kZN5pJB0kv3kIvmW1bJ2tpxtZreyn7DfiGSiatGI 6CPR56CMRZA/rESkAttiQJII4KVaqZvkEoYTc3reZE6KZzjOzJvCGWwKVtDxyHjGnJTGsJLpfOJw sUyLxr48j23wWb3XsLglg4tpPtSYKIzpEv2VmqCgCKVEoowQqX65KVI9yGTrHgwy3xmfydQPTu8w 5vGqBr5kuesHXuedFxSkCZEgiMZMQFYJyMT0TcsRLeEwLyOErfzdMtc3le/jM/cqr13DauGGSDX9 BnPBtYCuGoFVKlgViqLcq+IJx0k5qRbAU+Ti4GAlSYqGMd4E+FWTl4Pjzen6sjO4evVwc2JUbnO2 tWBO4Y51b+5Nb8zV46MJ6bpA13mRyvTs1gJbW0VmoOy5IsanuUkoVicv8WQj6wR7gBFjMIR5rLRi 1ino3xX0U5itcWAx4BsTjHiKZAuRl0bxXYqz5+EdMk4E2Pu5gFPv4+OJqYXnzQAv0kdsTiM04gop 4SIlgD2c4U0WK9Gxpb+tKt9QpLv+1R9Wdz5zzKEtebbOtGxfo+Xta5nVqeqgORnxqUfKd5bkxRU0 2V494ahoieZe81MGzZpTuqnMtRhPhiVkGdTmmJCFRRRHG8Uh6oFsg+ySwZ7ypmCllJdyXkhWeTC1 K42moNpyus+2J1QZ3x7wWThSX75jadyZljr7/pLYJv6l1/H1bRO7cv388fFfNn70vDNvx9jGc++s XYM/lyvGqKVOsHQXPA5HMRAruY9YS1WnMVbFI+ep8XBGbIF0A5fF5C7DuNJPHo1zlC7S5L5T031+ XbKtc6S1+Wh78lmiyWqwJ1dnG0RMrM4UfPiY2C9gRp88NKdnfMPzH/aV2de/VZrVXmyMK16ZRa3T ZFeJ+qH25GAdnFEotAotzQyz1hyoNSkxq9pV/wMeE/JOCx/iLHy0acuDm+wN9f1T/S4rM9l/HPeH CB2w40MIkQmIWAjNLyndLMAKinipmG5ZsIJMjC4t4Wz2Qn501CemqKg07sAw072mQza3ONXlFPUI ywcTswxB77mjchK0XQVcM6C+EQYwUoBl1sq8+fqo0vB9YQr/BcdOf4nzbWqTTqHQmdReTir3Th/r 7xchRXSierYpWqGINs1WJ0YrQCE6B37rAa27hmiC8jRFWf3fhLjRUXz5WyGGCXN9K+qZHsCfCrT8 kQdRDyB6As+T9tn7fQ/8+vvpXHcsYE+ha8t4pcd9sPE4KENHxHGlEIAjr486lmps9oKEUXL7aNIC g/S9MdcqpnvtKk9Q6A5VPrzDzgRdMqQH1U90GXdS0B70uA6gcmfaN51Z1XpiXfojfiZmcVtWYXuu NmZxazblWOi83FuQtf3S5s5x4N2XXqjqrZprc+7Mr9rt5oB/EqLj67ZJ8VsssH1izvJoSydfF1W8 5Rh4w+cUWVLM5S4qSzhFbr/fUvP7iRfWhVrLba6NNAbnIK8vgA6zGzXLRUbrzcG0aGjf1McT2ihp USloCXkqWRlOyIWotNKqurnOE6WO0fLNXTJT87LsjrIEffVQV8rewtL9lswKa4gi2VlasWGxFgeZ yzLjwyVB8qHQsOx0VazeoJLzOdUZhobyZP/AI3KZnJurUsXFxISEJec4AFX6w7+TSZGR7oyO1le0 mWa61ErTS+qpaTKZsiXzw/PCLRwKmSDYOlYmrE6TBPifOM347cNyo3Bxn8C0tgQEuncavJwgt+H8 gqzXS6ApgUZeKndXsJQnEwM+xpLiEuORwdFRjS0LNtq9zefGmL2uLbdgl23MYarHDhFXgx64AMh4 mdIq4zFn//i+2XrvorD2E3Lb1XT0OPPyNC1SpIO5dpgbBALhiF4MX541dCFr3/fHfrW290r/SFlQ 7L7NrxkDCsntaTkedrYKdaCp/GAPuJXVs4d5m2rLAW0xoG0W9QBj+PD0w8bcEn4S7l3HPcKer7Ev JlPCTrxV6MY/43vCFrxd8IW1KUKNGzXUPMZu5z17DN0LziQKRi2MmFf9aqg+zBAanKROWJKfrRHa Pxb4+T8Api27Pt6ayjCDRDQ7vSGXOjkwBDc9jO4II8xVbIfTCimD0+BM9Zyr7sZPK+AOX7MwTh2l DtTyHJeZqLatP9t1hQmOzYgxJMWZDIr46BB16rO2JYfW5iAGH354h7nyuIKe6iBPdxSGj5hnCA01 zIvQWA0hIQar5imZCE//6OKeHqHhgJMMfEiBukX4KZtMbKTNGBZmtEVyqZSn4pSweBsX6REiOVt8 GNVQIThJjuhNOOkRdvc/qZbkCDL8o/A+zhWcYvvuf/2ZztPAPP9H82inNGuJP8xbIFyAuc7dPobd EAWGnCIN0PHojcadN3BxIPjr2cNqpg6+oP/G4i8owQwH9BwJVIkMTj84h/+360TrcTg09TRGJw9W YrhMQAWzktQNZzc0n9xgt60/t57yUyLimgqIz1xizm4vNLhGMGFiAuIzSnkqMnsO/PN0bdGwMHrg Z+DHhHcjszRCY5IjnbNvH++NSFPjQ3yZLdK+YxwyYiecBzdFWne/pgUr0ut4CMfN6U9xsTCRgYcO 46ij5PzIy18+6AbAaD/MvwseaBDSas04DdoN7ZQ+Yj3tZt5Lj1hL7k7/BpcuaZovD7OUpy55Mbkm f3zb0r6m5DklG8t+ZDYO4OLSrnoHn7DUHp2f0lFYnVT3UsWibVtfLLlFrQxD9U+BFcujGHl7nCdl 3ZdD+goN7j8XFzjhoc1N5ez+057CTZa0X+fV9TrmJCxdn/fKqym1C3TbNtl3F0cWFCzmmgaft3Q0 8PVFiXhP+aurMmf6Dszy4+zVKZZii6ovYv4zluaasLCDfjJ/sbGsa9HKg0bfhEVOODHgPxL5HlBF IJ7iYnxYLxKr9b+vFPiJk8MK8SHfV74r3B9tW9/9wWa7L5s+XFN/oN5kX3e8ofZYV7Zgmffcgjlq W41dV7QoWxWdt5yZuij8eLrsYFJjf1WMzji/qa9s2WBndkbfX3GULrcpy1aTFSUJ0QR1v9UcB9Ha 9fAuOcCWwi0f6cQYKzE50OaqYYbaXF9Xr2ASmcR2IYNG9SrMu+aZJ7NirMdXW5khV00royU32l2f uT5bgccRPBg6IKYv8G8gAKGKxYsyixbGZrWv6Ghvre2A4X8DZNp0bgplbmRzdHJlYW0KZW5kb2Jq CjEzMyAwIG9iagoyODA3CmVuZG9iagoxOSAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAv VHJ1ZVR5cGUgL0Jhc2VGb250IC9UR1lGUlIrQ2FtYnJpYSAvRm9udERlc2NyaXB0b3IKMTM0IDAg UiAvVG9Vbmljb2RlIDEzNSAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFzdENoYXIgMTEwIC9XaWR0aHMg WyA1OTMgNTUyIDI3OAo0MzAgMjIwIDU1NSA1MzEgNDQxIDU1MiA4MzIgNDg4IDU1OCAzMzggNDE0 IDU0NyA0ODggMzAzIDU2MyA2MTEgNTA0IDY1MyAyNjYKNjIxIDU1NiAzODIgMzgyIDM1MCA1Mzcg NTU0IDU1NCA1NTQgNTU0IDM1MCAyMDUgNzc0IDI3MSAzMzIgNTA0IDQ5NCA4MTUgNjIzCjU2OCAy MDUgMzA3IDQ5NiA2ODEgNTQ3IDUyNCAzMjQgNjYyIDU1NCA1NzUgMjY0IDQ5MCA0ODMgMzkzIDU1 NCA1NTQgNTU0IDIzNwo1MzcgNDU1IDY4NyA2NDggMzc1IDM3NSA2NTMgNTcwIDUwMCA5MjEgNTU0 IDU1NCA2MjkgNjA0IDU1NCA1NTQgNTU0IDYxMSBdCj4+CmVuZG9iagoxMzUgMCBvYmoKPDwgL0xl bmd0aCAxMzYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AV2UzW6bQBSF9zzF LNNF5DHM2ImEkKJEkbxIW9XtA2AYLKQaEMYLv32/c52mVRbf4nDnXu6587N63r3shn5xq+/z2OzT 4rp+aOd0Hi9zk9whHfshW+eu7ZvlXdm35lRP2Yrk/fW8pNNu6EZXlplzqx+knJf56u6e2vGQvujb t7lNcz8c3d2v57192V+m6Xc6pWFxPqsq16aOcm/19LU+Jbey1PtdS7xfrvdk/Vvx8zolR0dkrG8t NWObzlPdpLkejikrva/K19cqS0P7KRT9LePQvS/N11UpvI+hyso8RxaSmwfJgATvt4VkRIL3/lFy gwQWW+4WCchO0QckIC33EQmUiorWSCDaSh6QgLRogwRkUrRFArn2o4QEZK5ohwQWSxaYF8i1JOYE ciOJQeF9UFcFXgXScvFa3PzKYIFXQVSOCrwKStWSeBWMznLxWpjfrVcUr4UZZAhIzAkWHyQxJ6hs XWGuMIMUJIo54T1GkJgTSNkPmBNINRkwJ6isSeLD8J4BIjEnmJUqB8wJLFgUc8EMMl6imBMsVlcB c4LFlou5YAaDLcZgsA3l7yzGq6AN9RzwKmhDOxjwKvCr0VHAYLF2IeBVELXFeGXgyK0qU8+gDY0u 4lWwWPaZvYHUcKhnMByNnUNtEOVccR/+Hvw8fLoIkTEIEtVhZAyC/rX1kTEIWrKyjCHaKLgwRBlD NO+cNCS+BaU0xohvQSmNkV0yaElbEPEtqGz/xXc074w6Kzd4FwxK94ITXXLIy9yvlcvFMojqv9xC A6nJcJMMFmvIHH+DqNpgSw2atFK44cqrZ23BBkeCJjVzzrtBrhyxDwaLrTLmOE7KtSYxyKWW1Dnh BhuU4r//bYFeJ72iH69ec5lnHjx7au0t1BvXD+njNZ7GSQWMPzQQaM4KZW5kc3RyZWFtCmVuZG9i agoxMzYgMCBvYmoKNjgxCmVuZG9iagoxMzQgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9y IC9Gb250TmFtZSAvVEdZRlJSK0NhbWJyaWEgL0ZsYWdzIDQgL0ZvbnRCQm94IFstMTQ3NSAtMjQ2 NCAyODY3IDMxMTddCi9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgOTUwIC9EZXNjZW50IC0yMjIgL0Nh cEhlaWdodCA2NjcgL1N0ZW1WIDAgL1hIZWlnaHQKNDY3IC9BdmdXaWR0aCA2MTUgL01heFdpZHRo IDI5MTkgL0ZvbnRGaWxlMiAxMzcgMCBSID4+CmVuZG9iagoxMzcgMCBvYmoKPDwgL0xlbmd0aCAx MzggMCBSIC9MZW5ndGgxIDEwMDAwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AX16 CVxTV77/OffeJASSkIUkrIHsQEIgO0sWCCHsi4AbCIIogqKACoJL666t3ay2tfZ1sS5tnXbaamfp vBmnndrWbk6ttm8+bWfmdW+1i/b1zUwVLu93boJK/50/8XJzF85v+/7W45pVI0tQHNqEaIR6VnQP Ie6H2gen55YOjPdGr+kvEdLz+5Z0L45eowk4e/rgRvQau+Bs6FuxZix2PQ8h7BsY7Ik9p6vg/iMr usdi66MP4TprZfeKJdH3TZfI9b9/br0LnluHVi2J/T2G9RP3+qJ/jKZiP7HL6ycMXxvRCygP3Yf4 iEJSlI92ICQ8LMsGeTF8EOJ/3iv/10d/W5jo+1+UFsf97fOf7/eTL2dvx2/84Pq6RnU5+Tu4FMIK 0R/4O8EBtgghddsPrsnDqsvcSrGH3KmRF0Yn8UsIMROIz3yKxplNaC2vFo0xB+B7LRyfwPVNaJza D8calMETRu/zd6AR3io4itFaZjca587/QuP0v9AQcxKFePmojTmPVIKFSMXcheRgmSamGxXQO1E/ M4T66S9QHzWAGukfUJBZhkqpItRCaRGPcaAgZUVB/uOohVkLRxDeX42qmS7URzeiFnoIdVK/QkZm OdyLQwq+A2XQf0Nq+J5EH0Kz8GGUTKWjY3BeQT2OBmgMtDCqpL9GAQahNlqCnoPDQr2FPoXDgj9D e2gj2sOsRJvhOB473wXnejjuhWMLHPvgGIRjMRwbpg/QYNQ2CInAbkfhWosakBJ+65AVnmWgbJSO bMiENMgM1rWgNJSKMhEDVnWAlfVIgXKQD/lRAAlQNQqhCKpFQeRCBciIvICCLCQBa8qQByWgJJSI cpEBxSMeqgF6blSM7KgMlaMwqkKlSIycYHsVKkRFSI5SUAlKRvXAjwipUQWqRHXgP+SnCT670ftY ipvwPnyOSqb6qb3U83Qm3UA/Sl9ispmlzK95ibzZvB28M3w+P8LfzX9PkCqoE9wvOBMnjtsSdz5u SmgWbhcei8+Nvyn+yfiJhIqETQmvJvwg8oiWi46JpsQR8QrxTvEB8VHxc+IvJMmSbIlHslzysOSE 5BXJu5KLiZmJNYk7E9+Q0lK/dIf0sAzLqmQLZEOyraCbk4DGHbxW0J0V9AAei92uAOUN0G6XSa+T UAK9O4CdDg2lTIILCZ2B1Uq9G8u0sIpWRnn5qlyD2pSWWBbIKjCkCLt8t5RHegLpiQafNcukFMjv whOTfLp7ohB/oVIZc93mlHxnkb62Ocng0GzR2DKckRxTwB/J01rN2en8lQcPsp8yB672Mv+88iRw RYHmEfMVbwnYUQcGdwco4CsfawUSrExSqZVwB3uxE2sotRJraTrdYU+WJhpZmy5V6g+yswtbzPjg Q7g12ejKmziBHz1pj0+2GHSN9s2LauoyfYVCu1041Me0XD3S0GxLsFPp1HYEeBkHqst4swFTuYAG 5CR0ZS4bZXZrHRqgLMECZfSspx0eNzzR6/iCFKxyOgKgQBu24PFArjhebYInD7/YWT4we9dt4+8/ YNh/MK9xIGjakFndtnVPWeW+LQ/YpeaqGrq7IqhXiu3h7f1zN7UahDm/GN31ZD11ee9tFe0eNUNN XplcKQht7u6+KQBIXzt1iZGDTrLAWjI9RxvMI+eIe50yCdbrkMwlNzgdKkbek1yzqGLpwQV1+waa +yqzejpfHmXZiZ2Y/+v2A7xC9uLcpdZb2G9eOsVevD2/t4f9OCUFz8Oz38OhZxQI9A+xmzkPmkgD fyJ6oK/rAWhSAj5YQm8mpBm3iwLICMZs2ap4kDwf//oPl48219eUdtS//lhRdkPrtoE5npSRd/eF /XaRSldaQXdHgjqQuuXRy489wU7NrbNn6zqYdN/y3ceWvIF5YwzISiyRC/RtUVkZvVZGdAxiguAW wKAjQHudNIeMqIWYrEWJWbqcQjN76j2rQ5vY2SnR5ee/h712v1WnTupRTCyKmYY3m33HXuPQJEz+ kOIrZTf5/KmTf5TlhCrD7MEZZonxIQQ+cqN80D/lI4kg8EYuhItUOXk+O/vBmSgTibp82xlJlieb Dd9APtxqlU/+d0a4km0LV2SwY76qXCVg8kZMAEHO4vvB4nkIGQXmGw2sngkAjx8D+gCmSgmtZDwN 1WV3LJicQrdh/rMdT/b3pNUsbVxxuL1+/+DoKkWBF+8zGBQCnrIh24Tb8Zx3cegpZSr7TdsSy23s dy+eYi/cvnS5r63JKrHbRZm2coI9sAePAT0UAidJGnpaZq3spwrgOIAQMc0OpWTu4kuSjGa2w2uV TZ4XKnNsbHtMFfiI1axOoKyy7BJ8qNAqvVJcrFfJ4+12iS7Sgg+xHeUBQ7Jopl7sCSptqIJ9CC+a W6qTwqv6SDPRFXBIZQKHqRyHM63CMYWPcbTbpmkfJbSv/FsKZE2wDCWGNVVkTXB+czQeTCsa7w/e s0M7ryZDZvZjbrnwzsfX5MzTVfTNYxZH2eO4jfHHI0iqgAsOyh4vfCCscVajBEIumJHARu7RHMp/ Vrn4cY0p2NDUpbcmimzZ+LmsQFmQfQYPFId8OrbSqFOnfJVjshrdP6fpr5NDbcsLiswZadlGxm4X 6P0Rdsfkd63lmTy7nVap5E4Dbg9kK/4/mo/JwkhBFg3oBTyRmemJUW0/gfmW4hytJi1pSdLExmml H7Eak0UL4pVGX3s7u3IG4O0iRVaoCrQ+AoUY0TpEYAxwngExuVeP4aOSz7zNhWgh1vLFxKic5AuL rFIhX8auWc3eJeMJuXt7p9lYghfiLbiZZ+DMM/FwDAUSQ2QWvvk+7C6a0NLf+dkXnmDv/hmATDjp twifU1d4NPBJsqcGq50minghSRbEC2V6DB4JnGbg/8eM9H8Y7KliXlyc0mjDfXlGtWjj5DmXVSET 8GfyWURl+NoK/Xj53e9UlJKYaRclZZVWX32YPjq3yVzPrjj95s/wB/Gb5IqXIHJISbbg6WwYEqjc A5lBDtGbj6Vyp8Mjj0ZuCUXdMfby7fW7Jh87/j/rb5tixSeeXLG/bv6B3rbNs83Sxscw86u/49LH HmT//MEF9uQj1BvsW+wLu7HoxPs4c0vrA1C+U1y8LuQQAfkCIsRP/M+hInWEXmd2xzIlfBfgJ8Rp NjtbPW2USxc+q9r2XM+gf83w3gbbrKFQj2OyJJKjTpgZAE78pu/oMhvTUnLL8JzVkQyGSMtu4TlA Wi3Uasio1jAgnVdN4qWNyscmCrJiVHYp9RPR6VJ9WoHXbk3yNhkLGnZUFtVUt5VU/jgVVcYrk1U3 6kLoNAeL9Ik5hkBDWOXondcvwp04PK0b9gL7IDX2b3TzL9BNPlShkLl/Vjl8UlhkRkOADedjG62n ScYDs9lADHwsQWWysddi13cXvrzvPv9cd5u5sLiAvWgKa+dlOy12+8rhuQMLvGXbhtqoWeyTVWVa Apkbs8qxE7e84IlL6Vh0uKouO87uXhd8rK4qI4F6fPKXKZGN7QtvChH/Hpq6RN8D+ixASKGhQJmE C7MNmCFFoSqWfEgtBriP1ohgW9n5pPDA7JGNrtHxkV3l/W9srduzokcd6awtW+pzDizbdHtjaORQ 94NvYe+8Xvu6kdreNl/x4Jb6oSNt0nT2+3mLzAXd5ZWLWl2lK2/v7N/TnuPGcuAFGGI2gPYAxwot ZD0asv+0Chm3LFqshpjiRSpLgdd7MwcpL1SYioSb8v0ui6IH0v3hOYtdqgkUA5NAqjYEfAySF/U3 EWnbwFfeBwqAHZxEKhsAJ8gaK/yUEoqLNZwxbkxrS5IUJn3fvsXjTw074hUGOz4MGSynprcusqwy lWSEO4stUvyXFY21xa7qXM/6xzZTdzd4s9RgEZKzJn3d26q19sV3r6eGo6ki0RDmMpkK+HkX+NEC P4Q6FLwKDBXYtVQBEZCEGfy+rQCq3gs4ky8S0t4QPpzjsOvZ7q3s02nZBVA92eOSrUYoeifepj2K 3GyN2OeF3Bpval1w9Ummvb3eHE9ERqqpHwVdQM8IbS1ZmuYiGFdoK6DGVlxLUrQA6+mn2BceZf8q 12j0WvxkwC6XvoZDj2Pe1xZnCb5VY9CaU9l9dzJzrh5iAuE59hSoakQFFn2Xf+ICs/LqHurq7hK/ h3CRYmmru/oaoS8HC+8H+hA5hJxgWiWfCJ2Go7mQxFNKcN3qtBt/zH7tcLnALTrT9KdfztZacvH6 nEBpgL0gSoeQ4i2wpYspP4U7mqC6tydEMqpC7Fa8oLLdZMiBvJfoblvOmtjfF0Vyk+F5vNoSKSZR rAlw/wzEdhN0jsjIFVw2SMcGY9QL+aQrAneAFgAgSIogOuoDXFCjDiXOvX9O3ZoA1mJt9pyqhoXJ W7s2bQr1jPmo+CSzlf1W9MbrtkhBeDBwJzO/pmR55O6HxWV9Y4XNzVsc+WnBLVvZwzV+V6ZKZMen qb7+olBKqNcBXBUAVz/y7uO6XITVMQ6gHtHrTGaBGTAJFoPKGFjiXJVr4JS4g4l09JQsv7+l58Vt NVurIhW0WG12fl8i0QYbCsY2DK8qamo00pm4OqRf8f5Dhz5anabzS5lgV51bIxe64q+erW/3ORSn Tr3yqr6mygZ26gc+mkE7HC65/oOTnsQHCLY0cBOLD3TNzTJHyB4ZCCYXd1VWrC0tcjbMn+v8w+mh 17c176aPnC2r1bT9dvvs2xcXesKhQn+O4uo3+z7boABZgQZjAVl1XPa/LhnkE4HeayauOU1FTQSH /gugAvpn3DQTE5CfZPF87RMlBjv6fYePr3l5fWigSKItLM/ftGPlkLW4sDhNcoOY6xrKs1MSXPGH mfLy7B8vHv5sSJnMPtvQWWpNeuuFF04naosLAnbgrA+k3wfSpxD5jTcwArlOSwIhUQOUbaQjpDeV Lt9Uf+ad5a9sXnLH7Hx68lb3eHfz1rLl/NzW8NL1CcfK6yz/vHzPpxtKB5/YJR892O6vwLMHbqk+ cj/xh0aA4he8/4DOHGH9tVgHHRigj4EW3emAXpxkBdKWO6me78QpOXnsUqtJGT9uSlHLxIzQP7K9 rdHbo3DatHmmNPF39NzJQ+VhvRIcj2vBqA4nxLlUp23Fri5zwq9K7HJT6cK6ftIDB9ky+mOQ0wFT jxbgwCwgHS8f4jtoWoNLcKwT5mKky+MlDhL9TYCp1mLOHLG8xVdwDTvnH1AaWbCO/vh5Yabhtedb fHUZ5eFLy3YUDby5a8lja8ta6/M9pbOqaouW3NpUVYkXTdb0djmr8pSOOYULF6c4nXfubdsclpir iu+ZRc8VJGQuDxx6VllcaDRJQ4M1nXubk4s6IsGlZkWNo2ihP/euBXNubsmRsW9v3GUOz7fPG/Xe NPGNabanbXZBmy/dnZsCei6FuKMDrIHrx7yKKzZh0gFVONfwEh1Ho//1e5yv4RVMQ/t8p3dOWU5S ormEHTXr1OK0xsrs0laLICnHwq4h1uDweNkHPtYYzEp11y9vZnfODeqhaRHJs8rDmL/99kh6VZ2F 3RwuNqdAIIq2xxXTLgioIxb4CuaHNOAOsoHeTUc5g/DPeTxhFt/8216zVi1mku15X/mleU52jBf+ 05+ufANUQhH8XGlDvjrOLZx0zynXiyHiU4jHVuARblV1dFVFtLvhhOaWxiO/OV585yZdoCxXxU/K 9V7wc0v++bbHR4zzki1FXbXUFw1hc3KCWwiaDIImfaBJ0Ci4gRf6dPh3LW3gREzqY25oQwIpVDeA BK52uKbpqFYHsrTKFJ/Xli+MM+bip2193s9xlmNWAbspNSVBl7dWl5GVVkgEXO0wywQx9VJ5AqHF afGlKJUaHR8GO6Wu99ldoSBgnZYlJWY4Ao/kpYsuccLbxenmcg99XcMc7/hD4J3r8WJscnqIsfRT cld+fiHQAtiKv5B+E3WBFtTETVXRWP1TBDE/g6pr96Kt9Q2GGJT46quC2sU3Jdd2dBeWd5dnxitM eexagjihIk1nM2VXzDJcvxev1OpsGTlVtSa+OMloZMdM2mQRgcYFP61jfH6jdMHCuiqzeda6pezO uuIsNfTXMTjOHgyZ0qVZdfUudu/MJ/OHwrmqBGOkzsreUuTTKRUkkMxAV1R+Jh/khyo3B8c86Jpc N3gVBzBBVDex9o7Jj7pQnCLNWGA2R1pNHIynUX3BnyCpae9weWaX5Srjkkz50xxHVlXnZMgy62oK 2N1Ru8zk6hBTW6pPcdUPtLA7KwKgMYJ+ksfegwgnhowKvdF0PiHjvZnBi0p6+4PVpze99+HK19ld W9eVd5aklg1VjW+W/u+lI58O/vjV0U+H8ZUzfy1buadx75/a3yFrV7PNTALoIJublADGo43QdUCB 3AQZhBikMhpeIDlbykECDwnVlgK2z5CXHMeI1Oa8i35xYqCqvjL7yLOL/7itZsyR7G8Jj6/7rHBW k1ZzrqzUmEwqKWVOpJhuq/Jnp8qFbuEhJlhkkv7z2yMfDafghV19ZVmvncK79A3VMMKCLAb8ZYHs Gq7ajca5G3KZSu1VcxmHNLI35FYmi+0rsKiFno5VpUeeXX1mZ+UqXyQsVOcZ2E+Sixvcm28ZHMwt KSpJlbDNMGo1BkN4vr/a9o+LRz8bzsjyS6/eUVIB40H6bEdvZebbf4C0qivOh7QaRQ2dBxyZOa8h KSSW3Di3+Sls8KDE27miojh/ONmTb6gMpaicTnbFDRBX0eX1ufzPPfbcpkgB+2h7RRapQG+Aqiue UO0EDMQDVcICV8pwye1aLwNDGSfJ6NH+64bOh5rqUvnqvE0LTU1LegeDnkU7m1ofql2UtqzDUOHJ ym5d1r4yOP/x4dD6DuojX0V6bZnN57JYaxaFGwfCmpSkswtaEvW+PGepO89Utai8ebxUrABujFOX qD8xJwgeFQGYayq1Si0xQ7SyIkCB5G90BPRJCXfgcvYPUmuhNTuiy6u8Obz5pn30rXHZwYXt/1zC lnevLkvXZnoqAvcfoqCcxqga6ikj/XtSS0D3xC0ZnWFBdOOuY3UV0IBEzrU31ThDbggVmyJzjHyJ Qm/GGZAAPJ/5+Ykt99W1jxaLjQH69yw9si6Qq6mtseO1RdGh3eTs+nCskmprrbpzC17XGjRKgQfF 1D+YeOAhExiK9TM/Ke1j/cwvbCaFWPLLN5OkeT48as7NzWCfHmUvp2vNIII9ISkrLa3EzPLxZwWB tFwr9FFx2srSyTTqYn1RepwdKGVMXeVbgVK0k4FibEYncyNRrpXRsFd2X1Jngoi7i3NEogcxvv39 ZyTyPA/uSE9P06awf99JXZyUUp9XlWSQgGc2E/oUzZ+4gr8yVWhySXMhSMzwl05mAXXIpfSrQN0L ckICnO7XIP0ponmFZMR8fMMeBuVVxJjkGh4qbosyVWfAlabGoj9/am8wsytbJIo9B2QKYzZ7XOv2 5r39rtVlVeFdjUoVVXYkzZmm1gigvymtZNm3QpFECAYupSnl9dMqozpND42OyFDkxRQ2+DzpkBlF DrUNIIZRElvDWQSm6zzi/dfQ7o31X9Gu80aFUQIqztu3cY63Yr7IoNPkOyss7JdpWpMZ35dvkosl x0/LFPnFUas1bzjQIH4lJ0tduGY+dbm6WAMumKDUpqYVm9kE/N/Z5RmWaesRbmaB3lpAb0lwIdO6 sVYHo1a9TAs7O+CAXrplgqUM7GVHsSt5LvWPyb9igctlMqRgHfs3O11saK3EUsfEq1J9Hdc9J7Nf 43L0JUR3ZOTCLDe1dZmxW1LQv8DjtCUJvoyEI2tWV/gL6mE3qAai4jGgvAp2TWnYIeSqLAXZ7Fp1 +vRpeueFC5PdX8KWN0Yr4JcXVobdcSN57n39S3iA0QB+kfJRC8h9rHVrKR9bgN/GLz5Aqul++hSN eY8DN2nEu2EkSHokMptSJqm1M64wPpOQYGidVeQ1y1j5ta/4E/qUoS4juGRZtSeyfn75rBkX+ByJ 6pX0CWo/1DAS2Lkis0hup4oMq11m7Ywr7ExI0Le0FOXo5TL87fXvvPvIqov76jzumgXBKI3rVyBj gG2mnwIKICOZEdBPTdoepM7z7vvXfwrIQBu14Tfpo1TTtA7ooxPP0XX4zW3k2XNsPfUJ7wEyLcZk EimTymGMpNTBqIX7wB6WWkU+TuqTY/815nGP/eVYxOO3FGj0MrlGn55rdJZ0svW9Z3EDyJaOZ51f 1iySZFsbF+w/OPUR+/Li1vwcZTKhZAFKbVFKCmhT5DIpBWnW7SCT9ui0nTKbyEdv+beEeA/0nmWP sx+zn7JPzyCES2KEMPqUbaYeBW0QtGgBqHBQj7IhfJL9HkMGFFQ0/7gwyk8zVO+x9yDeAjrwV/Ce BN47yTY38w82A9d76N/h3qhuMYz9cG/1MmhLWD3+K7HtHvoUdZR7SqjBcy15p7W0P5VSBpelwIt5 +Bw54N3NkNW+gbldrLIhc08ysCN64Oaechm3VwcTX+tfzpWNHO7+4L3PWN/4zeMjvuV1FR1FyVLc itt+i0VPt7K/ZI+xD7H3UG+yv2P/DKPJvM9xxobmA8ATRscB2meADuy1wHD7eslqIs2vGTv5Suo3 Ym2gs34yY3ChQ52eljU614rPe/mYV1xiVCZQ1dU8mS4QoS3ZxlBxPVZ3HYNVN8Oqr8Gq2eBfxPG5 7T3oI7zTU9DYpjTxahqgQ520+wxK6WzZxGuWu3escRZ6kwt6av+zbHz8XOvvTirz6hYMn5z/iCg9 L5/9sKD/w3s2har6O/JrV4fefqHIeegB9/y5i5eOvXYvUL4L9PZ6bN4JGzDchId0REoNHSvUYhGS RHAL1LbgWZysD695vXP4WFt4/SL/8Dz3krfvmfNqy5h+dc+W7c8ca9v5fNvocOdoOlN80uuJbG2f vbnLJkxwt47Urnmuz5x1vq/zjt13H5gXN+/WOYNjvf1gv3roo7S8BaBXHeggAPsJEA6dsZ1PgT5W TsJN6Lj1mGJgcj55nqq+U1ns0ErqRJe4zYNl7Ld4J5+JZ8e5ye/hWnr1xCGZxX7mcHSrAE/92PlV yeRekPtekPtdwJYJIW+04AEByWQBrEi2WGG/VaCVXVeIXnfvuGa8a/uuqnWzwosKmyizTiMXNSRO vuha51/728VD5/c85T3f2/XIw8t2B2TyfOruBHXWl2y1StV9YnTHC/Afhii0BSqSeNB1CtnVxEod n4KS+JrK9TpuWG/wYpIEyC5zdLxDFE7feeDbB7PiWw8tHH64afHZ+z/4+9AZLL2XnbK3N5lE/Hj+ pi21vcG0dTybfdsUeobxFfacGNvy6iosxcLj2PPF9rjJ5arcrASRojD0x9Ou9vVV+44QNO+b+pGh YP4o4WKbG7shAcF/gFBoYQP+d3uoNLYqx65VKeYk0W0845XzdmYkMTHdFsakKx8EDU6BNBkgDXTB MA3ngi9XTZFAb451F9wMhWwExUYhRMfR4p8UCtwwh6KTqeE1Q+/esf21QV93DfVfw2dvvutUz8Dk M+mBnqqWYW/Zqpqbtidoynqrm0f8obHGmiXBNOqs2PrE2pHj3fN/sWbuphaduOPjpY8umHX/8pUP Y35JX11e2cbmto2+Wya+LxtuLijf1ta1u9rWQLC2GDi/yNkBqgCjmxj72sCTTHLksiSKESiII077 H1cV4KLb3tqojFnBN/rs6DsfPsp++NJjpopQMEUoifMOt9T2lWnWme0b/uflqA3aDo5Xsn9jL/3I 7n1DTt0jTjGr4lJz8255qYcY4Z7DwM0G7KK/pztBoxDlFDDxBSsoN9CjE7fSo9S53bvZ7t27ia02 oB309wz5n0DwFlYKMXlpUkN9TNG34Y33sufYc/f+5D2vW4jh1Q3Ux5MaenTHvTgP593Lbr0NkR8y fcbcNz6xf2vl/Ehzs6W8e8WiVf3d/wdW1fxKCmVuZHN0cmVhbQplbmRvYmoKMTM4IDAgb2JqCjcz ODQKZW5kb2JqCjYyIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFz ZUZvbnQgL1lIUFBTVStDb25zb2xhcy1Cb2xkIC9Gb250RGVzY3JpcHRvcgoxMzkgMCBSIC9Ub1Vu aWNvZGUgMTQwIDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciA3MSAvV2lkdGhzIFsgNTUwIDU1 MCA1NTAKNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUw IDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwCjU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAg NTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgXSA+PgplbmRvYmoKMTQwIDAgb2Jq Cjw8IC9MZW5ndGggMTQxIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdk81u ozAURvc8hZftosIB8lMJIVWtKmXRmVEz8wCATYTUACJkkbef8920HWkWZ3F8fY2/K5M+71/2Q7+4 9Nc8toe4uK4fwhzP42Vuo2visR+SVeZC3y6fZmvtqZ6SlObD9bzE037oRleWiXPpOy3nZb66u6cw NvFeaz/nEOd+OLq7P88HWzlcpukjnuKwOJ9UlQux47i3evpRn6JLrfVhH6j3y/WBrn87fl+n6LgR HavbldoxxPNUt3Guh2NMSu+r8vW1SuIQ/ivlu1tH031uzVZVKbzP2yopswwF7zMvzVFAM2mBgveb RrpGAV1LNyh4v32UblHg5JV0hwJaSx9RYPNGWqPAUba5QQG1W7UosNk+FFDgqKjeiAKXtM1dVeYM gKruzMcNjuqkhBOoenPCCU4upIQT6FZKOMFmqxIuvwXcqUo44f1a08gJJ9AgJZyg1zYTjuDo1m5F uPwWULNi9gbVXEo4Qa+GQ0oDtV4FBFQfKsgqvC9ULcgrqCoCawbT0DUKsgpUkyzIKui1KlkLy8vN qZJVMFjNqiCroJe3wdv6ekR6Zvodvp9ve5lnXq79M/ao9Vj7IX7/VtM46QDjLzq/6B4KZW5kc3Ry ZWFtCmVuZG9iagoxNDEgMCBvYmoKNDU1CmVuZG9iagoxMzkgMCBvYmoKPDwgL1R5cGUgL0ZvbnRE ZXNjcmlwdG9yIC9Gb250TmFtZSAvWUhQUFNVK0NvbnNvbGFzLUJvbGQgL0ZsYWdzIDUgL0ZvbnRC Qm94ClstNDc2IC0yOTYgNzAwIDk2OV0gL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA3NDMgL0Rlc2Nl bnQgLTI1NyAvQ2FwSGVpZ2h0IDYzOAovU3RlbVYgMCAvTGVhZGluZyAxNzEgL1hIZWlnaHQgNDk2 IC9BdmdXaWR0aCA1NTAgL01heFdpZHRoIDU1MCAvRm9udEZpbGUyCjE0MiAwIFIgPj4KZW5kb2Jq CjE0MiAwIG9iago8PCAvTGVuZ3RoIDE0MyAwIFIgL0xlbmd0aDEgNDUyMCAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PgpzdHJlYW0KeAF1VwtQVFeaPuc+uhERaaBf0A+6m+5L0zTQ3XQ39INHN48WpGlE EBB5CCI4ICCCGkVkkWhGsxPXmJioia9xNzM1ScVxnCkzw5iYjMnMWlsuY02lMplUNpPJuJVNosNa lNLX/U93E8xM7a36773nnP/+/3/+x3f+u3PH2BYUhw4gGqHuwa5hFLnwAjx6tw7s6Y2OqSsIJf62 b0tXT3SMFuHp6IOJ6BgXwDOzb3Dn7ti4GZ5nB4a6Y+tUJ4zXDXbtjslHf4RxxvauwS3whEt0AG5Z //96znOwnjO8Y8uSfSB/9XEPTJLrceyKjp64Y3jPwm4URONIiCiUhPIQmSMXDW/kna3/8ps3Z/I6 Vnv+F62Iiyy99Vl6Fnm5FbrTu2gJn2NfFl4H3jiQEL3gO/Ze+B5uZ2Cdr2df/lZqjAFlMb0oCISA poA6gAaBjgCtBeoFImvkncwdAzoRe7pjcwF4XgE6DUTmngGSAsUBaWLvc0wvngQC2dgCRNY+A7ID jQLtBSLyiQyik8gkzxtgaHT/CCUgASLx0iAOGWBWBTNCJEMZKA2JEYNWoVRYkcO6Fjy4GqUgCXwh RQqkRPFIhFaiZPANixLBPytQJtKBb/UoHaljzqhH9egYeg19jY14C76A/5NqpvZTr1MfUJ/QSrqM HqfP0H9mEhk7s5bZwRxjZpkvWC3rZ5vYfnaSfZf9SLBKsFFwVHBP6BaGhCRjGIgoYuRsOmgSgp2Q fVikEUUoNZHSCXW0zeqwF+RSOp3dZlVRNJnV5lL2gmKKjBn5op0uCjdRrdya/jLB9xP2rvEpS7r8 Rc4dP+y3LohUnESSpRKJVFkSCacSsekPP2fTH21jRI++pn7lbPMbZjDly1UXGmUvWkJ94YsSgzIp SWkAZoVIpOBIdk3FLEwGP2QjZBNprBIxmCFU0eJURpcSMU5ksxZTNJC9wKDTiabwpU8+keYHLJYW P8fPh+/I7A3uEyc8DXbpu+4Wj3py+iU2/fQrlk1Bjygur6a35P0P6Kt6T7aUv6S0+cJFKnvA2NjJ HyKx7QD9QvDQSggs+EYnAguAaBFf/uAB/uUDqih8k00P/41a9fBzBJEbfHyX/pBJhPhZ4Asukf7W X7aII7UCod3hIM4Ti2AtkRKnSsDJTjpOkFG5vtsdHA8ZvRNv7Z+RWIJFrW+sW/PrrSPn+63zJ4qb HPJQhW27b0ZblC3NXbezMvBUs9XLleTIjPobSoOpaaopXI3flmU71cVl1RVgy5HHXzFKdgYyLRO2 EomdgQPjhVEDWOI7sEckAQuKKUZZ9+z1kaFfb5iPdx7f2nq0w/oYycxl2cUjJcrGHFeHP5NKPPrv h8o0CraVv/J+VVNg5lcH1o+v1fU08eUrE/ObJ8n+18L+PwadEsj17+7fKpGCbpyqgtRxOEUGA9k9 HS/IKA+2OIi6uqPXRwy1qvnwkNTsyy4eBrUmd7s/8wWu1CwPzMyOHb11qCw+Dj/7cC+eX78LFG/A v4wqplDv47sMAr9nICPZq0CoiSkSPxEC8LrQEd00g2g63GOs6S+tfm0j19a5OXfnLw6Ul+97c3Dg 0rBrAWc412S3ja+kquUhnb+3IlOa9s7K5EShb2p2Yt/vjtX5d18q9bS4FHuHYc+klNLZk1CrCtAd 3ZhYrBGTdNHYNdFqkUgxk56zp8RU7VDjH/AjD/gPMVcyer7Ht8v26HPmamKK1FrrvDgbbqb+bfbl gVPduaIEfgIqYC3fxuiZBORFIdQJ8iWR/NdpDZxAIIZNSqWkFJYL02kwEI2xhw3crhFjkmSkPHIp DnIyZWkYjcGMQur+3olWe6tUJEtSm9Lv1U+320qnrk/ufXPEkZzp0FtsyUqDWG/xDpxoNjdocWdY s2ugosOTJjd79X9Q6sVCY0ej2Z8jid7pSl1tVuM/NZvFiSJjWlKGPAmvoPTlXcVV+zc5uMoul87j LEhTNFu1bodVpu+va5zZmLdi5eVFm7swLbtQla6Xr6KY1ExdJp1e36Gy+jIbO1S2cqjGIwAJJLuk pBoLIslLKlJYDEBFKoq6uw/SdX4+QV1a3VQQ3BnkqBf+tacpPMHO8Bd/oXdniW2bpuvDTSRTj4Gs ++zrUB3KpepYRjYMcRNBBO0a6lOZyaXVuk0ymcmt1bpMMv4+/yklx/rFV7GPTdS4THK5yaXRuHLk 8hwXv3J28Tezs2DrCciKErA1HmzFEeDAGoxpxD8zP4+7sYXvwbN4kWfYmcX38Ou8JfwHMCNm1Qyc AGjZBjy3rJG5OfuoCBQArxs0mCAzABfBG7Fi1j3xZpMSx0iid8CbZiZBmqr2GG4zCbLUtFJu7meM JMdalNnYIpDl2dyZQ9uoK4YiQ8r6LeHB5Td64XlzqTG5pY7cT50MQ2HHIgH1JvlOJCKangjEnEDt D7YWPhEIeoGUsywWBgoFoG5VICcFzrsYRi1HQQhwvgSRAFCq8gPXdo1c3uermLo2tuPyvjJ+187S Vlf6gSFva6GCYnbf/Oegb/q96T2/OVrrP3jj6VdetW7Y6Xv1nGXDOFgMvRcjAk2QOzgGAiQqMZOF tJxarclXO0YrHn68Ql5S215Yu6ueo6nBolCBrKU3PAFu4IrNMnvfma0g7TTg3G2QBii/hKx2gqOR 45LLpZeKXkzgIFqnKpq+XTt5bv3wlVD7Ww2dHanOnvqakWp94dCloc7niza8VFOzMdneEWzevSYD mzbsrdWJU//I6bwWqUGnl4rtgY7S4u0N+akJNxVSR740U6uXyIsCbSQabmIN64XuAukFgsiRQ5BH 5CQ5LIqdMLd9T3t6jnWY+a+x6CE+wo+F2j078uJXJ2c3zbThb2YxU8a/NctrN7SkrgKZz4DMj+iF iL9iIqDUdEtHmghPFJd4odjmBBm+2o3O4FiQoxfC2xoatzRR04txEdS2tU/XUz8iFoLXmXUgDVpD jQZrUqTOFA11g/+CH8RJcyXFd7AAPr5+7TIVINzAxbQBdzLhpjkhraFt5JPojb7F3xvQaPr4b577 6xqRsffaYF6K92PsGx7l3wYp75x5Ftv5W8fOUdDZYui3EBMAWeQEp2koQU1KCilE+V/vAgRP8C9i 458/xcn8eTyCm/gfUQgv8JdxkI8P88RuQF9idxp4lpwkBs6ugpoCfF3axFf20e+/1i93qxPUWt3q 7IDXmrK8qaGDN2f8LPsfFEtTGUV1ed9uEqM5/ix1H4/BqYGkkgg2M0t9VQTO5zx9tTmiNGWaSJLt 5SxBh6L88O8Ov00lcx6j0qhR68wZaneuwlzb7dh08akqROHJx3epLxgKaomUKAHEJ46FlL8bUzaD L1+hyPcZDGUWhcJSZvi7MUMpLD790qTeZ1GE64AdZgi7z6CHz0ENho4H9jECWv9BJ2XODthV0E5l Z1UWqFQFlXhEDb1VVpVdrbZXZRkDdmhuMUDhKF3CXoYelPSfkLBwYFmoRH4Om/lRYcnsQy/gKY4D rtQYFwFnIByHTfwdKoEfnWVvzC68Daj+GX2cngbUJR0twjqIN6EP3tNgAd7zLtzp4/g+n4jvA4cd sMfCWsByNTIB9xPeIscJm5oqjZ3mbIHBDgdvpE2yVB56Z2Lg6sHqqqff3Tdwdbp68SGF/1s3Gizs rDJSSRQvz9hZW9hVlUUdP8e/0bb2Av9m5Hmev5qqS8abuzuKxi/vF+mS+LNd7a6xn4JiNApnEc/q yFlhg32xnB7aTPFJXMv/KYRfvYXVH9KBszc/enT1Q8K9F7gXwO4Mwo2LAWui2M/FGkvYh1CoEU9h +4b+omRZbqW59qB7qvHOvs7TQ97s0FjNLMVdgcX93evNer9F6S+8VNdh6XyuPXjowIGqn31KdBx5 /CW9CDoKl/3CRQAu2kVEfgjIK0E3oT12/kLbBSC3GDjxXy9pa6orFSVnGht2B/WG4J6GYzPBrd60 vsHgyXrzunXrzQMXhgoHN5f0ruHwD7pODbpoVsj+PmG1wh60mCot6dfUBVVcqEElv7U6NVGQ2/hU za7jXLylFn6cCfZ+SX8FPTlJnljMorYB+Bp0kXMb/gjgd+Wr5tO/36euDJQri56vfeHMv1x4jKj7 4fvtPVePNODz/ReGXYxgBXsnUTTau20r9fO/8A8yW06Cc6PdJOyeQ060BrSovtthLcF7tMI4EoEl lBcmAuu3zRadQH5BApM/7t7+2qibK2+xmus8OufgD4d6zw4WaV2h/8ksyVX0drb3aj31LFdhU413 5QTdWoOvmbqSXtb4vfKWw225eU1P1fj7m8qVacXBTm/VRLvDFBryF/fUl/lSzY5Srqy8stLgseX8 TZzvqjCtDSUb3MZsf6GVdDkAp5BZFkBBW8RbTCxyTmfsnIj9yumXz1knpBPNF3QcPPfzzS9eHjvT lRdH2Q9XdJweKa6afKOv9yeTVXx6ftCpGu5O93qdYqm9ifro5c/P93kkt41147VyeUZO50sDm8/t KHEd+cufMlz11m1b45Olq1oOb8on8YNenb7INMO/LmIxlgIWx4XbqfOn+ST8jZQqpJyv8P18JNI3 Il19hHMFxWGMgS3cfgp/zYuY5vAH4fdfwSfxKdKAE7nJQOQSwJ82agmEQg2NJv/Q9tGhga5Rs29o AET+H8KQLacKZW5kc3RyZWFtCmVuZG9iagoxNDMgMCBvYmoKMzQ2NwplbmRvYmoKMTEgMCBvYmoK PDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvUUtEUVhHK0NhbWJy aWEgL0ZvbnREZXNjcmlwdG9yCjE0NCAwIFIgL1RvVW5pY29kZSAxNDUgMCBSIC9GaXJzdENoYXIg MzMgL0xhc3RDaGFyIDc5IC9XaWR0aHMgWyAzMjQgNTU4IDMzOAo0ODggNDE0IDIyMCA1NzUgNDk0 IDI3OCA1OTMgNDg4IDQzMCA1MjQgNTM3IDUzMSA0NDEgNjIzIDIwNSA1NjggMjcxIDUwNCAyMDUK NTU1IDMzMiA2NjIgMzAzIDU1MiAyNjQgODMyIDgxNSA2MDQgNDgzIDU1NiAzMDcgNTA0IDU1NCA1 NTQgNTU0IDU1NCA2ODEgNzc0CjU2MyA2MTEgNjQ4IDUzOCA1MzcgNTU0IF0gPj4KZW5kb2JqCjE0 NSAwIG9iago8PCAvTGVuZ3RoIDE0NiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFt CngBXZPLattAGIX3eopZpovgsWZkJyAEISXgRS/U7QPoMjKCWhKyvPDb9zu/0xS6+BZH//XMaDav h8+HcVjd5vsytce0un4YuyVdpuvSJtek0zBm29x1Q7u+K/vWnus521B8vF3WdD6M/eTKMnNu84OS y7rc3MNLNzXpk759W7q0DOPJPfx6PdqX43Wef6dzGlfns6pyXepp96Wev9bn5DZW+njoiA/r7ZGq fxk/b3NybETF9r5SO3XpMtdtWurxlLLS+6p8e6uyNHb/heL+XtH076n5tiqF9/G5yso8R4L3uyQZ kOD9PkpGJBAtJAskEM0ld0jw3lurPRLobMlPSKB2r+RnJCAtuUaC94UNapBAdKvkFgkMCpIdEog2 kgkJDNpJ9kgg2iMDZyGQqg14FSSrc8Cr8J4OSLwK1vCSeBXUtpJ4FayhQQGvglqL4jWY350sBLwK op0kXgVzLYrXYH531gqvwfzudVYBr8J7cpB4FaxhrfAa7n5N4jWY30KtIl4FSz5J4lUg5SjiVbCG Oke8CqK6BVYzmKvD4d4MpNXilRMmmRMjileBtLl4jeY36iT5mww667qZZjBXtxDxKpDWCq/R/Bay H/EquAVbEq/0VLLOOeJVMJfO/OJ//2X97XqVH6+ovS4LD8ierr0tvZlhTB+ve55mNTD+AM+9BpMK ZW5kc3RyZWFtCmVuZG9iagoxNDYgMCBvYmoKNTExCmVuZG9iagoxNDQgMCBvYmoKPDwgL1R5cGUg L0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvUUtEUVhHK0NhbWJyaWEgL0ZsYWdzIDQgL0ZvbnRC Qm94IFstMTQ3NSAtMjQ2NCAyODY3IDMxMTddCi9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgOTUwIC9E ZXNjZW50IC0yMjIgL0NhcEhlaWdodCA2NjcgL1N0ZW1WIDAgL1hIZWlnaHQKNDY3IC9BdmdXaWR0 aCA2MTUgL01heFdpZHRoIDI5MTkgL0ZvbnRGaWxlMiAxNDcgMCBSID4+CmVuZG9iagoxNDcgMCBv YmoKPDwgL0xlbmd0aCAxNDggMCBSIC9MZW5ndGgxIDY0NDAgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCngBdVgHfFPXuT/n3ivJki1ZsjayZO1ryxrWto0k27IsbzAeDBtsvMAONphtk4Eh CZDQNAPSJKRNSoAMmjarI8lryGjaktnsX1+SjuQHCQkZ8H7pSwP25X3nSqw0T7Z07rlX+ub/G+fb sG7jMMpB04hGaHC8fwLxL0oHy6aVY1MrsvtvENIUjAz3D2X2aAbWyAjcyOxxCFb7yPiGyex+MazP ja0ZzD6nboH9wHj/ZJY++hD25tX948OZ7+tzyP7/f+4mv3dPrBvO/h4D/fw9scyP0bnsK7u9uGC4 LEPPIQ+6AwkRheTIh3YgJD6oKAZ9MfwhJPxkRcG/P/p7X37sX8hAxEDoqU/ujJP1zZvwK9+EvmjS nNZ9DVsxUMi84HeifVwFQtrub0KzBzWneUrZh/xSJkihI/gPCDEzSMgcQ1PMNNosaEaTzD64bkZT 1J3w3oCM5Fq4A20UrEMbmd3w7AhKCnyom3kHaZhW1EufQG30TjTKTKBR+lM0Qo2h+fQ3qIqqQB1M AFY3qhI+CNeb4V0F31uPGun5qIOeQL3Ub5CDWYUamRykFAaQkf470sK1Ch9EOqoQHYZ1nHoQjTGr 0TZ4P55dt8O6F7TI2AehPLDdCOwtYL0cVAirGhXBUyHSIh2SoQJkRnokQkakBAuVICmag2yIRSrk QgKkQVZUjAwoF6zvQCawohO5USn4xAuU7YgBT+QjBZIA9cyrDbWh3eh9LMdteC9+G89SNqqdup/6 hg7SQ/TD9DEml1nI7GLeFUgEjYIjgs+E9cIx4ReiatFq0RHRdznVOeM5j+QcE9vEk+Jnxf8t/kL8 b4lQUikZltwnOZkrBiYMOgIfOwSdIJkbEALoxeFQgoom6HDIabPKKJEtnMDBgIlSq2Ajo41Yq7aF scKiIG8qKtS47FqnIb8mYS6z68XLYzfUpgcThfn2mNvsVIsKbsEzs0K6f6Ycf6rROFxhVu8LVtia 21X2gGm7yWsMpkuciXjaY3GzxYXC1fv3c8eYfWdXMN+eeRikosC2iPlMMAx2toLhwwkK5PJhi0iG 1SqNVg13cBQHsYnSqrGFpgsDfp0838F5rXPk8Squq7yDxfvvwZ06R8gz8wS+74hfoiu1W+f7tw00 tRTFysV+v3hihOk4e2heuzfXTxVS1yPwwxRwvULQBZ50oQhCQcJXEfJSbNgSMAFnGRapM6uNDkTC 8MRmFYr0WBMMJMCAXlyKpxIuqUTrhCf3Pt9bO9a160dT799tv3O/Z/5YlfOqosbua2+tqd+7/W6/ nG1oovvrqmxqqT91/eii6U67uOQXm3Y93Eqd3vOjup6IlqFmz8yuFiW39fdfkwC8bT53iikAm5jB WwobzxvcU8AzjwYVMmyzIkWowB4MaJiCQV3TQN3K/Utb9o61j9SbB3v/uInjZnZi4W979gnKuZOL Vrpv4L78w4vcyZt8Kwa5j/V6vBh3vYeTjyoR2B/yGPMOWMIASCV2oC/aAXhSIiF4wsYS1kw4RAFk RJPeYo0ENPfh3z5z+v721qbqZa0vP1BRPK/zurGFEf3Gd/em4v48jbW6ju5PV1lB6477Tj/wEHdu UYu/2LqMKYyt2n14+BUsmGRAV+IJF/D3ZnRlbBYFsTGoCYqXAgYDCToapHlkZDzEmAfyzdaScpZ7 8T13wJLf2yuz+nzv4ag/7rZqVYPKmYGsawRd3Fv+poApd/Ybfayam47F58w+qyhJ1qe4/Ze5JSuH GORwZeSgvy+HiiDwUinEA5oST8zPffB6Roh8q8/7uswcKeZSl7BPdboLZv9pTNVz3ak6IzcZa3Cp AZOXYgIYEitQRcB9DkKO73OyqGW0Gh8Wq0u8XHeWNL7fzWpzz9Qm7Lq8y6n5czWWZB2hCdwoKdDU EJoAaDaDcQwY5yneWXX7DsviJqOCjWfIpXY+uKFksbVuZDEztKjaKvdfpEW8JAdaJqAFHmEu90iG 3kNYWFpZYjEZVMOqmavPC3rI7dDlLZWoHbGeHm71ZYr785TmZANIuhGKE5EUIhGDropLLVAQtWH4 0xRcfpsPVTG2CKXEELxt+irccrFQwW1Yz92iEIj5e3vOizGM+/B23C6w8+aZuTdrOZk9vQBvvQOH K2Ys9Ndx7rmHuNt+wKgzQfo1Iue5MwIa5CRZ1IS1QScVx5mkQQyqsGEvZkFSI75UAV5S+qd2/xyp ICdH7fDiEY9Dm3f17Nsht1IhEl4uZwVljHWXx/Gq296qqyax489Tmasbz95L37+ojW3lxo+++gPy QRwTD5XzHoI4/k8MBTQkv9usbDibweBahB+SGrx+rvG8kU59frzhul8ProlvWLtnnnfBRHIwMDs3 XaLNvRxiT/xu5P4rvEzH3BvWLlyfNpIoTgL3q4A7ZCylBSKXhsg9bwQmrMgUmiRTOaApLYtGt/Js o1AdlLnX+OKhUuUghOrBhUMhzQzKMhTJtfZEjEEFFaNtBM3dkBPfBw5+2KhIVgIFvBeStlpG8fgA 5fh7GZBTamZYpXTaRvYOTf1ybUCitPvxwXK3vKRpRUv6ivo5BPk3V5bK8V/H5zdXhhpdkSsf2Ebd Ni9q1oLhZbZ0+2ys/7pGi3/otiuptZmQyLen2ok8GpDnXZDHAhvCHYqVEvNVlY8vSgSoJa7H73vL oGJ9jouEeWI6msQHSwJ+G9d/LfeIobgMMp8/R+d2QMGaeYOOKF3FJmksKvH7Jc7OpWcfZnp6WlkJ URn1Qtk6A/xINEMEUpAgLWFsscpokU1hUeN6PFpb47LqBmaGqF9yt7Meu82mHKB3LNWHlw9zt/qZ o1JDqCeFF5WRrN927hT9KGDaiQJAjyUVxQt1ze4gtY2UOugKKOgKMLEqDYmPJvXYBI0ClD/qQP6i uxa2bEhgC7YUL2yY16e7dvn0dHJwMkZJVKyb+yrvlZe96bLUmsTNzJKmuavSt90rrRmZLG9v3x7w Gaq2X8sdbIqHijR5fnyUGhmtSOqTKwKg4yhI1Q5S8Tbl6x7PFQSJRLUy2mZ1Qu8CMmjopq2KQNKf HqvSVS6vr9tcXRGct2RR8JmjEy9f176bPvRmTbOp+8nru24aKo+kkuXxEuXZL/cev4p0bcCDKRXc Ad0GyTYhL82GwZQ8VkW2KEtgdZ6LFuoNMBWCb0FvJkwztFTLBv9nrlBVGvkilpdftWw0dvDxDX+8 MjlWIbOU1/qmd6yecFeWVxpkTNXylrCpQBySnN0yr7ZYnxuSHGRqa4u/O3nw+IRaxz02r7farXrt ueeO5lsqyxJ+kGwEtN8L2uuJ/o5LBIHKY8kYPxKlvSCgUERPV6+abn39rVV/2jb84y4fPXtjeKq/ /dqaVUJXZ2rllbmHa1tKvz19+7Grqtc8tKtg0/6eeB3uGruh8dBdBEvzAQKfCn4KHSHCtgtxCpUf vM5AaxgMQA9IcEDawSA1+LVUX+LhVrqdasmUU69VSBlxfOP13fOjg8qg1+JxGqRf04tmD9SmbGqA Ll/6qWVBiNE5Qe/4ruVs7m/m+guc1X0to6T3quJq6I9BzwCqQR0gASsinZYQchNY2oTn4mwHxsd3 KBIlwMx8EkhqLZh3B/SJPFKVfKN4PqmVYiv98VPiIvtLT3XEWoy1qVNX7KgYe3XX8AObazpbfZHq BQ3NFcM3tjXU44HZphXLgw0edWBhed+QPhi8eU/3tpSMbai8fQG9SJRbtCpx4DF1ZbnDKU+uaerd 066rWJauWskqmwIVfXHXLUsXbu0oUXBvXL2LTS3xL94UvWbmS2dXpLurrDtWGHbpwaNEu8/gfESD TyFL2ML0hfaKxxy02ha89ckVrEUrZXR+z2dxuSfITQpSL7xw5su8AnMyjX9dPc+nzQmLZ8MLa21S PhNUQa6NAYKrgWYwEIVeCf6hR3XyiQfnY1Kb+MaZmMgHWaiUj13+Ht/e8ZjHY2aLWh+Len3iHIcL P+IdiX6CzYEFZdz0HH2u1bPZajQbyolA6wOsQsRD/3SM8ojEpcHSmF6tNlmF0FxXh97ndiWrwO+0 QpVvDCR+7inMO8UL65cWsrURuu58JADyQHb8IcjO9yRZMS8V6fvszvwwIaAEthX20a+i5UBRSyCr 0fIZK1MHLurKkNpzsXfgmV24RzLbxZY3GsRrZLHWhirL0DW65mX95bX9tUUSpdPDbWatWqlYabB6 ncV1C+wX70nUFqvXWNLQ7BRKVQ4HN+m06PKIKz+P01YmFnfIl/a1NLDsgi0ruZ0tlWYtdGvg2NoU FnatSToL5eaW1hC35/InSyZSLk2uI93i5m6oiFnVShJUl6Ehoz/jA/1hNFCCszpc0Cvjf15XKEHR oChjm2xrxfi4TUShHKXBUcay6U4nD7vzKPw8nitr6lkWinTVuNQ5KqfvvMTpdY0lRkVRS1MZtzvj l8ulOsA0V9v0odaxDm5nXQIYkEpDcvp7EO1SOE8jwYXcSo5YlwcypXrjg/VHp9/7cPXL3K5rt9T2 zp1TM9EwtU3+r1OHjq357rP7j63FZ17/W83qW+fveaHnLUK7kWtncsEGxagcMiYkj0yLzuvNYxz0 JsggzCCt0/AFKCVhOQ8JPCHWlpZxI3aPLofJ07Kek3FpfqKhtb740GNDz17XNBnQxTtSU1uOly9o s5jerql26EhdVpekK+nuhnjxnAJxWHyAqapwyr/96tBHa/W4b/lIjfmlF/Eu27xGcowgGKU9oDvL Y5Qkr2xa5QH5fScB+KK943WVvrW6iM9en9RrgkFu/BJAaejaVpfwk4jf1ZYu4+7rqTPDSeJSF4Qk hGsvWFwCXEmy4Ison1a1Jv6ED2aAFpAv5HwGZaGHytRULXVuuSbWEm3rc7YNr1hTFRnY2dZ5T/OA 4Ypl9rqIubjzip7VVUseXJu8chn1UayusLnGGwuVupsGUvPHUia96s2lHfm2mCdYHfY4GwZq26eq pUqQxnHuFPUC8wTxvpKc5NQWtYWUnExNJ26BsuMIJGyq3B/jWu4ZubvcXZy2euq3prZds5e+Mae4 qq/n22Gutn99TaGlKFKXuOsABS0uRo1QyR3070kVg56TJ5lp/sD1/F6r5is68IASArUcs43YWGBP VjrTCx1CmdLGYqNQ5YocjwvzO+5o6dlUKXUk6N9z9MYtCZepucmPN1dUQj8v8c92taayNby7s+Hm 7XhLZ5VDDjIoz/0vIwEZikCgbBdowGRCkEnGF7vAX3idSqnsV6+q5J4Y3sS6XEbukU3c6UILCyr4 c1Vmg2Euywnx8bKEweWG7jPHUl89a6BOtlYU5viBk/HcWaEbODlgPIdt0AZksn2m7wxeypSG1pM2 cWd2n9IWgYq7K0vy8n6G8U3vPyor8ETwssJCg0XP/WMndXJWTn3SMNdI0gvLEv4ULZw5gz9z1plc MCzxi/KN8epZM3DXApL/DNyjoCeUm/P6QbFRZrI4qT8+fMnUhooqs0KS/klL5WxXz7Hacb1zfsVf jvnnsdzqDpny1n0KpaOYe9wSjnreeNcdcmvwrvlqDVVzyBA0aE0iOIFW13Pca8l0PoReSO3Uv3xU 49AabAyIbK+IYgrbY5FCqEN5Aa0XIIaRimviPQLzBAHpoS6gPcq343BU5Xv1Sw1Giaic6MjVC6N1 S/LsVpMvWFfKnTBYnCy+w+cskMoeP6pQ+iozXmu/at886Z9KzNryDUuo042VJgjBXLVljqGS5XLx P4trjaXnvUek0XFf4Fp0ArIfcvBpiD+Fh1gclpWNLo0EvSrRiXQqvWF9XbysFSZWTZDVDsMP18Ek lIZJI981KMlAbt3Ro0fpnZ9/Ptt/4gShPA4fUaAM02wHeR59+QQ8wGgMP0/FqKXkPraELVSMK8Nv 4OfvJvlyG2SGL2GulM3FFMyQSDtdoJBTWF5ALvgJj4yi3H99u2bjwf4P3jvOxaa2Tm2MrWqpW1ah k+NO3P0kznukk/sVd5i7h7udepV7mvsLLsKeT7DxqvZ9fyOyPQ5oeR34wDQDjsIXiyxMj4QiFgeF aup3Ukuit3XWuKYvoC00mDctcuN3okIsqJzrUOdSjY0ChTWRpkuLHcnKVqxdfhiobgOqLwHVYtCY PwCRoRB0PlGIer4XzI4yiZ1pOCFSR/wxu1repZh5qfS2HRuC5VFd2WDzf9VMTb3d+fQRtadl6doj S36eV+jxcR+WjX54+3SyYXSZr3l98o3nKoIH7g4vWTS0cvKln4DdtkOmkQBnPcxywSNWIQWFBQyX nRBaiSEj9ii2wpSFzMsyBwaQyknfvO+rn5klnQf61t7bNvTmXR/8Y+J1LP8Jd87f0+bME0qE09ub V1QZtgi8/uvOoUeZWPngE5Pb/7wORsLix3Hk0+tzZldpXObcPGV58tmjoZ4rG/YeIhbee+47hoLT oIzPBmEchoMgjHKVFhglPn0rZeAaSvwWjXKhiu4WOM6842c25ucXelM4hcgLwyQb81dCQmFBc2rB 4vrS2v7xgXWj/f8Hs/V9iQplbmRzdHJlYW0KZW5kb2JqCjE0OCAwIG9iago0ODUxCmVuZG9iago1 NiAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9WQldC UkYrQXJpYWwtQm9sZE1UIC9Gb250RGVzY3JpcHRvcgoxNDkgMCBSIC9Ub1VuaWNvZGUgMTUwIDAg UiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciAzMyAvV2lkdGhzIFsgMjc4IF0gPj4KZW5kb2JqCjE1 MCAwIG9iago8PCAvTGVuZ3RoIDE1MSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFt CngBXZDBbsMgEETvfMUek0ME9hkhVaki+dA2qpMPwLC2kGpAa3zw3xeIk0o97IGZeTAsP3fvnXcJ +JWC6THB6LwlXMJKBmHAyXnWtGCdSfupambWkfEM99uScO78GEBKBsC/M7Ik2uDwZsOAx6J9kUVy foLD/dxXpV9j/MEZfQLBlAKLY77uQ8dPPSPwip46m32XtlOm/hK3LSLkRploHpVMsLhEbZC0n5BJ IZS8XBRDb/9ZOzCMe7JtlCwjRCtq/ukUtHzxVcmsRLlN3UMtWgo4j69VxRDLg3V+AW40cBIKZW5k c3RyZWFtCmVuZG9iagoxNTEgMCBvYmoKMjIzCmVuZG9iagoxNDkgMCBvYmoKPDwgL1R5cGUgL0Zv bnREZXNjcmlwdG9yIC9Gb250TmFtZSAvVkJXQlJGK0FyaWFsLUJvbGRNVCAvRmxhZ3MgNCAvRm9u dEJCb3gKWy02MjggLTM3NiAyMDAwIDEwNTZdIC9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgOTA1IC9E ZXNjZW50IC0yMTIgL0NhcEhlaWdodAo3MTYgL1N0ZW1WIDAgL0xlYWRpbmcgMzMgL1hIZWlnaHQg NTE5IC9BdmdXaWR0aCA0NzkgL01heFdpZHRoIDIwMDAgL0ZvbnRGaWxlMgoxNTIgMCBSID4+CmVu ZG9iagoxNTIgMCBvYmoKPDwgL0xlbmd0aCAxNTMgMCBSIC9MZW5ndGgxIDQ3MiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAErKSpNZeBgaGBgZmBIzk0sYAADxgQgJZWeU5kG5bcAaa2M 1MQUCJ/hD5A2ywAKQOVNgLRKRm5JBZQfAaQ5cvKTYfI1QD5bbmIF1HyGO0C+Ql5ibipU/QYgrYFb XmcCUF6noCgV5j6g+fyTbSCaGf5DAZSLoBiBTCamSww2DFMY2BiYGAQY9BlAYiDACuSD2GxnzqrP e5YUz2/zlUOSAyy16LGNLIhxNuCq+K9ff/4KMHAUAdVywvUC9bHb/fNjcBZg+PXrV5UAA1wGrB9I MLEBhZgswVxGqCwP0A08QBFFIB/mClEGUZBqEJcVCIGxwA5UIKgoqAokGBlYGP4oMB/448DK8JtB geUAUBUQMDIIQfWzMQgzMIQ5hTsFuWk7FmUm5ug65eek+IYAFQEAEidHQAplbmRzdHJlYW0KZW5k b2JqCjE1MyAwIG9iagozMDcKZW5kb2JqCjEgMCBvYmoKPDwgL1RpdGxlIChNaWNyb3NvZnQgV29y ZCAtIGRyYWZ0LXBlbG92LWNvcmUtY29tYXAuZG9jeCkgL1Byb2R1Y2VyIChtYWNPUyBWZXJzaW9u IDEwLjE1LjYgXChCdWlsZCAxOUc3M1wpIFF1YXJ0eiBQREZDb250ZXh0KQovQ3JlYXRvciAoV29y ZCkgL0NyZWF0aW9uRGF0ZSAoRDoyMDIwMDczMDA3NDAxM1owMCcwMCcpIC9Nb2REYXRlIChEOjIw MjAwNzMwMDc0MDEzWjAwJzAwJykKPj4KZW5kb2JqCnhyZWYKMCAxNTQKMDAwMDAwMDAwMCA2NTUz NSBmIAowMDAwMTIzMzczIDAwMDAwIG4gCjAwMDAwMDQ2NTMgMDAwMDAgbiAKMDAwMDA1Njk2NCAw MDAwMCBuIAowMDAwMDAwMDIyIDAwMDAwIG4gCjAwMDAwMDQ2MzMgMDAwMDAgbiAKMDAwMDAwNDc1 NyAwMDAwMCBuIAowMDAwMDA3NjUyIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDA2 MjgxMiAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAxMTYwNDMgMDAwMDAgbiAKMDAw MDAwMDAwMCAwMDAwMCBuIAowMDAwMDcwMzk5IDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAK MDAwMDA4NjEwOSAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwNTczMjcgMDAwMDAg biAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMTAyMzM4IDAwMDAwIG4gCjAwMDAwMDQ5MTYgMDAw MDAgbiAKMDAwMDAwNzYzMSAwMDAwMCBuIAowMDAwMDA5OTY2IDAwMDAwIG4gCjAwMDAwMDc2ODgg MDAwMDAgbiAKMDAwMDAwOTk0NSAwMDAwMCBuIAowMDAwMDEwMDczIDAwMDAwIG4gCjAwMDAwMDAw MDAgMDAwMDAgbiAKMDAwMDA4ODYyOSAwMDAwMCBuIAowMDAwMDE1ODI4IDAwMDAwIG4gCjAwMDAw MTAyMTAgMDAwMDAgbiAKMDAwMDAxNTgwNyAwMDAwMCBuIAowMDAwMDE1OTM1IDAwMDAwIG4gCjAw MDAwODI2MjIgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDgxNDc1IDAwMDAwIG4g CjAwMDAwMjA4NzcgMDAwMDAgbiAKMDAwMDAxNjA4NSAwMDAwMCBuIAowMDAwMDIwODU2IDAwMDAw IG4gCjAwMDAwMjA5ODQgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDk1OTA5IDAw MDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDA5ODMzMCAwMDAwMCBuIAowMDAwMDAwMDAw IDAwMDAwIG4gCjAwMDAwNzM4NzIgMDAwMDAgbiAKMDAwMDAyMTIxNCAwMDAwMCBuIAowMDAwMDIx MjY4IDAwMDAwIG4gCjAwMDAwMjM5ODQgMDAwMDAgbiAKMDAwMDAyMTMyMSAwMDAwMCBuIAowMDAw MDIzOTYzIDAwMDAwIG4gCjAwMDAwMjQwOTEgMDAwMDAgbiAKMDAwMDAyOTQyMiAwMDAwMCBuIAow MDAwMDI0MjY5IDAwMDAwIG4gCjAwMDAwMjk0MDEgMDAwMDAgbiAKMDAwMDAyOTUyOSAwMDAwMCBu IAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAxMjIyMDcgMDAwMDAgbiAKMDAwMDAzNTE1NyAwMDAw MCBuIAowMDAwMDI5Njc5IDAwMDAwIG4gCjAwMDAwMzUxMzYgMDAwMDAgbiAKMDAwMDAzNTI2NCAw MDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAxMTEzMzEgMDAwMDAgbiAKMDAwMDA0MTIw MyAwMDAwMCBuIAowMDAwMDM1NDgxIDAwMDAwIG4gCjAwMDAwNDExODIgMDAwMDAgbiAKMDAwMDA0 MTMxMCAwMDAwMCBuIAowMDAwMDQ2OTE3IDAwMDAwIG4gCjAwMDAwNTcwODcgMDAwMDAgbiAKMDAw MDA0MTUxNCAwMDAwMCBuIAowMDAwMDQ2ODk2IDAwMDAwIG4gCjAwMDAwNDcwMjUgMDAwMDAgbiAK MDAwMDA1MjMwNCAwMDAwMCBuIAowMDAwMDQ3MjI5IDAwMDAwIG4gCjAwMDAwNTIyODMgMDAwMDAg biAKMDAwMDA1MjQxMiAwMDAwMCBuIAowMDAwMDU2MjMyIDAwMDAwIG4gCjAwMDAwNTI2MTYgMDAw MDAgbiAKMDAwMDA1NjIxMSAwMDAwMCBuIAowMDAwMDU2MzQwIDAwMDAwIG4gCjAwMDAwNTY3NTgg MDAwMDAgbiAKMDAwMDA1NjU0NCAwMDAwMCBuIAowMDAwMDU2NzM4IDAwMDAwIG4gCjAwMDAwNTY4 NjYgMDAwMDAgbiAKMDAwMDA1NzE4NCAwMDAwMCBuIAowMDAwMDU3Mjc2IDAwMDAwIG4gCjAwMDAw NTgyNzUgMDAwMDAgbiAKMDAwMDA1NzY4MyAwMDAwMCBuIAowMDAwMDU4MjU1IDAwMDAwIG4gCjAw MDAwNTg1MjggMDAwMDAgbiAKMDAwMDA2Mjc5MSAwMDAwMCBuIAowMDAwMDYzMjkzIDAwMDAwIG4g CjAwMDAwNjI5NzQgMDAwMDAgbiAKMDAwMDA2MzI3MyAwMDAwMCBuIAowMDAwMDYzNTI5IDAwMDAw IG4gCjAwMDAwNzAzNzggMDAwMDAgbiAKMDAwMDA3MTEyMyAwMDAwMCBuIAowMDAwMDcwNjU5IDAw MDAwIG4gCjAwMDAwNzExMDMgMDAwMDAgbiAKMDAwMDA3MTM3NiAwMDAwMCBuIAowMDAwMDczODUw IDAwMDAwIG4gCjAwMDAwNzQ5NDEgMDAwMDAgbiAKMDAwMDA3NDI3NCAwMDAwMCBuIAowMDAwMDc0 OTIwIDAwMDAwIG4gCjAwMDAwNzUxODUgMDAwMDAgbiAKMDAwMDA4MTQ1MyAwMDAwMCBuIAowMDAw MDgxOTYyIDAwMDAwIG4gCjAwMDAwODE2NDAgMDAwMDAgbiAKMDAwMDA4MTk0MSAwMDAwMCBuIAow MDAwMDgyMjEyIDAwMDAwIG4gCjAwMDAwODI2MDEgMDAwMDAgbiAKMDAwMDA4Mjc5OSAwMDAwMCBu IAowMDAwMDgzMDM3IDAwMDAwIG4gCjAwMDAwODYwODcgMDAwMDAgbiAKMDAwMDA4NjczOCAwMDAw MCBuIAowMDAwMDg2MzMxIDAwMDAwIG4gCjAwMDAwODY3MTcgMDAwMDAgbiAKMDAwMDA4Njk5MyAw MDAwMCBuIAowMDAwMDg4NjA3IDAwMDAwIG4gCjAwMDAwODkxMjYgMDAwMDAgbiAKMDAwMDA4ODgw NCAwMDAwMCBuIAowMDAwMDg5MTA1IDAwMDAwIG4gCjAwMDAwODkzNzQgMDAwMDAgbiAKMDAwMDA5 NTg4NyAwMDAwMCBuIAowMDAwMDk2NDk1IDAwMDAwIG4gCjAwMDAwOTYxMTMgMDAwMDAgbiAKMDAw MDA5NjQ3NCAwMDAwMCBuIAowMDAwMDk2NzQzIDAwMDAwIG4gCjAwMDAwOTgzMDggMDAwMDAgbiAK MDAwMDA5OTE2NyAwMDAwMCBuIAowMDAwMDk4NjMyIDAwMDAwIG4gCjAwMDAwOTkxNDYgMDAwMDAg biAKMDAwMDA5OTQxNyAwMDAwMCBuIAowMDAwMTAyMzE2IDAwMDAwIG4gCjAwMDAxMDM1OTIgMDAw MDAgbiAKMDAwMDEwMjgxMiAwMDAwMCBuIAowMDAwMTAzNTcxIDAwMDAwIG4gCjAwMDAxMDM4MzIg MDAwMDAgbiAKMDAwMDExMTMwOSAwMDAwMCBuIAowMDAwMTEyMjA4IDAwMDAwIG4gCjAwMDAxMTE2 NTQgMDAwMDAgbiAKMDAwMDExMjE4NyAwMDAwMCBuIAowMDAwMTEyNDYyIDAwMDAwIG4gCjAwMDAx MTYwMjEgMDAwMDAgbiAKMDAwMDExNzAwMiAwMDAwMCBuIAowMDAwMTE2MzkyIDAwMDAwIG4gCjAw MDAxMTY5ODEgMDAwMDAgbiAKMDAwMDExNzI0MiAwMDAwMCBuIAowMDAwMTIyMTg1IDAwMDAwIG4g CjAwMDAxMjI2OTkgMDAwMDAgbiAKMDAwMDEyMjM3NyAwMDAwMCBuIAowMDAwMTIyNjc4IDAwMDAw IG4gCjAwMDAxMjI5NTQgMDAwMDAgbiAKMDAwMDEyMzM1MiAwMDAwMCBuIAp0cmFpbGVyCjw8IC9T aXplIDE1NCAvUm9vdCA4NSAwIFIgL0luZm8gMSAwIFIgL0lEIFsgPGY4NTM0YTQxZjI2MzdkNjk5 NjIxNzFkYzRkMGEzOTQ5Pgo8Zjg1MzRhNDFmMjYzN2Q2OTk2MjE3MWRjNGQwYTM5NDk+IF0gPj4K c3RhcnR4cmVmCjEyMzYwNwolJUVPRgo= --000000000000fd0d9405aba3dfd0-- From nobody Thu Jul 30 02:00:10 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 861443A0FDC for ; Thu, 30 Jul 2020 02:00:08 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 uXGMsVPkCYhr for ; Thu, 30 Jul 2020 02:00:06 -0700 (PDT) Received: from authenticated.a-painless.mh.aa.net.uk (a-painless.mh.aa.net.uk [IPv6:2001:8b0:0:30::51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9F93A0F9F for ; Thu, 30 Jul 2020 02:00:02 -0700 (PDT) Received: from a-webmail.thn.aa.net.uk ([2001:8b0:62::22] helo=webmail.aa.net.uk) by a-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k14Pw-0003uL-Av; Thu, 30 Jul 2020 10:00:00 +0100 Received: from cpc104502-sgyl40-2-0-cust104.18-2.cable.virginm.net ([82.34.80.105]) by webmail.aa.net.uk with HTTP (HTTP/1.1 POST); Thu, 30 Jul 2020 09:59:52 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_40c9ab4a3b40d4888ec8e029dee3278d" Date: Thu, 30 Jul 2020 09:59:52 +0100 From: Kio Smallwood To: Carsten Bormann Cc: cbor@ietf.org, Brendan Moran , Michael Richardson In-Reply-To: References: <25163.1596045376@localhost> <0A0FEABF-ADF2-4342-9AC3-42F768F14CCF@mothers-arms.co.uk> Message-ID: <99a918d0f4cdabc88071a82056efe621@mothers-arms.co.uk> X-Sender: kio@mothers-arms.co.uk User-Agent: Roundcube Webmail/1.3.14 Archived-At: Subject: Re: [Cbor] "ordered hash" 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, 30 Jul 2020 09:00:09 -0000 --=_40c9ab4a3b40d4888ec8e029dee3278d Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Thanks Carsten! > I think this idiom is frequent enough that it should get a 1+1 tag. Yes I agree. > The difference from a map is that this is both order-preserving and allowing duplicate keys; whether you want one or two of these properties on the application data model level may differ between applications. I've always felt that allowing duplicate keys is unnecessary, does it need to be bundled with order-preserving? Your other example MList = [* (K, [* V])] covers this use case nicely. > FAList = [* (K, V)] Yes a flattened AList is the main use case. Allocating tags for the other structures at the same time makes good sense. Thanks, Kio On 2020-07-30 5:08, Carsten Bormann wrote: > On 2020-07-30, at 01:44, Kio Smallwood wrote: > >> I wrote a proposal for tag 272 ordered map. >> >> https://github.com/Sekenre/cbor-ordered-map-spec > > (272 is already taken: Non-UTF-8 CESU-8 string.) > >> Unfortunately no one has approved the tag allocation or given me any guidance on how to proceed. > > Let's look into this. > > I think this idiom is frequent enough that it should get a 1+1 tag. > > The difference from a map is that this is both order-preserving and allowing duplicate keys; whether you want one or two of these properties on the application data model level may differ between applications. > > The traditional alist (association list) is > > AList = [* [K, V]] > > By using the exact structure of a map (except that the array head will have double the argument that the map head has), we can save 1 byte per k/v pair ("flattened alist"): > > FAList = [* (K, V)] > > So [["a", 1], ["b", 2]] becomes ["a", 1, "b", 2] > > I'm not sure which of these MCR was inquiring on. The first is definitely an alist, and there is no need for a new term. The second can be called an ordered multimap, but there are other structures that also deserve this name. > > If adjacent duplicate keys of non-trivial size are likely in an ordered multimap, a better version of the multimap is: > > MList = [* (K, [* V])] > > So [["aaa", 1], ["aaa", 2], ["bbb", 3]] becomes ["aaa", [1, 2], "bbb", [3]] > > If V can never be an array (*), this can be further optimized into: > > OMList = [* (K, [2* V] / V)] > > So [["aaa", 1], ["aaa", 2], ["bbb", 3]] becomes ["aaa", [1, 2], "bbb", 3] > > Further refine by using delta coding for the keys (works best with sorted keys), etc. Also, a map can be used for the outer structure if order preservation is not actually needed: > > MMap = {* K => [* V]} > OMMap = {* K => [2* V] / V} > > There are many idioms to choose from; it would probably be best to define tags for at least each of the ones listed here. I think FAList (what Kio proposed) is the one that will see the most use. > > Grüße, Carsten > > (*) Or extra-wrap just arrays: > OEMList = [* (K, [2* V] / [V .and [* any]] / V)] --=_40c9ab4a3b40d4888ec8e029dee3278d Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Thanks Carsten!

I think this idiom is frequent enough that it should get a 1+1 tag.

Yes I agree.

The difference from a map is that this is both order-preserving and allo= wing duplicate keys; whether you want one or two of these properties on the= application data model level may differ between applications.

I've always felt that allowing duplicate keys is unnecessary, does it ne= ed to be bundled with order-preserving? Your other example MList<K, V>= ; =3D [* (K, [* V])] covers this use case nicely.

FAList<K, V> =3D [* (K, V)]

Yes a flattened AList is the main use case. Allocating tags for the othe= r structures at the same time makes good sense.

Thanks,

Kio

On 2020-07-30 5:08, Carsten Bormann wrote:

= On 2020-07-30, at 01:44, Kio Smallwood <kio@mothers-arms.co.uk> wrote:

I wrote a proposal for tag 272 ordered map.

https://github.com/Sekenre/cbor-o= rdered-map-spec

(272 is already taken: Non-UTF-8 CESU-8 string.)

Unfortunately no one has approved the tag allocation o= r given me any guidance on how to proceed.

Let's look into this.

I think this idiom is frequent en= ough that it should get a 1+1 tag.

The difference from a map i= s that this is both order-preserving and allowing duplicate keys; whether y= ou want one or two of these properties on the application data model level = may differ between applications.

The traditional alist (associ= ation list) is

AList<K, V> =3D [* [K, V]]

B= y using the exact structure of a map (except that the array head will have = double the argument that the map head has), we can save 1 byte per k/v pair= ("flattened alist"):

FAList<K, V> =3D [* (K, V)]
=
So [["a", 1], ["b", 2]] becomes ["a", 1, "b", 2]

I'm no= t sure which of these MCR was inquiring on.  The first is definitely a= n alist, and there is no need for a new term.  The second can be calle= d an ordered multimap, but there are other structures that also deserve thi= s name.  

If adjacent duplicate keys of non-trivial size = are likely in an ordered multimap, a better version of the multimap is:

MList<K, V> =3D [* (K, [* V])]

So [["aaa", 1],= ["aaa", 2], ["bbb", 3]] becomes ["aaa", [1, 2], "bbb", [3]]

I= f V can never be an array (*), this can be further optimized into:
OMList<K, V> =3D [* (K, [2* V] / V)]

So [["aaa", 1]= , ["aaa", 2], ["bbb", 3]] becomes ["aaa", [1, 2], "bbb", 3]

Fu= rther refine by using delta coding for the keys (works best with sorted key= s), etc.  Also, a map can be used for the outer structure if order pre= servation is not actually needed:

MMap<K, V> =3D {* K = =3D> [* V]}
OMMap<K, V> =3D {* K =3D> [2* V] / V}
<= br /> There are many idioms to choose from; it would probably be best to de= fine tags for at least each of the ones listed here.  I think FAList (= what Kio proposed) is the one that will see the most use.

Gr&u= uml;ße, Carsten

(*) Or extra-wrap just arrays:
OEM= List<K, V> =3D [* (K, [2* V] / [V .and [* any]] / V)]


--=_40c9ab4a3b40d4888ec8e029dee3278d-- From nobody Thu Jul 30 02:05: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 B7AF83A0FEF for ; Thu, 30 Jul 2020 02:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLz_5lzinnH0 for ; Thu, 30 Jul 2020 02:05:09 -0700 (PDT) Received: from authenticated.a-painless.mh.aa.net.uk (a-painless.mh.aa.net.uk [IPv6:2001:8b0:0:30::51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBCD3A0FED for ; Thu, 30 Jul 2020 02:05:09 -0700 (PDT) Received: from a-webmail.thn.aa.net.uk ([2001:8b0:62::22] helo=webmail.aa.net.uk) by a-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k14Uu-0004sW-4u; Thu, 30 Jul 2020 10:05:08 +0100 Received: from cpc104502-sgyl40-2-0-cust104.18-2.cable.virginm.net ([82.34.80.105]) by webmail.aa.net.uk with HTTP (HTTP/1.1 POST); Thu, 30 Jul 2020 10:05:07 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_4e920ad0342e196f1e9433448e6820f0" Date: Thu, 30 Jul 2020 10:05:07 +0100 From: Kio Smallwood To: Alexander Pelov Cc: cbor@ietf.org In-Reply-To: References: <25163.1596045376@localhost> <0A0FEABF-ADF2-4342-9AC3-42F768F14CCF@mothers-arms.co.uk> Message-ID: <5f66b697f4749fd0575e7548141f90cd@mothers-arms.co.uk> X-Sender: kio@mothers-arms.co.uk User-Agent: Roundcube Webmail/1.3.14 Archived-At: Subject: Re: [Cbor] "ordered hash" 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, 30 Jul 2020 09:05:12 -0000 --=_4e920ad0342e196f1e9433448e6820f0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Alexander, Thanks for this, it's good to see people thinking in similar directions! Cheers, Kio On 2020-07-30 8:46, Alexander Pelov wrote: > Hi all, > > Several years ago we had this type of discussion for the use of COMI/CORECONF. We called it in a couple of different ways: > - DeterministicMultimaps > - COMAP (CBOR Order-preserving Multimap) > - Order-Keeping Multimap (OKMM) > > Unfortunately, I don't think we published any open specs outside the Task Force (although we did have quite some discussion at CORE WG). > > One of the latest specs we had is attached (sorry for the PDF). > > Cheers, > Alexander > > On Thu, Jul 30, 2020 at 6:08 AM Carsten Bormann wrote: > >> On 2020-07-30, at 01:44, Kio Smallwood wrote: >>> >>> I wrote a proposal for tag 272 ordered map. >>> >>> https://github.com/Sekenre/cbor-ordered-map-spec >> >> (272 is already taken: Non-UTF-8 CESU-8 string.) >> >>> Unfortunately no one has approved the tag allocation or given me any guidance on how to proceed. >> >> Let's look into this. >> >> I think this idiom is frequent enough that it should get a 1+1 tag. >> >> The difference from a map is that this is both order-preserving and allowing duplicate keys; whether you want one or two of these properties on the application data model level may differ between applications. >> >> The traditional alist (association list) is >> >> AList = [* [K, V]] >> >> By using the exact structure of a map (except that the array head will have double the argument that the map head has), we can save 1 byte per k/v pair ("flattened alist"): >> >> FAList = [* (K, V)] >> >> So [["a", 1], ["b", 2]] becomes ["a", 1, "b", 2] >> >> I'm not sure which of these MCR was inquiring on. The first is definitely an alist, and there is no need for a new term. The second can be called an ordered multimap, but there are other structures that also deserve this name. >> >> If adjacent duplicate keys of non-trivial size are likely in an ordered multimap, a better version of the multimap is: >> >> MList = [* (K, [* V])] >> >> So [["aaa", 1], ["aaa", 2], ["bbb", 3]] becomes ["aaa", [1, 2], "bbb", [3]] >> >> If V can never be an array (*), this can be further optimized into: >> >> OMList = [* (K, [2* V] / V)] >> >> So [["aaa", 1], ["aaa", 2], ["bbb", 3]] becomes ["aaa", [1, 2], "bbb", 3] >> >> Further refine by using delta coding for the keys (works best with sorted keys), etc. Also, a map can be used for the outer structure if order preservation is not actually needed: >> >> MMap = {* K => [* V]} >> OMMap = {* K => [2* V] / V} >> >> There are many idioms to choose from; it would probably be best to define tags for at least each of the ones listed here. I think FAList (what Kio proposed) is the one that will see the most use. >> >> Grüße, Carsten >> >> (*) Or extra-wrap just arrays: >> OEMList = [* (K, [2* V] / [V .and [* any]] / V)] >> >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor --=_4e920ad0342e196f1e9433448e6820f0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Alexander,

Thanks for this, it's good to see people thinking in similar directions!=

Cheers,

Kio

On 2020-07-30 8:46, Alexander Pelov wrote:

Hi all,
 
Several years ago we had this type of discussion for the use of COMI/C= ORECONF. We called it in a couple of different ways: 
- DeterministicMultimaps
- COMAP (CBOR Order-preserving Multimap)
- Order-Keeping Multimap (OKMM)
 
Unfortunately, I don't think we published any open specs outside the T= ask Force (although we did have quite some discussion at CORE WG).
 
One of the latest specs we had is attached (sorry for the PDF). <= /div>
 
Cheers,
Alexander
 
 

On Thu, Jul 30, 2020 at 6:08 AM Carst= en Bormann <cabo@tzi.org> wrote:<= /div>
On 2020-07-30, at 01:44, Kio= Smallwood <kio@mothers-arms= =2Eco.uk> wrote:
>
> I wrote a proposal for tag 2= 72 ordered map.
>
> http= s://github.com/Sekenre/cbor-ordered-map-spec

(272 is alrea= dy taken: Non-UTF-8 CESU-8 string.)

> Unfortunately no one = has approved the tag allocation or given me any guidance on how to proceed= =2E

Let's look into this.

I think this idiom is f= requent enough that it should get a 1+1 tag.

The difference fr= om a map is that this is both order-preserving and allowing duplicate keys;= whether you want one or two of these properties on the application data mo= del level may differ between applications.

The traditional ali= st (association list) is

AList<K, V> =3D [* [K, V]]

By using the exact structure of a map (except that the array head = will have double the argument that the map head has), we can save 1 byte pe= r k/v pair ("flattened alist"):

FAList<K, V> =3D [* (K, = V)]

So [["a", 1], ["b", 2]] becomes ["a", 1, "b", 2]
I'm not sure which of these MCR was inquiring on.  The first is de= finitely an alist, and there is no need for a new term.  The second ca= n be called an ordered multimap, but there are other structures that also d= eserve this name. 

If adjacent duplicate keys of non-tri= vial size are likely in an ordered multimap, a better version of the multim= ap is:

MList<K, V> =3D [* (K, [* V])]

So [[= "aaa", 1], ["aaa", 2], ["bbb", 3]] becomes ["aaa", [1, 2], "bbb", [3]]

If V can never be an array (*), this can be further optimized into= :

OMList<K, V> =3D [* (K, [2* V] / V)]

So [= ["aaa", 1], ["aaa", 2], ["bbb", 3]] becomes ["aaa", [1, 2], "bbb", 3]
=
Further refine by using delta coding for the keys (works best with = sorted keys), etc.  Also, a map can be used for the outer structure if= order preservation is not actually needed:

MMap<K, V> = =3D {* K =3D> [* V]}
OMMap<K, V> =3D {* K =3D> [2* V] / V= }

There are many idioms to choose from; it would probably be b= est to define tags for at least each of the ones listed here.  I think= FAList (what Kio proposed) is the one that will see the most use.
Grüße, Carsten

(*) Or extra-wrap just arrays:<= br /> OEMList<K, V> =3D [* (K, [2* V] / [V .and [* any]] / V)]
=

_______________________________________________
CBOR ma= iling list
CBOR@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/cbor" target=3D"_blank" rel= =3D"noopener noreferrer">https://www.ietf.org/mailman/listinfo/cbor


--=_4e920ad0342e196f1e9433448e6820f0-- From nobody Thu Jul 30 02:06:05 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 164543A0FEE for ; Thu, 30 Jul 2020 02:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 pi5fdrteLfbn for ; Thu, 30 Jul 2020 02:06:00 -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 8E7373A0FED for ; Thu, 30 Jul 2020 02:06:00 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4BHPdy5xlNz10M4; Thu, 30 Jul 2020 11:05:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <99a918d0f4cdabc88071a82056efe621@mothers-arms.co.uk> Date: Thu, 30 Jul 2020 11:05:58 +0200 Cc: cbor@ietf.org, Brendan Moran , Michael Richardson X-Mao-Original-Outgoing-Id: 617792757.938367-1313239eb2b251f7f82a759ff76d7e6b Content-Transfer-Encoding: quoted-printable Message-Id: References: <25163.1596045376@localhost> <0A0FEABF-ADF2-4342-9AC3-42F768F14CCF@mothers-arms.co.uk> <99a918d0f4cdabc88071a82056efe621@mothers-arms.co.uk> To: Kio Smallwood X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] "ordered hash" 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, 30 Jul 2020 09:06:04 -0000 Thank you, Kio! I think I will write a subsection in=20 https://www.ietf.org/id/draft-bormann-cbor-notable-tags-02.html (even if we don=E2=80=99t have the actual tags yet), probably 6.4. Can I use your text as a contribution (like I did [and still plan to do] = with Peter Occil=E2=80=99s contribution)? (I would need some address = information that you want to see in a draft/RFC.) Gr=C3=BC=C3=9Fe, Carsten > On 2020-07-30, at 10:59, Kio Smallwood wrote: >=20 > Thanks Carsten! >=20 >> I think this idiom is frequent enough that it should get a 1+1 tag. >>=20 > Yes I agree. >=20 >> The difference from a map is that this is both order-preserving and = allowing duplicate keys; whether you want one or two of these properties = on the application data model level may differ between applications. >>=20 > I've always felt that allowing duplicate keys is unnecessary, does it = need to be bundled with order-preserving? Your other example MList = =3D [* (K, [* V])] covers this use case nicely. >=20 >> FAList =3D [* (K, V)] >>=20 > Yes a flattened AList is the main use case. Allocating tags for the = other structures at the same time makes good sense. >=20 > Thanks, >=20 > Kio >=20 > On 2020-07-30 5:08, Carsten Bormann wrote: >=20 >> On 2020-07-30, at 01:44, Kio Smallwood = wrote: >>>=20 >>> I wrote a proposal for tag 272 ordered map. >>>=20 >>> https://github.com/Sekenre/cbor-ordered-map-spec >>=20 >> (272 is already taken: Non-UTF-8 CESU-8 string.) >>=20 >>> Unfortunately no one has approved the tag allocation or given me any = guidance on how to proceed. >>=20 >> Let's look into this. >>=20 >> I think this idiom is frequent enough that it should get a 1+1 tag. >>=20 >> The difference from a map is that this is both order-preserving and = allowing duplicate keys; whether you want one or two of these properties = on the application data model level may differ between applications. >>=20 >> The traditional alist (association list) is >>=20 >> AList =3D [* [K, V]] >>=20 >> By using the exact structure of a map (except that the array head = will have double the argument that the map head has), we can save 1 byte = per k/v pair ("flattened alist"): >>=20 >> FAList =3D [* (K, V)] >>=20 >> So [["a", 1], ["b", 2]] becomes ["a", 1, "b", 2] >>=20 >> I'm not sure which of these MCR was inquiring on. The first is = definitely an alist, and there is no need for a new term. The second = can be called an ordered multimap, but there are other structures that = also deserve this name. =20 >>=20 >> If adjacent duplicate keys of non-trivial size are likely in an = ordered multimap, a better version of the multimap is: >>=20 >> MList =3D [* (K, [* V])] >>=20 >> So [["aaa", 1], ["aaa", 2], ["bbb", 3]] becomes ["aaa", [1, 2], = "bbb", [3]] >>=20 >> If V can never be an array (*), this can be further optimized into: >>=20 >> OMList =3D [* (K, [2* V] / V)] >>=20 >> So [["aaa", 1], ["aaa", 2], ["bbb", 3]] becomes ["aaa", [1, 2], = "bbb", 3] >>=20 >> Further refine by using delta coding for the keys (works best with = sorted keys), etc. Also, a map can be used for the outer structure if = order preservation is not actually needed: >>=20 >> MMap =3D {* K =3D> [* V]} >> OMMap =3D {* K =3D> [2* V] / V} >>=20 >> There are many idioms to choose from; it would probably be best to = define tags for at least each of the ones listed here. I think FAList = (what Kio proposed) is the one that will see the most use. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> (*) Or extra-wrap just arrays: >> OEMList =3D [* (K, [2* V] / [V .and [* any]] / V)] >>=20 >=20 >=20 From nobody Thu Jul 30 02:22: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 A35BB3A100E for ; Thu, 30 Jul 2020 02:22: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 mrptl4F561Ho for ; Thu, 30 Jul 2020 02:22:52 -0700 (PDT) Received: from authenticated.a-painless.mh.aa.net.uk (a-painless.mh.aa.net.uk [IPv6:2001:8b0:0:30::51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A803A0AE6 for ; Thu, 30 Jul 2020 02:22:51 -0700 (PDT) Received: from a-webmail.thn.aa.net.uk ([2001:8b0:62::22] helo=webmail.aa.net.uk) by a-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k14m2-0006bJ-9v; Thu, 30 Jul 2020 10:22:50 +0100 Received: from cpc104502-sgyl40-2-0-cust104.18-2.cable.virginm.net ([82.34.80.105]) by webmail.aa.net.uk with HTTP (HTTP/1.1 POST); Thu, 30 Jul 2020 10:22:50 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_0a6161064199be81b572e7d78ec09d8c" Date: Thu, 30 Jul 2020 10:22:50 +0100 From: Kio Smallwood To: Carsten Bormann Cc: cbor@ietf.org In-Reply-To: References: <25163.1596045376@localhost> <0A0FEABF-ADF2-4342-9AC3-42F768F14CCF@mothers-arms.co.uk> <99a918d0f4cdabc88071a82056efe621@mothers-arms.co.uk> Message-ID: <3a9dec4d93dcc0957e93a4517297020c@mothers-arms.co.uk> X-Sender: kio@mothers-arms.co.uk User-Agent: Roundcube Webmail/1.3.14 Archived-At: Subject: Re: [Cbor] "ordered hash" 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, 30 Jul 2020 09:22:55 -0000 --=_0a6161064199be81b572e7d78ec09d8c Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Yes you can use my text, I'll have to think about what address to use... Cheers, Kio On 2020-07-30 10:05, Carsten Bormann wrote: > Thank you, Kio! > > I think I will write a subsection in > https://www.ietf.org/id/draft-bormann-cbor-notable-tags-02.html > (even if we don't have the actual tags yet), probably 6.4. > > Can I use your text as a contribution (like I did [and still plan to do] with Peter Occil's contribution)? (I would need some address information that you want to see in a draft/RFC.) > > Grüße, Carsten > > On 2020-07-30, at 10:59, Kio Smallwood wrote: > > Thanks Carsten! > > I think this idiom is frequent enough that it should get a 1+1 tag. > Yes I agree. > > The difference from a map is that this is both order-preserving and allowing duplicate keys; whether you want one or two of these properties on the application data model level may differ between applications. > I've always felt that allowing duplicate keys is unnecessary, does it need to be bundled with order-preserving? Your other example MList = [* (K, [* V])] covers this use case nicely. > > FAList = [* (K, V)] > Yes a flattened AList is the main use case. Allocating tags for the other structures at the same time makes good sense. > > Thanks, > > Kio > > On 2020-07-30 5:08, Carsten Bormann wrote: > > On 2020-07-30, at 01:44, Kio Smallwood wrote: > I wrote a proposal for tag 272 ordered map. > > https://github.com/Sekenre/cbor-ordered-map-spec > (272 is already taken: Non-UTF-8 CESU-8 string.) > > Unfortunately no one has approved the tag allocation or given me any guidance on how to proceed. > Let's look into this. > > I think this idiom is frequent enough that it should get a 1+1 tag. > > The difference from a map is that this is both order-preserving and allowing duplicate keys; whether you want one or two of these properties on the application data model level may differ between applications. > > The traditional alist (association list) is > > AList = [* [K, V]] > > By using the exact structure of a map (except that the array head will have double the argument that the map head has), we can save 1 byte per k/v pair ("flattened alist"): > > FAList = [* (K, V)] > > So [["a", 1], ["b", 2]] becomes ["a", 1, "b", 2] > > I'm not sure which of these MCR was inquiring on. The first is definitely an alist, and there is no need for a new term. The second can be called an ordered multimap, but there are other structures that also deserve this name. > > If adjacent duplicate keys of non-trivial size are likely in an ordered multimap, a better version of the multimap is: > > MList = [* (K, [* V])] > > So [["aaa", 1], ["aaa", 2], ["bbb", 3]] becomes ["aaa", [1, 2], "bbb", [3]] > > If V can never be an array (*), this can be further optimized into: > > OMList = [* (K, [2* V] / V)] > > So [["aaa", 1], ["aaa", 2], ["bbb", 3]] becomes ["aaa", [1, 2], "bbb", 3] > > Further refine by using delta coding for the keys (works best with sorted keys), etc. Also, a map can be used for the outer structure if order preservation is not actually needed: > > MMap = {* K => [* V]} > OMMap = {* K => [2* V] / V} > > There are many idioms to choose from; it would probably be best to define tags for at least each of the ones listed here. I think FAList (what Kio proposed) is the one that will see the most use. > > Grüße, Carsten > > (*) Or extra-wrap just arrays: > OEMList = [* (K, [2* V] / [V .and [* any]] / V)] _______________________________________________ CBOR mailing list CBOR@ietf.org https://www.ietf.org/mailman/listinfo/cbor --=_0a6161064199be81b572e7d78ec09d8c Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Yes you can use my text, I'll have to think about what address to use.= =2E.

Cheers,

Kio

On 2020-07-30 10:05, Carsten Bormann wrote:

= Thank you, Kio!

I think I will write a subsection in
https://www.ietf.org/id/draft-= bormann-cbor-notable-tags-02.html
(even if we don't have the actu= al tags yet), probably 6.4.

Can I use your text as a contribut= ion (like I did [and still plan to do] with Peter Occil's contribution)? &n= bsp;(I would need some address information that you want to see in a draft/= RFC.)

Grüße, Carsten


On 2020-07-30, at 10:59, Kio Smallwood <kio@mothers-arms.co.uk> wrote:
=
Thanks Carsten!

I think this idiom is frequent enough that it should g= et a 1+1 tag.
Yes I agree.

The difference from a map is that this is both order-p= reserving and allowing duplicate keys; whether you want one or two of these= properties on the application data model level may differ between applicat= ions.
I've always felt that allowing duplicate keys is unnecessary, does it need = to be bundled with order-preserving? Your other example MList<K, V> = =3D [* (K, [* V])] covers this use case nicely.

FAList<K, V> =3D [* (K, V)]
Yes a flattened AList is the main use case. Allocating tags for the other s= tructures at the same time makes good sense.

Thanks,
Kio

On 2020-07-30 5:08, Carsten Bormann wrote:

On 2020-07-30, at 01:44, Kio Smallwood <kio@mothers-arms.co.uk> wrote:

I wrote a proposal for tag 272 ordered map.

https://github.com/Sekenre/cbor-o= rdered-map-spec

(272 is already taken: Non-UTF-8 CESU-8 string.)

Unfortunately no one has approved the tag allocation o= r given me any guidance on how to proceed.

Let's look into this.

I think this idiom is frequent en= ough that it should get a 1+1 tag.

The difference from a map i= s that this is both order-preserving and allowing duplicate keys; whether y= ou want one or two of these properties on the application data model level = may differ between applications.

The traditional alist (associ= ation list) is

AList<K, V> =3D [* [K, V]]

B= y using the exact structure of a map (except that the array head will have = double the argument that the map head has), we can save 1 byte per k/v pair= ("flattened alist"):

FAList<K, V> =3D [* (K, V)]
=
So [["a", 1], ["b", 2]] becomes ["a", 1, "b", 2]

I'm no= t sure which of these MCR was inquiring on.  The first is definitely a= n alist, and there is no need for a new term.  The second can be calle= d an ordered multimap, but there are other structures that also deserve thi= s name.  

If adjacent duplicate keys of non-trivial size = are likely in an ordered multimap, a better version of the multimap is:

MList<K, V> =3D [* (K, [* V])]

So [["aaa", 1],= ["aaa", 2], ["bbb", 3]] becomes ["aaa", [1, 2], "bbb", [3]]

I= f V can never be an array (*), this can be further optimized into:
OMList<K, V> =3D [* (K, [2* V] / V)]

So [["aaa", 1]= , ["aaa", 2], ["bbb", 3]] becomes ["aaa", [1, 2], "bbb", 3]

Fu= rther refine by using delta coding for the keys (works best with sorted key= s), etc.  Also, a map can be used for the outer structure if order pre= servation is not actually needed:

MMap<K, V> =3D {* K = =3D> [* V]}
OMMap<K, V> =3D {* K =3D> [2* V] / V}
<= br /> There are many idioms to choose from; it would probably be best to de= fine tags for at least each of the ones listed here.  I think FAList (= what Kio proposed) is the one that will see the most use.

Gr&u= uml;ße, Carsten

(*) Or extra-wrap just arrays:
OEM= List<K, V> =3D [* (K, [2* V] / [V .and [* any]] / V)]


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


--=_0a6161064199be81b572e7d78ec09d8c-- From nobody Thu Jul 30 10:08: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 AAA833A0C9A; Thu, 30 Jul 2020 10:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-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 jtzFtYtkLMX6; Thu, 30 Jul 2020 10:08:41 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30074.outbound.protection.outlook.com [40.107.3.74]) (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 738003A0C70; Thu, 30 Jul 2020 10:08:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lWt5g7OFjkh0UNTHimtKYUxfCEuJ/Lge0GfAeQSXjhqLzOxL9YympRHGxhC3w6RrOmbMShmoAdF/kYljyT3J1e9lQku6i3tc8wmt2K21iiUM8EmPNZ7UwJ8d/QQljtLWN/Wq5Fd2GobdWT8LTOZn6yA3DIp66QYJ2PUriXo7Sc5c1ixM/dcn5pYQSQz1jarAuI8Yol0B00OsKEU13/pOjufeHfvogNUdYt4cX7/jxljtCuXm1NSEDAaSIgUlvRad+zIZYqzKqo4oGLKvwpDA/MRHc5PQzuaPEvlVRjD2SwNIC/9oqhPO/XnCh0X0EgZFuTQw4pZ0dGg9CQVkzFSuiQ== 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=X1jjC+adPTml8UdDWm+dSaLBmCksYTCJqQo0mHxvjho=; b=PSKXyVzjaJIcICO7DoKfJP3LwZc00qWXbiFY1wbZvhHB3/uM7CaSj7vkUwAfXFu7QIXPc2NhXLW2jhEGJuZu2c8TpuvMM94NPM4oGwp9mCCtXjx9Sm1CPtyhLo4364XaI82ezLY7wAfUgjlEiVSR9ENUBloaOptqQ1baFrR9vxf0LzMFVABM1cga5gpbDAzEUBRfpAYzC6oIokJIi6a2eIn4ivnHS/rRNwLtQgkC3iQWWjvcnxDrZgHGiG6dZ3Nvkr4cjBlpxmOUgctnLZOzb+tejc3c4p8lw1mbneU3g1yUcxOqrOTObG9D5CFvx4y3tBjZnJAsNp1q1TaKksKFSw== 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=X1jjC+adPTml8UdDWm+dSaLBmCksYTCJqQo0mHxvjho=; b=KwV2O2h8rwoZ2LnmQQ1HLXCKTwALn993CDYzwxFM/CFhSqQH6rO/wCGd/X+S0wgq+JNpFzEIv2nV2FGwNz+xVRggPEu83+Ie2ERA35J5Eo3WiYAHKMX4I9qEQ9sJDNMF/GcpCvO59KaSLoNIJlQv8W2nwrpB4e8jRX019MMVi3s= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR07MB3385.eurprd07.prod.outlook.com (2603:10a6:7:32::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.11; Thu, 30 Jul 2020 17:08:39 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3239.017; Thu, 30 Jul 2020 17:08:39 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" , "draft-bormann-cbor-tags-oid@ietf.org" Thread-Topic: =?utf-8?B?8J+UlCBXRyBhZG9wdGlvbiBjYWxsIG9uIGRyYWZ0LWJvcm1hbm4tY2Jvci10?= =?utf-8?Q?ags-oid-07?= Thread-Index: AQHWWswmyp4Atl2Zsk+Vmry3ilT2SqkglA+A Date: Thu, 30 Jul 2020 17:08:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [79.12.182.121] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 90ba7c05-f0a5-4a08-589f-08d834ab3418 x-ms-traffictypediagnostic: HE1PR07MB3385: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: imGcP2P8KfygkJ35ERylrSwgrPjfJrBnWeLtqL65QnsnRFz0dg5ALf0Ypcpl48KQqPaHb2ts2Os0C1XtT1HXmWRnGoC4e5NvVbwY84JXw360M5Y5I2pMEMfaGb5r6pEZOzuoRgJmBvjpHxygQJkG3+/R19ZROrIYeP+GmewBu8iZB6cZ/ajn8q+n8nqSjWAFq3zxFZiZtYfMrMT8HLLXHJ6NPInEGYFW/Jm/DjwPsbAfZCrr3cL0fwI4im2YcWuE6rz4nyoYnnUk/H4wzwLChEy1a+SC9VgSEMJCEzX7gnS6+uv7lBG1oAZdijZNULQ3gG6+3EPELWPVURg+DC8hv8VJBNehRnGDXno4ifdYRT2S/zD55WpetGSkVqZ2mDZ554PWdwO0BBBJlmREEpS3aJVoS2u2zCY5A8iNBnF2z1P2nx+ifqfXm4/vRbQw8caAAYSkJcuAwnIAdW6K0TJ7/g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(366004)(376002)(136003)(396003)(450100002)(4326008)(54906003)(6486002)(478600001)(966005)(2906002)(6512007)(316002)(4744005)(71200400001)(36756003)(6916009)(5660300002)(8936002)(2616005)(33656002)(66446008)(66476007)(66946007)(64756008)(86362001)(44832011)(186003)(26005)(91956017)(76116006)(66556008)(6506007)(379964003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: R5dN4IueRZUx8n2IonxNYO77pvMFbaNCnUveqNY83YlpEDNj2avDo671u1UWitBGa6DCye479k5LWCzHoFCwxSOWj+hY+wvyeCw7rvqBFmIaMq0EGp7gxZQh+F1vdijRd1KJR6ZYcwXVqpqrc1H6FkqGLaOAmuu6+xvM2qGr1Bw1PsuDWr0h2yYBwNEJiZkdWFNs+un9HB0Frt6twfe/cBgUYGerA4d/2z1mbNB3UyarhnWsUi8LDEjKp1y9k7/QtNwu3KRubwL3u2nIkj2j4z0fyZdMlVKBOp5GolpIUjF3QnTK38iOxFRzHXqMLMSasDrEj1WLAvq4DWdCVjN3uMi4ZCyT93iLqxgKFe6j2MTePf3WlzNZrhZe6fHxdJ+QuE97X2OrX6ffMSW58Ux0vNphQhGNO9VZ4q02dXe12ZhManOxAtcpls7c0322NKqQAbN3/m45HoPDvWA76Da/YwGV3VugthQIer4bgAxl6gj5W9jMbTYgLgwNldbE3lyM2h+dPaicPkTVP0R1MZ98de7AMDLcqkuG7MNCZeilVfXyVheAL47xRMzQ0aJV7GG4qjXxvEpo7OqhK2Q5PCx7LMTXcMo9NkgJQS9xCVtplUVJFL2ErnGKCC1KDqPmJQsIOfRLm6RK19HSexe93iYPrQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <1EE058085DD902448DA3CAFEC541B1DA@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 90ba7c05-f0a5-4a08-589f-08d834ab3418 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 17:08:38.9798 (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: IcGCqgcsfwARr6BDoRHchlqu6vHzgbcp50LDuKmztB4eTby41uR0OHjLttToornSBSwosnLcuF7Gdkh9G3OsnEoVwrBtYq2svoiOiY+3dQPHWXYgwPpeaiovQSv/sAWZ X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3385 Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WG_adoption_call_on_draft-bormann-?= =?utf-8?q?cbor-tags-oid-07?= 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, 30 Jul 2020 17:08:45 -0000 VGhpcyBjb25jbHVkZXMgdGhlIFdHIGFkb3B0aW9uIGNhbGwuIEFzIHN0YXRlZCBkdXJpbmcgSUVU RiAxMDgsIHRoZSBkb2N1bWVudCBpcyBhZG9wdGVkLiBBdXRob3JzIHBsZWFzZSByZS1zdWJtaXQg d2l0aCBkcmFmdC1pZXRmLWNib3ItLi4uIGluIHRoZSBkb2N1bWVudCdzIG5hbWUuDQoNClRoYW5r cywNCkZyYW5jZXNjYSAmIEppbQ0KDQrvu79PbiAxNS8wNy8yMDIwLCAxOToyMCwgIkZyYW5jZXNj YSBQYWxvbWJpbmkiIDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbT4gd3JvdGU6DQoN CiAgICAgQ0JPUiB3ZywNCg0KICAgIFRoaXMgc3RhcnRzIGEgV0cgYWRvcHRpb24gY2FsbCBvbiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvIGRyYWZ0LWJvcm1hbm4tY2Jvci10YWdzLW9pZC0w NywgZW5kaW5nIG9uICpTdW5kYXksIEp1bHkgMjYqLiAgUGxlYXNlIHJlcGx5IHRvIHRoaXMgdGhy ZWFkIGJ5IHN0YXRpbmcgd2hldGhlciB5b3Ugc3VwcG9ydCB0aGUgYWRvcHRpb24sIGFuZCBpbmRp Y2F0ZSB5b3VyIHdpbGxpbmduZXNzIHRvIHJldmlldyB0aGUgZHJhZnQgaWYgaXQgYmVjb21lcyBh IHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoNCiAgICBXZSB3aWxsIGFubm91bmNlIHRoZSByZXN1 bHQgb2YgdGhlIGFkb3B0aW9uIGNhbGwgYXQgb3VyIElFVEYgMTA4IG1lZXRpbmcsIE1vbmRheSwg SnVseSAyNy4NCg0KICAgIENCT1IgQ2hhaXJzDQogICAgSmltICYgRnJhbmNlc2NhDQoNCg0K From nobody Thu Jul 30 10:40:15 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 2C85C3A101E; Thu, 30 Jul 2020 10:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-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 u_Gz5i6cQjoY; Thu, 30 Jul 2020 10:40:09 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60072.outbound.protection.outlook.com [40.107.6.72]) (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 6B7203A1099; Thu, 30 Jul 2020 10:39:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ag1qIGX6z/IKXSOM+V0bXieGBM5JNX6wfFjLJ6QbRf5ooWm1If6e9XXOdzpFBSwBva6N4CA5Ki9P8ZHMtWF1SopGRUL1J9p+CWD0/4ykRjHCIBnnbAEC444btQ2PtggU0hs9iExxc7O+jL/w6PDNVCf4GZvTt4TDPryt1uDnql0cM4P3l7ohl/pSGJUj0Gv/jZov/V5HV722BsGzsTJamSKPFONBkTJcJEzbcVirTtLDCovc2TK22osQZ7jN6TbTIHuw8jiKfLl/DZknzBMkKVllZA8nB0IfDw914NIxgEOJs6sIbz91FnCqNtEW7171WUMUJC80vnge6GfZ81WaEw== 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=ZBe7cfiIQepwb4Gva+ZfBv0e/tRyBLtuQM5NVnDT2oY=; b=B18LLEkffJEu57MC9LrcEsHt6pHuiIqFE3Ua10IucLg0HhiWXO/abMAZT2A1SSSW42b4qfw2VeVKwPijYiugl0fAkRVrw+9CDE1ZckQdYIiy8fV2gg3uZlIawtW4jOvO9OcqHNH/Ex+e+Eu5S89qP5LEDELIWTafhAOFivIlMIYR7Ng/c6UIAsspQPkE1A7mD2kpE8ux1GQq7kNBsYLqrY03EeOgAWdNP2C/EnUF/ysoMZOG8HvJTsM2h1LMdNWHdSXTHw5eAvh6MrQvOmIpsr0jjmR0YPBDVLpGYprBq7al63xqv/p6CERiB5JR4gxT1QoF7NIxZMTRsr2Xklnraw== 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=ZBe7cfiIQepwb4Gva+ZfBv0e/tRyBLtuQM5NVnDT2oY=; b=jVt7ZLyfDlilgSRSdC6VgScMpJZ07rTF6LjRqevlqODtG8WbMim3osLIIxHh052LZiTF7dDVNCtxtE+tVGjIFBRTsKQhg364blOXg31j0nEADJzT02my4kLCsIdqCYNRtkuFWe7G3bPAm7EeHbypV0Q11HQxDx09Ml1rAlzzPow= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0701MB2140.eurprd07.prod.outlook.com (2603:10a6:3:2a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.10; Thu, 30 Jul 2020 17:39:47 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3239.017; Thu, 30 Jul 2020 17:39:47 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: Minutes IETF 108 Thread-Index: AQHWZphrrEqgoXyeZUmQgOTBBHfu9A== Date: Thu, 30 Jul 2020 17:39:47 +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/16.39.20071300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [79.12.182.121] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 53f6731f-b8e5-4395-097c-08d834af8de9 x-ms-traffictypediagnostic: HE1PR0701MB2140: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Es+fL1w7SIVnX040MEN/c80ARKY1wxQau2HKe5bWt/yfC1l1cpSGTwyxv+w189rz969EBw9UgYXFSXXhD/tmw7O+ZrGh0h41hZeTSeSP+sf+kmRi9mbXWvh8rbC/zEFQ5vSyfgCUu+br/I/YgIlVgrulQP9gHFSQG7WtGLoqO1AeawD5Rx/M+SsTUqDzsOSB5eDP4Jx0AOEeOK456W7cEjf3WOo39loGPvXoq4Vr3+af5PnFc5hSbwZz4gB0rhpB3Pxqn+jmezi9VpQBSdfP8YpXQ8Zq46szyB+5Clf/eUtZi2WDKMxqZhkBFJOPyIOUwP3d+/27sZZ7M7nLs8ZyMZCwyBHwrPieG21y6eg+kkmf5hYAfUpKCqUA/zjM6Yp5i11m+jbYsgfIeBLiTce3og== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(366004)(346002)(396003)(136003)(7116003)(6512007)(26005)(2616005)(44832011)(36756003)(186003)(6506007)(478600001)(966005)(6486002)(4326008)(71200400001)(86362001)(76116006)(316002)(6916009)(8676002)(91956017)(2906002)(66946007)(66476007)(33656002)(4744005)(66556008)(5660300002)(8936002)(66446008)(64756008)(450100002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Ai5fTCRHetxmof7RXe6gDdRL8vN6k1Aofolbuk52FdWIkoLmh6GvMfiRCGIafBw7mo1vFyhLGjXmL7jlRWuvnvc4RU0En6SangUgEIPnryFU1ONSmuHhIuTZS9JNg5hHo+v0FVxv2wFBQwEqEcAOK+4RIe6IKCSErrJqoZFiJbHe0zIagCU0y4MPXpFUDgpgzQoq+M+2uU9sibCHU9EqXF/BVFd/TwDRUSrYmefIIlEhCZ/6jbj+C1fRk2cdZ4J2X1HtVS27YFyXuh6MwOIAwsBCvFQmfHUlJ3/4kwA9ONtUB0YwU9pUvrTMFSk7MC/yJUpaAKo4AnN3qRP05cDbkP7YNjM5dAjI5Auag58MGdqIaZrY9+YQmS3tRckO6pu2jkz1jeCwMsLkTTCSNDb1FHV2Uvq3HOYlfePhGelOBwI+lqjxqrWfe5NUQnE1s3EvAjWH1LvfQbWqT/XvSw2r2KJBGpZcFGsw1exyxRHpLzyvBshPxZHiYkipOtHkgTZRQddkhqaxEXOlR7yQgCAet+QCE7k7Utyn9I+uj+DVVMWLyAM47q5ojfgPdQG+Hq0XqFk1FRDeMsF2kaSKYy4zoTZTln5rgQWlJfc/RboV47ZpqCPioRzVtXlyyLMkBUiY4/SChohCR0a97JlzaeZJ4w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <1F48184FD8E3F749A65D63C53868A83C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 53f6731f-b8e5-4395-097c-08d834af8de9 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 17:39:47.6796 (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: Srh6GyO73sbUeliqxFcfQ8JG+4MPsvt0hiJDlSqfnAwLNN7TSb1gU4p+yMvAIBPdumRV6VG/qhi5EaqMc7443BcjKCRHidAOY3NEaDufTXpal0yGtuugLFmxcNXnPQo7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2140 Archived-At: Subject: [Cbor] Minutes IETF 108 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, 30 Jul 2020 17:40:14 -0000 SGkgYWxsLA0KDQpUaGFuayB5b3UgZm9yIGEgdmVyeSBnb29kIGRpc2N1c3Npb24gYW5kIHByb2R1 Y3RpdmUgbWVldGluZy4gDQoNClRoZSBtaW51dGVzIGZyb20gdG9kYXkgaGF2ZSBiZWVuIHBvc3Rl ZDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMTA4L21pbnV0ZXMvbWludXRlcy0x MDgtY2Jvci0wMSANCkJpZyB0aGFua3MgdG8gb3VyIG1pbnV0ZSB0YWtlcnMgTWljaGFlbCBhbmQg SmltLg0KDQpJZiB5b3VyIGlucHV0IGhhcyBub3QgYmVlbiBjYXB0dXJlZCBjb3JyZWN0bHkgcGxl YXNlIHJlYWNoIG91dCB0byB1cy4NCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCg== From nobody Thu Jul 30 12:38:08 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 161D53A0BC9 for ; Thu, 30 Jul 2020 12:38:07 -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 jpWGczrxvCJm for ; Thu, 30 Jul 2020 12:38:05 -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 390633A0BC7 for ; Thu, 30 Jul 2020 12:38:05 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 30 Jul 2020 12:37:58 -0700 From: Jim Schaad To: Date: Thu, 30 Jul 2020 12:37:57 -0700 Message-ID: <03ec01d666a8$ef102580$cd307080$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdZmqIi/+HrHb1mgQQalyH0gm/LskQ== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] CBOR Compression 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, 30 Jul 2020 19:38:07 -0000 While thinking through some of the places that I would potentially use CBOR Compression/Dictionarying, I of course came on how I would use it with things like CoRAL. In this case I would want to be able to prefix strings, maps and arrays. By allowing the prefixing of arrays I get a goodly amount of compression for CRI values as well. This might change the entire way that we look at how we build a dictionary for CoRAL!!! Jim From nobody Thu Jul 30 13:02:08 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 47B033A0C54; Thu, 30 Jul 2020 13:01:40 -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: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159613929979.20988.16211229254749490944@ietfa.amsl.com> Date: Thu, 30 Jul 2020 13:01:39 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-09-02 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 20:01:41 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2020-09-02 from 17:00 to 18:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m8abc7d12fe6aaeb2c84fe10148a4b4f9 Meeting number: 161 827 6159 Password: h7MeKJEqj68 From nobody Thu Jul 30 13:02:12 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 B60C53A0D13; Thu, 30 Jul 2020 13:01:57 -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: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159613931769.32089.11796793148182812051@ietfa.amsl.com> Date: Thu, 30 Jul 2020 13:01:57 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-09-16 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 20:02:04 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2020-09-16 from 17:00 to 18:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m8abc7d12fe6aaeb2c84fe10148a4b4f9 Meeting number: 161 827 6159 Password: h7MeKJEqj68 From nobody Thu Jul 30 13:02:40 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 9E2693A0E99; Thu, 30 Jul 2020 13:02:31 -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: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159613935162.30625.13608373798406687070@ietfa.amsl.com> Date: Thu, 30 Jul 2020 13:02:31 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-09-30 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 20:02:38 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2020-09-30 from 17:00 to 18:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m8abc7d12fe6aaeb2c84fe10148a4b4f9 Meeting number: 161 827 6159 Password: h7MeKJEqj68 From nobody Thu Jul 30 13:03:03 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 3A87A3A0DC7; Thu, 30 Jul 2020 13:02:51 -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: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159613937121.16268.2913715143169003335@ietfa.amsl.com> Date: Thu, 30 Jul 2020 13:02:51 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-10-14 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 20:02:58 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2020-10-14 from 17:00 to 18:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m8abc7d12fe6aaeb2c84fe10148a4b4f9 Meeting number: 161 827 6159 Password: h7MeKJEqj68 From nobody Thu Jul 30 13:03:14 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 F29A93A0D4B; Thu, 30 Jul 2020 13:03: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: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159613938596.31604.15807300638761289096@ietfa.amsl.com> Date: Thu, 30 Jul 2020 13:03:05 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-10-28 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 20:03:12 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2020-10-28 from 17:00 to 18:00 Europe/Paris (16:00 to 17:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m8abc7d12fe6aaeb2c84fe10148a4b4f9 Meeting number: 161 827 6159 Password: h7MeKJEqj68 From nobody Thu Jul 30 13:03:32 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 6C6343A0F46; Thu, 30 Jul 2020 13:03:21 -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: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159613940137.32089.4647614118717671022@ietfa.amsl.com> Date: Thu, 30 Jul 2020 13:03:21 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-11-11 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 20:03:27 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2020-11-11 from 17:00 to 18:00 Europe/Paris (16:00 to 17:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m8abc7d12fe6aaeb2c84fe10148a4b4f9 Meeting number: 161 827 6159 Password: h7MeKJEqj68 From nobody Thu Jul 30 13:50: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 7FDE43A0CA0 for ; Thu, 30 Jul 2020 13:49:51 -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 GA3XjqzVmy-s for ; Thu, 30 Jul 2020 13:49:49 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2679A3A0CB9 for ; Thu, 30 Jul 2020 13:49:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B7A183004C0 for ; Thu, 30 Jul 2020 16:49:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dxgpP0UQwMmw for ; Thu, 30 Jul 2020 16:49:39 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 54D0A300B71; Thu, 30 Jul 2020 16:49:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: <159613940137.32089.4647614118717671022@ietfa.amsl.com> Date: Thu, 30 Jul 2020 16:49:40 -0400 Cc: IESG Secretary Content-Transfer-Encoding: quoted-printable Message-Id: <573A30E2-2D7A-4721-820E-EE6E8D62839C@vigilsec.com> References: <159613940137.32089.4647614118717671022@ietfa.amsl.com> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-11-11 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, 30 Jul 2020 20:49:52 -0000 This is scheduled for the week before IETF 109. The week before IETF = 108 had no virtual interims, and I think that worked well. Can we drop = this one? Russ > On Jul 30, 2020, at 4:03 PM, IESG Secretary = wrote: >=20 > The Concise Binary Object Representation Maintenance and Extensions = (cbor) WG will hold > a virtual interim meeting on 2020-11-11 from 17:00 to 18:00 = Europe/Paris (16:00 to 17:00 UTC). >=20 > Agenda: > (No agenda submitted) >=20 > Information about remote participation: > = https://ietf.webex.com/ietf/j.php?MTID=3Dm8abc7d12fe6aaeb2c84fe10148a4b4f9= >=20 > Meeting number: 161 827 6159 Password: h7MeKJEqj68 From nobody Thu Jul 30 14:26:08 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 D9EA23A0D01 for ; Thu, 30 Jul 2020 14:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 i6yaSb4Mj254 for ; Thu, 30 Jul 2020 14:26:04 -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 019E03A0D18 for ; Thu, 30 Jul 2020 14:25:41 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4BHk3S13Tjzyd9; Thu, 30 Jul 2020 23:25:40 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <03ec01d666a8$ef102580$cd307080$@augustcellars.com> Date: Thu, 30 Jul 2020 23:25:39 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 617837139.194284-889580c449275104e9482e3114aa3037 Content-Transfer-Encoding: quoted-printable Message-Id: <94E4C502-3CD3-4F36-8EDE-AA594546BCF0@tzi.org> References: <03ec01d666a8$ef102580$cd307080$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] CBOR Compression 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, 30 Jul 2020 21:26:07 -0000 On 2020-07-30, at 21:37, Jim Schaad wrote: >=20 > By allowing the prefixing of arrays I get a goodly amount > of compression for CRI values as well. Aah, right. This introduces a slight dent in the use of Tag 6 as a reference to = prefix 0 (Tag 6 with an array starts a new packed instance right now). = Simply saying =E2=80=9Ccan=E2=80=99t use Tag 6 to reference an array = prefix=E2=80=9D creates a slight complication for the compressor, who = would need to swap/rotate prefix 0 with the first non-array prefix = (possibly including a non-existent prefix if all prefixes are array = prefixes), but that seems acceptable to me. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 30 19: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 43A213A07CA for ; Thu, 30 Jul 2020 19:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 s-6r9QCxWZRT for ; Thu, 30 Jul 2020 19:40:29 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 58DE23A07C5 for ; Thu, 30 Jul 2020 19:40:28 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id 1KtzkzUzY6kPr1KyAks5P3; Fri, 31 Jul 2020 02:40:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1596163226; bh=0KKL3ko7IsJZIKLcXpDOIUOZ1tUQA0PIVaTDaXeO9dQ=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=lgQtBHuCt9tsIXkl2EzxcnXigMrs/X46wMSSYnaWqmCujhnTFV4UsnydsGaX9RrwK 8ne+kL05wtq674zinr+x50dCnAKP0BkKhiMpOJ1AQIwmIVzFsk4gzO+Zoe12aPV2Cm TPlj56djgxzlc8sCwUzU+ChySZiNdbdQkEiIBzUSmAcBWQxeC/w/+TBCY1yUFQMyB5 eQhRFjosUhPzSPnSNY5P/ktLMuXOlpRs2TXUw4s/HT3g/jFvX0bnvdlMuRDghcSYtb Ce0Vv+H7UsZAbBlHUFsGd0fnX9EtkVB1oblr21XYf4abLhO1D69BC0dYWxFfeQayVo +0sRXvZjidMGg== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-18v.sys.comcast.net with ESMTPA id 1KxgkDWE0rocI1KxhkweuQ; Fri, 31 Jul 2020 02:39:57 +0000 X-Xfinity-VMeta: sc=0.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 06V6dgcx010635 for ; Fri, 31 Jul 2020 02:39:42 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 06V6dg5R010632; Fri, 31 Jul 2020 02:39:42 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: cbor@ietf.org In-Reply-To: (cabo@tzi.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 31 Jul 2020 02:39:42 -0400 Message-ID: <873658yyq9.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [Cbor] Packing CBOR (draft-bormann-cbor-packed-01) 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, 31 Jul 2020 02:40:32 -0000 Spending more time thinking about this, and reading the -01: I'm glad to see that the Abstract pays more attention to the usages that Packed CBOR with aid. It seems that the major advantage is where the entire Packed CBOR value will be read into storage, and then individual items will be indexed out of it and utilized. Conversely, a situation where it would not help is when the entire CBOR is parsed and its values put into an internal data structure, from which they are consumed by the application. That latter is a situation where the stream parsers that others have mentioned would be useful. With selective access, there would be particular gains if only a small number of items are accessed, but it was not predictable in advance which ones they would be. Whether this is a common pattern, I don't know. It seems to be expected that implementations will not generate the unpacked structure and use that. However, to access items directly in Packed CBOR requires that the top-level array must be scanned to locate the shared items. Or at least, it must be scanned lazily as references are found that need expanding. This goes back to the expectation that the entire Packed CBOR will be directly accessible whenever an item is to be extracted, but also that the packing saves storage space, not processing time, as the entire packed astructure may need to be parsed to extract an element that is "early" in the unpacked structure. It seems to be open where a Packed CBOR can be placed. The options seem to be (1) only at the top level, (2) multiple instances are permitted (and hence, not necessarily at the top level) but not nested within each other, and (3) Packed CBORs can be nested. Another choice is whether shared prefixes and shared structures may contain references to shared things. Interestingly, if one is indexing into the structure, following shared references doesn't require a recursion stack even if shared structures may themselves contain references. But following shared prefixes does, as the final value may be composed of an arbitrary number of fragments and the first byte of the value is from the deepest-nested fragment. If shared things may contain references, what Packed CBOR are they interpreted within? If there is only one, that is the one. But if Packed CBOR can be nested, a possibility is that they are interpreted in the *outer* Packed CBOR -- that is, a references is interpreted witin the smallest Packed CBOR within whose rump the reference is contained. That has the interesting property that it eliminates circular references (and I think that ensures that expansion would always terminate), but probably isn't useful in practice. It seems natural for CBOR that Packed CBOR could be included as an item within a larger CBOR structure. That makes it easier to assemble larger structures from smaller ones, but makes parsing more complex. Though it shouldn't be too hard to write a "Packed CBOR unifier" that turns two or more Packed CBORs into one by unioning their dictionaries and renumbering all the references, then assembling the structure containg the input rumps. In regard to prefix sharing in strings, the idea of allowing the same prefix to be used by both byte and character strings is attractive but seems semantically fraught. A subtle point is that the current draft talks about concatenation but doesn't specify what it must, that the concatenation is as sequences of bytes that are (for UTF-8 strings) subsequently interpreted as characters. CBOR is careful to require that character strings always consist of a series of proper UTF-8 characters, even the components of an "indefinite" character string. But concatenating an arbitrary sequence of bytes to the beginning may or may not preserve that property. So it may be more consistent with CBOR's semantics to only allow prefixing UTF-8 strings with UTF-8 strings. And it probably needs to be stated how packing works in "indefinite" constructions. For indefinite byte strings and UTF-8 strings, presumably references are not allowed as components (although the tag-prefix-reference can be applied *to* the indefinite string). For indefinite arrays, component items can be references. For indefinite maps, component keys and values can be references, but a contained reference cannot be used to provide a shared subset of key/value pairs. I wonder if it might be better to define the Packed CBOR structure as a map: Packed-CBOR = #6.6({0:rump, 1:[*prefix], 2:[*shared]}) If I counted correctly, this format has these overhead bytes: tag.6, map.3, int.0, int.1, array.(# of prefixes), int.2, array.(# of shareds). The current format has these: tag.6, array.(# of shareds+2), array.(# of prefixes). A map usually costs 4 more bytes, but allows lots of extensibility. OTOH, I don't know if we want to allow much extensibility. Dale From nobody Thu Jul 30 23:53: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 349583A0FB8 for ; Thu, 30 Jul 2020 23:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 7DCqV40UKW7M for ; Thu, 30 Jul 2020 23:53: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 A87ED3A0FB7 for ; Thu, 30 Jul 2020 23:53:39 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4BHyfn5nCGz17pZ; Fri, 31 Jul 2020 08:53:37 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <873658yyq9.fsf@hobgoblin.ariadne.com> Date: Fri, 31 Jul 2020 08:53:37 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 617871217.01363-a5c681454e5ef131da3040e7299dbf57 Content-Transfer-Encoding: quoted-printable Message-Id: References: <873658yyq9.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Packing CBOR (draft-bormann-cbor-packed-01) 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, 31 Jul 2020 06:53:44 -0000 Hi Dale, great set of deliberation/discussion points. I=E2=80=99ll try to turn = some of them into issues on the draft once IETF is over and I have a = repo to put issues into. Let me pick just one for now: On 2020-07-31, at 08:39, Dale R. Worley wrote: >=20 >=20 > I wonder if it might be better to define the Packed CBOR structure as = a > map: >=20 > Packed-CBOR =3D #6.6({0:rump, 1:[*prefix], 2:[*shared]}) >=20 > If I counted correctly, this format has these overhead bytes: tag.6, > map.3, int.0, int.1, array.(# of prefixes), int.2, array.(# of = shareds). > The current format has these: tag.6, array.(# of shareds+2), > array.(# of prefixes). > A map usually costs 4 more bytes, but allows lots of extensibility. > OTOH, I don't know if we want to allow much extensibility. The original draft went for a 1+0-byte tag to save bytes (it still needs = to put in two array heads, one for the outer array, one for the inner = prefix array, so the total overhead for setting up packing is 3 bytes = [one tag, one container, one sub-container for prefix], as opposed to = the 7 [tag, map, 0, 1, array, 2, array] from above). (A map would also = make it indeterminate which parts arrive first.) A cheaper way to get extensibility is to use a larger number of tags to = select a specific variant; we probably would go into 1+1 or 1+2-land = with that, but could stay with a more dense encoding of each variant. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 31 00:42:01 2020 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 027963A101C; Fri, 31 Jul 2020 00:41:59 -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: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <159618131891.441.174227584289363981@ietfa.amsl.com> Date: Fri, 31 Jul 2020 00:41:59 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-tags-oid-00.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 07:41:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF. Title : Concise Binary Object Representation (CBOR) Tags for Object Identifiers Authors : Carsten Bormann Sean Leonard Filename : draft-ietf-cbor-tags-oid-00.txt Pages : 14 Date : 2020-07-31 Abstract: The Concise Binary Object Representation (CBOR, draft-ietf-cbor- 7049bis) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. The present document defines CBOR tags for object identifiers (OIDs). It is intended as the reference document for the IANA registration of the CBOR tags so defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-tags-oid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-tags-oid-00 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-tags-oid-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 31 01:15: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 D52493A108C for ; Fri, 31 Jul 2020 01:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-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 IDq9p91QBWb3 for ; Fri, 31 Jul 2020 01:15:11 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2049.outbound.protection.outlook.com [40.107.20.49]) (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 013833A108A for ; Fri, 31 Jul 2020 01:15:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lrJgjvukpba3jylMccd1HC/zDmKfUWwY7RsrVHP77ENvkrjRc++pxRqHxUKsV020+I8oUCgSBJ7k7leff73x9JWtHKnR5pbUyD7ov6oga2sjT+j9JhW/5bRrsV+ZhmQlbVONoHXZtrgOlec5oAaAXJt0f0qjCFc1B78Bu9IuZEQfdLDVInl5/aeXTHDzdD+QWmKthzy7oiam75KPZy2t7TZndQmSAZyajJCPBbG99BtmcnV8oi4fp6C5y/jP7zHT3BqQqt+3nEVbjXlKKc8Z2MUm0xoEZppnx2bfv6w8al6p9fQ2LPSnrrwwjYLEgwfJs5OAGA+XBqo3OLZ84QBJ4Q== 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=Iar5KkB7+Z1l0KnCpnVJWjQirNWXTgonc725wvc4mjU=; b=J3DLVIQjWiU/QiT0MSNGpVJfzCfpVfpo208NVz8Q64+bLjviMq3zSgPnsd4FKEwfVCk1I/2iqJKWgVO7dpmj55bnoUOF0Km5lFc+wp8MP3YomSj4pt/2Wjg5jtMe5ULkQ+Pp9p9SueesV7gVPJ0733fmv07oTgie52N82ZQ25LRAW2kmt7aWo3sllxYWRQsV0Se13oHdkSavYmHlp4gf5kKN/ckoKLh03Bwf6aNV+4pnEGrLk2UpAHBNnUTw/Zr90M1XxR7Y33qNri0Pxa/EGc7lJL60EcSi6SKuwAQ0VHxo5XGn4j6yqfn/mfmoN0uiiix1vbY5uaskEpN0Dawt8A== 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=Iar5KkB7+Z1l0KnCpnVJWjQirNWXTgonc725wvc4mjU=; b=uWV4koFeGhsphxUs4yFbpoV69Ak0edCeThn1cZ3PNeqVJraIjbOiXgOnDoI6+F/qCSUE8r3DRl8WjIXshUvnb6e6Wwt68izCidYCwVX5zSxMnIylTOsK7noMjZo5hFnOzLZO7qGIZVdHGc6n1fPoegBt+ZhiO4qWDzEzzb2i89k= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0701MB2331.eurprd07.prod.outlook.com (2603:10a6:3:73::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Fri, 31 Jul 2020 08:15:08 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3239.020; Fri, 31 Jul 2020 08:15:07 +0000 From: Francesca Palombini To: Russ Housley , "cbor@ietf.org" Thread-Topic: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-11-11 Thread-Index: AQHWZq0JbSbXp/aRcUyGvgU6szKCAKkgmIkAgADhCQA= Date: Fri, 31 Jul 2020 08:15:07 +0000 Message-ID: References: <159613940137.32089.4647614118717671022@ietfa.amsl.com> <573A30E2-2D7A-4721-820E-EE6E8D62839C@vigilsec.com> In-Reply-To: <573A30E2-2D7A-4721-820E-EE6E8D62839C@vigilsec.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [79.12.182.121] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 64729348-5ebf-449b-3768-08d83529d665 x-ms-traffictypediagnostic: HE1PR0701MB2331: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QSUyXnSFFBxgYMPTVtiCBzF8+6AhHXxnWcY9j5TuXPNlZ3oKguxwRS78kQ3icI36cAyCGNnQpW6MGMKUE+69ARC8AAAiCvjL7Gjf7Gh0gsAegl2DZcvMB1FinG1rVp4/NpsQIMKOpmvmQyuyA9G5QAVxEV6hJ/m1urbrdfbobaxnHdzVRFW8iRWs91iAbaBZFFUAdzn8nOcYFWCcKciZXQD6KfmaE1ZP7fCjkXZw95170UMS5HozO+rQnMt/GG61iis6Jtv+H2GN1vKQKW/9oFGdBqG9am58X0h0bLK0I5iOaS9uWE+pPzaJ7bLIlcS3EWFDK3m01zgIBq4sazoyXn5Ua77YEFzqZneafHjDuvwDulGwi80CF7jlF3Bx6N45dubX1UTJUn4HBN5oWdC1ww== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(346002)(39860400002)(366004)(376002)(4744005)(2616005)(4001150100001)(16799955002)(33656002)(26005)(5660300002)(53546011)(966005)(6486002)(6506007)(186003)(86362001)(478600001)(110136005)(91956017)(66446008)(64756008)(66556008)(71200400001)(66946007)(36756003)(8676002)(8936002)(76116006)(83380400001)(2906002)(44832011)(316002)(66476007)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: iJnPkOJ3VoGY3FssHKgK1vbyo18O57MoRTUjSqG+BzawHoZgZC7mGafW5qODGDPWKWNZVLQZHuAVh9DO8kCNWckxd2k5ELx3aObXs/FucgmVX1Q34si7WMJW/T/NYb6f+JCABE6y9dkPdmiwOiU3L2Vn3rKbcZIB13si4A8o3axibB9sn0Z4w9V+Db3tDWcTBSkbbH/dnXGG5f0frs1iywWlVApBhUA6ce43uYwuaPE9MmzjHbPiGDbD43nkOPAGD+N/UJbzAA24oXJOyDhm3QqWy9weU6XNmZmwQt3P6KaRx41J+LqFXwJGtISsGXh0Q5Gw1kn2MWvsmqmMy6Jow3fg0cX/F+amE+LLmT4sp8zOC6unFzh8VyVDVxRwy/SmK2YnVwY7kzBwIFPr9vzUEPjkmGc33G9l3nKCmMo3Jt4g0ifjbb3bHAl3pD9kP498BsSqK68e6K6YK5Yf2nMhEf4jtPwZZ1/XFCfuwHLxQyKkk1McHI21UhNojvaAlyQUarnE96wl23GWv8zMEb2EvmmUIvcXQC9vcLv1yaQwEQAviKvavkCnPkU3zw/QFH73v3+W3rZGK4lXQiHebE+MoA2/5DYMHkkk94MFlNBomtHkIN8/h9zGr6wmhyzLZJnHDb5mW+esK7zypKxSjW3y7A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <2A7545D9B48E0B41A826682539C67A6B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 64729348-5ebf-449b-3768-08d83529d665 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2020 08:15:07.5836 (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: g9eImHKSi6W8uSjs0vuBcXQZ0CeNRtD17ubml9S67LsPldK1bITtrDAf5nrxar7EMxM0w4aTd6YuwiSzZkEppRtK6YzsLhBdfDaxQV6iRUtnHxc9s4dyLZ/DLoB7A2Cw X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2331 Archived-At: Subject: Re: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-11-11 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, 31 Jul 2020 08:15:15 -0000 SGkgUnVzcywNCg0KV2Ugd2lsbCBtb3N0IGxpa2VseSBlbmQgdXAgY2FuY2VsbGluZyB0aGlzIG1l ZXRpbmcsIGlmIGFsbCBnb2VzIGFzIHBsYW5uZWQuIFdlIGhhdmUgcmVhbGl6ZWQgdGhhdCBjYW5j ZWxsaW5nIHRoZSBtZWV0aW5nIGlzIG11Y2ggc2ltcGxlciB0aGFuIHJlcXVlc3RpbmcgYSBuZXcg b25lIDopDQoNCkZyYW5jZXNjYQ0KDQrvu79PbiAzMC8wNy8yMDIwLCAyMjo1MCwgIkNCT1Igb24g YmVoYWxmIG9mIFJ1c3MgSG91c2xleSIgPGNib3ItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2YgaG91c2xleUB2aWdpbHNlYy5jb20+IHdyb3RlOg0KDQogICAgVGhpcyBpcyBzY2hlZHVsZWQg Zm9yIHRoZSB3ZWVrIGJlZm9yZSBJRVRGIDEwOS4gIFRoZSB3ZWVrIGJlZm9yZSBJRVRGIDEwOCBo YWQgbm8gdmlydHVhbCBpbnRlcmltcywgYW5kIEkgdGhpbmsgdGhhdCB3b3JrZWQgd2VsbC4gIENh biB3ZSBkcm9wIHRoaXMgb25lPw0KDQogICAgUnVzcw0KDQogICAgPiBPbiBKdWwgMzAsIDIwMjAs IGF0IDQ6MDMgUE0sIElFU0cgU2VjcmV0YXJ5IDxpZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4gd3Jv dGU6DQogICAgPiANCiAgICA+IFRoZSBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRp b24gTWFpbnRlbmFuY2UgYW5kIEV4dGVuc2lvbnMgKGNib3IpIFdHIHdpbGwgaG9sZA0KICAgID4g YSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBvbiAyMDIwLTExLTExIGZyb20gMTc6MDAgdG8gMTg6 MDAgRXVyb3BlL1BhcmlzICgxNjowMCB0byAxNzowMCBVVEMpLg0KICAgID4gDQogICAgPiBBZ2Vu ZGE6DQogICAgPiAoTm8gYWdlbmRhIHN1Ym1pdHRlZCkNCiAgICA+IA0KICAgID4gSW5mb3JtYXRp b24gYWJvdXQgcmVtb3RlIHBhcnRpY2lwYXRpb246DQogICAgPiBodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYvai5waHA/TVRJRD1tOGFiYzdkMTJmZTZhYWViMmM4NGZlMTAxNDhhNGI0ZjkNCiAg ICA+IA0KICAgID4gTWVldGluZyBudW1iZXI6IDE2MSA4MjcgNjE1OSBQYXNzd29yZDogaDdNZUtK RXFqNjgNCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgQ0JPUiBtYWlsaW5nIGxpc3QNCiAgICBDQk9SQGlldGYub3JnDQogICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYm9yDQoNCg== From nobody Fri Jul 31 10:34: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 ECC9F3A0BD5 for ; Fri, 31 Jul 2020 10:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 mBQWXGoTd803 for ; Fri, 31 Jul 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 A73BF3A0BD1 for ; Fri, 31 Jul 2020 10:34:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 23A4C389AE; Fri, 31 Jul 2020 13:13:26 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nTrF8ZF8a9ge; Fri, 31 Jul 2020 13:13:20 -0400 (EDT) Received: from sandelman.ca (unknown [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E8B6038998; Fri, 31 Jul 2020 13:13:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 70D88319; Fri, 31 Jul 2020 13:33:34 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , Kio Smallwood , cbor@ietf.org, Brendan Moran In-Reply-To: References: <25163.1596045376@localhost> <0A0FEABF-ADF2-4342-9AC3-42F768F14CCF@mothers-arms.co.uk> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] "ordered hash" 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, 31 Jul 2020 17:34:14 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > By using the exact structure of a map (except that the array head will > have double the argument that the map head has), we can save 1 byte p= er > k/v pair (=E2=80=9Cflattened alist=E2=80=9D): > FAList =3D [* (K, V)] > So [[=E2=80=9Ca=E2=80=9D, 1], [=E2=80=9Cb=E2=80=9D, 2]] becomes [=E2= =80=9Ca=E2=80=9D, 1, =E2=80=9Cb=E2=80=9D, 2] > I=E2=80=99m not sure which of these MCR was inquiring on. The first = is > definitely an alist, and there is no need for a new term. The second > can be called an ordered multimap, but there are other structures that > also deserve this name. I am definitely referring to this. "flattened alist" is a new term to me, and I'm mostly happen with this term. I am unclear what the "second one" is. I think that: Alist: [[=E2=80=9Ca=E2=80=9D, 1], [=E2=80=9Cb=E2=80=9D, 2]] flatened alist: [=E2=80=9Ca=E2=80=9D, 1, =E2=80=9Cb=E2=80=9D, 2] > OMList =3D [* (K, [2* V] / V)] > So [[=E2=80=9Caaa=E2=80=9D, 1], [=E2=80=9Caaa=E2=80=9D, 2], [=E2=80= =9Cbbb=E2=80=9D, 3]] becomes [=E2=80=9Caaa=E2=80=9D, [1, 2], =E2=80=9Cbbb= =E2=80=9D, 3] It's an optimization which is not preserve the order. That is: [[=E2=80=9Caaa=E2=80=9D, 1], [=E2=80=9Caaa=E2=80=9D, 2], [=E2=80=9Cbbb= =E2=80=9D, 3]] vs:[[=E2=80=9Caaa=E2=80=9D, 1], [=E2=80=9Cbbb=E2=80=9D, 3], [=E2=80=9Caaa= =E2=80=9D, 2]] vs:[[=E2=80=9Caaa=E2=80=9D, 2], [=E2=80=9Cbbb=E2=80=9D, 3], [=E2=80=9Caaa= =E2=80=9D, 1]] I agree that a tag may be in order. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8kVe4ACgkQgItw+93Q 3WXlWQf+OuNrkyKWd7KBQRc8+TOYhsKWXPkplzTZMTDEV41xUjhtvLSRim49VQY/ ueJllwFzgsKzivpfPpYGJ8Xzunha56YNgdYiJOKjtOVuaa2nhj9n3rM+GSjMxlvI VgaNtreFLha30KNzmaEDFdxCPEAV998SuPBnlmVLDwUz31qrrLqUfL4TF+/pcarM YxdHfRqA9qsS/p2JmInopKFyE5kiTGkEr8zPGcxVKqfeVxwwv0DhxgG3i/exWWQE mKFrbG2zIkl8G2UNRyQ7H76Sna92BcdEhtOmkExbnQLzmtyr3nZUBysDcqyY7SNl KRA/AGQ2JKOucVKsIhhqAci9N+QibA== =vdY8 -----END PGP SIGNATURE----- --=-=-=--