From nobody Fri Nov 3 13:24:29 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E1C13FF85 for ; Fri, 3 Nov 2017 13:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1MrZLvozcdj for ; Fri, 3 Nov 2017 13:24:25 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC8313FF97 for ; Fri, 3 Nov 2017 13:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vA3KOLWb018632 for ; Fri, 3 Nov 2017 21:24:22 +0100 (CET) Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yTD2F4wyKzDXcQ; Fri, 3 Nov 2017 21:24:21 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Fri, 3 Nov 2017 21:24:20 +0100 X-Mao-Original-Outgoing-Id: 531433460.402557-6a3f315e2d486d8cd26d900cc0bf6d80 Content-Transfer-Encoding: quoted-printable Message-Id: <43C3FA56-316E-45DF-A231-D36431712B9C@tzi.org> References: To: cbor@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Cbor] More formal definition of CDDL matching rules X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 20:24:28 -0000 On Jul 18, 2017, at 20:43, Kevin Braun wrote: >=20 > I know the question of more formally specifying validation rules = already came up. I have started writing up the matching rules, piece by piece motivated = by the syntactic elements of the language. = https://cbor-wg.github.io/cddl/matching/draft-ietf-cbor-cddl.html#rfc.appe= ndix.B The new text is not yet finely honed yet; at this point I=E2=80=99m = mainly interested to hear whether the approach goes into the right = direction. My plan is that we could have a -01 with an editorially combed version = of this by November 11. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Nov 3 17:34:26 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088FD13FF6A for ; Fri, 3 Nov 2017 17:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 3dyMJqpylHOZ for ; Fri, 3 Nov 2017 17:34:23 -0700 (PDT) Received: from mail4.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 0157813FEF5 for ; Fri, 3 Nov 2017 17:34:22 -0700 (PDT) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1509755659; h=from:subject:to:date:message-id; bh=ebepsmichb7MDSIPwwAzKvmC2lNcxAv728rQerWjWQU=; b=YH4TKVqblIP/jV1YOo+EtFNZiDDljZyX4eiTFCMLQwRrGVAU7Cd/D/msVYxJxwM0CtJC8/WO0+R M0Dsp13r172kIF/0XnhqetEb0L0UpEP3bfK5UXBEnWOJ1O10puaP6vg9lOo74nGztpdR8Akcl8nnA 42+2uvljOxQk6FPm1+t4QVR3kX9vs3tDEQkuUW6tkLwCW9YyX2kLgZSgr9sxEqYIEtODMzVt/Yx7T vvOlro9m3dhsFcjUR6OldI3+h83bZiHgqfeMRB7oY8h3WenzYjc0XW1bJUf4deH+GUjwpNKejZ4tX okNl5h0E9uA5510zqHwNi4UewuFBS2wQkKEQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Nov 2017 17:34:18 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Nov 2017 17:33:16 -0700 From: Jim Schaad To: 'Carsten Bormann' , References: <43C3FA56-316E-45DF-A231-D36431712B9C@tzi.org> In-Reply-To: <43C3FA56-316E-45DF-A231-D36431712B9C@tzi.org> Date: Fri, 3 Nov 2017 17:34:13 -0700 Message-ID: <002601d35504$a56b0200$f0410600$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGj3fF8wyHPCFZvH3Ek15yu4fStEgFUitzto1enQwA= X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Cbor] More formal definition of CDDL matching rules X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 00:34:25 -0000 My first answer, having tried to read it and not managed it, is that = this is a really bad approach. As a consumer of CDDL, I do not care = what the ABNF is and how that is implemented. What I want to know is = for a FOO operation, what are the rules that I should expect. If this = is just supplementary information that is covered in the main document = it is fine. Jim > -----Original Message----- > From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Friday, November 3, 2017 1:24 PM > To: cbor@ietf.org > Subject: [Cbor] More formal definition of CDDL matching rules >=20 > On Jul 18, 2017, at 20:43, Kevin Braun wrote: > > > > I know the question of more formally specifying validation rules = already came > up. >=20 > I have started writing up the matching rules, piece by piece motivated = by the > syntactic elements of the language. >=20 > https://cbor-wg.github.io/cddl/matching/draft-ietf-cbor- > cddl.html#rfc.appendix.B >=20 > The new text is not yet finely honed yet; at this point I=E2=80=99m = mainly interested to > hear whether the approach goes into the right direction. >=20 > My plan is that we could have a -01 with an editorially combed version = of this > by November 11. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Fri Nov 3 19:33:52 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B5613FB04 for ; Fri, 3 Nov 2017 19:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 QVyeziFQr37k for ; Fri, 3 Nov 2017 19:33:47 -0700 (PDT) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9289313FB05 for ; Fri, 3 Nov 2017 19:33:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2G8BABp299Z/xoHYZleGQEBAQEBAQEBAQEBBwEBAQEBg11kA2snB4NzmVGBSwkighCWMQoYC4UYAoQ/QxQBAgEBAQEBAQEDaCiCakYsAQEBAQEBAQEBTAINMSwBAQEEAQEhDwEFNhcECQIRBAEBAQICIwMCAicfAQgIBg0GAgEBihkBBAyNe51ngieLPAEBAQEBAQEDAQEBAQEBAQEBGgWBDoIfggeBUYFqKwuCdIVRggo9gmEFoUSBCIEmhTCPIIlJBSSHCpU+AgQGBQIZAYE5NiKBDlMmXYcedYkVLIEFAYEQAQEB X-IPAS-Result: A2G8BABp299Z/xoHYZleGQEBAQEBAQEBAQEBBwEBAQEBg11kA2snB4NzmVGBSwkighCWMQoYC4UYAoQ/QxQBAgEBAQEBAQEDaCiCakYsAQEBAQEBAQEBTAINMSwBAQEEAQEhDwEFNhcECQIRBAEBAQICIwMCAicfAQgIBg0GAgEBihkBBAyNe51ngieLPAEBAQEBAQEDAQEBAQEBAQEBGgWBDoIfggeBUYFqKwuCdIVRggo9gmEFoUSBCIEmhTCPIIlJBSSHCpU+AgQGBQIZAYE5NiKBDlMmXYcedYkVLIEFAYEQAQEB X-IronPort-AV: E=Sophos;i="5.43,368,1503352800"; d="scan'208";a="1245674" Received: from mail-mtas26.fraunhofer.de ([153.97.7.26]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2017 03:33:41 +0100 X-IronPort-AV: E=Sophos;i="5.44,339,1505772000"; d="scan'208";a="654759" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaS26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2017 03:33:40 +0100 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id vA42Xalf008368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 4 Nov 2017 03:33:38 +0100 Received: from [192.168.16.50] (134.102.43.163) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 4 Nov 2017 03:33:31 +0100 To: References: <43C3FA56-316E-45DF-A231-D36431712B9C@tzi.org> <002601d35504$a56b0200$f0410600$@augustcellars.com> From: Henk Birkholz Message-ID: <85e2f8df-9213-f833-82cd-10834dafbc85@sit.fraunhofer.de> Date: Sat, 4 Nov 2017 03:33:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <002601d35504$a56b0200$f0410600$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [134.102.43.163] Archived-At: Subject: Re: [Cbor] More formal definition of CDDL matching rules X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 02:33:51 -0000 Hi Jim, I think there are distinct advantages to include this content as an appendix. There most certainly is demand for the capability to check if a cbor message matches a certain CDDL data definition via a general function. And this section will be enable readers to create corresponding match functions. True, it is not of interest to every consumer of the document, but it has that distinct purpose and maybe we just have to highlight that purpose more explicitly? Viele Grüße, Henk On 11/04/2017 01:34 AM, Jim Schaad wrote: > My first answer, having tried to read it and not managed it, is that this is a really bad approach. As a consumer of CDDL, I do not care what the ABNF is and how that is implemented. What I want to know is for a FOO operation, what are the rules that I should expect. If this is just supplementary information that is covered in the main document it is fine. > > Jim > > >> -----Original Message----- >> From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten Bormann >> Sent: Friday, November 3, 2017 1:24 PM >> To: cbor@ietf.org >> Subject: [Cbor] More formal definition of CDDL matching rules >> >> On Jul 18, 2017, at 20:43, Kevin Braun wrote: >>> >>> I know the question of more formally specifying validation rules already came >> up. >> >> I have started writing up the matching rules, piece by piece motivated by the >> syntactic elements of the language. >> >> https://cbor-wg.github.io/cddl/matching/draft-ietf-cbor- >> cddl.html#rfc.appendix.B >> >> The new text is not yet finely honed yet; at this point I’m mainly interested to >> hear whether the approach goes into the right direction. >> >> My plan is that we could have a -01 with an editorially combed version of this >> by November 11. >> >> Grüße, Carsten >> >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > From nobody Fri Nov 3 22:02:03 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4F513FB37 for ; Fri, 3 Nov 2017 22:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 fNxgHZR2GnU4 for ; Fri, 3 Nov 2017 22:02:00 -0700 (PDT) Received: from mail4.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 8628E13FB15 for ; Fri, 3 Nov 2017 22:02:00 -0700 (PDT) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1509771715; h=from:subject:to:date:message-id; bh=PrHb59tgW8Sjj3u+9mCD3b7fjpj0TAYXRlW8XAcLgkw=; b=BxYB7J/plCfD/aiU5McU+ErAO46E/MJskZ99TYwSzY2NW/amjY6pwnhUnIZwn+v5ghnT2DEfwHj TqrAL+aZdSi5RSziRuCr4kCVJZCvqnmD1hVwEpXVhmNeD70QeiTFQ6EiY3vKZmhHHD37HIVds0ZeP Jlk+PgIJMOvAjhptcwTp57vriRSnMZGWzMLsfFWqkMTpml/WHxy0gDbXIB4vLe0sYjtQliqRcAMu9 W9IfWDlBUxFX+35fxxJFr+o+FEcMTRITRTGh7qad5S3BTxVkw5Vbbp3TADSSJ1kTksD32nXcGLpHd uFzN5WU0ykILcAhhAKyj45FOtsh6bGJc0IFQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Nov 2017 22:01:55 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Nov 2017 22:00:52 -0700 From: Jim Schaad To: 'Henk Birkholz' , References: <43C3FA56-316E-45DF-A231-D36431712B9C@tzi.org> <002601d35504$a56b0200$f0410600$@augustcellars.com> <85e2f8df-9213-f833-82cd-10834dafbc85@sit.fraunhofer.de> In-Reply-To: <85e2f8df-9213-f833-82cd-10834dafbc85@sit.fraunhofer.de> Date: Fri, 3 Nov 2017 22:01:50 -0700 Message-ID: <002901d3552a$07bed290$173c77b0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGj3fF8wyHPCFZvH3Ek15yu4fStEgFUitztAhM/iHAB0w3ixKM4wRtw X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] More formal definition of CDDL matching rules X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 05:02:02 -0000 > -----Original Message----- > From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Henk Birkholz > Sent: Friday, November 3, 2017 7:34 PM > To: cbor@ietf.org > Subject: Re: [Cbor] More formal definition of CDDL matching rules >=20 > Hi Jim, >=20 > I think there are distinct advantages to include this content as an = appendix. > There most certainly is demand for the capability to check if a cbor = message > matches a certain CDDL data definition via a general function. And = this section > will be enable readers to create corresponding match functions. >=20 > True, it is not of interest to every consumer of the document, but it = has that > distinct purpose and maybe we just have to highlight that purpose more > explicitly? This is where I would explicitly disagree. The matching rules are of = interest to EVERY reader of the document. The implementation details = about how to do an ABNF match is of interest only to the people who want = to implement a CDDL matcher. Jim >=20 > Viele Gr=C3=BC=C3=9Fe, >=20 > Henk >=20 > On 11/04/2017 01:34 AM, Jim Schaad wrote: > > My first answer, having tried to read it and not managed it, is that = this is a > really bad approach. As a consumer of CDDL, I do not care what the = ABNF is > and how that is implemented. What I want to know is for a FOO = operation, > what are the rules that I should expect. If this is just = supplementary > information that is covered in the main document it is fine. > > > > Jim > > > > > >> -----Original Message----- > >> From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten > >> Bormann > >> Sent: Friday, November 3, 2017 1:24 PM > >> To: cbor@ietf.org > >> Subject: [Cbor] More formal definition of CDDL matching rules > >> > >> On Jul 18, 2017, at 20:43, Kevin Braun wrote: > >>> > >>> I know the question of more formally specifying validation rules > >>> already came > >> up. > >> > >> I have started writing up the matching rules, piece by piece > >> motivated by the syntactic elements of the language. > >> > >> https://cbor-wg.github.io/cddl/matching/draft-ietf-cbor- > >> cddl.html#rfc.appendix.B > >> > >> The new text is not yet finely honed yet; at this point I=E2=80=99m = mainly > >> interested to hear whether the approach goes into the right = direction. > >> > >> My plan is that we could have a -01 with an editorially combed > >> version of this by November 11. > >> > >> Gr=C3=BC=C3=9Fe, Carsten > >> > >> _______________________________________________ > >> CBOR mailing list > >> CBOR@ietf.org > >> https://www.ietf.org/mailman/listinfo/cbor > > > > _______________________________________________ > > CBOR mailing list > > CBOR@ietf.org > > https://www.ietf.org/mailman/listinfo/cbor > > >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Sat Nov 4 02:25:08 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5765F13FB88 for ; Sat, 4 Nov 2017 02:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tys9FtehMQIf for ; Sat, 4 Nov 2017 02:25:03 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D14F13FB31 for ; Sat, 4 Nov 2017 02:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vA49OoSm010075; Sat, 4 Nov 2017 10:24:51 +0100 (CET) Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yTYLp4yZGzDXjB; Sat, 4 Nov 2017 10:24:50 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <002601d35504$a56b0200$f0410600$@augustcellars.com> Date: Sat, 4 Nov 2017 10:24:47 +0100 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 531480287.739737-95bc5b96ba81671a8d6fd419dec35ac9 Content-Transfer-Encoding: quoted-printable Message-Id: <85BA5F43-50BF-4216-AB08-D4E32A1C26A6@tzi.org> References: <43C3FA56-316E-45DF-A231-D36431712B9C@tzi.org> <002601d35504$a56b0200$f0410600$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] More formal definition of CDDL matching rules X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 09:25:06 -0000 Hi Jim, thank you for the very quick feedback. The appendix uses the ABNF just as a reminder of the structure of a CDDL = specification =E2=80=94 I couldn=E2=80=99t come up with a more succinct = way. But the information is in the text, not the ABNF =E2=80=94 that is = just a repeat of Appendix D. > On Nov 4, 2017, at 01:34, Jim Schaad wrote: >=20 > My first answer, having tried to read it and not managed it, is that = this is a really bad approach. As a consumer of CDDL, I do not care = what the ABNF is and how that is implemented. =20 The text is not about implementation (although you can indeed implement = it from the text), but about the language semantics. (I understand it may be a bit confusing to discuss a language that is in = effect notating a (tree) grammar by going along the (string) grammar of = the (tree) grammar language.) > What I want to know is for a FOO operation, what are the rules that I = should expect. If this is just supplementary information that is = covered in the main document it is fine. It should already be covered in the main document, but the exact way the = matching is supposed to be done has to be inferred from the text (and we = have got feedback that the inference may not be obvious). So we thought = it might be a good idea to summarize the matching rules once more in the = appendix. Gr=C3=BC=C3=9Fe, Carsten >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten = Bormann >> Sent: Friday, November 3, 2017 1:24 PM >> To: cbor@ietf.org >> Subject: [Cbor] More formal definition of CDDL matching rules >>=20 >> On Jul 18, 2017, at 20:43, Kevin Braun wrote: >>>=20 >>> I know the question of more formally specifying validation rules = already came >> up. >>=20 >> I have started writing up the matching rules, piece by piece = motivated by the >> syntactic elements of the language. >>=20 >> https://cbor-wg.github.io/cddl/matching/draft-ietf-cbor- >> cddl.html#rfc.appendix.B >>=20 >> The new text is not yet finely honed yet; at this point I=E2=80=99m = mainly interested to >> hear whether the approach goes into the right direction. >>=20 >> My plan is that we could have a -01 with an editorially combed = version of this >> by November 11. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 >=20 >=20 From nobody Sat Nov 4 04:20:44 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889F113FB17 for ; Sat, 4 Nov 2017 04:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: OpenSSL error: too long)" header.d=uni-bremen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5K206NpEmRPD for ; Sat, 4 Nov 2017 04:20:40 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702C313FB09 for ; Sat, 4 Nov 2017 04:20:39 -0700 (PDT) Received: from [192.168.1.5] (x4e33a751.dyn.telefonica.de [78.51.167.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 27E21204EF for ; Sat, 4 Nov 2017 12:20:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-bremen.de; s=dkim; t=1509794437; bh=at0P9fJ7Px5yZOLS+hMQ1N6PiiI0CTrxQtKNJGJwt9M=; h=To:References:From:Date:In-Reply-To; b=ADQRouHh44ivyyLx8UU9yxLruol/+kdOJGEY3DW7Zcbw4QLyJAie/IxM+dZyB/jRO TZ938wnmJvoL66HqbFkSG4UmvT77Wq+3F7fkyzOcheqR2Jiwyo2CSxy1u9wDYJ5NEQ CkNY62mAELBUpwgZX8QS+7qE9OBcyTEt7Cbqjo00= To: cbor@ietf.org References: <43C3FA56-316E-45DF-A231-D36431712B9C@tzi.org> <002601d35504$a56b0200$f0410600$@augustcellars.com> <85BA5F43-50BF-4216-AB08-D4E32A1C26A6@tzi.org> From: Christoph Vigano Message-ID: <2bc89613-98a7-18c1-03f0-db3f900aae82@uni-bremen.de> Date: Sat, 4 Nov 2017 12:20:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <85BA5F43-50BF-4216-AB08-D4E32A1C26A6@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2AEtCWU3or5RXLGkuOPXpN5NGnQhSln2T" Archived-At: Subject: Re: [Cbor] More formal definition of CDDL matching rules X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 11:20:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2AEtCWU3or5RXLGkuOPXpN5NGnQhSln2T Content-Type: multipart/mixed; boundary="gkDFfcokh4Boe7tcAp1i9EkrhBER6Wqlr"; protected-headers="v1" From: Christoph Vigano To: cbor@ietf.org Message-ID: <2bc89613-98a7-18c1-03f0-db3f900aae82@uni-bremen.de> Subject: Re: [Cbor] More formal definition of CDDL matching rules References: <43C3FA56-316E-45DF-A231-D36431712B9C@tzi.org> <002601d35504$a56b0200$f0410600$@augustcellars.com> <85BA5F43-50BF-4216-AB08-D4E32A1C26A6@tzi.org> In-Reply-To: <85BA5F43-50BF-4216-AB08-D4E32A1C26A6@tzi.org> --gkDFfcokh4Boe7tcAp1i9EkrhBER6Wqlr Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Carsten, thank you for writing an explanation of the matching rules. > It should already be covered in the main document, but the exact way th= e matching is supposed to be done has to be inferred from the text (and w= e have got feedback that the inference may not be obvious). So we though= t it might be a good idea to summarize the matching rules once more in th= e appendix. Would it help to have more examples in the text to further showcase the various edge cases and specific matching rules? Or would that worsen the readability of the text? I think my point is that the edge cases and specific matching rules would be better understood if also shown in a specific example, as opposed to having to extract and infer the information from a text. Also, is there a documentation somewhere where those edge cases are collected, so others could help writing those samples more easily? What do you think? Viele Gr=C3=BC=C3=9Fe Christoph > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> >> Jim >> >> >>> -----Original Message----- >>> From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten Borman= n >>> Sent: Friday, November 3, 2017 1:24 PM >>> To: cbor@ietf.org >>> Subject: [Cbor] More formal definition of CDDL matching rules >>> >>> On Jul 18, 2017, at 20:43, Kevin Braun wrote: >>>> >>>> I know the question of more formally specifying validation rules alr= eady came >>> up. >>> >>> I have started writing up the matching rules, piece by piece motivate= d by the >>> syntactic elements of the language. >>> >>> https://cbor-wg.github.io/cddl/matching/draft-ietf-cbor- >>> cddl.html#rfc.appendix.B >>> >>> The new text is not yet finely honed yet; at this point I=E2=80=99m m= ainly interested to >>> hear whether the approach goes into the right direction. >>> >>> My plan is that we could have a -01 with an editorially combed versio= n of this >>> by November 11. >>> >>> Gr=C3=BC=C3=9Fe, Carsten >>> >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >> >> >> >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 --gkDFfcokh4Boe7tcAp1i9EkrhBER6Wqlr-- --2AEtCWU3or5RXLGkuOPXpN5NGnQhSln2T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJTBAEBCAA9FiEEke2XqjEOm6fTVrsm4YjBRm5TGmcFAln9ooQfHGNocmlzdG9w aC52aWdhbm9AdW5pLWJyZW1lbi5kZQAKCRDhiMFGblMaZ7PHD/wKKsgYEemP6tUV rfgsrCBXbmUYtG28n62T6lhZh0KfrC0UnrsIfSsOq2mhrCDrOZLu1vWvlPHbfqWX 6JvHTy8J9sbqoaBB6gN+XwSNwXow0cdAM+BqjModkceZFtVg8YirP5rCCN5YKtKg KPynZUC3yOANDBRjj5ULaDUh04yvkOI3PPhgC0nISLN92ozwVbV8dIn5IGwkSSw1 OkcMPrLH1v1Q6348c2qpuXuGSwLL68ORFx3/4zuzFTNxinA/C68F5T0jdc6xp1zO Bi1frg/gL21ASm3/6FkJsDSuqKLvqlwh0g94ZDLRY0VJTBqTKGyQZHhWsNxlTw7Z efkfQX/hBJq4cfOozBtvtNuZcbZppL97SGMwfNf2MAFpQa3U8byHWDsDpIu5krZ1 FeEkHS/QHa2FOOta4sn/JOU6em1RkNPw7tI5l2XfP2yxR1uhJ5N2IDneOGSvyshA QVv543PciuyCTVMEVk41neZ092YS3qelwowIlqDyQojw6ylkMtCvh+X4nuGKR0lC xJe7BFRiZ5wOQzZoJfkBtjJ9h1j6OAgLpYAYWrv4yNcuv4B+Btk7AziEllAhdZ3r XXRi8TRHaUbLVSXI0j5Ev5bnB/SKmBlGHJvS+UUi4RCQ6XwRpqbTh5RE5iYayzrM lQmE4R3wql+bAEq4P0Ixt5KEVMLLcA== =UBXN -----END PGP SIGNATURE----- --2AEtCWU3or5RXLGkuOPXpN5NGnQhSln2T-- From nobody Sat Nov 4 12:57:24 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6FB13FBD6 for ; Sat, 4 Nov 2017 12:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 2rrrAJ37rxPG for ; Sat, 4 Nov 2017 12:57:20 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 9D14513FBDB for ; Sat, 4 Nov 2017 12:57:20 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id k7so5187156pga.3 for ; Sat, 04 Nov 2017 12:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=a7pv2kHrKHsrC3xrOBf4QZ/rqGCJ3BuYUERvMj9kQN8=; b=vMA8zOwA8d4g6ZjPGupIdZKMuTg5YKQyHnSPd7KmY1gx8aWuZDsKWg79hA4ZWk46GP 97/y8RMiPuxEoXBi4s3nz1wKTarLE0yBxjxwCsfejYR5iJodqzNOCEQS9B9Ui9RD4VX3 8mKRvD3GIssSb6fS48FzrEORyWliYjzO5E5mP4rCu+f6eM1nUJW4me2scsbeCTtXqPLl uwN9lAYcMg8W5Y4hiXilfzE+ubfcusfRVt+0STXZY4H1l8OFFknkatsXGsye9ZztrPwj /eXSw7PCGsqaz8AK24haLk/YYmijrurgjE2molXwV06mMHZv/Hhh/AMph32AEklNusZf 7HrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=a7pv2kHrKHsrC3xrOBf4QZ/rqGCJ3BuYUERvMj9kQN8=; b=Q3CxgRKIrqFavKdi2pOqjExkKkZFoVpb+2K7+/CIt/zVP8f/P+gNWsv7Omy4Ah/cwa wXxjtRmo3tc9MFbCWAoNouKTKjj0O5MKm/Npmvj8tutmr2vBA7Id4cmjw63TYdRyYP0x wv7qVL0GGe1voGrrHpgzTU0EkaF1LNxy9Z1naYEd57SLELt+4/7z3ewRo+Gpd1Yo5JaN 00SLUfMwyZOIjfZH7+nGewntinlf67YOo8cgUXenWdWW/uBBGtKI0lqzNmrPq8uHHH4q +ze1dpfw/RIpK3vPqW7l8n15XOuy5sbBCdr4jLya+jwpZwtWLsGEN94bOm0QhljvmOCs bNJA== X-Gm-Message-State: AMCzsaUdm58s/LanRs6S1dzUD3pg++XZbCTg88xSbbrJwmKgg5Il4G6g 6tEQQEZwhsQvkRQsfcX/k2vYEw== X-Google-Smtp-Source: ABhQp+TodJLE6NviH8ynIdKZPfixcGxsq4UYKCku2Ja63Fb+C/554MptAS+0jNHRfUY6PU+uCA6WDw== X-Received: by 10.98.155.218 with SMTP id e87mr11672718pfk.96.1509825439637; Sat, 04 Nov 2017 12:57:19 -0700 (PDT) Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g16sm18493049pfd.87.2017.11.04.12.57.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Nov 2017 12:57:18 -0700 (PDT) To: cbor@ietf.org References: <43C3FA56-316E-45DF-A231-D36431712B9C@tzi.org> <002601d35504$a56b0200$f0410600$@augustcellars.com> <85BA5F43-50BF-4216-AB08-D4E32A1C26A6@tzi.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <900f9b37-dc42-cb9e-f809-c093342f5f3e@gmail.com> Date: Sun, 5 Nov 2017 08:57:13 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <85BA5F43-50BF-4216-AB08-D4E32A1C26A6@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] More formal definition of CDDL matching rules X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 19:57:22 -0000 On 04/11/2017 22:24, Carsten Bormann wrote: > Hi Jim, >=20 > thank you for the very quick feedback. >=20 > The appendix uses the ABNF just as a reminder of the structure of a CDD= L specification =E2=80=94 I couldn=E2=80=99t come up with a more succinct= way. But the information is in the text, not the ABNF =E2=80=94 that is= just a repeat of Appendix D. >=20 >> On Nov 4, 2017, at 01:34, Jim Schaad wrote: >> >> My first answer, having tried to read it and not managed it, is that t= his is a really bad approach. As a consumer of CDDL, I do not care what = the ABNF is and how that is implemented. =20 >=20 > The text is not about implementation (although you can indeed implement= it from the text), but about the language semantics. >=20 > (I understand it may be a bit confusing to discuss a language that is i= n effect notating a (tree) grammar by going along the (string) grammar of= the (tree) grammar language.) >=20 >> What I want to know is for a FOO operation, what are the rules that I = should expect. If this is just supplementary information that is covered= in the main document it is fine. >=20 > It should already be covered in the main document, but the exact way th= e matching is supposed to be done has to be inferred from the text (and w= e have got feedback that the inference may not be obvious). So we though= t it might be a good idea to summarize the matching rules once more in th= e appendix. I think it is useful. It seems a little unnatural to have this Appendix *= before* the ABNF Appendix, however. In response to Jim, as a consumer of CDDL I hope I don't need to study th= e ABNF and the matching rules, but when I can't avoid it, I want as much precisi= on as possible. Having this material in appendices seems right to me. Brian From nobody Sat Nov 4 14:31:39 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C400113FB06 for ; Sat, 4 Nov 2017 14:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZ44qZbdeoC8 for ; Sat, 4 Nov 2017 14:31:35 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E6C13FAE5 for ; Sat, 4 Nov 2017 14:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vA4LVVT0007450; Sat, 4 Nov 2017 22:31:31 +0100 (CET) Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yTsTH5PvmzDXnK; Sat, 4 Nov 2017 22:31:31 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <900f9b37-dc42-cb9e-f809-c093342f5f3e@gmail.com> Date: Sat, 4 Nov 2017 22:31:30 +0100 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 531523890.848327-e67a085a62e6d54b357cf6bd9ae46e87 Content-Transfer-Encoding: quoted-printable Message-Id: <100F7DEB-B668-46FF-BAA5-BAD14924DAF7@tzi.org> References: <43C3FA56-316E-45DF-A231-D36431712B9C@tzi.org> <002601d35504$a56b0200$f0410600$@augustcellars.com> <85BA5F43-50BF-4216-AB08-D4E32A1C26A6@tzi.org> <900f9b37-dc42-cb9e-f809-c093342f5f3e@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] More formal definition of CDDL matching rules X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 21:31:37 -0000 On Nov 4, 2017, at 20:57, Brian E Carpenter = wrote: >=20 > It seems a little unnatural to have this Appendix *before* > the ABNF Appendix, however. Right. Since many documents cite appendices of the draft directly = (e.g., Appendix G for the extended diagnostic notation), I have been = trying to keep their designations the same. But I don=E2=80=99t think anyone cites the ABNF, so we can shuffle these = around. So the matching rules are now at = https://cbor-wg.github.io/cddl/matching/draft-ietf-cbor-cddl.html#rfc.appe= ndix.C Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Nov 4 14:51:11 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95EC13FB6C for ; Sat, 4 Nov 2017 14:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Hn9T2xh3GG5 for ; Sat, 4 Nov 2017 14:51:08 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FA113FADA for ; Sat, 4 Nov 2017 14:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vA4Lp43W023614; Sat, 4 Nov 2017 22:51:04 +0100 (CET) Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yTsvr3MLwzDXnS; Sat, 4 Nov 2017 22:51:04 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <2bc89613-98a7-18c1-03f0-db3f900aae82@uni-bremen.de> Date: Sat, 4 Nov 2017 22:51:03 +0100 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 531525063.593307-b46d19596570d1cf56841bc107467a73 Content-Transfer-Encoding: quoted-printable Message-Id: References: <43C3FA56-316E-45DF-A231-D36431712B9C@tzi.org> <002601d35504$a56b0200$f0410600$@augustcellars.com> <85BA5F43-50BF-4216-AB08-D4E32A1C26A6@tzi.org> <2bc89613-98a7-18c1-03f0-db3f900aae82@uni-bremen.de> To: Christoph Vigano X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] More formal definition of CDDL matching rules X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 21:51:10 -0000 On Nov 4, 2017, at 12:20, Christoph Vigano = wrote: >=20 > Would it help to have more examples in the text to further showcase = the > various edge cases and specific matching rules? Or would that worsen = the > readability of the text? There is always this tension between illustrating defining text via = examples and obscuring the defining text by drowning it in a sea of = examples. I believe the really good examples are the ones based on actual = protocols (such as the one restating RFC 7071 or the ones *in* RFCs such = as 8007, 8152, or RFC-to-be anima-grasp). (Recent editorial runs were heavier on the side of deleting existing = examples than on adding new ones, as some of the early examples are no = longer that useful.) > I think my point is that the edge cases and specific matching rules > would be better understood if also shown in a specific example, as > opposed to having to extract and infer the information from a text. Well, I hope there actually aren=E2=80=99t that many edge cases. So far, we have found that map rules with wildcards in them may violate = the POLS, and maybe it is indeed useful to collect examples in that = space. > Also, is there a documentation somewhere where those edge cases are > collected, so others could help writing those samples more easily? The CDDL github repo also has a wiki. =20 We could start collecting examples there and then later decide where to = put those. In case that makes sense, I have created a page=20 https://github.com/cbor-wg/cddl/wiki/Examples-for-CDDL-Matching (Note that the actual matching instances can easily be generated in the = CDDL tool. We could leave that as an exercise for the user=E2=80=A6 Maybe not.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Nov 14 22:40:43 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB611294CF for ; Tue, 14 Nov 2017 22:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 a0_TK3OgAVUX for ; Tue, 14 Nov 2017 22:40:35 -0800 (PST) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052CA129508 for ; Tue, 14 Nov 2017 22:40:34 -0800 (PST) Received: from dhcp-894b.meeting.ietf.org (dhcp-894b.meeting.ietf.org [31.133.137.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A6A0E274F7; Wed, 15 Nov 2017 01:40:32 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Leonard In-Reply-To: <900f9b37-dc42-cb9e-f809-c093342f5f3e@gmail.com> Date: Wed, 15 Nov 2017 14:40:29 +0800 Cc: cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <43C3FA56-316E-45DF-A231-D36431712B9C@tzi.org> <002601d35504$a56b0200$f0410600$@augustcellars.com> <85BA5F43-50BF-4216-AB08-D4E32A1C26A6@tzi.org> <900f9b37-dc42-cb9e-f809-c093342f5f3e@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] More formal definition of CDDL matching rules X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 06:40:38 -0000 > On Nov 5, 2017, at 3:57 AM, Brian E Carpenter = wrote: >=20 > On 04/11/2017 22:24, Carsten Bormann wrote: >> Hi Jim, >>=20 >> thank you for the very quick feedback. >>=20 >> The appendix uses the ABNF just as a reminder of the structure of a = CDDL specification =E2=80=94 I couldn=E2=80=99t come up with a more = succinct way. But the information is in the text, not the ABNF =E2=80=94 = that is just a repeat of Appendix D. >>=20 >>> On Nov 4, 2017, at 01:34, Jim Schaad wrote: >>>=20 >>> My first answer, having tried to read it and not managed it, is that = this is a really bad approach. As a consumer of CDDL, I do not care = what the ABNF is and how that is implemented. =20 >>=20 >> The text is not about implementation (although you can indeed = implement it from the text), but about the language semantics. >>=20 >> (I understand it may be a bit confusing to discuss a language that is = in effect notating a (tree) grammar by going along the (string) grammar = of the (tree) grammar language.) >>=20 >>> What I want to know is for a FOO operation, what are the rules that = I should expect. If this is just supplementary information that is = covered in the main document it is fine. >>=20 >> It should already be covered in the main document, but the exact way = the matching is supposed to be done has to be inferred from the text = (and we have got feedback that the inference may not be obvious). So we = thought it might be a good idea to summarize the matching rules once = more in the appendix. >=20 > I think it is useful. It seems a little unnatural to have this = Appendix *before* > the ABNF Appendix, however. >=20 > In response to Jim, as a consumer of CDDL I hope I don't need to study = the ABNF > and the matching rules, but when I can't avoid it, I want as much = precision as > possible. Having this material in appendices seems right to me. I reviewed the current Appendix B and Appendix C parts. Appendix C looks =E2=80=9Cokay=E2=80=9D for what it is (not a complete = endorsement, but I think it is a contribution to the document, and = therefore is useful, so I echo Brian Carpenter=E2=80=99s opinion). Appendix B=E2=80=99s ABNF is mostly okay, but has some stuff worth = addressing. Looks like Unicode characters in CDDL are generically considered = =E2=80=9Cokay=E2=80=9D. That is fine but = draft-seantek-unicode-in-abnf-03 should be referenced for the premise of = going up to %x10FFFD for Unicode. Also, it=E2=80=99s not clear why you don=E2=80=99t want %x10FFFE and = %x10FFFF, but you allow %xFFFE, %xFFFF, %x1FFFE, %x1FFFF, etc. in the = definition of PCHAR and SCHAR. Either allow everything up through = %x10FFFF, or use one of the predefined rules that carve out the = problematic non character code points. See =E2=80=9CUCHAR=E2=80=9D and = =E2=80=9CUVCHAR=E2=80=9D in the document above: they are designed for = that purpose. There are conflicts and redundancies with the way that this document = defines some basic rules, and RFC 5234. For example: this document = defines CRLF as %x0A or %x0D.0A. But RFC 5234=E2=80=99s core rules = define CRLF as=E2=80=A6wait for it!=E2=80=A6CRLF. I don=E2=80=99t think = you want to be mixing different line styles. Just let RFC 5234=E2=80=99s = Core Rules define CRLF, so you don=E2=80=99t have to redefine it. We all = =E2=80=9Cknow=E2=80=9D how to deal with line endings, and the canonical = line ending format for Internet interchange is CRLF. Another source of = conflict may be the way that WS is defined, since WS =3D SP / NL, which = admits bare newline, but omits HTAB. The cddl processor(s) out there do = accept HTAB as whitespace, right? Similarly, HEXDIG is already in the Core Rules. BINDIG isn=E2=80=99t = necessary because the Core Rules already have BIT. If it would help, I can revise this section and post/PR the revisions. Thanks, Sean From nobody Tue Nov 14 22:53:12 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5951270A0 for ; Tue, 14 Nov 2017 22:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 zsro7LBkSgyb for ; Tue, 14 Nov 2017 22:53:08 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A92129524 for ; Tue, 14 Nov 2017 22:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vAF6r3h5029434; Wed, 15 Nov 2017 07:53:03 +0100 (CET) Received: from [IPv6:2001:67c:370:128:4d3c:6103:9cb2:c423] (unknown [IPv6:2001:67c:370:128:4d3c:6103:9cb2:c423]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ycFSZ517rzDXbh; Wed, 15 Nov 2017 07:53:02 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPad Mail (15B93) In-Reply-To: Date: Wed, 15 Nov 2017 14:52:59 +0800 Cc: Brian E Carpenter , cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <43C3FA56-316E-45DF-A231-D36431712B9C@tzi.org> <002601d35504$a56b0200$f0410600$@augustcellars.com> <85BA5F43-50BF-4216-AB08-D4E32A1C26A6@tzi.org> <900f9b37-dc42-cb9e-f809-c093342f5f3e@gmail.com> To: Sean Leonard Archived-At: Subject: Re: [Cbor] More formal definition of CDDL matching rules X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 06:53:11 -0000 Hi Sean, great input on the abnf (should we have abnf doctors?); will pick this up in= next version.=20 I don=E2=80=99t agree on the line ends; the name crlf is not right and needs= to be fixed, but we need to allow Unix line ends. Sent from my iPad > On 15. Nov 2017, at 14:40, Sean Leonard wrote: >=20 >=20 >> On Nov 5, 2017, at 3:57 AM, Brian E Carpenter wrote: >>=20 >> On 04/11/2017 22:24, Carsten Bormann wrote: >>> Hi Jim, >>>=20 >>> thank you for the very quick feedback. >>>=20 >>> The appendix uses the ABNF just as a reminder of the structure of a CDDL= specification =E2=80=94 I couldn=E2=80=99t come up with a more succinct way= . But the information is in the text, not the ABNF =E2=80=94 that is just a= repeat of Appendix D. >>>=20 >>>> On Nov 4, 2017, at 01:34, Jim Schaad wrote: >>>>=20 >>>> My first answer, having tried to read it and not managed it, is that th= is is a really bad approach. As a consumer of CDDL, I do not care what the A= BNF is and how that is implemented. =20 >>>=20 >>> The text is not about implementation (although you can indeed implement i= t from the text), but about the language semantics. >>>=20 >>> (I understand it may be a bit confusing to discuss a language that is in= effect notating a (tree) grammar by going along the (string) grammar of the= (tree) grammar language.) >>>=20 >>>> What I want to know is for a FOO operation, what are the rules that I s= hould expect. If this is just supplementary information that is covered in t= he main document it is fine. >>>=20 >>> It should already be covered in the main document, but the exact way the= matching is supposed to be done has to be inferred from the text (and we ha= ve got feedback that the inference may not be obvious). So we thought it mi= ght be a good idea to summarize the matching rules once more in the appendix= . >>=20 >> I think it is useful. It seems a little unnatural to have this Appendix *= before* >> the ABNF Appendix, however. >>=20 >> In response to Jim, as a consumer of CDDL I hope I don't need to study th= e ABNF >> and the matching rules, but when I can't avoid it, I want as much precisi= on as >> possible. Having this material in appendices seems right to me. >=20 > I reviewed the current Appendix B and Appendix C parts. >=20 > Appendix C looks =E2=80=9Cokay=E2=80=9D for what it is (not a complete end= orsement, but I think it is a contribution to the document, and therefore is= useful, so I echo Brian Carpenter=E2=80=99s opinion). >=20 > Appendix B=E2=80=99s ABNF is mostly okay, but has some stuff worth address= ing. >=20 > Looks like Unicode characters in CDDL are generically considered =E2=80=9C= okay=E2=80=9D. That is fine but draft-seantek-unicode-in-abnf-03 should be r= eferenced for the premise of going up to %x10FFFD for Unicode. >=20 > Also, it=E2=80=99s not clear why you don=E2=80=99t want %x10FFFE and %x10FF= FF, but you allow %xFFFE, %xFFFF, %x1FFFE, %x1FFFF, etc. in the definition o= f PCHAR and SCHAR. Either allow everything up through %x10FFFF, or use one o= f the predefined rules that carve out the problematic non character code poi= nts. See =E2=80=9CUCHAR=E2=80=9D and =E2=80=9CUVCHAR=E2=80=9D in the documen= t above: they are designed for that purpose. >=20 > There are conflicts and redundancies with the way that this document defin= es some basic rules, and RFC 5234. For example: this document defines CRLF a= s %x0A or %x0D.0A. But RFC 5234=E2=80=99s core rules define CRLF as=E2=80=A6= wait for it!=E2=80=A6CRLF. I don=E2=80=99t think you want to be mixing diffe= rent line styles. Just let RFC 5234=E2=80=99s Core Rules define CRLF, so you= don=E2=80=99t have to redefine it. We all =E2=80=9Cknow=E2=80=9D how to dea= l with line endings, and the canonical line ending format for Internet inter= change is CRLF. Another source of conflict may be the way that WS is defined= , since WS =3D SP / NL, which admits bare newline, but omits HTAB. The cddl p= rocessor(s) out there do accept HTAB as whitespace, right? >=20 > Similarly, HEXDIG is already in the Core Rules. BINDIG isn=E2=80=99t neces= sary because the Core Rules already have BIT. >=20 > If it would help, I can revise this section and post/PR the revisions. >=20 > Thanks, >=20 > Sean >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 >=20 From nobody Wed Nov 15 03:37:57 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEEA124BE8 for ; Wed, 15 Nov 2017 03:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vb6NAbPHqRbw for ; Wed, 15 Nov 2017 03:37:54 -0800 (PST) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05DEF1200FC for ; Wed, 15 Nov 2017 03:37:53 -0800 (PST) Received: from dhcp-894b.meeting.ietf.org (dhcp-894b.meeting.ietf.org [31.133.137.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 409CD275AB; Wed, 15 Nov 2017 06:37:50 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Leonard In-Reply-To: Date: Wed, 15 Nov 2017 19:37:37 +0800 Cc: Brian E Carpenter , Carsten Bormann Content-Transfer-Encoding: quoted-printable Message-Id: <04C839FE-732C-4F46-97A0-66AF654AC37A@seantek.com> References: <43C3FA56-316E-45DF-A231-D36431712B9C@tzi.org> <002601d35504$a56b0200$f0410600$@augustcellars.com> <85BA5F43-50BF-4216-AB08-D4E32A1C26A6@tzi.org> <900f9b37-dc42-cb9e-f809-c093342f5f3e@gmail.com> To: cbor@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] More formal definition of CDDL matching rules X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 11:37:56 -0000 > On Nov 15, 2017, at 2:52 PM, Carsten Bormann wrote: >=20 > Hi Sean, >=20 > great input on the abnf (should we have abnf doctors?); will pick this = up in next version.=20 > [=E2=80=A6] the name crlf is not right and needs to be fixed, [=E2=80=A6= ] Okay great. > I don=E2=80=99t agree on the line ends; [=E2=80=A6] but we need to = allow Unix line ends. I understand the premise that you are getting at, and do not have a = problem with allowing Unix line ends. I dealt with the same problem in = prix-textual (RFC 7468). I am not sure how to resolve it in the confines of ABNF, but I did a = survey this afternoon of all ABNF relating to newlines in RFC 2000-RFC = 7999. The majority simply call the end-of-line marker ; there is a = minority that call it other things, namely . Of the minority, a = large portion of the minority admits CRLF / LF; a much smaller minority = admits CR / LF (aka any of bare CR, bare LF, or CRLF -- which means that = LF CR is unambiguously two lines, but CRLF is ambiguous as to whether it = is one line or two lines). Just think about it this way: when you define the end-of-line as CRLF / = LF, abnfgen will produce random combinations of CRLF and LF-terminated = lines. I will bring the matter up on abnf-discuss@, since there should be an = agreed-upon colloquialism in ABNF to say =E2=80=9Cend of line=E2=80=9D. Thanks, Sean ~~~~~~~ 2017-11-15 Facts about CRLF and new lines in ABNF in RFC Series Sean Leonard Facts about CRLF and new lines: Surveyed ABNF of all RFCs between RFC 2000 to RFC 7999. =E2=80=9CWhat is the end-of-line marker called, other than CRLF?=E2=80=9D = (by search of CRLF) Answer: Most call it CRLF. Amongst the minority, EOL is the most common, = followed by line-break or lineBreak. Most define the end-of-line marker = as CR LF; in the minority, most in the minority use CRLF / LF, and a = smaller subset uses CR / LF (aka any of bare CR, bare LF, or CRLF). RFC Hint Name =3D Definition 2705 Megaco EOL =3D CRLF / LF 2967* TISDAG nl =3D %d13 %d10 2967* TISDAG SEP =3D (CR LF) | LF <-- NOT actually ABNF=20 3108 SDP EOL =3D (CR / LF / CRLF) 3435 Megaco EOL =3D CRLF / LF 3780 SMIng lineBreak =3D CRLF / LF 4997 ROHC-FN CRLF =3D %x0A / %x0D.0A 4997 ROHC-FN NL =3D COMMENT / CRLF 4997 ROHC-FN COMMENT =3D "//" *(SP / HTAB / VCHAR) CRLF 5228* Sieve (Sieve explicitly limits to CRLF-only in text) 5234* ABNF c-nl =3D comment / CRLF 5234* ABNF comment =3D ";" *(WSP / VCHAR) CRLF 6020 YANG line-break =3D CRLF / LF 7208* SPF CRLF =3D 7468 PKIXt eol =3D CRLF / CR / LF 7468 PKIXt eolWSP =3D WSP / CR / LF 7468 PKIXt W =3D WSP / CR / LF / %x0B / %x0C =E2=80=9CHow is =E2=80=98nl=E2=80=99 defined?=E2=80=9D (by search of = =E2=80=98nl=E2=80=99) Answer: Always CRLF. RFC Hint Name =3D Definition 2957 whoispp nl =3D %d13 %d10 2958 whoispp nl =3D %d13 %d10 2967* TISDAG nl =3D %d13 %d10 4997 ROHC-FN NL =3D COMMENT / CRLF 5234* ABNF c-nl =3D comment / CRLF 5234* ABNF comment =3D ";" *(WSP / VCHAR) CRLF 6787* MRCPv2 phrase-nl =3D "Phrase-NL" ":" 1*UTFCHAR CRLF =E2=80=9CHow is =E2=80=99newline=E2=80=99 used?=E2=80=9D (by search of = =E2=80=98newline=E2=80=99)=20 Answer: =E2=80=98newline=E2=80=99 is never defined as a rule name. When = it appears in comments, it is *always* associated with CR LF only. (Same = as =E2=80=98nl=E2=80=99.) =E2=80=9CHow is =E2=80=980A=E2=80=99 used?=E2=80=9D (by search of 0A) Answer: =E2=80=980A=E2=80=99 is almost always defined as LF or used as = LF; no additional interesting variations were uncovered. The only = interesting variation is RFC 4464, which has %x0a / %x0d / (others) as = whitespace generically, but that protocol is not line-oriented. * items do not address the premise of the inquiry, but is included = anyway for completeness. ~~~~~~~ >=20 >=20 >> On 15. Nov 2017, at 14:40, Sean Leonard wrote: >>=20 >>=20 >>> On Nov 5, 2017, at 3:57 AM, Brian E Carpenter = wrote: >>>=20 >>> On 04/11/2017 22:24, Carsten Bormann wrote: >>>> Hi Jim, >>>>=20 >>>> thank you for the very quick feedback. >>>>=20 >>>> The appendix uses the ABNF just as a reminder of the structure of a = CDDL specification =E2=80=94 I couldn=E2=80=99t come up with a more = succinct way. But the information is in the text, not the ABNF =E2=80=94 = that is just a repeat of Appendix D. >>>>=20 >>>>> On Nov 4, 2017, at 01:34, Jim Schaad = wrote: >>>>>=20 >>>>> My first answer, having tried to read it and not managed it, is = that this is a really bad approach. As a consumer of CDDL, I do not = care what the ABNF is and how that is implemented. =20 >>>>=20 >>>> The text is not about implementation (although you can indeed = implement it from the text), but about the language semantics. >>>>=20 >>>> (I understand it may be a bit confusing to discuss a language that = is in effect notating a (tree) grammar by going along the (string) = grammar of the (tree) grammar language.) >>>>=20 >>>>> What I want to know is for a FOO operation, what are the rules = that I should expect. If this is just supplementary information that is = covered in the main document it is fine. >>>>=20 >>>> It should already be covered in the main document, but the exact = way the matching is supposed to be done has to be inferred from the text = (and we have got feedback that the inference may not be obvious). So we = thought it might be a good idea to summarize the matching rules once = more in the appendix. >>>=20 >>> I think it is useful. It seems a little unnatural to have this = Appendix *before* >>> the ABNF Appendix, however. >>>=20 >>> In response to Jim, as a consumer of CDDL I hope I don't need to = study the ABNF >>> and the matching rules, but when I can't avoid it, I want as much = precision as >>> possible. Having this material in appendices seems right to me. >>=20 >> I reviewed the current Appendix B and Appendix C parts. >>=20 >> Appendix C looks =E2=80=9Cokay=E2=80=9D for what it is (not a = complete endorsement, but I think it is a contribution to the document, = and therefore is useful, so I echo Brian Carpenter=E2=80=99s opinion). >>=20 >> Appendix B=E2=80=99s ABNF is mostly okay, but has some stuff worth = addressing. >>=20 >> Looks like Unicode characters in CDDL are generically considered = =E2=80=9Cokay=E2=80=9D. That is fine but = draft-seantek-unicode-in-abnf-03 should be referenced for the premise of = going up to %x10FFFD for Unicode. >>=20 >> Also, it=E2=80=99s not clear why you don=E2=80=99t want %x10FFFE and = %x10FFFF, but you allow %xFFFE, %xFFFF, %x1FFFE, %x1FFFF, etc. in the = definition of PCHAR and SCHAR. Either allow everything up through = %x10FFFF, or use one of the predefined rules that carve out the = problematic non character code points. See =E2=80=9CUCHAR=E2=80=9D and = =E2=80=9CUVCHAR=E2=80=9D in the document above: they are designed for = that purpose. >>=20 >> There are conflicts and redundancies with the way that this document = defines some basic rules, and RFC 5234. For example: this document = defines CRLF as %x0A or %x0D.0A. But RFC 5234=E2=80=99s core rules = define CRLF as=E2=80=A6wait for it!=E2=80=A6CRLF. I don=E2=80=99t think = you want to be mixing different line styles. Just let RFC 5234=E2=80=99s = Core Rules define CRLF, so you don=E2=80=99t have to redefine it. We all = =E2=80=9Cknow=E2=80=9D how to deal with line endings, and the canonical = line ending format for Internet interchange is CRLF. Another source of = conflict may be the way that WS is defined, since WS =3D SP / NL, which = admits bare newline, but omits HTAB. The cddl processor(s) out there do = accept HTAB as whitespace, right? >>=20 >> Similarly, HEXDIG is already in the Core Rules. BINDIG isn=E2=80=99t = necessary because the Core Rules already have BIT. >>=20 >> If it would help, I can revise this section and post/PR the = revisions. >>=20 >> Thanks, >>=20 >> Sean >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >>=20 >>=20 >=20 From nobody Wed Nov 15 04:17:13 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26991129401 for ; Wed, 15 Nov 2017 04:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7WIJLPM3Zao for ; Wed, 15 Nov 2017 04:17:10 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48EC129480 for ; Wed, 15 Nov 2017 04:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vAFCH4lr026062; Wed, 15 Nov 2017 13:17:04 +0100 (CET) Received: from [IPv6:2001:67c:370:128:519:5fad:5aa4:a89c] (unknown [IPv6:2001:67c:370:128:519:5fad:5aa4:a89c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ycNfS2MpRzDXhV; Wed, 15 Nov 2017 13:17:04 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPad Mail (15B93) In-Reply-To: <04C839FE-732C-4F46-97A0-66AF654AC37A@seantek.com> Date: Wed, 15 Nov 2017 20:17:01 +0800 Cc: cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4EF0D8E4-F320-4AA4-B701-8FC5440F5337@tzi.org> References: <43C3FA56-316E-45DF-A231-D36431712B9C@tzi.org> <002601d35504$a56b0200$f0410600$@augustcellars.com> <85BA5F43-50BF-4216-AB08-D4E32A1C26A6@tzi.org> <900f9b37-dc42-cb9e-f809-c093342f5f3e@gmail.com> <04C839FE-732C-4F46-97A0-66AF654AC37A@seantek.com> To: Sean Leonard Archived-At: Subject: Re: [Cbor] More formal definition of CDDL matching rules X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 12:17:12 -0000 Thanks for the pointer to the usage of EOL. Since CR only line endings are e= ntirely historic (the last major OS using them became obsolete some 15 years= ago), I think defining EOL as [CR] LF seems to be the right thing.=20 Sent from my iPad > On 15. Nov 2017, at 19:37, Sean Leonard wrote: >=20 >=20 >> On Nov 15, 2017, at 2:52 PM, Carsten Bormann wrote: >>=20 >> Hi Sean, >>=20 >> great input on the abnf (should we have abnf doctors?); will pick this up= in next version.=20 >> [=E2=80=A6] the name crlf is not right and needs to be fixed, [=E2=80=A6= ] >=20 > Okay great. >=20 >> I don=E2=80=99t agree on the line ends; [=E2=80=A6] but we need to allow U= nix line ends. >=20 > I understand the premise that you are getting at, and do not have a proble= m with allowing Unix line ends. I dealt with the same problem in prix-textua= l (RFC 7468). >=20 > I am not sure how to resolve it in the confines of ABNF, but I did a surve= y this afternoon of all ABNF relating to newlines in RFC 2000-RFC 7999. The m= ajority simply call the end-of-line marker ; there is a minority that c= all it other things, namely . Of the minority, a large portion of the m= inority admits CRLF / LF; a much smaller minority admits CR / LF (aka any of= bare CR, bare LF, or CRLF -- which means that LF CR is unambiguously two li= nes, but CRLF is ambiguous as to whether it is one line or two lines). >=20 > Just think about it this way: when you define the end-of-line as CRLF / LF,= abnfgen will produce random combinations of CRLF and LF-terminated lines. >=20 > I will bring the matter up on abnf-discuss@, since there should be an agre= ed-upon colloquialism in ABNF to say =E2=80=9Cend of line=E2=80=9D. >=20 > Thanks, >=20 > Sean >=20 > ~~~~~~~ > 2017-11-15 Facts about CRLF and new lines in ABNF in RFC Series > Sean Leonard >=20 > Facts about CRLF and new lines: >=20 > Surveyed ABNF of all RFCs between RFC 2000 to RFC 7999. >=20 > =E2=80=9CWhat is the end-of-line marker called, other than CRLF?=E2=80=9D (= by search of CRLF) >=20 > Answer: Most call it CRLF. Amongst the minority, EOL is the most common, f= ollowed by line-break or lineBreak. Most define the end-of-line marker as CR= LF; in the minority, most in the minority use CRLF / LF, and a smaller subs= et uses CR / LF (aka any of bare CR, bare LF, or CRLF). >=20 > RFC Hint Name =3D Definition > 2705 Megaco EOL =3D CRLF / LF > 2967* TISDAG nl =3D %d13 %d10 > 2967* TISDAG SEP =3D (CR LF) | LF <-- NOT actually ABNF=20 > 3108 SDP EOL =3D (CR / LF / CRLF) > 3435 Megaco EOL =3D CRLF / LF > 3780 SMIng lineBreak =3D CRLF / LF > 4997 ROHC-FN CRLF =3D %x0A / %x0D.0A > 4997 ROHC-FN NL =3D COMMENT / CRLF > 4997 ROHC-FN COMMENT =3D "//" *(SP / HTAB / VCHAR) CRLF > 5228* Sieve (Sieve explicitly limits to CRLF-only in text) > 5234* ABNF c-nl =3D comment / CRLF > 5234* ABNF comment =3D ";" *(WSP / VCHAR) CRLF > 6020 YANG line-break =3D CRLF / LF > 7208* SPF CRLF =3D > 7468 PKIXt eol =3D CRLF / CR / LF > 7468 PKIXt eolWSP =3D WSP / CR / LF > 7468 PKIXt W =3D WSP / CR / LF / %x0B / %x0C >=20 >=20 > =E2=80=9CHow is =E2=80=98nl=E2=80=99 defined?=E2=80=9D (by search of =E2=80= =98nl=E2=80=99) >=20 > Answer: Always CRLF. >=20 > RFC Hint Name =3D Definition > 2957 whoispp nl =3D %d13 %d10 > 2958 whoispp nl =3D %d13 %d10 > 2967* TISDAG nl =3D %d13 %d10 > 4997 ROHC-FN NL =3D COMMENT / CRLF > 5234* ABNF c-nl =3D comment / CRLF > 5234* ABNF comment =3D ";" *(WSP / VCHAR) CRLF > 6787* MRCPv2 phrase-nl =3D "Phrase-NL" ":" 1*UTFCHAR CRLF >=20 >=20 > =E2=80=9CHow is =E2=80=99newline=E2=80=99 used?=E2=80=9D (by search of =E2= =80=98newline=E2=80=99)=20 >=20 > Answer: =E2=80=98newline=E2=80=99 is never defined as a rule name. When it= appears in comments, it is *always* associated with CR LF only. (Same as =E2= =80=98nl=E2=80=99.) >=20 > =E2=80=9CHow is =E2=80=980A=E2=80=99 used?=E2=80=9D (by search of 0A) >=20 > Answer: =E2=80=980A=E2=80=99 is almost always defined as LF or used as LF;= no additional interesting variations were uncovered. The only interesting v= ariation is RFC 4464, which has %x0a / %x0d / (others) as whitespace generic= ally, but that protocol is not line-oriented. >=20 > * items do not address the premise of the inquiry, but is included anyway f= or completeness. > ~~~~~~~ >=20 >>=20 >>=20 >>> On 15. Nov 2017, at 14:40, Sean Leonard wrote: >>>=20 >>>=20 >>>> On Nov 5, 2017, at 3:57 AM, Brian E Carpenter wrote: >>>>=20 >>>> On 04/11/2017 22:24, Carsten Bormann wrote: >>>>> Hi Jim, >>>>>=20 >>>>> thank you for the very quick feedback. >>>>>=20 >>>>> The appendix uses the ABNF just as a reminder of the structure of a CD= DL specification =E2=80=94 I couldn=E2=80=99t come up with a more succinct w= ay. But the information is in the text, not the ABNF =E2=80=94 that is just= a repeat of Appendix D. >>>>>=20 >>>>>> On Nov 4, 2017, at 01:34, Jim Schaad wrote: >>>>>>=20 >>>>>> My first answer, having tried to read it and not managed it, is that t= his is a really bad approach. As a consumer of CDDL, I do not care what the= ABNF is and how that is implemented. =20 >>>>>=20 >>>>> The text is not about implementation (although you can indeed implemen= t it from the text), but about the language semantics. >>>>>=20 >>>>> (I understand it may be a bit confusing to discuss a language that is i= n effect notating a (tree) grammar by going along the (string) grammar of th= e (tree) grammar language.) >>>>>=20 >>>>>> What I want to know is for a FOO operation, what are the rules that I= should expect. If this is just supplementary information that is covered i= n the main document it is fine. >>>>>=20 >>>>> It should already be covered in the main document, but the exact way t= he matching is supposed to be done has to be inferred from the text (and we h= ave got feedback that the inference may not be obvious). So we thought it m= ight be a good idea to summarize the matching rules once more in the appendi= x. >>>>=20 >>>> I think it is useful. It seems a little unnatural to have this Appendix= *before* >>>> the ABNF Appendix, however. >>>>=20 >>>> In response to Jim, as a consumer of CDDL I hope I don't need to study t= he ABNF >>>> and the matching rules, but when I can't avoid it, I want as much preci= sion as >>>> possible. Having this material in appendices seems right to me. >>>=20 >>> I reviewed the current Appendix B and Appendix C parts. >>>=20 >>> Appendix C looks =E2=80=9Cokay=E2=80=9D for what it is (not a complete e= ndorsement, but I think it is a contribution to the document, and therefore i= s useful, so I echo Brian Carpenter=E2=80=99s opinion). >>>=20 >>> Appendix B=E2=80=99s ABNF is mostly okay, but has some stuff worth addre= ssing. >>>=20 >>> Looks like Unicode characters in CDDL are generically considered =E2=80=9C= okay=E2=80=9D. That is fine but draft-seantek-unicode-in-abnf-03 should be r= eferenced for the premise of going up to %x10FFFD for Unicode. >>>=20 >>> Also, it=E2=80=99s not clear why you don=E2=80=99t want %x10FFFE and %x1= 0FFFF, but you allow %xFFFE, %xFFFF, %x1FFFE, %x1FFFF, etc. in the definitio= n of PCHAR and SCHAR. Either allow everything up through %x10FFFF, or use on= e of the predefined rules that carve out the problematic non character code p= oints. See =E2=80=9CUCHAR=E2=80=9D and =E2=80=9CUVCHAR=E2=80=9D in the docum= ent above: they are designed for that purpose. >>>=20 >>> There are conflicts and redundancies with the way that this document def= ines some basic rules, and RFC 5234. For example: this document defines CRLF= as %x0A or %x0D.0A. But RFC 5234=E2=80=99s core rules define CRLF as=E2=80=A6= wait for it!=E2=80=A6CRLF. I don=E2=80=99t think you want to be mixing diffe= rent line styles. Just let RFC 5234=E2=80=99s Core Rules define CRLF, so you= don=E2=80=99t have to redefine it. We all =E2=80=9Cknow=E2=80=9D how to dea= l with line endings, and the canonical line ending format for Internet inter= change is CRLF. Another source of conflict may be the way that WS is defined= , since WS =3D SP / NL, which admits bare newline, but omits HTAB. The cddl p= rocessor(s) out there do accept HTAB as whitespace, right? >>>=20 >>> Similarly, HEXDIG is already in the Core Rules. BINDIG isn=E2=80=99t nec= essary because the Core Rules already have BIT. >>>=20 >>> If it would help, I can revise this section and post/PR the revisions. >>>=20 >>> Thanks, >>>=20 >>> Sean >>>=20 >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 >=20 From nobody Thu Nov 16 01:12:25 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242AA127369 for ; Thu, 16 Nov 2017 01:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 xfOA4rvhPaE2 for ; Thu, 16 Nov 2017 01:12:20 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 935C7126C25 for ; Thu, 16 Nov 2017 01:12:20 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id d28so19184990pfe.2 for ; Thu, 16 Nov 2017 01:12:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=9iWYmdVBfY/tOAAhpCHJvwMANLvjAdSE2qI8I4aoB7I=; b=ge3klatf6AGCpQjEY0YhRae3dGdOo3toI5oTudYZkUP27Kooz45seULau6Egq1iL18 IIgn8OZZ/hCu6v8srwzEcxzBfxlWGsqhZVMk6TpqmTPqxGhlBNJcnVGjHNL7V0SAq7+8 JM8IwaGa856+QpnSIyBgn5KBImbmLy3rAwHDY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=9iWYmdVBfY/tOAAhpCHJvwMANLvjAdSE2qI8I4aoB7I=; b=UTPN2mdehjR27JjifcLlT29SCiNaJGfbq3oA9ov/U6/q7uecZ2tOiaujADCZmRwiRF YXcB6VDsohNCiWFGZbEVbmnMf/yF6C+ytRP+A4o+KShU3Lc8yYQzYAtxnw1Kor0U46eO xU1So9Jj7PXU4U1FWbdxov1SstQMiUN9HjNpozEZ4JxYiv68UJfFWaNV26uGESJPbGbZ 6SgIU6jpB+TQhfZCErkY6eG3bYti30PZjVs3/+R4bl8dxlwjJkUA9yV7Qc1+VPSsm112 p7VDOICPZ9xBzVvk84fVR1oVpKOUdBTDHfroDuF9K8zKq6cEyTwDyZOIflRwkgjQnXuA a+tQ== X-Gm-Message-State: AJaThX45dGAMWGxhMO8u0YDCPWcKnliTsVDhBnu1arNU5xJHr9FY8A1M EVq6ca5gIJUIPBbU7gy7CA4z/rEcsmI= X-Google-Smtp-Source: AGs4zMbcuV/xMotMCAV7EOkdKSdQU5eBM1aRPSDCr8aJTmMiuaKwGYx52l5iTJWZp2ei1n4DifcP9A== X-Received: by 10.101.71.205 with SMTP id f13mr1051737pgs.112.1510823539701; Thu, 16 Nov 2017 01:12:19 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:7d00:3b6c:bf07:dde2? ([2001:67c:370:128:7d00:3b6c:bf07:dde2]) by smtp.gmail.com with ESMTPSA id n72sm2001027pfg.109.2017.11.16.01.12.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 01:12:19 -0800 (PST) From: Joe Hildebrand Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Thu, 16 Nov 2017 17:12:13 +0800 References: <7DB04C3B-A3BD-4DF4-B8EF-0B4454E139AA@mozilla.com> To: "cbor@ietf.org" In-Reply-To: <7DB04C3B-A3BD-4DF4-B8EF-0B4454E139AA@mozilla.com> Message-Id: X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Cbor] Implementation Matrix for node-cbor X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 09:12:24 -0000 Reminder that there's code to generate the implementation matrix = available. > On Jul 18, 2017, at 11:57 AM, Joe Hildebrand = wrote: >=20 > I filled in = https://github.com/cbor-wg/CBORbis/wiki/Implementation-matrix with info = from node-cbor, distinguishing what could be decoded and encoded. >=20 > The code (and sample data) is here: > = https://github.com/hildjj/node-cbor/blob/master/test/implementation_matrix= .js >=20 > in case anyone wants to use the same inputs. >=20 > =E2=80=94=20 > Joe Hildebrand >=20 =E2=80=94=20 Joe Hildebrand From nobody Tue Nov 21 20:51:53 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCEE129C39 for ; Tue, 21 Nov 2017 20:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 sDq0XxTUkxGr for ; Tue, 21 Nov 2017 20:51:50 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 0C828126C23 for ; Tue, 21 Nov 2017 20:51:50 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id o6so15161671qkh.3 for ; Tue, 21 Nov 2017 20:51:50 -0800 (PST) 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=OJRTQe/hCP8thSvCWPCvH9pdT6mPB1zNREt+FFjnGNg=; b=P2uRnnfwLU9PD+6k+kk1wakdcZqZZXbBVnH6GniVa+InbbhPws62ac1hVjUw/bEuHB zBgtBAUoUkpdYuHecbSfAA3vVLdz3x4Qn6QtGTXzOwNxsJfP9ipfCqpXr6hDYq0SsZba 80yCpRvOEiZqayj7Xko114ZkHKMuSvUbNceEhGW2vUb3CD7w2/uaaRQInT4q8XsAy5G+ QwP6qQGY65Hfu9P7zl2kvj25c6JSmJNjpiM3gjE6fpkRCwE3eTyrctGwPtCfVk7lHctL +yV1lmziS7a0NYtdgSR0s8+nq4ta4cB4VU5Ys6F+o72rOXU6XDthbyfui/tHieMFCmsx o1rQ== 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=OJRTQe/hCP8thSvCWPCvH9pdT6mPB1zNREt+FFjnGNg=; b=MjXjVLxajK4wE1n49NK7+wKOGMofb2tKwPM7VSPBo2S82arV/ifAmP64SniHj82PJv mKsZebBE2z/5vxbg3Zv/s5FDqT8LdA8pRF1u5i8YPFZGVMH13P4TMapHWpnjXcGWw8fs dz737/nt81IkkKnfY0TjhBuGBQCiJdARf5DaL10eiinFaITmColuPOaEZMMJrAksCbuR bIiLmPzAq5DXnmp3fxAva0sO8A5MmbsxQYryGsYqnHZZmZFnY8SZlD2F7bBPWTNvBJvg S/VFzT5DGYm60usheN6SdW+q9/AM8tHs3eIhpc9XUiNLBLFk/jEBj3rtYTH8kdXi+N5h 2Xgg== X-Gm-Message-State: AJaThX5R7ER3K0bduCYNKqQTNQidvKv+Cky43W0Usc6b838vC97MXxL3 LVrsu2Axgw5D0ugRXukQ6XEfrUcf4rIHt+lpJYbXoQ== X-Google-Smtp-Source: AGs4zMY2Cz2Scx4Q7H7/PuyG9MGc2jJ9I3CTnh33zjHWoAdiYMoQNWY/J3L24J3DImPi/zlE1nbJXDrYZcGJqSmh1ws= X-Received: by 10.55.98.134 with SMTP id w128mr29207632qkb.292.1511326308924; Tue, 21 Nov 2017 20:51:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.89.244 with HTTP; Tue, 21 Nov 2017 20:51:48 -0800 (PST) From: Kaoru Maeda Date: Wed, 22 Nov 2017 13:51:48 +0900 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="001a11482b1cc8821c055e8b13b7" Archived-At: Subject: [Cbor] CDDL: avoiding bad regex patterns in validation X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 04:51:51 -0000 --001a11482b1cc8821c055e8b13b7 Content-Type: text/plain; charset="UTF-8" This is what I texted at IETF100. When building a generic CDDL validator, a bad regex may result in a poor performance. Document may want to clarify this wrt description vs validation. Example: suppose you want to ensure double quotes are paired. You wrote a regex "([^\\"]+|\\.)*". It works to find correctly closed pairs. However, it takes 2^n computation time against a long string with an unclosed quote if you use a standard PCRE engine. (This example can be easily fixed by removing an excessive + "([^\\"]|\\.)*".) A CDDL validator/editor that accepts user-written regex may take care of this. If a bad regex and a PCRE engine are embedded in a product, a DoS attack might be possible with a crafted input. (I don't know whether PCRE with extended expressions can be compiled into DFA.) Kaoru Maeda --001a11482b1cc8821c055e8b13b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is what I texted at IETF100.

When = building a generic CDDL validator, a bad regex may result in a poor perform= ance.=C2=A0
Document may want to clarify this wrt descriptio= n vs validation.

Example: suppose you want t= o ensure double quotes are paired.=C2=A0 You wrote a regex "([^\\"= ;]+|\\.)*".=C2=A0 It works to find correctly closed pairs.=C2=A0 Howev= er, it takes 2^n computation time against a long string with an unclosed qu= ote if you use a standard PCRE engine. (This example can be easily fixed by= removing an excessive + "([^\\"]|\\.)*".)

A CDDL validator/editor that accepts user-written regex may ta= ke care of this. If a bad regex and a PCRE engine are embedded in a product= , a DoS attack might be possible with a crafted input. (I don't know wh= ether PCRE with extended expressions can be compiled into DFA.)
=


Kaoru Maeda


--001a11482b1cc8821c055e8b13b7-- From nobody Wed Nov 22 04:34:39 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C58129435 for ; Wed, 22 Nov 2017 04:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 CzPvlbk39JPK for ; Wed, 22 Nov 2017 04:34:36 -0800 (PST) Received: from mail4.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 7EFC0129432 for ; Wed, 22 Nov 2017 04:34:36 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_000_012C_01D3634B.30DAA990" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1511354072; h=from:subject:to:date:message-id; bh=4RiJGwJqxnqrz7uOOI8O46648AQPBykde7XGZToqhjo=; b=J8qNPd/hCD/OvI/3Z3UQYtKgQenzwEV1vv8yjW6Uvv8oVjD8PyIcpFUEct4wP/VQj4Wmr18//m3 RdoP2/xpwC9h0YfVBWeCcv53R1P8P1GP1dDX9L+V0jiTnZUdfZYbMOce6tpwYNHgwqRJT2nPfI5sT DEn8klKkHD0fOlA7j9eicEqQ+NoD4OIIlqonAGxuYJGqprMDUheOWZZjdP/Yc14pr7X/vo4H9GWKj U7SxPYOP/qz8/VVtmNr4HASzeYFTe+Cd6PYbRzYueR0WrIpUHZvLgDUx6vWQfkicnJYYhp7vzdxRJ WZ2orYahPLenDrakoTgu/P+cRsbzM89tYiHQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 22 Nov 2017 04:34:31 -0800 Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 22 Nov 2017 04:33:25 -0800 From: Jim Schaad To: 'Joe Hildebrand' CC: Date: Wed, 22 Nov 2017 04:34:29 -0800 Message-ID: <012b01d3638e$3efde990$bcf9bcb0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdNjjie2INuxuvzTRO2RRpA0ZbaXuw== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] CBOR Interop Testing script X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 12:34:38 -0000 ------=_NextPart_000_012C_01D3634B.30DAA990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Joe, You said you had some tests for helping fill in the interop matrix, but the path did not get into the minutes that were taken. Please post the path. Jim ------=_NextPart_000_012C_01D3634B.30DAA990 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Joe,

 

You said you = had some tests for helping fill in the interop matrix, but the path did = not get into the minutes that were taken.  Please post the = path.

 

Jim

 

------=_NextPart_000_012C_01D3634B.30DAA990-- From nobody Wed Nov 22 04:46:23 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9C3127010 for ; Wed, 22 Nov 2017 04:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 QfTaQA3qNiqY for ; Wed, 22 Nov 2017 04:46:19 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF181129436 for ; Wed, 22 Nov 2017 04:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vAMCk8Rq017225; Wed, 22 Nov 2017 13:46:08 +0100 (CET) Received: from [192.168.217.124] (p5DC7E827.dip0.t-ipconnect.de [93.199.232.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yhhym2bhgzDWbK; Wed, 22 Nov 2017 13:46:08 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <012b01d3638e$3efde990$bcf9bcb0$@augustcellars.com> Date: Wed, 22 Nov 2017 13:46:07 +0100 Cc: Joe Hildebrand , cbor@ietf.org X-Mao-Original-Outgoing-Id: 533047566.913773-929b488583b88936414c8ee16d3abc95 Content-Transfer-Encoding: quoted-printable Message-Id: References: <012b01d3638e$3efde990$bcf9bcb0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] CBOR Interop Testing script X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 12:46:22 -0000 On Nov 22, 2017, at 13:34, Jim Schaad wrote: >=20 > Joe, > =20 > You said you had some tests for helping fill in the interop matrix, = but the path did not get into the minutes that were taken. Please post = the path. He did, in = : > The code (and sample data) is here: > = https://github.com/hildjj/node-cbor/blob/master/test/implementation_matrix= .js Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Nov 24 00:00:56 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBEB129B2A for ; Fri, 24 Nov 2017 00:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 OyCYTD8jkTD6 for ; Fri, 24 Nov 2017 00:00:52 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 1B63E127241 for ; Fri, 24 Nov 2017 00:00:51 -0800 (PST) Received: from [172.24.16.82] ([78.51.82.175]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Ledpu-1ewBUF3VQE-00qP0f for ; Fri, 24 Nov 2017 09:00:49 +0100 To: cbor@ietf.org References: <012b01d3638e$3efde990$bcf9bcb0$@augustcellars.com> From: Carl-Heinz Genzel Message-ID: <90e4fc2f-e31f-6953-d748-28987887816d@gmx.de> Date: Fri, 24 Nov 2017 09:00:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:uGo9v2Nn3eZo8ekfikoQTZynz7FnC2Zwpy/eBRh++lqJTap9T9i 2BULaMIfG1aAbJfzsUcvbxVt3KO9QjCRekBB6zGrqwfzVEmFDhBAYoJctRgC7QX1V6eWzWJ fOpaD17NxPbwPH7g/dlDAzQjcJlGZWMQD1DO+RuSf+i872QlwaDgBuJal1wZVtzmWYWzLWW yLLo22N1EO1+VA9bcQXDg== X-UI-Out-Filterresults: notjunk:1;V01:K0:HdqO2jfcDFU=:rjn8AcS3ahsLaTCLOVqAeE MgWarMCG4F7LnYTr3u8MnBqI8xhAg3KZIiv2IS2wulDyLadHdjOxjWhtrNvTNvjwYkVcZ1ZiO 6bEI7YQ0gRzbB4t52dXRmSpolfxWmazYnm43V/Uhw55YyNVeLu1UXEqaVoi8UaHkWR8bC9jVM maaFjfKwqYHOm5UV00eCPvsfcmgc6K6ZiIfxCbzvCnxywKZAqLRPvXV/R7RRFoq9Et72vLAR+ zRDEZj45HZkJCxeR84jD6IpwpYlkCV5hX13+MiTP2Jhkt3FBLbTuGAIaDoW+9m7XaBJhGjRhR QuwU7WON2tMMM1vVoW+Dr87OUwOiizyIUxopxQ+tvQETRDv47eK3tWLvHJxoj6mDOiQeRzvdw qr5/JpBh05mtyVHe5ZAWCfojS01mG+dEfTgqbUmOIFtHysIGfgeTQwjv8F5ZZMHxhpR4hIynr dr4VSJYmFscYiOAqS0A9Ks3chjgPcw02ThCKNi2LXAwg5xnxTodWfZnp2KlKbx+ju5xsmwIYh aA8KLCjGo/yTUMG2z1zsKpYxDtBt4YG0gsEPKeA2vkh5v50bkQOMKteJyRPdS313TK8Y67nl+ U0ow29inlADPQKNThd8uyjnzaudB+AhgZSXLYanHvrvQD2rSVDC1PDf4sVSUOQsmn81yBlv8N 3boHQvK2alyHx66ryGgB5k4ZO1VDscK8XaM0Plhyx0/myjRgSIgiheXmNlPblGBu+e3JgTSvB vIbMYr/9r01V1j/7kz212dfUKHFODTriZyWi02NyFuF9SK0onNUul4oebNIjOTjvvA0BmCzvX +20q37rKLO9G+jkOCfB0+FnIMcHO6qjnSFueR9fit6pw7uUqRw= Archived-At: Subject: [Cbor] Restrictable/Extension protected Choice X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 08:00:54 -0000 Hello everybody, my name is Carl-Heinz Genzel, I just joined the list and would like to discuss a question/use case with you. For the background, I am currently using CDDL and CBOR for a soon to be Open Source project. Since I am trying to create an extensible base for a message protocol I am using ".within" and enumeration as choices (&-notation) a lot. CDDL works great for me. Regarding choices, I came across the question, if it is possible to restrict a choice from further extension? Currently it is my understanding that everybody who extends the CDDL structure, I developed, has to adhere to the ".within" constraints but can always extend any choice at any given point. Is that correct? I'd like to protect some choices against that. Have you already thought about that? Whenever it suits you I'd like to discuss it with you. Sorry for just dropping into the ongoing discussion. Best Regards, Carl-Heinz Genzel ________________________ Westerstraße 76 28199 Bremen Tel.: 0421-69506029 From nobody Wed Nov 29 01:50:15 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4C1126FB3; Wed, 29 Nov 2017 01:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 CZppQGuf4K4i; Wed, 29 Nov 2017 01:50:10 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE991270AE; Wed, 29 Nov 2017 01:50:09 -0800 (PST) X-AuditID: c1b4fb3a-039e19c000004c48-03-5a1e82cf93c1 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 57.AC.19528.FC28E1A5; Wed, 29 Nov 2017 10:50:08 +0100 (CET) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 29 Nov 2017 10:50:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jNA3gnIXhMloWuMVT0ORN89sgUCWtY/DxMCK189DlEQ=; b=R5znoTm0KxCziWwmyawzlov/quUin/g+ohhuvW95FwRD4et4huatC9EYzFlvVR20HOfORJCKzyrqfOdxnfYZsxKSzvqZOeC9FOFbufqiIL4Rh2Y5a49a3N9v3z+duG8rGFNKLO8t5UGwpbfiT0CN4NSOQu1IAyY2IDKcCLJKXy8= Received: from HE1PR07MB1529.eurprd07.prod.outlook.com (10.169.122.151) by HE1PR07MB1530.eurprd07.prod.outlook.com (10.169.122.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Wed, 29 Nov 2017 09:50:06 +0000 Received: from HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::e0f3:425a:fdd1:3a4]) by HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::e0f3:425a:fdd1:3a4%13]) with mapi id 15.20.0282.006; Wed, 29 Nov 2017 09:50:06 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: Minutes IETF100 CBOR Thread-Index: AdNo9pf+xsleYN4hRo2jV8QmCtvU+w== Date: Wed, 29 Nov 2017 09:50:06 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.94] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1530; 6:TWIINOMnF4Mf7rz9ofDZaJI60TDY6Z3B90UweRDQTKHGDznUWYyx2zdNEUbzHX5wjmwau6yl2KqrILOtiecSk+cIISssK6+NvSCArxcpox5FJQOU+RyFPIcB3xQNjscSKTWm16T2SAUtooXA5uiB3ViEp5Vnbs3JjZEqNNlYcTUlWHUtiOVP4vuxFkKsW6O++ADUEU7aHEC2Cb81X3hbmak081N4iekRtcDujiaey6Q0PPFwJ2AsfT2qeizntDGKhbktEOxqONVac6EePcT/chg32xgCYdK5XvW5mf8WBBZId344A6ZDEJ3Otg5WaFPPU0qxgCbrms98tu+9JLGGrI9oI/dzs4w6u41bUzOLhWA=; 5:IcvXJ7R/iUiEIpaZH/MJqO5XldjwSF0sa3fKLP77jWEdhGvLId/RL9KW1b4VgPPzXldsp2j33jsdPoxcB4M5Gj9sxfPEBktMEUp0hCJ1rhm9K7vvmpUofmq/D1317alwzYGsZTF7Lo76TBYAUYw2GQZD9BGDXbPoVGm+tHZrQAk=; 24:RIrwFLHgU8Kdbrq5+FL6aCO8v02RIN38YpqJ1mrW+n3BFLT9kit15HLvNqWbJIwfRSgX/FdPUTpyjesEWYQFD2El5Ii471TZDyZyuC7H14s=; 7:ukYw/VREraYCnUTSFH+9YyL2BhMRsM8hYd9LmIhdpP7GT+k17dwTcWcxfqAmXUO5shr2ok5Fvf3nMiNcj1yrWMQxgqyFxje/0Yl9k8nxc6ZKYzMkkd/CWFlyWGSMATjbMB3XP0es8suEEP1oVGMahh19VDtB8pq9FQEVZdzRnBqsvvEfiFmT05Fm2YDaJfrMhk0Qrexc/b1Cfh872OEDioa1T1Jg2dt88xiAyWAE/bIklqid2KlmzpnWuiDqlpJR x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ea018d3d-1e23-4505-0a3f-08d5370e9219 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:HE1PR07MB1530; x-ms-traffictypediagnostic: HE1PR07MB1530: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820)(100405760836317)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231022)(3002001)(6041248)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(201708071742011); SRVR:HE1PR07MB1530; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR07MB1530; x-forefront-prvs: 05066DEDBB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(346002)(376002)(53754006)(199003)(189002)(316002)(9686003)(7116003)(19609705001)(236005)(25786009)(5640700003)(450100002)(54356999)(50986999)(7736002)(74316002)(55016002)(5660300001)(7696005)(2501003)(14454004)(2900100001)(6306002)(54896002)(606006)(8936002)(6436002)(53936002)(189998001)(97736004)(66066001)(478600001)(102836003)(790700001)(3846002)(3280700002)(4326008)(6116002)(966005)(105586002)(106356001)(86362001)(6506006)(99286004)(33656002)(5250100002)(68736007)(2906002)(2351001)(1730700003)(3660700001)(81156014)(81166006)(8676002)(5630700001)(6916009)(561944003)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1530; H:HE1PR07MB1529.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB1529D16DE80A628FE79C4F72983B0HE1PR07MB1529eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ea018d3d-1e23-4505-0a3f-08d5370e9219 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2017 09:50:06.2508 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1530 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHfe69m1dpdJ0OD6ZSi6AUV0rQCC3LPtiLEX0wE6mWXnWoc907 Rf0gzpcIRVFw5bbCl1ZmpZapCQ3CqdWwdLp8YVJgWpopRlmkTcm7u8Bvv3P+/+c8z//wkLjY JAgglSoNzagUmVKhN6FPeC4JsxUHJx5oLRHJjeudSK6/cYuIxmJNplXsHEr0jkyhM5W5NLP/ yBXv9OaZFoG6oRLLu92+KixCjcuoHHmRQB0EZ+djvBx5k2KqD8F6UZG7eINgcWke4wqCqsRh rr4b45U6DFbsY4gvphGY7TcJbpiQigTb9LKAYz9qN+hq+4TliCRxKhxWzdc49KWCwHL3EO+Q wvVBG8GzDF63OFxMUHtA2+8QciyikuDO4k/XRLR5dEX7COcYp/zBMVuP8REoMJmHcZ4l8HVm w+1PhvdTVZ58fyeUTZQIeA6C0foK1/OBsnhCV+UwwQsy6KpZcu8lDgzOMZw3mRCU9rxy3xAC s2+7PLkwQGWAflrNtwthYKmJ4P0NOLR1DAp5IRBGFsxu1gvBqivkWEzR0NxahqpRqGFLIINr XdlQunzc4MrvA1b9LMFbZDCpqxXyHAr3G7/hPIdB3YaF2NpvQJ4PkYSlWTYrLSJCRjPKZJbN VslUtKYDbf6d3s6/h3tQ79wxC6JIJN0mqlMHJ4oFilw2P8uCgMSlfqInpzZbohRFfgHNZF9m cjJp1oJ2kITUX2Q9KUoUU2kKDZ1B02qa+a9ipFdAEYpbMR7V1eSCX9UnZrF0/IWvh8eIx5T/ +XcV44U/rLp5W6Rz4gvKGfi9jx46/f0DHa8tvtotX6teKEgwpq59NrEh26Oa8tpSX2Lhe32U v8zx7Q5Jpy707GRUTOzaCfaCJuqBNuaSUfT0DPsnZpc88ONQ/2i0/ZmX/aKdUd1LckoJNl0R HoIzrOIf42T/gTcDAAA= Archived-At: Subject: [Cbor] Minutes IETF100 CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 09:50:14 -0000 --_000_HE1PR07MB1529D16DE80A628FE79C4F72983B0HE1PR07MB1529eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I uploaded the minutes for the CBOR meeting at IETF100 on the datatracker: = https://datatracker.ietf.org/meeting/100/materials/minutes-100-cbor/ Many thanks to Jim Schaad and St=E9phane Bortzmeyer for taking them! Please let us know if you have any comment, and if you have actively partic= ipated, take a second to make sure that your comments were correctly captur= ed. Thanks, Francesca -- CBOR WG Meeting IETF 100 - Singapore Thursday, Nov 16, 2017, 15:50-17:50 Chairs: Joe Hildebrand (JH), Francesca Palombini (FP) Minute takers: * St=E9phane Bortzmeyer * Jim Schaad * Introduction [15'] : Chairs Agenda bashing and status update * CDDL [30'] : Carsten (CB), Henk (HB) https://tools.ietf.org/html/draft-ietf-cbor-cddl-00 (Requires some ABNF background) CDDL wants to be "like ABNF" except that CBOR is not text (tree of items, w= ith structures likes arrays) Example of use of CDDL : GRASP (in Anima) To do: * appendix B on matching rules. (currently in Github only ? ) * wildcard vs. "more specific" in a map definition We would like the "m= ore specific" to win. How to express that? Proposal: use "cuts" Get inspiration from draft-miller-json-constrained-notation? (pull re= quest to be sent) Typo in slide 18 : the second ant is an elk Sean Leonard (SL): I have a different method which could express this by d= oing a general with a restriction on the general I will do a pull request for more clarification Jim Schaad: I do not understand why this needs to be expressed in the gramm= ar rather than as semantic information. SL: Currently no normative reference in CDDL for doing regular expression Regular expressions should be first class items in the language When REs are in a string, the escaping makes it difficult to read. JH: Like the proposal of killing slashes. Brian Carpenter (BC): The cuts proposal too complicated, let's keep REs for= CDDL v2 - also want to keep number of changes to absolute minimum SL: Currently the controls are both overly general and too constrained. Wa= nt to be able to do something like .size only allows lengths which are mult= iples of 2. Allowing REs at the top might be able to allow this. CB: Right now REs are only for text strings.(but SL would like them to be = more general: sequences of items, not just of characters) FP: First question is: Is the work useful? Once we answer that, if the answ= er is yes, we can move to next question: should it be delayed? CB: PCRE is not currently defined in a normative spec, even if it is the ri= ght one. Alexey Melnikov: One of the sip docs has this - JH: One of the ECMA has a slightly less powerful/expressive version. [ACTION ITEM]: Alexey to look for regex normative reference document See also the wrap-up * CBOR specification status [30'] : Carsten https://tools.ietf.org/html/draft-ietf-cbor-7049bis-01 Taking CBOR to full Internet standard (don't change it) The only really new part is the one about CBOR data model ("the biggest f= ailing of JSON") Reminder that not all extensions are mandatory in CBOR. Except false and= true and null :-) SL: Currently document says undefined is a core element - CB: Need to look - Expects undefined to be optional 40 implementations (personal opinion: they vary widely in quality, and leve= l of maintenance) Interoperability problem with the padding. Tags 22, 33, 34 no perfectly def= ined.Base64url typically used without padding, Base64 often with padding. A= nd case issue, also. SL: Is there a canonicalization reason for making the decision? Dave Thaler: Does anybody care? Yes OCF does want to be able to do this. = It uses both (or either) JSON-Schema and Swagger to specify things in JSON = but puts CBOR on wire - Both Json Schema and Swagger define BASE64 but not = BASE64url. TinyCBOR maintainer would love to fix that if either json-schem= a or swagger added spec support for base64url. Thinks the proposal should be fine - needs to check - look at tiny-CBOR htt= ps://github.com/intel/tinycbor Matt Miller: Safest to keep the padding for base64 JH: Argue to remove all Base64 because you have binary and don't need it. = The tags could be removed from standard. [ACTION ITEM] Put base64 issue on the mailing list [ACTION ITEM] Jim does PeterO implementation in matrix [ACTION ITEM] DT to poke tinyCBOR author (Thiago Macieira) to fill in imple= mentation matrix for tinycbor * OID Tags [10'] : Carsten, Sean https://tools.ietf.org/html/draft-bormann-cbor-tags-oid-06 Many tags (besides the ones in RFC 7049), sometimes in RFC; sometimes not. = Some are on-charter but not all. * Array Tags [10'] : Carsten https://tools.ietf.org/html/draft-jroatch-cbor-tags-06 Careful on the encoding: the space is not unlimited JH: General concept of - one big thing plus lots of variations - may want t= o have a pattern version - example two item array - first item is format, s= econd is data Could do this type of pattern here. SL: The fact that tagging is optional may make the case of a small array (s= uch as an RGB) value having a large tag normally for an array of bytes woul= d be easier. JH: Having a document on when and how to use tags as suggested by SL would = be useful FP: Blocking issue on adoption at the last meeting was people who read and = reviewed. Consensus on 3-bytes tags, it seems * Time Tags [5'] : Carsten https://tools.ietf.org/html/draft-bormann-cbor-time-tag-01 Document tag 1001, if the WG agrees CB: Should we allow this as an independent or wait and then do this AM: Do current things first, but no other opinion. Who wants to work on time formats? Three people. JH: this is not enough * Wrap-up [10'] : Chairs JH: How many people think we need to do much more work on CDDL before goin= g out - (none?) How many people think we should polish and call it good - many hands Request of Alexey to look for people wanting to use CDDL for JSON schema. -= need more review of Appendix B. Things that need to be looked at - if no reference RE should be on the bubb= le. Rip out features w/o full consensus and can be put into the next version of= CDDL. Need to have something that talks about the difference between a validation= compiler and a documentation of what the language should to be. This ough= t to be added to the Philosophy document that SL volunteered for. --_000_HE1PR07MB1529D16DE80A628FE79C4F72983B0HE1PR07MB1529eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I uploaded the minutes for the CBOR meeting at IETF1= 00 on the datatracker: https://datatracker.ietf.org/meeting/100/materials/minutes-100-cbor/<= /a>

Many thanks to Jim Schaad and St=E9phane Bortzmeyer = for taking them!

Please let us know if you have any comment, and if y= ou have actively participated, take a second to make sure that your comment= s were correctly captured.

 

Thanks,

Francesca

 

--

CBOR WG Meeting

IETF 100 - Singapore

Thursday, Nov 16, 2017, 15:50-17:50=

Chairs: Joe Hildebrand (JH), Francesca Palombi= ni (FP)

 

Minute takers:

    * St=E9phane Bortzmeye= r

    * Jim Schaad

 

* Introduction [15'] : Chairs

  Agenda bashing and status update

 

* CDDL [30'] : Carsten (CB), Henk = (HB)

  https://tools.ietf.org/html= /draft-ietf-cbor-cddl-00

 

(Requires some ABNF background)

 

CDDL wants to be "like ABNF" except = that CBOR is not text (tree of items, with structures likes arrays)

 

Example of use of CDDL : GRASP (in Anima)=

 

To do:

   

    * appendix B on matchi= ng rules. (currently in Github only ? )

    * wildcard vs. "more s= pecific" in a map definition We would like the "more specific&quo= t; to win. How to express that? Proposal: use "cuts"  &= nbsp;         

      Get inspir= ation from draft-miller-json-constrained-notation? (pull request to be sent= )

   

    Typo in slide 18 : the= second ant is an elk

   

Sean Leonard (SL):  I have a different me= thod which could express this by doing a general with a restriction on the = general

    I will do a pull request fo= r more clarification

   

Jim Schaad: I do not understand why this needs= to be expressed in the grammar rather than as semantic information.

 

SL:  Currently no normative reference in = CDDL for doing regular expression

Regular expressions should be first class item= s in the language

When REs are in a string, the escaping makes i= t difficult to read.

 

 

JH: Like the proposal of killing slashes.=

 

Brian Carpenter (BC): The cuts proposal too co= mplicated, let's keep REs for CDDL v2 - also want to keep number of changes= to absolute minimum

 

SL: Currently the controls are both overly gen= eral and too constrained.  Want to be able to do something like .size = only allows lengths which are multiples of 2.

    Allowing REs at the top mig= ht be able to allow this.

 

CB:  Right now REs are only for text stri= ngs.(but SL would like them to be more general: sequences of items, not jus= t of characters)

 

FP: First question is: Is the work useful? Onc= e we answer that, if the answer is yes, we can move to next question: shoul= d it be delayed?

 

CB: PCRE is not currently defined in a normati= ve spec, even if it is the right one. 

 

Alexey Melnikov: One of the sip docs has this = -

 

JH: One of the ECMA has a slightly less powerf= ul/expressive version.

 

[ACTION ITEM]: Alexey to look for regex normat= ive reference document

 

See also the wrap-up

 

   

* CBOR specification status [30'] : Carsten

  https://tools.ietf.org/html/draft-ietf-= cbor-7049bis-01

 

  Taking CBOR to full Internet stand= ard (don't change it)

 

  The only really new part is the on= e about CBOR data model ("the biggest failing of JSON")

  

  Reminder that not all extensions&n= bsp; are mandatory in CBOR. Except false and true and null :-)

 

SL: Currently document says undefined is a cor= e element -

CB: Need to look - Expects undefined to be opt= ional

 

40 implementations (personal opinion: they var= y widely in quality, and level of maintenance)

 

Interoperability problem with the padding. Tag= s 22, 33, 34 no perfectly defined.Base64url typically used without padding,= Base64 often with padding. And case issue, also.

 

SL: Is there a canonicalization reason for mak= ing the decision?

 

Dave Thaler: Does anybody care?  Yes OCF = does want to be able to do this.  It uses both (or either) JSON-Schema= and Swagger to specify things in JSON but puts CBOR on wire - Both Json Schema and Swagger define BASE64 but not BASE64url. = TinyCBOR maintainer would love to fix that if either json-schema or swagge= r added spec support for base64url.

Thinks the proposal should be fine - needs to = check - look at tiny-CBOR https://github.com/intel/tinycbor

 

 

Matt Miller: Safest to keep the padding for ba= se64

 

JH: Argue to remove all Base64 because you hav= e binary and don't need it.  The tags could be removed from standard.<= o:p>

   

[ACTION ITEM] Put base64 issue on the mailing = list

 

[ACTION ITEM] Jim does PeterO implementation i= n matrix

[ACTION ITEM] DT to poke tinyCBOR author (Thia= go Macieira) to fill in implementation matrix for tinycbor

   

* OID Tags [10'] : Carsten, Sean

  https://tools.ietf.org/html= /draft-bormann-cbor-tags-oid-06

 

Many tags (besides the ones in RFC 7049), some= times in RFC; sometimes not. Some are on-charter but not all.

 

* Array Tags [10'] : Carsten=

  https://tools.ietf.org/html/draft-jroat= ch-cbor-tags-06

 

  Careful on the encoding: the space= is not unlimited

 

JH: General concept of - one big thing plus lo= ts of variations - may want to have a pattern version - example two item ar= ray - first item is format, second is data

Could do this type of pattern here.=

 

SL: The fact that tagging is optional may make= the case of a small array (such as an RGB) value having a large tag normal= ly for an array of bytes would be easier.

 

JH: Having a document on when and how to use t= ags as suggested by SL would be useful

 

FP: Blocking issue on adoption at the last mee= ting was people who read and reviewed.

 

Consensus on 3-bytes tags, it seems=

 

* Time Tags [5'] : Carsten

  https://tools.ietf.org/html/draft-borma= nn-cbor-time-tag-01

 

Document tag 1001, if the WG agrees=

 

CB: Should we allow this as an independent or = wait and then do this

AM: Do current things first, but no other opin= ion.

 

Who wants to work on time formats? Three peopl= e.

JH: this is not enough

 

* Wrap-up [10'] : Chairs

 

JH:  How many people think we need to do = much more work on CDDL before going out - (none?)

How many people think we should polish and cal= l it good - many hands

Request of Alexey to look for people wanting t= o use CDDL for JSON schema. - need more review of Appendix B.

 

Things that need to be looked at - if no refer= ence RE should be on the bubble.

Rip out features w/o full consensus and can be= put into the next version of CDDL.

 

Need to have something that talks about the di= fference between a validation compiler and a documentation of what the lang= uage should to be.  This ought to be added to the Philosophy document that SL volunteered for.

 

--_000_HE1PR07MB1529D16DE80A628FE79C4F72983B0HE1PR07MB1529eurp_-- From nobody Thu Nov 30 14:14:41 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA09120227 for ; Thu, 30 Nov 2017 14:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 RN7be9yJj9T2 for ; Thu, 30 Nov 2017 14:14:36 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 A1A63126BF6 for ; Thu, 30 Nov 2017 14:14:36 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id d137so298090itc.2 for ; Thu, 30 Nov 2017 14:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nEhFga+kZsJMoq9PhZ4E9qip7HxZkPgWePPnO16IZsM=; b=dce/BKMICb6gKpj+YG7T4p5+naMFEkEzD4kh72EzzuHmRyjK3lNFWoVfVEWuqYaKtl 7GFA2oHvh/F04E8WABAt8iHa/8J7/1+9b+xIl5hWdELXIpDQSW4/LB6vobE6kCvT8JBA DTCjYWeKIRgGm5ucu+Yu2jx3NeVJrCbH/c2rI= 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=nEhFga+kZsJMoq9PhZ4E9qip7HxZkPgWePPnO16IZsM=; b=VwE98X23FlcWyUuIkiPYhBrdBDSfxOe/Xd7wvhUvg9PXODwu8R8wvVw0EByq9le1xK fkeLY1hKAmxDmJ6QlbX4c9QO4DizjAjtQ56sP7QlFOQMyH+fPqTSnxTq11fu/GmwuPxj s74aWLkJSU51o/pokWF8p55zni5wEKCjhTiXvVfAsDI2MLZKgUG9c5friQFjKR6MBePD +E8/J9dB7dHMOlLpaY6CH+FsPrNL13H72VkwJxFehPnxNBdRAjtj4MNWQR5xC5B7lu0l R1GU2zuVzGRjolMuHobfDYsQrt4sv5wx5DhksQUZoKHo0iLYs0qnbUjuofi3jiCEoCHj klaw== X-Gm-Message-State: AJaThX7PUsiHEvFhwlDCRubMHPVJ5QoMi1/XyXlFoBIiUvu5S3pptw+i kEjwuZdVuJGEneYPFvF//sG72YmqOn+HG+E+6ZKg0/cOsAI= X-Google-Smtp-Source: AGs4zMaUJp57gVYtF7NCEkGBAiwmVLNjPQ32IqcOvNhPNxzb0cnacs/WG4raGuxCZsILln6REfOnkTGrFGDfmAQ9pKo= X-Received: by 10.36.70.146 with SMTP id j140mr5817690itb.66.1512080075469; Thu, 30 Nov 2017 14:14:35 -0800 (PST) MIME-Version: 1.0 References: <012801d32f2e$a95aaf10$fc100d30$@augustcellars.com> <7C19E4CE-32E2-44B2-BD44-1BAA48190674@tzi.org> <013a01d32fcb$ac8cede0$05a6c9a0$@augustcellars.com> In-Reply-To: From: Jeffrey Yasskin Date: Thu, 30 Nov 2017 22:14:22 +0000 Message-ID: To: Francesca Palombini Cc: cbor@ietf.org, hildjj@cursive.net, aamelnikov@fastmail.fm Content-Type: multipart/alternative; boundary="001a1144b8e6c5f852055f3a9336" Archived-At: Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested Canonicalization X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 22:14:39 -0000 --001a1144b8e6c5f852055f3a9336 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Belatedly, I've discovered a user of "canonical" CBOR who's proposing a different map order than the RFC suggests: https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-client-to-authent= icator-protocol-v2.0-rd-20170927.html#message-encoding. (Note that this isn't a final standard yet and may change.) This is justified by the RFC saying that "Those protocols are free to define what they mean by a canonical format and what encoders and decoders are expected to do. This section lists some suggestions for such protocols." That is (as Jim said), the RFC doesn't specify "canonical" CBOR: it just provides an option for higher-level protocols to do so. The use of a different order in CTAP is going to either force its implementers to write custom CBOR encoders and decoders or require the generic encoders to take a configuration option for the map order. If the generic encoders take an option, then it stops being an issue for CBORbis to suggest a different order. --- On the question of *which* order, it may be instructive to look at the current Chromium implementation: https://cs.chromium.org/chromium/src/content/browser/webauth/cbor/cbor_valu= es.h?l=3D27&rcl=3D9c334c65915ec312ae1e13c4da9285ee8c58735b We currently have serializations and deserializations create a C++ datastructure representing the CBOR value, and maps are represented by a std::map<> whose comparator implements the canonical order. This is not as high-performance as it could be, but it does allow the encoder to guarantee that its output is well-formed without relying on its caller to maintain any invariants. However, once we add support for more than just string keys, having the comparison check the keys' serializations' lengths first looks like it's going to make us allocate space for the serializations inside the comparator. i.e. O(log N) allocations for a tree lookup instead of just O(log N) comparisons. There are ways around this, but they appear to involve having each CBORValue object cache its serialization, which isn't pretty either. An ordering that doesn't compare the length first (e.g. Jim's memcmp suggestion) seems like it'll be more amenable to optimizations. Jeffrey On Thu, Oct 5, 2017 at 4:20 AM Francesca Palombini < francesca.palombini@ericsson.com> wrote: > Hi, > > (chair-hat on) I would really like to hear the opinion of the working > group on this one. > Please make sure you read through the mail thread and express your > thoughts. > > Thanks, > Francesca > > > -----Original Message----- > > From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann > > Sent: den 17 september 2017 20:08 > > To: Jim Schaad > > Cc: cbor@ietf.org; core@ietf.org WG > > Subject: Re: [core] draft-ietf-cbor-7049bis - Change suggested > > Canonicalization > > > > Hi Jim, > > > > I do share your frustration a bit, because I do believe the canonical > map key > > sorting order is one of the very few things we didn=E2=80=99t quite get= right > about RFC > > 7049. The question about fixing this really is procedurally, can we fi= x > it, and > > what is the impact on people who are now using the old order. > > > > > I complained that this was not a good sorting order before RFC 7049 w= as > > published, so this is not a new issue. I wish that I could find the > mails from > > the time as my memory was that you said we could discuss it on the next > > version which is what I am trying to do. > > > > I must admit I don=E2=80=99t remember that discussion (it would have be= en more > > than four years in the past) and my mail program apparently doesn=E2=80= =99t > either. > > > > (My mail program does remember errata report 4409 from July 2015, where > > you did propose another sorting order.) > > > > >> Why do you think the values need to be in there, too? > > >> Map keys must be different, so the value never can have an effect, > > > > > > That is from below - where you could have multiple duplicate keys. I= t > is > > very possible people will do this even if it is not a valid encoding. > > > > The reason why 7049 does not outright make emitting duplicate keys a > > conformance issue is that, in a streaming implementation, it is hard to > check > > for duplicate keys. That argument does not apply to an implementation > that > > has to sort map member keys to achieve a canonical encoding. So, while > > creating canonical encoding, the implementation can also check for key > > duplication and raise an error if that happens. > > > > >> Now, if it were mid-2013, I would just agree with you, change the > > >> draft, and ask the WG (at the time appsawg) whether there are any > > further comments. > > > > > > Given that you did not agree with me at the time when I raised this > issue, I > > would disagree with this statement. > > > > Well, I probably should have said =E2=80=9Cknowing what I know now=E2= =80=9D (i.e., the > > degree of POLS violation that the current rules pose) I would agree wit= h > you. > > (At the time, the definition we now have in RFC 7049 appeared to be > > expedient.) > > > > >> Unfortunately, CBOR has been out there, we are on the way to an > > >> Internet STD, and the current canonicalization is what=E2=80=99s imp= lemented > > >> (at least in a couple of places). If we change this, we have to tak= e > > >> canonicalization out from the STD and put it into a separate > specification. > > >> We could decide to do this, but I=E2=80=99m not sure that this helps= . (We=E2=80=99ll > > >> also have the CER vs. DER situation again.) > > > > > > I do not believe that changing this would in any way stop the > advancement > > to STD. > > > > Now that (i.e., just going ahead and changing things here) is an > interesting > > thought. > > > > One problem with that is that in the IETF, the IESG is the gating > function, and > > it is sufficient for a single member of the IESG to disagree with this > thought to > > hold up the process. > > > > > This section is completely non-normative there is not a single > normative > > statement in the entire section. Nor is the set of rules complete given > that > > there are two paragraphs at the end which have additional rules that > "might" > > need to be added. Making this one change would not alter the fact that > it is > > non-normative and incomplete. > > > > Filling in those blanks might be another argument for going ahead and > > writing a separate document about canonicalized CBOR instead. > > > > > There is a possible multiple encoding issue that may come, but that i= s > > already implicit in the text of this section. The current text reads > "Those > > protocols are free to define what they mean by a canonical format and > what > > encoders and decoders are expected to do." Which means that multiple > > encodings are already not only possible but probably. I think that we > can get > > this fixed now and go forward with an obsoleted suggested > canonicalization > > and be fine. > > > > > > The suggested algorithm is far easier to understand, easier to get > right and > > also has some advantages where one can do the canonicalization without > > having to do the encoding first. > > > > > > int CompareNodes(node1, node2) > > > if node1.majorMode !=3D node2.majorMode then return node1.majorMode > > - node2.majorMode; > > > if node1.majorMode has a length field and node1.length !=3D > node2.length > > then return node1.length - node2.length; > > > return compare node1 and node2 values - this is major mode dependen= t. > > > > > > With the current method, you need to do a lot more work to try and ge= t > > things in the correct order if you have any mixing of major modes, whic= h > is > > now very common place despite the statement that this is probably a bad > > practice. > > > > Indeed, this is one thing we have learned since 2013: There are quite > good > > reasons for mixing major types in the keys of a single map. > > > > > If you have to emit all of the keys, sort them and then remember the > > original order to emit the values, it is harder than concatenating the > entire > > thing and then emitting the values after doing the sort. You are going > to > > need to keep some type of more complex structure - and thus more code- = to > > do the emission in the generic case. Yes for a small fixed set of keys > this is > > not necessary but I do not believe that is where a good canonicalizatio= n > > routine is going to be needed. > > > > Here is my implementation of a pre-canonicalizer for maps from the cbor= - > > canonical gem (the type =E2=80=9CHash=E2=80=9D in Ruby is an order-pres= erving map, so we > > can do all this entirely at the data model level): > > > > def cbor_pre_canonicalize > > Hash[collect {|k, v| > > k =3D k.cbor_pre_canonicalize > > v =3D v.cbor_pre_canonicalize > > cc =3D k.to_cbor # already canonical > > [cc.size, cc, k, v]}.sort.collect{|s, cc, k, v| > [k, v]}] > > end > > > > A sorting rule that is entirely based on (byte-wise) lexical ordering > would > > enable pre-sorting on types =E2=80=94 there often would be no need to g= enerate > the > > entire key encoding for sorting. But then, you have to generate them > > anyway, so the additional overhead is mostly a matter of memory > > allocation/copying. > > > > Here is an (untested) implementation of what I think you are proposing: > > > > def cbor_pre_canonicalize > > Hash[collect {|k, v| > > k =3D k.cbor_pre_canonicalize > > v =3D v.cbor_pre_canonicalize > > cc =3D k.to_cbor # already canonical > > [cc, k, v]}.sort.collect{|cc, k, v| [k, v]}] > > end > > > > I.e., the size of the key encoding is removed from the list of things t= o > sort for. > > > > > I strongly urge that this change be done even if it might hurt > backwards > > compatibility and the sooner we make the decision to do it the better a= s > it > > reduces the number of people who will do it wrong. > > > > Now whether we should do this or not is a good question for the CBOR WG > > to look at. > > > > (I=E2=80=99ve added the WG back to the recipient list.) > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > --001a1144b8e6c5f852055f3a9336 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Belatedly, I've discovered a user of "canonical&q= uot; CBOR who's proposing a different map order than the RFC suggests:= =C2=A0ht= tps://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-client-to-authentic= ator-protocol-v2.0-rd-20170927.html#message-encoding. (Note that this i= sn't a final standard yet and may change.)

This is j= ustified by the RFC saying that "Those protocols are free to define wh= at they mean by a canonical format and what encoders and decoders are expec= ted to do.=C2=A0 This section lists some suggestions for such protocols.&qu= ot; That is (as Jim said), the RFC doesn't specify "canonical"= ; CBOR: it just provides an option for higher-level protocols to do so.

The use of a different order in CTAP is going to eith= er force its implementers to write custom CBOR encoders and decoders or req= uire the generic encoders to take a configuration option for the map order.= If the generic encoders take an option, then it stops being an issue for C= BORbis to suggest a different order.

---

On the question of *which* order, it may be instructive to = look at the current Chromium implementation:=C2=A0https://cs.chromium.org/c= hromium/src/content/browser/webauth/cbor/cbor_values.h?l=3D27&rcl=3D9c3= 34c65915ec312ae1e13c4da9285ee8c58735b

We curre= ntly have serializations and deserializations create a C++ datastructure re= presenting the CBOR value, and maps are represented by a std::map<> w= hose comparator implements the canonical order. This is not as high-perform= ance as it could be, but it does allow the encoder to guarantee that its ou= tput is well-formed without relying on its caller to maintain any invariant= s. However, once we add support for more than just string keys, having the = comparison check the keys' serializations' lengths first looks like= it's going to make us allocate space for the serializations inside the= comparator. i.e. O(log N) allocations for a tree lookup instead of just O(= log N) comparisons. There are ways around this, but they appear to involve = having each CBORValue object cache its serialization, which isn't prett= y either.

An ordering that doesn't compare the= length first (e.g. Jim's memcmp suggestion) seems like it'll be mo= re amenable to optimizations.

Jeffrey


On Thu, O= ct 5, 2017 at 4:20 AM Francesca Palombini <francesca.palombini@ericsson.com> wrote:
<= /div>
Hi,

(chair-hat on) I would really like to hear the opinion of the working group= on this one.
Please make sure you read through the mail thread and express your thoughts= .

Thanks,
Francesca

> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann
> Sent: den 17 september 2017 20:08
> To: Jim Schaad <ietf@augustcellars.com>
> Cc: cbor@ietf.org; core@ietf.org WG= <core@ietf.org&g= t;
> Subject: Re: [core] draft-ietf-cbor-7049bis - Change suggested
> Canonicalization
>
> Hi Jim,
>
> I do share your frustration a bit, because I do believe the canonical = map key
> sorting order is one of the very few things we didn=E2=80=99t quite ge= t right about RFC
> 7049.=C2=A0 The question about fixing this really is procedurally, can= we fix it, and
> what is the impact on people who are now using the old order.
>
> > I complained that this was not a good sorting order before RFC 70= 49 was
> published, so this is not a new issue.=C2=A0 I wish that I could find = the mails from
> the time as my memory was that you said we could discuss it on the nex= t
> version which is what I am trying to do.
>
> I must admit I don=E2=80=99t remember that discussion (it would have b= een more
> than four years in the past) and my mail program apparently doesn=E2= =80=99t either.
>
> (My mail program does remember errata report 4409 from July 2015, wher= e
> you did propose another sorting order.)
>
> >> Why do you think the values need to be in there, too?
> >> Map keys must be different, so the value never can have an ef= fect,
> >
> > That is from below - where you could have multiple duplicate keys= .=C2=A0 It is
> very possible people will do this even if it is not a valid encoding.<= br> >
> The reason why 7049 does not outright make emitting duplicate keys a > conformance issue is that, in a streaming implementation, it is hard t= o check
> for duplicate keys.=C2=A0 That argument does not apply to an implement= ation that
> has to sort map member keys to achieve a canonical encoding.=C2=A0 So,= while
> creating canonical encoding, the implementation can also check for key=
> duplication and raise an error if that happens.
>
> >> Now, if it were mid-2013, I would just agree with you, change= the
> >> draft, and ask the WG (at the time appsawg) whether there are= any
> further comments.
> >
> > Given that you did not agree with me at the time when I raised th= is issue, I
> would disagree with this statement.
>
> Well, I probably should have said =E2=80=9Cknowing what I know now=E2= =80=9D (i.e., the
> degree of POLS violation that the current rules pose) I would agree wi= th you.
> (At the time, the definition we now have in RFC 7049 appeared to be > expedient.)
>
> >> Unfortunately, CBOR has been out there, we are on the way to = an
> >> Internet STD, and the current canonicalization is what=E2=80= =99s implemented
> >> (at least in a couple of places).=C2=A0 If we change this, we= have to take
> >> canonicalization out from the STD and put it into a separate = specification.
> >> We could decide to do this, but I=E2=80=99m not sure that thi= s helps.=C2=A0 (We=E2=80=99ll
> >> also have the CER vs. DER situation again.)
> >
> > I do not believe that changing this would in any way stop the adv= ancement
> to STD.
>
> Now that (i.e., just going ahead and changing things here) is an inter= esting
> thought.
>
> One problem with that is that in the IETF, the IESG is the gating func= tion, and
> it is sufficient for a single member of the IESG to disagree with this= thought to
> hold up the process.
>
> > This section is completely non-normative there is not a single no= rmative
> statement in the entire section. Nor is the set of rules complete give= n that
> there are two paragraphs at the end which have additional rules that &= quot;might"
> need to be added.=C2=A0 Making this one change would not alter the fac= t that it is
> non-normative and incomplete.
>
> Filling in those blanks might be another argument for going ahead and<= br> > writing a separate document about canonicalized CBOR instead.
>
> > There is a possible multiple encoding issue that may come, but th= at is
> already implicit in the text of this section.=C2=A0 The current text r= eads "Those
> protocols are free to define what they mean by a canonical format and = what
> encoders and decoders are expected to do." Which means that multi= ple
> encodings are already not only possible but probably.=C2=A0 I think th= at we can get
> this fixed now and go forward with an obsoleted suggested canonicaliza= tion
> and be fine.
> >
> > The suggested algorithm is far easier to understand, easier to ge= t right and
> also has some advantages where one can do the canonicalization without=
> having to do the encoding first.
> >
> > int CompareNodes(node1, node2)
> >=C2=A0 =C2=A0if node1.majorMode !=3D node2.majorMode then return n= ode1.majorMode
> - node2.majorMode;
> >=C2=A0 =C2=A0if node1.majorMode has a length field and node1.lengt= h !=3D node2.length
> then return node1.length - node2.length;
> >=C2=A0 =C2=A0return compare node1 and node2 values - this is major= mode dependent.
> >
> > With the current method, you need to do a lot more work to try an= d get
> things in the correct order if you have any mixing of major modes, whi= ch is
> now very common place despite the statement that this is probably a ba= d
> practice.
>
> Indeed, this is one thing we have learned since 2013: There are quite = good
> reasons for mixing major types in the keys of a single map.
>
> > If you have to emit all of the keys, sort them and then remember = the
> original order to emit the values, it is harder than concatenating the= entire
> thing and then emitting the values after doing the sort.=C2=A0 You are= going to
> need to keep some type of more complex structure - and thus more code-= to
> do the emission in the generic case.=C2=A0 Yes for a small fixed set o= f keys this is
> not necessary but I do not believe that is where a good canonicalizati= on
> routine is going to be needed.
>
> Here is my implementation of a pre-canonicalizer for maps from the cbo= r-
> canonical gem (the type =E2=80=9CHash=E2=80=9D in Ruby is an order-pre= serving map, so we
> can do all this entirely at the data model level):
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0def cbor_pre_canonicalize
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hash[collect {|k, v|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0k =3D k.cbor_pre_canonicalize
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0v =3D v.cbor_pre_canonicalize
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0cc =3D k.to_cbor # already canonical
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[cc.size, cc, k, v]}.sort.collect{|s, cc, k, v| [k, v]}]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0end
>
> A sorting rule that is entirely based on (byte-wise) lexical ordering = would
> enable pre-sorting on types =E2=80=94 there often would be no need to = generate the
> entire key encoding for sorting.=C2=A0 But then, you have to generate = them
> anyway, so the additional overhead is mostly a matter of memory
> allocation/copying.
>
> Here is an (untested) implementation of what I think you are proposing= :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0def cbor_pre_canonicalize
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hash[collect {|k, v|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0k =3D k.cbor_pre_canonicalize
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0v =3D v.cbor_pre_canonicalize
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0cc =3D k.to_cbor # already canonical
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[cc, k, v]}.sort.collect{|cc, k, v| [k, v]}]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0end
>
> I.e., the size of the key encoding is removed from the list of things = to sort for.
>
> > I strongly urge that this change be done even if it might hurt ba= ckwards
> compatibility and the sooner we make the decision to do it the better = as it
> reduces the number of people who will do it wrong.
>
> Now whether we should do this or not is a good question for the CBOR W= G
> to look at.
>
> (I=E2=80=99ve added the WG back to the recipient list.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>
> _______________________________________________
> core mailing list
> core@ietf.org > https://www.ietf.org/mailman/listinfo/core
_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
--001a1144b8e6c5f852055f3a9336--