From nobody Mon May 4 08: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 424F23A0AE4 for ; Mon, 4 May 2020 08:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 UFo0ugwV-B8A for ; Mon, 4 May 2020 08: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 7E85C3A0AD8 for ; Mon, 4 May 2020 08:31:23 -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, 4 May 2020 08:31:17 -0700 From: Jim Schaad To: Date: Mon, 4 May 2020 08:31:15 -0700 Message-ID: <027701d62229$0e606450$2b212cf0$@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: AdYiKLSynenJsl8QRCyllFZ/pFLm/g== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Decoding two-byte simple values X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 15:31:25 -0000 The document says that an encoder MUST NOT encode simple values below 24 as a two byte sequence. The document is silent on the decode, but the tests in appendix G list some examples that are encoded this way. Question: Should this be tagged as a decode error? Jim From nobody Mon May 4 08:36: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 414B83A0AFD for ; Mon, 4 May 2020 08:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 2l17fYtEAyOa for ; Mon, 4 May 2020 08:36:38 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 D6A563A0AF8 for ; Mon, 4 May 2020 08:36:29 -0700 (PDT) IronPort-SDR: KEEjxHIqmXJCSu/SpSVn5pmfVXmjeAaCXy8UzDH4M9IQcv+bur+c0S4hAxQQB0DeCzUtE7HT79 Zs0m4mhgdYZg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 May 2020 08:36:27 -0700 IronPort-SDR: KPI8ihE0kQEzPllR4QLpqCdUV9VRTn5xazRmrdrDGh5DtF3U1reMywtNeq1APn1eM+ZHIugikc x397r2SIWNQw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,352,1583222400"; d="scan'208";a="259379332" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga003.jf.intel.com with ESMTP; 04 May 2020 08:36:19 -0700 Received: from tjmaciei-mobl1.localnet (10.254.73.205) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 4 May 2020 08:36:19 -0700 From: Thiago Macieira To: CC: Jim Schaad Date: Mon, 4 May 2020 08:36:18 -0700 Message-ID: <3239390.hC9ZXX6zrk@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <027701d62229$0e606450$2b212cf0$@augustcellars.com> References: <027701d62229$0e606450$2b212cf0$@augustcellars.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.254.73.205] Archived-At: Subject: Re: [Cbor] Decoding two-byte simple values X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 15:36:39 -0000 On Monday, 4 May 2020 08:31:15 PDT Jim Schaad wrote: > The document says that an encoder MUST NOT encode simple values below 24 as > a two byte sequence. The document is silent on the decode, but the tests in > appendix G list some examples that are encoded this way. Question: Should > this be tagged as a decode error? I do treat it as a decode error in TinyCBOR, but that check can be disabled by a non-default #define when building the code. case SimpleTypeInNextByte: #ifndef CBOR_PARSER_NO_STRICT_CHECKS if (unlikely(it->extra < 32)) { it->type = CborInvalidType; return CborErrorIllegalSimpleType; } #endif break; This is the only check that can be disabled during the normal decode. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products From nobody Mon May 4 08:38: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 2397F3A0AC8 for ; Mon, 4 May 2020 08:38: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 L2nw9QREbHB5 for ; Mon, 4 May 2020 08:38:45 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 472D03A090A for ; Mon, 4 May 2020 08:38:27 -0700 (PDT) IronPort-SDR: Bs1sb7MA2PnRxGblekVWyM0IcfIW0va8/FCvKnEVJpoaO2VYctmLJSVFX/5gOjh8OqVMMabdyz y1mTfodgkuSg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 May 2020 08:38:26 -0700 IronPort-SDR: BB+L6tQQby0/ZNn6McsJdzjbgVXZMwoxVugNKuSuk/oWAIeNRG1DI7nn2vBgQm7oK5epremfbQ dqLCo6RQcNRg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,352,1583222400"; d="scan'208";a="461055599" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga006.fm.intel.com with ESMTP; 04 May 2020 08:38:26 -0700 Received: from tjmaciei-mobl1.localnet (10.254.73.205) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 4 May 2020 08:38:26 -0700 From: Thiago Macieira To: Date: Mon, 4 May 2020 08:38:25 -0700 Message-ID: <4560387.VjUl3CmK8F@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <3239390.hC9ZXX6zrk@tjmaciei-mobl1> References: <027701d62229$0e606450$2b212cf0$@augustcellars.com> <3239390.hC9ZXX6zrk@tjmaciei-mobl1> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.254.73.205] Archived-At: Subject: Re: [Cbor] Decoding two-byte simple values X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 15:38:46 -0000 On Monday, 4 May 2020 08:36:18 PDT Thiago Macieira wrote: > if (unlikely(it->extra < 32)) { And clearly this should be 24, not 32... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products From nobody Mon May 4 10:15: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 773983A0DC0 for ; Mon, 4 May 2020 10:15: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 ZHGUdlJg5Vg4 for ; Mon, 4 May 2020 10:15: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 63C6C3A0E88 for ; Mon, 4 May 2020 10:15:11 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49G8cX4vGmzyVj; Mon, 4 May 2020 19:15:08 +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: <4560387.VjUl3CmK8F@tjmaciei-mobl1> Date: Mon, 4 May 2020 19:15:08 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 610305308.1406519-f5570517dd9317124026b83ca9fcf138 Content-Transfer-Encoding: quoted-printable Message-Id: <41A19121-CBD1-4C46-B743-BF8824C9668F@tzi.org> References: <027701d62229$0e606450$2b212cf0$@augustcellars.com> <3239390.hC9ZXX6zrk@tjmaciei-mobl1> <4560387.VjUl3CmK8F@tjmaciei-mobl1> To: Thiago Macieira X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Decoding two-byte simple values X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 17:15:37 -0000 Hi Thiago, On 2020-05-04, at 17:38, Thiago Macieira = wrote: >=20 > On Monday, 4 May 2020 08:36:18 PDT Thiago Macieira wrote: >> if (unlikely(it->extra < 32)) { >=20 > And clearly this should be 24, not 32... No, actually 32. (We goofed: =C2=BB (To minimize confusion, only the values 32 to 255 are = used.) =C2=AB Yeah right. =E2=80=9CMinimize confusion=E2=80=9D.) Section 3.3 in the editorial revision makes some of this a bit more = clear: Simple values with a two-byte encoding and a second byte of 0..31 are = not well-formed. See also the pseudocode, which now tests for that [2]: case 7: if (ai =3D=3D 24 && val < 32) fail(); // bad simple And the examples appendix is updated as well [3]. Please send in [4] any comments on this editorial revision very, very = soon=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten [1]: = https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#rfc.section= .3.3 [2]: = https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#rfc.appendi= x.C [3]: = https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#rfc.appendi= x.A [4]: https://github.com/cbor-wg/CBORbis/issues From nobody Mon May 4 14:15: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 0BC0A3A109C; Mon, 4 May 2020 14:15:40 -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 rg7OxiYdhgB6; Mon, 4 May 2020 14:15: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 D83DE3A10AA; Mon, 4 May 2020 14:15:36 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49GFxx6k33zyyy; Mon, 4 May 2020 23:15:33 +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, 4 May 2020 23:15:33 +0200 Cc: "cbor@ietf.org" , "cbor-chairs@ietf.org" X-Mao-Original-Outgoing-Id: 610319733.37696-b3f56ff9a052b62ac4ad6ea7ded5930f Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Francesca Palombini X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-jo?= =?utf-8?q?nes-cbor-date-tag?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 21:15:41 -0000 Hi Francesca, just making sure to express explicitly that I=E2=80=99m still part of = the in-room consensus to adopt this draft as a WG document. Gr=C3=BC=C3=9Fe, Carsten > On 2020-04-23, at 11:10, Francesca Palombini = wrote: >=20 > At the last interim meeting, we had in-room consensus to adopt = https://tools.ietf.org/html/draft-jones-cbor-date-tag-01. >=20 > This is a 2 weeks confirmation call for adopting this draft as a CBOR = working group item, ending 2020-05-06.=20 >=20 > If you do not agree with the in-room consensus to adopt this as a WG = document, please speak up now. If you agree with adopting this document, = you can also tell us. >=20 > CBOR Chairs > Francesca and Jim >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Tue May 5 03:21:59 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849D63A162C; Tue, 5 May 2020 03:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 rOX6GFZi6qbY; Tue, 5 May 2020 03:21:53 -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 101513A162F; Tue, 5 May 2020 03:21:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FfBACkPbFe/xoHYZlmGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBR4IqbgNVLyoKhBmQYwglm1MLCwEBAQEBAQEBAQY?= =?us-ascii?q?BARgLCgIEAQEChEICggYkOBMCEAEBBgEBAQEBBQQCAmmFVgyDVH4BAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBFgJDVRIBAR4BAQEDAQEbBg8BBTYLEAkCDgoCAiYCAic?= =?us-ascii?q?gEAYNAQUCAQGDIgGCewULln6beYEyhD0CgRGDdoE6BoEOKoxED4FMP4ERJww?= =?us-ascii?q?Dglo+gmcBAQIBhHSCYASRRaEMB4FLgQB/BIcVj3gjgluIYYRPBY0QkBeJVJN?= =?us-ascii?q?IAgQCCQIVgWkjgVZNJE+CaVAYDZlIhURyAgE0AgYBBwEBAwkBe5A6AYEPAQE?= X-IPAS-Result: =?us-ascii?q?A2FfBACkPbFe/xoHYZlmGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBR4IqbgNVLyoKhBmQYwglm1MLCwEBAQEBAQEBAQYBARgLCgIEAQECh?= =?us-ascii?q?EICggYkOBMCEAEBBgEBAQEBBQQCAmmFVgyDVH4BAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBFgJDVRIBAR4BAQEDAQEbBg8BBTYLEAkCDgoCAiYCAicgEAYNAQUCAQGDI?= =?us-ascii?q?gGCewULln6beYEyhD0CgRGDdoE6BoEOKoxED4FMP4ERJwwDglo+gmcBAQIBh?= =?us-ascii?q?HSCYASRRaEMB4FLgQB/BIcVj3gjgluIYYRPBY0QkBeJVJNIAgQCCQIVgWkjg?= =?us-ascii?q?VZNJE+CaVAYDZlIhURyAgE0AgYBBwEBAwkBe5A6AYEPAQE?= X-IronPort-AV: E=Sophos;i="5.73,354,1583190000"; d="scan'208";a="21659872" Received: from mail-mtas26.fraunhofer.de ([153.97.7.26]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 May 2020 12:21:47 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnAABrPbFe/1lIDI1mGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFHgipuA1QwKgqEGZBjCCWbXgsBAwEBAQE?= =?us-ascii?q?BBgEBGAsKAgQBAYREAoILJDgTAhABAQUBAQECAQUEbYVWDIVyAQEBAwEBGwY?= =?us-ascii?q?PAQU2CxAJAg4KAgImAgInIBAGDQEFAgEBgyIBgwALln6beYEyhD0CgRGDdoE?= =?us-ascii?q?6BoEOKoxED4FMP4ERJwwDglo+gmcBAQIBhHSCYASRRaEMB4FLgQB/BIcVj3g?= =?us-ascii?q?jgluIYYRPBY0QkBeJVJNIAgQCCQIVgWkigVZNJE+CaVAYDZlIhURBMQIBNAI?= =?us-ascii?q?GAQcBAQMJAXuQOgGBDwEB?= X-IronPort-AV: E=Sophos;i="5.73,354,1583190000"; d="scan'208";a="112910208" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaS26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 May 2020 12:21:45 +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 045ALhjD028059 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Tue, 5 May 2020 12:21:44 +0200 Received: from [192.168.16.50] (79.234.123.239) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 5 May 2020 12:21:38 +0200 To: Carsten Bormann , Francesca Palombini CC: "cbor@ietf.org" , "cbor-chairs@ietf.org" References: From: Henk Birkholz Message-ID: <7075cf11-08c2-6234-bb77-c566f1879b2f@sit.fraunhofer.de> Date: Tue, 5 May 2020 12:21:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.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.234.123.239] Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-jo?= =?utf-8?q?nes-cbor-date-tag?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 10:21:58 -0000 I 2nd the adoption, the I-D is straight forward, does not seem to be controversial to me, and there is the entanglement with ISO that should drive us to move this forward. Viele Grüße, Henk On 04.05.20 23:15, Carsten Bormann wrote: > Hi Francesca, > > just making sure to express explicitly that I’m still part of the in-room consensus to adopt this draft as a WG document. > > Grüße, Carsten > > >> On 2020-04-23, at 11:10, Francesca Palombini wrote: >> >> At the last interim meeting, we had in-room consensus to adopt https://tools.ietf.org/html/draft-jones-cbor-date-tag-01. >> >> This is a 2 weeks confirmation call for adopting this draft as a CBOR working group item, ending 2020-05-06. >> >> If you do not agree with the in-room consensus to adopt this as a WG document, please speak up now. If you agree with adopting this document, you can also tell us. >> >> CBOR Chairs >> Francesca and Jim >> >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > From nobody Tue May 5 10:21:10 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 AED6A3A0A2E; Tue, 5 May 2020 10:21:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158869926156.25534.3425369671471607595@ietfa.amsl.com> Date: Tue, 05 May 2020 10:21:01 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-05-06 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, 05 May 2020 17:21:02 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2020-05-06 from 17:00 to 18:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: CBOR WG Meeting - Interim 20-08 Wednesday, May 6, 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 Etherpad: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-cbor-08 Agenda: * Date and time tag document : Chairs https://tools.ietf.org/html/draft-jones-cbor-date-tag-01 - WG adoption call result * CBOR specification status : Carsten https://tools.ietf.org/html/draft-ietf-cbor-7049bis-13 Summary from last meeting: - Implementers review status - Next submission by the end of the April, then ready to ship * 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 May 5 14:38: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 3DFF93A0BB0 for ; Tue, 5 May 2020 14:37:59 -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, HTML_MESSAGE=0.001, 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 RBEGMkYLgqgi for ; Tue, 5 May 2020 14:37:57 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2045.outbound.protection.outlook.com [40.107.21.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09EFB3A0BAC for ; Tue, 5 May 2020 14:37:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QvB6PwBcOE1GenPSzZZGSVCsnbteNt0iqROQOTgwu/ZTsq658St3qD3HvqHbP39mWd7z9KSZjyPwaJhwfHT8K7BO8V39+YgLALAKi+6k5APjTb8yNz6QBzEy2+iB7S/HMEmtenG1Am2bxtyXV7kj57L9gnPm1gIu7ioWipeDLLoIubK/ZG7RcdmJH3+vdG1N6i2YwJteFxOM5ftts4qBdrHSyf+Ewesp2eMa9GEfVAbOi5a3nDpf2ejyEIyGMwwY9vYXv97ptSd80tKcTzCYfsbcSspXD8fWVIMIkImeT96DUXFMKPYv21NFNi4yBcsoqRkISRRi/RIXsmX5gg/I7w== 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=S7lR7ilhNaOz582NHXhvy3HAqdjIms06CeEx6ZkCtu0=; b=aOYhVmJjeSwPTKRfz8Z3xduOcM0fnDROEK2iPAkoWdZRANupvWLKgGDVz6vz2Mhl7YlRV7w1nsOihld4IaUfESnwaLUf02C4EvDneBlpXiRiEQqMvvKV+q6x5GFBcvQSoccRTO9h831higkTaBn3hZAda+5hUnzgPmL0oHoS03nepN2zSBQ+mVZhebFfcr7FjSlxSfNI8awdMETOS8mabNG/eCFh1+umlN/LN711Ei83u7owFZe4L4TuvBQDjjDwctmFoiunBxSt7lcHZ01kqbArE3rX0gZQvabFwkxEfsNrxjc4RRWF5+/gJMM7DV/O5Ld6ZEMuGZsOf8TI5QGcLQ== 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=S7lR7ilhNaOz582NHXhvy3HAqdjIms06CeEx6ZkCtu0=; b=uBgkROXvRRguBthe59XlwBMxi/bkZa6/8d6GpPLDRLe/r3cxNlWMesup8v2UY+7aUL5acUqDkoqOm1Ynt0R17moGUOK9j48RgwhwjKLkSxk5L6ZFPZ/g6dSByDzuwd+CSb1P48qg+eIFdTofCUIgKplzQ+xbrxgIPjZTQ91cnZo= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by AMXSPR01MB0001.eurprd07.prod.outlook.com (2603:10a6:209:9a::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.11; Tue, 5 May 2020 21:37:54 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526%6]) with mapi id 15.20.2979.025; Tue, 5 May 2020 21:37:54 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: Reminder: Survey on planning for possible online IETF meetings Thread-Index: AQHWItMI3sTRoI/sR06quN6A10+TDqiaJr6A Date: Tue, 5 May 2020 21:37:54 +0000 Message-ID: References: <158857581528.28405.17372040856513106617@ietfa.amsl.com> 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.36.20041300 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: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7bd5eff4-4e23-4b2d-9c8b-08d7f13c91fe x-ms-traffictypediagnostic: AMXSPR01MB0001: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0394259C80 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aqdidXR/lAnZFJmv5pcPwOzTyWoabPuOMYrl9xhuHouxh4mQRBLb7kPHzJ4G8oMwuk1jdIVE94xiuaVd4MxhT4jM9WAjb0LH2PUdKMfqeoMyd5BRXVMolO3EpaG9S7B7SNmIcFdYCqp9h140EGYk/+MXI0VeFvzfxj8Sj9sxx7ecMuOUGw3ZMt85Jq7+nFtFfrTsTzIaL8on9vCXkm7PSk2viqxuMwihePBCcwigGyVzOsYtHjzOV7WdGee/4Qtz6ejONgatanFekf2TXU2CaOtOZIfiA4bGBpayGMiA5WwrIp1ZJA5KHQQ0zsqZaBOTl6aQPgrnDakN6FZGuYHJc8P2GHp2BbprSCy2oJcArUMKUZOexhB9f7cM/e5EPZIh//UkVvI6dlvKUtr4UnRj/z3A9FdJYKehnxmzEZruutn4XVlpLCj+LbFRHcPwDU7C2Fh62wf6KJ9yBfRV9mCOgfGlSwz3243t2GEUm/4TLnog3NqQJQG6s/g99I+60sKtoFKVxf+L1fvswa61TmkmG6KYkZ3FEJR9P/zM25kAciD/e2FbjHLwzN6WovdoJPdyF20LTucqpNz6pEPFAeaoIVOpvwrE3CD/pqW8OHMZ5Kc= 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)(376002)(346002)(136003)(366004)(396003)(39860400002)(33430700001)(71200400001)(66476007)(66446008)(66946007)(66556008)(6916009)(44832011)(6512007)(76116006)(316002)(2616005)(5660300002)(478600001)(64756008)(36756003)(966005)(6486002)(186003)(2906002)(86362001)(8936002)(33656002)(9326002)(26005)(33440700001)(6506007)(8676002)(53546011)(166002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: MjXWfWEPn6ZTU0YrZXKh1kjbQGhiezNqy9V0JRKCiNFmc8fqXV9On5kfm2a7reeGstEHciEk3d8rOWrcv8KsuCbzlyJjMfP5HY6INheCI+BnXfnUIg1omWbpcN5SFjr95TrYgu+hG2wkrM+V9Iv2YavRB3wyvCKWUEzHMOC0eRZqj9TTl9tfTlqyhuwFr0+dffaHjCyWObkHruuZoNAYAmk/fbuvb/3ZaYvHaH0fhIL5n7piMcl3IzHIOKl7/F5/1gTm8Y8Lx4wpv03CvTY2ar6CwxVNDFvwmSVmD3yAIgwPXdvJhNmPFDeseNbv8oFGJVnY9jQz1NOJwuFmOQGuaz83gaXH2ByZl92dTHmvOnUUKQuRSDvrEJoT2gfEzQWdf+HmM/Nu+QtWGIvFOoyhi3DBTX8iv1w/aPTWWR43ie8jd85Nk8nnjtJuL2hAA1B3CPwBn2MVfFybpoeDvI2KoSHMVM+CPTlF2VFxQ1u7QnNCCdTe8yDhacwEHG4B8qgAvSCOxaqpApSEVm3HUhPhZz5cNAnQPEo1C2nAq3R/ZFFW/bMAO8upNFPLvQ3h6iOWXeHuoHKHLxFB3DLRyPYxGcedE0s69fwxKgAZ6cC2kj+S8GQJzo66LxnwVtjw3wEy0iTfFe6l/DVtHuZpy9mCHrNT0Z8axwPyF7/s4yElRvvqnUWyuzzrM71V/z5cAmAVlw7ny3v2t+g+n+o6usXok6OERjrWjleINW5KiddSlP+ErofbY1W2nS7iaGeIqa98AP+sPgHxmJWQ/RFBA86CFHlecoKBjs5uvxXir5097348y06PUixI9ZxheD4/i7Dv x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_C6F8D37FA0DF469BA73F090C0DA39043ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7bd5eff4-4e23-4b2d-9c8b-08d7f13c91fe X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2020 21:37:54.5119 (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: 7zgT7M6dXSpCpbcxliMS3XdQ4jynTNlQog8BNP9LqpzmfMu7EVTqXOk3Kidy4qPDSPvxzSzUoNwxPU/lZygV9Xh28RoNhvNbkTi5l5H+A6hQUy3/TWKBcpQyRD5PsgMb X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXSPR01MB0001 Archived-At: Subject: [Cbor] FW: Reminder: Survey on planning for possible online IETF meetings 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, 05 May 2020 21:37:59 -0000 --_000_C6F8D37FA0DF469BA73F090C0DA39043ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClBsZWFzZSB0YWtlIGEgbW9tZW50IHRvIGFuc3dlciB0aGlzIHN1cnZleSBpZiB5b3Ug cGxhbiBvbiBhdHRlbmRpbmcgZnV0dXJlIG9ubGluZSBJRVRGIG1lZXRpbmdzLg0KDQpGcmFuY2Vz Y2ENCg0KRnJvbTogV0dDaGFpcnMgPHdnY2hhaXJzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFs ZiBvZiBBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbj4NCkRhdGU6IFR1ZXNkYXksIDUg TWF5IDIwMjAgYXQgMTM6NDgNClRvOiBJRVRGIFdHIENoYWlycyA8d2djaGFpcnNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBGd2Q6IFJlbWluZGVyOiBTdXJ2ZXkgb24gcGxhbm5pbmcgZm9yIHBvc3NpYmxl IG9ubGluZSBJRVRGIG1lZXRpbmdzDQoNClBsZWFzZSBjaXJjdWxhdGUgdGhpcyB0byB5b3VyIHdv cmtpbmcgZ3JvdXAgbGlzdHMuIFRoZSBzdXJ2ZXkgZGF0YSB3aWxsIGJlIHZlcnkgaW1wb3J0YW50 IGFzIHdlIHBsYW4gZnV0dXJlIElFVEYgbWVldGluZ3MuDQoNClRoYW5rcywNCkFsaXNzYQ0KDQoN CkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQpGcm9tOiBJRVRGIEV4ZWN1dGl2ZSBEaXJlY3Rv ciA8ZXhlYy1kaXJlY3RvckBpZXRmLm9yZzxtYWlsdG86ZXhlYy1kaXJlY3RvckBpZXRmLm9yZz4+ DQpTdWJqZWN0OiBSZW1pbmRlcjogU3VydmV5IG9uIHBsYW5uaW5nIGZvciBwb3NzaWJsZSBvbmxp bmUgSUVURiBtZWV0aW5ncw0KRGF0ZTogTWF5IDQsIDIwMjAgYXQgMzowMzozNSBBTSBFRFQNClRv OiAiSUVURiBBbm5vdW5jZW1lbnQgTGlzdCIgPGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRv OmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0KUmVwbHktVG86IGlldGYxMDhwbGFubmluZ0BpZXRm Lm9yZzxtYWlsdG86aWV0ZjEwOHBsYW5uaW5nQGlldGYub3JnPg0KDQpUaGlzIGlzIGEgcmVtaW5k ZXIgdGhhdCB3ZSBuZWVkIHRoZSBJRVRGIGNvbW11bml0eSB0byBoZWxwIHVzIHBsYW4gZm9yIHRo ZSBwb3NzaWJpbGl0eSB0aGF0IG9uZSBvciBtb3JlIHVwY29taW5nIElFVEYgbWVldGluZ3MgaW4g MjAyMCBhbmQgcG9zc2libHkgMjAyMSBtYXkgbm90IGJlIGFibGUgdG8gZ28gYWhlYWQgaW4gcGVy c29uLiAgWW91IGNhbiBoZWxwIHVzIHdpdGggdGhpcyBieSBmaWxsaW5nIG91dCB0aGUgZm9sbG93 aW5nIHN1cnZleToNCg0KaHR0cHM6Ly93d3cuc3VydmV5bW9ua2V5LmNvbS9yLzUzMjhGRkoNCg0K U28gZmFyIHdlIGhhdmUgMTE0IHJlc3BvbnNlcyBhbmQgd2Ugd291bGQgaWRlYWxseSBsaWtlIDUw MCBvciBtb3JlLg0KDQpUaGUgc3VydmV5IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgcGFnZXMgYW5k IHdpbGwgdGFrZSAxNS0yMCBtaW51dGVzIHRvIGNvbXBsZXRlOg0KDQoxLiBXZWxjb21lDQoyLiBP bmxpbmUgSUVURiAxMDcgYW5kIHRoZSBzdWJzZXF1ZW50IHZpcnR1YWwgaW50ZXJpbXMNCjMuIFJl cGxhY2luZyBhIGNhbmNlbGxlZCBpbi1wZXJzb24gbWVldGluZw0KNC4gT25saW5lIG1lZXRpbmcg Zm9ybWF0IGFuZCB0aW1lem9uZQ0KNS4gUmVwbGljYXRpbmcgaHVtbWluZw0KNi4gUmVwbGljYXRp bmcgdGhlIGhhbGx3YXkgZW52aXJvbm1lbnQNCjcuIEZlZXMNCjguIFRoYW5rcyBhbmQgYW55dGhp bmcgZWxzZQ0KDQpXZSBydW4gdGhlIHN1cnZleSBpbiBhbm9ueW1vdXMgbW9kZSB3aGljaCBtZWFu cyB0aGF0IHdlIG9ubHkgc2VlIGRhdGEgdGhhdCB5b3UgZXhwbGljaXRseSBwcm92aWRlLg0KDQpU aGFuayB5b3UgaW4gYWR2YW5jZSBmb3IgeW91ciBoZWxwLg0KDQotLQ0KQWxpc3NhIENvb3Blciwg SUVURiBDaGFpcg0KSmF5IERhbGV5LCBJRVRGIEV4ZWN1dGl2ZSBEaXJlY3Rvcg0KQ29saW4gUGVy a2lucywgSVJURiBDaGFpcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KSUVURi1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCklFVEYtQW5ub3VuY2VAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zi1hbm5vdW5j ZQ0KDQo= --_000_C6F8D37FA0DF469BA73F090C0DA39043ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <72332D52730B2740BEB2790433ED580A@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJIZWx2ZXRp Y2EgTmV1ZSI7DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlBsZWFzZSB0YWtlIGEgbW9tZW50 IHRvIGFuc3dlciB0aGlzIHN1cnZleSBpZiB5b3UgcGxhbiBvbiBhdHRlbmRpbmcgZnV0dXJlIG9u bGluZSBJRVRGIG1lZXRpbmdzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5GcmFuY2VzY2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+V0dDaGFpcnMg Jmx0O3dnY2hhaXJzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBBbGlzc2EgQ29v cGVyICZsdDthbGlzc2FAY29vcGVydy5pbiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwg NSBNYXkgMjAyMCBhdCAxMzo0ODxicj4NCjxiPlRvOiA8L2I+SUVURiBXRyBDaGFpcnMgJmx0O3dn Y2hhaXJzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5Gd2Q6IFJlbWluZGVyOiBT dXJ2ZXkgb24gcGxhbm5pbmcgZm9yIHBvc3NpYmxlIG9ubGluZSBJRVRGIG1lZXRpbmdzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlBsZWFzZSBjaXJj dWxhdGUgdGhpcyB0byB5b3VyIHdvcmtpbmcgZ3JvdXAgbGlzdHMuIFRoZSBzdXJ2ZXkgZGF0YSB3 aWxsIGJlIHZlcnkgaW1wb3J0YW50IGFzIHdlIHBsYW4gZnV0dXJlIElFVEYgbWVldGluZ3MuDQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoYW5rcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPkFsaXNzYTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Eg TmV1ZSZxdW90OyI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5JRVRGIEV4ZWN1dGl2ZSBEaXJlY3RvciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmV4ZWMtZGlyZWN0b3JAaWV0Zi5vcmciPmV4ZWMtZGlyZWN0b3JAaWV0Zi5v cmc8L2E+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+U3ViamVjdDogUmVtaW5kZXI6 IFN1cnZleSBvbiBwbGFubmluZyBmb3IgcG9zc2libGUgb25saW5lIElFVEYgbWVldGluZ3M8L3Nw YW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5EYXRlOg0KPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPk1heSA0LCAyMDIwIGF0 IDM6MDM6MzUgQU0gRURUPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5UbzoNCjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij4m cXVvdDtJRVRGIEFubm91bmNlbWVudCBMaXN0JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aWV0 Zi1hbm5vdW5jZUBpZXRmLm9yZyI+aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5SZXBseS1UbzoNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86 aWV0ZjEwOHBsYW5uaW5nQGlldGYub3JnIj5pZXRmMTA4cGxhbm5pbmdAaWV0Zi5vcmc8L2E+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhpcyBpcyBh IHJlbWluZGVyIHRoYXQgd2UgbmVlZCB0aGUgSUVURiBjb21tdW5pdHkgdG8gaGVscCB1cyBwbGFu IGZvciB0aGUgcG9zc2liaWxpdHkgdGhhdCBvbmUgb3IgbW9yZSB1cGNvbWluZyBJRVRGIG1lZXRp bmdzIGluIDIwMjAgYW5kIHBvc3NpYmx5IDIwMjEgbWF5IG5vdCBiZSBhYmxlIHRvIGdvIGFoZWFk IGluIHBlcnNvbi4gJm5ic3A7WW91IGNhbiBoZWxwIHVzDQogd2l0aCB0aGlzIGJ5IGZpbGxpbmcg b3V0IHRoZSBmb2xsb3dpbmcgc3VydmV5OiA8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5zdXJ2ZXltb25rZXkuY29tL3IvNTMyOEZGSiI+aHR0cHM6Ly93d3cuc3VydmV5bW9ua2V5LmNv bS9yLzUzMjhGRko8L2E+PGJyPg0KPGJyPg0KU28gZmFyIHdlIGhhdmUgMTE0IHJlc3BvbnNlcyBh bmQgd2Ugd291bGQgaWRlYWxseSBsaWtlIDUwMCBvciBtb3JlLjxicj4NCjxicj4NClRoZSBzdXJ2 ZXkgY29udGFpbnMgdGhlIGZvbGxvd2luZyBwYWdlcyBhbmQgd2lsbCB0YWtlIDE1LTIwIG1pbnV0 ZXMgdG8gY29tcGxldGU6PGJyPg0KPGJyPg0KMS4gV2VsY29tZTxicj4NCjIuIE9ubGluZSBJRVRG IDEwNyBhbmQgdGhlIHN1YnNlcXVlbnQgdmlydHVhbCBpbnRlcmltczxicj4NCjMuIFJlcGxhY2lu ZyBhIGNhbmNlbGxlZCBpbi1wZXJzb24gbWVldGluZzxicj4NCjQuIE9ubGluZSBtZWV0aW5nIGZv cm1hdCBhbmQgdGltZXpvbmU8YnI+DQo1LiBSZXBsaWNhdGluZyBodW1taW5nPGJyPg0KNi4gUmVw bGljYXRpbmcgdGhlIGhhbGx3YXkgZW52aXJvbm1lbnQ8YnI+DQo3LiBGZWVzPGJyPg0KOC4gVGhh bmtzIGFuZCBhbnl0aGluZyBlbHNlPGJyPg0KPGJyPg0KV2UgcnVuIHRoZSBzdXJ2ZXkgaW4gYW5v bnltb3VzIG1vZGUgd2hpY2ggbWVhbnMgdGhhdCB3ZSBvbmx5IHNlZSBkYXRhIHRoYXQgeW91IGV4 cGxpY2l0bHkgcHJvdmlkZS48YnI+DQo8YnI+DQpUaGFuayB5b3UgaW4gYWR2YW5jZSBmb3IgeW91 ciBoZWxwLjxicj4NCjxicj4NCi0tIDxicj4NCkFsaXNzYSBDb29wZXIsIElFVEYgQ2hhaXI8YnI+ DQpKYXkgRGFsZXksIElFVEYgRXhlY3V0aXZlIERpcmVjdG9yPGJyPg0KQ29saW4gUGVya2lucywg SVJURiBDaGFpcjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KSUVURi1Bbm5vdW5jZSBtYWlsaW5nIGxpc3Q8YnI+DQpJRVRGLUFu bm91bmNlQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZXRmLWFubm91bmNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_C6F8D37FA0DF469BA73F090C0DA39043ericssoncom_-- From nobody Wed May 6 08:32: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 4C9AD3A0B2E for ; Wed, 6 May 2020 08:32: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 NoBMAHEB2L9d for ; Wed, 6 May 2020 08:32:41 -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 D07323A0B0B for ; Wed, 6 May 2020 08:32:40 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5B6A03818F for ; Wed, 6 May 2020 11:30:40 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3322D73B for ; Wed, 6 May 2020 11:32:39 -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] RFC7049bis processing of unknown tags 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, 06 May 2020 15:32:43 -0000 --=-=-= Content-Type: text/plain After discussion about #176/#181 I submitted #182: https://github.com/cbor-wg/CBORbis/issues/182 RFC7049 specified that CBOR tags which were not recognized should be ignored. RFC7049bis wishes to change this behaviour such that unknown tags would not be ignored, but would at least, be presented to the application for further determination. This is a change that would render existing CBOR parsers instantly invalid. --- The suggestion is that parsers should be in RFC7049 mode by default, and applications that want RFC7049bis behaviour should initialize the parser with an option that enables it [or use a new parser with awareness]. Applications that want to make use of tags defined in RFC7049bis need to put the parser in RFC7049bis mode. --- I think that Carsten does not agree with my suggested solution, but I'm not attached to it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6y2JYACgkQgItw+93Q 3WUKXwf6A8s6OojDBYCrefYckq+ToRkiCr2Dddh+w9Ul0dNUcUHZkWXEDyGplLKQ 8K84l0+6lE7kfG1mpiejSqflBm6mBJ2r5Fja/qksfAoNNNEs+Rf/H4h8yyFMW/bP DrFWkBRYySCHaCUnAPcXlRiA3N3DX+sqOlyOUBXhjIz1oGaWahyoO92xtX3hEJjT ACE44lStqwRnz27qc8/Q5nLyG+069te19vlzaaX0bDR1uv3xCvGVdwBnvSpcarpG xfz817xUBWHfQL+MbMXO4BUjMhyI3bJXMkCI9RetZ/aejm4GgEOjMZCHNGqYtHmz TDx8eEzNYYvNKmo5jtYjFG8+tGu6wg== =2lx4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 6 08:38: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 001D23A07F9 for ; Wed, 6 May 2020 08:38:16 -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 In6-A-bHyLiE for ; Wed, 6 May 2020 08:38:11 -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 9A2393A0B3A for ; Wed, 6 May 2020 08:38:09 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49HLMg4yHDzyT3; Wed, 6 May 2020 17:38:07 +0200 (CEST) From: Carsten Bormann Content-Type: multipart/alternative; boundary="Apple-Mail=_324EF250-0DD5-4D8B-974C-F0395C059D88" X-Mao-Original-Outgoing-Id: 610472286.159918-f96bc53374e44f49e29b6f99f4027f72 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 6 May 2020 17:38:06 +0200 Message-Id: <6ACF0CA3-59C4-4CE1-9344-81B43C75BAF4@tzi.org> References: To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Cbor] Fwd: [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] 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, 06 May 2020 15:38:17 -0000 --Apple-Mail=_324EF250-0DD5-4D8B-974C-F0395C059D88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 JFYI: Interesting discussion in core/netmod about potentially needing to = represent sparse bit sets. Anything we (cbor WG) can contribute to that? Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: "Rob Wilton \(rwilton\)" > Subject: [netmod] CBOR YANG encoding of union & bits = [draft-ietf-core-yang-cbor-12] > Date: 2020-05-06 at 12:43:49 CEST > To: "core@ietf.org" , "netmod@ietf.org" = , "draft-ietf-core-yang-cbor@ietf.org" = > Archived-At: = = >=20 > Hi, >=20 > [Cross posting to Netmod for wider YANG expertise.] >=20 > I had a couple of questions on the CBOR YANG encoding of bits and = unions (based on draft-ietf-core-yang-cbor-12). Apologies if these have = already been discussed/closed in the WGLC. >=20 > 1) Regarding the encoding of the bits datatype: > [draft-ietf-core-yang-cbor-12, section 6.7] >=20 > The CBOR YANG encoding of the bits datatype is defined as a byte = string encoding of a bitfield. However, my concern here is that YANG = bit positions are allowed to be up 2^32-1. >=20 > E.g. the following, pathologically bad, bits definition would seem to = have a very inefficient encoding in CBOR: >=20 > typedef alarm-state { > type bits { > bit unknown { > position 4000000000; > } > bit under-repair; > bit critical; > bit major; > bit minor; > bit warning; > bit indeterminate; > } > } >=20 >=20 > How much should we be concerned about this pathological case? Would = it be reasonable for implementations to reject bitfields larger than a = small set size (e.g. perhaps 256 bits)? >=20 > Or, if it is supported by the language then is it reasonable that = implementation SHOULD support it? In which case I think that we might = need a second encoding of bits that supports this pathological case. = Perhaps an array of 'set' bit positions, or alternatively the union = string encoding of bits could be used. >=20 >=20 > 2) Regarding the encoding of unions: >=20 > I was questioning whether the special encoding of bits type within a = union was required in CBOR [draft-ietf-core-yang-cbor-12, section 6.7]. = Am I right to presume that this is to ensure that the CBOR encoding of = unions is always at least as specific as XML? If so, this seems like a = reasonable design choice. But that leads on to these general YANG = questions: >=20 > Should the value encoding of a YANG union type behave the same way = regardless of whether the encoding is XML/JSON/CBOR? Or is it = reasonable for there to be differences in the case of conflicting = values? Perhaps this is already answered by RFC 7951 that can behave = differently from the XML encoding of unions. >=20 > Longer term, should YANG be looking for a discriminated-union type? = Or perhaps it would be sufficient for tooling to flag up potentially = ambiguous union definitions, particularly those that may be encoding = dependent. >=20 >=20 > Regards, > Rob >=20 > [As an individual contributor] >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_324EF250-0DD5-4D8B-974C-F0395C059D88 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 JFYI:= Interesting discussion in core/netmod about potentially needing to = represent sparse bit sets.
Anything we (cbor WG) can = contribute to that?

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


Begin forwarded = message:

From: = "Rob Wilton \(rwilton\)" <rwilton=3D40cisco.com@dmarc.ietf.org>
Subject: = [netmod] CBOR = YANG encoding of union & bits [draft-ietf-core-yang-cbor-12]
Date: = 2020-05-06 at 12:43:49 CEST
To: = "core@ietf.org" <core@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, "draft-ietf-core-yang-cbor@ietf.org" <draft-ietf-core-yang-cbor@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/zaAtN5l8NuXUT1u3oj= 3qy9UG_m8>

Hi,

[Cross = posting to Netmod for wider YANG expertise.]

I had a couple of questions on the CBOR YANG encoding of bits = and unions (based on draft-ietf-core-yang-cbor-12).  Apologies if = these have already been discussed/closed in the WGLC.

1) Regarding the encoding of the bits datatype:
[draft-ietf-core-yang-cbor-12, section 6.7]

The CBOR YANG encoding of the bits datatype is defined as a = byte string encoding of a bitfield.  However, my concern here is = that YANG bit positions are allowed to be up 2^32-1.

E.g. the following, pathologically bad, bits definition would = seem to have a very inefficient encoding in CBOR:

  typedef alarm-state {
=     type bits {
=       bit unknown {
=         position 4000000000;
      }
=       bit under-repair;
=       bit critical;
=       bit major;
=       bit minor;
=       bit warning;
=       bit indeterminate;
=     }
  }


How much should we be concerned about this = pathological case?  Would it be reasonable for implementations to = reject bitfields larger than a small set size (e.g. perhaps 256 = bits)?

Or, if it is supported by the = language then is it reasonable that implementation SHOULD support it? =  In which case I think that we might need a second encoding of bits = that supports this pathological case.  Perhaps an array of 'set' = bit positions, or alternatively the union string encoding of bits could = be used.


2) Regarding the = encoding of unions:

I was questioning = whether the special encoding of bits type within a union was required in = CBOR [draft-ietf-core-yang-cbor-12, section 6.7].  Am I right to = presume that this is to ensure that the CBOR encoding of unions is = always at least as specific as XML?  If so, this seems like a = reasonable design choice.  But that leads on to these general YANG = questions:

Should the value encoding of a = YANG union type behave the same way regardless of whether the encoding = is XML/JSON/CBOR?  Or is it reasonable for there to be differences = in the case of conflicting values?  Perhaps this is already = answered by RFC 7951 that can behave differently from the XML encoding = of unions.

Longer term, should YANG be = looking for a discriminated-union type?  Or perhaps it would be = sufficient for tooling to flag up potentially ambiguous union = definitions, particularly those that may be encoding dependent.


Regards,
Rob

[As an individual contributor]







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

= --Apple-Mail=_324EF250-0DD5-4D8B-974C-F0395C059D88-- From nobody Wed May 6 09:07: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 DFEAA3A0B6A for ; Wed, 6 May 2020 09:06:59 -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 Et1S3X32v9Do for ; Wed, 6 May 2020 09:06: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 632CE3A0B69 for ; Wed, 6 May 2020 09:06:40 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49HM0Z4M5RzyT3; Wed, 6 May 2020 18:06: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: <17300.1588779159@localhost> Date: Wed, 6 May 2020 18:06:37 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 610473997.474916-3a1970a50c17f5d0ab9558dc011b677e Content-Transfer-Encoding: quoted-printable Message-Id: <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> References: <17300.1588779159@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] RFC7049bis processing of unknown tags 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, 06 May 2020 16:07:00 -0000 Hi Michael, Thank you for your interjection at the CBOR interim. I think this is a good issue to roll up. On 2020-05-06, at 17:32, Michael Richardson = wrote: >=20 >=20 > After discussion about #176/#181 I submitted #182: >=20 > https://github.com/cbor-wg/CBORbis/issues/182 >=20 > RFC7049 specified that CBOR tags which were not recognized should be = ignored. That is not exactly what it says: (3.5) A decoder that comes across a tag (Section 2.4) that it does not recognize, such as a tag that was added to the IANA registry after the decoder was deployed or a tag that the decoder chose not to implement, might issue a warning, might stop processing altogether, might handle the error and present the unknown tag value together with the contained data item to the application (as is expected of generic decoders), might ignore the tag and simply present the contained data item only to the application, or take some other type of action. So there always was a choice. Note that there always was a preference to present the unknown tag to = the application, for =E2=80=9Cgeneric decoders=E2=80=9D; i.e., the = choice is more for application-specific decoders. > RFC7049bis wishes to change this behaviour such that unknown tags = would not > be ignored, but would at least, be presented to the application for = further > determination. This is a change that would render existing CBOR = parsers > instantly invalid. A change that would remove the choice is not what was intended so far, = just increased emphasis on the options: =E2=80=94 1 might issue a warning,=20 =E2=80=94 2 might stop processing altogether, =E2=80=94 3 might handle the error and present the unknown tag value = together with the contained data item to the application (as is expected of generic decoders),=20 as opposed to =E2=80=94 4 might ignore the tag and simply present the contained data item only to the application, or=20 =E2=80=94 5 take some other type of action. Generally, it is a good idea if users of a library know what they will = get, so the behavior to be expected needs to be documented. A generic = decoder that only does 3 (as is =E2=80=9Cexpected=E2=80=9D) will be the = most interoperable one. There are two pieces of text in 7049bis that may not entirely be = aligned: (3.4:) Decoders do not need to understand tags of every tag number, and tags may be of little value in applications where the implementation creating a particular CBOR data item and the implementation decoding that stream know the semantic meaning of each item in the data flow. Their primary purpose in this specification is to define common data types such as dates. A secondary purpose is to provide conversion hints when it is foreseen that the CBOR data item needs to be translated into a different format, requiring hints about the content of items. Understanding the semantics of tags is optional for a decoder; it can simply present both the tag number and the tag content to the application, without interpreting the additional semantics of the tag. But also: (7.1:) CBOR has three major extension points: [=E2=80=A6] * the "tag" space (values in major type 6). Again, only a small part of the codepoint space has been allocated, and the space is abundant (although the early numbers are more efficient than the later ones). Implementations receiving an unknown tag number can choose to simply ignore it (process just the enclosed tag content) or to process it as an unknown tag number wrapping the tag content. The IANA registry in Section 9.2 is the appropriate way to address the extensibility of this codepoint space. > The suggestion is that parsers should be in RFC7049 mode by default, But there is no RFC 7049 mode =E2=80=94 there is a choice. > and > applications that want RFC7049bis behaviour should initialize the = parser with > an option that enables it [or use a new parser with awareness]. It definitely is a good idea to either always get behavior 3, or to = provide flags that control the behavior. > Applications that want to make use of tags defined in RFC7049bis need = to put > the parser in RFC7049bis mode. RFC7049bis does not define any new tags (so far). > I think that Carsten does not agree with my suggested solution, but = I'm not > attached to it. I hope I have explained how the situation is a bit more nuanced than = might have come over in the meeting. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 6 09:17: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 C91C23A0BF1 for ; Wed, 6 May 2020 09:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, 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 3UaKA1Bra5AC for ; Wed, 6 May 2020 09:17:41 -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 71A763A0BE3 for ; Wed, 6 May 2020 09:17:41 -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 1jWMjr-0002tg-US for cbor@ietf.org; Wed, 06 May 2020 17:17:39 +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); Wed, 06 May 2020 17:17:37 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_3c0f35a54d46a08e69dd4c56c572f324" Date: Wed, 06 May 2020 17:17:37 +0100 From: Kio Smallwood To: cbor@ietf.org In-Reply-To: <6ACF0CA3-59C4-4CE1-9344-81B43C75BAF4@tzi.org> References: <6ACF0CA3-59C4-4CE1-9344-81B43C75BAF4@tzi.org> Message-ID: <269a22c2b07ee953a09b48c535b28791@mothers-arms.co.uk> X-Sender: kio@mothers-arms.co.uk User-Agent: Roundcube Webmail/1.3.11 Archived-At: Subject: Re: [Cbor] Fwd: [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] 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, 06 May 2020 16:17:44 -0000 --=_3c0f35a54d46a08e69dd4c56c572f324 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 That's an interesting problem. I would use a tagged map where the key is an integer offset in bytes from the beginning of the sparse array, and the value would be the byte(s) from that position. i.e. 2020({0: h'0107', 4000000000: h'15'}) D9 07E4 # tag(2020) A2 # map(2) 00 # unsigned(0) 42 # bytes(2) 0107 # "\x01\a" 1A EE6B2800 # unsigned(4000000000) 41 # bytes(1) 15 # "\x15" My thinking in this is that bit flags would tend to cluster together in practice. It does have one problem in that it is possible to create overlapping byte sequences. The decoder would not need to allocate much space. Cheers, Kio On 2020-05-06 16:38, Carsten Bormann wrote: > JFYI: Interesting discussion in core/netmod about potentially needing to represent sparse bit sets. > Anything we (cbor WG) can contribute to that? > > Grüße, Carsten > >> Begin forwarded message: >> From: "Rob Wilton \(rwilton\)" >> >> Subject: [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] >> >> Date: 2020-05-06 at 12:43:49 CEST >> >> To: "core@ietf.org" , "netmod@ietf.org" , "draft-ietf-core-yang-cbor@ietf.org" >> >> Archived-At: >> >> Hi, >> >> [Cross posting to Netmod for wider YANG expertise.] >> >> I had a couple of questions on the CBOR YANG encoding of bits and unions (based on draft-ietf-core-yang-cbor-12). Apologies if these have already been discussed/closed in the WGLC. >> >> 1) Regarding the encoding of the bits datatype: >> [draft-ietf-core-yang-cbor-12, section 6.7] >> >> The CBOR YANG encoding of the bits datatype is defined as a byte string encoding of a bitfield. However, my concern here is that YANG bit positions are allowed to be up 2^32-1. >> >> E.g. the following, pathologically bad, bits definition would seem to have a very inefficient encoding in CBOR: >> >> typedef alarm-state { >> type bits { >> bit unknown { >> position 4000000000; >> } >> bit under-repair; >> bit critical; >> bit major; >> bit minor; >> bit warning; >> bit indeterminate; >> } >> } >> >> How much should we be concerned about this pathological case? Would it be reasonable for implementations to reject bitfields larger than a small set size (e.g. perhaps 256 bits)? >> >> Or, if it is supported by the language then is it reasonable that implementation SHOULD support it? In which case I think that we might need a second encoding of bits that supports this pathological case. Perhaps an array of 'set' bit positions, or alternatively the union string encoding of bits could be used. >> >> 2) Regarding the encoding of unions: >> >> I was questioning whether the special encoding of bits type within a union was required in CBOR [draft-ietf-core-yang-cbor-12, section 6.7]. Am I right to presume that this is to ensure that the CBOR encoding of unions is always at least as specific as XML? If so, this seems like a reasonable design choice. But that leads on to these general YANG questions: >> >> Should the value encoding of a YANG union type behave the same way regardless of whether the encoding is XML/JSON/CBOR? Or is it reasonable for there to be differences in the case of conflicting values? Perhaps this is already answered by RFC 7951 that can behave differently from the XML encoding of unions. >> >> Longer term, should YANG be looking for a discriminated-union type? Or perhaps it would be sufficient for tooling to flag up potentially ambiguous union definitions, particularly those that may be encoding dependent. >> >> Regards, >> Rob >> >> [As an individual contributor] >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --=_3c0f35a54d46a08e69dd4c56c572f324 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

That's an interesting problem. I would use a tagged map where the key is= an integer offset in bytes from the beginning of the sparse array, and the= value would be the byte(s) from that position.

i.e.

2020({0: h'0107', 4000000000: h'15'})

D9 07E4           # ta= g(2020)
   A2        = ;     # map(2)
      00&n= bsp;         # unsigned(0)
&nb= sp;     42       &nb= sp;  # bytes(2)
         = 0107     # "\x01\a"
     = 1A EE6B2800 # unsigned(4000000000)
      41&= nbsp;         # bytes(1)
 = ;        15     = ;  # "\x15"


My thinking in this is that bit flags would tend to cluster together in = practice.

It does have one problem in that it is possible to create overlapping by= te sequences.

The decoder would not need to allocate much space.

Cheers,

Kio


On 2020-05-06 16:38, Carsten Bormann wrote:

JFYI: Interesting discussion in core/netmod about potentially need= ing to represent sparse bit sets.
Anything we (cbor WG) can contribute to that?
 
Grüße, Carsten
 

Begin forwarded message:

From: "Rob Wilton \(rwilton\)" <rwilton=3D40cisco.com@dmar= c.ietf.org>
Subject: [netmod] CBOR YANG encodin= g of union & bits [draft-ietf-core-yang-cbor-12]
<= /div>
Date: 2020-05-06 at 12:43:49 CEST

Hi,

[Cross posting to Netmod for wider YANG expertise.]

I had a couple of questions on the CBOR YANG encoding of bits and u= nions (based on draft-ietf-core-yang-cbor-12).  Apologies if these hav= e already been discussed/closed in the WGLC.

1) Regarding the en= coding of the bits datatype:
[draft-ietf-core-yang-cbor-12, section 6= =2E7]

The CBOR YANG encoding of the bits datatype is defined as = a byte string encoding of a bitfield.  However, my concern here is tha= t YANG bit positions are allowed to be up 2^32-1.

E.g. the follo= wing, pathologically bad, bits definition would seem to have a very ineffic= ient encoding in CBOR:

  typedef alarm-state {
=     type bits {
     &nb= sp;bit unknown {
        posi= tion 4000000000;
      }
 &n= bsp;    bit under-repair;
    = ;  bit critical;
      bit ma= jor;
      bit minor;
  = ;    bit warning;
     &= nbsp;bit indeterminate;
    }
  }=


How much should we be concerned about this pathological c= ase?  Would it be reasonable for implementations to reject bitfields l= arger than a small set size (e.g. perhaps 256 bits)?

Or, if it i= s supported by the language then is it reasonable that implementation SHOUL= D support it?  In which case I think that we might need a second encod= ing of bits that supports this pathological case.  Perhaps an array of= 'set' bit positions, or alternatively the union string encoding of bits co= uld be used.


2) Regarding the encoding of unions:
I was questioning whether the special encoding of bits type within a uni= on was required in CBOR [draft-ietf-core-yang-cbor-12, section 6.7].  = Am I right to presume that this is to ensure that the CBOR encoding of unio= ns is always at least as specific as XML?  If so, this seems like a re= asonable design choice.  But that leads on to these general YANG quest= ions:

Should the value encoding of a YANG union type behave the = same way regardless of whether the encoding is XML/JSON/CBOR?  Or is i= t reasonable for there to be differences in the case of conflicting values?=  Perhaps this is already answered by RFC 7951 that can behave differe= ntly from the XML encoding of unions.

Longer term, should YANG b= e looking for a discriminated-union type?  Or perhaps it would be suff= icient for tooling to flag up potentially ambiguous union definitions, part= icularly those that may be encoding dependent.


Regards,Rob

[As an individual contributor]







_______________________________________________<= br />netmod mailing list
netmod@iet= f.org
https://www.ietf.org/mailman/listinfo/netmod

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


--=_3c0f35a54d46a08e69dd4c56c572f324-- From nobody Wed May 6 11:08: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 983F13A098E; Wed, 6 May 2020 11:08:50 -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 XaYVo-GIlwpg; Wed, 6 May 2020 11:08:48 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30086.outbound.protection.outlook.com [40.107.3.86]) (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 502B23A098A; Wed, 6 May 2020 11:08:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fB/ZMYoa13EyqEkLmI7uUBp9/2m/tS9R2NpARH8YSSJOH2ilCOkJkgAGls7tbP9GhtVmXI1nT6lhEdH1C17kJKlt0ynN0vY8BvAT1uqC+XRAeyBvaKUcdxjLopaDEqvDgUCfc/hA2M8312bAmUxJR1DHkNcukS4wMCvtjcsR6JTGF3alfKiJc72shfvTEo9xdE93W7/I9aNgPFKR74Bas7P2Pqoi6TwGqlsuoRo5up5RTYKI8dMVPn4TUwMPwbW2uD3f10W0ov5Ib1heIKhTC5ffSfZBWules0m45lovoxY8OnkC85qmdD0eXDfQlmLbeBUOLJkeziOXxex81vHoAw== 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=8KSR2O1kA7NbrKnd3oTM+AHWW3HVxGOM3jxxrNlSlUw=; b=mr42z7UKuiNqvKEuMKiv0sIRRDUIDLeTd91HKs1tPM6g+vfz6E7LBFExlafVlNPCp924rDUcWAtD8LMmIiWghD0VIRFZeZgV2ZyuhyCBr+0zR5uKlrLOSPLGiZbsyu6+Q5qqKbXtY0EQt3mjCkzITcwQ47F4sPxf1YwERBtgUHyhLutXUCHxfR1j5oU79B8EO2waavQR8VJmrFbSEngouwIxr2IC66XAMLbr9LuIA8BK07uLRBJLp/XPNZcHEuVgHkKgJk0+acTdqMWsc+fnFRQ+apH/nenatdnzURLufTTVfRu2+KOuQFfXs94J0aAlRchJTDhaem+zqGSpWDyFSQ== 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=8KSR2O1kA7NbrKnd3oTM+AHWW3HVxGOM3jxxrNlSlUw=; b=TH7O2UP21OLf3hG9D9z9XoqLT3vEG6prxRi0l20ZWEKOYSFMOH9qCUswYFHKBmXV8Vpz2ux2pb7uqRZgoHWX4gl8+YJUu205B8r1QTIKlN08bchVsHN/7DuO6F8bdUBhvzX1s6meq1w3mHMaWMKaO/8TnbtRLGhHKp4iF6ksMPc= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (52.133.6.18) by HE1PR0702MB3643.eurprd07.prod.outlook.com (10.167.125.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.14; Wed, 6 May 2020 18:08:45 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526%6]) with mapi id 15.20.2979.028; Wed, 6 May 2020 18:08:45 +0000 From: Francesca Palombini To: "cbor@ietf.org" , "draft-jones-cbor-date-tag@ietf.org" Thread-Topic: =?utf-8?B?W0Nib3JdIPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBvZiBkcmFmdC1q?= =?utf-8?Q?ones-cbor-date-tag?= Thread-Index: AQHWGU8MatEIlU1iC0ynTVRcHNLC2aiYf6yAgADboICAAjZggA== Date: Wed, 6 May 2020 18:08:45 +0000 Message-ID: References: <7075cf11-08c2-6234-bb77-c566f1879b2f@sit.fraunhofer.de> In-Reply-To: <7075cf11-08c2-6234-bb77-c566f1879b2f@sit.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 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: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b9e60ea6-01f0-4dd3-fd18-08d7f1e884bb x-ms-traffictypediagnostic: HE1PR0702MB3643: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /zW+Z8Qi1pOkw2PmvJ1I4G9HeeAZtky9yHU+/+IZUCESV4XEUvFhSo+QPOfRDvbNwE/zQvvSk45k4ceDtt0Pq4qGf5ILxMOr2BwnKWyYBurFN/YqY+0FwTWmRwBElSZzLx8LyC+llkc/eHP/fvxvgBixRYcxMp/1aKOn3ta89KPxFDNq47YGB/co/0DD6f5WOgCRmjnZwdzQ3ta94s6nKfMtPqd1COU4pG+1/labWtRQ7Fd9ng3Uv30K/W1LGPxqP8b57h1cF7nmFkQnDBKh1ERFChfLGjIJJVrQC72rNl+I4eLUFCaS6MunpdBMXQDq+15neZURzAvnxOBeN++bIIwHIWrZsa2KIHoeTzALytOQY/0vhceX3hR9RnMTIuH7M6kgd2ZfPPwOka7ea7E9aJ7xXOhCDJJtbS2QoiKW8l32WHH+Zet+yLgDEXy8KHMPLihagsNYJps/xT0zver2YONRWrVViOBJsCDSvYRjGu7ndP8hVaSk3bq6QooYvqDEifGK6ZVzLBbNQlWcXCTdHlN6cHYN+TcnQHGe3tIHkkL+4zGIASaZ1uhMrvu/V7eKyG0oQuJHZ/LUBE2v19gSKP/glmOlcoLxgHLDK3445Ng= 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)(346002)(376002)(39860400002)(136003)(396003)(33430700001)(966005)(478600001)(186003)(66556008)(53546011)(64756008)(66476007)(5660300002)(36756003)(8936002)(6506007)(66946007)(71200400001)(76116006)(66446008)(33656002)(110136005)(26005)(6512007)(2616005)(316002)(44832011)(86362001)(33440700001)(6486002)(2906002)(450100002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 2AO0/5rpp81FHqllaXD/BLDhDASWSEkPUgoETrg5de+3eQdOhnA7ewSHWReI3fwzFimLCouyyOUpMKmIrRXhjoRsci0BYnoaGwEsTm1ewsX5rAMsFM0JeHK4HdkJ62y/LelVsNg5B96Xne5dAhDKt3N+tHUaVonCRNn+qAGp0YQCcNyxGhO7lwR7bMSTdLl3H6hOYkhUZDCL7k1zFmtQr5yVvlTQjCd04sax+199rA5knmM6OtvQfv3ttBA79FF3UBv7NAhjGeO57NMYb+sigu+zl0VAQCKNCn1XBkYgNO8w0LM8RDf9NiADaCdRYDGvHdwGzypIcf52+rh/JnIm/U+OHcfwF39bp597DItILhQP8UChzgscQjE2FaEFbB0fHYCWbniYMOKtfGvcpA90w519kW+1tQgf0x2TRIX1qBBBmqcG7go31teNF6Too9v55FCb+nybSecYb+18SB/LT+rikmVndfknBD3lpEfL0WFKuQD/KkEuqlpt7FcCtMeOOYlh14L2JhymUdFCqkHCGhnR4d9BCWi+g7+Apc8phXMPgM0KtftXW4A3y0WJJ1pcd3CAIb1DgXIy5X9PaZ1WokOv1/kzYtD8OhWrsYKE7wS6nXZjFrrHtTOzWxqDLv8/NDqY208+VU784z01uJ/7pc7FPHc0tFQlOzYpL9okql9AFSCpOF3H6RSMcP+dbXQ0cKZCTtzkbHV+Ej2Aj8v7FJnxSshI78+G/OYpKosF9dBaVQLxS3rFjJubtkeeHb85fEp1eJplqXwqadsFZ+be5cpjLNb40nkcj9SMqDZp5Pjw/kTSU57ZkO64LW0hcslW x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b9e60ea6-01f0-4dd3-fd18-08d7f1e884bb X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 18:08:45.6824 (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: lrvIosiazyI16RZaHe1jnwLB4tQTi6zWMbYJox1re52JleGYl8r66B7nDgXm5fwx4UXJx7M0iBqwuBJVIjE/8ujctrI3kMVRma3SjF9uLvVqGBwvvxY3IqnsZfsXIxBe X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3643 Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-jo?= =?utf-8?q?nes-cbor-date-tag?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 18:08:51 -0000 VGhpcyBjb25jbHVkZXMgdGhlIGFkb3B0aW9uIGNhbGwuICBBcyBtZW50aW9uZWQgZHVyaW5nIHRo ZSBpbnRlcmltLCBhbGwgcmVzcG9uc2Ugd2FzIHBvc2l0aXZlIHNvIHRoZSBkb2N1bWVudCBoYXMg YmVlbiBhZG9wdGVkLg0KDQpNaWtlLCBwbGVhc2UgcmUtcHVibGlzaCB1c2luZyBkcmFmdC1pZXRm LWNib3ItZGF0ZS10YWctMDAuDQoNCihBbHNvLCBwbGVhc2Ugc2VlIHRoZSBjb21tZW50IGluIHRo ZSBtYWlsaW5nIGxpc3QgZnJvbSBDYXJzdGVuLCBpZiB5b3UgaGF2ZW4ndCBhbHJlYWR5LCBhcyBu b3RlZCBkdXJpbmcgdGhlIGludGVyaW0pLg0KDQpKaW0gJiBGcmFuY2VzY2ENCg0K77u/T24gMDUv MDUvMjAyMCwgMTI6MjIsICJIZW5rIEJpcmtob2x6IiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5o b2Zlci5kZT4gd3JvdGU6DQoNCiAgICBJIDJuZCB0aGUgYWRvcHRpb24sDQoNCiAgICB0aGUgSS1E IGlzIHN0cmFpZ2h0IGZvcndhcmQsIGRvZXMgbm90IHNlZW0gdG8gYmUgY29udHJvdmVyc2lhbCB0 byBtZSwgDQogICAgYW5kIHRoZXJlIGlzIHRoZSBlbnRhbmdsZW1lbnQgd2l0aCBJU08gdGhhdCBz aG91bGQgZHJpdmUgdXMgdG8gbW92ZSB0aGlzIA0KICAgIGZvcndhcmQuDQoNCiAgICBWaWVsZSBH csO8w59lLA0KDQogICAgSGVuaw0KDQogICAgT24gMDQuMDUuMjAgMjM6MTUsIENhcnN0ZW4gQm9y bWFubiB3cm90ZToNCiAgICA+IEhpIEZyYW5jZXNjYSwNCiAgICA+IA0KICAgID4ganVzdCBtYWtp bmcgc3VyZSB0byBleHByZXNzIGV4cGxpY2l0bHkgdGhhdCBJ4oCZbSBzdGlsbCBwYXJ0IG9mIHRo ZSBpbi1yb29tIGNvbnNlbnN1cyB0byBhZG9wdCB0aGlzIGRyYWZ0IGFzIGEgV0cgZG9jdW1lbnQu DQogICAgPiANCiAgICA+IEdyw7zDn2UsIENhcnN0ZW4NCiAgICA+IA0KICAgID4gDQogICAgPj4g T24gMjAyMC0wNC0yMywgYXQgMTE6MTAsIEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5w YWxvbWJpbmk9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KICAgID4+DQog ICAgPj4gQXQgdGhlIGxhc3QgaW50ZXJpbSBtZWV0aW5nLCB3ZSBoYWQgaW4tcm9vbSBjb25zZW5z dXMgdG8gYWRvcHQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLWNib3It ZGF0ZS10YWctMDEuDQogICAgPj4NCiAgICA+PiBUaGlzIGlzIGEgMiB3ZWVrcyBjb25maXJtYXRp b24gY2FsbCBmb3IgYWRvcHRpbmcgdGhpcyBkcmFmdCBhcyBhIENCT1Igd29ya2luZyBncm91cCBp dGVtLCBlbmRpbmcgMjAyMC0wNS0wNi4NCiAgICA+Pg0KICAgID4+IElmIHlvdSBkbyBub3QgYWdy ZWUgd2l0aCB0aGUgaW4tcm9vbSBjb25zZW5zdXMgdG8gYWRvcHQgdGhpcyBhcyBhIFdHIGRvY3Vt ZW50LCBwbGVhc2Ugc3BlYWsgdXAgbm93LiBJZiB5b3UgYWdyZWUgd2l0aCBhZG9wdGluZyB0aGlz IGRvY3VtZW50LCB5b3UgY2FuIGFsc28gdGVsbCB1cy4NCiAgICA+Pg0KICAgID4+IENCT1IgQ2hh aXJzDQogICAgPj4gRnJhbmNlc2NhIGFuZCBKaW0NCiAgICA+Pg0KICAgID4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPj4gQ0JPUiBtYWlsaW5n IGxpc3QNCiAgICA+PiBDQk9SQGlldGYub3JnDQogICAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jYm9yDQogICAgPiANCiAgICA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBDQk9SIG1haWxpbmcgbGlzdA0KICAg ID4gQ0JPUkBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jYm9yDQogICAgPiANCg0K From nobody Wed May 6 11:11: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 2DB3A3A09B9 for ; Wed, 6 May 2020 11:11:23 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 WCryOWDcxcrm for ; Wed, 6 May 2020 11:11:21 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30062.outbound.protection.outlook.com [40.107.3.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 2657C3A09AF for ; Wed, 6 May 2020 11:11:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VHMh0M17n/jhDjgKr0OJoufimXxPm+VLRYxU84JgEtaZHL362o7mGOxyO8NFHu9Z1yMNY9L7JVajfg083isyKuDzxiigWG9y+HA6ufXkpVcK0SNd0HYNcJKA2Bt/fVsnzVQaTcNWKSAxpHeAVheYWZwT/Vaf6KGvJ7RJ2Y1EKRs1Aj3NOG2vL7eVTXBfNuf2qIIIrAN9hTtPOT+cuqyeHMGgXE56u1eD0kLxiMGbRChQOCY6a/nqUX/jAynLwta4O1ohUnCUppvGTKzHF4Ai6YgD39hzP3k5OAIzJhAlairGc6sEabT5bvC3q5bA8NL2rwhC80Gj5sDdwk++IHfbVw== 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=5qmKcEgD1zXZknnXy0Nb5vPdlBZYtsFia/epHVFVMSM=; b=OOELvSBM4K1+chwtr8d1KAsz25tVoLBC45fPJ4tfE3WG5woa4uEecfSDtFoG6QsLKSNbKmGKe0o1v4Wqt01w96XdWB+0ws3S3ItaaU6VOsgsBkVg4CI15HnZPqX+AKrKltxAH07VDIGWJKwgTcCoSz+r1F59TIs30b7dfN32qbN1s5SGHpSWxg/9exY7vr7j57cqQfJDinlXseSf1KprwkbQKImL8UTP4colYF1ykpeJqPpoc/gbA9TOmSbDmbtb4TNQP4ncxp2+wasbr8CLCDslTmD0hiTcAkyBFIP5wK5JBwejl99t+NnBoNFTOmd9q0Mrk5Uumy+M2dxFlIShUw== 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=5qmKcEgD1zXZknnXy0Nb5vPdlBZYtsFia/epHVFVMSM=; b=lmYzkDQ/cwYj7ND+DCYhUmDa6NKwNxoTngBy3c4xfksbBZgVLcSrnbJCdN2nshmJfyGY45A9qFkNm6dMJ47t9reOf9MVo8uCoYc7obF+B1gAzmPfZwgaUdAFG2oFadp77/mYEOmRGwNFwHonCua8URAezHKSJoSe4Ss5fOspmtI= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (52.133.6.18) by HE1PR0702MB3643.eurprd07.prod.outlook.com (10.167.125.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.14; Wed, 6 May 2020 18:11:17 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526%6]) with mapi id 15.20.2979.028; Wed, 6 May 2020 18:11:17 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: Minutes interim 2020-05-06 Thread-Index: AQHWI9G8f+wckCmst0mAx73wQkgt/g== Date: Wed, 6 May 2020 18:11:17 +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.36.20041300 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: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8c1c17f8-1d4d-4c01-7ba5-08d7f1e8df49 x-ms-traffictypediagnostic: HE1PR0702MB3643: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mwIPgai2O8RRw2+D4Jocy6DoyqTYL5rv1cyBGwmyWPES5Indpvhlted/dBHqgGLBdpgmurHzY4SNVGSxoe2JNB+0THnxKlwe+BeDcSt3P6dOsCK3s1hgImHNZ4IC5a9oMyhmSHw46pOoK7G/t5VZ7KT8izckfxduVOjYOqUIGy9qnk9FGGlA9wES2YY+MprReeLM5s/L8NIvt7dhgjhNJsDZFx/Pqlo3PiNksQj6wAz44U1Sd21oU8RpwshELM9jIGl+2vHfd8EyrW2Lp/SB4kyPbjI0GXpiokdUC22XlkGgbNpbgVrqB+kH5yYq6ZghoXAbYfUREvWR0p+QTUO7xv6PdsUyFjnPdTtctWP2RxsT2rRratmKrDNzWNxPXWqIWAjbbVSQwDiyC6hKWcBkcoeyDMmmSxTQ9beEBUVPQSr4PDLsCFSjzejRKonCAnTiZXhEixU/fAB6GwrJdTNEHb5Nr815mzLRXnH+xxSa52nEW+hsaC04O4X36MqVoeAesiSP2eZvgp62XRUXqMfCMaYsmbfd1gDEMXQDDInO0Vam9JkTlmkocyPuUuJFyBVsoJsUS96zb2+U9Ghk0nXWFAd5yDrYmY0ZmnpRqvJfyAA= 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)(346002)(376002)(39860400002)(136003)(396003)(33430700001)(966005)(478600001)(6916009)(8676002)(186003)(66556008)(64756008)(66476007)(5660300002)(36756003)(8936002)(6506007)(66946007)(71200400001)(76116006)(66446008)(33656002)(26005)(6512007)(2616005)(16799955002)(316002)(44832011)(86362001)(33440700001)(6486002)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: QWnY+4dMZLajVarPtEnVeqbODmojf3hYv6+1IAoo2a7g5HuUr1qUP7XiC6v6P9FsQ5/ViKDLhdVh97MbbU34vVTle5UHyzYTALofvYXVPZrpWSt2JWqNQTZYVwUNOKSLqwMDbhsLSia984DBQ883ZR8cBlwytpRDgW4VHo1h6pJUGbMzVhDWUI4mVmJdt+p6SXy3yHorGtxrBP6KWUjoEB7/jlYzR8JADnaJjCZ0lJi+GH41Xl6q3kQnCiC+3UELYp/ndiZBrXke5+h6euScC8ZYhHycog6NXYmy9JJDh8VNxAU5JVDyV4CZvZxSHe//HOEG2MKetUPbdNs0Gqx14XgtcBzdTCUZ24iZW1/uh8DcbEEV+ytA/v/7SNBD9wRwPNNfEghPyq6ga/Qzawg/F7njswogJCLJMry0GRxoQxN6wUsTbn0lLAeZWjrQZMxsf2S1C4ssPcymPhUGyShgXMfOX0Hz97Bj/hMM6mI/l9C5J5RTd2SMmJd6w0SqStJ2KszRHkAzTY45V83V0KHxZWTNgO0TCLNwzKhq6s/gNlaOE/F6c5FWpjwMjFVdcckkJpNfviVQcnOY1f6rTihNfwMJ+si9Jv//uQ7eSJzxL35Ak2MOANyWPtkPhCbWLV8KLbLA5F024yesXn6vLPwj27dy/8UQ1+1dBWIuMkPX+iD3i/TAktpAtTpg6w3Q978wGpQpiR4Ybg2+8EZkCdzrkY+7woVrd/erak8peamtUjFT0peYXjAxKBKMNai3Oy4WyisgdoAP0TpBe/TRAMY8LH/JsI9VNnyQbHposQptW09DAYI9+gxmLLauJWv+EsdV x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c1c17f8-1d4d-4c01-7ba5-08d7f1e8df49 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 18:11:17.6216 (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: GJ9aFR33W/47M2y50bQ5vZQZ/ZGjO3S+RAHdiNSZN6RkJltkKchfPe+Iom1NlaSK3LqqAaszc94Fv1r+rG1BKsA7n5QeS5Fvkp3Kq8dHIByvJtepUGeOrrKYEZsUJSGx X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3643 Archived-At: Subject: [Cbor] Minutes interim 2020-05-06 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, 06 May 2020 18:11:23 -0000 SGksDQoNCk1pbnV0ZXMgZnJvbSB0b2RheSBoYXZlIGJlZW4gcG9zdGVkOiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL21lZXRpbmcvaW50ZXJpbS0yMDIwLWNib3ItMDgvbWF0ZXJpYWxzL21p bnV0ZXMtaW50ZXJpbS0yMDIwLWNib3ItMDgtMjAyMDA1MDYxNzAwLnR4dCBUaGV5IGluY2x1ZGUg dGhlIHJlY29yZGluZy4NCg0KVGFsayB0byB5b3UgaW4gMiB3ZWVrcywNCkZyYW5jZXNjYQ0KDQrv u79PbiAwNS8wNS8yMDIwLCAxOToyMSwgIkNCT1Igb24gYmVoYWxmIG9mIElFU0cgU2VjcmV0YXJ5 IiA8Y2Jvci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpZXNnLXNlY3JldGFyeUBpZXRm Lm9yZz4gd3JvdGU6DQoNCiAgICBNRUVUSU5HIERFVEFJTFMgSEFWRSBDSEFOR0VELiAgU0VFIExB VEVTVCBERVRBSUxTIEJFTE9XLg0KDQogICAgVGhlIENvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXBy ZXNlbnRhdGlvbiBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9ucyAoY2JvcikgV29ya2luZyBHcm91 cCB3aWxsIGhvbGQNCiAgICBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9uIDIwMjAtMDUtMDYg ZnJvbSAxNzowMCB0byAxODowMCBFdXJvcGUvUGFyaXMgKDE1OjAwIHRvIDE2OjAwIFVUQykuDQoN CiAgICBBZ2VuZGE6DQogICAgQ0JPUiBXRyBNZWV0aW5nIC0gSW50ZXJpbSAyMC0wOA0KICAgIFdl ZG5lc2RheSwgTWF5IDYsIDIwMjAsIDE3OjAwIC0gMTg6MDAgQ0VTVA0KICAgIENoYWlyczogRnJh bmNlc2NhIFBhbG9tYmluaSwgSmltIFNjaGFhZA0KDQogICAgV2ViZXg6IGh0dHBzOi8vaWV0Zi53 ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1mMDVjNDdhOWE0MTgxNzllM2U4MTBhMTUxZGNiMjVh OQ0KICAgIE1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0NyA4MzYgNDIwIA0KICAgIE1l ZXRpbmcgcGFzc3dvcmQ6IGVtSHJpZ0MyMks0DQoNCiAgICBKYWJiZXI6IGNib3JAamFiYmVyLmll dGYub3JnDQoNCiAgICBFdGhlcnBhZDogaHR0cHM6Ly9ldGhlcnBhZC5pZXRmLm9yZzo5MDA5L3Av bm90ZXMtaWV0Zi1pbnRlcmltLTIwMjAtY2Jvci0wOA0KDQogICAgQWdlbmRhOg0KDQogICAgKiBE YXRlIGFuZCB0aW1lIHRhZyBkb2N1bWVudCA6IENoYWlycw0KICAgICAgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLWNib3ItZGF0ZS10YWctMDENCiAgICAgIC0gV0cgYWRv cHRpb24gY2FsbCByZXN1bHQNCg0KICAgICogQ0JPUiBzcGVjaWZpY2F0aW9uIHN0YXR1cyA6IENh cnN0ZW4NCiAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNib3It NzA0OWJpcy0xMw0KDQogICAgICBTdW1tYXJ5IGZyb20gbGFzdCBtZWV0aW5nOg0KICAgICAgLSBJ bXBsZW1lbnRlcnMgcmV2aWV3IHN0YXR1cw0KICAgICAgLSBOZXh0IHN1Ym1pc3Npb24gYnkgdGhl IGVuZCBvZiB0aGUgQXByaWwsIHRoZW4gcmVhZHkgdG8gc2hpcA0KDQogICAgKiBBb0INCg0KICAg IEluZm9ybWF0aW9uIGFib3V0IHJlbW90ZSBwYXJ0aWNpcGF0aW9uOg0KICAgIGh0dHBzOi8vaWV0 Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1mMDVjNDdhOWE0MTgxNzllM2U4MTBhMTUxZGNi MjVhOSAgIE1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0NyA4MzYgNDIwICAgIE1lZXRp bmcgcGFzc3dvcmQ6IGVtSHJpZ0MyMks0DQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgIENCT1IgbWFpbGluZyBsaXN0DQogICAgQ0JPUkBp ZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Jvcg0K DQo= From nobody Wed May 6 19:16: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 94D7D3A03F3 for ; Wed, 6 May 2020 19:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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=W1e1s43u; dkim=pass (2048-bit key) header.d=comcastmailservice.net header.b=aIEdoBcF 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 lFyTNUYddyrY for ; Wed, 6 May 2020 19:16:39 -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 E24DB3A0365 for ; Wed, 6 May 2020 19:16:38 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net ([69.252.207.38]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id WVw2jlezUnv6FWW5Vjq3kz; Thu, 07 May 2020 02:16:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1588817797; bh=x9Lf7HghSsHakwZc6+jEUY+RLMlzQJhledInLtzHVtM=; h=Received:Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=W1e1s43ujJhO7L79R/CFKBHzlhQT9HknXOQZcu9L60ox5dZiJCXsDkVze58Chtely rEoiypV0S51cCJ7Ya7D4E9U6pd1qS10DKcUoWqfXSBxRj3x+hXHDkg/keT5wZvmXhB kKl8E+e6b6EY/gW8xU2QPNPDWzaQOWVUxww08X2etaZ4mD0UsQLzL6hn6kqJB3engv KQM1oiqbW65yurxwvaowrlBjDjOyuGvhykfbVfgIepDRIsMvpNgxbNN+SBuNLFSHXU lvh3B6UHa/jHJQDvPCEfQH3KiGEyAbSeENlPOmX7Afo6FE746DZsVgmbOUZNs3h1Uy mCUwtT2j7SPTQ== Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id WW31jMLjcaccEWW5UjM7xV; Thu, 07 May 2020 02:16:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1588817796; bh=x9Lf7HghSsHakwZc6+jEUY+RLMlzQJhledInLtzHVtM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=aIEdoBcFRXKC9gO2kOT5p2Lpw19NLojMIGZJrSIygRqJnE2ps2mh15MvytB9MQp40 oiU3fpmFDOFVpV/W2H74m5IEY4rYrYbdTOcOpHSmPA8W8AlxTATfqih3bkPUFLCEL6 kMRUvbx/a2Gren7bspRFW5WanRS0oJ0c44plJWFXQ17xDtz2hE45b84+pEOsFovck+ jaARBdkEZBSrQ/Ak+YPHw8VF/OLfA8LaEQjBr4ZrcjIsolmqGggbDhOxMgxN6M77OY oEzBDgEt25a3+m+eTg3V82xS8j6xCkX8JGHiTGOlXLx47mhuIToTi+jmeKUIfDoRUB 8TDk5lhvFVDtQ== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-07v.sys.comcast.net with ESMTPA id WW5PjsJM5D1LzWW5SjTnCf; Thu, 07 May 2020 02:16:36 +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 0472GUof010972; Wed, 6 May 2020 22:16:30 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 0472GTsU010956; Wed, 6 May 2020 22:16:29 -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: <6ACF0CA3-59C4-4CE1-9344-81B43C75BAF4@tzi.org> (cabo@tzi.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 06 May 2020 22:16:29 -0400 Message-ID: <87k11oa3r6.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [Cbor] Fwd: [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] 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, 07 May 2020 02:16:41 -0000 Carsten Bormann writes: > JFYI: Interesting discussion in core/netmod about potentially needing > to represent sparse bit sets. Anything we (cbor WG) can contribute to > that? One common representation for sparse bit sets is the list of indexes of the 1 bits. For this, the "Typed Arrays" proposal seems ideal. I'm not sure this influences the Netmod discussion, though. Dale From nobody Thu May 7 05:07: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 A471E3A079D for ; Thu, 7 May 2020 05:07:07 -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, HTML_MESSAGE=0.001, 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 w_MIqeKLIEKy for ; Thu, 7 May 2020 05:07:04 -0700 (PDT) Received: from sjmda13.webex.com (sjmda13.webex.com [64.68.124.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A4F3A07A0 for ; Thu, 7 May 2020 05:07:04 -0700 (PDT) Received: from rva2rmd101.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda13.webex.com (Postfix) with ESMTP id 122A4300006C for ; Thu, 7 May 2020 12:07:04 +0000 (GMT) Received: from rva2rmd101.webex.com (localhost [127.0.0.1]) by rva2rmd101.webex.com (Postfix) with ESMTP id 7D8F5102289E for ; Thu, 7 May 2020 12:07:03 +0000 (GMT) Date: Thu, 7 May 2020 12:07:03 +0000 (GMT) From: CBOR Working Group Reply-To: cbor-chairs@ietf.org To: cbor@ietf.org Message-ID: <876919715.5121251588853223513.JavaMail.nobody@rva2rmd101.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1024227_1969063014.1588853223513" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=160506581260185031, X-WBX-TID=2q2iuup8c3lgakrqkxjfjxxart66ewlaqtla2012s0omk0h7zzf4toop, X-WBX-RID=c286ef0e15b2449f8febfa34426a091c, X-WBX-SVC:Meeting Center, X-WBX-TT:Updated Meeting Invitation, Date:Thu May 07 12:07:03 GMT 2020 reminder-40.1.1-4 Archived-At: Subject: [Cbor] Webex meeting changed: CBOR Interim Meeting X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 12:07:08 -0000 ------=_Part_1024227_1969063014.1588853223513 Content-Type: multipart/Alternative; boundary="----=_Part_1024228_2102608619.1588853223513" ------=_Part_1024228_2102608619.1588853223513 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhpLCBjYm9yQGlldGYub3JnLAoKQ0JPUiBXb3JraW5nIEdyb3VwIGNoYW5nZWQgdGhlIFdlYmV4 IG1lZXRpbmcgaW5mb3JtYXRpb24uCgoKQ0JPUiBJbnRlcmltIE1lZXRpbmcKT2NjdXJzIGV2ZXJ5 IDIgd2VlayhzKSBvbiBXZWRuZXNkYXkgZWZmZWN0aXZlIFdlZG5lc2RheSwgTWF5IDIwLCAyMDIw IHVudGlsIFdlZG5lc2RheSwgSnVseSAxNSwgMjAyMCBmcm9tIDU6MDAgUE0gdG8gNjowMCBQTSwg KFVUQyswMjowMCkgQW1zdGVyZGFtLCBCZXJsaW4sIEJlcm4sIFJvbWUsIFN0b2NraG9sbSwgVmll bm5hCjU6MDAgcG0gIHwgIChVVEMrMDI6MDApIEFtc3RlcmRhbSwgQmVybGluLCBCZXJuLCBSb21l LCBTdG9ja2hvbG0sIFZpZW5uYSAgfCAgMSBocgpNZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUp OiA2NDcgODM2IDQyMCAKTWVldGluZyBwYXNzd29yZDogZW1IcmlnQzIySzQKCgoKV2hlbiBpdCdz IHRpbWUsIGpvaW4gdGhlIG1lZXRpbmcuCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW01ZGI1M2FkODUwMjQ0ZTI1ZmNlY2YxMGMzMGExYTgxMQoKQWRkIHRvIENhbGVuZGFy Cmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW00ZTA0MGQ3N2QzMzYwNWI4 Nzc5MzA0ZjcyOWI0OWI3MA0KDQoKCg0KSk9JTiBCWSBQSE9ORQ0KMS02NTAtNDc5LTMyMDggQ2Fs bC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKQpUYXAgaGVyZSB0byBjYWxsIChtb2JpbGUgcGhv bmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCow MSo2NDc4MzY0MjAlMjMlMjMqMDEqCg0KDQoKSk9JTiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQ UExJQ0FUSU9OCkRpYWwgc2lwOjY0NzgzNjQyMEBpZXRmLndlYmV4LmNvbQpZb3UgY2FuIGFsc28g ZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuCgoKSm9pbiB1 c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzCkRpYWwg c2lwOjY0NzgzNjQyMC5pZXRmQGx5bmMud2ViZXguY29tCgoKQ2FuJ3Qgam9pbiB0aGUgbWVldGlu Zz8KaHR0cHM6Ly9jb2xsYWJvcmF0aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkw NTUKCgpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2Vydmlj ZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNz aW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwg bWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2Vu dCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNv cmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4g dGhlIHNlc3Npb24uCg== ------=_Part_1024228_2102608619.1588853223513 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KKiB7CiAgICBwYWRkaW5nOiAwOyAgICBtYXJnaW46IDA7 fQp0YWJsZSB7Cglib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVy OiAwOwlib3JkZXItc3BhY2luZzogMDt9Cgp0ciB7CglsaW5lLWhlaWdodDogMThweDt9CgphLCB0 ZCB7Cglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdv cmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO30KCi50 aXRsZSB7Cglmb250LXNpemU6IDI4cHg7fQoKLmltYWdlIHsKCXdpZHRoOiBhdXRvOwltYXgtd2lk dGg6IGF1dG87fQoKLmZvb3RlciB7Cgl3aWR0aDogNjA0cHg7fQoKLm1haW4gewoKfUBtZWRpYSBz Y3JlZW4gYW5kIChtYXgtZGV2aWNlLXdpZHRoOiA4MDBweCkgewoJLnRpdGxlIHsKCQlmb250LXNp emU6IDIycHggIWltcG9ydGFudDsJfQoJLmltYWdlIHsKCQl3aWR0aDogYXV0byAhaW1wb3J0YW50 OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX0KCS5mb290ZXIgewoJCXdpZHRoOiAxMDAl ICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnQKCX0KCS5tYWluIHsKCQl3 aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50Cgl9Cn0K PC9zdHlsZT4KCjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFy Z2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiPgoJPHRyIHN0eWxl PSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+Cgk8dHI+CgkJPHRkIGFsaWduPSJs ZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAiPgoJCQk8IS0tPHRhYmxlIGJn Y29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6IDEwMCU7IHBhZGRpbmct bGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFp biI+CgkJCQk8dHI+CgkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5ic3A7 CQkJCQk8L3RkPgoJCQkJPC90cj4KCQkJPC90YWJsZT4tLT4KCgo8dGFibGU+CiAgICAgICAgPHRy PgogICAgICAgICAgICA8dGQ+CgkJCQk8cCBzdHlsZT0iZm9udC1zaXplOiAxNnB4O2ZvbnQtZmFt aWx5OiBhcmlhbDtjb2xvcjojMDAwMDAwO2ZvbnQtd2VpZ2h0OiBib2xkO2xpbmUtaGVpZ2h0OiAy MnB4OyI+CiAgICAgICAgICAgICAgICAgICAgQ0JPUiBXb3JraW5nIEdyb3VwIGNoYW5nZWQgdGhl IFdlYmV4IG1lZXRpbmcgaW5mb3JtYXRpb24uCiAgICAgICAgICAgICAgICA8L3A+CiAgICAgICAg ICAgIDwvdGQ+CiAgICAgICAgPC90cj4KICAgICAgICA8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAy MHB4OyI+CgkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyMHB4OyI+Jm5ic3A7PC90ZD4KCQk8L3RyPgog ICAgICAgIDx0cj4KICAgICAgICAgICAgPHRkPgoJCQkJPHAgc3R5bGU9ImZvbnQtc2l6ZTogMTZw eDtmb250LWZhbWlseTogYXJpYWw7Y29sb3I6IzAwMDAwMDtsaW5lLWhlaWdodDogMjJweDsiPgog ICAgICAgICAgICAgICAgICAgIFdoZW4gaXQncyB0aW1lLCBqb2luIHRoZSBXZWJleCBtZWV0aW5n IGhlcmUuCiAgICAgICAgICAgICAgICA8L3A+CiAgICAgICAgICAgIDwvdGQ+CiAgICAgICAgPC90 cj4KICAgICAgICA8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+CgkJCTx0ZCBzdHlsZT0i aGVpZ2h0OiAyMHB4OyI+Jm5ic3A7PC90ZD4KCQk8L3RyPgo8L3RhYmxlPgoKCgoJCQkJCQk8dGFi bGUgc3R5bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50OyI+CgkJCQkJCQk8dHI+ CgkJCQkJCQkJPHRkIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGNvbG9yOiAjMDAwMDAwOyBm b250LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiAyMnB4OyI+CgkJCQkJCQkJCU1lZXRpbmcgbnVt YmVyIChhY2Nlc3MgY29kZSk6IDY0NyA4MzYgNDIwCgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+ CgkJCQkJCTwvdGFibGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0 byFpbXBvcnRhbnQiPgoJCQkJCQkJPHRyID4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtZmFtaWx5 OiBhcmlhbDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtc2l6ZTogMTZweDsgbGluZS1oZWlnaHQ6IDIy cHg7Ij5NZWV0aW5nIHBhc3N3b3JkOiBlbUhyaWdDMjJLNDwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJ CQk8L3RhYmxlPgoJCQkJCQkKCgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAlIj4KCQkJCQkJCTx0 ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDE2cHg7Ij4KCQkJCQkJCQk8dGQgc3R5bGU9ImhlaWdodDog MTZweDsiPiZuYnNwOzwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQkJPHRyID4KCQkJCQkJCQk8dGQg c3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjojNjY2NjY2OyBmb250LWZhbWlseTogYXJpYWw7 IGxpbmUtaGVpZ2h0OiAyMnB4OyBtYXJnaW46IDA7Ij5PY2N1cnMgZXZlcnkgMiB3ZWVrKHMpIG9u IFdlZG5lc2RheSBlZmZlY3RpdmUgV2VkbmVzZGF5LCBNYXkgMjAsIDIwMjAgdW50aWwgV2VkbmVz ZGF5LCBKdWx5IDE1LCAyMDIwIGZyb20gNTowMCBQTSB0byA2OjAwIFBNLCAoVVRDKzAyOjAwKSBB bXN0ZXJkYW0sIEJlcmxpbiwgQmVybiwgUm9tZSwgU3RvY2tob2xtLCBWaWVubmEKCQkJCQkJCQk8 L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6 ZToxNnB4OyBjb2xvcjojNjY2NjY2OyBmb250LWZhbWlseTogYXJpYWw7IGxpbmUtaGVpZ2h0OiAy MnB4OyBtYXJnaW46IDA7Ij4KCQkJCQkJCQkJNTowMCBwbSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJz cDsoVVRDKzAyOjAwKSBBbXN0ZXJkYW0sIEJlcmxpbiwgQmVybiwgUm9tZSwgU3RvY2tob2xtLCBW aWVubmEmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7MSBocgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8 L3RyPgoJCQkJCQk8L3RhYmxlPgoKCiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5 bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD4KCiAgICAKCgkJCTx0YWJsZSBzdHlsZT0i cGFkZGluZy1ib3R0b206IDRweDtmb250LWZhbWlseTogQXJpYWw7Ij48dHIgc3R5bGU9ImxpbmUt aGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90 YWJsZT4KCQkJPHRhYmxlIHN0eWxlPSd3aWR0aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50Oyc+ PHRyPjx0ZCBzdHlsZT0nd2lkdGg6YXV0byFpbXBvcnRhbnQ7ICc+PHRhYmxlIGJvcmRlcj0nMCcg Y2VsbHBhZGRpbmc9JzAnIGNlbGxzcGFjaW5nPScwJyBzdHlsZT0nd2lkdGg6YXV0bzt3aWR0aDph dXRvIWltcG9ydGFudDsgYmFja2dyb3VuZC1jb2xvcjojNDNBOTQyOyBib3JkZXI6MHB4IHNvbGlk ICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjBweDsgbWluLXdpZHRoOjE2MHB4IWltcG9ydGFudDsn Pjx0Ym9keT48dHI+PHRkIGFsaWduPSdjZW50ZXInIHN0eWxlPSdwYWRkaW5nOjEwcHggMzZweDtm b250LWZhbWlseTogQXJpYWw7Jz48YSBocmVmPSdodHRwczovL2lldGYud2ViZXguY29tL2lldGYv ai5waHA/TVRJRD1tNWRiNTNhZDg1MDI0NGUyNWZjZWNmMTBjMzBhMWE4MTEnIHN0eWxlPSdjb2xv cjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Jz5Kb2luIG1l ZXRpbmc8L2E+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48L3RkPjwvdHI+PC90YWJsZT4KCQkJ PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDQ4cHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjQ4 cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoKCgk8dGFibGU+PHRib2R5Pjx0cj48dGQgc3R5 bGU9ImNvbG9yOiAjMDAwMDAwO2ZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxMnB4OyBm b250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIGJ5IHBob25lPC9i PjwvdGQ+PC90cj48dHI+PHRkIHN0eWxlPSJjb2xvcjogIzk5OTk5OTtmb250LWZhbWlseTogQXJp YWw7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5UYXAgdG8gY2FsbCBpbiBm cm9tIGEgbW9iaWxlIGRldmljZSAoYXR0ZW5kZWVzIG9ubHkpPC90ZD48L3RyPjx0ciBzdHlsZT0i bWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMztmb250LWZhbWlseTogQXJpYWw7 Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4OyI+PGEgaHJlZj0ndGVsOiUyQjEtNjUw LTQ3OS0zMjA4LCwqMDEqNjQ3ODM2NDIwJTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7 ICB0ZXh0LWRlY29yYXRpb246bm9uZTsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRw eDtsaW5lLWhlaWdodDogMjRweDsnPjEtNjUwLTQ3OS0zMjA4PC9hPiZuYnNwOzxzcGFuIHN0eWxl PSJjb2xvcjogIzMzMzMzMzsiPkNhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L3NwYW4+ PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJmb250LWZhbWlseTog QXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4OyI+PC90ZD48L3RyPjwvdGJv ZHk+PC90YWJsZT48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48dHIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyOHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjhweCI+Jm5ic3A7PC90 ZD48L3RyPjwvdGFibGU+Cgk8dGFibGU+PHRyPjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBm b250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGlu ZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIGZyb20gYSB2aWRlbyBzeXN0ZW0gb3IgYXBwbGljYXRp b248L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjog IzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0 OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjY0NzgzNjQyMEBpZXRmLndlYmV4LmNvbSIgICBz dHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOSI+NjQ3ODM2NDIwQGlldGYu d2ViZXguY29tPC9hPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0i Y29sb3I6ICMzMzMzMzM7IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5l LWhlaWdodDogMjRweDsiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIg eW91ciBtZWV0aW5nIG51bWJlci48L3RkPjwvdHI+PC90YWJsZT48dGFibGU+PHRyIHN0eWxlPSJs aW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90 cj48L3RhYmxlPgogICAgPHRhYmxlIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRy Pjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXpl OiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIHVz aW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3M8L2I+PC90 ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsg Zm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+ RGlhbCA8YSBocmVmPSIgc2lwOjY0NzgzNjQyMC5pZXRmQGx5bmMud2ViZXguY29tIiAgIHN0eWxl PSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij42NDc4MzY0MjAuaWV0ZkBseW5j LndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90YWJsZT4KCgkJCTx0YWJsZSBzdHlsZT0id2lkdGg6 IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPgogICAgICAgICAgICAgICAgPHRyIHN0 eWxlPSJoZWlnaHQ6IDcycHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+CgkJCQk8dHI+CgkJCQkJPHRk IHN0eWxlPSJoZWlnaHQ6IDI0cHg7IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpBcmlhbDsg Zm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28gdG8gPGEg aHJlZj0iaHR0cDovL2hlbHAud2ViZXguY29tIiBzdHlsZT0iY29sb3I6IzA0OUZEOTsgdGV4dC1k ZWNvcmF0aW9uOm5vbmU7Ij5odHRwOi8vaGVscC53ZWJleC5jb208L2E+CgkJCQkJPC90ZD4KCQkJ CTwvdHI+CiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+PHRkPiZuYnNw OzwvdGQ+PC90cj4KCQkJPC90YWJsZT4KCQk8L3RkPgoJPC90cj4KPC90YWJsZT4K ------=_Part_1024228_2102608619.1588853223513 Content-Type: text/calendar;method=REQUEST;charset=utf-8; Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkV1cm9wZS9BbXN0ZXJkYW0NClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9FdXJvcGUvQW1zdGVyZGFtDQpYLUxJQy1MT0NBVElPTjpFdXJvcGUvQW1z dGVyZGFtDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9GRlNFVFRPOisw MjAwDQpUWk5BTUU6Q0VTVA0KRFRTVEFSVDoxOTcwMDMyOVQwMjAwMDANClJSVUxFOkZSRVE9WUVB UkxZO0JZTU9OVEg9MztCWURBWT0tMVNVDQpFTkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpU Wk9GRlNFVEZST006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClRaTkFNRTpDRVQNCkRUU1RBUlQ6 MTk3MDEwMjVUMDMwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTEwO0JZREFZPS0xU1UN CkVORDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAw NTA3VDEyMDcwM1oNCkFUVEVOREVFO0NOPSJjYm9yQGlldGYub3JnIjtST0xFPVJFUS1QQVJUSUNJ UEFOVDtSU1ZQPVRSVUU6TUFJTFRPOmNib3JAaWV0Zi5vcmcNCk9SR0FOSVpFUjtDTj0iQ0JPUiBX b3JraW5nIEdyb3VwIjpNQUlMVE86Y2Jvci1jaGFpcnNAaWV0Zi5vcmcNCkRUU1RBUlQ7VFpJRD1F dXJvcGUvQW1zdGVyZGFtOjIwMjAwNTIwVDE3MDAwMA0KRFRFTkQ7VFpJRD1FdXJvcGUvQW1zdGVy ZGFtOjIwMjAwNTIwVDE4MDAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm L2oucGhwP01USUQ9bTVkYjUzYWQ4NTAyNDRlMjVmY2VjZjEwYzMwYTFhODExDQpUUkFOU1A6T1BB UVVFDQpTRVFVRU5DRToxNTg4ODUzMjIzDQpVSUQ6YWRjNzJjNDAtOTQ5MC00NWRkLWJmN2EtZjIx MDVjZmM1OThiDQpERVNDUklQVElPTjpcblxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTVkYjUzYWQ4NTAyNDRlMjVmY2VjZjEw YzMwYTFhODExXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDcgODM2IDQyMFxuXG5c bk1lZXRpbmcgcGFzc3dvcmQ6IGVtSHJpZ0MyMks0XG5cblxuXG5KT0lOIEJZIFBIT05FXG4xLTY1 MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0byBj YWxsIChtb2JpbGUgcGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJCMS02 NTAtNDc5LTMyMDgsLCowMSo2NDc4MzY0MjAlMjMlMjMqMDEqXG5cblxuXG5KT0lOIEZST00gQSBW SURFTyBTWVNURU0gT1IgQVBQTElDQVRJT05cbkRpYWwgc2lwOjY0NzgzNjQyMEBpZXRmLndlYmV4 LmNvbVxuWW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRp bmcgbnVtYmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNr eXBlIGZvciBCdXNpbmVzc1xuRGlhbCBzaXA6NjQ3ODM2NDIwLmlldGZAbHluYy53ZWJleC5jb21c blxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25oZWxw LmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBs ZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIg aW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNo IG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBz ZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYg eW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2Vy bnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQtREVT QztGTVRUWVBFPXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxuKiB7XG4gICAgcGFk ZGluZzogMDsgICAgbWFyZ2luOiAwO31cbnRhYmxlIHtcbglib3JkZXItY29sbGFwc2U6IHNlcGFy YXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2luZzogMDt9XG5cbnRyIHtc bglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRkIHtcbglmb250LXNpemU6IDE0cHg7CWZvbnQt ZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1i cmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxuLnRpdGxlIHtcbglmb250LXNpemU6IDI4cHg7 fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwltYXgtd2lkdGg6IGF1dG87fVxuXG4uZm9vdGVy IHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7XG5cbn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4 LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0bGUge1xuCQlmb250LXNpemU6IDIycHggIWlt cG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRoOiBhdXRvICFpbXBvcnRhbnQ7CQltYXgtd2lk dGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290ZXIge1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0 YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxuCS5tYWluIHtcbgkJd2lkdGg6 IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbn1cbjwv c3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFy Z2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiPlxuCTx0ciBzdHls ZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCTx0cj5cbgkJPHRkIGFsaWdu PSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAiPlxuCQkJPCEtLTx0YWJs ZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7IHdpZHRoOiAxMDAlOyBwYWRk aW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBhbGlnbj0ibGVmdCIgY2xhc3M9 Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+ Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPi0tPlxuXG5cblxuXG5cbgkJ CTx0YWJsZT5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjQiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+V2hlbiBpdCdzIHRpbWUsIGpvaW4gdGhlIFdlYmV4IG1l ZXRpbmcgaGVyZS48L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCQk8dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48 L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDcgODM2 IDQyMDwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT5cbgkJCVxuCQkJ PHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5lbUhyaWdDMjJLNDwvRk9OVD48L3RkPjwvdHI+PC90YWJs ZT5cblxuICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAy MHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPHRyPlxu CQkJCTx0ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4JCQkJCTx0YWJsZSBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5bGU9IndpZHRoOmF1dG87 d2lkdGg6YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNBOTQyOyBib3JkZXI6MHB4 IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdpZHRoOjE2MHB4IWltcG9y dGFudDsiPlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiBzdHlsZT0icGFk ZGluZzoxMHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5w aHA/TVRJRD1tNWRiNTNhZDg1MDI0NGUyNWZjZWNmMTBjMzBhMWE4MTEiIHN0eWxlPSJjb2xvcjoj RkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5Kb2luIG1lZXRp bmc8L2E+PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4JCQkJPC90ZD5cbgkJCTwv dHI+XG4JCTwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFM Ij4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSI0 IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij5Kb2luIGJ5IHBob25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+PGI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwq MDEqNjQ3ODM2NDIwJTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29y YXRpb246bm9uZTsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdo dDogMjRweDsnPjEtNjUwLTQ3OS0zMjA4PC9hPjwvYj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMv Q2FuYWRhKTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48QlI+XG5cbjx0YWJsZT48dHIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpF PSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gZnJvbSBhIHZpZGVvIHN5c3Rl bSBvciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVmPSJzaXA6NjQ3ODM2NDIwQGlldGYud2Vi ZXguY29tIj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPjY0Nzgz NjQyMEBpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42 OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05U PiZuYnNwOyA8QlI+XG5cbjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0 cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiB1 c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPC9iPjwv dGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7 IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsi PkRpYWwgPGEgaHJlZj0iIHNpcDo2NDc4MzY0MjAuaWV0ZkBseW5jLndlYmV4LmNvbSIgICBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOSI+NjQ3ODM2NDIwLmlldGZAbHlu Yy53ZWJleC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+XG5cbgkJCTx0YWJsZSBzdHlsZT0id2lk dGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0 ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJ CQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpB cmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28g dG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2ViZXguY29tIiBzdHlsZT0iY29sb3I6IzA0OUZEOTsg dGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRwOi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwv dGQ+XG4JCQkJPC90cj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+ PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwvdGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFi bGU+XG4NClNVTU1BUlk6Q0JPUiBJbnRlcmltIE1lZXRpbmcNClBSSU9SSVRZOjUNCkNMQVNTOlBV QkxJQw0KUlJVTEU6RlJFUT1XRUVLTFk7V0tTVD1TVTtVTlRJTD0yMDIwMDcxNTtJTlRFUlZBTD0y O0JZREFZPVdFDQpCRUdJTjpWQUxBUk0NClRSSUdHRVI6LVBUNU0NCkFDVElPTjpESVNQTEFZDQpE RVNDUklQVElPTjpSZW1pbmRlcg0KRU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRB Ug0K ------=_Part_1024228_2102608619.1588853223513-- ------=_Part_1024227_1969063014.1588853223513 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkV1cm9wZS9BbXN0ZXJkYW0NClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9FdXJvcGUvQW1zdGVyZGFtDQpYLUxJQy1MT0NBVElPTjpFdXJvcGUvQW1z dGVyZGFtDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9GRlNFVFRPOisw MjAwDQpUWk5BTUU6Q0VTVA0KRFRTVEFSVDoxOTcwMDMyOVQwMjAwMDANClJSVUxFOkZSRVE9WUVB UkxZO0JZTU9OVEg9MztCWURBWT0tMVNVDQpFTkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpU Wk9GRlNFVEZST006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClRaTkFNRTpDRVQNCkRUU1RBUlQ6 MTk3MDEwMjVUMDMwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTEwO0JZREFZPS0xU1UN CkVORDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAw NTA3VDEyMDcwM1oNCkFUVEVOREVFO0NOPSJjYm9yQGlldGYub3JnIjtST0xFPVJFUS1QQVJUSUNJ UEFOVDtSU1ZQPVRSVUU6TUFJTFRPOmNib3JAaWV0Zi5vcmcNCk9SR0FOSVpFUjtDTj0iQ0JPUiBX b3JraW5nIEdyb3VwIjpNQUlMVE86Y2Jvci1jaGFpcnNAaWV0Zi5vcmcNCkRUU1RBUlQ7VFpJRD1F dXJvcGUvQW1zdGVyZGFtOjIwMjAwNTIwVDE3MDAwMA0KRFRFTkQ7VFpJRD1FdXJvcGUvQW1zdGVy ZGFtOjIwMjAwNTIwVDE4MDAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm L2oucGhwP01USUQ9bTVkYjUzYWQ4NTAyNDRlMjVmY2VjZjEwYzMwYTFhODExDQpUUkFOU1A6T1BB UVVFDQpTRVFVRU5DRToxNTg4ODUzMjIzDQpVSUQ6YWRjNzJjNDAtOTQ5MC00NWRkLWJmN2EtZjIx MDVjZmM1OThiDQpERVNDUklQVElPTjpcblxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTVkYjUzYWQ4NTAyNDRlMjVmY2VjZjEw YzMwYTFhODExXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDcgODM2IDQyMFxuXG5c bk1lZXRpbmcgcGFzc3dvcmQ6IGVtSHJpZ0MyMks0XG5cblxuXG5KT0lOIEJZIFBIT05FXG4xLTY1 MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0byBj YWxsIChtb2JpbGUgcGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJCMS02 NTAtNDc5LTMyMDgsLCowMSo2NDc4MzY0MjAlMjMlMjMqMDEqXG5cblxuXG5KT0lOIEZST00gQSBW SURFTyBTWVNURU0gT1IgQVBQTElDQVRJT05cbkRpYWwgc2lwOjY0NzgzNjQyMEBpZXRmLndlYmV4 LmNvbVxuWW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRp bmcgbnVtYmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNr eXBlIGZvciBCdXNpbmVzc1xuRGlhbCBzaXA6NjQ3ODM2NDIwLmlldGZAbHluYy53ZWJleC5jb21c blxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25oZWxw LmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBs ZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIg aW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNo IG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBz ZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYg eW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2Vy bnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQtREVT QztGTVRUWVBFPXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxuKiB7XG4gICAgcGFk ZGluZzogMDsgICAgbWFyZ2luOiAwO31cbnRhYmxlIHtcbglib3JkZXItY29sbGFwc2U6IHNlcGFy YXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2luZzogMDt9XG5cbnRyIHtc bglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRkIHtcbglmb250LXNpemU6IDE0cHg7CWZvbnQt ZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1i cmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxuLnRpdGxlIHtcbglmb250LXNpemU6IDI4cHg7 fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwltYXgtd2lkdGg6IGF1dG87fVxuXG4uZm9vdGVy IHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7XG5cbn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4 LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0bGUge1xuCQlmb250LXNpemU6IDIycHggIWlt cG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRoOiBhdXRvICFpbXBvcnRhbnQ7CQltYXgtd2lk dGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290ZXIge1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0 YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxuCS5tYWluIHtcbgkJd2lkdGg6 IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbn1cbjwv c3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFy Z2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiPlxuCTx0ciBzdHls ZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCTx0cj5cbgkJPHRkIGFsaWdu PSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAiPlxuCQkJPCEtLTx0YWJs ZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7IHdpZHRoOiAxMDAlOyBwYWRk aW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBhbGlnbj0ibGVmdCIgY2xhc3M9 Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+ Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPi0tPlxuXG5cblxuXG5cbgkJ CTx0YWJsZT5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjQiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+V2hlbiBpdCdzIHRpbWUsIGpvaW4gdGhlIFdlYmV4IG1l ZXRpbmcgaGVyZS48L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCQk8dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48 L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDcgODM2 IDQyMDwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT5cbgkJCVxuCQkJ PHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5lbUhyaWdDMjJLNDwvRk9OVD48L3RkPjwvdHI+PC90YWJs ZT5cblxuICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAy MHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPHRyPlxu CQkJCTx0ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4JCQkJCTx0YWJsZSBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5bGU9IndpZHRoOmF1dG87 d2lkdGg6YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNBOTQyOyBib3JkZXI6MHB4 IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdpZHRoOjE2MHB4IWltcG9y dGFudDsiPlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiBzdHlsZT0icGFk ZGluZzoxMHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5w aHA/TVRJRD1tNWRiNTNhZDg1MDI0NGUyNWZjZWNmMTBjMzBhMWE4MTEiIHN0eWxlPSJjb2xvcjoj RkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5Kb2luIG1lZXRp bmc8L2E+PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4JCQkJPC90ZD5cbgkJCTwv dHI+XG4JCTwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFM Ij4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSI0 IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij5Kb2luIGJ5IHBob25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+PGI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwq MDEqNjQ3ODM2NDIwJTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29y YXRpb246bm9uZTsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdo dDogMjRweDsnPjEtNjUwLTQ3OS0zMjA4PC9hPjwvYj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMv Q2FuYWRhKTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48QlI+XG5cbjx0YWJsZT48dHIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpF PSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gZnJvbSBhIHZpZGVvIHN5c3Rl bSBvciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVmPSJzaXA6NjQ3ODM2NDIwQGlldGYud2Vi ZXguY29tIj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPjY0Nzgz NjQyMEBpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42 OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05U PiZuYnNwOyA8QlI+XG5cbjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0 cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiB1 c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPC9iPjwv dGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7 IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsi PkRpYWwgPGEgaHJlZj0iIHNpcDo2NDc4MzY0MjAuaWV0ZkBseW5jLndlYmV4LmNvbSIgICBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOSI+NjQ3ODM2NDIwLmlldGZAbHlu Yy53ZWJleC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+XG5cbgkJCTx0YWJsZSBzdHlsZT0id2lk dGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0 ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJ CQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpB cmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28g dG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2ViZXguY29tIiBzdHlsZT0iY29sb3I6IzA0OUZEOTsg dGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRwOi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwv dGQ+XG4JCQkJPC90cj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+ PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwvdGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFi bGU+XG4NClNVTU1BUlk6Q0JPUiBJbnRlcmltIE1lZXRpbmcNClBSSU9SSVRZOjUNCkNMQVNTOlBV QkxJQw0KUlJVTEU6RlJFUT1XRUVLTFk7V0tTVD1TVTtVTlRJTD0yMDIwMDcxNTtJTlRFUlZBTD0y O0JZREFZPVdFDQpCRUdJTjpWQUxBUk0NClRSSUdHRVI6LVBUNU0NCkFDVElPTjpESVNQTEFZDQpE RVNDUklQVElPTjpSZW1pbmRlcg0KRU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRB Ug0K ------=_Part_1024227_1969063014.1588853223513-- From nobody Thu May 7 05:51:57 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BFC3A0657 for ; Thu, 7 May 2020 05:51:56 -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 ARE6GbIZUS5s for ; Thu, 7 May 2020 05:51:55 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150055.outbound.protection.outlook.com [40.107.15.55]) (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 B2CBD3A05E2 for ; Thu, 7 May 2020 05:51:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lEghMnYV+4iU0+Y5o84Xx7wdwtSoregtdL5AUqfC93z84xiBB9X3wJvtp+o0fsj63S/J06AM2cmgQQh+Ywh8R4bniGKTQw9izIIAgZmVG8YurnRC1YuHQ53bNE7ee3Jkeb8HkFL/MHypXKDk40sFhZ5zc+04dHyM4Y2/fLRJWQ0ktADFkKk3d5KvcjLChFbLMl3kkWddYGN8vxsl7HMeI3huL5KHHlK3J+trT3gniLtRD46a+2BEN81e8oIcDGtxTSrZGSbDo047ORBlGftn/kTgYUVjrrfNB78xKhahjcZbQgyHQKMytZ4EdoZU7RpWl96HlhZjkQ9qDdXyIQd5BA== 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=7bfhbjNW/GwsMbf8ck0xc65OHkhccq3WJgAyGN7Mga4=; b=DcNmzYrUn09yREPWTcRo3GwMXEF4ve8V8qzdcHdSJgZlWGRVgXuyCDLWOfQhJhxugfJ+6oJknSB8JvUqObBWEU7F5XUgL12L75vMEO5OgVisJZHwJjsdqYyWF64aLdgpG5m8K7SRzovUHMHf+1BE2hP/jqFGIlHRGXiJkAu968AsKOMgxWQTLn/YAs/Y/3V8Ldcc/YnyBY+OzpzrbGtwUy2U/3WtWWgp+Ld+LCIGJkvR6ix2EFmAVWMUcUNnYiP6sK9wxAv5yFvih/WsI1fPBJvjyLYSqLa8+vmM0QWHLZ1VMFKEDrdeyhGiYQ/TEaBwYVecXPDeffN8JqF4Zn8B+w== 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=7bfhbjNW/GwsMbf8ck0xc65OHkhccq3WJgAyGN7Mga4=; b=Lsp5QKsyBQqbKd4ozLO+rMADis3etme9PZpmPpcqq5bYgF6giUkvUO8vP7UB/r8BjWuyKleFgqNqo5scfITBirYG2JLn80O7eF4LDfFLGJmE2qb/J55OsjBQv0d+Ih0bh3VkRxeuroIh3A89VQqBgkiemYDVcH1MmFM30IVG19s= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0702MB3547.eurprd07.prod.outlook.com (2603:10a6:7:85::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.11; Thu, 7 May 2020 12:51:50 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526%6]) with mapi id 15.20.2979.030; Thu, 7 May 2020 12:51:50 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: [Cbor] Webex meeting changed: CBOR Interim Meeting Thread-Index: AQHWJG5GEgz3dFZaGkK8kNBOI5luww== Date: Thu, 7 May 2020 12:51:50 +0000 Message-ID: <77942163-2A0D-4831-B6C5-380ABFA64F2D@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.36.20041300 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: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f323c1ee-aa16-4ad2-e5cf-08d7f2856915 x-ms-traffictypediagnostic: HE1PR0702MB3547: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 03965EFC76 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: X7g+L6V+xD1ixxaUyGCSuuNQ4qNDDaY5LBL13StT0hYAFSvlLqRn5EihADT91JrJvjnxOkZcQtx93aDyH1wf3RCCx8s97s+uk7CItlksynlX5q/5xfcCnyxUfC8lTMgKAHkmsfUZ++AtKdWI+PcJGQXzZ9JXIribjIcCY99JCN4cg+uK7fGnVuE4ZSCR6sCFaLRPJXmiFShf01UY1iSnVs+PNhuUuhmvLZPOUpqXVv1at4TB/8MwIioWeJ01kUiMVHoumuoKPYPkPttlI5p8VNhtMHukOhlChFkjPV6Wiupk4sRIrsUZgLmVSl/7bfP3P6c2jM43YQj4NVWLqk5DZxGya2xUYKcUL50kMycRorqNXgeny79iwynoYeleK5ZCib2tZCPLD4aK25y8u/4YauKAEhBv6dGIBR3uQPZ8a+gJ/X0H97nm+P3LEkoMmhzRtbfrWHnHUCgZFzD2o/8oCLIO776u4i2qd8OmRobRbswSKg7L/1BkxQIP7vE6lfVfHGTbJYQMxrjdsFPyM0a3ag== 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)(366004)(136003)(376002)(39860400002)(346002)(33430700001)(558084003)(478600001)(33440700001)(33656002)(5660300002)(316002)(6512007)(83300400001)(83320400001)(83280400001)(83310400001)(83290400001)(6916009)(36756003)(8676002)(64756008)(186003)(6486002)(26005)(6506007)(66946007)(44832011)(2616005)(2906002)(76116006)(71200400001)(66446008)(86362001)(66556008)(66476007)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: RboLRj+Mv89gjbfBXxBziDG/l3kCN0L8OmntqAIoix569kjrjwQmET/uUIAWsqxuhmnd6QxU14us4lvKY8/cBEj2SHIRD2sR/lMYe9KtjH1O1DZv8zTe4MvAKfldnWsIWB9LEG+deVMti6g+TdfQsS+6llVJOO50MTUpu/umzovUv8CWdLf88foiD260eft9HAftNM4ZBVdxGeGJtns11yul/9ANsslPxo5N5VfkNPmPCsc8g7viA2LK/WHJuxqrhItQGCsXBEJPkZkhFhqicXHoL6h0CXVNCdA8ZulsO691C/mVU4Lzy+Uye7Vm2eouHa9eTjgmy4d87CrgtuXlE+iA6MYWxMYHQOLZpdD5ERxCLDY5y9Sja4Hh892KLrsCQso+815BcX98kOtz0QwVwqk46DGj1MG5fql9zyWsChNo3NNma4UhXSWD/RLZDSFCGr+kgXtI62ThZObKWxi2hYaxr5YigCw92NlhBnmEuHVtVRrEJjq5BPBvQHVpRaEkFputkWlikUnh3eXQXoAlYWcynOvCJ/CvDnEZUvELIGmlH5Sb17JMcH/8mrw23nuLw6IQqilBBjO5NerLd+buBE2hceJ+4KbOteuJcyOJ2GH5qYkoSGW+1ezRzmELRK2GJQ3ah6ZjCVyYw61CmWbYH2uWAZG8YL+kt6ui0JCdnImOMX3OgmupJ03DXzNCdDsGEUZ7c59C/8MIM2fpYnTIk2sCqfXXDQUyPItWj2AKd49WPhZ+oCb+TUWF3tYfWesaRK/qbO9EXuQaqly2S62XYT4KcJvjzi/yHnGtmieHuNYJ1enwqfzdNGB251ZdFEm+ x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <90BBAD55C53A28409747A475C5D3FDD0@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f323c1ee-aa16-4ad2-e5cf-08d7f2856915 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 12:51:50.2440 (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: O3Z0Xnidschx9VDzlIWG8GLaUDUJnr6Vv05W0VQWwVvCTpBs4GYXV7zTDNYCWuvdEpIBKB7nbCJ5+kiFH1gf9p7K7yAwtzc8CfbcrD+1CBau+no8FNhku1B4EBgwgHLe X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3547 Archived-At: Subject: Re: [Cbor] Webex meeting changed: CBOR Interim Meeting X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 12:51:56 -0000 SGksDQoNClBsZWFzZSBkaXNyZWdhcmQgdGhpcyBlbWFpbC4gSSBuZWVkZWQgdG8gdXBkYXRlIHRo ZSBuYW1lIG9mIHRoZSB3ZWJleCBzZXJpZSB0byBzaW1wbGlmeSB1cGxvYWRpbmcgdGhlIGludGVy aW0gbWVldGluZ3MgdG8gWW91dHViZSBieSB0aGUgU2VjcmV0YXJpYXQuDQoNClRoYW5rcywNCkZy YW5jZXNjYQ0KDQo= From nobody Thu May 7 10:57: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 E81E83A081F for ; Thu, 7 May 2020 10:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cPwTknBk6jL for ; Thu, 7 May 2020 10:57:03 -0700 (PDT) Received: from p3plsmtpa07-05.prod.phx3.secureserver.net (p3plsmtpa07-05.prod.phx3.secureserver.net [173.201.192.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927713A0816 for ; Thu, 7 May 2020 10:57:03 -0700 (PDT) Received: from [192.168.1.34] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id WklajQIMZnixGWklajo7Ok; Thu, 07 May 2020 10:57:03 -0700 X-CMAE-Analysis: v=2.3 cv=EId4LGRC c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=gKmFwSsBAAAA:8 a=l70xHGcnAAAA:8 a=oGbIuagOAAAA:20 a=48vgC7mUAAAA:8 a=MyrpCqbCbTeHI8NfTcAA:9 a=glFH8JdS2aZt9yrC:21 a=w6Ru0WYD7LVBO0l3:21 a=QEXdDO2ut3YA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=JtN_ecm89k2WOvw5-HMO:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Laurence Lundblade In-Reply-To: <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> Date: Thu, 7 May 2020 10:57:02 -0700 Cc: Michael Richardson , cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3608.80.23.2.2) X-CMAE-Envelope: MS4wfKmPXPz+wSjpthlnONPdwBLvr5NxuPbhiu9INDWHcVgW6gyzb+QtqTfCecV29CUct/wlu0tk6kOnO6s1bK4J2Fjdhgws3xEJz8p9U45jm+Gs7tUh2tJd vpmO2NfBKw4NiscNP/+wj0JAKITsiBE1POeF5WTq38IMOfXS7x/atDMi2Spb8dV7mgGxpHCSOphodrFt4UrDnBYqqbjITjrBRuZFjRWy/Qcx5vZkWi1igB+s Archived-At: Subject: Re: [Cbor] RFC7049bis processing of unknown tags 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, 07 May 2020 17:57:06 -0000 The upshot seems to be, that if you put a tag into encoded CBOR you = better really mean it, because you can=E2=80=99t count on it being = ignored by apps and/or decoders that don=E2=80=99t understand it. Tags = are not like HTTP or RFC 822 headers where unknowns are explicitly to be = ignored. Looking through the registered tags, most define a new data type. In = most cases decoders can=E2=80=99t ignore the new type and successfully = implement the protocol using it. Also, in the registry, just a few tags are conversion hints. These seem = like the ones to ignore because 1) they are hints and 2) the decoder = might not be converting them and 3) applicability is only in certain = operating environments. However, there is no way to generically know if a tag is a hint, = particularly for newly defined tags, so decoders and apps can=E2=80=99t = be counted on to ignore even hints and it comes back to the same. One = can=E2=80=99t expect tags to be ignored, so don=E2=80=99t put them in = unless they are really necessary. Probably a good thing to discourage = rampant use of gratuitous tagging. LL > On May 6, 2020, at 9:06 AM, Carsten Bormann wrote: >=20 > Hi Michael, >=20 > Thank you for your interjection at the CBOR interim. > I think this is a good issue to roll up. >=20 > On 2020-05-06, at 17:32, Michael Richardson = wrote: >>=20 >>=20 >> After discussion about #176/#181 I submitted #182: >>=20 >> https://github.com/cbor-wg/CBORbis/issues/182 >>=20 >> RFC7049 specified that CBOR tags which were not recognized should be = ignored. >=20 > That is not exactly what it says: >=20 > (3.5) > A decoder that comes across a tag (Section 2.4) that it does not > recognize, such as a tag that was added to the IANA registry after > the decoder was deployed or a tag that the decoder chose not to > implement, might issue a warning, might stop processing altogether, > might handle the error and present the unknown tag value together > with the contained data item to the application (as is expected of > generic decoders), might ignore the tag and simply present the > contained data item only to the application, or take some other type > of action. >=20 > So there always was a choice. > Note that there always was a preference to present the unknown tag to = the application, for =E2=80=9Cgeneric decoders=E2=80=9D; i.e., the = choice is more for application-specific decoders. >=20 >> RFC7049bis wishes to change this behaviour such that unknown tags = would not >> be ignored, but would at least, be presented to the application for = further >> determination. This is a change that would render existing CBOR = parsers >> instantly invalid. >=20 > A change that would remove the choice is not what was intended so far, = just increased emphasis on the options: >=20 > =E2=80=94 1 might issue a warning,=20 > =E2=80=94 2 might stop processing altogether, > =E2=80=94 3 might handle the error and present the unknown tag value = together > with the contained data item to the application (as is expected of > generic decoders),=20 >=20 > as opposed to >=20 > =E2=80=94 4 might ignore the tag and simply present the > contained data item only to the application, or=20 > =E2=80=94 5 take some other type > of action. >=20 > Generally, it is a good idea if users of a library know what they will = get, so the behavior to be expected needs to be documented. A generic = decoder that only does 3 (as is =E2=80=9Cexpected=E2=80=9D) will be the = most interoperable one. >=20 > There are two pieces of text in 7049bis that may not entirely be = aligned: >=20 > (3.4:) > Decoders do not need to understand tags of every tag number, and = tags > may be of little value in applications where the implementation > creating a particular CBOR data item and the implementation decoding > that stream know the semantic meaning of each item in the data flow. > Their primary purpose in this specification is to define common data > types such as dates. A secondary purpose is to provide conversion > hints when it is foreseen that the CBOR data item needs to be > translated into a different format, requiring hints about the = content > of items. Understanding the semantics of tags is optional for a > decoder; it can simply present both the tag number and the tag > content to the application, without interpreting the additional > semantics of the tag. >=20 > But also: >=20 > (7.1:) > CBOR has three major extension points: >=20 > [=E2=80=A6] >=20 > * the "tag" space (values in major type 6). Again, only a small > part of the codepoint space has been allocated, and the space is > abundant (although the early numbers are more efficient than the > later ones). Implementations receiving an unknown tag number can > choose to simply ignore it (process just the enclosed tag = content) > or to process it as an unknown tag number wrapping the tag > content. The IANA registry in Section 9.2 is the appropriate way > to address the extensibility of this codepoint space. >=20 >> The suggestion is that parsers should be in RFC7049 mode by default, >=20 > But there is no RFC 7049 mode =E2=80=94 there is a choice. >=20 >> and >> applications that want RFC7049bis behaviour should initialize the = parser with >> an option that enables it [or use a new parser with awareness]. >=20 > It definitely is a good idea to either always get behavior 3, or to = provide flags that control the behavior. >=20 >> Applications that want to make use of tags defined in RFC7049bis need = to put >> the parser in RFC7049bis mode. >=20 > RFC7049bis does not define any new tags (so far). >=20 >> I think that Carsten does not agree with my suggested solution, but = I'm not >> attached to it. >=20 > I hope I have explained how the situation is a bit more nuanced than = might have come over in the meeting. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Thu May 7 11:46:20 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 DC73A3A0883 for ; Thu, 7 May 2020 11:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03gcIWuUbRMx for ; Thu, 7 May 2020 11:46:15 -0700 (PDT) Received: from p3plsmtpa12-03.prod.phx3.secureserver.net (p3plsmtpa12-03.prod.phx3.secureserver.net [68.178.252.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FB03A087D for ; Thu, 7 May 2020 11:46:15 -0700 (PDT) Received: from [192.168.1.34] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id WlXCjDb08z9SEWlXCj9qpZ; Thu, 07 May 2020 11:46:15 -0700 X-CMAE-Analysis: v=2.3 cv=HeVqsRM8 c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=u_KS9xM8wRvn8V2lsNYA:9 a=QEXdDO2ut3YA:10 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: Date: Thu, 7 May 2020 11:46:14 -0700 To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-CMAE-Envelope: MS4wfPXFr+3T9nCGBbbxWErSKMggLKPODYxPZF6mBSzYez3mvau/ceCQ6618U0nPeRP3Q04dZYiS8+8vAgyQ+xdkyps61RxRZltf3jUiB6aNQBaVc8cdQS43 salSpP/Hu+RQxz+BF6NNTnegB6DrC0LDBNItnxKmKcc9XPG9bYVnKQ71 Archived-At: Subject: [Cbor] Conflicting tags 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, 07 May 2020 18:46:18 -0000 I am after comments and wisdom on what to do when encountering a data = item with conflicting tags, say one that is tagged both a positive and = negative bignum (both byte strings), or one that is tagged as both a CWT = and a decimal fraction (both arrays). Just passing the tag up to the next layer can=E2=80=99t be the answer = because that is just passing the error condition along, not detecting = it. I think it needs to be detected and handled. The context for my question is a generic decoder that does full decoding = of many of the tags itself rather than just passing a tag indicator up. = For example, C supports arrays of integers natively, so it would be good = for a generic decoder to decode some RFC 8746 tags to a C array of = integers. It seems reasonable to detect conflicts for the tags that are known and = handled. Maybe a little messy, but possible, even for dozens of them or = even for most of the registered tags. The question is what to do about = unknown tags. My thought is the the implementation considers some of the known tags to = be hints and others to be new type definitions. The hint tags are = usually the ones for suggested conversions.=20 The apply the following: - Data item with only unknown tags: pass all the tags up - Data item with known data type tag that will be fully decoded, plus an = unknown tag: this is an error - Data item with with hint tags that are being passed up and unknown = tags: pass all the tags up Thanks for thoughts and comments! LL From nobody Thu May 7 11:55: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 EA2AE3A0893 for ; Thu, 7 May 2020 11:55: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 95fwGD2LPwOh for ; Thu, 7 May 2020 11:55: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 A6CF33A088E for ; Thu, 7 May 2020 11:55:30 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49J2hw3hZWzyqh; Thu, 7 May 2020 20:55:28 +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, 7 May 2020 20:55:28 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 610570528.054782-147b26a001fd2cd2e36b61485f7bbf22 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Conflicting tags 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, 07 May 2020 18:55:37 -0000 On 2020-05-07, at 20:46, Laurence Lundblade = wrote: >=20 > I am after comments and wisdom on what to do when encountering a data = item with conflicting tags, say one that is tagged both a positive and = negative bignum (both byte strings), or one that is tagged as both a CWT = and a decimal fraction (both arrays). Cannot happen, I=E2=80=99d say. The outer tag is tagging the inner tag. But Tag 2 and Tag 3 are both defined only for byte strings, so the outer = tag has a wrong type as its value. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 7 15:50:12 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DEE3A0E2B for ; Thu, 7 May 2020 15:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9wN3mme-SLk for ; Thu, 7 May 2020 15:50:04 -0700 (PDT) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 A1D403A0DD0 for ; Thu, 7 May 2020 15:50:04 -0700 (PDT) Received: by mail-qv1-xf34.google.com with SMTP id v10so3577701qvr.2 for ; Thu, 07 May 2020 15:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xebqd2t+sGm/Z+9wevzOVnhLk13hPdgNomoPgmgB4uM=; b=bYE00rsUbyyZNTnY/jT+BupAL5/oVFpHbYpU1n7heyz57HZhCqEUCXms4CNSCdt2l4 Vua1C4yMSiIJSjMVYkXzYMP9SKku/TjyjI1RtobOcvwn6zLs9hmnSMGwGx3KdgxXxxYi aHuoyLcJuP8lY8/qTOu77ghQHqFaVOKr5jrxQ= 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=xebqd2t+sGm/Z+9wevzOVnhLk13hPdgNomoPgmgB4uM=; b=jwyePUcb31dPNS1aaIsXnGPh0eqjH2/SvB/PQEjEssV5GH6yQQA26Aqx9L9Z0Ut3rt m+o5kFaOZ7+DZu7r/looyTcpfpO/iXiio2tfKH6oj8KLIFGbd4D1gtleGf58R4dWdeUF 4/HD/ntlyUyPRtVmZcjD33csis2etb/Z7KVSfdBiEJZwNQvcknQKsAApX8GBy9Wz/WvY 6NPbdOmhgV4funjVgNl1VceqoZ8kBbNyhABO7232Mn/lGO+i2QtcuUKXhJE1bUPnu4Vm fJdY6Mc5LOA053P9I6XA+VgTxxCr9QYIntdZqx2azxX83g37EGzseavnwEEnld6KcTHD USgA== X-Gm-Message-State: AGi0PuYuamprrirwYpqcNSnJ7cEbOlC2vG1dTh4h+fL0WyZC6QFErc/K hp3DsxSYvwWC74odAo400LsUli8SmKlguvambhE93Q== X-Google-Smtp-Source: APiQypKUHplolg1J+BD0pLRgIjYMz7Nu9IRCHPul29ScOV0E4kTI0viGlPYlN3jPGTGR3MVpSqs8BzsSnmIHPhVx2ho= X-Received: by 2002:a0c:c987:: with SMTP id b7mr6423676qvk.20.1588891802856; Thu, 07 May 2020 15:50:02 -0700 (PDT) MIME-Version: 1.0 References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> In-Reply-To: <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> From: Jeffrey Yasskin Date: Thu, 7 May 2020 15:49:50 -0700 Message-ID: To: Carsten Bormann Cc: Michael Richardson , cbor@ietf.org Content-Type: multipart/alternative; boundary="0000000000007f82c405a516b334" Archived-At: Subject: Re: [Cbor] RFC7049bis processing of unknown tags 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, 07 May 2020 22:50:11 -0000 --0000000000007f82c405a516b334 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think at least some of this change was my doing, so I'll send three opinions. 1) I should have changed the text in 7.1, "Implementations receiving an unknown tag number can choose to simply ignore it (process just the enclosed tag content)", and I must have just missed it. 2) I don't think it makes sense for any parser to see a tag and give the application its contents instead of the tagged contents. That said, this is a change that does make some RFC7049-compliant parsers non-compliant with RFC7049-bis, which is a downside. On the third hand, the parsers will still exist, applications using them don't need to upgrade if it breaks their protocol. 3) While RFC7049-bis is already somewhat overstepping the bounds of a standard in specifying error-handling options, it'd be even farther out of bounds to specify parser API options. :) Jeffrey On Wed, May 6, 2020 at 9:07 AM Carsten Bormann wrote: > Hi Michael, > > Thank you for your interjection at the CBOR interim. > I think this is a good issue to roll up. > > On 2020-05-06, at 17:32, Michael Richardson wrote= : > > > > > > After discussion about #176/#181 I submitted #182: > > > > https://github.com/cbor-wg/CBORbis/issues/182 > > > > RFC7049 specified that CBOR tags which were not recognized should be > ignored. > > That is not exactly what it says: > > (3.5) > A decoder that comes across a tag (Section 2.4) that it does not > recognize, such as a tag that was added to the IANA registry after > the decoder was deployed or a tag that the decoder chose not to > implement, might issue a warning, might stop processing altogether, > might handle the error and present the unknown tag value together > with the contained data item to the application (as is expected of > generic decoders), might ignore the tag and simply present the > contained data item only to the application, or take some other type > of action. > > So there always was a choice. > Note that there always was a preference to present the unknown tag to the > application, for =E2=80=9Cgeneric decoders=E2=80=9D; i.e., the choice is = more for > application-specific decoders. > > > RFC7049bis wishes to change this behaviour such that unknown tags would > not > > be ignored, but would at least, be presented to the application for > further > > determination. This is a change that would render existing CBOR parsers > > instantly invalid. > > A change that would remove the choice is not what was intended so far, > just increased emphasis on the options: > > =E2=80=94 1 might issue a warning, > =E2=80=94 2 might stop processing altogether, > =E2=80=94 3 might handle the error and present the unknown tag value toge= ther > with the contained data item to the application (as is expected of > generic decoders), > > as opposed to > > =E2=80=94 4 might ignore the tag and simply present the > contained data item only to the application, or > =E2=80=94 5 take some other type > of action. > > Generally, it is a good idea if users of a library know what they will > get, so the behavior to be expected needs to be documented. A generic > decoder that only does 3 (as is =E2=80=9Cexpected=E2=80=9D) will be the m= ost interoperable > one. > > There are two pieces of text in 7049bis that may not entirely be aligned: > > (3.4:) > Decoders do not need to understand tags of every tag number, and tags > may be of little value in applications where the implementation > creating a particular CBOR data item and the implementation decoding > that stream know the semantic meaning of each item in the data flow. > Their primary purpose in this specification is to define common data > types such as dates. A secondary purpose is to provide conversion > hints when it is foreseen that the CBOR data item needs to be > translated into a different format, requiring hints about the content > of items. Understanding the semantics of tags is optional for a > decoder; it can simply present both the tag number and the tag > content to the application, without interpreting the additional > semantics of the tag. > > But also: > > (7.1:) > CBOR has three major extension points: > > [=E2=80=A6] > > * the "tag" space (values in major type 6). Again, only a small > part of the codepoint space has been allocated, and the space is > abundant (although the early numbers are more efficient than the > later ones). Implementations receiving an unknown tag number can > choose to simply ignore it (process just the enclosed tag content) > or to process it as an unknown tag number wrapping the tag > content. The IANA registry in Section 9.2 is the appropriate way > to address the extensibility of this codepoint space. > > > The suggestion is that parsers should be in RFC7049 mode by default, > > But there is no RFC 7049 mode =E2=80=94 there is a choice. > > > and > > applications that want RFC7049bis behaviour should initialize the parse= r > with > > an option that enables it [or use a new parser with awareness]. > > It definitely is a good idea to either always get behavior 3, or to > provide flags that control the behavior. > > > Applications that want to make use of tags defined in RFC7049bis need t= o > put > > the parser in RFC7049bis mode. > > RFC7049bis does not define any new tags (so far). > > > I think that Carsten does not agree with my suggested solution, but I'm > not > > attached to it. > > I hope I have explained how the situation is a bit more nuanced than migh= t > have come over in the meeting. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > --0000000000007f82c405a516b334 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think at least some of this change was = my doing, so I'll send three opinions.

=
1) I should have changed the text in 7.1, "Implementations receiv= ing an unknown tag number can choose to simply ignore it (process just the = enclosed tag content)", and I must have just missed it.
2) I= don't think it makes sense for any parser to see a tag and give the ap= plication its contents instead of the tagged contents. That said, this is a= change that does make some RFC7049-compliant parsers non-compliant with RF= C7049-bis, which is a downside. On the third hand, the parsers will still e= xist, applications using them don't need to upgrade if it breaks their = protocol.
3) While RFC7049-bis is already somewhat overstepping t= he bounds of a standard in specifying error-handling options, it'd be e= ven farther out of bounds to specify parser API options. :)

<= /div>
Jeffrey

On Wed, May 6, 2020 at 9:07 AM Carsten Bormann <cabo@tzi.org> wrote:
Hi Michael,

Thank you for your interjection at the CBOR interim.
I think this is a good issue to roll up.

On 2020-05-06, at 17:32, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>
>
> After discussion about #176/#181 I submitted #182:
>
> https://github.com/cbor-wg/CBORbis/issues/182<= br> >
> RFC7049 specified that CBOR tags which were not recognized should be i= gnored.

That is not exactly what it says:

(3.5)
=C2=A0 =C2=A0A decoder that comes across a tag (Section 2.4) that it does n= ot
=C2=A0 =C2=A0recognize, such as a tag that was added to the IANA registry a= fter
=C2=A0 =C2=A0the decoder was deployed or a tag that the decoder chose not t= o
=C2=A0 =C2=A0implement, might issue a warning, might stop processing altoge= ther,
=C2=A0 =C2=A0might handle the error and present the unknown tag value toget= her
=C2=A0 =C2=A0with the contained data item to the application (as is expecte= d of
=C2=A0 =C2=A0generic decoders), might ignore the tag and simply present the=
=C2=A0 =C2=A0contained data item only to the application, or take some othe= r type
=C2=A0 =C2=A0of action.

So there always was a choice.
Note that there always was a preference to present the unknown tag to the a= pplication, for =E2=80=9Cgeneric decoders=E2=80=9D; i.e., the choice is mor= e for application-specific decoders.

> RFC7049bis wishes to change this behaviour such that unknown tags woul= d not
> be ignored, but would at least, be presented to the application for fu= rther
> determination. This is a change that would render existing CBOR parser= s
> instantly invalid.

A change that would remove the choice is not what was intended so far, just= increased emphasis on the options:

=E2=80=94 1 might issue a warning,
=E2=80=94 2 might stop processing altogether,
=E2=80=94 3 might handle the error and present the unknown tag value togeth= er
=C2=A0 =C2=A0with the contained data item to the application (as is expecte= d of
=C2=A0 =C2=A0generic decoders),

as opposed to

=E2=80=94 4 might ignore the tag and simply present the
=C2=A0 =C2=A0contained data item only to the application, or
=E2=80=94 5 take some other type
=C2=A0 =C2=A0of action.

Generally, it is a good idea if users of a library know what they will get,= so the behavior to be expected needs to be documented.=C2=A0 A generic dec= oder that only does 3 (as is =E2=80=9Cexpected=E2=80=9D) will be the most i= nteroperable one.

There are two pieces of text in 7049bis that may not entirely be aligned:
(3.4:)
=C2=A0 =C2=A0Decoders do not need to understand tags of every tag number, a= nd tags
=C2=A0 =C2=A0may be of little value in applications where the implementatio= n
=C2=A0 =C2=A0creating a particular CBOR data item and the implementation de= coding
=C2=A0 =C2=A0that stream know the semantic meaning of each item in the data= flow.
=C2=A0 =C2=A0Their primary purpose in this specification is to define commo= n data
=C2=A0 =C2=A0types such as dates.=C2=A0 A secondary purpose is to provide c= onversion
=C2=A0 =C2=A0hints when it is foreseen that the CBOR data item needs to be<= br> =C2=A0 =C2=A0translated into a different format, requiring hints about the = content
=C2=A0 =C2=A0of items.=C2=A0 Understanding the semantics of tags is optiona= l for a
=C2=A0 =C2=A0decoder; it can simply present both the tag number and the tag=
=C2=A0 =C2=A0content to the application, without interpreting the additiona= l
=C2=A0 =C2=A0semantics of the tag.

But also:

(7.1:)
=C2=A0 =C2=A0CBOR has three major extension points:

=C2=A0 =C2=A0[=E2=80=A6]

=C2=A0 =C2=A0*=C2=A0 the "tag" space (values in major type 6).=C2= =A0 Again, only a small
=C2=A0 =C2=A0 =C2=A0 part of the codepoint space has been allocated, and th= e space is
=C2=A0 =C2=A0 =C2=A0 abundant (although the early numbers are more efficien= t than the
=C2=A0 =C2=A0 =C2=A0 later ones).=C2=A0 Implementations receiving an unknow= n tag number can
=C2=A0 =C2=A0 =C2=A0 choose to simply ignore it (process just the enclosed = tag content)
=C2=A0 =C2=A0 =C2=A0 or to process it as an unknown tag number wrapping the= tag
=C2=A0 =C2=A0 =C2=A0 content.=C2=A0 The IANA registry in Section 9.2 is the= appropriate way
=C2=A0 =C2=A0 =C2=A0 to address the extensibility of this codepoint space.<= br>
> The suggestion is that parsers should be in RFC7049 mode by default,
But there is no RFC 7049 mode =E2=80=94 there is a choice.

> and
> applications that want RFC7049bis behaviour should initialize the pars= er with
> an option that enables it [or use a new parser with awareness].

It definitely is a good idea to either always get behavior 3, or to provide= flags that control the behavior.

> Applications that want to make use of tags defined in RFC7049bis need = to put
> the parser in RFC7049bis mode.

RFC7049bis does not define any new tags (so far).

> I think that Carsten does not agree with my suggested solution, but I&= #39;m not
> attached to it.

I hope I have explained how the situation is a bit more nuanced than might = have come over in the meeting.

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

_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
--0000000000007f82c405a516b334-- From nobody Thu May 7 16:42:27 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86373A0889 for ; Thu, 7 May 2020 16:42: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 DnSavFnKf9bT for ; Thu, 7 May 2020 16:42:23 -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 165073A0865 for ; Thu, 7 May 2020 16:42:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8A4263898C; Thu, 7 May 2020 19:40:20 -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 2hawsYl54T7A; Thu, 7 May 2020 19:40:19 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 376013898B; Thu, 7 May 2020 19:40:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7E79558B; Thu, 7 May 2020 19:42:19 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org cc: Carsten Bormann , Jeffrey Yasskin In-Reply-To: References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@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] RFC7049bis processing of unknown tags 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, 07 May 2020 23:42:26 -0000 --=-=-= Content-Type: text/plain Jeffrey Yasskin wrote: > 3) While RFC7049-bis is already > somewhat overstepping the bounds of a standard in specifying > error-handling options, it'd be even farther out of bounds to specify > parser API options. :) I disagree strongly with this part :-) It's is a regular and common mistake in IETF/many specifications that they do not adequately explain what the behaviour is supposed to be when a newer option shows up. We probably spend 70% of our time at the IETF making sure that we don't break old code. Is that too high? Well, maybe, because we don't spend the effort up-front. As an example: IKE (IPsec) has a major and minor version. We have no idea what it would mean to increment the minor version. Having a minor version was a waste of time. (I crafted the text for the VendorID payload in IKEv1. I believe that I got it right, and made sure that we could make use of private extensions without conflicts in the number space) As for API options, yes, we often do need to give advice on providing ways to put things into compatibility mode, and what that means. At no point are we writing down some enum or #define though. I believe that I am less concerned about having rfc7049bis render some existing parsers "non-compliant" --- they *ARE* still compliant to RFC7049. I am a user of parsers, I have occasionally had to write my own conversions, but mostly I would say that I am not up to speed on some of the details. -- ] 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 [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl60nNsACgkQgItw+93Q 3WUrDwf9GY407dcS+T+pU8n8vI0qXTaPVRIPn+L6an9KN8Pko2/ZWcm17QbOjsOs BvlbO4S+sxPtaBGI0iaB4jrwBv48e3AmgCA952IJrd3X2X3RRe7tPZlTdTrHu8VI g12MXhmT6HyboeYeFGlYrsUMrGh0FyWT1IFwUhsk0HCngf3jv0qaIGM3NLngu1RM 3ppNw0/BVP7+W/vxeup2B26dOVx4QKFDx8Ts0o2Hu4fWQHuZv9egqa8AzF/GhyBI xIeWRlWnUxwE3JWel6ixSKrk6qCK6NNnhrDRlKdE8fSGfAxpfUVVBx2PNLGz7C6Y VjlhihqR1cm5UhPi2YCgbHdsLZKz4g== =Tls8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 7 19:18: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 2817F3A0C26; Thu, 7 May 2020 19:18:04 -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 grFklhHjP5Pb; Thu, 7 May 2020 19:18:01 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650129.outbound.protection.outlook.com [40.107.65.129]) (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 DCB4C3A0C16; Thu, 7 May 2020 19:18:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eWcwSqudp6NDUgCE4h9jsrSpzDNXNl8Cso+5n4kialpDhgs7KLMuefzDvke1USCfOkf774GkW/mBEtsFMbNxdV6eMuYxzaWMgpzjdfDsl7Mu5K+3tvqY9Xz8ApYp+dKNt3LAp/qAdXX9iciI8HNJI4EFmrdPICmt5qmcgHTJ47Wr0N7aWhBrWc+YrZ05Hsq67J2vmT1MC2dMUnfwuR3p6PqMTFZSfURrGYh3iZDsiiTRG8xZ09DXaeFz/3hYW66fw12rI431PMUNHHRLNJ8O+r2UR9yx+yavYHLEoJbvlbOdRYtGF17K/QwVKQcEF3u8+/Vf42xbnx9EJckhfwpzlw== 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=tZDvyqr+6z9ECxqS/g1PoYq2tf4bHuUqWWPx2n/fulg=; b=eUlBxKzyEHofD03ywM37J0xh8SiUeeaWERF86mOsQ9KvTNghck4NFTFEOj9wrsCskuKX49K6+dg2mEgtiFtU3gEeGtU1bad/qLkCGp0ncb/qlMx+/e1jtFtSzX0JLqUlkbkBtb5glmklDT6geJOMzfXOaPOAsMjvGHfzptwYHkwsd6lAeG4rSOTTmv9I09N2oPF+pNhNC2knGrSCZtzz1yepgMVgaYRZLRCN0g8Rp34mbO0svLe8t4+U6Sn4BcO8LpEPjzlKe/BYz8PiRzu0Sz8UV/E0fDTQ8atpqkhHQqXRsWmvWq0Yhl7fDKpTJmE93koG1bL+jDeTwlYxV4m7Sw== 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=tZDvyqr+6z9ECxqS/g1PoYq2tf4bHuUqWWPx2n/fulg=; b=fqOVHMbl6jerQRbLoPy0EC1WqA2VaYJEmwfv2sWBccSZJzafERegLwadY85K/zcbd2f9aUzvuxn0tkv88XfmAxGiNHQKvdoOaZajVSXGM7hBEWpN7qkeOQJotb2T1h3HufN3wcXLeYyD3nN9/PdzfbifWSnUHytmfkxAA3Sc2kE= Received: from BY5PR00MB0676.namprd00.prod.outlook.com (2603:10b6:a03:20c::15) by BY5PR00MB0806.namprd00.prod.outlook.com (2603:10b6:a03:1dc::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3016.0; Fri, 8 May 2020 02:17:58 +0000 Received: from BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::7d21:c7e9:3141:cf8d]) by BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::7d21:c7e9:3141:cf8d%9]) with mapi id 15.20.3020.000; Fri, 8 May 2020 02:17:58 +0000 From: Mike Jones To: Francesca Palombini , "cbor@ietf.org" , "draft-jones-cbor-date-tag@ietf.org" CC: "cbor@ietf.org" Thread-Topic: =?utf-8?B?W0Nib3JdIPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBvZiBkcmFmdC1q?= =?utf-8?Q?ones-cbor-date-tag?= Thread-Index: AQHWI9FpGl0odfL7skutaRcX5SmccqiddWCg Date: Fri, 8 May 2020 02:17:57 +0000 Message-ID: References: <7075cf11-08c2-6234-bb77-c566f1879b2f@sit.fraunhofer.de> 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=2e2228dd-2f82-4d1f-8125-00004830866f; 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-05-08T02:15:14Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; 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: a72eb0e5-8781-41a1-1a41-08d7f2f60683 x-ms-traffictypediagnostic: BY5PR00MB0806: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 039735BC4E x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 79TD7iVqCeEUubTsYOI/KKlVLwrvfv+xg3dqJiCUrlis9OfET7mn3+7HU7tAMY+OvX9k4nsAhgC9BZjl/wvDGqvvcytpiZ25SKy3LSqi00IoHElEAN24zFtjd/kudERReU+KoAvhnkdianDfsNGQEavGueQKnsviLUweh43spxlAoIxAEk5pbdcGHL1LxS/ep1ypCQQaWMlGtIEV7uBYC4VJxWF1sv07pfFOLRJ+ABwBqTEHP5z5agQBXKEEJsv3iOMedqGU6TJDAeeucS6k0L14eD2EzR3ekAo9/BLjl5LcTQkYcNrVfmcQKu+1H5ELOFjLS0l0Y3gKkFxfzt1h3BIiZVwd9at8DUbSrIUXBsVCGzLqZeTA0JtpespwQgD5MHXqUv0onyKWS1FJZm0uaDGyEEicPLM7v2M17kQaoK/hn+d6HTDjC07T2GztUrJPA92HpT7zkuu5G4H/9MmgUlNRd75RuXEdXTTMwMSVgV8= 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)(346002)(396003)(366004)(376002)(39860400002)(136003)(33430700001)(966005)(5660300002)(66556008)(8990500004)(6506007)(10290500003)(82950400001)(82960400001)(66476007)(7696005)(76116006)(26005)(33656002)(4326008)(316002)(66446008)(110136005)(86362001)(2906002)(8936002)(53546011)(64756008)(52536014)(186003)(66946007)(71200400001)(9686003)(83320400001)(83280400001)(83310400001)(478600001)(83290400001)(83300400001)(55016002)(33440700001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ehVVvF5gyrOGGMjoebUah3fjquA37GYWYozSwgrZndDc4Zd75ajzcYXZuqwFs2cOT3ZwMw/pC5pu8ph4HwRb9uLXhevXRmHlqxzlvWR31cbWGp2+rfAe2AkEUMf+HMEMWECxgOaZ9leG9UEZs1CIKnojEkyY80D3cNT1J4jE2KUfz7l3emzaKhS/g8/ggy+N46tN5/H0E+xWL51OSImiiDrsnb6BPAvFcRTvqLjJ3SHdCaw7GktdfeTcymJ4p9gPpBHyX9niPMOfCfjARGGe8wL8B7plU9FpV6Kg6fawpkhjlPozGM0Is2eUbM5nadw2P66hwyCQt0yiyuWYu3i2VDLQj/trhakw0tprzN1XHXwNMWhXdI1VUe3iheAjGpn+ULeNYTFSSqI2bBlYNotcBRRC+cf6c4jajQJq/fuLZ+uaqGwT3ZOkfvvDle0eHbYM1JNgnL9aEBJFWrunXd4GiY9sg9ooOVnugy0DA4tCzddSHvMXhwhMMn2FbX7UilC5kXmPAw969133UrCy2j/ppEX+PT1sq2p6bJspYgOrArHflYz+OHbiMx0MDuPWXJxJZzj12JR7GmrNb6KZBxycaNfYVFqdCYzCI5gEEktpNqPGGk/nYII/kvDg+oHjDh9k4/CxOwr1byIJPIsUx8sO2Cw5Z04rgN1Fm1o0/q0kATi2u2dezIRZBCKXYj2pJzEr76i8Hc48d2jrVFEDBPzemmrci65RRFU7oQQPTeKE8mkZTYFUgGWErMm9y6yxIOxcBzDfvTlqiXxRv4GErJoM5/sGqNSW0RxgfNa9E6plIrM= 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: a72eb0e5-8781-41a1-1a41-08d7f2f60683 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 02:17:57.9763 (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: BE2y3tszOzocLxyIc3fnh7+P1xXdjga+PvDLaR/zhdevwhaS4VCPYSyVh+gqVpR/a9NuzgE6AoNs1sSCAIXZmw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR00MB0806 Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-jo?= =?utf-8?q?nes-cbor-date-tag?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 02:18:05 -0000 SSd2ZSBwb3N0ZWQgZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTAwLCB3aGljaCBpcyBjdXJyZW50 bHkgYXdhaXRpbmcgYXBwcm92YWwgb2YgdGhlIGNoYWlycy4gIEl0IGNvbnRhaW5zIG5vIG5vcm1h dGl2ZSBjaGFuZ2VzIGZyb20gZHJhZnQtam9uZXMtY2Jvci1kYXRlLXRhZy0wMS4gIEFsc28sIGNh biB5b3UgcGxlYXNlIHVwZGF0ZSB0aGUgZGF0YXRyYWNrZXIgdG8gc2F5IHRoYXQgdGhpcyB2ZXJz aW9uIHJlcGxhY2VzIGRyYWZ0LWpvbmVzLWNib3ItZGF0ZS10YWcuDQoNCkknbGwgYWRkcmVzcyBD YXJzdGVuIGNvbW1lbnRzIGluIC0wMS4NCg0KCQkJCVRoYW5rcywNCgkJCQktLSBNaWtlDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFu Y2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbT4gDQpTZW50OiBXZWRuZXNkYXksIE1heSA2LCAy MDIwIDExOjA5IEFNDQpUbzogY2JvckBpZXRmLm9yZzsgZHJhZnQtam9uZXMtY2Jvci1kYXRlLXRh Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtDYm9yXSDwn5SUIFdvcmtpbmcgR3JvdXAgQWRvcHRp b24gb2YgZHJhZnQtam9uZXMtY2Jvci1kYXRlLXRhZw0KDQpUaGlzIGNvbmNsdWRlcyB0aGUgYWRv cHRpb24gY2FsbC4gIEFzIG1lbnRpb25lZCBkdXJpbmcgdGhlIGludGVyaW0sIGFsbCByZXNwb25z ZSB3YXMgcG9zaXRpdmUgc28gdGhlIGRvY3VtZW50IGhhcyBiZWVuIGFkb3B0ZWQuDQoNCk1pa2Us IHBsZWFzZSByZS1wdWJsaXNoIHVzaW5nIGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wMC4NCg0K KEFsc28sIHBsZWFzZSBzZWUgdGhlIGNvbW1lbnQgaW4gdGhlIG1haWxpbmcgbGlzdCBmcm9tIENh cnN0ZW4sIGlmIHlvdSBoYXZlbid0IGFscmVhZHksIGFzIG5vdGVkIGR1cmluZyB0aGUgaW50ZXJp bSkuDQoNCkppbSAmIEZyYW5jZXNjYQ0KDQrvu79PbiAwNS8wNS8yMDIwLCAxMjoyMiwgIkhlbmsg Qmlya2hvbHoiIDxoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPiB3cm90ZToNCg0KICAg IEkgMm5kIHRoZSBhZG9wdGlvbiwNCg0KICAgIHRoZSBJLUQgaXMgc3RyYWlnaHQgZm9yd2FyZCwg ZG9lcyBub3Qgc2VlbSB0byBiZSBjb250cm92ZXJzaWFsIHRvIG1lLCANCiAgICBhbmQgdGhlcmUg aXMgdGhlIGVudGFuZ2xlbWVudCB3aXRoIElTTyB0aGF0IHNob3VsZCBkcml2ZSB1cyB0byBtb3Zl IHRoaXMgDQogICAgZm9yd2FyZC4NCg0KICAgIFZpZWxlIEdyw7zDn2UsDQoNCiAgICBIZW5rDQoN CiAgICBPbiAwNC4wNS4yMCAyMzoxNSwgQ2Fyc3RlbiBCb3JtYW5uIHdyb3RlOg0KICAgID4gSGkg RnJhbmNlc2NhLA0KICAgID4gDQogICAgPiBqdXN0IG1ha2luZyBzdXJlIHRvIGV4cHJlc3MgZXhw bGljaXRseSB0aGF0IEnigJltIHN0aWxsIHBhcnQgb2YgdGhlIGluLXJvb20gY29uc2Vuc3VzIHRv IGFkb3B0IHRoaXMgZHJhZnQgYXMgYSBXRyBkb2N1bWVudC4NCiAgICA+IA0KICAgID4gR3LDvMOf ZSwgQ2Fyc3Rlbg0KICAgID4gDQogICAgPiANCiAgICA+PiBPbiAyMDIwLTA0LTIzLCBhdCAxMTox MCwgRnJhbmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNlc2NhLnBhbG9tYmluaT00MGVyaWNzc29uLmNv bUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQogICAgPj4NCiAgICA+PiBBdCB0aGUgbGFzdCBpbnRl cmltIG1lZXRpbmcsIHdlIGhhZCBpbi1yb29tIGNvbnNlbnN1cyB0byBhZG9wdCBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtY2Jvci1kYXRlLXRhZy0wMS4NCiAgICA+Pg0K ICAgID4+IFRoaXMgaXMgYSAyIHdlZWtzIGNvbmZpcm1hdGlvbiBjYWxsIGZvciBhZG9wdGluZyB0 aGlzIGRyYWZ0IGFzIGEgQ0JPUiB3b3JraW5nIGdyb3VwIGl0ZW0sIGVuZGluZyAyMDIwLTA1LTA2 Lg0KICAgID4+DQogICAgPj4gSWYgeW91IGRvIG5vdCBhZ3JlZSB3aXRoIHRoZSBpbi1yb29tIGNv bnNlbnN1cyB0byBhZG9wdCB0aGlzIGFzIGEgV0cgZG9jdW1lbnQsIHBsZWFzZSBzcGVhayB1cCBu b3cuIElmIHlvdSBhZ3JlZSB3aXRoIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQsIHlvdSBjYW4gYWxz byB0ZWxsIHVzLg0KICAgID4+DQogICAgPj4gQ0JPUiBDaGFpcnMNCiAgICA+PiBGcmFuY2VzY2Eg YW5kIEppbQ0KICAgID4+DQogICAgPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCiAgICA+PiBDQk9SIG1haWxpbmcgbGlzdA0KICAgID4+IENCT1JAaWV0 Zi5vcmcNCiAgICA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3IN CiAgICA+IA0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICA+IENCT1IgbWFpbGluZyBsaXN0DQogICAgPiBDQk9SQGlldGYub3JnDQogICAg PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3INCiAgICA+IA0KDQo= From nobody Thu May 7 19:35:55 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 7FAB23A0E9C; Thu, 7 May 2020 19:35:14 -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: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <158890531443.27531.17009295107276840534@ietfa.amsl.com> Date: Thu, 07 May 2020 19:35:14 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-date-tag-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, 08 May 2020 02:35:15 -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-00.txt Pages : 5 Date : 2020-05-07 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 applicaitons 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-00 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-date-tag-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 Thu May 7 19:39: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 28C413A0E92 for ; Thu, 7 May 2020 19:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8cJbnJi7BHL for ; Thu, 7 May 2020 19:39:01 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 233453A00D5 for ; Thu, 7 May 2020 19:39:00 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id x12so145638qts.9 for ; Thu, 07 May 2020 19:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kv1U7chXmW++S6d2JM9raQQ7v1ZZ45q7DesJXrjQ/ME=; b=SN0l1ZKoX4oneti2DSUwyQc22qOWkB2i9hRClGhkHTKyIKCNcMV8ZdTjOwxRBhzonG qECBVwULo3iUlgHYaINBeI0TaRsDiG3kwZo7bFGUZ3Piac2T/WkDnsD0Y3s4mHMg6AXK 55G0BtJ37PhgKK28EisASfR/MKYq2GI/eYHBs= 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=kv1U7chXmW++S6d2JM9raQQ7v1ZZ45q7DesJXrjQ/ME=; b=k7WDu8C0XYClrmc5GSulrHQmgDYzFnsXhmBVpwPh83WlTKxeTTxLLKUeP8aDBCOTkL t9NbG8vDWwPbgvvRPWrpZZmWC9uREIa4f5LduJM/fT/oq7a1MP+sa3XbuAIztqbWNv/z 0yZTauEZxt+iSL42tzWDMAj84FsB5mQ+A9Ip0vgxlSUXT0NGVEASu7OKYawr9ngY8M2A otsmCEKmNx8rBcFoWYQ5IleiaTSYAg9KZVJabXsOe4J8AWB1Enck2Gm34PXj0q9kFYbn e37rK4HyCXbKnn2Ao8jTizpzDKKWfInLWDIB1iAUQGM6sLwlhRyknkdlzdPOry7Vkrxw Rn2w== X-Gm-Message-State: AGi0PuZbwYn3nnpeTJZ0zqDYRw7MDqDpiQMYU2740A+vHy8IEFTgKrPU xt1kJ4N+Rx0aNTzZ/jLKXFb9tzg3LUW9LaGXns1eHw== X-Google-Smtp-Source: APiQypLg94tSmkGPbBOIFRYRc6IEa4RfFfYiHKqPSukB9zQeemWz/NKBv2s63QYyqw3tFok0YrBJ15F7FRdEhlwlCds= X-Received: by 2002:ac8:33ec:: with SMTP id d41mr599462qtb.382.1588905539539; Thu, 07 May 2020 19:38:59 -0700 (PDT) MIME-Version: 1.0 References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> In-Reply-To: <13690.1588894939@localhost> From: Jeffrey Yasskin Date: Thu, 7 May 2020 19:38:47 -0700 Message-ID: To: Michael Richardson Cc: cbor@ietf.org, Carsten Bormann , Jeffrey Yasskin Content-Type: multipart/alternative; boundary="00000000000044812305a519e67b" Archived-At: Subject: Re: [Cbor] RFC7049bis processing of unknown tags 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, 08 May 2020 02:39:03 -0000 --00000000000044812305a519e67b Content-Type: text/plain; charset="UTF-8" On Thu, May 7, 2020 at 4:42 PM Michael Richardson wrote: > > Jeffrey Yasskin wrote: > > 3) While RFC7049-bis is already > > somewhat overstepping the bounds of a standard in specifying > > error-handling options, it'd be even farther out of bounds to specify > > parser API options. :) > > I disagree strongly with this part :-) > > It's is a regular and common mistake in IETF/many specifications that they > do > not adequately explain what the behaviour is supposed to be when a newer > option shows up. We probably spend 70% of our time at the IETF making sure > that we don't break old code. > Is that too high? Well, maybe, because we don't spend the effort up-front. > > As an example: IKE (IPsec) has a major and minor version. > We have no idea what it would mean to increment the minor version. > Having a minor version was a waste of time. > > (I crafted the text for the VendorID payload in IKEv1. > I believe that I got it right, and made sure that we could make > use of private extensions without conflicts in the number space) > > As for API options, yes, we often do need to give advice on providing ways > to > put things into compatibility mode, and what that means. At no point are > we > writing down some enum or #define though. > > I believe that I am less concerned about having rfc7049bis render some > existing parsers "non-compliant" --- they *ARE* still compliant to RFC7049. > > I am a user of parsers, I have occasionally had to write my own > conversions, > but mostly I would say that I am not up to speed on some of the details. > That's all reasonable. :) Given the discussion, and Lawrence's quick analysis of the existing tags, how do you currently feel about the state of RFC7049bis's requirements around error handling? * I'm not opposed to advice for parsers to have an option to treat a value tagged with an unknown tag as equivalent to the value itself. * I dislike the idea of any generic parser doing that by default, I think based on reasoning like in https://tools.ietf.org/html/draft-iab-protocol-maintenance-04. * If a parser passes unknown tags up to the application, a higher-level protocol can ignore them itself, skip their data item, return an error, or do something else appropriate to the context. So if the RFC should recommend a default in generic parsers, I'd vote for that one. * I don't intend to draft this wording myself. :) Jeffrey --00000000000044812305a519e67b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, May 7, 2020 at 4:42 PM Michael Ri= chardson <mcr+ietf@sandelman.= ca> wrote:

Jeffrey Yasskin <jyasskin@chromium.org> wrote:
=C2=A0 =C2=A0 > 3) While RFC7049-bis is already
=C2=A0 =C2=A0 > somewhat overstepping the bounds of a standard in specif= ying
=C2=A0 =C2=A0 > error-handling options, it'd be even farther out of = bounds to specify
=C2=A0 =C2=A0 > parser API options. :)

I disagree strongly with this part :-)

It's is a regular and common mistake in IETF/many specifications that t= hey do
not adequately explain what the behaviour is supposed to be when a newer option shows up.=C2=A0 We probably spend 70% of our time at the IETF making= sure
that we don't break old code.
Is that too high?=C2=A0 Well, maybe, because we don't spend the effort = up-front.

As an example: IKE (IPsec) has a major and minor version.
We have no idea what it would mean to increment the minor version.
Having a minor version was a waste of time.

(I crafted the text for the VendorID payload in IKEv1.
I believe that I got it right, and made sure that we could make
use of private extensions without conflicts in the number space)

As for API options, yes, we often do need to give advice on providing ways = to
put things into compatibility mode, and what that means.=C2=A0 At no point = are we
writing down some enum or #define though.

I believe that I am less concerned about having rfc7049bis render some
existing parsers "non-compliant" --- they *ARE* still compliant t= o RFC7049.

I am a user of parsers, I have occasionally had to write my own conversions= ,
but mostly I would say that I am not up to speed on some of the details.

That's all reasonable. :) Given the di= scussion, and Lawrence's quick analysis of the existing tags, how do yo= u currently feel about the state of RFC7049bis's requirements around er= ror handling?

* I'm not opposed to advice for = parsers to have an option to treat a value tagged with an unknown tag as eq= uivalent to the value itself.
* I dislike the idea of any generic= parser doing that by default, I think based on reasoning like in=C2=A0https= ://tools.ietf.org/html/draft-iab-protocol-maintenance-04.
* I= f a parser passes unknown tags up to the application, a higher-level protoc= ol can ignore them itself, skip their data item, return an error, or do som= ething else appropriate to the context. So if the RFC should recommend a de= fault in generic parsers, I'd vote for that one.
* I don'= t intend to draft this wording myself. :)

Jeffrey<= /div>
--00000000000044812305a519e67b-- From nobody Thu May 7 20: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 D2D563A0A81 for ; Thu, 7 May 2020 20:06:34 -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 MmTnSkA5AD6U for ; Thu, 7 May 2020 20:06:32 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640093.outbound.protection.outlook.com [40.107.64.93]) (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 8CFB33A0EEA for ; Thu, 7 May 2020 20:06:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AKXsX4KMbJb2fe+xcZxVGC9mpXFr47XuiPgkYeLSuoYNtOhYd8RQ94RMGkyPVe2Z33iUhIGsFNn97gCsH+jO7j9joICo9c580glKTrc6d56tdd6wgI2hoIXJHhNOFmkXYLRd32PU71Kvdk6kjxBwfiQfBpX6ehXzIi5UC/QkGQCnU67tzxcrQF5eRY19KKMPEYSS2FG/PBf8nG11DJcJEddYP5zT9UsQCre8tm29lS3Rj61KOFlStvOmLplunQ6i4NW7j2W4FOwyxdUuNh900JXRuboKaF3WAgdAmj8F5NT23BBcTox5jWA3B2/4LlvSSmGiYp8knIkcFxUJ9ZQT8A== 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=5ORNB1XUjKmgiArMmu6DXRI4+dmDa1jNAr369BjIVXE=; b=TvZoBpsn3j/rK67mVzsxSA3F9lOzLe50JUufFkZ5bF+rabotsbb4Xug942n3jnY4OvKGGHAZ27nF4sWk2RruaOG53kRSM7oDPXvThQlU68RE6G6JhO7p9KcmlN/xL+ezsh7qiHl8qfC61ktHGNW80JXBwNMHCQyosN6qlR49M/fpmONVJsFSdy3J2FAOw3NDs2mAkbqhfkKvfWZ7tmooP62uBkCjnfk4cIGkQPS5wL7+np7T7tttUiVfhv335l1w43H8NqdNHyzB1Kq+TvLPKZY7vzkc6El4nHNPCIolF6lMAr+JdrRLjKePdXBVcK/px798SaPaz221F8ZgqBoCNw== 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=5ORNB1XUjKmgiArMmu6DXRI4+dmDa1jNAr369BjIVXE=; b=RyEY3GsEk0xzsRgVJ/sjnOKsngvru2KU0rCBmk6wblDRv7Gq/ztnm7S4hJKWTZh1yV2WwQSFFN8ap0j2rnf/TR/suuEn8hfk9hJ3X+wq6pPs3wqWNk2w9iGXuxu5F0ekf+nBzqpgf/GQ5j/r/z8G9WMHedE8La2pj9YMB0Rlk94= Received: from BY5PR00MB0676.namprd00.prod.outlook.com (2603:10b6:a03:20c::15) by BY5PR00MB0658.namprd00.prod.outlook.com (2603:10b6:a03:20a::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.0; Fri, 8 May 2020 03:06:27 +0000 Received: from BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::7d21:c7e9:3141:cf8d]) by BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::7d21:c7e9:3141:cf8d%9]) with mapi id 15.20.3020.000; Fri, 8 May 2020 03:06:27 +0000 From: Mike Jones To: "cbor@ietf.org" Thread-Topic: Working group adoption of Concise Binary Object Representation (CBOR) Tags for Date Thread-Index: AdYk5H5EG5NTFHORQA651kSh7ZlwDQ== Date: Fri, 8 May 2020 03:06:27 +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=35c3ef6c-92fb-493e-b28e-0000e37d395b; 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-05-08T02:58:00Z; 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: f04338c0-dc23-46b0-b7fd-08d7f2fccc8b x-ms-traffictypediagnostic: BY5PR00MB0658: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 039735BC4E x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 00K9ATjxeJr9KiOYlnMlVA2MAO9NjvowZaJjX6GFv4S5PLS0T9chbQNJUFqb6abdjE1wT3tMpjluKW9owkL36vGcpXV2f5DSe3CaPRpNWCWN6zQTV+QirMk5ko6cdkXzD6vRT9IKTNGcQnvOUTcemA//q/N45T73fBKhSStSU2d4CJl2sOPO+V9QumSD8cfqPF2mVQPcyKqLJKIP2hYMEybw91oDTVr5BrBSPQd1yVTq46LUU2qBHEGzWlyzgxxElB2zKe6dmoqoVQgil6cSUL3FHuBU6wVjYi8xyMluvfLbiZa3Ak4wxzfEWlO9or8uAlI5iEFoyA+dXbfx9+c4Al/hAP7jblpf2/G7q24zGtmDZr7qWyLT8tDkFUKlWUmezlh0ucC6EGTgRnkYTsHiwruhphIFtvtZEwBiswyTMhu6JvtwTiFnuUX6lFeyq1WoyopLrNvYMhiUrByO7Dy6TojVV/wiv1zCdrbgBnW703LS/WqU90vvAOGqOi0o5Y+SrMwI00mG9iNMMC4cE5yP6A== 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)(396003)(376002)(346002)(136003)(366004)(33430700001)(71200400001)(5660300002)(82950400001)(82960400001)(316002)(966005)(21615005)(166002)(83290400001)(83280400001)(83320400001)(83310400001)(66946007)(66446008)(66476007)(66556008)(64756008)(33440700001)(83300400001)(76116006)(6506007)(52536014)(8990500004)(7696005)(9686003)(6916009)(186003)(55016002)(10290500003)(478600001)(26005)(86362001)(2906002)(33656002)(8936002)(8676002)(6606295002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: cgYh21ihBP0aIw1qiz5ISrtsfOjGeH2UZRUMgzpn89kj6KtLymUmc49wxdGjN54HspEkZcLsEwFB3I+zS8od5bjQreweP6fwY/xcN3zZhECaCbcX9UvCNH0UEYV23RzUYGh9STbxEDfyx13DqRXqfaThkbiJ9RYj+2FJZByRZnPqmKROPIFqV2RZ31RskqnHZBwPiqHsh1lFbPy5mZgk9looV2FxU2ZHk25pCI3URzDyte2fKLODX+GSEDzdgm/RpiDT5TtZOgGOPBEuddZJDST83z7u+uvZvx/w/MbHGVuPRHz/6XHacf8lmLY8z7q3p3OVKm7G7YwAZO3FVjouPT6oapXIJWAKRLIbeRe/G3YBE6pLboaNbTxTvuposid+uA+YriwxuV6isqvKkdlsQzbyPQYItW6u2BsSMI8iYlor4OXG0msHWsHj//tdy4xX1czJXjBc6IwrWHP8UUeL8ZNaHENdZEbKq/5bm3Gqsgo= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR00MB0676EF89DC414D8A4D58C540F5A20BY5PR00MB0676namp_" 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: f04338c0-dc23-46b0-b7fd-08d7f2fccc8b X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 03:06:27.2070 (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: ttLNVsndFHfMoK/oM10hzpsH7sw9igvtuKqB4OCuN9YTzelQtX4VgsBSRNdjI1YObgkn5RgznExxxS9e4jGtyA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR00MB0658 Archived-At: Subject: [Cbor] Working group adoption of Concise Binary Object Representation (CBOR) Tags for Date 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, 08 May 2020 03:06:39 -0000 --_000_BY5PR00MB0676EF89DC414D8A4D58C540F5A20BY5PR00MB0676namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The IETF CBOR working group= has adopted the specification Concise Binary Object Representation (CBOR) = Tags for Date. The abstract of the specification is: The Concise Binary Object Representation (CBOR, RFC 7049) is a data format = whose design goals include the possibility of extremely small code size, fa= irly small message size, and extensibility without the need for version neg= otiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 704= 9 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 h= ave become known. This specification defines a CBOR tag for an RFC 3339 dat= e text string, for applications needing a textual date representation witho= ut a time. It also defines a CBOR tag for days since the Posix epoch, for a= pplications needing a numeric date representation without a time. It is int= ended as the reference document for the IANA registration of the CBOR tags = defined. The need for this arose for the ISO Mobile Driver's License specification i= n the working group ISO/IEC JTC 1/SC 17 "Cards and security devices for per= sonal identification". The specification is available at: * https://tools.ietf.org/html/draft-ietf-cbor-date-tag-00 An HTML-formatted version is also available at: * https://self-issued.info/docs/draft-ietf-cbor-date-tag-00.html -- Mike P.S. This notice was also posted at https://self-issued.info/?p=3D2083 and= @selfissued. --_000_BY5PR00MB0676EF89DC414D8A4D58C540F5A20BY5PR00MB0676namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The IETF CBOR working group has adopted the specification Concise Binary= Object Representation (CBOR) Tags for Date. The abstract of the specif= ication is:

 

The Concise Binary Obj= ect Representation (CBOR, RFC 7049) is a data format whose design goals inc= lude the possibility of extremely small code size, fairly small message siz= e, and extensibility without the need for version negotiation.

 <= /p>

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 “secon= ds 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 repre= sentation without a time. It also defines a CBOR tag for days since the Pos= ix epoch, for applications needing a numeric date representation without a time. It is intended as the refere= nce document for the IANA registration of the CBOR tags defined.=

 

The need for this arose for the ISO Mobile Driver= 217;s License specification in the working group ISO/IEC JTC 1/SC 17 “= ;Cards and security devices for personal identification”.<= /p>

 

The specification is available at:

--_000_BY5PR00MB0676EF89DC414D8A4D58C540F5A20BY5PR00MB0676namp_-- From nobody Thu May 7 21:22: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 8FCC43A0EE9 for ; Thu, 7 May 2020 21:22:53 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GBQzrWQajNz for ; Thu, 7 May 2020 21:22:52 -0700 (PDT) Received: from p3plsmtpa06-09.prod.phx3.secureserver.net (p3plsmtpa06-09.prod.phx3.secureserver.net [173.201.192.110]) (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 E98633A0EE8 for ; Thu, 7 May 2020 21:22:51 -0700 (PDT) Received: from [192.168.1.34] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id WuXCjVlj5oXx7WuXDj2QUQ; Thu, 07 May 2020 21:22:51 -0700 X-CMAE-Analysis: v=2.3 cv=Revu9Glv c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=RIlx1_Rhpp72ai8PUUAA:9 a=QEXdDO2ut3YA:10 a=bfIT2CVviWJ-shvUhXEA:9 a=yt1We-i2Pdz6Jy0M:21 a=_W_S_7VecoQA:10 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D4443572-47E2-4172-B638-AB57EFA75527" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 7 May 2020 21:22:50 -0700 In-Reply-To: Cc: Michael Richardson , cbor@ietf.org, Carsten Bormann To: Jeffrey Yasskin References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-CMAE-Envelope: MS4wfGwZwhCYzWb56YE89pgrU/3higCxjMPqaiqmRLvhw0AN/ecO8pSXfXGUbCfFWNYJWDCeoAKoteiFIwkeMldWnxLIe2uSd6cuXrYaUo+EG42XWgL2y2In 64yhiUTDmoTudxSHAWWwcDSt9zBj5kVXIkkbg5LytZLbCL66dHYt7M8uEY2mkgXX9J3yA6613PLjFBclldTxKZ5psocX4GQmSWpMzuwa6EnOeZ54lv967Wd5 /TifhJqPyID6tjchd1Q7Rw== Archived-At: Subject: Re: [Cbor] RFC7049bis processing of unknown tags 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, 08 May 2020 04:22:54 -0000 --Apple-Mail=_D4443572-47E2-4172-B638-AB57EFA75527 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The more core issue for me is how protocols and protocol implementations = handle unknown tags. Generic decoders are an implementation detail in a = way. It is still useful to discuss then, but what drives the CBOR = specification should be the effect on an end-end protocol. In most use cases where a tag defines a new data type it will not be = useful to ignore the tag. An implementation that doesn=E2=80=99t = understand the new data type is out of date and incompatible. However, = it is useful to entirely skip the full data item with the unknown tag, = but it seems preferable to handle that with map keys/labels or such. If = you don=E2=80=99t know the map key/label, skip the data item. An unknown = tag shouldn=E2=80=99t break the ability to do that. In some cases of type definition it might be useful to interpret the = data item as if it were untagged, but from a quick look at the registry, = it doesn=E2=80=99t seem to be useful that often. For example, if you are = tagging something as a positive bignum, you probably really to know that = to do anything with the data item. Ignoring a COSE tag isn=E2=80=99t = going to be productive in any way. (It is possible that you know it is a = positive bignum by other means than tagging, but in that case, you = should be tagging in the first place; optional tagging is discouraged). The analogy doesn=E2=80=99t completely work, but it seems kind of like = ignoring type-defining tags is like ignoring typedefs in C. It's the case of conversion hints, where ignoring tags can work. But you = have to know the purpose of the tag is a conversion hint and that its = not a new type definition. Conversion hints don=E2=80=99t seem to the = the main purpose of tagging, critically useful, or widely used, so it = doesn=E2=80=99t seem critical to change CBOR to accommodate them. =46rom what Cartsen said it seems it would be an incompatible change = from 7049 to require tags be ignored and it doesn=E2=80=99t seem that = necessary. If I=E2=80=99d put anything in CBORbis, it would be a warning that one = should not count on unknown tags being ignored in CBOR, unless the = protocol specification says they must be ignored and how to do it and = what it means. LL Also, it seems fine to define protocol modes that get implemented as API = options, but it is the mode that is defined not the API. --Apple-Mail=_D4443572-47E2-4172-B638-AB57EFA75527 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The more core issue = for me is how protocols and protocol implementations handle unknown = tags. Generic decoders are an implementation detail in a way. It is = still useful to discuss then, but what drives the CBOR specification = should be the effect on an end-end protocol.

In most use cases where a tag defines a = new data type it will not be useful to ignore the tag. An implementation = that doesn=E2=80=99t understand the new data type is  out of date = and incompatible. However, it is useful to entirely skip the full data = item with the unknown tag, but it seems preferable to handle that with = map keys/labels or such. If you don=E2=80=99t know the map key/label, = skip the data item. An unknown tag shouldn=E2=80=99t break the ability = to do that.

In = some cases of type definition it might be useful to interpret the data = item as if it were untagged, but from a quick look at the registry, it = doesn=E2=80=99t seem to be useful that often. For example, if you are = tagging something as a positive bignum, you probably really to know that = to do anything with the data item. Ignoring a COSE tag isn=E2=80=99t = going to be productive in any way. (It is possible that you know it is a = positive bignum by other means than tagging, but in that case, you = should be tagging in the first place; optional tagging is = discouraged).

The analogy doesn=E2=80=99t completely work, but it seems = kind of like ignoring type-defining tags is like ignoring  typedefs = in C.

It's the = case of conversion hints, where ignoring tags can work. But you have to = know the purpose of the tag is a conversion hint and that its not a new = type definition. Conversion hints don=E2=80=99t seem to the the main = purpose of tagging, critically useful, or widely used, so it doesn=E2=80=99= t seem critical to change CBOR to accommodate them.

=46rom what Cartsen said = it seems it would be an incompatible change from 7049 to require tags be ignored and it doesn=E2=80=99t seem = that necessary.

If I=E2=80=99d put anything in CBORbis, it would be a warning = that one should not count on unknown tags being ignored in CBOR, unless = the protocol specification  says they must be ignored and how to do = it and what it means.

LL


Also, it seems fine to = define protocol modes that get implemented as API options, but it is the = mode that is defined not the API.


= --Apple-Mail=_D4443572-47E2-4172-B638-AB57EFA75527-- From nobody Thu May 7 23:48: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 B32DB3A07EA for ; Thu, 7 May 2020 23:48:15 -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 hcL73eRMhtOu for ; Thu, 7 May 2020 23:48:11 -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 B63E33A07E9 for ; Thu, 7 May 2020 23:48:10 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49JLWD2Yd1z160j; Fri, 8 May 2020 08:48:08 +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: <269a22c2b07ee953a09b48c535b28791@mothers-arms.co.uk> Date: Fri, 8 May 2020 08:48:07 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 610613287.64902-aa69152301fed45287782eb5e362db3a Content-Transfer-Encoding: quoted-printable Message-Id: <853DC97D-91C7-4188-ADE1-AFC2431EFD3B@tzi.org> References: <6ACF0CA3-59C4-4CE1-9344-81B43C75BAF4@tzi.org> <269a22c2b07ee953a09b48c535b28791@mothers-arms.co.uk> To: Kio Smallwood X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] 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, 08 May 2020 06:48:16 -0000 If we go for this, as I=E2=80=99m proposing in = = : I think we should require that =E2=80=94 the offsets are (unsigned and) divisible by 8; =E2=80=94 the byte strings do not overlap. I=E2=80=99m also not sure we wouldn=E2=80=99t want to require the = offset/bitstring pairs to be in order, which would need an array instead = of a map (as maps are not ordered). Gr=C3=BC=C3=9Fe, Carsten > On 2020-05-06, at 18:17, Kio Smallwood wrote: >=20 > That's an interesting problem. I would use a tagged map where the key = is an integer offset in bytes from the beginning of the sparse array, = and the value would be the byte(s) from that position. >=20 > i.e. >=20 > 2020({0: h'0107', 4000000000: h'15'}) >=20 > D9 07E4 # tag(2020) > A2 # map(2) > 00 # unsigned(0) > 42 # bytes(2) > 0107 # "\x01\a" > 1A EE6B2800 # unsigned(4000000000) > 41 # bytes(1) > 15 # "\x15" >=20 >=20 >=20 > My thinking in this is that bit flags would tend to cluster together = in practice. >=20 > It does have one problem in that it is possible to create overlapping = byte sequences. >=20 > The decoder would not need to allocate much space. >=20 > Cheers, >=20 > Kio >=20 >=20 >=20 > On 2020-05-06 16:38, Carsten Bormann wrote: >=20 >> JFYI: Interesting discussion in core/netmod about potentially needing = to represent sparse bit sets. >> Anything we (cbor WG) can contribute to that? >> =20 >> Gr=C3=BC=C3=9Fe, Carsten >> =20 >>=20 >>> Begin forwarded message: >>>=20 >>> From: "Rob Wilton \(rwilton\)" >>> Subject: [netmod] CBOR YANG encoding of union & bits = [draft-ietf-core-yang-cbor-12] >>> Date: 2020-05-06 at 12:43:49 CEST >>> To: "core@ietf.org" , "netmod@ietf.org" = , "draft-ietf-core-yang-cbor@ietf.org" = >>> Archived-At: = = >>>=20 >>> Hi, >>>=20 >>> [Cross posting to Netmod for wider YANG expertise.] >>>=20 >>> I had a couple of questions on the CBOR YANG encoding of bits and = unions (based on draft-ietf-core-yang-cbor-12). Apologies if these have = already been discussed/closed in the WGLC. >>>=20 >>> 1) Regarding the encoding of the bits datatype: >>> [draft-ietf-core-yang-cbor-12, section 6.7] >>>=20 >>> The CBOR YANG encoding of the bits datatype is defined as a byte = string encoding of a bitfield. However, my concern here is that YANG = bit positions are allowed to be up 2^32-1. >>>=20 >>> E.g. the following, pathologically bad, bits definition would seem = to have a very inefficient encoding in CBOR: >>>=20 >>> typedef alarm-state { >>> type bits { >>> bit unknown { >>> position 4000000000; >>> } >>> bit under-repair; >>> bit critical; >>> bit major; >>> bit minor; >>> bit warning; >>> bit indeterminate; >>> } >>> } >>>=20 >>>=20 >>> How much should we be concerned about this pathological case? Would = it be reasonable for implementations to reject bitfields larger than a = small set size (e.g. perhaps 256 bits)? >>>=20 >>> Or, if it is supported by the language then is it reasonable that = implementation SHOULD support it? In which case I think that we might = need a second encoding of bits that supports this pathological case. = Perhaps an array of 'set' bit positions, or alternatively the union = string encoding of bits could be used. >>>=20 >>>=20 >>> 2) Regarding the encoding of unions: >>>=20 >>> I was questioning whether the special encoding of bits type within a = union was required in CBOR [draft-ietf-core-yang-cbor-12, section 6.7]. = Am I right to presume that this is to ensure that the CBOR encoding of = unions is always at least as specific as XML? If so, this seems like a = reasonable design choice. But that leads on to these general YANG = questions: >>>=20 >>> Should the value encoding of a YANG union type behave the same way = regardless of whether the encoding is XML/JSON/CBOR? Or is it = reasonable for there to be differences in the case of conflicting = values? Perhaps this is already answered by RFC 7951 that can behave = differently from the XML encoding of unions. >>>=20 >>> Longer term, should YANG be looking for a discriminated-union type? = Or perhaps it would be sufficient for tooling to flag up potentially = ambiguous union definitions, particularly those that may be encoding = dependent. >>>=20 >>>=20 >>> Regards, >>> Rob >>>=20 >>> [As an individual contributor] >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Fri May 8 02: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 4559E3A0969 for ; Fri, 8 May 2020 02:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, 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 t8MK7ZrAt9VL for ; Fri, 8 May 2020 02:37:54 -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 6FA3B3A0968 for ; Fri, 8 May 2020 02:37:54 -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 1jWzS4-0003O8-Uo; Fri, 08 May 2020 10:37:53 +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); Fri, 08 May 2020 10:37:43 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a304aec462039ee76c575a323ed1e383" Date: Fri, 08 May 2020 10:37:43 +0100 From: Kio Smallwood To: Carsten Bormann Cc: cbor@ietf.org In-Reply-To: <853DC97D-91C7-4188-ADE1-AFC2431EFD3B@tzi.org> References: <6ACF0CA3-59C4-4CE1-9344-81B43C75BAF4@tzi.org> <269a22c2b07ee953a09b48c535b28791@mothers-arms.co.uk> <853DC97D-91C7-4188-ADE1-AFC2431EFD3B@tzi.org> Message-ID: <5dac70881c52c6fde0fc80c87363386e@mothers-arms.co.uk> X-Sender: kio@mothers-arms.co.uk User-Agent: Roundcube Webmail/1.3.11 Archived-At: Subject: Re: [Cbor] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] 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, 08 May 2020 09:37:56 -0000 --=_a304aec462039ee76c575a323ed1e383 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Carsten, Yes I agree, requiring an array makes more sense. I would prefer a byte offset instead of a bit offset then you don't need to worry about the divisible by eight constraint. Therefore the specification would be: - A tagged array containing: - An unsigned integer byte offset - followed by one or more contiguous bytes containing set bits - the next offset (must be strictly larger than the offset + length of previous data item) - the next byte(s) - etc. e.g. 2020([0, h'0107', 500000000, h'15']) The following example should result in an error: 2020([0, h'0107', 1, h'01']) A case should be made that each offset+byte pair should have at least one set bit. So this would be a valid bitfield that's all zeros: 2020([]) Cheers, Kio On 2020-05-08 7:48, Carsten Bormann wrote: > If we go for this, as I'm proposing in : > > I think we should require that > > -- the offsets are (unsigned and) divisible by 8; > -- the byte strings do not overlap. > > I'm also not sure we wouldn't want to require the offset/bitstring pairs to be in order, which would need an array instead of a map (as maps are not ordered). > > Grüße, Carsten --=_a304aec462039ee76c575a323ed1e383 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Carsten,

Yes I agree, requiring an array makes more sense. I would prefer a byte = offset instead of a bit offset then you don't need to worry about the divis= ible by eight constraint.

Therefore the specification would be:

- A tagged array containing:

- An unsigned integer byte offset

- followed by one or more contiguous bytes containing set bits

- the next offset (must be strictly larger than the offset + length of p= revious data item)

- the next byte(s)

- etc.

e.g.

2020([0, h'0107', 500000000, h'15'])

The following example should result in an error:

2020([0, h'0107', 1, h'01'])

A case should be made that each offset+byte pair should have at least on= e set bit. So this would be a valid bitfield that's all zeros:

2020([])

Cheers,

Kio

On 2020-05-08 7:48, Carsten Bormann wrote:

= If we go for this, as I'm proposing in <https://mailarchive.ietf.org/arch/msg/netmod/hR= MjLIIpOyTNtmkv4yd3gyjd_gA>:

I think we should require t= hat

— the offsets are (unsigned and) divisible by 8;
— the byte strings do not overlap.

I'm also not sure = we wouldn't want to require the offset/bitstring pairs to be in order, whic= h would need an array instead of a map (as maps are not ordered).
Grüße, Carsten


--=_a304aec462039ee76c575a323ed1e383-- From nobody Fri May 8 03:05:22 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9793C3A0993 for ; Fri, 8 May 2020 03:05: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 DftH4sgcxDxF for ; Fri, 8 May 2020 03:05: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 DCF183A0985 for ; Fri, 8 May 2020 03:05:13 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49JQtb38Fqz161N; Fri, 8 May 2020 12:05:11 +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: <5dac70881c52c6fde0fc80c87363386e@mothers-arms.co.uk> Date: Fri, 8 May 2020 12:05:10 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 610625110.855669-663979bd12a37db540ad56744cb7b8d6 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6ACF0CA3-59C4-4CE1-9344-81B43C75BAF4@tzi.org> <269a22c2b07ee953a09b48c535b28791@mothers-arms.co.uk> <853DC97D-91C7-4188-ADE1-AFC2431EFD3B@tzi.org> <5dac70881c52c6fde0fc80c87363386e@mothers-arms.co.uk> To: Kio Smallwood X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] 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, 08 May 2020 10:05:20 -0000 On 2020-05-08, at 11:37, Kio Smallwood wrote: >=20 > - the next offset (must be strictly larger than the offset + length of = previous data item) >=20 > - the next byte(s) >=20 > - etc. >=20 > e.g. >=20 > 2020([0, h'0107', 500000000, h'15']) >=20 > The following example should result in an error: >=20 > 2020([0, h'0107', 1, h'01']) >=20 > A case should be made that each offset+byte pair should have at least = one set bit. So this would be a valid bitfield that's all zeros: >=20 > 2020([]) Looks good. Even better: make sure that an overlap cannot even be = encoded. The numbers in the array could be the number of bytes not sent that are = presumed all zero. So your first example would become: 2020([0, h'0107', 499999998, h'15=E2=80=99]) Or, actually, since the first zero becomes redundant now,=20 2020([h'0107', 499999998, h'15=E2=80=99]) So the contents of the array would be byte strings or numbers that = indicate gaps by giving the number of zero bytes. Numbers should probably be positive (non-zero), and we could forbid = adjacent numbers or trailing numbers. Or we could just make that the = preferred encoding and still allow them (including zeros); I don=E2=80=99t= have a strong opinion. (I=E2=80=99m not motivated enough to think = about c14n now=E2=80=A6) [ASN.1 has the ability to indicate that the last byte in a bit string = isn=E2=80=99t completely part of the bit string. A trailing negative = number could indicate that. But I still haven=E2=80=99t seen a true use = case for ASN.1 bit strings since I thought about that in 2013=E2=80=A6] Gr=C3=BC=C3=9Fe, Carsten From nobody Fri May 8 03:19: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 8CC413A09AA for ; Fri, 8 May 2020 03:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_lofGCV5wuU for ; Fri, 8 May 2020 03:19:41 -0700 (PDT) Received: from mail-edgeDD24.fraunhofer.de (mail-edgeDD24.fraunhofer.de [192.102.167.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 9946A3A09A0 for ; Fri, 8 May 2020 03:19:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EVBABkpYde/xmnZsBmGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4F9LGwDVS8qCoQRjnmBZC2bPQoKAQEBAQEBAQEBBgE?= =?us-ascii?q?BGAsKAgQBAQKEQgKCRyQ4EwIQAQEGAQEBAQEFBAICaYVWDINTfgEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEWAkNVEgEBHgEBAQMBASEPAQU2CxAJAg4KAgImAgInIBA?= =?us-ascii?q?GAQwBBQIBAYMiAYJ8BAuTP5t5gTKFS4NngTgGgQ4qjDEPgUw/gREnD4IsLj6?= =?us-ascii?q?CZwEBhHeCXgSQf6ATB4FJd3wElh8jgkyIOIQxBYxGjzKcHQIEAgkCFYFpI4F?= =?us-ascii?q?XTSRPgmlQGA2OJgMXFW8BCIdXhUNygSmNGQGBDwEB?= X-IPAS-Result: =?us-ascii?q?A2EVBABkpYde/xmnZsBmGwEBAQEBAQEFAQEBEQEBAwMBA?= =?us-ascii?q?QGBe4F9LGwDVS8qCoQRjnmBZC2bPQoKAQEBAQEBAQEBBgEBGAsKAgQBAQKEQ?= =?us-ascii?q?gKCRyQ4EwIQAQEGAQEBAQEFBAICaYVWDINTfgEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEWAkNVEgEBHgEBAQMBASEPAQU2CxAJAg4KAgImAgInIBAGAQwBBQIBAYMiA?= =?us-ascii?q?YJ8BAuTP5t5gTKFS4NngTgGgQ4qjDEPgUw/gREnD4IsLj6CZwEBhHeCXgSQf?= =?us-ascii?q?6ATB4FJd3wElh8jgkyIOIQxBYxGjzKcHQIEAgkCFYFpI4FXTSRPgmlQGA2OJ?= =?us-ascii?q?gMXFW8BCIdXhUNygSmNGQGBDwEB?= X-IronPort-AV: E=Sophos;i="5.72,341,1580770800"; d="scan'208";a="31669664" Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeDD24.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2020 12:19:37 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlEAC9MbVe/1lIDI1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUeBfS1vA1QwLAqEGo58gWQtm2ELAQMBAQEBAQYBARgLCgI?= =?us-ascii?q?EAQGERAKCDSQ4EwIQAQEFAQEBAgEFBG2FVgyFcgEBAQMBASEPAQU2CxAJAg4?= =?us-ascii?q?KAgImAgInIBAGAQwBBQIBAYMiAYMAC5QHm3mBMoVRg1aBOgaBDiqMRA+BTD+?= =?us-ascii?q?BEScPgiwuPoJnAQGEeYJgBJFOoR0HgU2BAH8Elx8jglyIZ4RUBo0dkB2dKgI?= =?us-ascii?q?EAgkCFYFpIoFWTSRPgmlQGA2QSQMXFW4BCIdXhURBMTcCBgEHAQEDCXyQDQG?= =?us-ascii?q?BDwEB?= X-IronPort-AV: E=Sophos;i="5.73,367,1583190000"; d="scan'208";a="81862281" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2020 12:19:33 +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 048AJUhx009082 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Fri, 8 May 2020 12:19:30 +0200 Received: from [192.168.16.50] (79.234.119.240) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 8 May 2020 12:19:25 +0200 To: Carsten Bormann , Kio Smallwood CC: References: <6ACF0CA3-59C4-4CE1-9344-81B43C75BAF4@tzi.org> <269a22c2b07ee953a09b48c535b28791@mothers-arms.co.uk> <853DC97D-91C7-4188-ADE1-AFC2431EFD3B@tzi.org> <5dac70881c52c6fde0fc80c87363386e@mothers-arms.co.uk> From: Henk Birkholz Message-ID: <991b9e36-dd49-d2d9-302a-78a829374fd1@sit.fraunhofer.de> Date: Fri, 8 May 2020 12:19:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.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.234.119.240] Archived-At: Subject: Re: [Cbor] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] 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, 08 May 2020 10:19:47 -0000 Hi all, quick note. I think it is sufficient to highlight "utilized bytes", it should also be expected that "a byte might not be used entirely", e.g. the last byte that might not be completely used by a bit string. That maps nicely to CBOR, simplifies the post-processing and would eliminate the additional use of a trailing negative number (please mind, not singed int). That said, the "trailing negative number" is not a bad idea. I am just wondering, if we might want to "imply" a trailing negative number for bytes not entirely used for a bit string all the time, eliminating the need for that trailing negative number to be expressed, in general. Viele Grüße, Henk On 08.05.20 12:05, Carsten Bormann wrote: > On 2020-05-08, at 11:37, Kio Smallwood wrote: >> >> - the next offset (must be strictly larger than the offset + length of previous data item) >> >> - the next byte(s) >> >> - etc. >> >> e.g. >> >> 2020([0, h'0107', 500000000, h'15']) >> >> The following example should result in an error: >> >> 2020([0, h'0107', 1, h'01']) >> >> A case should be made that each offset+byte pair should have at least one set bit. So this would be a valid bitfield that's all zeros: >> >> 2020([]) > > Looks good. Even better: make sure that an overlap cannot even be encoded. > The numbers in the array could be the number of bytes not sent that are presumed all zero. > > So your first example would become: > > 2020([0, h'0107', 499999998, h'15’]) > > Or, actually, since the first zero becomes redundant now, > > 2020([h'0107', 499999998, h'15’]) > > So the contents of the array would be byte strings or numbers that indicate gaps by giving the number of zero bytes. > > Numbers should probably be positive (non-zero), and we could forbid adjacent numbers or trailing numbers. Or we could just make that the preferred encoding and still allow them (including zeros); I don’t have a strong opinion. (I’m not motivated enough to think about c14n now…) > > [ASN.1 has the ability to indicate that the last byte in a bit string isn’t completely part of the bit string. A trailing negative number could indicate that. But I still haven’t seen a true use case for ASN.1 bit strings since I thought about that in 2013…] > > Grüße, Carsten > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > From nobody Fri May 8 10:32:59 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36103A0E06 for ; Fri, 8 May 2020 10:32:55 -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 T7ps6I3befbh for ; Fri, 8 May 2020 10:32:52 -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 8377E3A0DFF for ; Fri, 8 May 2020 10:32:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 58095389B6 for ; Fri, 8 May 2020 13:30:49 -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 1oz5gDMBuBJP for ; Fri, 8 May 2020 13:30:48 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 884FC389B5 for ; Fri, 8 May 2020 13:30:48 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 755CB4E7 for ; Fri, 8 May 2020 13:32:49 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org In-Reply-To: References: <6ACF0CA3-59C4-4CE1-9344-81B43C75BAF4@tzi.org> <269a22c2b07ee953a09b48c535b28791@mothers-arms.co.uk> <853DC97D-91C7-4188-ADE1-AFC2431EFD3B@tzi.org> <5dac70881c52c6fde0fc80c87363386e@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] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12] 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, 08 May 2020 17:32:57 -0000 --=-=-= Content-Type: text/plain Carsten Bormann wrote: > Looks good. Even better: make sure that an overlap cannot even be > encoded. The numbers in the array could be the number of bytes not > sent that are presumed all zero. At this point, we seem to have gotten to just doing Run-Length Encoding. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl61l8EACgkQgItw+93Q 3WX1DQgAgFNaRkKggzaPZOv+Bwgtzjo0WhLlU2fIBadawek/HmEkBgffDjELIokf 7oFlWieAxdVR+TKZDoDDpB9VwF27q7yEH1ja92PSfIUgKeigyk4elU5g0f4umYX+ GPcMwBY7eENhA0/uacZaTN39o1Sv40Cd22S0AT9TQUnY/WLPb0nmJ0B5tArIaoWL 5zu1iqT+E/epNi77Jh38JN6El2TFFgHKkLOggkYQNaGoLVpKs9ykewG4WGHugV+l v1TaaK5xhi5Xgpr27kmAFD4AhtEqOTLARmUcLRe5UzzN8xYzGJIq2K0WFeJtFb2d gwd0nCBHbcYsc+nfaMJzopkaLQtxwQ== =1LqH -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 12 13:28: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 D34FB3A0AAA for ; Tue, 12 May 2020 13:28:53 -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 7NxqY_QV9cDZ for ; Tue, 12 May 2020 13:28: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 4E4D73A0AA9 for ; Tue, 12 May 2020 13:28:50 -0700 (PDT) Received: from client-pool2-101.vpn.uni-bremen.de (client-pool2-101.vpn.uni-bremen.de [134.102.48.101]) (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 49M8XJ2GSJzyf6; Tue, 12 May 2020 22:28:48 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 611008127.321901-c4069a5a27d036b2d40cb14cf1008b3f Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 12 May 2020 22:28:47 +0200 Message-Id: <9B6B7286-F934-4576-86E4-D8654293A9FC@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Cbor] Invalid tag (issue 176); notable tags 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: Tue, 12 May 2020 20:28:54 -0000 As we discussed in conjunction with = https://github.com/cbor-wg/CBORbis/issues/176, we need a registration = for an invalid tag, which is reserved so it can be used in an = implementation to store the absence of a tag into an integer that would = otherwise carry the number of that tag. I have put the text for a specification for that registration in: = https://www.ietf.org/id/draft-bormann-cbor-notable-tags-00.html#name-iana-= considerations I have also applied for the tag number at IANA. I took the occasion to start drafting the =E2=80=9Cnotable tags=E2=80=9D = draft I have been bandying about in recent CBOR meetings. Most of the = text that would make that draft useful is not yet written. I also need = to shop around for permissions to copy over original tag definition = texts into that draft. But the structure is already a good straw man = for how I think this document should look like. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue May 12 15:09: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 D68763A0C3B for ; Tue, 12 May 2020 15:09:33 -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 KT4OWVVn7Hak for ; Tue, 12 May 2020 15:09:32 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 2ECF83A0C38 for ; Tue, 12 May 2020 15:09:31 -0700 (PDT) IronPort-SDR: ecbkWBjQ6FijIKOLXYoTs57X59+7eDdy17tsxeqcFg6bw7e474KRCHiuIKmWfmQVmCkTJrE4wI axRhhsnptmvQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 May 2020 15:09:31 -0700 IronPort-SDR: Kj6NAwwdJV2HMLodqtUMSoo1gYrUyqYDvYZCCjX1B4/A+rgWJh5TRMPIRzSdpG7t79ihMpEcrB +Yd0HaM9JYVQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,385,1583222400"; d="scan'208";a="298167202" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga008.jf.intel.com with ESMTP; 12 May 2020 15:09:31 -0700 Received: from tjmaciei-mobl1.localnet (10.254.96.85) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 12 May 2020 15:09:30 -0700 From: Thiago Macieira To: Date: Tue, 12 May 2020 15:09:30 -0700 Message-ID: <3461942.bKgpO4XBJ3@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <9B6B7286-F934-4576-86E4-D8654293A9FC@tzi.org> References: <9B6B7286-F934-4576-86E4-D8654293A9FC@tzi.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.254.96.85] Archived-At: Subject: Re: [Cbor] Invalid tag (issue 176); notable tags 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: Tue, 12 May 2020 22:09:34 -0000 On Tuesday, 12 May 2020 13:28:47 PDT Carsten Bormann wrote: > As we discussed in conjunction with > https://github.com/cbor-wg/CBORbis/issues/176, we need a registration for > an invalid tag, which is reserved so it can be used in an implementation to > store the absence of a tag into an integer that would otherwise carry the > number of that tag. > > I have put the text for a specification for that registration in: > > https://www.ietf.org/id/draft-bormann-cbor-notable-tags-00.html#name-iana-co > nsiderations > > I have also applied for the tag number at IANA. The best tag number for this would be 0, since it allows a bzero'ed structure to indicate the invalid tag, but that's already taken. The second best would be ~uint64_t(0), which would also allow the same property, just by making the implementation store the actual tag number plus 1 (0 is -1, 1 is 0, etc.). So why limit it to 16-bit? Anyway, more importantly for me is a bit of text explaining what implementations should do when seeing this tag. This is similar to the Undefined simple type, which is very concrete and yet has special roles. For example, in Qt, these two methods exist: QJsonObject::insert(QStringView key, const QJsonValue &value) QCborMap::insert(QStringView key, const QCborValue &value) But they differ in behaviour if the value is Undefined. The JSON method, upon receiving a value that is undefined, will remove the key from the map, as JSON does not support undefined values. QCborMap, on the other hand, stores a CBOR value of type Undefined. If this discussion is of interest, I'll start a new thread to talk about Undefined. But for the invalid tag, let's make sure we have some wording to indicate its usage. I suggest something along the lines of: "Implementations MAY choose to discard this tag, as if it were not present. Therefore, CBOR interchange may not rely on this tag being processed by the recipient in any particular form: the decoder may pass it on to a higher layer for processing or it may discard. Similarly, encoders receiving this tag from a higher layer may opt not to encode it in the byte stream." For me, I won't treat it in any special way. If it is present, the decoder will see a QCborTag(0xffff) and I will add a QCborKnownTags::Invalid to Qt and CborInvalidTag to TinyCBOR (if it fits into 32-bit). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products From nobody Tue May 12 22:13: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 39BAE3A0CF8 for ; Tue, 12 May 2020 22:13: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 T0PWAq9-jYWr for ; Tue, 12 May 2020 22:13: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 C5AD73A0C08 for ; Tue, 12 May 2020 22:13:40 -0700 (PDT) Received: from client-0133.vpn.uni-bremen.de (client-0133.vpn.uni-bremen.de [134.102.107.133]) (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 49MN9t68LnzySS; Wed, 13 May 2020 07:13: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: <3461942.bKgpO4XBJ3@tjmaciei-mobl1> Date: Wed, 13 May 2020 07:13:38 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 611039617.674159-9bc9addbb648eed991f996f2f0e7fc48 Content-Transfer-Encoding: quoted-printable Message-Id: <54D2E6E4-DF68-4E21-8418-D7EAE6768315@tzi.org> References: <9B6B7286-F934-4576-86E4-D8654293A9FC@tzi.org> <3461942.bKgpO4XBJ3@tjmaciei-mobl1> To: Thiago Macieira X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Invalid tag (issue 176); notable tags 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: Wed, 13 May 2020 05:13:44 -0000 > The best tag number for this would be 0, since it allows a bzero'ed = structure=20 > to indicate the invalid tag, but that's already taken. Indeed =E2=80=94 we just didn=E2=80=99t think of that implementation = approach when we allocated 0 to time/date in 2013. > The second best would=20 > be ~uint64_t(0), which would also allow the same property, just by = making the=20 > implementation store the actual tag number plus 1 (0 is -1, 1 is 0, = etc.). So=20 > why limit it to 16-bit? This was discussed at the same time we also discussed that 64-bit (i.e., = > 32 bit) tags are likely only going to be processed by implementations = that do 64-bit numbers as well, and it was pointed out that some = implementations will even attempt to get by with 16 bits for the tags = they need. But we could go ahead and reserve ~0 as another invalid tag = as that strategy (storing tag number+1) is only visible inside an = implementation, so it doesn=E2=80=99t matter whether that tag is = processed during interchange. > Anyway, more importantly for me is a bit of text explaining what=20 > implementations should do when seeing this tag. = https://www.ietf.org/id/draft-bormann-cbor-notable-tags-00.html#name-inval= id-tag Is that text sufficient? > This is similar to the=20 > Undefined simple type, which is very concrete and yet has special = roles. >=20 > For example, in Qt, these two methods exist: >=20 > QJsonObject::insert(QStringView key, const QJsonValue &value) > QCborMap::insert(QStringView key, const QCborValue &value) >=20 > But they differ in behaviour if the value is Undefined. The JSON = method, upon=20 > receiving a value that is undefined, will remove the key from the map, = as JSON=20 > does not support undefined values. QCborMap, on the other hand, stores = a CBOR=20 > value of type Undefined. (There could be an insert_unless_undefined that inherits the semantics = of JSON-oriented method.) > If this discussion is of interest, I'll start a new thread to talk = about=20 > Undefined. Yes, please. Even better if you could include tag 31 = https://github.com/svaarala/cbor-specs/blob/master/cbor-absent-tag.rst = in that discussion. > But for the invalid tag, let's make sure we have some wording to=20 > indicate its usage. I suggest something along the lines of: >=20 > "Implementations MAY choose to discard this tag, as if it were not = present.=20 We are moving away from encouraging discarding tags. But the point with the invalid tag is that it is always invalid during = interchange; we should not give instructions that give the impression = there will be uniform processing if the tag actually is encountered = during interchange. > Therefore, CBOR interchange may not rely on this tag being processed = by the=20 > recipient in any particular form: the decoder may pass it on to a = higher layer=20 > for processing or it may discard. Similarly, encoders receiving this = tag from=20 > a higher layer may opt not to encode it in the byte stream." >=20 > For me, I won't treat it in any special way. That is certainly a correct way of processing the tag number when it = occurs in interchange. That leaves it to the application to react to it. > If it is present, the decoder=20 > will see a QCborTag(0xffff) and I will add a QCborKnownTags::Invalid = to Qt and=20 > CborInvalidTag to TinyCBOR (if it fits into 32-bit). Maybe we should go for Invalid1 (0xffff) and Invalid2 = (0xffffffffffffffff) then=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 13 08:42: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 899B03A0FC2 for ; Wed, 13 May 2020 08:41:57 -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 kuIKfbOLzUuf for ; Wed, 13 May 2020 08:41:54 -0700 (PDT) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D9C83A0DF9 for ; Wed, 13 May 2020 08:41:53 -0700 (PDT) IronPort-SDR: NQUy1yDgsb1C5+QAmccbqBXggRAx4v0u/k3iWGRL0HUC9Y8xj5Q+5lhkBEBnJTkgwoa5Mi3IO/ VpBLByPwGGSA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2020 08:41:53 -0700 IronPort-SDR: UhdGae5YjAMjP2rwewiL1rb/YulqMdVJ21CixUKLat7swH/YM4yjARGyCni22mAVFuUoJSGA6R NORnAtuxFkuA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,388,1583222400"; d="scan'208";a="463979772" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga005.fm.intel.com with ESMTP; 13 May 2020 08:41:52 -0700 Received: from tjmaciei-mobl1.localnet (10.255.230.198) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 13 May 2020 08:41:52 -0700 From: Thiago Macieira To: Date: Wed, 13 May 2020 08:41:51 -0700 Message-ID: <3364916.3PCeGIPBnu@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <54D2E6E4-DF68-4E21-8418-D7EAE6768315@tzi.org> References: <9B6B7286-F934-4576-86E4-D8654293A9FC@tzi.org> <3461942.bKgpO4XBJ3@tjmaciei-mobl1> <54D2E6E4-DF68-4E21-8418-D7EAE6768315@tzi.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.255.230.198] Archived-At: Subject: Re: [Cbor] Invalid tag (issue 176); notable tags 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: Wed, 13 May 2020 15:42:01 -0000 On ter=C3=A7a-feira, 12 de maio de 2020 22:13:38 PDT Carsten Bormann wrote: > This was discussed at the same time we also discussed that 64-bit (i.e., > > 32 bit) tags are likely only going to be processed by implementations that > do 64-bit numbers as well, and it was pointed out that some implementatio= ns > will even attempt to get by with 16 bits for the tags they need. But we > could go ahead and reserve ~0 as another invalid tag as that strategy > (storing tag number+1) is only visible inside an implementation, so it > doesn=E2=80=99t matter whether that tag is processed during interchange. Indeed. TinyCBOR's own structure for validating tags could be shrunk to 16-= bit=20 and save just under half of the memory use. Right now, I'm using some extra= =20 bits to indicate that tags 21, 22 and 23 apply to arrays, maps and byte=20 strings so I need more than 16 bits anyway, but there are other ways of=20 indicating the same thing. > https://www.ietf.org/id/draft-bormann-cbor-notable-tags-00.html#name-inva= lid > -tag Is that text sufficient? It's sufficient, based on the discussion here. But if I hadn't participated= ,=20 I'd read the "are encouraged to" as something I should implement, not just= =20 something I can ignore. > > If this discussion is of interest, I'll start a new thread to talk about > > Undefined. >=20 > Yes, please. Even better if you could include tag 31 > https://github.com/svaarala/cbor-specs/blob/master/cbor-absent-tag.rst in > that discussion. Will do. > > If it is present, the decoder > > will see a QCborTag(0xffff) and I will add a QCborKnownTags::Invalid to= Qt > > and CborInvalidTag to TinyCBOR (if it fits into 32-bit). >=20 > Maybe we should go for Invalid1 (0xffff) and Invalid2 (0xffffffffffffffff) > then=E2=80=A6 Then reserve 0xffff, 0xffffffff and 0xffffffffffffffff. =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products From nobody Wed May 13 08:43:52 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCDD3A0E09 for ; Wed, 13 May 2020 08:43:47 -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 U1nBCP6iTU4R for ; Wed, 13 May 2020 08:43: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 13CC83A0FB6 for ; Wed, 13 May 2020 08:43:39 -0700 (PDT) Received: from [192.168.217.119] (p548DC699.dip0.t-ipconnect.de [84.141.198.153]) (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 49Mf8n5LgHzyfm; Wed, 13 May 2020 17: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: <3364916.3PCeGIPBnu@tjmaciei-mobl1> Date: Wed, 13 May 2020 17:43:37 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 611077416.958976-88643451d6a13189595b4aa2db828a5a Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B6B7286-F934-4576-86E4-D8654293A9FC@tzi.org> <3461942.bKgpO4XBJ3@tjmaciei-mobl1> <54D2E6E4-DF68-4E21-8418-D7EAE6768315@tzi.org> <3364916.3PCeGIPBnu@tjmaciei-mobl1> To: Thiago Macieira X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Invalid tag (issue 176); notable tags 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: Wed, 13 May 2020 15:43:47 -0000 On 2020-05-13, at 17:41, Thiago Macieira = wrote: >=20 > Then reserve 0xffff, 0xffffffff and 0xffffffffffffffff. Makes sense to me. Any opposing views? Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 13 11:39: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 87A643A076C for ; Wed, 13 May 2020 11:39: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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id un5n-EPZhu4c for ; Wed, 13 May 2020 11:39:07 -0700 (PDT) Received: from p3plsmtpa08-03.prod.phx3.secureserver.net (p3plsmtpa08-03.prod.phx3.secureserver.net [173.201.193.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 653F53A065A for ; Wed, 13 May 2020 11:39:07 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id YwHajBqjErEB6YwHajhAIz; Wed, 13 May 2020 11:39:06 -0700 X-CMAE-Analysis: v=2.3 cv=F7YpiZpN c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=gKmFwSsBAAAA:8 a=QyXUC8HyAAAA:8 a=48vgC7mUAAAA:8 a=qcf52qGWj-doIjofsq4A:9 a=QEXdDO2ut3YA:10 a=rKrVYePj7rwA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Laurence Lundblade In-Reply-To: Date: Wed, 13 May 2020 11:39:05 -0700 Cc: Thiago Macieira , cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B6B7286-F934-4576-86E4-D8654293A9FC@tzi.org> <3461942.bKgpO4XBJ3@tjmaciei-mobl1> <54D2E6E4-DF68-4E21-8418-D7EAE6768315@tzi.org> <3364916.3PCeGIPBnu@tjmaciei-mobl1> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfBm1CfgYNuMIt5Jk2i3S0qgw5Q/2U0wkdRCCXMOIcfk0ZHNlz18fx3mtml3zv36DgtHKwAgFR3wXeLCwaXH3d94Oj6GcRzGyB/hiqaSVWsZtAA3tdQUE 4noR7OrxvNPUbjx9YjOps8qWWsPOMk97DXuVU7baVxgUY191sVLq3cMwKP9Twalk21DLIETlCrz13w99NU5m1yP8gwDECGA/609iSQhhdrmjtasUGnTslpVd Archived-At: Subject: Re: [Cbor] Invalid tag (issue 176); notable tags 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: Wed, 13 May 2020 18:39:09 -0000 +1 LL > On May 13, 2020, at 8:43 AM, Carsten Bormann wrote: >=20 > On 2020-05-13, at 17:41, Thiago Macieira = wrote: >>=20 >> Then reserve 0xffff, 0xffffffff and 0xffffffffffffffff. >=20 > Makes sense to me. Any opposing views? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Thu May 14 09:31:52 2020 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361AF3A0BD6 for ; Thu, 14 May 2020 09:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxdYCPv0Nush for ; Thu, 14 May 2020 09:31:45 -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 A443D3A0BBF for ; Thu, 14 May 2020 09:31:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5EFEB389D8 for ; Thu, 14 May 2020 12:29:38 -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 AqhLuQxqmm89 for ; Thu, 14 May 2020 12:29:34 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 08F693899A for ; Thu, 14 May 2020 12:29:34 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D9F1D213 for ; Thu, 14 May 2020 12:31:39 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org In-Reply-To: References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@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: [Cbor] my (WGLC re-)views on error processing in RFC7049bis and future-proofing 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, 14 May 2020 16:31:50 -0000 --=-=-= Content-Type: text/plain Carsten and Paul, my appologies for the length of this email. I've been working on this an hour or so a day for a week :-( I will probably reply and emphasis my important points. This document says it is going to Internet Standard, but *only* in the Contributing section. Please also forgive me that I haven't re-read RFC7049 in a long while, so I might be complaining about things that are just matching 7049. Jeffrey Yasskin wrote: >> I am a user of parsers, I have occasionally had to write my own >> conversions, but mostly I would say that I am not up to speed on some >> of the details. > That's all reasonable. :) Given the discussion, and Lawrence's quick > analysis of the existing tags, how do you currently feel about the > state of RFC7049bis's requirements around error handling? Maybe time for a top-to-bottom read. Probably appropriate thing to do during WGLC :-) Intro does say: "It does not create a new version of the format." I think that I'd like to amend this to say that: This document is a revised edition of [RFC7049], 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. -> This document is a revised edition of [RFC7049], with editorial improvements, added detail, and fixed errata. In clarifying some interpretations of [RFC7049] it may in some cases create situations where an existing parser may no longer comply to this specification. While this revision formally obsoletes RFC 7049, it does not obsolete any valid encoders, and thus keeps full compatibility with the interchange format from RFC 7049. It does not create a new version of the format. I note this text (section 2.1): While there is a strong expectation that generic encoders and decoders can represent "false", "true", and "null" ("undefined" is intentionally omitted) in the form appropriate for their programming environment, implementation of the data model extensions created by tags is truly optional and a matter of implementation quality. This seems to have something to do with tags. Also section 2.2 ends with: "0.0" as an integer (major type 0, Section 3.1). However, if a specific data model declares that floating-point and integer representations of integral values are equivalent, using both map keys "0" and "0.0" in a single map would be considered duplicates, even while encoded as different major types, and so invalid; and an encoder could encode integral-valued floats as integers or vice versa, perhaps to save encoded bytes. To me, this says that all generic encoders that intend to return data in the native form of their programming environment need to be configured as to the protocol. This is supporting my suggestion that a well designed library would/could have to be configured for the specific data model when it comes to how unknown tags are treated. > * I'm not opposed to advice for parsers to have an option to treat a > value tagged with an unknown tag as equivalent to the value itself. > * I dislike the idea of any generic parser doing that by default, I think > based on reasoning like in > https://tools.ietf.org/html/draft-iab-protocol-maintenance-04. * If a > parser passes unknown tags up to the application, a higher-level > protocol can ignore them itself, skip their data item, return an error, > or do something else appropriate to the context. So if the RFC should > recommend a default in generic parsers, I'd vote for that one. * I > don't intend to draft this wording myself. :) I think that I'm arguing for generic parsers to be in RFC7049 mode, which might mean ignoring unknown tags (if that's what they did before), passing the data up using whatever native interpretation there is, until they are configured otherwise. That is, if there is a seconds-since-epoch tag (XXX) which a generic parser did not understand, followed by an integer, that it would return an integer if it did not have an interface that passed tags. > 28, 29, 30: These values are reserved for future additions to the > CBOR format. In the present version of CBOR, the encoded item is > not well-formed. I think that there is a bug here. What should a parser written today do when it encounters these values? (forward reference to section 7.2?) Getting this right is how we deal with future-proofing. It seems seeing such a thing means a current decoder has to abort/fail. What we write here has a profound implication, I think, on how easily we could act on the advice of section 7.2. Section 10, first paragraph implies we should say something. In general, I think that the details in this introductionary encoding section are too detailed, particularly for 31. I think that detail belongs later on. I got no value (I retained nothing) from having that level of detail there. I wonder if section 3.1, under major type 0 should give clarify that "0" is encoded as 0b000_00000. (That is no negative 0) "A string containing an invalid UTF-8 sequence is well- formed but invalid." I think that this might need clarification. I guess that RFC8742 include sequences of 7049bis CBOR sequences. I wonder if Updates 8742 is appropriate. > If the break stop code appears after a key in a map, in place of that > key's value, the map is not well-formed. This does mean that the entire map is not well-formed, or just the key/value pair where this occurs? I take the first meaning, but I want to be sure. 3.2.3: (Note that zero-length chunks, while not particularly useful, are permitted.) they might be useful in non-TCP/IP situations where it is useful to send a "keep-alive" on some channel. I think that it might be cleaner to swap the order of sections 3.2 (infinite length things), and 3.3 (floating-point and stuff). This just puts major type 7 more in context first. > As with all other major types, the 5-bit value 24 signifies a single- > byte extension: it is followed by an additional byte to represent the > simple value. (To minimize confusion, only the values 32 to 255 are > used.) This maintains the structure of the initial bytes: as for the Or, to put it another way, 5-bit Values 24->31 in table 3 are also "Simple Values". Could future Simple Values (such as 0..19) can, have complex structure the way that values 24->27 do? Or to put it another way, can a decoder depend upon unassigned simple values having the one-or-two byte structure presented and be able to skip unknown values? Or does a decoder that encounters undefined values here have to fail? > formed. (This implies that an encoder cannot encode false, true, > null, or undefined in two-byte sequences, only the one-byte variants > of these are well-formed.) I here suggest the text say: + formed. (This implies that an encoder cannot encode false, true, + null, floats, undefined-23, reserved-[28..31], or break in two-byte + sequences, only the one-byte variants of these are well-formed.) While it's too late to change, was there a reason "True" didn't get 0b111_00001? Clearly False, and Null would then compete to be 0b111_00000, and maybe that's reason enough to not play such games. Section 3.4 says: } Their primary purpose in this specification is to define common data } types such as dates. A secondary purpose is to provide conversion } hints when it is foreseen that the CBOR data item needs to be } translated into a different format, requiring hints about the content } of items. I don't think that the "primary purpose" is still just dates. The note about "hints" suggests that tags are always advisory, and I think that this thread has established that for some protocols, they really are not. } Understanding the semantics of tags is optional for a } decoder; it can simply present both the tag number and the tag } content to the application, without interpreting the additional } semantics of the tag. I wonder if this text should be stronger. Maybe: + Understanding the semantics of every tag is optional for a decoder; + a decoder MAY simply present some or all tags to the + application, without interpreting the additional + semantics of the tag. I would then go on: + Decoders which translate CBOR values into language specific objects, + (e.g., dates, bignum, example3, ...) MAY consume the tags along with + the values, returning only the language defined object. I note that AFAIK, we do not use tag#24 (Encoded CBOR data item) for the signed object, in COSE. Should we? What's the difference between #24 and #55799. I guess I will read onwards to find out... Got it. BTW: Tag 25 and 29 are called out after Table 5, but are not listed *in* table 5. That whole paragraph could use some more periods, and maybe a blank line. I'm still loss as to why is better than . Why can't we use decimal fractions, or bigfloats for time? I suppose float64 has enough precision for a millenia or so, even if one wants microseconds precision. I think that words "bytewise lexicographic order" used in 4.2.1 may not survive translations in a meaningful way. The eight item example might be clearer if presented in a table so that the bytes can be lined up. If keys of a map have tags, I assume that the tags are to be included in the lexicographically order? Maybe 4.2.3 could cover both ways with a forward reference? I think that 4.2.2 gets into whether or not a tag is required, and I think that it might need to be considered more in context of when tags can be skipped. I think that the the Introduction should have a section 1.3 that addresses the concept of "Protocols" on top of CBOR, referencing section 5. I think that 4.2.2 should forward reference to 5, or maybe sections 4 and 5 I suggest "protocol" be capitalized consistently as Protocol when it is used in this way. I don't find that section 5.2 fits into section 5. I think we already covered this concept. "0x62c0ae" does not contain valid UTF-8 and so is not a valid CBOR item. ...... Generic encoders and decoders are expected to forward simple values and tags even if their specific codepoints are not registered at the time the encoder/decoder is written (Section 5.4). Generic decoders provide ways to present well-formed CBOR values, both valid and invalid, to an application. The diagnostic notation (Section 8) may be used to present well-formed CBOR values to humans. I don't personally know enough UTF-8 to know why the above is invalid UTF-8. Maybe saying that it's not because c0ae is an unsigned code point by because... (I remember the valid MIME and valid UTF-8 debate we had last time, and I am not trying to re-open it.) I think that the second paragraph above should be swapped with the first one. 1. Replace the problematic item with an error marker and continue with the next item, or -> this might be a place where that desired "invalid tag" from last week's discussion fits in!!! Having read through section 5, I believe even more than two weeks ago, that the "65535" tag should go into RFC7049bis, not a new document. 5.3.1 "Duplicate keys in a map" seems to suggest that "Stream Encoder" will be specified/discussed in section 5.6, when in fact that section is about keys, including duplicate keys. Maybe 5.3.1/Basic Validity could go later, or just not be said at all, since the entire section is about this topic? I think that section 7.1 has a lot of aspirational language ("an attempt should..."), which might have been appropriate for the ID that let to 7049, but SHOULD now be definitive. "An attempt was made to make..." -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl69cmsACgkQgItw+93Q 3WXLgAf/W/eM2Ed8IevMXslMAgxcEDi2oMy3PsqYqYTNKofZvlUe+wYDOcwosHu6 +J2sojADOSoYZA6C2nfv0JgPj1tMNR/J86mauZj6w99isb/lUSjbVkOsTTsyHQa2 H2eWOYmYUmZKdGjoyZT+OMHNk83FWh2UBu/dYsebRIbWNwaM4ezoJ3BAb2/fY/Sb fvgNOTCXpO0ggkHrfnZk1hnB/awpFwZWC+cMnDCzwvzDfigZtLnyy88PDDj8zQqx zZYXTcLoqmTPEXJo8Rf9hoSwhhkIynQc2Z5vyaWCoG7MXdu3zymq8XyvAAODrKcp Gc20gUFHU8I0nNjgP2/Q41x6ZMruYA== =bcpA -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 15 16:28: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 0992C3A0C41 for ; Fri, 15 May 2020 16:28:01 -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 SDiMVsvi2p7O for ; Fri, 15 May 2020 16:27: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 3E2A43A0995 for ; Fri, 15 May 2020 16:27:54 -0700 (PDT) Received: from [192.168.217.119] (p548DC699.dip0.t-ipconnect.de [84.141.198.153]) (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 49P4MW1PhqzyVc; Sat, 16 May 2020 01:27: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: <2963.1589473899@localhost> Date: Sat, 16 May 2020 01:27:50 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 611278070.4433759-0564b36d26d6a241cf35243d554b6f05 Content-Transfer-Encoding: quoted-printable Message-Id: References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> <2963.1589473899@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] my (WGLC re-)views on error processing in RFC7049bis and future-proofing 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, 15 May 2020 23:28:03 -0000 Hi Michael, thank you for taking the time to dive deep! I=E2=80=99m going to send multiple versions of this reply, with more and = more answers filled in; I hope this is not too jarring (you can simply = ignore the initial versions if it is). This is version 1 of my = response. > This document says it is going to Internet Standard, but *only* in the = Contributing section. Fellow = https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/?includ= e_text=3D1 does not say it at all=E2=80=A6 (Well, datatracker knows it, but the document is silent.) > Please also forgive me that I haven't re-read RFC7049 in a long while, = so I > might be complaining about things that are just matching 7049. We want to improve on 7049, so if there is a reason to complain, please = do! > Jeffrey Yasskin wrote: >>> I am a user of parsers, I have occasionally had to write my own >>> conversions, but mostly I would say that I am not up to speed on = some >>> of the details. >=20 >> That's all reasonable. :) Given the discussion, and Lawrence's quick >> analysis of the existing tags, how do you currently feel about the >> state of RFC7049bis's requirements around error handling? >=20 > Maybe time for a top-to-bottom read. Probably appropriate thing to do = during WGLC :-) >=20 > Intro does say: "It does not create a new version of the format." >=20 > I think that I'd like to amend this to say that: >=20 > This document is a revised edition of [RFC7049], with editorial > improvements, added detail, and fixed errata. This revision = formally > obsoletes RFC 7049, while keeping full compatibility of the > interchange format from RFC 7049. It does not create a new version > of the format. >=20 > -> > This document is a revised edition of [RFC7049], with editorial > improvements, added detail, and fixed errata. In clarifying some > interpretations of [RFC7049] it may in some cases create situations = where > an existing parser may no longer comply to this specification. > While this revision formally obsoletes RFC 7049, it does not = obsolete > any valid encoders, and thus keeps full compatibility with the > interchange format from RFC 7049. It does not create a new version > of the format. >=20 >=20 > I note this text (section 2.1): >=20 > While there is a strong expectation that generic encoders and > decoders can represent "false", "true", and "null" ("undefined" is > intentionally omitted) in the form appropriate for their programming > environment, implementation of the data model extensions created by > tags is truly optional and a matter of implementation quality. >=20 > This seems to have something to do with tags. >=20 > Also section 2.2 ends with: >=20 > "0.0" as an integer (major type 0, Section 3.1). However, if a > specific data model declares that floating-point and integer > representations of integral values are equivalent, using both map > keys "0" and "0.0" in a single map would be considered duplicates, > even while encoded as different major types, and so invalid; and an > encoder could encode integral-valued floats as integers or vice > versa, perhaps to save encoded bytes. >=20 > To me, this says that all generic encoders that intend to return data = in the > native form of their programming environment need to be configured as = to the > protocol. This is supporting my suggestion that a well designed = library > would/could have to be configured for the specific data model when it = comes > to how unknown tags are treated. >=20 >> * I'm not opposed to advice for parsers to have an option to treat a >> value tagged with an unknown tag as equivalent to the value itself. >=20 >> * I dislike the idea of any generic parser doing that by default, I = think >> based on reasoning like in >> https://tools.ietf.org/html/draft-iab-protocol-maintenance-04. * If = a >> parser passes unknown tags up to the application, a higher-level >> protocol can ignore them itself, skip their data item, return an = error, >> or do something else appropriate to the context. So if the RFC should >> recommend a default in generic parsers, I'd vote for that one. * I >> don't intend to draft this wording myself. :) >=20 > I think that I'm arguing for generic parsers to be in RFC7049 mode, = which > might mean ignoring unknown tags (if that's what they did before), = passing > the data up using whatever native interpretation there is, until they = are > configured otherwise. >=20 > That is, if there is a seconds-since-epoch tag (XXX) which a generic = parser > did not understand, followed by an integer, that it would return an = integer > if it did not have an interface that passed tags. >=20 >> 28, 29, 30: These values are reserved for future additions to the >> CBOR format. In the present version of CBOR, the encoded item is >> not well-formed. >=20 > I think that there is a bug here. > What should a parser written today do when it encounters these values? > (forward reference to section 7.2?) Give up (not well-formed), as there is no way to know how big the head = with these ai values is. > Getting this right is how we deal with future-proofing. We do have extension points that have full compatibility; this potential = one just doesn=E2=80=99t. > It seems seeing such a thing means a current decoder has to = abort/fail. > What we write here has a profound implication, I think, on how easily = we > could act on the advice of section 7.2. =20 It would be a CBOR 1.1 (or 2.0), it will not be easy on existing = decoders! > Section 10, first paragraph implies > we should say something. >=20 > In general, I think that the details in this introductionary encoding = section > are too detailed, particularly for 31. I think that detail belongs = later > on. I got no value (I retained nothing) from having that level of = detail there. >=20 > I wonder if section 3.1, under major type 0 should give clarify that = "0" > is encoded as 0b000_00000. (That is no negative 0) >=20 > "A string containing an invalid UTF-8 sequence is well- > formed but invalid." >=20 > I think that this might need clarification. >=20 > I guess that RFC8742 include sequences of 7049bis CBOR sequences. > I wonder if Updates 8742 is appropriate. You lost me here. >=20 >> If the break stop code appears after a key in a map, in place of = that >> key's value, the map is not well-formed. >=20 > This does mean that the entire map is not well-formed, or just the > key/value pair where this occurs? I take the first meaning, but I = want to be > sure. It says that the map is not well-formed, but of course the whole data = item is dubious as it is not clear whether the map has ended or not. = So, again, give up. Should be clear in Appendix C. > 3.2.3: > (Note that zero-length > chunks, while not particularly useful, are permitted.) >=20 > they might be useful in non-TCP/IP situations where it is useful to = send a > "keep-alive" on some channel. We haven=E2=80=99t addressed general padding im CBOR (which would again = require a 1.1 or 2.0 maybe), and I would hate to suggest this here as = the only padding that CBOR already offers. > I think that it might be cleaner to swap the order of sections 3.2 = (infinite > length things), and 3.3 (floating-point and stuff). This just puts = major > type 7 more in context first. >=20 >> As with all other major types, the 5-bit value 24 signifies a = single- >> byte extension: it is followed by an additional byte to represent = the >> simple value. (To minimize confusion, only the values 32 to 255 are >> used.) This maintains the structure of the initial bytes: as for = the >=20 > Or, to put it another way, 5-bit Values 24->31 in table 3 are also = "Simple > Values". =20 24, yes, 25 to 27 no (floating point), and 28 to 30 are reserved. (31 is the break stop code and not a value at all.) > Could future Simple Values (such as 0..19) can, have complex > structure the way that values 24->27 do? No, the general syntax of heads does apply to the unallocated code = points as well. > Or to put it another way, can a decoder depend upon unassigned simple = values > having the one-or-two byte structure presented and be able to skip = unknown > values? =20 Yes. > Or does a decoder that encounters undefined values here have to > fail? No: 5.2.: Generic encoders and decoders are expected to forward simple values and tags even if their specific codepoints are not registered at the time the encoder/decoder is written (Section 5.4). >> formed. (This implies that an encoder cannot encode false, true, >> null, or undefined in two-byte sequences, only the one-byte variants >> of these are well-formed.) >=20 > I here suggest the text say: >=20 > + formed. (This implies that an encoder cannot encode false, true, > + null, floats, undefined-23, reserved-[28..31], or break in = two-byte > + sequences, only the one-byte variants of these are well-formed.) The implication we give doesn=E2=80=99t have to be exhaustive. The = sentence you propose is very confusing because it is at a different = level: head syntax, but that is not the issue here. The text here is = about the choice that the general head syntax seems to leave for simple = values 0..23, which we are saying it actually doesn=E2=80=99t. > While it's too late to change, was there a reason "True" didn't get = 0b111_00001? Yes. An earlier version of CBOR used simple values 0..15 for some form = of compression. So we allocated the other simple values at the top, not at the bottom. > Clearly False, and Null would then compete to be 0b111_00000, and = maybe > that's reason enough to not play such games. Right. >=20 > Section 3.4 says: >=20 > } Their primary purpose in this specification is to define common = data > } types such as dates. A secondary purpose is to provide conversion > } hints when it is foreseen that the CBOR data item needs to be > } translated into a different format, requiring hints about the = content > } of items. >=20 > I don't think that the "primary purpose" is still just dates. > The note about "hints" suggests that tags are always advisory, and I = think > that this thread has established that for some protocols, they really = are > not. >=20 > } Understanding the semantics of tags is optional for a > } decoder; it can simply present both the tag number and the tag > } content to the application, without interpreting the additional > } semantics of the tag. >=20 > I wonder if this text should be stronger. > Maybe: >=20 > + Understanding the semantics of every tag is optional for a = decoder; > + a decoder MAY simply present some or all tags to the > + application, without interpreting the additional > + semantics of the tag. >=20 > I would then go on: > + Decoders which translate CBOR values into language specific = objects, > + (e.g., dates, bignum, example3, ...) MAY consume the tags along = with > + the values, returning only the language defined object. >=20 > I note that AFAIK, we do not use tag#24 (Encoded CBOR data item) for = the > signed object, in COSE. Should we? > What's the difference between #24 and #55799. 55799 is a tag that can have any CBOR data item as tag content 24 is a tag that can only be on byte strings. The byte string then *encodes* another CBOR data item. (The main use here is to keep the decoder from decoding, to provide easy = skip-ability or because we need exact bytes as in COSE.) As often with tags, there is no need for tag 24 on a byte string when it = is clear from context that the byte string contains encoded CBOR; this = is the case in COSE. > I guess I will read onwards to find out... Got it. >=20 > BTW: Tag 25 and 29 are called out after Table 5, but are not listed = *in* table 5. > That whole paragraph could use some more periods, and maybe a blank = line. > I'm still loss as to why is better than = . >=20 > Why can't we use decimal fractions, or bigfloats for time? That may have been a mistake (which is one reason we have tag 1001 now). The WG has generally taken a dim view on extending the domain (allowable = syntax for tag content) for a tag, so we can=E2=80=99t =E2=80=9Cfix=E2=80=9D= that =E2=80=94 note that for the date tag, we have taken the decision = not to reuse one tag for two different tag content syntaxes either. > I suppose float64 has enough precision for a millenia or so, even if = one > wants microseconds precision. It has 53 bits of precision, so it gives ~ microseconds (~ 20 bits after = the decimal point) for 2**33 seconds or 272 years from the epoch or = until 2242. Four microseconds until 3058. > I think that words "bytewise lexicographic order" used in 4.2.1 may = not > survive translations in a meaningful way. The eight item example = might be > clearer if presented in a table so that the bytes can be lined up. > If keys of a map have tags, I assume that the tags are to be included = in the > lexicographically order? Maybe 4.2.3 could cover both ways with a = forward reference? >=20 > I think that 4.2.2 gets into whether or not a tag is required, and I = think > that it might need to be considered more in context of when tags can = be > skipped. >=20 > I think that the the Introduction should have a section 1.3 that = addresses > the concept of "Protocols" on top of CBOR, referencing section 5. > I think that 4.2.2 should forward reference to 5, or maybe sections 4 = and 5 > I suggest "protocol" be capitalized consistently as Protocol when it = is used > in this way. >=20 > I don't find that section 5.2 fits into section 5. > I think we already covered this concept. >=20 > "0x62c0ae" does not contain valid UTF-8 and so is not a valid CBOR > item. ...... > Generic encoders and decoders are > expected to forward simple values and tags even if their specific > codepoints are not registered at the time the encoder/decoder is > written (Section 5.4). >=20 > Generic decoders provide ways to present well-formed CBOR values, > both valid and invalid, to an application. The diagnostic notation > (Section 8) may be used to present well-formed CBOR values to = humans. >=20 > I don't personally know enough UTF-8 to know why the above is invalid = UTF-8. > Maybe saying that it's not because c0ae is an unsigned code point by = because... > (I remember the valid MIME and valid UTF-8 debate we had last time, = and I am > not trying to re-open it.) > I think that the second paragraph above should be swapped with the = first one. >=20 > 1. Replace the problematic item with an error marker and continue > with the next item, or >=20 > -> this might be a place where that desired "invalid tag" from last = week's > discussion fits in!!! >=20 > Having read through section 5, I believe even more than two weeks ago, = that > the "65535" tag should go into RFC7049bis, not a new document. We didn=E2=80=99t want new stuff in 7049bis, so this is now in = draft-bormann-cbor-notable-tags with a mention here; RFC7049bis combines = with its registries to give the full semantics of CBOR, so this is OK. > 5.3.1 "Duplicate keys in a map" seems to suggest that "Stream Encoder" = will > be specified/discussed in section 5.6, when in fact that section is = about > keys, including duplicate keys. Maybe 5.3.1/Basic Validity could go = later, > or just not be said at all, since the entire section is about this = topic? >=20 > I think that section 7.1 has a lot of aspirational language ("an = attempt > should..."), which might have been appropriate for the ID that let to = 7049, > but SHOULD now be definitive. "An attempt was made to make..." Section 7 may need another fine combing, indeed. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri May 15 18:41:18 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 BC6893A08B1 for ; Fri, 15 May 2020 18:41:09 -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 QUMOH6oTlVVJ for ; Fri, 15 May 2020 18:41:07 -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 40FEC3A0843 for ; Fri, 15 May 2020 18:41:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2695738A3E; Fri, 15 May 2020 21:38:42 -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 emV3KVFUeIfc; Fri, 15 May 2020 21:38:25 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 064FC38A14; Fri, 15 May 2020 21:38:25 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0E8A7516; Fri, 15 May 2020 21:40:22 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: cbor@ietf.org In-Reply-To: References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> <2963.1589473899@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] my (WGLC re-)views on error processing in RFC7049bis and future-proofing 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, 16 May 2020 01:41:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >>> 28, 29, 30: These values are reserved for future additions to the >>> CBOR format. In the present version of CBOR, the encoded item is n= ot >>> well-formed. >> >> I think that there is a bug here. What should a parser written today >> do when it encounters these values? (forward reference to section >> 7.2?) > Give up (not well-formed), as there is no way to know how big the head > with these ai values is. Give up, returning the content so-far, or ?? >> Getting this right is how we deal with future-proofing. > We do have extension points that have full compatibility; this > potential one just doesn=E2=80=99t. >> It seems seeing such a thing means a current decoder has to >> abort/fail. What we write here has a profound implication, I think, >> on how easily we could act on the advice of section 7.2. > It would be a CBOR 1.1 (or 2.0), it will not be easy on existing > decoders! Should we plan a tag for version? >> Section 10, first paragraph implies we should say something. >> >> In general, I think that the details in this introductionary encoding >> section are too detailed, particularly for 31. I think that detail >> belongs later on. I got no value (I retained nothing) from having th= at >> level of detail there. >> >> I wonder if section 3.1, under major type 0 should give clarify that >> "0" is encoded as 0b000_00000. (That is no negative 0) >> >> "A string containing an invalid UTF-8 sequence is well- formed but >> invalid." >> >> I think that this might need clarification. >> >> I guess that RFC8742 include sequences of 7049bis CBOR sequences. I >> wonder if Updates 8742 is appropriate. > You lost me here. Do we need to Update 8742 too? >> 3.2.3: (Note that zero-length chunks, while not particularly useful, >> are permitted.) >> >> they might be useful in non-TCP/IP situations where it is useful to >> send a "keep-alive" on some channel. > We haven=E2=80=99t addressed general padding im CBOR (which would aga= in require > a 1.1 or 2.0 maybe), and I would hate to suggest this here as the only > padding that CBOR already offers. Okay, so maybe forward to Protocol. >> Could future Simple Values (such as 0..19) can, have complex structu= re >> the way that values 24->27 do? > No, the general syntax of heads does apply to the unallocated code > points as well. I think we should state this. It's a extension point that we can reliably = skip. >> I note that AFAIK, we do not use tag#24 (Encoded CBOR data item) for >> the signed object, in COSE. Should we? What's the difference betwe= en >> #24 and #55799. > 55799 is a tag that can have any CBOR data item as tag content 24 is a > tag that can only be on byte strings. The byte string then *encodes* > another CBOR data item. (The main use here is to keep the decoder fr= om > decoding, to provide easy skip-ability or because we need exact bytes > as in COSE.) As often with tags, there is no need for tag 24 on a by= te > string when it is clear from context that the byte string contains > encoded CBOR; this is the case in COSE. Understood. >> I guess I will read onwards to find out... Got it. >> >> BTW: Tag 25 and 29 are called out after Table 5, but are not listed >> *in* table 5. That whole paragraph could use some more periods, and >> maybe a blank line. I'm still loss as to why is >> better than . >> >> Why can't we use decimal fractions, or bigfloats for time? > That may have been a mistake (which is one reason we have tag 1001 > now). The WG has generally taken a dim view on extending the domain > (allowable syntax for tag content) for a tag, so we can=E2=80=99t =E2= =80=9Cfix=E2=80=9D that =E2=80=94 > note that for the date tag, we have taken the decision not to reuse o= ne > tag for two different tag content syntaxes either. okay. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6/RIUACgkQgItw+93Q 3WW+Bwf/RqoNDFKvM+Ppl79q8ZNczTrMmx2FO8sFitqzuN9sRf87cCbDQpJIL+oZ 4Y9mQIihkVr50PxiOFIHizhCMCQBZf+IXWdrmU7rhWa4C44yl7To3u5NQKiCCmba 9LWIys6DRyAmKF52hXumvYySjLK87LiD12JFWpUE5QxokF1lOxgMbBwXVRSsn1JI NZ7ZpEq72i208Vy9mALLKmeu16W3ROxVsKp/uUFfAS5GYq6fZ7+WHfeMV4oFHVBl SFr7nWr9cI1ZPTGpI0eUMsQxeu12bfkoumzkcxDaprjP6Fxs1bOytLP4DMCaaY4Q k0MzXhvpPPUQUKxF+qdeMRJxhXJOMQ== =smit -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 15 23:49: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 C38C23A0813 for ; Fri, 15 May 2020 23:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 c-UbbxeR3bME for ; Fri, 15 May 2020 23:49: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 3D0E53A080E for ; Fri, 15 May 2020 23:49:28 -0700 (PDT) Received: from [192.168.217.119] (p548DC699.dip0.t-ipconnect.de [84.141.198.153]) (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 49PG9248NQzySP; Sat, 16 May 2020 08:49: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: <26665.1589593222@localhost> Date: Sat, 16 May 2020 08:49:25 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 611304565.650685-67a4815eb07b9b9d3a4f2ff6bd7613e6 Content-Transfer-Encoding: quoted-printable Message-Id: References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> <2963.1589473899@localhost> <26665.1589593222@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] my (WGLC re-)views on error processing in RFC7049bis and future-proofing 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, 16 May 2020 06:49:37 -0000 Good morning Michael, a few quick answers to your quick answers to my first quick answers. > Carsten Bormann wrote: >>>> 28, 29, 30: These values are reserved for future additions to the >>>> CBOR format. In the present version of CBOR, the encoded item is = not >>>> well-formed. >>>=20 >>> I think that there is a bug here. What should a parser written = today >>> do when it encounters these values? (forward reference to section >>> 7.2?) >=20 >> Give up (not well-formed), as there is no way to know how big the = head >> with these ai values is. >=20 > Give up, returning the content so-far, or ?? 1.2: CBOR decoders by definition only return contents from well-formed data items. So the answer is =E2=80=9Creturn an error=E2=80=9D. >=20 >>> Getting this right is how we deal with future-proofing. >=20 >> We do have extension points that have full compatibility; this >> potential one just doesn=E2=80=99t. >=20 >>> It seems seeing such a thing means a current decoder has to >>> abort/fail. What we write here has a profound implication, I think, >>> on how easily we could act on the advice of section 7.2. >=20 >> It would be a CBOR 1.1 (or 2.0), it will not be easy on existing >> decoders! >=20 > Should we plan a tag for version? No. First of all, we have no idea whether the room we left here in the = encoding space will ever be exercised. Yes, it is an attractive = nuisance (not exercising it leaves one feel strangely unsatisfied), but = people have been happy with the other ways to indicated 128-bit etc. = values. Second, the habit to put versions in interchange specifications = generally is misguided. Unless they are needed to prevent false = interoperability. But false interoperability cannot happen here, as the = reserved ai values are easily recognizable as such. (CBOR is designed to be versionless, by defining well-defined extension = points. Version indications also would take significant space in one = major area of application of CBOR: Small data items.) >=20 >>> Section 10, first paragraph implies we should say something. >>>=20 >>> In general, I think that the details in this introductionary = encoding >>> section are too detailed, particularly for 31. I think that detail >>> belongs later on. I got no value (I retained nothing) from having = that >>> level of detail there. >>>=20 >>> I wonder if section 3.1, under major type 0 should give clarify that >>> "0" is encoded as 0b000_00000. (That is no negative 0) >>>=20 >>> "A string containing an invalid UTF-8 sequence is well- formed but >>> invalid." >>>=20 >>> I think that this might need clarification. >>>=20 >>> I guess that RFC8742 include sequences of 7049bis CBOR sequences. I >>> wonder if Updates 8742 is appropriate. >=20 >> You lost me here. >=20 > Do we need to Update 8742 too? But nothing is updated, and certainly not in 8742? >>> 3.2.3: (Note that zero-length chunks, while not particularly useful, >>> are permitted.) >>>=20 >>> they might be useful in non-TCP/IP situations where it is useful to >>> send a "keep-alive" on some channel. >=20 >> We haven=E2=80=99t addressed general padding im CBOR (which would = again require >> a 1.1 or 2.0 maybe), and I would hate to suggest this here as the = only >> padding that CBOR already offers. >=20 > Okay, so maybe forward to Protocol. Yes. >>> Could future Simple Values (such as 0..19) can, have complex = structure >>> the way that values 24->27 do? >=20 >> No, the general syntax of heads does apply to the unallocated code >> points as well. >=20 > I think we should state this. It's a extension point that we can = reliably skip. Well, if we say how heads are decoded, that should be enough =E2=80=94 = we don=E2=80=99t have to restate that everywhere they are used. But = maybe I don=E2=80=99t understand where you see the extension point here. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat May 16 15:28: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 E190B3A0BAB for ; Sat, 16 May 2020 15:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 3IfdkRDAl8Jg for ; Sat, 16 May 2020 15:28:03 -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 D57A43A0BA9 for ; Sat, 16 May 2020 15:28:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1C06438A7B; Sat, 16 May 2020 18:25:38 -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 a28zQgakdi5q; Sat, 16 May 2020 18:25:20 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4CCEA38A7A; Sat, 16 May 2020 18:25:20 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F32A5A3; Sat, 16 May 2020 18:27:17 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: cbor@ietf.org In-Reply-To: References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> <2963.1589473899@localhost> <26665.1589593222@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] my (WGLC re-)views on error processing in RFC7049bis and future-proofing 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, 16 May 2020 22:28:06 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >>> No, the general syntax of heads does apply to the unallocated code >>> points as well. >> I think we should state this. It's a extension point that we can >> reliably skip. > Well, if we say how heads are decoded, that should be enough =E2=80= =94 we don=E2=80=99t > have to restate that everywhere they are used. But maybe I don=E2=80= =99t > understand where you see the extension point here. I think that maybe we just need to be a bit more regular in how we describe things. I like how the document begins, and how it gets a good idea for how things work without drowning me in detail. But, I think that we then need to make sure that we are being authoritative afterwards. Yes, I think we need to beat people on the head. In a long document, people can't read it in one sitting, and so they use it as reference. They read only the part that they are working on at that moment. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7AaMUACgkQgItw+93Q 3WWipQf/VHDFMkZaJ280/o5bZWCEiKI/U+ULvjA4rmnnuAstuOhGt8SZI4LPYUpQ qGFlq9I1O1ESq5/x/PX+6I2GSMO0W8SWadR8wfwIbNM7nWZPpthC+g81LTgWniB5 wxLKfecBr7pss/SfekpwpBzqNkuoF0mfPNbgbK9tBicefSpumvaDwHIZAPbgw07f Sqz+4WVbqZgCVydrlPWQKTTbkJM/JZii7bMbHYW6h5Ib/SYDE3lrt3Ye4Rh+BOnL 2gJPrVjjxSqdKbcSAjMLngLezZ4riX3ah9rYp4IflnrpxLALcIeY6PFM1sOcf4GX 2RMH4ZbMVbnlMbIZZAfwjyWli/Xfnw== =hN4A -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun May 17 09:30: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 A4F573A090A for ; Sun, 17 May 2020 09:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 YIyfOYO8ImQ0 for ; Sun, 17 May 2020 09:30:23 -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 7A12B3A07AC for ; Sun, 17 May 2020 09:30:23 -0700 (PDT) Received: from [192.168.217.119] (p548DC699.dip0.t-ipconnect.de [84.141.198.153]) (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 49Q70r3WFnzycs; Sun, 17 May 2020 18:30:20 +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: <20723.1589668037@localhost> Date: Sun, 17 May 2020 18:30:19 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 611425819.712767-b19c93071fcc14e39b70d8ec9a4e522c Content-Transfer-Encoding: quoted-printable Message-Id: <81FD6C7E-9AF9-4A9D-91E2-B6D0AF92C25F@tzi.org> References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> <2963.1589473899@localhost> <26665.1589593222@localhost> <20723.1589668037@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] my (WGLC re-)views on error processing in RFC7049bis and future-proofing 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, 17 May 2020 16:30:27 -0000 > On 2020-05-17, at 00:27, Michael Richardson = wrote: >=20 >=20 > Carsten Bormann wrote: >>>> No, the general syntax of heads does apply to the unallocated code >>>> points as well. >=20 >>> I think we should state this. It's a extension point that we can >>> reliably skip. >=20 >> Well, if we say how heads are decoded, that should be enough =E2=80=94 = we don=E2=80=99t >> have to restate that everywhere they are used. But maybe I don=E2=80=99= t >> understand where you see the extension point here. >=20 > I think that maybe we just need to be a bit more regular in how we = describe > things. I like how the document begins, and how it gets a good idea = for how > things work without drowning me in detail. >=20 > But, I think that we then need to make sure that we are being = authoritative > afterwards. Yes, I think we need to beat people on the head. In a = long > document, people can't read it in one sitting, and so they use it as > reference. They read only the part that they are working on at that = moment. Now PR #186: https://github.com/cbor-wg/CBORbis/pull/186 Back to your other comments... Gr=C3=BC=C3=9Fe, Carsten From nobody Tue May 19 03:53:43 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 CF36F3A00B0; Tue, 19 May 2020 03:53:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158988561467.2154.12381297433805201852@ietfa.amsl.com> Date: Tue, 19 May 2020 03:53:34 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-05-20 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, 19 May 2020 10:53:35 -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-05-20 from 17:00 to 18:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: CBOR WG Meeting - Interim 20-09 Wednesday, May 20, 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 Etherpad: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-cbor-09 Agenda: * CBOR specification status : Carsten https://tools.ietf.org/html/draft-ietf-cbor-7049bis-13 - unknown tag conclusion (mail thread here: https://mailarchive.ietf.org/arch/msg/cbor/S6TmVACm7I6tHrbyDwVvgOikIM8/) - mcr review status (mail thread here: https://mailarchive.ietf.org/arch/msg/cbor/QOk_hrJoF8NcuiorkeXex9mUH4w/) * CBOR notable tags : Carsten https://tools.ietf.org/html/draft-bormann-cbor-notable-tags-01 * AoB Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m5db53ad850244e25fcecf10c30a1a811 Meeting number (access code): 647 836 420 Meeting password: emHrigC22K4 From nobody Wed May 20 06:31: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 9FCFF3A09AA for ; Wed, 20 May 2020 06:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3-aqTW7Hy5q5 for ; Wed, 20 May 2020 06:30: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 A882E3A09A9 for ; Wed, 20 May 2020 06:30:54 -0700 (PDT) Received: from [192.168.217.119] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (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 49RttP2Jbtzydq; Wed, 20 May 2020 15:30:53 +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, 20 May 2020 15:30:52 +0200 Cc: Michael Richardson , cbor@ietf.org X-Mao-Original-Outgoing-Id: 611674251.9330471-f7002a426a0d7606f6d42c73a67c69e2 Content-Transfer-Encoding: quoted-printable Message-Id: References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] RFC7049bis processing of unknown tags 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, 20 May 2020 13:30:59 -0000 On 2020-05-07, at 19:57, Laurence Lundblade = wrote: >=20 > However, there is no way to generically know if a tag is a hint, CoAP options carry a bit that tells the receiver whether processing (and = thus understanding) the option is Critical or Elective. We didn=E2=80=99t= do the same for CBOR tags. But, as you say, most tag usage is not just = for a hint, so it is right to emphasize the handling as an =E2=80=9Cunknow= n tag=E2=80=9D. I searched for =E2=80=9Cignore=E2=80=9D in the current draft. There is some ignoring of unknown tags in the proposed CBOR-to-JSON = conversion. I think this is acceptable. (There is also some text about ignoring encoding hints in diagnostic = notation, unrelated to tags.) For the occurrence in 7.1 (which I should have caught when handling = Jeffrey=E2=80=99s pull request), I propose a slight rewording to stay = closer to what we are trying to say. https://github.com/cbor-wg/CBORbis/pull/187 Note that we also have =C2=BBGeneric encoders and decoders are expected = to forward simple values and tags even if their specific codepoints are not registered at the time the encoder/decoder is written ({{validity-checking}}).=C2=AB (Section 5.2) =E2=80=94 we could add some = exhortations about their API here for the case that they don=E2=80=99t, = or we could leave that as is. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 20 07:50: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 6828E3A0A69 for ; Wed, 20 May 2020 07:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 p2dLrCioAemF for ; Wed, 20 May 2020 07:49: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 C339F3A0A0E for ; Wed, 20 May 2020 07:49:54 -0700 (PDT) Received: from [192.168.217.119] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (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 49RwdV2TglzySM; Wed, 20 May 2020 16:49: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: <2963.1589473899@localhost> Date: Wed, 20 May 2020 16:49:49 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 611678989.4689569-7cb80b15a8e40de33e658a2dc6d12dde Content-Transfer-Encoding: quoted-printable Message-Id: <377E8232-0638-419F-8D79-710F42C2B4E3@tzi.org> References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> <2963.1589473899@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] my (WGLC re-)views on error processing in RFC7049bis and future-proofing 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, 20 May 2020 14:49:59 -0000 Hi Michael, This is the second version of this reply. Items that I think we have handled are removed. > Jeffrey Yasskin wrote: >>> I am a user of parsers, I have occasionally had to write my own >>> conversions, but mostly I would say that I am not up to speed on = some >>> of the details. >=20 >> That's all reasonable. :) Given the discussion, and Lawrence's quick >> analysis of the existing tags, how do you currently feel about the >> state of RFC7049bis's requirements around error handling? >=20 > Maybe time for a top-to-bottom read. Probably appropriate thing to do = during WGLC :-) >=20 > Intro does say: "It does not create a new version of the format." >=20 > I think that I'd like to amend this to say that: >=20 > This document is a revised edition of [RFC7049], with editorial > improvements, added detail, and fixed errata. This revision formally > obsoletes RFC 7049, while keeping full compatibility of the > interchange format from RFC 7049. It does not create a new version > of the format. >=20 > -> > This document is a revised edition of [RFC7049], with editorial > improvements, added detail, and fixed errata. In clarifying some > interpretations of [RFC7049] it may in some cases create situations = where > an existing parser may no longer comply to this specification. > While this revision formally obsoletes RFC 7049, it does not obsolete > any valid encoders, and thus keeps full compatibility with the > interchange format from RFC 7049. It does not create a new version > of the format. I don=E2=80=99t think we want to go to that level of detail right there = in the intro. I=E2=80=99m also not sure 7049 was formally defining =E2=80=9Ccompliance=E2= =80=9D of decoders. I think we could move some of this thinking into the =E2=80=9Cchanges = from 7049=E2=80=9D appendix, the fate of which we haven=E2=80=99t really = decided as a WG yet. > I note this text (section 2.1): >=20 > While there is a strong expectation that generic encoders and > decoders can represent "false", "true", and "null" ("undefined" is > intentionally omitted) in the form appropriate for their programming > environment, implementation of the data model extensions created by > tags is truly optional and a matter of implementation quality. >=20 > This seems to have something to do with tags. Yes. Implementation of specific tags was always optional with CBOR; there is = no single =E2=80=9Crequired tag=E2=80=9D. > Also section 2.2 ends with: >=20 > "0.0" as an integer (major type 0, Section 3.1). However, if a > specific data model declares that floating-point and integer > representations of integral values are equivalent, using both map > keys "0" and "0.0" in a single map would be considered duplicates, > even while encoded as different major types, and so invalid; and an > encoder could encode integral-valued floats as integers or vice > versa, perhaps to save encoded bytes. >=20 > To me, this says that all generic encoders that intend to return data = in the > native form of their programming environment need to be configured as = to the > protocol. This is supporting my suggestion that a well designed = library > would/could have to be configured for the specific data model when it = comes > to how unknown tags are treated. I=E2=80=99d say the implementation of the specific data model has to be = configured for the library... >> * I'm not opposed to advice for parsers to have an option to treat a >> value tagged with an unknown tag as equivalent to the value itself. >=20 >> * I dislike the idea of any generic parser doing that by default, I = think >> based on reasoning like in >> https://tools.ietf.org/html/draft-iab-protocol-maintenance-04. * If = a >> parser passes unknown tags up to the application, a higher-level >> protocol can ignore them itself, skip their data item, return an = error, >> or do something else appropriate to the context. So if the RFC should >> recommend a default in generic parsers, I'd vote for that one. * I >> don't intend to draft this wording myself. :) >=20 > I think that I'm arguing for generic parsers to be in RFC7049 mode, (I don=E2=80=99t think that is a thing.) > which > might mean ignoring unknown tags (if that's what they did before), = passing > the data up using whatever native interpretation there is, until they = are > configured otherwise. Generic decoders that want to evolve to be usable with applications that = need tag support will need to develop a transition strategy. Isn=E2=80=99= t that obvious to any library developer? > That is, if there is a seconds-since-epoch tag (XXX) which a generic = parser > did not understand, followed by an integer, that it would return an = integer > if it did not have an interface that passed tags. That generic decoder would not be useful for an application that needs = to be able to handle both integers and time tags in the same position. = That doesn=E2=80=99t change. [Skipping the 28, 29, 30 part, because I think #186 addressed it.] > In general, I think that the details in this introductionary encoding = section > are too detailed, particularly for 31. I think that detail belongs = later > on. I got no value (I retained nothing) from having that level of = detail there. I think there was another proposal to move around elements of Section 3. Sometimes it is necessary to include some detail in an overview for = completeness; we can=E2=80=99t really pretend ai=3D31 does not exist for = a few sections and then do a surprise reveal, can we? > I wonder if section 3.1, under major type 0 should give clarify that = "0" > is encoded as 0b000_00000. (That is no negative 0) Is this really more about major type 1, and the value -1? > "A string containing an invalid UTF-8 sequence is well- > formed but invalid." >=20 > I think that this might need clarification. Not for a pedantic like me who has already memorized the content of = Section 1.2=E2=80=A6 > I guess that RFC8742 include sequences of 7049bis CBOR sequences. > I wonder if Updates 8742 is appropriate. You still lost me here. What are 7049 CBOR sequences? Oh. We are talking about =E2=80=9CData Streams=E2=80=9D. This probably = should mention RFC 8742 (which only happens in 3.1)! >=20 >> If the break stop code appears after a key in a map, in place of that >> key's value, the map is not well-formed. >=20 > This does mean that the entire map is not well-formed, or just the > key/value pair where this occurs? I take the first meaning, but I = want to be > sure. It says that the map is not well-formed, but of course the whole data = item is dubious as it is not clear whether the map has ended or not. = So, again, give up. Should be clear in Appendix C. > 3.2.3: > (Note that zero-length > chunks, while not particularly useful, are permitted.) >=20 > they might be useful in non-TCP/IP situations where it is useful to = send a > "keep-alive" on some channel. We haven=E2=80=99t addressed general padding in CBOR (which would again = require a 1.1 or 2.0 maybe), and I would hate to suggest this here as = the only padding that CBOR already offers. > I think that it might be cleaner to swap the order of sections 3.2 = (infinite > length things), and 3.3 (floating-point and stuff). This just puts = major > type 7 more in context first. >=20 >> As with all other major types, the 5-bit value 24 signifies a single- >> byte extension: it is followed by an additional byte to represent the >> simple value. (To minimize confusion, only the values 32 to 255 are >> used.) This maintains the structure of the initial bytes: as for the >=20 > Or, to put it another way, 5-bit Values 24->31 in table 3 are also = "Simple > Values". =20 24, yes, 25 to 27 no (floating point), and 28 to 30 are reserved. (31 is the break stop code and not a value at all.) > Could future Simple Values (such as 0..19) can, have complex > structure the way that values 24->27 do? No, the general syntax of heads does apply to the unallocated code = points as well. > Or to put it another way, can a decoder depend upon unassigned simple = values > having the one-or-two byte structure presented and be able to skip = unknown > values? =20 Yes. > Or does a decoder that encounters undefined values here have to > fail? No: 5.2.: Generic encoders and decoders are expected to forward simple values and tags even if their specific codepoints are not registered at the time the encoder/decoder is written (Section 5.4). >> formed. (This implies that an encoder cannot encode false, true, >> null, or undefined in two-byte sequences, only the one-byte variants >> of these are well-formed.) >=20 > I here suggest the text say: >=20 > + formed. (This implies that an encoder cannot encode false, true, > + null, floats, undefined-23, reserved-[28..31], or break in = two-byte > + sequences, only the one-byte variants of these are well-formed.) The implication we give doesn=E2=80=99t have to be exhaustive. The = sentence you propose is very confusing because it is at a different = level: head syntax, but that is not the issue here. The text here is = about the choice that the general head syntax seems to leave for simple = values 0..23, which we are saying it actually doesn=E2=80=99t. > While it's too late to change, was there a reason "True" didn't get = 0b111_00001? Yes. An earlier version of CBOR used simple values 0..15 for some form = of compression. So we allocated the other simple values at the top, not at the bottom. > Clearly False, and Null would then compete to be 0b111_00000, and = maybe > that's reason enough to not play such games. Right. >=20 > Section 3.4 says: >=20 > } Their primary purpose in this specification is to define common = data > } types such as dates. A secondary purpose is to provide conversion > } hints when it is foreseen that the CBOR data item needs to be > } translated into a different format, requiring hints about the = content > } of items. >=20 > I don't think that the "primary purpose" is still just dates. Dates were an example here (and we might soon have a data tag :-). > The note about "hints" suggests that tags are always advisory, In the second case =E2=80=94 does it really suggest that for the data = types? > and I think > that this thread has established that for some protocols, they really = are > not. >=20 > } Understanding the semantics of tags is optional for a > } decoder; it can simply present both the tag number and the tag > } content to the application, without interpreting the additional > } semantics of the tag. >=20 > I wonder if this text should be stronger. > Maybe: >=20 > + Understanding the semantics of every tag is optional for a = decoder; each, actually (I prefer not to spell that out). > + a decoder MAY simply present some or all tags to the > + application, without interpreting the additional > + semantics of the tag. I don=E2=80=99t like interoperability keywords in such places. > I would then go on: > + Decoders which translate CBOR values into language specific = objects, > + (e.g., dates, bignum, example3, ...) MAY consume the tags along = with > + the values, returning only the language defined object. >=20 > I note that AFAIK, we do not use tag#24 (Encoded CBOR data item) for = the > signed object, in COSE. Should we? > What's the difference between #24 and #55799. 55799 is a tag that can have any CBOR data item as tag content 24 is a tag that can only be on byte strings. The byte string then *encodes* another CBOR data item. (The main use here is to keep the decoder from decoding, to provide easy = skip-ability or because we need exact bytes as in COSE.) As often with tags, there is no need for tag 24 on a byte string when it = is clear from context that the byte string contains encoded CBOR; this = is the case in COSE. > I guess I will read onwards to find out... Got it. >=20 > BTW: Tag 25 and 29 are called out after Table 5, but are not listed = *in* table 5. > That whole paragraph could use some more periods, and maybe a blank = line. > I'm still loss as to why is better than = . >=20 > Why can't we use decimal fractions, or bigfloats for time? That may have been a mistake (which is one reason we have tag 1001 now). The WG has generally taken a dim view on extending the domain (allowable = syntax for tag content) for a tag, so we can=E2=80=99t =E2=80=9Cfix=E2=80=9D= that =E2=80=94 note that for the date tag, we have taken the decision = not to reuse one tag for two different tag content syntaxes either. > I suppose float64 has enough precision for a millenia or so, even if = one > wants microseconds precision. It has 53 bits of precision, so it gives ~ microseconds (~ 20 bits after = the decimal point) for 2**33 seconds or 272 years from the epoch or = until 2242. Four microseconds until 3058. > I think that words "bytewise lexicographic order" used in 4.2.1 may = not > survive translations in a meaningful way. Deepl turns this into "byteweise lexikographische Ordnung=E2=80=9D, na = ja. The next alternative "byteweise lexikographische Reihenfolge=E2=80=9D is = very close. No idea about "ordre lexicographique par octet=E2=80=9D. Or "=D0=BF=D0=BE=D1=88=D0=B0=D0=B3=D0=BE=D0=B2=D1=8B=D0=B9 = =D0=BB=D0=B5=D0=BA=D1=81=D0=B8=D0=BA=D0=BE=D0=B3=D1=80=D0=B0=D1=84=D0=B8=D1= =87=D0=B5=D1=81=D0=BA=D0=B8=D0=B9 =D0=BF=D0=BE=D1=80=D1=8F=D0=B4=D0=BE=D0=BA= =E2=80=9D, for that matter. But "=E5=AD=97=E8=8A=82=E8=AF=8D=E5=BA=8F=E2=80=9D looks really good :-) = (and is completely wrong). > The eight item example might be > clearer if presented in a table so that the bytes can be lined up. > If keys of a map have tags, I assume that the tags are to be included = in the > lexicographically order? Maybe 4.2.3 could cover both ways with a = forward reference? Well, 4.2.3 is the old (7049) ordering. > I think that 4.2.2 gets into whether or not a tag is required, and I = think > that it might need to be considered more in context of when tags can = be > skipped. But it is about deterministic encoding, not about that other = discussion=E2=80=A6 > I think that the the Introduction should have a section 1.3 that = addresses > the concept of "Protocols" on top of CBOR, referencing section 5. > I think that 4.2.2 should forward reference to 5, or maybe sections 4 = and 5 > I suggest "protocol" be capitalized consistently as Protocol when it = is used > in this way. >=20 > I don't find that section 5.2 fits into section 5. > I think we already covered this concept. This section reaffirms to concept developed above. It also discusses = the application interface =E2=80=94 have we really covered that here? >=20 > "0x62c0ae" does not contain valid UTF-8 and so is not a valid CBOR > item. ...... > Generic encoders and decoders are > expected to forward simple values and tags even if their specific > codepoints are not registered at the time the encoder/decoder is > written (Section 5.4). >=20 > Generic decoders provide ways to present well-formed CBOR values, > both valid and invalid, to an application. The diagnostic notation > (Section 8) may be used to present well-formed CBOR values to humans. >=20 > I don't personally know enough UTF-8 to know why the above is invalid = UTF-8. Because it uses a long form where there is a shorter form - UTF-8 uses = deterministic (shortest) encoding. > Maybe saying that it's not because c0ae is an unsigned code point by = because... This is a mild reminder that you have to read up on UTF-8 to understand = CBOR. > (I remember the valid MIME and valid UTF-8 debate we had last time, = and I am > not trying to re-open it.) > I think that the second paragraph above should be swapped with the = first one. Well, that would expose that the paragraphs are partially redundant =E2=80= =A6 Now https://github.com/cbor-wg/CBORbis/issues/189 > 1. Replace the problematic item with an error marker and continue > with the next item, or >=20 > -> this might be a place where that desired "invalid tag" from last = week's > discussion fits in!!! Well, hmm. The tag is invalid in interchange to allow the = implementation to do with it what it wants, so, yes, you are right, but = that wasn=E2=80=99t the intention for its use. > Having read through section 5, I believe even more than two weeks ago, = that > the "65535" tag should go into RFC7049bis, not a new document. We didn=E2=80=99t want new stuff in 7049bis, so this is now in = draft-bormann-cbor-notable-tags with a mention here; RFC7049bis combines = with its registries to give the full semantics of CBOR, so this is OK. > 5.3.1 "Duplicate keys in a map" seems to suggest that "Stream Encoder" = will > be specified/discussed in section 5.6, when in fact that section is = about > keys, including duplicate keys. Maybe 5.3.1/Basic Validity could go = later, > or just not be said at all, since the entire section is about this = topic? It sure needs to be said (and the term introduced). The section 5.6 reference needs to be pulled out of the last sentence. Now https://github.com/cbor-wg/CBORbis/pull/190 >=20 > I think that section 7.1 has a lot of aspirational language ("an = attempt > should..."), which might have been appropriate for the ID that let to = 7049, > but SHOULD now be definitive. "An attempt was made to make..." Section 7 may need another fine combing, indeed (and now has some comb = marks in #187). Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 21 10:45: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 E35C23A0ABE for ; Thu, 21 May 2020 10:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JJ3n1G6qCSf for ; Thu, 21 May 2020 10:45:22 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 942BA3A0A9B for ; Thu, 21 May 2020 10:45:22 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id m44so6155017qtm.8 for ; Thu, 21 May 2020 10:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g1kK94+t8MiBOEilxQ4cZGsYLR57S7POrHjiDmmvcOs=; b=VFksscrMjkyYYGg95f0Xgmx9w5MhyInORmMzZ5p5U2IMJA/xGpa1wObzfwe6P8D4nv yZD3GrKd9KM6IesXhuIQ2LyGMGcEMmHLZZ6LZXZAiRSbztoBE0byVsZsRGzv6SOrBKFw QjSfjWH0NNUycM/BAyKpXCNoqBVp5bk2Za3zU= 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=g1kK94+t8MiBOEilxQ4cZGsYLR57S7POrHjiDmmvcOs=; b=XUYWO63+kSACfzrZsSngGMPCGq49jbERG9mJaGSIL/0eM/8flJ3zKqEFg841h/kUKg lKVc8jcDZxqgU6CtckQn7p4/cDxIebZ6SjdRfxs3/YsLLMC4h9FEss7Hq26dQ+cfZOHO WBCR2uOpl/Dfrj3hN8/lQT81xja1Vr8HxsAsKTVYG9uELwpr+LagMRRTV+akIfvqfUzf lIrAcc61A1o/mHIhPRXe2AtpJa8u4wPqTUkntC+ChKKK0ettcTvzG6DHFbehpriqD9a7 oZPxF/+/u4ErdaZ/co0yVB0xjAambcdxbMsamGxUnPc7c3squtwYD4ZgLdSpn8njMFAh QIag== X-Gm-Message-State: AOAM531AK2atUj5RJEmaygCgTZ+/0+riR/MjzqfvGJnSCs942CG91+dW AHMVMcvFECRhyjRbT877uyIdEe8LpXphjELU/KB5M5UX/9E= X-Google-Smtp-Source: ABdhPJwAmwEqdArt/Hm5nCYIdaUFxZtACuvCWK0vepedV4kZubHU/7BMFl/rRbWcYEE/85b+y1+NtSUxNOUT99EFhv4= X-Received: by 2002:ac8:2679:: with SMTP id v54mr11570015qtv.130.1590083121082; Thu, 21 May 2020 10:45:21 -0700 (PDT) MIME-Version: 1.0 References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> <2963.1589473899@localhost> <377E8232-0638-419F-8D79-710F42C2B4E3@tzi.org> In-Reply-To: <377E8232-0638-419F-8D79-710F42C2B4E3@tzi.org> From: Jeffrey Yasskin Date: Thu, 21 May 2020 10:45:07 -0700 Message-ID: To: Carsten Bormann Cc: Michael Richardson , cbor@ietf.org Content-Type: multipart/alternative; boundary="00000000000098e05e05a62c139f" Archived-At: Subject: Re: [Cbor] my (WGLC re-)views on error processing in RFC7049bis and future-proofing 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, 21 May 2020 17:45:24 -0000 --00000000000098e05e05a62c139f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 20, 2020 at 7:50 AM Carsten Bormann wrote: > > "A string containing an invalid UTF-8 sequence is well- > > formed but invalid." > > > > I think that this might need clarification. > > Not for a pedantic like me who has already memorized the content of > Section 1.2=E2=80=A6 Quick note that I've added a citation to section 1.2 in https://github.com/cbor-wg/CBORbis/pull/191, which Paul rapidly merged. :) Jeffrey --00000000000098e05e05a62c139f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 20, 2020 at 7:50 AM Carsten B= ormann <cabo@tzi.org> wrote:
>=C2=A0 "A string containing an invalid UTF-8 sequence is well-
>=C2=A0 =C2=A0formed but invalid."
>
> I think that this might need clarification.

Not for a pedantic like me who has already memorized the content of Section= 1.2=E2=80=A6

Quick note that I've adde= d a citation to section 1.2 in=C2=A0https://github.com/cbor-wg/CBORbis/pull/191,=C2=A0whic= h Paul rapidly merged. :)

Jeffrey
--00000000000098e05e05a62c139f-- From nobody Thu May 21 13:24: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 8EA8C3A07C6 for ; Thu, 21 May 2020 13:24:48 -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 w4FajWXDS__1 for ; Thu, 21 May 2020 13:24: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 DA4FF3A0898 for ; Thu, 21 May 2020 13:24:45 -0700 (PDT) Received: from [192.168.217.119] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (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 49Sh1P6536zyT3; Thu, 21 May 2020 22:24:41 +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, 21 May 2020 22:24:41 +0200 Cc: Michael Richardson , cbor@ietf.org X-Mao-Original-Outgoing-Id: 611785481.099923-3ece34072e985bcdf562b7c2f87d2cbc Content-Transfer-Encoding: quoted-printable Message-Id: References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> <2963.1589473899@localhost> <377E8232-0638-419F-8D79-710F42C2B4E3@tzi.org> To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] my (WGLC re-)views on error processing in RFC7049bis and future-proofing 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, 21 May 2020 20:24:49 -0000 On 2020-05-21, at 19:45, Jeffrey Yasskin wrote: >=20 > Quick note that I've added a citation to section 1.2 in = https://github.com/cbor-wg/CBORbis/pull/191, which Paul rapidly merged. = :) Thank you! Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 21 16: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 6944C3A0C92 for ; Thu, 21 May 2020 16:10:53 -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 5gq76MA1KYNt for ; Thu, 21 May 2020 16:10:48 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09BC3A0C50 for ; Thu, 21 May 2020 16:10:47 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2607:f0b0:f:40:c840:256e:f31:f2f9]) by relay.sandelman.ca (Postfix) with ESMTPS id 16C191F449; Thu, 21 May 2020 23:10:45 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 15AC21A329C; Thu, 21 May 2020 19:10:44 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: cbor@ietf.org In-reply-to: <377E8232-0638-419F-8D79-710F42C2B4E3@tzi.org> References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> <2963.1589473899@localhost> <377E8232-0638-419F-8D79-710F42C2B4E3@tzi.org> Comments: In-reply-to Carsten Bormann message dated "Wed, 20 May 2020 16:49:49 +0200." X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Thu, 21 May 2020 19:10:44 -0400 Message-ID: <4347.1590102644@dooku> Archived-At: Subject: Re: [Cbor] my (WGLC re-)views on error processing in RFC7049bis and future-proofing 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, 21 May 2020 23:10:54 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >> This document is a revised edition of [RFC7049], with editorial >> improvements, added detail, and fixed errata. In clarifying some >> interpretations of [RFC7049] it may in some cases create situations >> where an existing parser may no longer comply to this specification. >> While this revision formally obsoletes RFC 7049, it does not obsolete >> any valid encoders, and thus keeps full compatibility with the >> interchange format from RFC 7049. It does not create a new version = of >> the format. > I don=E2=80=99t think we want to go to that level of detail right the= re in the > intro. I=E2=80=99m also not sure 7049 was formally defining =E2=80= =9Ccompliance=E2=80=9D of > decoders. > I think we could move some of this thinking into the =E2=80=9Cchanges= from > 7049=E2=80=9D appendix, the fate of which we haven=E2=80=99t really d= ecided as a WG > yet. okay, I can go for that. >> This seems to have something to do with tags. > Yes. Implementation of specific tags was always optional with CBOR; > there is no single =E2=80=9Crequired tag=E2=80=9D. yes, okay, but some Protocols might require them. So maybe we need some additional BCP14-like terms. Hmm. >> which might mean ignoring unknown tags (if that's what they did >> before), passing the data up using whatever native interpretation >> there is, until they are configured otherwise. > Generic decoders that want to evolve to be usable with applications > that need tag support will need to develop a transition strategy. > Isn=E2=80=99t that obvious to any library developer? Yes, but sometimes application developers need a hammer. This happens far less often in open source situations, but in other situations, the hammer is sometimes necessary to make a supplier spend the effort. >> In general, I think that the details in this introductionary encoding >> section are too detailed, particularly for 31. I think that detail >> belongs later on. I got no value (I retained nothing) from having th= at >> level of detail there. > I think there was another proposal to move around elements of Section > 3. Sometimes it is necessary to include some detail in an overview f= or > completeness; we can=E2=80=99t really pretend ai=3D31 does not exist = for a few > sections and then do a surprise reveal, can we? We can just say less in section 3. ai=3D31 "Stop-Code, ses section FOO" That's okay. It's some of the other detail that seems to accumulated there which distracted me. >> I wonder if section 3.1, under major type 0 should give clarify that >> "0" is encoded as 0b000_00000. (That is no negative 0) > Is this really more about major type 1, and the value -1? maybe. >> I guess that RFC8742 include sequences of 7049bis CBOR sequences. I >> wonder if Updates 8742 is appropriate. > You still lost me here. What are 7049 CBOR sequences? > Oh. We are talking about =E2=80=9CData Streams=E2=80=9D. This proba= bly should mention > RFC 8742 (which only happens in 3.1)! Yes. >>> If the break stop code appears after a key in a map, in place of th= at >>> key's value, the map is not well-formed. >> >> This does mean that the entire map is not well-formed, or just the >> key/value pair where this occurs? I take the first meaning, but I >> want to be sure. > It says that the map is not well-formed, but of course the whole data > item is dubious as it is not clear whether the map has ended or not. > So, again, give up. Should be clear in Appendix C. I am concerned that different kinds of parsers wind up resulting in an error at a different point, possibly causing some content to be examined, while other content is not. This is akin to the duplicate key challenge. >> Could future Simple Values (such as 0..19) can, have complex structu= re >> the way that values 24->27 do? > No, the general syntax of heads does apply to the unallocated code > points as well. I'd like to say this. >> Or to put it another way, can a decoder depend upon unassigned simple >> values having the one-or-two byte structure presented and be able to >> skip unknown values? > Yes. >> I guess I will read onwards to find out... Got it. >> >> BTW: Tag 25 and 29 are called out after Table 5, but are not listed >> *in* table 5. That whole paragraph could use some more periods, and >> maybe a blank line. I'm still loss as to why is >> better than . >> >> Why can't we use decimal fractions, or bigfloats for time? > That may have been a mistake (which is one reason we have tag 1001 > now). The WG has generally taken a dim view on extending the domain > (allowable syntax for tag content) for a tag, so we can=E2=80=99t =E2= =80=9Cfix=E2=80=9D that =E2=80=94 > note that for the date tag, we have taken the decision not to reuse o= ne > tag for two different tag content syntaxes either. okay. >> I think that words "bytewise lexicographic order" used in 4.2.1 may >> not survive translations in a meaningful way. > Deepl turns this into "byteweise lexikographische Ordnung=E2=80=9D, n= a ja. The > next alternative "byteweise lexikographische Reihenfolge=E2=80=9D is = very > close. No idea about "ordre lexicographique par octet=E2=80=9D. Or = "=D0=BF=D0=BE=D1=88=D0=B0=D0=B3=D0=BE=D0=B2=D1=8B=D0=B9 > =D0=BB=D0=B5=D0=BA=D1=81=D0=B8=D0=BA=D0=BE=D0=B3=D1=80=D0=B0=D1=84=D0= =B8=D1=87=D0=B5=D1=81=D0=BA=D0=B8=D0=B9 =D0=BF=D0=BE=D1=80=D1=8F=D0=B4=D0= =BE=D0=BA=E2=80=9D, for that matter. But "=E5=AD=97=E8=8A=82=E8=AF=8D=E5= =BA=8F=E2=80=9D looks > really good :-) (and is completely wrong). I'm less concerned about translations of the draft by mechanical, but translations by human who didn't understand the original mathematical meaning. Whether that person is a translator, or a non-native english/germanic/latin speaker writing code. I'm just asking if you could use a less technical term. HIT ME ON THE HEAD. >> I think that the the Introduction should have a section 1.3 that >> addresses the concept of "Protocols" on top of CBOR, referencing >> section 5. I think that 4.2.2 should forward reference to 5, or may= be >> sections 4 and 5 I suggest "protocol" be capitalized consistently as >> Protocol when it is used in this way. >> >> I don't find that section 5.2 fits into section 5. I think we alrea= dy >> covered this concept. > This section reaffirms to concept developed above. It also discusses > the application interface =E2=80=94 have we really covered that here? I don't understand your comments here. >> "0x62c0ae" does not contain valid UTF-8 and so is not a valid CBOR >> item. ...... Generic encoders and decoders are expected to forward >> simple values and tags even if their specific codepoints are not >> registered at the time the encoder/decoder is written (Section 5.4). >> >> Generic decoders provide ways to present well-formed CBOR values, bo= th >> valid and invalid, to an application. The diagnostic notation >> (Section 8) may be used to present well-formed CBOR values to humans. >> >> I don't personally know enough UTF-8 to know why the above is invalid >> UTF-8. > Because it uses a long form where there is a shorter form - UTF-8 uses > deterministic (shortest) encoding. Can you please say that in the document. } For instance, "0x62c0ae" uses a long form where there is a shorter form, = and } UTF-8 mandates deterministic (shortest) encoding, therefore, this not a v= alid } CBOR item. >> Maybe saying that it's not because c0ae is an unsigned code point by >> because... > This is a mild reminder that you have to read up on UTF-8 to understa= nd > CBOR. Yes, but many will just plop the text into a UTF-8 parser and hope. We can't all be experts at everything :-) >> Having read through section 5, I believe even more than two weeks ag= o, >> that the "65535" tag should go into RFC7049bis, not a new document. > We didn=E2=80=99t want new stuff in 7049bis, so this is now in > draft-bormann-cbor-notable-tags with a mention here; RFC7049bis > combines with its registries to give the full semantics of CBOR, so > this is OK. I feel that this is a reasonable thing to address short-cuming in existng P= S, but I won't fall on this sword. > Gr=C3=BC=C3=9Fe, Carsten Thank you for all the work. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl7HCnMACgkQlUzhVv38 QpDKkAf+OGi0bAl2PgJSc8lkphpJTAtUkiPjc6QJlPogkF3SOzmZ9cQ6nf5sehiN akRVj45Lj+yGa5QQJj6SJkLk/UtkcFcbcOR8/lJz7lx136xAwMilknzFA2VTKEQk l0eSPQ69VFygdq6p2v70nVW0w6YlzE0NA36479IC4aQpo6qXzpRzdlK18NKH5xZ0 xV0sCEIOb1kSrE4B9Es1CMR7Hy5yBrA0wZq6X8WgzcTqYzeQLCHag6nUK6MsVlIW CCykKSIhy8QiF01MqxX9+faV5yexuh6OrfshH/Z3sEup68QF5zBYe9MtWIczD7O5 QNGg+2eVpPCLmGDmZrZmOGsvS7p8fA== =E3X/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 22 12:22: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 62A2B3A00B2 for ; Fri, 22 May 2020 12:22: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, HTML_MESSAGE=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 jpREezTZJ1iS for ; Fri, 22 May 2020 12:22:32 -0700 (PDT) Received: from p3plsmtpa12-01.prod.phx3.secureserver.net (p3plsmtpa12-01.prod.phx3.secureserver.net [68.178.252.230]) (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 53BDD3A005B for ; Fri, 22 May 2020 12:22:32 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id cDFWjEzf3dUjIcDFXj4ZMT; Fri, 22 May 2020 12:22:31 -0700 X-CMAE-Analysis: v=2.3 cv=V4wDLtvi c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=l70xHGcnAAAA:8 a=_O5UbtG09yanlUfFYO0A:9 a=QEXdDO2ut3YA:10 a=aCfU-6BJkAhjHx_qEzUA:9 a=ltQafFx8tGN9ivf1:21 a=_W_S_7VecoQA:10 a=JtN_ecm89k2WOvw5-HMO:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <5DBD6E24-BD31-493A-84DD-852D8985DE93@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_584850CF-E0DE-414E-B355-19A8F5AA2690" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 22 May 2020 12:22:30 -0700 In-Reply-To: <4347.1590102644@dooku> Cc: Carsten Bormann , cbor@ietf.org To: Michael Richardson References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> <2963.1589473899@localhost> <377E8232-0638-419F-8D79-710F42C2B4E3@tzi.org> <4347.1590102644@dooku> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfNsLXEG6T8IpKAL794tbp9l2H4tGoMe31lKs65xdG5NxOiBZ72ODQu+S5fLXMuLt+KhEGrwKsd2brQmw/kXEDXN6ooKO56QAaNd0dtbjvuGAdHtemPqY oGEpPWcVJPj3MGRXRy8Gtn66MV0WPZKyVGv6xDEXRIYIdsFkSzEBpZMLSqp3h5pFoaa0VAJ67+Zezws0QDPysDfxvuufvJvXWiqvhJUu1TkeZRnjzs7/Czyd Archived-At: Subject: Re: [Cbor] my (WGLC re-)views on error processing in RFC7049bis and future-proofing 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, 22 May 2020 19:22:35 -0000 --Apple-Mail=_584850CF-E0DE-414E-B355-19A8F5AA2690 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 21, 2020, at 4:10 PM, Michael Richardson = wrote: >=20 >>> Why can't we use decimal fractions, or bigfloats for time? >=20 >> That may have been a mistake (which is one reason we have tag 1001 >> now). The WG has generally taken a dim view on extending the domain >> (allowable syntax for tag content) for a tag, so we can=E2=80=99t = =E2=80=9Cfix=E2=80=9D that =E2=80=94 >> note that for the date tag, we have taken the decision not to reuse = one >> tag for two different tag content syntaxes either. >=20 > okay. I think the main time type should have solely been an integer. You can = express +/- 500 billion years to 1 second accuracy with 64 bits. The = earth is only 4.5 billions years old so it is even good enough for most = science. It=E2=80=99s only really odd scientific use cases that would = need anything else as far as I can imagine. I would disallow float dates in the main time type. Floats only enable = microsecond accuracy. They give no greater range that is of much use. = Also, they have less precision and the precision varies by year. This is about code size and HW support. You don=E2=80=99t want to have = to implement decoding of a variety of time formats for 0.0001% of the = use cases. It is also a pain for every protocol to say =E2=80=9Cuse the = time tag, but disallow floats=E2=80=9D. The CDDL type for time has this = problem. Maybe should probably have a new CDDL type =E2=80=9Csimple_time=E2= =80=9D or that is tag 1, but disallows float. Then I=E2=80=99d create a second Swiss army knife time format that can = use floats, bignums, decimal fractions and so on. I=E2=80=99ve been = playing with implementations of conversions of these types and so far it = takes 500-1000 bytes of code to convert all of them in some form or = other. I=E2=80=99m kind of in favor of defining yet another time tag that just = allows integers, but the current epoch time tag has been around for a = long time now so it seems ugly to do so. In reality, probably everyone will just implement 64-bit only time as = sort of an unstated best practice and it will be OK. LL --Apple-Mail=_584850CF-E0DE-414E-B355-19A8F5AA2690 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 21, 2020, at 4:10 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Why can't we use decimal = fractions, or bigfloats for time?

That may have been a mistake (which = is one reason we have tag 1001
now).  The WG has = generally taken a dim view on extending the domain
(allowable syntax for tag content) for a tag, so we can=E2=80=99= t =E2=80=9Cfix=E2=80=9D that =E2=80=94
note that for the = date tag, we have taken the decision not to reuse one
tag = for two different tag content syntaxes either.

okay.

I think the main time type should have solely been an = integer. You can express +/- 500 billion years to 1 second accuracy with = 64 bits. The earth is only 4.5 billions years old so it is even good = enough for most science. It=E2=80=99s only really odd scientific use = cases that would need anything else as far as I can imagine.

I would disallow float = dates in the main time type. Floats only enable microsecond accuracy. = They give no greater range that is of much use. Also, they have less = precision and the precision varies by year.

This is about code size and HW support. = You don=E2=80=99t want to have to implement decoding of a variety of = time formats for 0.0001% of the use cases. It is also a pain for every = protocol to say =E2=80=9Cuse the time tag, but disallow floats=E2=80=9D. = The CDDL type for time has this problem. Maybe should probably have a = new CDDL type =E2=80=9Csimple_time=E2=80=9D or that is tag 1, but = disallows float.

Then I=E2=80=99d create a second Swiss army knife time format = that can use floats, bignums, decimal fractions and so on. I=E2=80=99ve = been playing with implementations of conversions of these types and so = far it takes 500-1000 bytes of code to convert all of them in some form = or other.

I=E2=80= =99m kind of in favor of defining yet another time tag that just allows = integers, but the current epoch time tag has been around for a long time = now so it seems ugly to do so.

In reality, probably = everyone will just implement 64-bit only time as sort of an unstated = best practice and it will be OK.

LL

= --Apple-Mail=_584850CF-E0DE-414E-B355-19A8F5AA2690-- From nobody Fri May 22 18:31: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 12A9C3A0D57 for ; Fri, 22 May 2020 18:31: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 NbOMdn5Yr7he for ; Fri, 22 May 2020 18:31: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 9D81D3A0D56 for ; Fri, 22 May 2020 18:31:48 -0700 (PDT) Received: from [192.168.217.119] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (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 49TQnD2DFczyNj; Sat, 23 May 2020 03:31: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: <5DBD6E24-BD31-493A-84DD-852D8985DE93@island-resort.com> Date: Sat, 23 May 2020 03:31:43 +0200 Cc: Michael Richardson , cbor@ietf.org X-Mao-Original-Outgoing-Id: 611890303.851043-fbac178c2848a475c1bf144e919a14d0 Content-Transfer-Encoding: quoted-printable Message-Id: <970E5584-CA07-4004-9993-1DFAEDAEA576@tzi.org> References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> <2963.1589473899@localhost> <377E8232-0638-419F-8D79-710F42C2B4E3@tzi.org> <4347.1590102644@dooku> <5DBD6E24-BD31-493A-84DD-852D8985DE93@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] my (WGLC re-)views on error processing in RFC7049bis and future-proofing 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, 23 May 2020 01:31:55 -0000 > On 2020-05-22, at 21:22, Laurence Lundblade = wrote: >=20 >> On May 21, 2020, at 4:10 PM, Michael Richardson = wrote: >>=20 >>>> Why can't we use decimal fractions, or bigfloats for time? >>=20 >>> That may have been a mistake (which is one reason we have tag 1001 >>> now). The WG has generally taken a dim view on extending the domain >>> (allowable syntax for tag content) for a tag, so we can=E2=80=99t = =E2=80=9Cfix=E2=80=9D that =E2=80=94 >>> note that for the date tag, we have taken the decision not to reuse = one >>> tag for two different tag content syntaxes either. >>=20 >> okay. >=20 > I think the main time type should have solely been an integer. With hindsight, I almost agree. > You can express +/- 500 billion years to 1 second accuracy with 64 = bits. The earth is only 4.5 billions years old so it is even good enough = for most science. It=E2=80=99s only really odd scientific use cases that = would need anything else as far as I can imagine. There is range (of which an integer has plenty for seconds-based time), = and there is precision. Unfortunately, precision isn=E2=80=99t that great with floating point(*) = either, which led to the alternative time tag 1001. > I would disallow float dates in the main time type. Floats only enable = microsecond accuracy. They give no greater range that is of much use. = Also, they have less precision and the precision varies by year. Your CBOR-based protocol is welcome to do that. > This is about code size and HW support. You don=E2=80=99t want to have = to implement decoding of a variety of time formats for 0.0001% of the = use cases. It is also a pain for every protocol to say =E2=80=9Cuse the = time tag, but disallow floats=E2=80=9D. The CDDL type for time has this = problem. Maybe should probably have a new CDDL type =E2=80=9Csimple_time=E2= =80=9D or that is tag 1, but disallows float. Your CDDL definition of the data interchanged by your protocol could = usefully say: itime =3D #6.1(int) For many applications, I=E2=80=99d actually go so far as uitime =3D #6.1(uint) (This is most useful for all protocols that describe point in time that = lie after the creation of the protocols, such as claims issuance dates = etc.) I think that the notable tags document is a good place to make this = discussion accessible as well as CDDL fragments like the above that can = be copied (so people don=E2=80=99t invent thousands of names for the = same thing). > Then I=E2=80=99d create a second Swiss army knife time format that can = use floats, bignums, decimal fractions and so on. I=E2=80=99ve been = playing with implementations of conversions of these types and so far it = takes 500-1000 bytes of code to convert all of them in some form or = other. That=E2=80=99s tag 1001. But, again, your protocol can restrict that = tag to the times you actually need. > I=E2=80=99m kind of in favor of defining yet another time tag that = just allows integers, but the current epoch time tag has been around for = a long time now so it seems ugly to do so. And it is not needed: The tag content is plainly visible, so it is easy = to find out if someone sent you a floating point time (which you may not = want) or an integer time; as seen above, it is also easy to write the = CDDL for restricting this to what you want. > In reality, probably everyone will just implement 64-bit only time as = sort of an unstated best practice and it will be OK. Hah. Since (unsigned) 32-bit time takes us to 2106-02-07 06:28:15 UTC, = I=E2=80=99m sure lots of people will go for that in their constrained = implementations. Make sure you tell your grandkids not to fly (or = otherwise rely on product safety) on that date and time :-) But note that 32-bit seconds also are already not useful any more for = taking out 99-year leases on your neighbor=E2=80=99s garage. TL;DR: It probably wasn=E2=80=99t too bright to define tag 1 as = #6.1(int/float) in RFC 7049, but that=E2=80=99s where we are, and we = know how to mitigate any ugliness. Gr=C3=BC=C3=9Fe, Carsten (Insert discussion of epochs, eras, GPS 1024 week rollovers, and = everything else.) (*) We could have embraced 128-bit numbers (including floating point) = earlier. Seemed preposterous for CBOR in 2013. But they have entered = the picture in RFC 8746 (tags 83 and 87), and there are even CPU = architectures for 128-bit processors now. From nobody Mon May 25 01:58: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 0F5573A0811; Mon, 25 May 2020 01:58:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: francesca.palombini@ericsson.com, cbor@ietf.org, cbor-chairs@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159039709196.21285.18180561497923933289@ietfa.amsl.com> Date: Mon, 25 May 2020 01:58:13 -0700 Archived-At: Subject: [Cbor] cbor - New Meeting Session Request 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: Mon, 25 May 2020 08:58:22 -0000 A new meeting session request has just been submitted by Francesca Palombini, a Chair of the cbor working group. --------------------------------------------------------- Working Group Name: Concise Binary Object Representation Maintenance and Extensions Area Name: Applications and Real-Time Area Session Requester: Francesca Palombini Number of Sessions: 1 Length of Session(s): 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 Tue May 26 14:04: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 90F143A07C7 for ; Tue, 26 May 2020 14:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJlpvPe20iEp for ; Tue, 26 May 2020 14:04:13 -0700 (PDT) Received: from p3plsmtpa06-06.prod.phx3.secureserver.net (p3plsmtpa06-06.prod.phx3.secureserver.net [173.201.192.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A81BA3A07BC for ; Tue, 26 May 2020 14:04:13 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id dgk8jK70T4ZBJdgk8jMQVU; Tue, 26 May 2020 14:04:13 -0700 X-CMAE-Analysis: v=2.3 cv=cICeTWWN c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=l70xHGcnAAAA:8 a=rYox9fP2dRPCqH_q7FQA:9 a=QEXdDO2ut3YA:10 a=VQsTwkKI0r2B1ew5bfkA:9 a=57RQabm3FGYuLpd2:21 a=_W_S_7VecoQA:10 a=JtN_ecm89k2WOvw5-HMO:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <589BF33E-9A41-400B-A91B-F45F85062269@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FC28DFBA-C145-4FC0-8BA3-C19227924983" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 26 May 2020 14:04:11 -0700 In-Reply-To: <26665.1589593222@localhost> Cc: Carsten Bormann , cbor@ietf.org To: Michael Richardson References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> <2963.1589473899@localhost> <26665.1589593222@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfHRs2Nd77VU+kMm6E+qBhGLLXt69XYgmgW37XNPh++jU+VpGhkTfljmjsK/5+YQusOy9Yz8JtRh9i11eHSA+tt5uEQsZiMP545YHdAS7qthDILWmT36b U7ZSUks3PvDWEN62uUM5HPulJ/XWl05wJg7SVncD3c4aXc0l9VvgtWBDW9c5z9UShwvd0yTQ656Wb4tzZzfBX/FR/JV3UpwE0hx9XyVm+BOlpaiOsDCfgBTA Archived-At: Subject: [Cbor] tag 24 and 55799 (was Re: my (WGLC re-)views on error processing in RFC7049bis and future-proofing) 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, 26 May 2020 21:04:16 -0000 --Apple-Mail=_FC28DFBA-C145-4FC0-8BA3-C19227924983 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 15, 2020, at 6:40 PM, Michael Richardson = wrote: >=20 >>> I note that AFAIK, we do not use tag#24 (Encoded CBOR data item) for >>> the signed object, in COSE. Should we? What's the difference = between >>> #24 and #55799. >=20 >> 55799 is a tag that can have any CBOR data item as tag content 24 is = a >> tag that can only be on byte strings. The byte string then *encodes* >> another CBOR data item. (The main use here is to keep the decoder = from >> decoding, to provide easy skip-ability or because we need exact bytes >> as in COSE.) As often with tags, there is no need for tag 24 on a = byte >> string when it is clear from context that the byte string contains >> encoded CBOR; this is the case in COSE. >=20 > Understood. My answer on the difference is that you use 55799 when the surrounding = data / file / protocol is not CBOR and 24 when it is CBOR. 55799 is = intended to work as a magic number, 24 is not because it is not unique = enough. =46rom a decoder point of view, they should be handled exactly the same = and should be able to occur legally in exactly the same contexts. Right? = Probably this should be stated explicitly. Right now there is no linkage = between them in the text. In addition to skip-ability it seems they could be used when some data = item might be JSON or might be CBOR or might be something else and you = want to explicit say what it is. Should there be a JSON tag? This is kind of twisted, but seems legal. Encoding:=20 - start with an RFC 3339 date string - base 64 encode it and tag it as so with tag 34 - tag it with tag 24 (55799 ) or to say it is CBOR - tag it with tag 0 to say it is a date string - tag it with 22 to say it should be b64=E2=80=99d if re-encoded = later Decoding: - remove the base 64 encoding because of the tag 34 - feed it back to the CBOR encoder because of tag 24 - interpret it as an RFC 3339 date because of tag 0 Base64 encoding / decoding is not that much code or that difficult, so a = generic decoder might actually do this. LL --Apple-Mail=_FC28DFBA-C145-4FC0-8BA3-C19227924983 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = May 15, 2020, at 6:40 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

I note that AFAIK, we do = not use tag#24 (Encoded CBOR data item) for
the signed = object, in COSE.  Should we?  What's the difference between
#24 and #55799.

55799 = is a tag that can have any CBOR data item as tag content 24 is a
tag that can only be on byte strings.  The byte string = then *encodes*
another CBOR data item.  (The main use = here is to keep the decoder from
decoding, to provide easy = skip-ability or because we need exact bytes
as in COSE.) =  As often with tags, there is no need for tag 24 on a byte
string when it is clear from context that the byte string = contains
encoded CBOR; this is the case in COSE.

Understood.

My answer on the difference is that you use = 55799 when the surrounding data / file / protocol is not CBOR and 24 = when it is CBOR. 55799 is intended to work as a magic number, 24 is not = because it is not unique enough.

=46rom a decoder point of view, they = should be handled exactly the same and should be able to occur legally = in exactly the same contexts. Right? Probably this should be stated = explicitly. Right now there is no linkage between them in the = text.

In = addition to skip-ability it seems they could be used when some data item = might be JSON or might be CBOR or might be something else and you want = to explicit say what it is. Should there be a JSON tag?

This is kind of twisted, = but seems legal.
  Encoding: 
    - start with an RFC 3339 date string
    - base 64 encode it and tag it as so with tag = 34
    - tag it with tag 24 (55799 ) or = to say it is CBOR
    - tag it with tag 0 = to say it is a date string
    - tag it = with 22 to say it should be b64=E2=80=99d if re-encoded later
 Decoding:
    - remove = the base 64 encoding because of the tag 34
  =   - feed it back to the CBOR encoder because of tag 24
    - interpret it as an RFC 3339 date because of = tag 0

Base64 = encoding / decoding is not that much code or that difficult, so a = generic decoder might actually do this.

LL



= --Apple-Mail=_FC28DFBA-C145-4FC0-8BA3-C19227924983-- From nobody Tue May 26 14:43: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 8E1AD3A09A2 for ; Tue, 26 May 2020 14:43:32 -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 uWQ6AaxA5AYv for ; Tue, 26 May 2020 14:43:28 -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 6318C3A0925 for ; Tue, 26 May 2020 14:43:28 -0700 (PDT) Received: from [172.16.42.112] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (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 49WnWx4p6SzytX; Tue, 26 May 2020 23:43:25 +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: <589BF33E-9A41-400B-A91B-F45F85062269@island-resort.com> Date: Tue, 26 May 2020 23:43:25 +0200 Cc: Michael Richardson , cbor@ietf.org X-Mao-Original-Outgoing-Id: 612222205.056496-7b279f04393f92516aa7ea2a4c3ee4c6 Content-Transfer-Encoding: quoted-printable Message-Id: References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> <2963.1589473899@localhost> <26665.1589593222@localhost> <589BF33E-9A41-400B-A91B-F45F85062269@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] tag 24 and 55799 (was Re: my (WGLC re-)views on error processing in RFC7049bis and future-proofing) 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, 26 May 2020 21:43:33 -0000 > On 2020-05-26, at 23:04, Laurence Lundblade = wrote: >=20 >=20 >> On May 15, 2020, at 6:40 PM, Michael Richardson = wrote: >>=20 >>>> I note that AFAIK, we do not use tag#24 (Encoded CBOR data item) = for >>>> the signed object, in COSE. Should we? What's the difference = between >>>> #24 and #55799. >>=20 >>> 55799 is a tag that can have any CBOR data item as tag content 24 is = a >>> tag that can only be on byte strings. The byte string then = *encodes* >>> another CBOR data item. (The main use here is to keep the decoder = from >>> decoding, to provide easy skip-ability or because we need exact = bytes >>> as in COSE.) As often with tags, there is no need for tag 24 on a = byte >>> string when it is clear from context that the byte string contains >>> encoded CBOR; this is the case in COSE. >>=20 >> Understood. >=20 > My answer on the difference is that you use 55799 when the surrounding = data / file / protocol is not CBOR and 24 when it is CBOR. 55799 is = intended to work as a magic number, 24 is not because it is not unique = enough. >=20 > =46rom a decoder point of view, they should be handled exactly the = same Actually, no. 55799 has any CBOR data item as tag content and essentially has the = semantics of that CBOR data item. 24 has a byte string as tag content. That byte string is identified by = the tag as encoded CBOR.=20 A byte string with embedded encoded CBOR is a data item, but it is = different from the data item that was encoded and embedded. Decoders = will differ in their tag 24 handling: they might go ahead and decode = that CBOR or just hand the byte string and tag to the application. In = either case, the decoded CBOR is not simply =E2=80=9Cin place=E2=80=9D, = making the tag and the byte string vanish. > and should be able to occur legally in exactly the same contexts. = Right? Probably this should be stated explicitly. Right now there is no = linkage between them in the text. >=20 > In addition to skip-ability it seems they could be used when some data = item might be JSON or might be CBOR or might be something else and you = want to explicit say what it is. Should there be a JSON tag? Very likely. That would probably take a UTF-8 string as tag content. (Tag 262 works for JSON-encoded content like tag 24 does for = CBOR-encoded content, requiring a byte string with that content though.) > This is kind of twisted, but seems legal. > Encoding:=20 > - start with an RFC 3339 date string > - base 64 encode it and tag it as so with tag 34 Why would one want to do that? > - tag it with tag 24 (55799 ) or to say it is CBOR Ignoring the 55799 case, you are missing one encoding step (tag 24 = requires a byte string with encoded CBOR, not a tagged text string). > - tag it with tag 0 to say it is a date string Not allowed. This only takes major type 3, no tags. > - tag it with 22 to say it should be b64=E2=80=99d if re-encoded = later Well, not =E2=80=9Cit=E2=80=9D, but any byte string in the CBOR data = item. So, here it would base-64 encode for JSON conversion the byte string in = tag 24 (the tag 24 itself would presumably be stripped in any JSON = conversion, but I=E2=80=99m already confused =E2=80=94 you can do = =E2=80=9CJSON in JSON=E2=80=9D as well, just not tag it). > Decoding: > - remove the base 64 encoding because of the tag 34 That is inside, so you see it last. > - feed it back to the CBOR encoder because of tag 24 > - interpret it as an RFC 3339 date because of tag 0 Lost track. > Base64 encoding / decoding is not that much code or that difficult, so = a generic decoder might actually do this. I wouldn=E2=80=99t touch that with a ten-foot pole =E2=80=94 it might = convert that pole into base64 without asking me. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 28 11:26: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 626A83A03F3 for ; Thu, 28 May 2020 11:26:52 -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 vb7cOG28Pdcw for ; Thu, 28 May 2020 11:26:50 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 3AA543A00D4 for ; Thu, 28 May 2020 11:26:50 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id k4so9985983uaq.10 for ; Thu, 28 May 2020 11:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0LjBXDc2y6saB2dOa1kk2ugqAdp8K+pp8MXqoXbYYiY=; b=gkQB9tLk+RENttooOvG+mx1qSCy1FjiqFaWv8Yqs3uSRu+Ap22FtrGcqySgrqoXJuj A76lDEE2fL4MVLl//s2KSP2KJ0qtv7cVU/z5ONXxetuO2bucmIY7Mi7sf7qRzDirPyzV w7p/fbXiagVRlVQyVZqUuM2t0lw7GpPDWjjUu4m+NnPjHDFPiN9mqrNp1JQYMGiFkS2h aL/qdv/x9PgCBvmUItR5qtbF0xkLxAUBMR6Hi9u2s5U0NYGWUJ2ibyBKSYATpZrfe/ka zcGw0FYhNU2ibzDhl0zunNOVIZH1tq3Ltzz77H9PvZNfxbFpkugPmHUJAz4oeGppAK6K Pfug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0LjBXDc2y6saB2dOa1kk2ugqAdp8K+pp8MXqoXbYYiY=; b=TIOGylU1Fj9N/NBncz6ew+Hye/f/RlEQW/S4VK7JPgR7tXK+giQWKx8dlZ/XCSN8gL OtPLw3+i0ni9VCk64ur1B0mNyCBqMEp44P3wcLgDG2Bn/wdKAJSO7q4HMyQq/D1D8rmm PlxAyvZ6sTgzWreZsSf4owvJDqv/IbLSYhtp+kfcwnRv4jwfwZtYF8gponAmd7gAdjyN inugPP6RuD3P2O8e5cGsPaIUcY6HufjR/MEDcBBt8TogQUixbkDL5r/9VzMC+PSi1niN knFl9jUQGvGzYweG1YtqB8S7t9xoN86Qs1heY7A20OIqKM0U8GjNOX4u95qjy6MvOK+L bpAQ== X-Gm-Message-State: AOAM532R1jcV5lrEG0746+V3xVnHvYTkzRyuUnzSoT0nfx8KdzmVhIUB a0n0dtEZsCAeJyo/7VqPsQ5Hhh77AK3t7cisDThdViqamZQ= X-Google-Smtp-Source: ABdhPJwZTp6aI8uUBQzAjq8LvYG5Boz5t+phfTox6ouE8gabCAqD3ThbsrLPx9KyzLg9oQMFpbYVwRe3OeMJZlYwX/8= X-Received: by 2002:ab0:2541:: with SMTP id l1mr3214909uan.101.1590690407771; Thu, 28 May 2020 11:26:47 -0700 (PDT) MIME-Version: 1.0 From: Jonathan Beri Date: Thu, 28 May 2020 11:26:11 -0700 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="000000000000b3f2f905a6b9789e" Archived-At: Subject: [Cbor] CBOR subreddit created 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, 28 May 2020 18:26:52 -0000 --000000000000b3f2f905a6b9789e Content-Type: text/plain; charset="UTF-8" https://www.reddit.com/r/CBOR/ FYI, I created a CBOR subreddit for those who use that service. Hope to see you there! P.S. I'm also trying to re-activate https://www.reddit.com/r/CoAP/ -- Jonathan Beri linkedin.com/in/jonathanberi --000000000000b3f2f905a6b9789e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
https://www.red= dit.com/r/CBOR/

FYI, I created a CBOR subreddit for = those who use that service. Hope to see you there!

P.S. I'm also trying to re-activate=C2=A0https://www.reddit.com/r/CoAP/

=
--
--000000000000b3f2f905a6b9789e-- From nobody Fri May 29 12:51: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 9F38B3A1028 for ; Fri, 29 May 2020 12:51: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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHn-vLKhWVxD for ; Fri, 29 May 2020 12:51:44 -0700 (PDT) Received: from p3plsmtpa12-03.prod.phx3.secureserver.net (p3plsmtpa12-03.prod.phx3.secureserver.net [68.178.252.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E3E3A1027 for ; Fri, 29 May 2020 12:51:43 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id el2cjUKdDLJbhel2djwE5c; Fri, 29 May 2020 12:51:43 -0700 X-CMAE-Analysis: v=2.3 cv=GfJpYjfL c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=gKmFwSsBAAAA:8 a=K6EGIJCdAAAA:8 a=l70xHGcnAAAA:8 a=48vgC7mUAAAA:8 a=oGbIuagOAAAA:20 a=K66lgTXJroBqEgRV2mMA:9 a=bg0PuE9aELsMXmur:21 a=uHyis1-MEgXJ5PKD:21 a=QEXdDO2ut3YA:10 a=9LDti0Gtzx2_Mf1CQ7QA:9 a=79FV-ZAur8EPG3bL:21 a=5dHfOENl6CG81EvN:21 a=B-n0CDPZXYMxRdyI:21 a=_W_S_7VecoQA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=JtN_ecm89k2WOvw5-HMO:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <674CEEEB-4C75-4E8D-A4F1-13058507D558@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C5028828-4E63-44F9-9278-2506035C9D87" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 29 May 2020 12:51:41 -0700 In-Reply-To: Cc: Michael Richardson , cbor@ietf.org To: Carsten Bormann References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> <2963.1589473899@localhost> <26665.1589593222@localhost> <589BF33E-9A41-400B-A91B-F45F85062269@island-resort.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfOZAaFoFK04uBjZbBDJgkFxW8Feh6RAlp+HTp7zdZ83clWLlWBn72YD81BPjUqc5bweXhio42BtZYTg4l9QmZf9L4aK+xpY5/h5oFK1AqlPzhdompWTB i1kWQ2WoDwkK74JaOBv7lyQTFs6ZXJKzmGTLlR2KBcCwMVHMeLZdPzNGJ4aybQexpPZFhky+3wGgMcuL6EbO2K8aP7sgveMdwicEnGln5+80l5ahwQ+DqNYh Archived-At: Subject: Re: [Cbor] tag 24 and 55799 (was Re: my (WGLC re-)views on error processing in RFC7049bis and future-proofing) 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, 29 May 2020 19:51:47 -0000 --Apple-Mail=_C5028828-4E63-44F9-9278-2506035C9D87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Really appreciate the discussion here (despite my incorrect statements). > On May 26, 2020, at 2:43 PM, Carsten Bormann wrote: >=20 >> On 2020-05-26, at 23:04, Laurence Lundblade = wrote: >>=20 >>> On May 15, 2020, at 6:40 PM, Michael Richardson = wrote: >>>=20 >>>>> I note that AFAIK, we do not use tag#24 (Encoded CBOR data item) = for >>>>> the signed object, in COSE. Should we? What's the difference = between >>>>> #24 and #55799. >>>=20 >>>> 55799 is a tag that can have any CBOR data item as tag content 24 = is a >>>> tag that can only be on byte strings. The byte string then = *encodes* >>>> another CBOR data item. (The main use here is to keep the decoder = from >>>> decoding, to provide easy skip-ability or because we need exact = bytes >>>> as in COSE.) As often with tags, there is no need for tag 24 on a = byte >>>> string when it is clear from context that the byte string contains >>>> encoded CBOR; this is the case in COSE. >>>=20 >>> Understood. >>=20 >> My answer on the difference is that you use 55799 when the = surrounding data / file / protocol is not CBOR and 24 when it is CBOR. = 55799 is intended to work as a magic number, 24 is not because it is not = unique enough. >>=20 >> =46rom a decoder point of view, they should be handled exactly the = same >=20 > Actually, no. >=20 > 55799 has any CBOR data item as tag content and essentially has the = semantics of that CBOR data item. This is well-formed and valid CBOR by RFC 7049 & CBORbis: D9 D9F7 # tag(55799) 81 # array(1) D9 D9F7 # tag(55799) D9 D9F7 # tag(55799) 01 # unsigned(1) One is tempted to say that 55799, as a true CBOR no-op, must always be = ignored by generic decoders. However, I think most implementations of = CBOR protocols (e.g., CWT, COSE) today would not tolerate 55799=E2=80=99s = showing up anywhere in the encoded CBOR like in my example above because = ignoring it universally has never been the rule. So you really need to mean it when you put tag 55799 in, the same as any = other tag. Its use needs to be mandated as part of the protocol = specification so implementors know it will be occurring and are ready to = ignore it. Probably it is not even CBOR protocol specifications that says to use = 55799. It is the protocol or file format that carries the encoded CBOR = that would indicate it is in use. Probably 55799 should never occur except at the beginning of some = encoded CBOR. >=20 > 24 has a byte string as tag content. That byte string is identified = by the tag as encoded CBOR.=20 > A byte string with embedded encoded CBOR is a data item, but it is = different from the data item that was encoded and embedded. Decoders = will differ in their tag 24 handling: they might go ahead and decode = that CBOR or just hand the byte string and tag to the application. In = either case, the decoded CBOR is not simply =E2=80=9Cin place=E2=80=9D, = making the tag and the byte string vanish. Yes of course (I should have known that). A generic decoder could have a mode that skips the = tag24-plus-byte-string the same it skips 55799, but it shouldn=E2=80=99t = be the default because protocols usually assign some semantics to it = such as having it hashed or distinguishing it from JSON (protocols = should never assign such semantics to 55799). > This is kind of twisted, but seems legal. >> Encoding:=20 >> - start with an RFC 3339 date string >> - base 64 encode it and tag it as so with tag 34 >=20 > Why would one want to do that? >=20 >> - tag it with tag 24 (55799 ) or to say it is CBOR >=20 > Ignoring the 55799 case, you are missing one encoding step (tag 24 = requires a byte string with encoded CBOR, not a tagged text string). >=20 >> - tag it with tag 0 to say it is a date string >=20 > Not allowed. This only takes major type 3, no tags. >=20 >> - tag it with 22 to say it should be b64=E2=80=99d if re-encoded = later I=E2=80=99m after a deeper understanding of how base64, tag 24 and 55799 = interact or don=E2=80=99t interact. My date string example was poor = (sorry). Base64 is really a content transfer encoding, not a data type. The = original data before base64 encoding is of some type or other. Whom ever = processes it after the base64 encoding is removed has to come to know = what type it is. However, CBOR generally treats base64 as a data type itself and as it is = has no means for indicating the type of the original data before base 64 = encoding was added (by contrast, MIME can describe both type and = transfer encoding). So how can the receiver of base64-tagged data know the type of original = data? It pretty much has to be in the definition of the CBOR protocol. = It might say it is always an X.509 cert or an elf executable or such. It = might say it is looked up by magic number (in which case 55799 might = apply). Lots more options... It is also possible to define tags whose content type can be bstr, = base64, base64-url. If it was really common to base64 encode X.509 certs = (maybe because of JOSE) and a tag was defined to indicate an X.509 cert, = it might be useful to say the X.509 tag content could be bstr, base64 or = base64-url. No suggestion for change and nothing at issue so far, just thinking = through how it fits together. What would really be helpful to me is some detailed example of when = you=E2=80=99d use the base64 tags. Why would you ever use them when CBOR = carries binary data just fine? Why wouldn=E2=80=99t every CBOR-based = protocol just say you always strip the base64 before CBOR encoding? And = why wouldn=E2=80=99t every CBOR bstr always be base64 encoded when = translating to JSON? >=20 > Well, not =E2=80=9Cit=E2=80=9D, but any byte string in the CBOR data = item. > So, here it would base-64 encode for JSON conversion the byte string = in tag 24 (the tag 24 itself would presumably be stripped in any JSON = conversion, but I=E2=80=99m already confused =E2=80=94 you can do = =E2=80=9CJSON in JSON=E2=80=9D as well, just not tag it). >=20 >> Decoding: >> - remove the base 64 encoding because of the tag 34 >=20 > That is inside, so you see it last. >=20 >> - feed it back to the CBOR encoder because of tag 24 >> - interpret it as an RFC 3339 date because of tag 0 >=20 > Lost track. >=20 >> Base64 encoding / decoding is not that much code or that difficult, = so a generic decoder might actually do this. >=20 > I wouldn=E2=80=99t touch that with a ten-foot pole =E2=80=94 it might = convert that pole into base64 without asking me. I wasn=E2=80=99t suggesting any base64 decoding conversion that wasn=E2=80= =99t indicating by a tag in an input stream or any base 64 encoding that = wasn=E2=80=99t requested through an explicit API request. Section = 3.4.5.3 seems to suggest the decoding is a good thing to do: 3.4.5.3 = . = Encoded Text Some text strings hold data that have formats widely used on the Internet, and sometimes those formats can be validated and presented to the application in appropriate form by the decoder. There are tags for some of these formats. As with tag numbers 21 to 23, if these tags are applied to an item other than a text string, they apply to all text string data items it contains. Is there anything wrong with a generic decoder validating and removing = bas64 encoding when encountering tag 34? Also see this issue I = filed against this text and Table 5. Thanks very much. LL --Apple-Mail=_C5028828-4E63-44F9-9278-2506035C9D87 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Really appreciate the discussion here (despite my incorrect = statements).

On May 26, 2020, at 2:43 PM, Carsten Bormann = <cabo@tzi.org> = wrote:

On 2020-05-26, at 23:04, Laurence = Lundblade <lgl@island-resort.com> wrote:

On May 15, 2020, at 6:40 = PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

I note that AFAIK, we do not use tag#24 (Encoded CBOR data = item) for
the signed object, in COSE.  Should we? =  What's the difference between
#24 and #55799.

55799 is a tag that can have any CBOR data item = as tag content 24 is a
tag that can only be on byte = strings.  The byte string then *encodes*
another CBOR = data item.  (The main use here is to keep the decoder from
decoding, to provide easy skip-ability or because we need = exact bytes
as in COSE.)  As often with tags, there = is no need for tag 24 on a byte
string when it is clear = from context that the byte string contains
encoded CBOR; = this is the case in COSE.

Understood.

My = answer on the difference is that you use 55799 when the surrounding data = / file / protocol is not CBOR and 24 when it is CBOR. 55799 is intended = to work as a magic number, 24 is not because it is not unique enough.

=46rom a decoder point of view, they should be = handled exactly the same

Actually, no.

55799 has any CBOR data item as = tag content and essentially has the semantics of that CBOR data = item.

This = is well-formed and valid CBOR by RFC 7049 & CBORbis:

D9 D9F7          # = tag(55799)
  =  81            # = array(1)
  =     D9 D9F7    # tag(55799)
         D9 = D9F7 # tag(55799)
            01   # = unsigned(1)


One is tempted to say = that 55799, as a true CBOR no-op, must always be ignored by generic = decoders. However, I think most implementations of CBOR protocols (e.g., = CWT, COSE) today would not tolerate 55799=E2=80=99s showing up anywhere = in the encoded CBOR like in my example above because ignoring it = universally has never been the rule.

So you really need to mean it when you = put tag 55799 in, the same as any other tag. Its use needs to be = mandated as part of the protocol specification so implementors know it = will be occurring and are ready to ignore it.

Probably it is not even CBOR protocol = specifications that says to use 55799. It is the protocol or file format = that carries the encoded CBOR that would indicate it is in = use.

Probably = 55799 should never occur except at the beginning of some encoded = CBOR.



24 has a byte = string as tag content.  That byte string is identified by the tag = as encoded CBOR. 
A byte string with embedded = encoded CBOR is a data item, but it is different from the data item that = was encoded and embedded. Decoders will differ in their tag 24 handling: = they might go ahead and decode that CBOR or just hand the byte string = and tag to the application.  In either case, the decoded CBOR is = not simply =E2=80=9Cin place=E2=80=9D, making the tag and the byte = string vanish.

Yes of course (I should have known that).

A generic decoder could have a mode that skips the = tag24-plus-byte-string the same it skips 55799, but it shouldn=E2=80=99t = be the default because protocols usually assign some semantics to it = such as having it hashed or distinguishing it from JSON (protocols = should never assign such semantics to 55799).


This is kind of twisted, but seems legal.
 Encoding: 
   - start with an RFC 3339 date string
   - base 64 encode it and tag it as so with = tag 34

Why would one want to do that?

   - tag it with tag = 24 (55799 ) or to say it is CBOR

Ignoring the 55799 case, you are = missing one encoding step (tag 24 requires a byte string with encoded = CBOR, not a tagged text string).

   - tag it with tag 0 = to say it is a date string

Not allowed.  This only = takes major type 3, no tags.

   - tag it with 22 to = say it should be b64=E2=80=99d if re-encoded later

I=E2=80=99m after a deeper understanding of = how base64, tag 24 and 55799 interact or don=E2=80=99t interact. My date = string example was poor (sorry).

Base64 is really a content transfer encoding, not = a data type.  The original data before base64 encoding is of some = type or other. Whom ever processes it after the base64 encoding is = removed has to come to know what type it is.

However, CBOR generally treats base64 as a data = type itself and as it is has no means for indicating the type of the = original data before base 64 encoding was added (by contrast, MIME can = describe both type and transfer encoding).

So how can the receiver of base64-tagged data know = the type of original data? It pretty much has to be in the definition of = the CBOR protocol. It might say it is always an X.509 cert or an elf = executable or such. It might say it is looked up by magic number (in = which case 55799 might apply). Lots more options...

It is also possible to define tags whose content = type can be bstr, base64, base64-url. If it was really common to base64 = encode X.509 certs (maybe because of JOSE) and a tag was defined to = indicate an X.509 cert, it might be useful to say the X.509 tag content = could be bstr, base64 or base64-url.

No suggestion for change and nothing at issue so = far, just thinking through how it fits together.

What would really be helpful to me is some = detailed example of when you=E2=80=99d use the base64 tags. Why would = you ever use them when CBOR carries binary data just fine? Why = wouldn=E2=80=99t every CBOR-based protocol just say you always strip the = base64 before CBOR encoding? And why wouldn=E2=80=99t every CBOR bstr = always be base64 encoded when translating to JSON?



Well, not = =E2=80=9Cit=E2=80=9D, but any byte string in the CBOR data = item.
So, here it = would base-64 encode for JSON conversion the byte string in tag 24 (the = tag 24 itself would presumably be stripped in any JSON conversion, but = I=E2=80=99m already confused =E2=80=94 you can do =E2=80=9CJSON in = JSON=E2=80=9D as well, just not tag it).

Decoding:
   - remove the base 64 encoding because of = the tag 34

That is inside, so you see it last.

   - feed it back to the CBOR encoder because = of tag 24
   - interpret it as an RFC 3339 = date because of tag 0

Lost track.

Base64 encoding / decoding is not = that much code or that difficult, so a generic decoder might actually do = this.

I wouldn=E2=80=99t touch that with a ten-foot pole =E2=80=94 = it might convert that pole into base64 without asking me.

I wasn=E2=80=99= t suggesting any base64 decoding conversion that wasn=E2=80=99t = indicating by a tag in an input stream or any base 64 encoding that = wasn=E2=80=99t requested through an explicit API request. Section = 3.4.5.3 seems to suggest the decoding is a good thing to = do:

3.4.5.3.  =
Encoded Text


   Some text strings hold data that have formats widely used on the
   Internet, and sometimes those formats can be validated =
and presented
   to the application in appropriate form by the decoder.  There are
   tags for some of these formats.  As with tag numbers 21 to 23, if
   these tags are applied to an item other than a text string, they
   apply to all text string data items it contains.

Is there anything = wrong with a generic decoder validating and removing bas64 encoding when = encountering tag 34?

Also see this issue I filed against this text and Table = 5.

Thanks very = much.

LL

= --Apple-Mail=_C5028828-4E63-44F9-9278-2506035C9D87-- From nobody Fri May 29 14:16: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 9B5F73A10A8 for ; Fri, 29 May 2020 14:16: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 FKD2JQIBd9Qg for ; Fri, 29 May 2020 14:16: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 742343A0D80 for ; Fri, 29 May 2020 14:16:49 -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 49Ycnq15tLzysD; Fri, 29 May 2020 23:16: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: <674CEEEB-4C75-4E8D-A4F1-13058507D558@island-resort.com> Date: Fri, 29 May 2020 23:16:46 +0200 Cc: Michael Richardson , cbor@ietf.org X-Mao-Original-Outgoing-Id: 612479806.393633-ab5e7e31359dfad0b54e2cc281bf6f9b Content-Transfer-Encoding: quoted-printable Message-Id: <96520350-30A2-4048-A8C5-967887B341EA@tzi.org> References: <17300.1588779159@localhost> <38BB6FFF-737F-4C11-AD7A-DA3F28A9F570@tzi.org> <13690.1588894939@localhost> <2963.1589473899@localhost> <26665.1589593222@localhost> <589BF33E-9A41-400B-A91B-F45F85062269@island-resort.com> <674CEEEB-4C75-4E8D-A4F1-13058507D558@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] tag 24 and 55799 (was Re: my (WGLC re-)views on error processing in RFC7049bis and future-proofing) 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, 29 May 2020 21:16:54 -0000 On 2020-05-29, at 21:51, Laurence Lundblade = wrote: >=20 > Really appreciate the discussion here (despite my incorrect = statements). >=20 >> On May 26, 2020, at 2:43 PM, Carsten Bormann wrote: >>=20 >>> On 2020-05-26, at 23:04, Laurence Lundblade = wrote: >>>=20 >>>> On May 15, 2020, at 6:40 PM, Michael Richardson = wrote: >>>>=20 >>>>>> I note that AFAIK, we do not use tag#24 (Encoded CBOR data item) = for >>>>>> the signed object, in COSE. Should we? What's the difference = between >>>>>> #24 and #55799. >>>>=20 >>>>> 55799 is a tag that can have any CBOR data item as tag content 24 = is a >>>>> tag that can only be on byte strings. The byte string then = *encodes* >>>>> another CBOR data item. (The main use here is to keep the decoder = from >>>>> decoding, to provide easy skip-ability or because we need exact = bytes >>>>> as in COSE.) As often with tags, there is no need for tag 24 on a = byte >>>>> string when it is clear from context that the byte string contains >>>>> encoded CBOR; this is the case in COSE. >>>>=20 >>>> Understood. >>>=20 >>> My answer on the difference is that you use 55799 when the = surrounding data / file / protocol is not CBOR and 24 when it is CBOR. = 55799 is intended to work as a magic number, 24 is not because it is not = unique enough. >>>=20 >>> =46rom a decoder point of view, they should be handled exactly the = same >>=20 >> Actually, no. >>=20 >> 55799 has any CBOR data item as tag content and essentially has the = semantics of that CBOR data item. >=20 > This is well-formed and valid CBOR by RFC 7049 & CBORbis: >=20 > D9 D9F7 # tag(55799) > 81 # array(1) > D9 D9F7 # tag(55799) > D9 D9F7 # tag(55799) > 01 # unsigned(1) Certainly. It becomes interesting if you add tags that do have = structural requirements: C1 # tag(1) D9 D9F7 # tag(55799) 1A 5ED17501 # unsigned(1590785281) is well-formed, but not valid. It would probably be valid if we had moved from structural to semantic = validity for the tags defined in RFC 7049; we decided not to. > One is tempted to say that 55799, as a true CBOR no-op, must always be = ignored by generic decoders. Tempted, yes, but not supported by 7049 or 7049bis. > However, I think most implementations of CBOR protocols (e.g., CWT, = COSE) today would not tolerate 55799=E2=80=99s showing up anywhere in = the encoded CBOR like in my example above because ignoring it = universally has never been the rule. Right. > So you really need to mean it when you put tag 55799 in, the same as = any other tag. Its use needs to be mandated as part of the protocol = specification so implementors know it will be occurring and are ready to = ignore it. You can use it without a protocol specification as well. But if you have one, that better tell you where 55799 is =E2=80=9Cexpected= =E2=80=9D. > Probably it is not even CBOR protocol specifications that says to use = 55799. It is the protocol or file format that carries the encoded CBOR = that would indicate it is in use. 55799 is a bit like a BOM on UTF-8 (except that the latter is damaged by = BOMs because it loses its ASCII compatibility, but let=E2=80=99s ignore = that for now). Definitely not something you want to use unless there is value in = determining the format from a =E2=80=9Cmagic number=E2=80=9D. > Probably 55799 should never occur except at the beginning of some = encoded CBOR. Probably. >> 24 has a byte string as tag content. That byte string is identified = by the tag as encoded CBOR.=20 >> A byte string with embedded encoded CBOR is a data item, but it is = different from the data item that was encoded and embedded. Decoders = will differ in their tag 24 handling: they might go ahead and decode = that CBOR or just hand the byte string and tag to the application. In = either case, the decoded CBOR is not simply =E2=80=9Cin place=E2=80=9D, = making the tag and the byte string vanish. >=20 > Yes of course (I should have known that). >=20 > A generic decoder could have a mode that skips the = tag24-plus-byte-string the same it skips 55799, The semantics are quite different, though. > but it shouldn=E2=80=99t be the default because protocols usually = assign some semantics to it such as having it hashed or distinguishing = it from JSON (protocols should never assign such semantics to 55799). Yes. >> This is kind of twisted, but seems legal. >>> Encoding:=20 >>> - start with an RFC 3339 date string >>> - base 64 encode it and tag it as so with tag 34 >>=20 >> Why would one want to do that? >>=20 >>> - tag it with tag 24 (55799 ) or to say it is CBOR >>=20 >> Ignoring the 55799 case, you are missing one encoding step (tag 24 = requires a byte string with encoded CBOR, not a tagged text string). >>=20 >>> - tag it with tag 0 to say it is a date string >>=20 >> Not allowed. This only takes major type 3, no tags. >>=20 >>> - tag it with 22 to say it should be b64=E2=80=99d if re-encoded = later >=20 > I=E2=80=99m after a deeper understanding of how base64, tag 24 and = 55799 interact or don=E2=80=99t interact. My date string example was = poor (sorry). >=20 > Base64 is really a content transfer encoding, not a data type. The = original data before base64 encoding is of some type or other. Whom ever = processes it after the base64 encoding is removed has to come to know = what type it is. We don=E2=80=99t have transfer encodings in CBOR, so we can only model = them as types. The tags 32-36 are really =E2=80=9Ctype tags=E2=80=9D =E2=80=94 they = tell you what=E2=80=99s in there but don=E2=80=99t give that a new = meaning. Why anyone would want to send base64-encoded data in CBOR instead of = transferring the byte string (then possibly tagged by 21/22 so it looks = the same again after a JSON conversion) is not discussed in RFC 7049. = There may be a need to preserve the actual text string for some reason; = base64 is deterministic only if you know all the choices. > However, CBOR generally treats base64 as a data type itself and as it = is has no means for indicating the type of the original data before base = 64 encoding was added (by contrast, MIME can describe both type and = transfer encoding). Right, the semantics of a =E2=80=9Cdecoded=E2=80=9D 33/34 is that of a = byte string. > So how can the receiver of base64-tagged data know the type of = original data? It pretty much has to be in the definition of the CBOR = protocol. Yes, byte string. If you need a =E2=80=9Cbase 64 encoded MAC-48 address=E2=80=9D, you can = go ahead and define a tag for that. > It might say it is always an X.509 cert or an elf executable or such. = It might say it is looked up by magic number (in which case 55799 might = apply). Lots more options... The tag, or a data definition (CDDL etc.), are the obvious two = approaches. > It is also possible to define tags whose content type can be bstr, = base64, base64-url. If it was really common to base64 encode X.509 certs = (maybe because of JOSE) and a tag was defined to indicate an X.509 cert, = it might be useful to say the X.509 tag content could be bstr, base64 or = base64-url. Yes. I think we don=E2=80=99t have a tag for X.509 certs at this time; = where these occur, they are defined in the protocols (e.g., = draft-ietf-cose-x509, which actually defines useful constructions around = X.509 certs, which anyway really should be called RFC 5280 certs), = ultimately supported by the COSE tags. > No suggestion for change and nothing at issue so far, just thinking = through how it fits together. >=20 > What would really be helpful to me is some detailed example of when = you=E2=80=99d use the base64 tags. Why would you ever use them when CBOR = carries binary data just fine? Why wouldn=E2=80=99t every CBOR-based = protocol just say you always strip the base64 before CBOR encoding? And = why wouldn=E2=80=99t every CBOR bstr always be base64 encoded when = translating to JSON? These are all good guidelines; see above for a possible reason, but I = don=E2=80=99t know a good one either. >>=20 >> Well, not =E2=80=9Cit=E2=80=9D, but any byte string in the CBOR data = item. >> So, here it would base-64 encode for JSON conversion the byte string = in tag 24 (the tag 24 itself would presumably be stripped in any JSON = conversion, but I=E2=80=99m already confused =E2=80=94 you can do = =E2=80=9CJSON in JSON=E2=80=9D as well, just not tag it). >>=20 >>> Decoding: >>> - remove the base 64 encoding because of the tag 34 >>=20 >> That is inside, so you see it last. >>=20 >>> - feed it back to the CBOR encoder because of tag 24 >>> - interpret it as an RFC 3339 date because of tag 0 >>=20 >> Lost track. >>=20 >>> Base64 encoding / decoding is not that much code or that difficult, = so a generic decoder might actually do this. >>=20 >> I wouldn=E2=80=99t touch that with a ten-foot pole =E2=80=94 it might = convert that pole into base64 without asking me. >=20 > I wasn=E2=80=99t suggesting any base64 decoding conversion that = wasn=E2=80=99t indicating by a tag in an input stream or any base 64 = encoding that wasn=E2=80=99t requested through an explicit API request. = Section 3.4.5.3 seems to suggest the decoding is a good thing to do: >=20 > 3.4.5.3. Encoded Text >=20 >=20 > Some text strings hold data that have formats widely used on the > Internet, and sometimes those formats=20 > can be validated and presented > to the application in appropriate form by the decoder > . There are > tags for some of these formats. As with tag numbers 21 to 23, if > these tags are applied to an item other than a text string, they > apply to all text string data items it contains. >=20 >=20 > Is there anything wrong with a generic decoder validating and removing = bas64 encoding when encountering tag 34? As long as the application knows this is happening =E2=80=94 it may no = longer be able to validate what it got on the structural level, though. > Also see this issue I filed against this text and Table 5. (Where =E2=80=9Cissue=E2=80=9D was a link to = https://github.com/cbor-wg/CBORbis/issues/194 .) Yes, I think we do have a genuine bug there. The specific text is from = pull request #18, with the change dated 2018-01-29. Thinking about a = good resolution now. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat May 30 10:22: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 E63D33A08A5 for ; Sat, 30 May 2020 10:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.038 X-Spam-Level: X-Spam-Status: No, score=-0.038 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_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjsw_5jY_Eoo for ; Sat, 30 May 2020 10:21:58 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 A33F93A08A3 for ; Sat, 30 May 2020 10:21:58 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id g14so1935754uaq.0 for ; Sat, 30 May 2020 10:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XuZA+GmqJGe7662JAaJ+2g2SFmjFjB3pclAjB43VF7U=; b=iBmJwKWOTJYNxVZKpJDuRbfqUxCucQpoNZrRfyRUR5goXusK1g5Xopo6JsrjAy6kX8 YcmebntyQw4ynz+oLT7axcNQ25zzbvx1Z/WlyXIdELiL85lIsogxbrPRlxYRi3toNNoK uDSJBT7/a/AkKzd56h7Up5/z4dlDPkFUcf8LKOlYe2R4v9fYf39oERKtXSSF/u2SG4Ui G0oCF1WoFFtQmAR9OqVuujzyDLSjobh5nmlgKRUg9+2U+hz8LfQhIMIIq2nE/0RE+HBA krHoPCr+aRosCvZDhOqA/Kqc9KQ1OvjV0ipIr+EHJSPtqJQRDZIgZtz0otlfy+OFNcsl u8jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XuZA+GmqJGe7662JAaJ+2g2SFmjFjB3pclAjB43VF7U=; b=VxMcZoCKwN+32gUaLmQ8iReF8P6Qx9zdfJCONpqFIC4A0gSuFy4g+0sK3AUMK6Y0l8 C4VcXAC/wcF138p2mWnb7T0I7NmAIDkFC1CL8q3y/PUhdOsXL3wHQDlg94fkHODfrVUo j6FpreKRGhGFdhBwQGvP5ANK+FPJxFL99dB7GZ0S7jZHNboiZXi6YFvQ9KO1+B+pokWI 7d6yw9c8o0vs+SDQWqLP7yofyO+lCDE9a3+cqJMnDWbWZn1tzhlALw78UGpGfXMu9wgj JPEU4kuKFUh3W3XUk4SunIpHpGukMwkzEZJELhDCAl9Mmb2YE9SNGkeVvakf9YtR234g KXzA== X-Gm-Message-State: AOAM532aOH2M5xBBN9KEQ+25LMvW5Jnk4Z3py8XnbZ3a3Mzl+pR80QcC Oe0Uid6UTC5U6321ZmZnIC4S3DU5qDbOY/FhqZrmiw86VlU= X-Google-Smtp-Source: ABdhPJws0sS5MW1RWH7TmnBl6cGVSgsXHq0iu7x3SgZuF2gKJoVK9l18eAsEP+/9oirnxHUAtpVdIa02ijQDE8MRp2s= X-Received: by 2002:ab0:2094:: with SMTP id r20mr10305235uak.3.1590859316960; Sat, 30 May 2020 10:21:56 -0700 (PDT) MIME-Version: 1.0 From: Jonathan Beri Date: Sat, 30 May 2020 10:21:20 -0700 Message-ID: To: cbor@ietf.org Content-Type: multipart/related; boundary="00000000000079cc6105a6e0cc66" Archived-At: Subject: [Cbor] CBOR logo experiment 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, 30 May 2020 17:22:00 -0000 --00000000000079cc6105a6e0cc66 Content-Type: multipart/alternative; boundary="00000000000079cc6005a6e0cc65" --00000000000079cc6005a6e0cc65 Content-Type: text/plain; charset="UTF-8" I had a moment of inspiration this morning and thought I'd experiment with a CBOR logo. I'm by no means a designer, so any feedback welcome: [image: image.png] Font: Hacked designed by David Libeau and licensed under Creative Commons by 4.0 . In HTML: H1, font-weight normal, color #333 I might try a colored font version too. Let me know what you think! -- Jonathan Beri linkedin.com/in/jonathanberi --00000000000079cc6005a6e0cc65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I had a moment of inspiration this morning and thought I&#= 39;d experiment with a CBOR logo. I'm by no means a designer, so any fe= edback welcome:

=3D"image.png"

Fo= nt: Hacked=C2=A0designed by David Libea= u and licensed under Creative Commons by 4.0.
In HTML: H1, font= -weight normal, color #333

I might try a colored f= ont version too.

Let me know what you think!
=

--
--00000000000079cc6005a6e0cc65-- --00000000000079cc6105a6e0cc66 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_katwayto1 iVBORw0KGgoAAAANSUhEUgAAAN8AAABgCAYAAACdZaeMAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAABJ6SURBVHhe7Z0FtFVFF8cHsbu7Fbs7MbDBLizs WIqBqKgYn7FcdqIY2IDdgV3LbkwE7MLuju/jN8zhO9x37r1n4pw597F/a82Cc3m8+96d2TN79v7v mQ7/HY0SBKF0JjB/CoJQMmJ8ghAJMT5BiIQYnyBEQoxPECIhxicIkRDjE4RIiPEJQiTE+AQhEmJ8 ghAJMT5BiIQYnyBEIpqw+p9//lFff/21euedd9Tw4cN1++KLL9Qvv/yiPvjgA/NVY5hjjjnUtNNO q9viiy+uOnXqpNtss82mOnbsaL7KnY8++kgddNBB6pNPPjGvhGOGGWZQs846q5psssn0z77wwgur xRZbTM0yyyxqookmMl8VH/rj888/VyNGjNDtzTffVN9//70aNWqU+uabb8xXKTXhhBOqeeedV00y ySRq0UUXVfPPP7/+k9emmmoq81Vh+PPPP1W/fv3U0KFDzSvFwdiib+acc061xBJLqLnmmqvw/inV +P744w/16quvqttvv10999xz6scffzT/4sbUU0+t1l57bdWtWze19NJLOxvi+++/r42PwVcWE088 sVp11VXVlltuqVZccUU9mMsm6Y9bbrlFPfnkk3qw+4ARdu3aVa2//vp60vHl999/VyeffLK67777 zCvlQf+sscYaqnv37l5jqxGlGB8zKB08aNAgb4OrBzPVfvvtp9ZZZx39wdkQw/jSMFAPOOAAtdFG G1n/7C789ttvuj+uvfbacVa1ULA6du7cWR188MHaa3ElpvGlWXDBBfX4WGWVVdQEE4TbqXX8z2jM 34PDTHrPPfeoI444Qj3xxBN6pi0KjPqRRx5Rr732mlpqqaXUNNNMY/6lOUwOQ4YMUT///LN5pVww hscff1y9/PLLepbFBSoC5tlnn31WHXrooeqBBx7Q71sE//77r57Qbr75Zv3Miujiwv3999963Iwc OdK8Eodvv/1WPfjgg3o80z9MLiEoLODy1VdfqaOOOkqdeOKJhcyu9XjhhRfU3nvvrZ5//nnzSuvw yiuvqF69euk9V2jY0w0cOFB//48//ti8WiwYz8UXX6yN/bPPPjOvtib8LldeeaU65ZRT1K+//mpe 9aMQ43vvvfe0G8VsHgOM/cgjj2xJAyT407dv36DBHwxvwIAB6rzzztODqGyYEHv27KnHRauDJ4e7 zmfqS3DjI4J56qmnRv+gcUPPPPPMQiKYRcNnd8MNNwTpYL7H4MGD9awdEyYVJsT2YIB8lo8++qh5 cieo8bFBvvDCC/XepQrQ0ddcc413FC8GzLBvvfWWeXLnmWee0X0SY8Wrhf64+uqrg7ltseCzZFyx tfIhqPERriZwUSWIlA0bNsw8tQ6s3A899JDX6kfetH///pUwvAQmFYIXJWa4CoGJkT26D8GMj1mA 2aBKHQ3MsnR2CBeubNgruQarGNwMdEQMVYOU06effmqeWhcisXh7rgQzvsceeyyIm1QErCCtuNfg Z3aNEjK47777bvNULfi96JNWX/2Y2EhDuBIkyY6L1KdPHz1T+4JMaYoppjBPY6iVOLnQu3dvtcMO O5incXFNsifSsTRZ8jgfiHyigrHlpptuUqeddpp5coOE/3zzzdcmrxWiP5DYnXXWWWqmmWYyr7TF NcmO5G2ttdZqmI+jn9544w3dVz7Cj4suukittNJK5smOIMb39NNP61yOq8uJlm733XfXCoIsmRU/ IisAbu0dd9zR8H0OP/xwteGGG5qn/0Nuiw8qa7NP8v/DDz9Uf/31l3klH7vuuqs68MADzdO44OYS +WVfcMkllzjn1hq9Rz34HdFOIDpwYdlll1X77ruv/jNLVkV/8LshEyTy5xrQYnLo0qWLeWqLq/Gh FDrmmGPUpJNOal6pD/2EjvWCCy5w2sO5To7g7Xbyw6PTdDW87bbbTkfjmKnq6Rs7dOigZUqEqkna o+msBwLmRISdbqyoSIP4oGsbCgpbw2sGgxbxNAPhsssuU8stt5z5FzsY5LaDm0DL22+/bZ7s2GST TdS5556rVlhhhbp6RvqDFWuvvfbSq1ej/mgEUfHYe3F+RxRRGDnCaltIobiuX97Gx5L9+uuvmyc7 EEXvv//+bdzMetDpiHbRDNYD42Tg1Db+H8qXF198sU3DRaNCoihmnHFG1aNHD/NkB4MTuZYN7Klc dKpIp1hlbfoDb6VRfzSCCcLH5QsJE+UWW2xhnvJDoNFVNultfGzsXbR3k08+uV71ppxySvNKPuhw xNN0ug2szOztYsE+hP1T0TALs5dxgVW60R4sC/qD6oyFFlrIvJIfBBBffvmleYoPK+D0009vnvLx 3XffOXtN3saHi+OSNKW2bZFFFjFPduDmbLbZZuYpPz4ugi/Uus0888zmqTgQS/N72sKgY/C5MN10 0+n+tIVIoW+iOiRMPLUBtGYQuHF1nb2Nz3XmYiXI695kQbRs7rnnNk/58HERfEHVzyAtGiozXFzO 2WefXbteLvC70Z8ulCXyzgPxAoppy8Lb+AgIuECNlE+BIjO1rRuHm+OTFG0FML4ffvjBPOWHQZcn OlgP6ildcB0/RYALHbJerxle78RAxu10YZ555jF/c4NZynblo26vKhv8ouB3dOkTXC6fanoiyuzj beFnrcqEyApuUwfqi5fxsX+yjcQB7g2d5QOzlO0eio1x1eRvoXGt4iChzmfqClsIl4HLHtVlDBUB npjP6m+Ll/Gxf3KRPzFDhvglbfeMzLKsDO0ZAgAu+Bz3APSFywFKKGWqUnXC5FymZ1Seg5uCjnJx UVwhOkqAhnxfmW5FDFz3UD7BL2DldDl/BsOrivERtSzqaI0svIyPFIPLTMvyHmJjS6oCWRCyMdqN N96oBbs0ih3RmpJER2aFNI0jDRZYYAHzv8uFfY2LS8hkUfQRdlBGJDaLn376yXm1bnW83U6XzTJq khCndJHYJcGLsJVGuDuRk+EC+exhQoM74+LyInnKGxVmBYkVPWQbUWaY3hVSG6h40MzWNnTBO++8 89gJnHbFFVc4p2CaEcXtHB8h8W278pFOsdEbEriIrZWsOgTcqGTI0vjiyZHvTCbwZBJv5KX5pGjE +EoAg0B8bssyyyzjnD9rFRA+uOQlXUHOuNVWW2mdb21Da4w0j4O3koZuuZEww2dbIMZXMKxGFLUi 3raBgNQ222xTamAqBqxEZaYayGdSvkbJVG0j2kldJ2L/pCHUb1QwS02nq1jEy/gQlcY65bnqEEhg taPO8aSTTrLOL26++eZq+eWXN09C0ZCGevjhh81TflwE5Qmy8nnAila7aWe1IqVB5QVnl3KolC3U /vG9fOR3Qn6ItlJTanveDYEY9oiuiPF5QIK4dtPue4QENXVUoVMDWAS4Xbvsskub/U6Ii02agQu9 7bbbtnlvIrTpfVbSSBP5HldRD9RZRKA5heGQQw5R9957r/mX/FCgbVuClcbrGAkqkffZZx/zlB+b Mv8yiH1RSgLV/FTru3YoaZ9mxy5wZAeV6kTyQpLnvUkxnX/++W0E8eRqOc8zFIgqiELWSzWx0oU4 Z4c9IftH15SWrHwVgbQC0c0yVfXtFVY0TtKr9UqSFsLw6K/VV1/dK5csPT2aJPyMO+bjRvhARI27 FDbddFOd2C2q7pBQ+nrrrTfOERu0Mk4Zx7PA7ax9bypcUCfxe19++eX6PExcTvbLeElVZM011/Q+ mUCMbzRJ+JkgR1FqhrygUkEqd/TRR1eqyrtIOOIPOSBXihEhrvrqj1vLeS++Ki0xvorCDU/sp9kP EQxoz8oV9p+krbjHD0VJVWIB9dh66621UN+X8dr4uBKZMzWTdv311+uDdROhdrqRrysbdIgEIkj0 4pK1VwPE2EjLkKbBLa0ypIG23377IGkgWflaABL07IW4cag98u677+oJBpeTM06rwnHHHTf2eMmk XXrppcHSQFFSDcwcrCRVSSLj1qHhYwYmVJ53r9W5c2cr4TNGhDvpem8EVRtnn3123eqBPOH+ejCo XA/2BZ/3Puyww3TZFwW9nO2z00476dd9vmcIMD6XU/Ly4mV8KAIoz2h2WYRvxxZNcm0VagXuLM97 9J5t54QYTAxMcpJZE1erGh+rHkl+IrysKsl+iuBTv3791NChQ/VzAkOWCpGiq86JflOyVo9OnTp5 1UF6uZ1Ee3wO3QkBx1hkqSOyGpv6LMjVkADmdymzktkFVgiXczkbEeJMHR/Yy1IdwM+QDt8zvvCQ 2PemGxPFaqutZr6qOLj+OS2yrm2+hzCXsufjEvm0/pGq8lDgh2d9MFmt3oe17rrralU7ub5Yeb68 kCtzPZ6/HoT2YxYeY/ykGkh+pyOdrHAI1ClCTjdKkKpy9IQPXm6nqywLA7S9eaced955p3Zb8tDM taJj0fnlPW69ntvJjUdZ7heuIsdY2JyXwiAbOHCgnmQSOFl65ZVX1op6BNwJrq5fPdmXDT5uJ5et oDxB7IBbnbjUtt8z68q2LOjnEJdz+rrqTisfg4vQPKqEMgshx1c4ImOPPfbQd1twMxCG157A3Udg 3b17d/OKG926ddOXtuDFHHvssW3c1aTtueee5n/Excn4UJoTEqZA1OWehvYOcql0kWbSOB+EmrEs l7heYyVG87nxxhvrotPddttt7PdLr3qxoA6OvbTPPpR8JoJyBAW+e25WPoJnZdyL4Yvk+VoAXM/Q 9weGAqHCkCFD9GFDrhBwYWIh2umjaWUHhaCaKGQZWlVfxPhaAAbUOeeco/N7saPLtRCo4efy0Tly Bgr7PVIMXAPgCj8LUVAu+LS9Qi4GYnwtAG4nFQ877rijHmDJnru2oYIZPny4/j+E6BNp3Omnn259 r0VeOHSIXBh6R1cI+BBpJoDkO7kQSOnfv7+esKqOGF8KOt7nWICiwKDY6xF0IV+Z7LlrG/ejJ+oZ DhROzjMlIud6dXMzOJi4V69eztdQA/vF2267TacVfGH/SYU5Iu2qI8aXglWlquUs1OAdf/zxzrfO FgVyMAw9hMo/BKQbSOfUE1RUCTG+FmHUqFE632V7c2rREL0lOZ7OQ9qCZhV9JwbsO/lheKz2VfRg ahHjawEYnD179tTiBIIJSy655DhHmme1l156aayiiHKdZC9YDyKFI0aM0Mlum9IlRPIIJnzkXhTT 4hZX7Yj/ohHjawHIg/Xt21f16dNH/53oIDrIRg11SHJmCQL4ZnIsVi9cWty1kSNHmlebg7oJpUcI xcj4hpPx1c68RV4mIYy5N47VYYMNNijM7eT7UyXAHfs2Kx81eLjEVIO0CkgCk/q8pMU4L8bJ+Gpn 3maXSWTBTOxamY2qhgFZpVtNG4GQnCptzmXhznQXmPA4XKmo68K4E4JBiWqmWfCEekciq1y5xorJ ydqsyMOGDTNfIeQhmtvJCVWukiRcHQS3yNtCGh+Ker5v7ayIgNoHDI9cGJpCksm2MLkRRCgSNLrk x5gomtXJMYHceuutasCAAeq6667Tng/PIY7kG59oyT0fSVlkSGgocZdiQS3hVVddpfdK9SYBVvdB gwZp5QaD2kW7SIqBkpsi4dRoDLxHjx6VOWGgSiD6Tm+1aHgjPkQzPtxUZlqSq7bgn6NgZ+Us6jjx PFDFTP3fU089lelOYpysnCR9KddhgBddfe0KExoJeryJ8SnimBcEGOmtFs13C+BVz5dgW9eXt+4q D1m1WZxzQs1bLdTRNfrAbOvHkHAR+qcjsrCpNWyGbQ0k++KsCOf999+vzjjjDPM0BrwHJoi80i68 DlxM25uXEihe7t2799j3q9cvtv3hUyfa7L1Y+SjnygJdq8tVblGMr2hOOOEEHWJn8LHPYlbPg21n l4nPwEoTckJwJe9dHVUyvka4vm9L7vmawYzKHovDeHxPFRZaBwplOX4ew8aYqk4Q46NwkWut0ofM ZrWyDp5lL4gB4noRAheEKhLE+PDZyfUkKvp6DQFuGVCCw8nTHE3AfXeCUEWCu52E1qmlqj22j1Zm EpbcWCtrBUmopy+Q5F49oX0R3PhQngwePDjzPBKikEI+ML70+S9VOK9FCEu7DLi0B+66665xqtSL TrIL5SPGV1EwvnSVetWKaAV/xPjGMwjFJ9FnqiSKgmuT0cSmo91J4yyaogTirUSQJHuaKiSqXU8S Zr/Kz40sDHxvFUpA/dC1a9e6Spg81J5OHQLOySQ3VgQxT8HOm8RPgyAj61KWPHTp0kVrYm0Jbnx5 yXs0u8sHGYpQE0mIgVgEYnxxiWZ8gjC+I3s+QYiEGJ8gREKMTxAiIcYnCJEQ4xOESIjxCUIkxPgE IRJifIIQCTE+QYiEGJ8gREKMTxAiIcYnCFFQ6n9y9swklcEvUgAAAABJRU5ErkJggg== --00000000000079cc6105a6e0cc66-- From nobody Sat May 30 18:13:18 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 AA64F3A1037 for ; Sat, 30 May 2020 18:13: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 OZeqI0lefReT for ; Sat, 30 May 2020 18:13: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 34BEB3A1031 for ; Sat, 30 May 2020 18:13: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 49ZL083zR8zyV3; Sun, 31 May 2020 03:13:12 +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: Sun, 31 May 2020 03:13:11 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 612580391.75225-768382cd7fc67bd0d3ff90f051b78253 Content-Transfer-Encoding: quoted-printable Message-Id: <124C2398-BBAB-47FB-B0C8-E6D7A04A3670@tzi.org> References: To: Jonathan Beri X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] CBOR logo experiment 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, 31 May 2020 01:13:18 -0000 Hi Jonathan, > On 2020-05-30, at 19:21, Jonathan Beri wrote: >=20 > (Insert apologies if, at this time of the day, my autopilot is = automatically switching into prof-talks-to-student mode here. I=E2=80=99v= e been chided for that before. Then mix in the Whitsunday mood=E2=80=A6) So what is the message that you are trying to convey with this logo? Let me try to guess through the eyes of a random instance of a persona = looking at data representation formats. We have the base form of the logo, which looks like some old-fashioned = (or really, outdated?), 1950=E2=80=99s, FORTRANy thing; black and white = of course. It seems that ancient logo bequeathed from the ancestors then has = incurred some damage through transmission errors and looks a bit = unstable now. Needs lots of cleanup before use. Not good for the squeaky clean product (security, banking, =E2=80=A6) = I=E2=80=99m building right now. To provide some contrast, let me do a quick proposal for a list of = branding properties that a CBOR logo maybe should convey (or at least = not actively counteract): =E2=80=94 stable =E2=80=94 efficient, concise, =E2=80=A6 (I think that=E2=80=99s where = the image is closest) =E2=80=94 and related to that: somewhat minimal, but not simpler =E2=80=94 approachable, friendly, easy to use =E2=80=94 open for new business (extensible, with low ceremony for that) It probably would require a genius to convey all of these properties in = one logo. I=E2=80=99m not that genius, so for cbor.me I settled with the same = basic idea you used (just say CBOR), and just threw in the font Palatino = and the color #663399 (please excuse my rusty HTML if you do examine the = site). That=E2=80=99s where I stopped=E2=80=A6 Yes, it requires a lot of background to even see in what ways that is = actually somewhat minimal (history questions: What is (was) minimal = about #663399 [1]? What is (was) almost minimal about Palatino [2]?). So I=E2=80=99d love to see if someone came up with something better. If you are looking for something completely different: we also have = Stefanie Gerdes=E2=80=99 design for a sea boar [3]. But that is maybe = more of a mascot than a logo. I=E2=80=99d like that in plush. Gr=C3=BC=C3=9Fe, Carsten PS.: Here are the answers for the two history questions, and a pointer = to the sea boar, in case you care: [1]: https://en.wikipedia.org/wiki/Web_colors#Web-safe_colors [2]: https://en.wikipedia.org/wiki/PostScript_fonts#Core_Font_Set [3]: http://www.tzi.de/~cabo/sea-boar.png From nobody Sun May 31 09:42: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 DBAF63A09E0 for ; Sun, 31 May 2020 09:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, 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, URI_NOVOWEL=0.5] 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 U5vnj1JqDuYS for ; Sun, 31 May 2020 09:41:56 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 E20ED3A096E for ; Sun, 31 May 2020 09:41:55 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id c9so2025431uao.11 for ; Sun, 31 May 2020 09:41:55 -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=dE8u9u6imViXgAsPQ1y6F07RJteVYQTUoX8LuCFyx/o=; b=BR6pQqZF8W9O7Am1BD7aZXueyPonkm6Vpt+acr8lDGwngGQCWL4WyywV8zPA0N8wU+ OXfMx9y4fHVDzQddBKaoVBqeQ34sZ/urWo9lFsxlClbbx+t2xa9he3kdox/M+C3Plm1f Wr47jZTRcdmwuKKZ7jGFLfteH/snndbt5QQ/X5LrKW1Q6NoY8bCosDskUubYYen54M8F nfvzs5+6zpaFgxmBK5K+aol1QplARyi1pt+grvxmck43lMa5zikEKs6gHpzgFPstu+eS vXxRvyswRSJoq3ebeBbz9pqFCoxK0LrOYqf7adMNXkBeG+KV+pO+WQ06ADva0ZL8V980 N/tw== 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=dE8u9u6imViXgAsPQ1y6F07RJteVYQTUoX8LuCFyx/o=; b=dHD5mxMHHjJi7khNadGA4j7VhGAP2NCzEkBm693Ac0y8XRtWmwlsmTioK9NKVKjhZf SB3c3H677yY2N3Dg9j8DFzgS2IaGAcYcK47Xkj17QLNYdPf8mxdqXUBRijBlGH07wNJG 5oBpN1CCs5KgxuZKxjLoBZd8snXn4ahCJkotgRil71qsQG6SrhAowjEMyz6HaW63ElVf 3d0oKpXRqdGcoQxHuCiZfE5hT56L9zP6CWbqXpw4WRfF/78XDTfburefAon3H+bAiy/5 5Q2Vvr1BXX/kxkUJxeSTy1Y9PFkq9jcYYTm0M3+aPdy60UaO6Rq9Ed5U5kKE99oS0Jke XsIw== X-Gm-Message-State: AOAM530o4rnGVium+aNVYeo5MR5AjLNYPllpIhz6GFtSnqV0j6w/RmNv U8KWXxJz4B+lwE9BDXFQ8bZvINGtSdjp7MJrTnFDY5zdt+8= X-Google-Smtp-Source: ABdhPJy6W/MtOKS9jK+IDFp91fZHZQ6vq5fPR4dPqle1tFYOMJZ7wwgUQVW3Wp1HwD33tzTfji+ySiinv2EHHdms6og= X-Received: by 2002:ab0:6f08:: with SMTP id r8mr14445192uah.111.1590943312105; Sun, 31 May 2020 09:41:52 -0700 (PDT) MIME-Version: 1.0 References: <124C2398-BBAB-47FB-B0C8-E6D7A04A3670@tzi.org> In-Reply-To: <124C2398-BBAB-47FB-B0C8-E6D7A04A3670@tzi.org> From: Jonathan Beri Date: Sun, 31 May 2020 09:41:14 -0700 Message-ID: To: Carsten Bormann Cc: cbor@ietf.org Content-Type: multipart/related; boundary="000000000000faad3d05a6f45a38" Archived-At: Subject: Re: [Cbor] CBOR logo experiment 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, 31 May 2020 16:41:58 -0000 --000000000000faad3d05a6f45a38 Content-Type: multipart/alternative; boundary="000000000000faad3505a6f45a37" --000000000000faad3505a6f45a37 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No apologies necessary! I thought of this as an experiment. The inspiration came from wanting to create an icon for the new subreddit I created. I wanted something with the visual flair usually found on the site. The basic meaning I was trying to convey 1) a compressed packet, which includes data as visualized by the little bits of characters 2) transmission or movement of data and I wanted to use web-safe fonts and CSS so it could be used in many places, though I did need a PNG for Reddit. I too agree that a good logo design requires a certain type of genius - and unfortunately I don't fit the bill. And as I stared at the logo I think it connotes data corruption as someone else mentioned and not the type of messaging we want. Experiment 1 marked as a success - will not use. I think for now the wordmark on cbor.me works for me. I generated a new PNG logo for Reddit using https://htmlcsstoimage.com/: [image: image.png] Hopefully someone might improve the design one day! Thanks for the feedback :) On Sat, May 30, 2020 at 6:13 PM Carsten Bormann wrote: > Hi Jonathan, > > > On 2020-05-30, at 19:21, Jonathan Beri wrote: > > > > > > (Insert apologies if, at this time of the day, my autopilot is > automatically switching into prof-talks-to-student mode here. I=E2=80=99= ve been > chided for that before. Then mix in the Whitsunday mood=E2=80=A6) > > So what is the message that you are trying to convey with this logo? > Let me try to guess through the eyes of a random instance of a persona > looking at data representation formats. > > We have the base form of the logo, which looks like some old-fashioned (o= r > really, outdated?), 1950=E2=80=99s, FORTRANy thing; black and white of co= urse. > It seems that ancient logo bequeathed from the ancestors then has incurre= d > some damage through transmission errors and looks a bit unstable now. > Needs lots of cleanup before use. > Not good for the squeaky clean product (security, banking, =E2=80=A6) I= =E2=80=99m building > right now. > > To provide some contrast, let me do a quick proposal for a list of > branding properties that a CBOR logo maybe should convey (or at least not > actively counteract): > > =E2=80=94 stable > =E2=80=94 efficient, concise, =E2=80=A6 (I think that=E2=80=99s where the= image is closest) > =E2=80=94 and related to that: somewhat minimal, but not simpler > =E2=80=94 approachable, friendly, easy to use > =E2=80=94 open for new business (extensible, with low ceremony for that) > > It probably would require a genius to convey all of these properties in > one logo. > I=E2=80=99m not that genius, so for cbor.me I settled with the same basic= idea > you used (just say CBOR), and just threw in the font Palatino and the col= or > #663399 (please excuse my rusty HTML if you do examine the site). > That=E2=80=99s where I stopped=E2=80=A6 > > Yes, it requires a lot of background to even see in what ways that is > actually somewhat minimal (history questions: What is (was) minimal about > #663399 [1]? What is (was) almost minimal about Palatino [2]?). > > So I=E2=80=99d love to see if someone came up with something better. > > If you are looking for something completely different: we also have > Stefanie Gerdes=E2=80=99 design for a sea boar [3]. But that is maybe mo= re of a > mascot than a logo. I=E2=80=99d like that in plush. > > Gr=C3=BC=C3=9Fe, Carsten > > PS.: Here are the answers for the two history questions, and a pointer to > the sea boar, in case you care: > > [1]: https://en.wikipedia.org/wiki/Web_colors#Web-safe_colors > [2]: https://en.wikipedia.org/wiki/PostScript_fonts#Core_Font_Set > [3]: http://www.tzi.de/~cabo/sea-boar.png > > --=20 Jonathan Beri linkedin.com/in/jonathanberi --000000000000faad3505a6f45a37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No apologies necessary! I thought of this as an experiment= . The inspiration came from wanting to create an icon for the new subreddit I creat= ed. I wanted something with the visual flair usually found on the site. The= basic meaning I was trying to convey

1) a compress= ed packet, which includes data as visualized by the little bits of characte= rs
2) transmission=C2=A0or movement of data

<= div>and I wanted to use web-safe fonts and CSS so it=C2=A0could be used in = many=C2=A0places, though I did need a PNG for Reddit. I too agree that a go= od logo design requires a certain type of genius - and unfortunately I don&= #39;t fit the bill. And as I stared at the logo I think it connotes data co= rruption as someone else mentioned=C2=A0and not the type of messaging we wa= nt. Experiment 1 marked as a success - will not use. I think for now the wo= rdmark on cbor.me works fo= r me. I generated a new PNG logo for Reddit using=C2=A0https://htmlcsstoimage.com/:
3D"image.png"

Hopefully someone might im= prove the design one day!

Thanks for the feedback = :)

On Sat, May 30, 2020 at 6:13 PM Carsten Bormann <cabo@tzi.org> wrote:
<= /div>
Hi Jonathan,

> On 2020-05-30, at 19:21, Jonathan Beri <jmberi@gmail.com> wrote:
>
> <image.png>

(Insert apologies if, at this time of the day, my autopilot is automaticall= y switching into prof-talks-to-student mode here.=C2=A0 I=E2=80=99ve been c= hided for that before.=C2=A0 Then mix in the Whitsunday mood=E2=80=A6)

So what is the message that you are trying to convey with this logo?
Let me try to guess through the eyes of a random instance of a persona look= ing at data representation formats.

We have the base form of the logo, which looks like some old-fashioned (or = really, outdated?), 1950=E2=80=99s, FORTRANy thing; black and white of cour= se.
It seems that ancient logo bequeathed from the ancestors then has incurred = some damage through transmission errors and looks a bit unstable now.=C2=A0= Needs lots of cleanup before use.
Not good for the squeaky clean product (security, banking, =E2=80=A6) I=E2= =80=99m building right now.

To provide some contrast, let me do a quick proposal for a list of branding= properties that a CBOR logo maybe should convey (or at least not actively = counteract):

=E2=80=94 stable
=E2=80=94 efficient, concise, =E2=80=A6 (I think that=E2=80=99s where the i= mage is closest)
=E2=80=94 and related to that: somewhat minimal, but not simpler
=E2=80=94 approachable, friendly, easy to use
=E2=80=94 open for new business (extensible, with low ceremony for that)
It probably would require a genius to convey all of these properties in one= logo.
I=E2=80=99m not that genius, so for cbor.me I settled with the same basic idea you= used (just say CBOR), and just threw in the font Palatino and the color #6= 63399 (please excuse my rusty HTML if you do examine the site).
That=E2=80=99s where I stopped=E2=80=A6

Yes, it requires a lot of background to even see in what ways that is actua= lly somewhat minimal (history questions: What is (was) minimal about #66339= 9 [1]?=C2=A0 What is (was) almost minimal about Palatino [2]?).

So I=E2=80=99d love to see if someone came up with something better.

If you are looking for something completely different: we also have Stefani= e Gerdes=E2=80=99 design for a sea boar [3].=C2=A0 But that is maybe more o= f a mascot than a logo.=C2=A0 I=E2=80=99d like that in plush.

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

PS.: Here are the answers for the two history questions, and a pointer to t= he sea boar, in case you care:

[1]: https://en.wikipedia.org/wiki/Web_color= s#Web-safe_colors
[2]: https://en.wikipedia.org/wiki/PostS= cript_fonts#Core_Font_Set
[3]: http://www.tzi.de/~cabo/sea-boar.png



--
--000000000000faad3505a6f45a37-- --000000000000faad3d05a6f45a38 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_kav9pywc1 iVBORw0KGgoAAAANSUhEUgAAAgAAAAIACAIAAAB7GkOtAAAAA3NCSVQICAjb4U/gAAAgAElEQVR4 nO3dZ3gU19k38Nm+K+1KK61670hIAoFAojdRRDPFYIyNbWwgrri32E5w3BLHccEt7ia4dwwYU0wH 06tQBdRQQ71rtdryflAewisElu6Zref/u3w9H/JcM3PQzsx/zsw59xFZLBYOAADYI7Z3AwAAwD4Q AAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAo BAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAw CgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAA jEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAA AKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEA AMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIA AAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQ AAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAo BAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAw CgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAA jEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAA AKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEA AMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIA AAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQ AAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAo BAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAw CgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwSmrvBvSDyWiuq2y9WNJY X9XaVNveUN3WXNfe3mLoaDV0tBoMHV0mo7n7P7FELFdKpXKJXCGRKaRypVTjpdT6uWt93b383LV+ 7t4Bav9wrVSG/AOH09neVVXceLG0qb6qteFiW2NNW2ujvr2ls725s7PDeOkkl0jF3f8p3GRuGrmb RqHWKrV+7t7+ai9/94AIrX+4VqFypgscbE9ksVjs3Yar6mg1FGfXlObVlubVXiiorS1vMRnNQu1c IhX7h3uGxOpC43TBsbqIgb7ungqhdg7Qdx2thqIz1UVnqouzqy8U1DVcbBNqz94B6tABusgkv8hE v8gkP4WbTKg9g2twuADo6jTlH63IO1JecKyiNL/OYrZR80QiLnSAT3xacEJacExKgFzpWI9OD05Y 09FqsHcr/ksqE0vlEqlM0t3HUmuVGm+Vxkul8VJ5+bv7h3n6h2u1fu4ikb0b6sAsFq44uzprX2nu obLinBqzyernuUQqjkr2S0gPSR4TFhbvY+3D2ZIdrw6RWCSTSy5dETKFxN1T6dF9OXgrNV4q3xCP gAitLlAjljji9eAoAdDRaji5q/jkruKcg2UGvdG+jZHKxNGDA4ZPjR6aEeUg3QKHCoC+kCul/uGe EYl+0YP8owcH+IV62LtFjqLw9MXDW86d2FHUWNNurzboAtVDM6LSMmNcIwkc/+qQysS+oZ6BkdrI JL+YlMDwBB+J1CHeP9s5ACxmy5nfLxzYWHBqT4nRYLJjS3olkYoHjghJy4wZPD7Cvq9THf8UvzaN lzJpdFjKhIiBI0IcrXdlG21Nnb9vyN+3Lq+quNHebfmfkDjdmDnxI2bGqtRye7eFzumuDplCEjHQ d+CI0KEZkQERWju2xG4B0NbUuf/nvF3f59RVtNilAf0iV0pHzoqbdGOSvX4tpzvFr0aulCaODBk7 L2HgyFBG3hHVlDX/9kXW7xvy7d61vRqlu2zsvISMxcle/u72bguFU18dgVFeqRlR6dNj/MI8bX90 OwRAU237ts9P7/4+x2Gvh2tIGh2asTh54IgQGx/XqU/xXvmGeIxfMHD0nHg3jRM/e15bXUXLhg+O Hdx01mafsviQSMVj5yXMWDbE08fN3m3pH9e4OpLHhGUsTk5ID7blQW0aAO3Nnb98fHzXdzkO+Lan X4KivWb/adjQjEibHdE1TvEruWnk028fMnFRkkwhsXdbhNTe3Ln+/aN7fsgVcNyabciV0oybkmfc McSJ3tS50tURFO015+7hKRMibHM4GwWAyWje9W32xo+Otzd32uBwthGZ5DfvvrQBw4JscCxXOsWv pPVzn3dv2oiZsfZuiAAsFm7/z3k/vX24tVFv77bQefm73/DwKFs+4vDhelfHgGFBix4dFRzjbe0D 2SIACrOqP39xT/m5emsfyC4SR4bMX5keEqez6lFc7xS/0qCxYUueHud07x8uV1vesuZvu84er7R3 Q4QxeHz4kqfGeehU9m7IH3DJq0MkFmUsTpp3X7pV56taNwAMeuNPbx/e+c0Zxxhrai0iETdxUdLc e9OsN1LIJU/xK7l7Km55ZvyQiRH2bgjF3h9zv3v9QGeH833ZugZ3T8WSp8Y5eFfAha+O8ASfFX+f 7BtirVHUkmeffdZKuy4rqFt936asfaVW2r9DKTpTfejXs4ERWr9Qq3zK37zmpLN/OOmLrk7T0W3n ZXJJTEqAvdvSD53tXZ+u2rV5zUmne+P/h7o6Tcd+K2xr0senhTjmVCbOpa+Optr23zfkB0V5W2n8 obUCYM8Pue89vrW5rsMaO3dMHa2GQ7+eqy5tihsaKPgHNBc+xa+Ud7i8sboteXSYSOygd5zLVRU3 vnbXRpd57dOr4uya3ENlyWPClA5ZTMK1rw5jl/nY9kK/UE9rfBIQ/u2Sscv82Qt7vvj7XmOXqz0N 9cXhzed2fpNt71Y4vX3r8tY+v9vx3xzmHan4x9J1F0ua7N0Qqys6U/3SrT+VFdTZuyEsMpssn/xl x751eYLvWeAAaG/ufP3ujdZoKLDmwMaCH1YftHcrruXAxoI3V25y1bfPV2qsbvvnsp+zD5TZuyEs sli4z17Yc+y3QmF3K+Sbivqq1jdXbqossvpM9+5CnrpAjS5QowtS6wI1Xv5qhUoqV/7vP47juqvm drQa2po625o7Gy621le11le1VhQ2VBU1tLewct06r22fn/YJ0ky4IdHeDenFrm+zv/rnfqsewidY 4x+u9Q/zDIjQ+od5unkolG4yhZtMoZLJlVKD3tjZ0dXZ3qVv72pv7rxY2tRdRPpiSWNtubVm13d2 GN95aPOf/jHZZgPV4XJrnt3lH64NiRXsXZBgAVBd2vTqXRsbqwWrZNuDp49bVLJf1CD/qGT/8ATf vswb6i63pFLLvQPUV/5/66tau2vwFhyrKM2rdfy3DWz67o2DsUMDbTAgul+2fnbqh9WHrLFn7wB1 /PDghPTghLRgjfe1xl8q3WVK9/+9kY9P+98M0ua6jtzDZbmHyvOOlAtYXLqbyWh+/4ltdzw3afi0 aGH3DH/IoDe++8iWp9bOU2uVguxQmACoLm361582NNUKX91QF6RJnRw1bEp0eILAZQu9A9TeAerU yVEcx7U1deYeLju5qzhrX6m+rUvYA9nRU2vnhQ/0FXCHFrOly2AyGc0GvbG1Ud/aqG+u66gpa66+ 0FRR2FBWUCf4MBijwfTxMzueWjtPKneUqcK7vs0W/O6vUsvTMmPGzksIHSDAhBIPnSp9emz69FiO 40rzavf+lHt48zkBT2yzyfLJX3fIFBKn7gcIcnWYTZYug6mr09jZYWyua2+qbW+42FZRWF9Z2FCa V2uNMcF1FS1fv7J/+YsZguxNgACoKWt+9U6B7/4KlXTM3IT06THC3r+uxt1TMWxK9LAp0UaDqbs6 ada+Utcb0sefSCzqfr2mUsuvnLFl7DJfyK/NPnDh9N7SkpwaoQ5afq5+y9pTM5cPFWqHfBzYWCDs m5+weJ9JNyalTo6yUumFsHifm/88duFDI49uPb/9q6yys8LMxzSbLB/++bf73phu49o1jkYsESlU UoVKqtZyusD/702DyWguya3NP1J+ZOt5YafBHtlyfvR18YL85flOBGtt1L98+7rqC838m9JN46Wc uChp4g2Jbh72LMTf0qDfty5317fZhKLts1akzr4zVdj20Ka6CN4D6LuasuZ96/L2rcsTpCKC0l32 4s+Lher2kuUcLHvrgV+FWrzFJ1gz5+7hw6fF2KwqqsVsOfTruZ//faS+qlWQHSrcZE98MsfuL+gc /+qoLGzY+W32/vX5Qg1X9Qv1WPXNQv7dYl7zAAx64xv3/lJ+roFnI7q5eSjmr0y//bmJCWnBMoWd C1EpVNLYIYHd9Z+rihr6dReLSw0SvEAQbaTz2HkJWl/7FPh191AkpAVPWDBQppCW5NbwHBNs7DIb DaakUaFCNY+gsrDhzZW/dnUKcAGr1PL5K9OWPjsxdIDOljWxRSJRSJxuwoKBKrW8MKvaxHugtqnL nLWvNG1ajH0Xm3T8q0PjpUoeEzZuXoJBbyrJFaBz3NbcqdYqo5L9ee6H1zDQT1ftLM4WpqefPiP2 uR8WTboxyaFqEEqk4rTMmFXfLFzx9wz7rtvgpBRuspnLh676ZiH/7uren3LtOOCyvbnzrQc3C9KA 2KGBf/16QcbiZKvWeLkGqVwy9ZbBf/ny+sgkP/57q69q/fejW/C+tC803qrFT4x+6rP5QdFe/Pf2 2xdZ/P/s9FPw109PHN9exPPwHMf5h3s+/N6sO56bqPGycwf/akRi0bAp0X/9esHiJ0bb/S2EM/IO UD/w9szMpSl8dtLVaTq8+ZxQTeoXi4X7dNVO/isXSaTiufcOf+S9Wb0OS7Mx3xCPxz66bubyofyn WxdmVVtpTJRLCov3eXLNPP5jqOqrWo9uPc9zJ8QAyD1U/vO7R3gem+O4YVOin/78ettUVOZJIhVP WJj4wrobxy8YyMhSVgISibh596UtfGgkn53Ya4Lhlv+cPL2Xb0krtVb56IfXTb99iOPUt5BIxdfd Neyhd2fyXw9y+1dZgjwOMkKhki5/MWPiIr4TXLZ+fprnHigB0Nqo/3TVTp4D50Vi0fyV6Sv+nmHf tXb7S6WW3/TkmCc+nStIJ441k29OnnrLYPLmpXm1Ag436PtB1793lOdOdIHqxz+eE5UswCsXwQ0Y FvToB7P513z+7IXd1hgI7sJufGz02HkJfPZQVlDHc4lpSgD85zm+v7RKLb//zenTbqPfC+wrMsnv 6c/mT1kyCF2B/pp3XxqfV895h8sFbMwfMhpMn67ayfNNa0is9xOfzvUPt8OKr30UEqd74pO5PGsO t7cY1j6/W6gmMWLxE6N5PhbwLA7R7wA4sLHg9J4SPodUusseeHuG7ZfVFZZULlnw4IiH/j3LqRcw sT2xRLT02QnkwsJ5R2waABs+OFZxntcgt+AY70c/vM7xTxKfYM3jH8/xCdbw2cmZ/Rd+X58vVJNY IJGKV/x9Mp+RL8e32zAAWhr0371+gM/xFCrpA2/NEGT4gSMYMCzoL19ef/ksfPhDARHakbPiaNsW 2LDqcmVhwzZ+71i9/N3vf2sG/zfstuGhU93/5gx3T17zb75ffdCp18K0Pe8ANZ9JjmVn6/nM6uhf AHz32oG2JvqivnKldOWbM6IG8R276lA03qoH357B59U2gzJvI44Iaqnv4HMG9ssX/9jH5+WPSi1/ 4K0ZWl9Hf/a/nH+4572vZfKZXtTW1PnT24cFbBILJt88iE8fsTDrInnbfgRA4emLh349Sz4Sx3F3 PD8pdogzrfTURyKx6PoH0pc+O8FeI7udjl+YJ7kXWH3BFsX3j249z2eNF7FEdM+r0wKjnG+kQPRg /2XPT+Kzh33r8krzaoVqDwukMjGfEUGFWdXkbftxw/r2NV4vf6beOthJ13rto5Gz4h58R4ARdYwg LzNrg9VXTEbzOn6jnGf/aVhcaqBQ7bGxoRmR4xcM5LOHH9/CtID+GTsvgfxhrMgGPYCj284XnaHn TFxq4Lx708ibO4vYoYGPfXSdl799qi84l9ghxPtjw0Vh6thcw94fc2vK6ONNY1ICpt/Oa9ab3S14 cASfqe+5h8ptPF7L2am1SvIVUZpfRx6U36cAsJgtGz84RjwCx3noVCtemuywK0oLKzjGe8zceHu3 wgmExft0L9jQX/p269brNhpMmz45Qd5cpZYve2GS48z2opErpctemET7gbqtf5/v5AnWkGtrGw2m 5jriuPw+/cDHthfyWedr0SOj+E8zARcjkYppFREMeuFrrF9u//p8PtNcbnxstCNUeuAvLN5n1gp6 Udvzpy7y+YjCoGgeo2PqKond4j4FwKaP6Q9E8cODhk3FykHQC10QZdS5VXsAZpNl62enyJtHJvmN mBkrYHvsa+otg3rUuO8XPh0pBoXE6cjjr+oriYWq/jgA8o5UkFczkEjFi58YQ9sWXJ7KnVJD2GK2 4uqdp3YX81lQd9GjowRsjN1J5ZL596eTN885WGaDFcJdhkQqJk/GtmIPYMfXWbRdcxw3ZckgVFGG q5GrKAFg1bUhd36bTd42LTPGZWY4XjJsSjSfiTu7vqP/PRlE7m+RC5X/QQDUVbaSCz8o3GTTqPN9 AK5GZrUAqCpuzD9aQdtWKhPPu881x7nd8DC9huvBXwo6rfzR3pV4+RMDgPxh7A8C4MDGfPIAo3Hz E9w0GBQPV0U7a9001lordP/P9Do2aZmxrvHt90qRSX6xQ4kjFPVtXcd3oEx0XympC6tZKwAO/kKc +iuRiiffPIi2LTCC1m+10ogyi9lyeAt9wZnJNycL2BhHM/km+r/u4CZe5QOYQq4KZ5UAOHeyijwd ZuSsOOeqggK2R1tjy0qVNfOPVTZWt9G2TUgPtvvC6FY1eFw4+ftk/pFy8h+WNeTXm8Yu4lLV1woA PpWm+TwyAAvMJgutiqFfqFUK6x/dRl9db4qrd3ZFYtGkG5No21osHN4C9ZGhk/ggL5URk+NaAXBy VzFtpyFxOmcsgwW2dKGgjlBrUyIVW2NlFYuFIw920AWqB44MFbY9DmjkrDhyrcNTu4sFbYvL6uok PsjLFEIHQGleLbnMdHpmDG1DYMe5E5RpogERWj71Ca6mOLuaPPs3dUo0CwvDqdTyxFHEnCs4Xtne QhynyJT2FmKpc/LHg6teS1n76KtgD5+GAIA/cGIn5bVATIpVyonzOduHTWFlojv5X2o2WXIPlQnb GJdEfub28CaOjLhqAORSi/nFDglAOUy4trrK1rMnqggbDhgWJHhjOB4rTfqGeIQn+AjbGIc1eFw4 +VUD+X7CFPKEXg8dcWRE7wFg0BsLTxNrTA+ZRKzzDuyg1duRSMUJVlh9s7PDWJxdQ9uWncd/juMU brKk0WG0bfNtu5izMzLojeRRl+Rn7t4D4Pypi+TF8OKHY4FcuJa6ytZ9P+USNhw4IsTNQ/hZYOdO VpHP9qTRrv/593JJ1M8A1ReaMRj02kpya8l1rsgVd3oPAPIik2qtMijalQdEA08WC7f2uV3GLsoN 10qFNsmdXZlCEpHoasV/ri2OOiWY47dyIQvOnSRWz1aopOQaEgIHQFxqIAsjIoBs86cn8o5Q6u14 B6iHTLTK28WibOKNKSrZn7VVoP3CPMkT8ch/Z0ac2FlM2zAkTke+6/Z++pJfiVrpGx24ht835JPX 2p18U7I1BoByHFdMvTE576q/fJBXLuSzpqzLq69qLckh3nXJvwjXawA0Vre1Nupt3xRwbVvXnvrP 33bTtvUN8Ri/MFHY9nSrr2ptayIOvo4byuLjDjn2ygrqhG2JK9n5Db1uNp+x0b1MHyg/30Dbl0Qq RvV/uFJLfceXL+87vp1eD2DBgyOs9LKlspB4tnMcF5HoK2BLnAX5s0dHq6Gxuk3rhzHiPenbuvaS hkVwHCdXSvm8d+klACrOE9f/8gvztFInHZyU0WDa/UPOpo9PkPuUHMeNnBVHXi/7D1VQA0AXpCFP v3RqgZH0h7yKwgYEwJU2fniMvKJL0uhQPudhL1tWFhEviSDU/4H/03Cx7fcN+Xt+yGmsoS+wznFc QIR28eOjhWrVlcgBwOzZLldKdYFq2pSlysKGgSNCBG+SU6s437Dj6zPkzYdP5VV2oZcAIK+JGhTN 6CUB3UxGc/m5+pyDZVn7Ss+fvsh/8V6Nt2rl6ukK6ioZfVFbTpx6w3K5w8AoL1oA1FD/2q6qs8P4 wZPbyNNQPH3cBo8P59OAXgKAPBstKAozAFycxWwxdpmNXaauTlNbk761Ud9c31FT1lxT1lxR2HAh v5ZczvBKGi/lA2/N8AnWCLXDXtEfd1gOgEivM/svEDakrQDhqswmy6erdlYWNZL3MO76BJ5v3XsG gMlobqBO2CMvGQFW8tKtP9m7CUS6IM2Db8/wC7NK6f9L+JztLI93CIwkhl8tAuD/dN/9T/BYKUGl lk9aRFyk4ZKeAdBU207uuVtprT5gzeDx4UtXTbBG1Yce+JztXgx/zCR/yG24iGoQHMdx7c2dHz2z I/t3Si/qkmm3DuZ/jfQMgJb6DtqORGIRuSQpQDd3T8X8lelj5sbb5nDks53jOA3DZzv5Su9oNRgN Jil14UPXcPZE1Zpnd5LfPXbTBWkyhFh1sWcANFMvCY2XUiRGFQggkiulY+cnzFw21N3T6g/+l5DP drVWyfKIZz59/eb6Du8AYuEaZ9dwsW39e0d/35DPf1e3PD1OkFHIgvUAyAWpgXE+wZpRsweMXzBQ rVXa+NDNdeSznd3Hf47jNF4qkYizkF6etTAZABfy63Z8c+bQprPkAT+Xm7AwMSFdmKLLPQOAvHIb uUQUsCko2itxZOjg8RExKQH2KiBIXoGP8ccdsUSk1ipbGiiT+9hZG9JkNBedqc47XH5k6/mqYvpQ nx4ik/wWPjxSqL31DAB9G/Hncbf+JztwAVHJfhmLkwcMD9Z42fp5/0r6ti7aho7QePvSeKtoAUC+ wzgms8li7DIZDSZ9e1dTbXtzXUd9VWtFYX3F+YbSvFqD3ijs4bwD1Hf9c4qAZVF6BkAH9edh/MMO 9FFhVnVR9o6weJ+BI0JSM6JCB+js2Bh9O/FslylYLAJxORn1ete3E0NXcE43SFrjrXro3ZnC1tLo eR53thMji3xCAGssZktJTk1JTs2vn5zwDfFIy4wZOy/BLutI42wnI0cgudfFOO8A9QNWmBnT81c0 dhFncqIHAAQ1Zc2/fHT8109PDB4fMXXJoKhB/rY8Os52MvJbCPLfnGWhA3QrV0+3xnfWXmYC03aE ZyIgM5ssJ3YUndhRlDwmbM7dw232XghnOxm5B2A28a0QxZrxCwYufGikTGGVU67nr0j+eXBJAH9Z +0qz9pWOuz5h/sp0lVpu7cPhbCcj94EEGQfJCC9/98WPj+FZ7u3arggAM/HnkTC2OCpYz54fck/t LrnlmXHJY8KseiCc7WTkV0DkvzlTZArJxEVJs1akKlTWHW7Qc+9iMfF3RbCDgJpq299+cHPm0pQ5 dw8XS6w1TUBEnYCAs93YRfwLkO8wjJArpWPmxmcuTbHNzKorAoB6sQlYBxig2+Y1J4tzau5+ZarS 3SpLApDLOeBsNxqIfwHrxbmzC4zUjp2fMHLWADeN1V9+XtIzAMiXBD7uO6Cn1s4LHyj8urUWC2c0 mLrnv7Q1d7Y26lvqOxqq2y6WNFWVNFacryeXWLhS3uHy1+7acP9bM6xRKAJnO1kXNQBYrqHUK5lC MmXJoGFTooNj7LCeimABgGcidohEnEwh6R6W0GtRzJqy5vOnLuYcKju9p4S82OklJbm1ryxf/9hH 1wmeATjbycg9AARAD12dpt/X58sVUu8AtQ0GPvTQMwDIy+/hmQgu8Q3x8A3xGDEz1mQ05xws2/19 Tta+Uj47rCpufPvBzQ+/N0vYddhxtpORewBWepvn1Bpr2te9e2TbF6fn3pM2dl68Lcsq90xjlTsx gvBMBFeSSMXJY8LueyPz+Z9uTJ8ey2dXRWeqP3xqO60C5dUoqQGAs53cA1C62foh11m0NXV+8fe9 r961kbbeMk3PACDnM/+ePrgwv1CPO56f+OSauSGx9Bedp/eUbF17SsBWkc/21kZKHTRX0tJA/MyD HsC1nT1e+cLNP+QeKrfN4XoGgJuGWNSzqbadd2PAxUUm+f35P/PGLxhI3sO6dw8XnakWqj0422ks ZgutFCjHcbZ/ze102ps7V6/ctG9dng2O1TMAyAvdMX5JQB9J5ZKbnhxzwyPEguZmk2XNs7uEGoZP XtqQ8bO9pUHPY+VwppdS6COL2fLZC3u2fX7a2gfq+UmNfEk013dYzBasCgl9kbE4WSwWf/3KfsK2 VcWN2z4/nbk0hX8zyI87bU16k9HM7IAW8lKaHI87jOD4DJI2Gc3GLrPRYGpt1Lc0dDRWt1WVNFYV NxZmVddV8Frs93Lfv3FQLBFlLBZg7d+ruSIAqGvdWcyW1kY9yytlQ2MLxTgAABkTSURBVL9MXJRY WdSw+/scwra/fHR85Kw4/lMlyTcji4VradBrfRl9mG2uI3aAlO4yKxU1szGJVCyRihUqqbunwj/8 /yvR3FzXcWZ/6cndxWf2X+DfVf321QMaL1VaZgzP/VxNz0cYD50beX2+JuGm/wALFj06ilb406A3 CtI79vR1p5/tNW38G+CkGqn/di9BFzNxTB461ajrBtzz6rSXN908997h/CevrHl219kTVYK07Uo9 A0AqE5NXnKktb+bdHmCIRCq+6cmxtG33/JDDfyiOVCb29CWe7ZVFgq3y6nTI/3afYA9hW+LINN6q 6bcPeWn94lkrUvks4mgymt9/fGt9lVXGhvbSLPKPVH6unl9jgDlRyX60+QGdHUZBhkn4BGloG1YW NfA/upOqLCT+23WBxL+281K4yWbfmfqXrxaExNFXuWhp0L//xDZrlCDsJQB8qQFQQT0tgGVTbx1M 2/DAxgL+R/cNoZ7t59l93CGHn08wcwHQLSBC+8Qnc4ZNiSbvoTi75oc3DwnYpG69BEBAhJa2L/Jz AbAsJNZ7wLAgwoZVxY385wTQz3ZWXwEZ9EbyQJfASC9hG+NE5Erp8hcnjZkbT97D9i+zBJ8g1ksA BEUTf6Sq4kbUSQcC8pPRyV3FPA8dFE2cmVxb3mzQE9eUd2pVxY3kghzke4trEIlFS54eN2r2APIe 1vxtV3uLkDUXegkAclVSk9F8saSJX3uARYPHh9NG42QfuMDz0EFRxFuSxcKV5tXyPLozKs6uoW2o dJd5B6iFbYzTEYm4JU+PTUgPpm3eWN323esHBGxPLwHgHaAmr0hw9kQlv/YAizx93AJJN+IL+XUt PCYlcRynC9KQixPkH63gc2gnVXCc+K8OiaV/BXUlEqn4zpenkD8+/b4+P++wYC+Ceh+cFJnkR9sd m5cE8BeRSDzlinOID6TdRCKOPB204DiLjztnqf9q8l3F9ajU8jtfniKVE+fEffH3veQlOXvoPQCi kv1puys4hgAAigjqXZj/e5hIavYUnr7I2kevmrLmxhriNGAEwOVCB+gWPDCCtm31heZtnwlTFvcq ATCIGAAtDXrMBgACco/4QkEdz0NHJRNvTAa9kfxC3EkVHKN3ehAAPUy4IZE2/o3juE2fnGi4KMBc 9N4DIHqQP7nQFd4CAYGXP/HzYE0Z3/nnsUMDyUUMz/zOa6Uzp0P+9/oEa/AFuAeRiLtt1QTaIncG vfGndw7zb0Pvd3mFm4wc1/xH5gGDyIXVGqv5Pgep1PKweB/atke3nud5dCfS2WE8s5847Cp+OHHc i2vTBapn/ymVtu2hTWdL+H0A464WABzHJaQRf7CCYxX8r0lgjUJFX5yLvDzhJeSzvfpCMzuDQU/v KSFPfUAAXE3GTcnk6RE/vsV3bvBVAyBpdBhtjxYLd4SlxyIQhFgiIr91bGvu5Hl08tnOcdzRbayc 7eR/qVgiGjgiRNjGuAyJVHzjY6Np2+YdqeA5N/iql1z4QF8vf2KhxMObz1HbA+wij4rjPyM3ZrA/ uWzv0W2FPI/uFPRtXWd+J77/iR0S6O5JXH2TBQOGBQ0aS3wE4fkl4KoBIBJxKRMiaDstzatltlIK kJHf5HR18n0FJBKLBo0Np21bV9GSc7CMZwMc38FfCsg/0ODxxL8tO65/YIRYQhmJUJJTc3ovfSTC tTrdqZPpteu2f5lF3hYYZDZZyGPqjV18A4DjuNTJUeRtbbB2q31ZzJbtXxGvaJGIGzqJ/rdlRECE dvR1xDpxG94/Sj7utQIgJiVAR62WfmBjPuMLZ0O/6Nu7yNvSBtL1kJAerPEivgXKOVhWcd6VS+Ge 3ltafYE43DYuNYj8MpkpM5YNoa0bU5pXe3pPCe2g1zqeSMSNmEFZrIPjOGOX+Td0AqDPGi7SFzxS uhFHEF1OIhUPm0rv8m77wpU7Ab99Sf/Xke8hrPEOUI+Zl0DbdsMHx2gb/kHgjJwVR140dff3OcJW LgUXxmfFOzl1CGkP5D44x3GHfz0ryMxMB1R0ppo8AVjhJhuagfc/fTXjjiG0oRDkTsAfBIBviAd5 hFxne9fWtcIUrACXx2dCr0IlwCsgjuNCB+jIZSGMXWb+g7IdE5/6wyNmxCrdhYlnFnj6uI2bb9NO wB+/cpp0YxJhv922fnYKKwRAX5DX9tJ4q8gTCK404YZE8raHN5/jv0KZozm67fz5UxfJm09YSP97 smnabSm2/BLwx0caOCKEPFHNZDR/+fI+2rbAlOJs4q3TL5RYRa5XqZOjPX2IRSk4jvv21d8FbIzd GQ2mH9+iDzNPSA9mfAkwAq2vmy2/BPQpaqbfPqT/jfmvvMPlTNVLAYLa8hbyIBNyGdFeSWXiKUsG kTcvzKo+tOmsgO2xr62fnSYv/8vxu2+wbPpS23UC+nSY4VOj/cM9CQ3q9u1rB3gu2wSu7cTOIvK2 fqH0M7NX464fyGfa6lf/3M/ng7bjKM2r3fghcWwJx3GRSX7kWseM0/q5j55DnRPQz05AnwJAJBbN WkEsWcdxXFNt+4dPbTebqCtJO5WK8w371uXZuxVOhk/tEPJKMlejUEmn3ZpC3ryj1fDJX3ZYzM59 thv0xo+f2cFnuZvr7homYHtYk7k0hfZlq7+dgL4eY/i0GPLKeRzH5R+tWPeuANWrHdy5k1WvLP/Z VYcDWsnZ45XkgpoisSh6cICw7eE4btKNSVo/+tylsyeqNq85KWB7bO/7Nw5WFdOrucSnBaP6Gx/e AerRcwbQtu1XJ6CvASAScTc8PJLUnv/a8p9Trr1UwKFNZ1+/5xdMfeivzf+h3yvD4n2sMcpQppDM 4fcAu/79o3wWz7Kv49uLdn+fw2cP19+fLlRjmDX99iE26AT04wAxKQHDp9GnSnIc9/EzO86drOKz B8dkMVt+fOvQJ3/dyb8wPWuy9pWS1xjhOM56b5lHzoqLSKR3ec0my78f3VJZ6Hz1IQpPX/z4Lzv4 7GH0nAHkBXbgEu8A9ajZVu8E9C9hFj0yyk0j7397/sugN755/6+Fp+nDih1QS4N+9cpNW/6DKW/9 1tne9c2/eI2bHDaF1xPJNYjEopv/PJY8DZ7juPYWw5v3/0peQt0uqkub3nl4C5/nGHdPxfyVePwX xvQ7rN4J6N/eNd6q66kr2XfrbO9avXKTy8yXOXu88vnF3/Nck4FZn67ayWcCcGCUV3iCFZ80w+J9 +MwL4ziuvqr1rfs3dbQ6x1vBlvqON+//tbVRz2cn81emk1dWgB50geoRM4mVlPrYCeh3vIyZG588 hr58Esdx+rau1fdtcvabprHL/MObh169cwOKntKse+fIiZ3FfPYwalacQG25qnn3pfOcZ1B2tv5f f3KCk6SuouWfy37mk8ccxyWODBkzl15PCa40446htHUC+tgJoPQvbvvreI23irDhJR2thtUrN239 zFlfmxRn17x0y49b156yOPdgP7v58a1Dv356gs8epHJJuvXLTCpU0qXPTuDzIojjuLKCupfv+Lm6 1HFropSdrX/5jp/Jc/G6uWnkt/51gkAtgv/yCdaMmEF80OlLJ4ASABpv1e1/m8jzqrCYLT+sPvTh U9v5r+dnSx2thq/+uf8fS38qP1dv77Y4pY5Ww/tPbOP/yWTCwoF8ajb0XUxKwPQ7+M5oratoefmO nx3zzWf+0Yp/rVjPv4+y5OlxWl9b/CKsmbFsiPU6AcQqWokjQ2bfKcBEj6Nbz7+45EenGDBnNln2 /pj7l/nf7Po2Gw/+NDkHy15c8uPx7fR5v93kSmnmbfS5Wv113Z3D4ofzHW7U2qh/Zfn6zWtOOs4c MbPJsuH9Y6/f8wv/rxSTbkzis6QaXINviEf6dGt9CaCXUZyxbCh50eDLVRU3vnrnhjXP7uL59cl6 LBbuxI6i5xZ///lLe1HTgqb8XP27j2xZfd8mnm+Zu2UsTub5ErJfRGLR8hcz+D/emozmn94+/Nrd Gx1hqmBtecsry3/e+OEx/oEUmeS34EFeY0Pg2mYsGyoSUzsB11wxmB4AIhF3x3MThRrwe2BjQffD Nf8FvgVkNlmO/Vb4/OLv33t8mzOO6ba7rk7TiZ3Fr9+98bkbvz+1m7hqXQ/+4Z4zltm6ypjGW3Xv 65mCrD1ZcKzyuRu/2/lNNp9CC3wYDabfvsh6/qbvC7MEeCXlHaC+59VpAlbkhiv5hXqkZcbQtt34 wbVWDOZ1QivcZCtXT3/5jnW15fSSgZe0N3d+9c/9Gz88lrE4efzCRD4TDvhra+rcvz5v5zfZrlHY y8aqS5vOnazKPlCWta+ks0PIbzwisej2v00U5EbcX2HxPstfzPj3o1v4vwBsbzF8/cr+7V9lzb1n eOqUaJ6f0/rOYuEObz7787tH6iqFOasVbrL73sj00NmuN8asmcuGHt58jtBdK8mtPb23dNDY3odu 8r2QPHSqB96eKchHpG4tDfp17x75dc3JMXPi02fEWnWg95VMRnPOwbIDGwtO7iq21wOa47NYOFOX qctgMnaZ25s7Wxo6Whr0DRdbL5Y0VRU3lJ+rb2mw1tu8zKUpkUnERbv4Gzw+fPETY778hzBLXNSU NX/41PYta091v0C3aqoZ9Maj285v/zKr7KxggxekMvHdr0wNjvEWaodwDf7hnsOnRtPKJm784OjV AkBkEeKDZvd7/OY64d+P+4Z4pE6OSp0cZdXJ5e0thvwj5Sd2FZ/eU8L/g9isFamz76QXT+3VgxPW OMt8IusZNC78nn9Npb0MFdDmNSd/elvgyoYqtTx9RuzYeQkhsQLfT8sK6vb8mHt48zlhzx+xRHTn y1ME+QrIH+3qeGrtPD4FLm2vqrjx2YXf0m7Y976e2WsGCPPQERChfeT92a/dtVHwCS81Zc2b15zc vOakp49b9GD/qGT/6EH+YfE+tKWTL9dY3VZ0prrwTPXZ45XFOTWOMzYDehU+0HfFSxl2v/tzHJe5 NKWr08SnVv6VOloNu77N3vVtti5QnZAeEj88OD4tWONFnFLb0qDPO1yee7gs91C5Nd5hiiWi2/82 0UHu/uwIiNAOmxp9ZAtlfa2rdQIE63UGRGif+GTO6pWbrLQIcFNt+/HtRd0jCCVScUCEVheo1gVp dIEanyCN1s9drpRe/p9IJDIZzcYuk76tq625s61J31jTVl/VWlfRWlnUUFHY0N7caY12gjX4hXmu fEOYb7CCmH1nqlwptcYq8HWVrfvW5XUvKeEb4hEQofUL8wwI1/qFebp7KBRuMoVKqnSTyRTSrk6j vr2rs8PY2d7V1txZXdpUVdJYXdpUVdwoyFCrq5FIxSteyhgyKdJ6h4Crmbk89ejW84ROwNW+BAh5 RemCNI9/POedhzYLMrrgGkxGc/m5ekzFYkT4QN+Vq6eTH4etZNptg1Vq+Zcv77Ne37GmrNmqt3IC hUp658tTEkeF2rshjAqM1KZOjj66TbBOgMCDt9Ra5SPvzyZXMQXoIXFkyCPvz3a0u3+3cdcn3Pva NIWb8AsSOCatr9tjH83B3d++Zi4fStuwuxPQ438UfvSuVC65bdX4Gx8bzebQ4PQZsRMX8SohCZdM WTLo3tczFSpHefNzpeQxYY9/PEcXpLF3Q6wuItH3z2vnhw7Q2bshrAuK9iJPur5yToC17tETFyU+ uWYun6XknY5viMdD786847mJKIfLn6eP24PvzFzw4AjHf4wIifV+5ovrB48Pt3dDrGjCwsTHPpqD Uj8OQsBOgBWvrrB4n2e+uH78goHWO4SDkEjFmUtTVn2zMD4t2N5tcQVpmTF//XpBQrrT/DHdNPJ7 Xp12wyMjZQq+g9Mcjbun4k//mLz4idFSmaMnMTuCY7zJH+F7dAKs27mWK6U3PTkmLTPm8xf3VBbR 15h2ZEMzIufek8ZUX8d6ogb53/DwSDtO9eIjY3Fy0qiwT1ftdMyqnwSDxoYteXqcbaquQr/MWpF6 YgelqGKP4UC2eLsakxLwzJcLdnydtenjE640myk+LXj+ynQbz1V2VSFxuum3p1hviUfb8A/3fPzj Obu/z1n/3pH2Fic+1bV+7gsfGuHsP4cLC4n1TpkQcXJXMWHby4cD2ejzmlQmnnrL4FGzB/zy0fE9 P+QYu5y7ykLUIP85dw3DCx/+RGLR4HHhGYuT41ID7d0WYYgloomLEodPi173zpH96/PMJiebYChT SDIWJ89YNtSRv70Dx3GzVqTSAuDyToBNf2O1Vrno0VHTbkvZuvbU3p9ynWspGI7jJFLx0IzIyTcN ikh0phnkjil8oG9qRtSwqdG6QLW92yI8tVa55OmxU28dvOH9o0e2nHOKBSQkUvHoOQNmLk/Fx16n EDpAN3h8OK3I7qVOgB1CXuvrdsMjI2csG7L3p9w9P+Q6RblNtVY5Zm78xEVJuDb4ULrLogf5J6SH DM2Icsn7fg9+oR7LXpg0c/nQ377IOvBLgdHgQKXOL6d0l42ZG5+xONk7wPV/FFcya0UqLQAudQLs 1stTa5XTbx+SeVtK1v4Lv2/Iz9pX6oCXh1wpTZkQMXxaTOLIEMcfj+iAZAqJf5hnYJRXVLJ/TEpA aJzOEYr52FhAhHbJ02Pn3DN8/895+9fnO9TiwCGx3qPnxI+cFadS27P6OtCExfsMGht27SVfrqa7 E2Dn13wisWjQ2LBBY8M6Wg3Htxed3FWUe7jc7mvCKFTShPSQYVOiB48Pd5z6M45GKpfI5BKpTCyV S2QKqbuHwkOn8vB203grPXVuuiBNYKSXLkhjs2L3Dk7jpcxcmpK5NOXcyarDm8+d2Flkjeq5feQd oB4yKTJ9uq3LrYPgZq1IpQVAdydAmHLQAjLojflHK3IPlRccrygrqLNZ6yRScWSSX0JacHxacGSS H573waosFu78qaoz+y/kHCorzau1QTFasUQUmeSXkBaSPCYMH7Ggm8MFwOU6Wg1FZ6pLcmsu5Ndd KKirLW8WcEyFVC4JivIKidWFxHmHxOoiEv0w7AHsor3FcP5UVXF2TXFO9YX8OgFrqnv5u4fG6SIS /SKT/KKS/ZXurJQtgj5y6ADowWQ015Q1V19orq9saaxpb6xpa67vaG/u7Gg1dLQaDHqjyWju/k8i FcsUEplCKu/+v0qpxlvl5efu5eeu9XP38nP3DtT4hXrgMR8cUEeroaq4sbq0qb6qtaG6raG6ra1J 397c2d5iMOiNxi6TyWg2myxiiUgiFUtlErlS6qaRu3ko3D2VXn7uXv7u3gFq/zBtYKSWnUJ1QONM AQAAAALCIzAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAA jEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAA AKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEA AMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIA AAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQ AAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAo BAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAw CgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAA jEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAA AKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEA AMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIA AAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQ AAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAo BAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAw CgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAA jEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAA AKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEAAMAoBAAAAKMQAAAAjEIAAAAwCgEA AMAoBAAAAKMQAAAAjEIAAAAwCgEAAMCo/wd+9O2cMtqRwAAAAABJRU5ErkJggg== --000000000000faad3d05a6f45a38-- From nobody Sun May 31 09:45: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 DAB963A09E1 for ; Sun, 31 May 2020 09:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=noctarius.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 U5NFuVaSSqch for ; Sun, 31 May 2020 09:45:24 -0700 (PDT) Received: from mail2.i-styledesign.de (mail2.i-styledesign.de [IPv6:2a01:4f9:2a:723:8000::104]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697593A09E0 for ; Sun, 31 May 2020 09:45:24 -0700 (PDT) Received: from mail2.i-styledesign.de (localhost.localdomain [127.0.0.1]) by mail2.i-styledesign.de (Proxmox) with ESMTP id D07792809FA; Sun, 31 May 2020 18:45:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=noctarius.com; s=default; t=1590943520; bh=EEGFZs7auRpP60KmpJ5Ah9Wc5QeBgVqtp+Ghl42D7sk=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=hMkfWALZq2uvm7x2/MFimKBXPInBqPVSTYBH5rhyNCte6NJkzHEh5SzKR6veC6L+F dGQ5rqLnl8IW7u2QfUnaVjEpPk1NQMMb86ZXX/i6TM7N3pWiBxiVNPXvotKotwJRE4 IYPopODKBD0UhQmcTK0VQvvrZ5BNeIp0qVlV6fIOnhFLhAPVZsfRAAmyyiz+Fey7sm Po5yd5OYXEKmD2eg6LJz9GMJG8uIAaaN6ViTEYN246QY8HcFQWeM7LxOtkwETx4KaT GqoUQiMhwXQcAvE4lOjwnmQ9jLA3xMlnL936Ltjs3vb0lr2BmoKZ70XKB/MU/kJeZl osQ6UdAXEnmuw== Received: from inner.mail2.i-styledesign.de (unknown [192.168.63.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.i-styledesign.de (Proxmox) with ESMTPS id 17E48280792; Sun, 31 May 2020 18:45:19 +0200 (CEST) Received: from [IPv6:2a02:908:113a:b760:c917:7be5:6d06:9149] (unknown [IPv6:2a02:908:113a:b760:c917:7be5:6d06:9149]) (Authenticated sender: me@noctarius.com) by inner.mail2.i-styledesign.de (Postfix) with ESMTPSA id B280B5D3600; Sun, 31 May 2020 18:45:18 +0200 (CEST) From: Christoph Engelbert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_290F6BC5-77B8-48FF-8324-3D08A06DEA6F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 31 May 2020 18:45:17 +0200 In-Reply-To: Cc: Carsten Bormann , cbor@ietf.org To: Jonathan Beri References: <124C2398-BBAB-47FB-B0C8-E6D7A04A3670@tzi.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] CBOR logo experiment 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, 31 May 2020 16:45:28 -0000 --Apple-Mail=_290F6BC5-77B8-48FF-8324-3D08A06DEA6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey folks, In a past presentation I loved to explain CBOR that way: = https://www.slideshare.net/ChristophEngelbert/cbor-the-better-json#30 = Maybe that gives some directional idea ;-) Cheers, Chris PS: Yeah those are the Simpsons. Blocky but definitely recognizable :D > On 31. May 2020, at 18:41, Jonathan Beri wrote: >=20 > No apologies necessary! I thought of this as an experiment.. The = inspiration came from wanting to create an icon for the new subreddit = I created. I wanted something with the = visual flair usually found on the site. The basic meaning I was trying = to convey >=20 > 1) a compressed packet, which includes data as visualized by the = little bits of characters > 2) transmission or movement of data >=20 > and I wanted to use web-safe fonts and CSS so it could be used in many = places, though I did need a PNG for Reddit. I too agree that a good logo = design requires a certain type of genius - and unfortunately I don't fit = the bill. And as I stared at the logo I think it connotes data = corruption as someone else mentioned and not the type of messaging we = want. Experiment 1 marked as a success - will not use. I think for now = the wordmark on cbor.me works for me. I generated a = new PNG logo for Reddit using https://htmlcsstoimage.com/ = : > >=20 > Hopefully someone might improve the design one day! >=20 > Thanks for the feedback :) >=20 > On Sat, May 30, 2020 at 6:13 PM Carsten Bormann > wrote: > Hi Jonathan, >=20 > > On 2020-05-30, at 19:21, Jonathan Beri > wrote: > >=20 > > >=20 > (Insert apologies if, at this time of the day, my autopilot is = automatically switching into prof-talks-to-student mode here. I=E2=80=99v= e been chided for that before. Then mix in the Whitsunday mood=E2=80=A6) >=20 > So what is the message that you are trying to convey with this logo? > Let me try to guess through the eyes of a random instance of a persona = looking at data representation formats. >=20 > We have the base form of the logo, which looks like some old-fashioned = (or really, outdated?), 1950=E2=80=99s, FORTRANy thing; black and white = of course. > It seems that ancient logo bequeathed from the ancestors then has = incurred some damage through transmission errors and looks a bit = unstable now. Needs lots of cleanup before use. > Not good for the squeaky clean product (security, banking, =E2=80=A6) = I=E2=80=99m building right now. >=20 > To provide some contrast, let me do a quick proposal for a list of = branding properties that a CBOR logo maybe should convey (or at least = not actively counteract): >=20 > =E2=80=94 stable > =E2=80=94 efficient, concise, =E2=80=A6 (I think that=E2=80=99s where = the image is closest) > =E2=80=94 and related to that: somewhat minimal, but not simpler > =E2=80=94 approachable, friendly, easy to use > =E2=80=94 open for new business (extensible, with low ceremony for = that) >=20 > It probably would require a genius to convey all of these properties = in one logo. > I=E2=80=99m not that genius, so for cbor.me I = settled with the same basic idea you used (just say CBOR), and just = threw in the font Palatino and the color #663399 (please excuse my rusty = HTML if you do examine the site). > That=E2=80=99s where I stopped=E2=80=A6 >=20 > Yes, it requires a lot of background to even see in what ways that is = actually somewhat minimal (history questions: What is (was) minimal = about #663399 [1]? What is (was) almost minimal about Palatino [2]?). >=20 > So I=E2=80=99d love to see if someone came up with something better. >=20 > If you are looking for something completely different: we also have = Stefanie Gerdes=E2=80=99 design for a sea boar [3]. But that is maybe = more of a mascot than a logo. I=E2=80=99d like that in plush. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > PS.: Here are the answers for the two history questions, and a pointer = to the sea boar, in case you care: >=20 > [1]: https://en.wikipedia.org/wiki/Web_colors#Web-safe_colors = > [2]: https://en.wikipedia.org/wiki/PostScript_fonts#Core_Font_Set = > [3]: http://www.tzi.de/~cabo/sea-boar.png = >=20 >=20 >=20 > --=20 > Jonathan Beri > linkedin.com/in/jonathanberi = > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_290F6BC5-77B8-48FF-8324-3D08A06DEA6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hey = folks,

In a past = presentation I loved to explain CBOR that way: https://www.slideshare.net/ChristophEngelbert/cbor-the-better-j= son#30

Maybe= that gives some directional idea ;-)

Cheers,
Chris

PS: Yeah those are the Simpsons. Blocky but definitely = recognizable :D

On 31. May 2020, at 18:41, = Jonathan Beri <jmberi@gmail.com> wrote:

No apologies necessary! I thought of this as an experiment.. = The inspiration came from wanting to create an icon for the new subreddit I created. I wanted something with the visual = flair usually found on the site. The basic meaning I was trying to = convey

1) a compressed packet, which includes data as visualized by = the little bits of characters
2) = transmission or movement of data

and I wanted to use web-safe fonts and = CSS so it could be used in many places, though I did need a = PNG for Reddit. I too agree that a good logo design requires a certain = type of genius - and unfortunately I don't fit the bill. And as I stared = at the logo I think it connotes data corruption as someone else = mentioned and not the type of messaging we want. Experiment 1 = marked as a success - will not use. I think for now the wordmark on cbor.me works = for me. I generated a new PNG logo for Reddit using https://htmlcsstoimage.com/:
<image.png>

Hopefully someone might improve the design one day!

Thanks for the feedback = :)

On Sat, May 30, 2020 at 6:13 PM Carsten = Bormann <cabo@tzi.org> wrote:
Hi Jonathan,

> On 2020-05-30, at 19:21, Jonathan Beri <jmberi@gmail.com> wrote:
>
> <image.png>

(Insert apologies if, at this time of the day, my autopilot is = automatically switching into prof-talks-to-student mode here.  = I=E2=80=99ve been chided for that before.  Then mix in the = Whitsunday mood=E2=80=A6)

So what is the message that you are trying to convey with this logo?
Let me try to guess through the eyes of a random instance of a persona = looking at data representation formats.

We have the base form of the logo, which looks like some old-fashioned = (or really, outdated?), 1950=E2=80=99s, FORTRANy thing; black and white = of course.
It seems that ancient logo bequeathed from the ancestors then has = incurred some damage through transmission errors and looks a bit = unstable now.  Needs lots of cleanup before use.
Not good for the squeaky clean product (security, banking, =E2=80=A6) = I=E2=80=99m building right now.

To provide some contrast, let me do a quick proposal for a list of = branding properties that a CBOR logo maybe should convey (or at least = not actively counteract):

=E2=80=94 stable
=E2=80=94 efficient, concise, =E2=80=A6 (I think that=E2=80=99s where = the image is closest)
=E2=80=94 and related to that: somewhat minimal, but not simpler
=E2=80=94 approachable, friendly, easy to use
=E2=80=94 open for new business (extensible, with low ceremony for = that)

It probably would require a genius to convey all of these properties in = one logo.
I=E2=80=99m not that genius, so for cbor.me I settled = with the same basic idea you used (just say CBOR), and just threw in the = font Palatino and the color #663399 (please excuse my rusty HTML if you = do examine the site).
That=E2=80=99s where I stopped=E2=80=A6

Yes, it requires a lot of background to even see in what ways that is = actually somewhat minimal (history questions: What is (was) minimal = about #663399 [1]?  What is (was) almost minimal about Palatino = [2]?).

So I=E2=80=99d love to see if someone came up with something better.

If you are looking for something completely different: we also have = Stefanie Gerdes=E2=80=99 design for a sea boar [3].  But that is = maybe more of a mascot than a logo.  I=E2=80=99d like that in = plush.

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

PS.: Here are the answers for the two history questions, and a pointer = to the sea boar, in case you care:

[1]: https://en.wikipedia.org/wiki/Web_colors#Web-safe_colors [2]: https://en.wikipedia.org/wiki/PostScript_fonts#Core_Font_Set
[3]: http://www.tzi.de/~cabo/sea-boar.png



--
Jonathan Beri
linkedin.com/in/jonathanberi
_______________________________________________
CBOR = mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor

= --Apple-Mail=_290F6BC5-77B8-48FF-8324-3D08A06DEA6F--