From matt@endpoint.com Tue Nov 6 13:58:22 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA82126CC7 for ; Tue, 6 Nov 2018 13:58:22 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=endpoint.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 m9nl7BRIDVXG for ; Tue, 6 Nov 2018 13:58:20 -0800 (PST) Received: from mail.endcrypt.com (mail.endcrypt.com [IPv6:2607:f0d0:1301:23::3]) (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 95BD91288BD for ; Tue, 6 Nov 2018 13:58:20 -0800 (PST) Received: from [192.168.1.8] (96-33-3-51.dhcp.jcsn.tn.charter.com [96.33.3.51]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.endcrypt.com (Postfix) with ESMTPSA id 6A4B7833F2 for ; Tue, 6 Nov 2018 21:58:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=endpoint.com; s=mail; t=1541541499; bh=cTnfLhX53NobyRCbOIivieZHPZv/DVHzJ3vC1VhhtkM=; h=To:From:Subject:Date:From; b=q0R5INGH4f3JBu0TtOBRqXKY/TpNdzkXP5j/+taea1GYGNg7nWZXoJHCTMo4nZR/A muY34xsIbQxSpVP3rF+mgWcJ+QZxsAVg43fLXMxcr4eaqckKMqQIYZP2DdD2DUw66i jaLcTdnBIok84xwGjJqHYzEmyQf6O58dyXgMkDkfnUPAVY0RBq1ZTMu0W/SaFtNk4u U3Bw9WlIOXCtLvHn6e+3XPeLfwSoNNcOYzXUm+HLSdoojYPwhYupIkMG1pWB5GtrIg YGsuffKPaSP6oYgEoJxF3qYasQCPPsAQByWe9EtfAjyqedrMSCIHx+kJ0qMx+OAIHH NGXmIkGnpenyQ== To: cbor@ietf.org From: Matt Vollrath Message-ID: <299e007c-10e5-d4cc-afd6-aac45fc3c54a@endpoint.com> Date: Tue, 6 Nov 2018 16:58:18 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Cbor] Question about CBOR padding X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 22:00:43 -0000 Hello list, I'm finding CBOR extremely useful for moving large binary blobs (specifically: ROS point clouds) into browsers via WebSocket. While hacking on a CBOR integration, I ran into something that the spec doesn't seem to cover. How should CBOR data be padded, if I were to do something weird like pack it into a PNG?  Believe it or not, the previous implementation packed JSON into PNG with \n padding to complete the last pixel.  I didn't see anything in the spec about padding, except the mention that UBJSON has an explicit noop code. I don't intend to wrap CBOR in PNG (per-message deflate is a much better way to get the same compression over ws), but thought the lack of an explicit padding solution was worth asking about. Thanks and keep up the good work, Matt Vollrath End Point Corp From nobody Tue Nov 6 14:25:17 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C153E130DC1 for ; Tue, 6 Nov 2018 14:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-Pfe7cqmIsx for ; Tue, 6 Nov 2018 14:25:13 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD311271FF for ; Tue, 6 Nov 2018 14:25:12 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 14:25:11 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,473,1534834800"; d="scan'208";a="103980313" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga004.fm.intel.com with ESMTP; 06 Nov 2018 14:25:11 -0800 Received: from tjmaciei-mobl1.localnet (10.7.197.62) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 6 Nov 2018 14:25:11 -0800 From: Thiago Macieira To: Date: Tue, 6 Nov 2018 14:25:11 -0800 Message-ID: <3153512.GtUnpKuXoF@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <299e007c-10e5-d4cc-afd6-aac45fc3c54a@endpoint.com> References: <299e007c-10e5-d4cc-afd6-aac45fc3c54a@endpoint.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.7.197.62] Archived-At: Subject: Re: [Cbor] Question about CBOR padding X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 22:25:16 -0000 On Tuesday, 6 November 2018 13:58:18 PST Matt Vollrath wrote: > Hello list, > > I'm finding CBOR extremely useful for moving large binary blobs > (specifically: ROS point clouds) into browsers via WebSocket. While > hacking on a CBOR integration, I ran into something that the spec > doesn't seem to cover. > > How should CBOR data be padded, if I were to do something weird like > pack it into a PNG? Believe it or not, the previous implementation > packed JSON into PNG with \n padding to complete the last pixel. I > didn't see anything in the spec about padding, except the mention that > UBJSON has an explicit noop code. CBOR has no need for padding and it does not have any byte sequence that can fill in for padding. Some CBOR decoders will simply stop when they've finished reading the one element, ignoring anything remaining in the buffer. If you know this is your case, then simply append anything you want until you reach the boundary you ant. Other decoders will report garbage at the end. If this is a possibility for your file format, you should design your container so you know where the actual CBOR data ends and so you can feed the decoder no padding. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Tue Nov 6 15:05:50 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C5F130E09; Tue, 6 Nov 2018 15:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 DVXdHv7Hg3cj; Tue, 6 Nov 2018 15:05:40 -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 51A40130E11; Tue, 6 Nov 2018 15:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wA6N5R2V024609; Wed, 7 Nov 2018 00:05:32 +0100 (CET) Received: from [IPv6:2001:67c:1232:144:5806:ec29:caf1:467b] (unknown [IPv6:2001:67c:1232:144:5806:ec29:caf1:467b]) (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 42qQBF3Tt3z1Bqf; Wed, 7 Nov 2018 00:05:25 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <5BAE5278.9060005@gmail.com> Date: Wed, 7 Nov 2018 06:05:20 +0700 Cc: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-cbor-cddl.all@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 563238319.030874-67ebffb30a8d9e341cbc27ad2556a927 Content-Transfer-Encoding: quoted-printable Message-Id: <7DEE4371-FA16-490B-B148-7E237DA5308E@tzi.org> References: <5BAE5278.9060005@gmail.com> To: Chris Lonvick X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] SECDIR review of draft-ietf-cbor-cddl-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 23:05:44 -0000 Hi Chris, thank you for this review. > On Sep 28, 2018, at 23:10, Chris Lonvick = wrote: >=20 > Hello, >=20 > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments.=20 >=20 > The summary of the review is READY with nits. >=20 > I skimmed through the draft and agree with the author's statement in = the first paragraph of the Security Considerations section: > This document presents a content rules language for expressing CBOR > data structures. As such, it does not bring any security issues on > itself, although specification of protocols that use CBOR naturally > need security analysis when defined. >=20 > (As a very minor nit, I'd suggest using "analyses" rather than = "analysis".) >=20 > Nit 1: The authors have made a good effort at identifying some of the = topics that may be considered in a security considerations section of = specifications that use protocols using CDDL to define CBOR structures. = However, I would recommend that those bullet points be used to = supplement a normative reference to RFC 3552 =E2=80=9CSecurity = Considerations Guidelines".=20 >=20 > Perhaps adding the following between the first and second paragraphs: > Guidelines for writing security considerations are defined in = Security Considerations Guidelines [RFC 3552]=20 > (BCP 72). Implementers using CDDL to define CBOR structures in = protocols must follow those guidelines. >=20 > Then change the start of the second paragraph from =E2=80=9CTopics = that may be..." to "Additional topics that may be..." I think this is a very good idea. It is now addressed (with slightly = different wording) in = https://github.com/cbor-wg/cddl/commit/d3b2483f1b7a94eb9ba9cab22143c43f1be= 8909d (which will be in -06). > Nit 2: I am not very familiar with all of this, but it seems to me = that RFC 8152, "CBOR Object Signing and Encryption (COSE)" should be a = normative reference rather than an informative reference, and some = mention should be made of it in the Security Considerations section. = Reference is made in RFC 8152 to CDDL (4th paragraph in Section 1.3): > As well as the prose description, a version of a CBOR grammar is > presented in CDDL. Since CDDL has not been published in an RFC, = this > grammar may not work with the final version of CDDL. The CDDL > grammar is informational; the prose description is normative. >=20 > I may be off base here, but it just seems that since 8152 has been = published as a Standards Track document, then this draft should = normatively reference it and any subsequent updates to 8152 should = normatively reference the Standards Track RFC issuing from this draft.=20= It is indeed true that COSE (RFC 8152) uses CDDL, and even goes ahead to = quickly define the subset it uses in its section 1.3 (with the slightly = confusing title =E2=80=9CCBOR grammar=E2=80=9D). That does not make the COSE specification a normative reference for CDDL = though =E2=80=94 many protocols specified in CDDL will not make use of = COSE, and those that do will rightly reference COSE as a normative = reference. There is no need to read section 1.3 of RFC 8152 to use the = specification of CDDL. I do agree that a COSEbis (which might be started about now) could use = the specification of CDDL as a normative reference (if the downref is = accepted), but we don=E2=80=99t have to have a position on that now. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Nov 6 15:52:15 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A572124D68; Tue, 6 Nov 2018 15:52:14 -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 PXmegTsnfgwg; Tue, 6 Nov 2018 15:52:11 -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 3DF12124C04; Tue, 6 Nov 2018 15:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wA6Nq0v6028779; Wed, 7 Nov 2018 00:52:05 +0100 (CET) Received: from [IPv6:2001:67c:1232:144:5806:ec29:caf1:467b] (unknown [IPv6:2001:67c:1232:144:5806:ec29:caf1:467b]) (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 42qRCy2FQpz1Bqf; Wed, 7 Nov 2018 00:51:58 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <153817214335.26462.1312093989723950989@ietfa.amsl.com> Date: Wed, 7 Nov 2018 06:51:54 +0700 Cc: gen-art@ietf.org, cbor@ietf.org, ietf@ietf.org, draft-ietf-cbor-cddl.all@ietf.org X-Mao-Original-Outgoing-Id: 563241113.127156-ce1017678aa6e4d3e1fe46e83e583be6 Content-Transfer-Encoding: quoted-printable Message-Id: <10456266-70D0-43FD-8FB2-00A5EF01A6A4@tzi.org> References: <153817214335.26462.1312093989723950989@ietfa.amsl.com> To: Ines Robles X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Genart last call review of draft-ietf-cbor-cddl-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 23:52:14 -0000 Hi Ines, Thank you very much for the review and the slight embarrassment it = causes to the authors=E2=80=A6 Comment 3 below we will pick up in the WG meeting today; I=E2=80=99ll = report about that later. The other comments are now addressed in the editor=E2=80=99s copy: https://github.com/cbor-wg/cddl/commits/master (Individual commits referenced below; the CI build is failing right now = because of a weird connectivity issue.) We plan to submit the fixes as part of -06 early next week. Gr=C3=BC=C3=9Fe, Carsten > On Sep 29, 2018, at 05:02, Ines Robles = wrote: >=20 > Reviewer: Ines Robles > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-cbor-cddl-05 > Reviewer: Ines Robles > Review Date: 2018-09-28 > IETF LC End Date: 2018-10-04 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: >=20 > I believe the draft is technically good. This document is well written = and > clear to understand. >=20 > The document proposes a notational convention named Concise data = definition > language (CDDL) to express Concise Binary Object Representation (CBOR) = data > structures. Its main goal is to provide an easy and unambiguous way to = express > structures for protocol messages and data formats that use CBOR or = JSON. >=20 > I have some minor questions. The document presents nits that should be = solved > before publication. >=20 > Major issues: Not found. >=20 > Minor issues: Not found. >=20 > Nits/editorial comments: >=20 > 1)-Abstract: It would be nice to expand CBOR the first time that it is > mentioned. Indeed. Fixed in 88e9a00 > 2)-Section 2: Page 8, You mention anonymous group. > Does it would be a good definition for an anonymous group?: =E2=80=9CLis= ts of > group_entries_ (between curly braces)that can be assigned to any type = of > composition (arrays, maps)=E2=80=9D The groups are anonymous because they are used right away in a pair of = curly braces (for a map) or square brackets (for an array). The examples in this section all happen to be in braces. I=E2=80=99m not sure that =E2=80=9Canonymous group=E2=80=9D needs to be = defined as a separate term, though, because it is just that: a group = that is anonymous. > 3)- Section 2.2.2.1 - Page 11: the ordering I think is ascendant, = right? So, > maybe, would it be nice to add =E2=80=9Cnatural ordering = relationship=E2=80=9D? question: is > the following valid?: >=20 > Take-off =3D { > takeoffcounting=3D 10..0 ; Is it valid? Is it = applicable? > } The type constituted by the range does not have any ordering = relationship (except that implied by numbering in general). The example you give would not make a difference from saying 0..10 =E2=80=94= in both cases, the eleven numbers 0 to 10 constitute the type. It is probably not so good that the current text seems to leave open = whether 10..0 means the same as 0..10. (There is no obvious right answer, so we will discuss this in the CBOR = WG meeting today and come back.) > 4)- In this paragraph: =E2=80=9C...When using a name as the left hand = side of a range > operator, use spacing as in > "min .. max" to separate off the range operator...." > =3D> Question: Is =E2=80=9Cmin .. max" equivalent to "min=E2=80=9D .. = =E2=80=9Cmax"? Sorry for leading the reader into quoting hell. The quotes here are generated by XML2RFC to delimit a code span, i.e., = they identify the example. Maybe we should make small figures out of these (ignoring that some = people don=E2=80=99t like sentences running over figures). Fixed in a530564 >=20 > 5)- There are some mismatches between Appendix B and Appendix C: >=20 > Appendix B: cddl =3D S 1*(rule S) > Appendix C: cddl =3D S 1*rule > ------------------------------------------------------------ >=20 > Appendix B: > rule =3D typename [genericparm] S assignt S type > / groupname [genericparm] S assigng S grpent >=20 > Appendix C: > rule =3D typename [genericparm] S assignt S type S > / groupname [genericparm] S assigng S grpent S > ------------------------------------------------------------ >=20 > Appendix B: type =3D type1 *(S "/" S type1) > Appendix C: type =3D type1 S *("/" S type1 S) >=20 > ------------------------------------------------------------ > Appendix B: group =3D grpchoice *(S "//" S grpchoice) > Appendix C: group =3D grpchoice S *("//" S grpchoice S) >=20 > ------------------------------------------------------------ > Appendix B: grpchoice =3D *(grpent optcom) > Appendix C: grpchoice =3D *grpent >=20 > ------------------------------------------------------------ >=20 > Appendix B: grpent =3D [occur S] [memberkey S] type > Appendix C: grpent =3D [occur S] [memberkey S] type optcom >=20 > ------------------------------------------------------------ >=20 > Appendix B: / [occur S] groupname [genericarg] ; preempted = by above > Appendix C: / [occur S] groupname [genericarg] optcom ; = preempted by > above >=20 > ------------------------------------------------------------ >=20 > Appendix B: / [occur S] "(" S group S ")" > Appendix C: / [occur S] =E2=80=9C(" S group S ")" optcom This is the embarrassing part. We recently cleaned up the whitespace = processing in the ABNF a bit, and I was sure all the changes made it to = the matching appendix. D=E2=80=99oh. Another case of =E2=80=9Ca = feature isn=E2=80=99t there if it isn=E2=80=99t checked by continuous = integration checking=E2=80=9D. Fixed in bfdecd8 >=20 > 6)- It would be nice to expand I-JSON to (=E2=80=9CInternet JSON") in = page 54 Fixed in cc43317 Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Nov 6 20:00:18 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965C812785F for ; Tue, 6 Nov 2018 20:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ijzj5XsKv-5 for ; Tue, 6 Nov 2018 20:00:16 -0800 (PST) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (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 2221C127332 for ; Tue, 6 Nov 2018 20:00:16 -0800 (PST) Received: by mail-io1-f53.google.com with SMTP id f12-v6so10996092iog.0 for ; Tue, 06 Nov 2018 20:00:16 -0800 (PST) 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=TNOAPs/qhWsRjDeWMZ+D+o5S3fulOW1FAlzaE+rW4nE=; b=o7C41ZHCgWFE5d844PJFzokA6CkrqM9Z+83brpEdyw2G90bNUJT838UXXs98IMz7pe TFt/L9Onh1iezebM1TSKaqVOgmBpLo6icHeMnOMwzkPzKAC9ELXSVYob3x7XMTNfiD1f 3gEr8NS/YmyT3/wxITdS6nsvuytrEz2IXKYgBVdUmnF09+SQS9cb586qIXpCosF41CPX 9BJyYh6w75rdF1FrS6Rsa+AUiGlp1HyYz7YoafaDR9MJlwbbZS1xuQGZDNGuFHMbLuqO ezRdIW+14VccHZ9TUyhv4D/Brnu8vSJsien5G52H01/e3CRtuPqrcmtcwyR9Vo7e65UQ +65A== X-Gm-Message-State: AGRZ1gJt6OUs23t2SEP38ILbFTtL1jma4rXqQWeFghveKUdSa7vD/CHM vZMa67MNAW36OYR/VhbZUcLNH0/ziZt/VnE2KLLhxU0XtWc= X-Google-Smtp-Source: AJdET5eLDlygLgJlC9YADroPywZuY7C7ZVOzyQxMnxwXR9WZNdUIV6KHmRk5UgIstTCkhHP1xnmUSNF0tb2xdY5B2R8= X-Received: by 2002:a6b:3a89:: with SMTP id h131-v6mr215392ioa.76.1541563214505; Tue, 06 Nov 2018 20:00:14 -0800 (PST) MIME-Version: 1.0 From: Barry Leiba Date: Wed, 7 Nov 2018 11:00:03 +0700 Message-ID: To: cbor@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cbor] CBOR conference calls from IETF 103 to IETF 104 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 04:00:18 -0000 We decided in this morning's CBOR session at IETF 103 that we would like to continue the bi-weekly conference calls, as they have been keeping us moving forward apace (and that makes your chairs happy; a happy chair is a... well, a happy chair, I suppose). We chose a day/time in relative haste before, because we had limited time to get an announcement out and to get the calls started. This time, we'd like to do a broader poll of the working group to try to pick a time that works for as many of us as possible. To that end, I've created the following doodle poll: https://doodle.com/poll/c7fhqvqexr7kxnbp The poll specifies dates during the week of 10 Dec, but please DO NOT answer the poll with that specific week in mind. Use those days as days of the week for repeating calls, and let us know which days and times work for you. Please respond to the doodle by 16 November, and we'll pick a day/time and get an announcement out. We'll start the calls either in mid-December (the week of 10 Dec, as in the doodle) or in January (likely the week of 7 Jan). Barry From nobody Tue Nov 6 20:43:07 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F991277D2 for ; Tue, 6 Nov 2018 20:43:05 -0800 (PST) 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, 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 PAlnDAu81dNK for ; Tue, 6 Nov 2018 20:43:03 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C70A127148 for ; Tue, 6 Nov 2018 20:43:03 -0800 (PST) Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:370:1998:a11:96ff:fe01:81e0]) by relay.sandelman.ca (Postfix) with ESMTPS id 6FC181F8BD for ; Wed, 7 Nov 2018 04:43:01 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id D3B2DCBF; Wed, 7 Nov 2018 10:12:32 +0530 (IST) From: Michael Richardson To: cbor@ietf.org In-reply-to: <3153512.GtUnpKuXoF@tjmaciei-mobl1> References: <299e007c-10e5-d4cc-afd6-aac45fc3c54a@endpoint.com> <3153512.GtUnpKuXoF@tjmaciei-mobl1> Comments: In-reply-to Thiago Macieira message dated "Tue, 06 Nov 2018 14:25:11 -0800." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 07 Nov 2018 11:42:32 +0700 Message-ID: <22058.1541565752@dooku.sandelman.ca> Archived-At: Subject: Re: [Cbor] Question about CBOR padding X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 04:43:06 -0000 --=-=-= Content-Type: text/plain Thiago Macieira wrote: > CBOR has no need for padding and it does not have any byte sequence that can > fill in for padding. True. You could pad with a sized or series of indefinite length array that ended with no items. I think it's best to just read the first "element", and ignore the rest though. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlvibTgACgkQlUzhVv38 QpBheQf/WuI2RX+D4vZvXyUxyfVc0AZGsrQ8fceQP4izmTcMRDniFdkSia66gN1d loZqZKZHw3wz+AM9f4eOD50n6M0FoB+aElMwAw8ZMtCEwcRjK+HkxVO8vFwvj/wE elH0udirB5tO5VRBCWJukwDDzHEvC3qTSaswTReN7e4X2GAfFKkgZXnTDkQnBo4C qOwrkJjfymcd9qzCrVZD3v2US/zoeSpv2Il8oF1DF4FTP3Dm1n2U4527K2fRVneK V66GyvlBdmR2qa75Aoi8kIRquy870JnizRy+Jam/FOQEHMm3Oid/m9GKJUcEHK7V NxKrRLh0uj2V1skPzWHdgGUy+1j4qw== =bSli -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 6 21:24:46 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DED130E5A for ; Tue, 6 Nov 2018 21:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 13aV4yD29cgT for ; Tue, 6 Nov 2018 21:24:41 -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 6F08C130E19 for ; Tue, 6 Nov 2018 21:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wA75OXSO004306; Wed, 7 Nov 2018 06:24:38 +0100 (CET) Received: from [IPv6:2001:67c:370:128:115b:4c89:51b3:85c7] (unknown [IPv6:2001:67c:370:128:115b:4c89:51b3:85c7]) (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 42qZbh2s5Xz1Bqf; Wed, 7 Nov 2018 06:24:32 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <22058.1541565752@dooku.sandelman.ca> Date: Wed, 7 Nov 2018 12:24:27 +0700 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 563261065.9690059-c73ffa9a6cbc6e692d3b38be69c38d7e Content-Transfer-Encoding: quoted-printable Message-Id: <90003C23-5B0E-4745-8D8B-22ABB68B3CFA@tzi.org> References: <299e007c-10e5-d4cc-afd6-aac45fc3c54a@endpoint.com> <3153512.GtUnpKuXoF@tjmaciei-mobl1> <22058.1541565752@dooku.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Question about CBOR padding X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 05:24:44 -0000 When we did CBOR, we didn=E2=80=99t have a very good use case for = padding. I=E2=80=99m not sure we have one now; but let me mention that we have = some free codes that could be set aside for padding. So if the WG wants to define a version of CBOR that supports padding, I = have a proposal to pull out of the drawer. In this particular case, it sounds like a stop code (=E2=80=9Cno more = data following=E2=80=9D) would also do it. Gr=C3=BC=C3=9Fe, Carsten > On Nov 7, 2018, at 11:42, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Thiago Macieira wrote: >> CBOR has no need for padding and it does not have any byte sequence = that can >> fill in for padding. >=20 > True. >=20 > You could pad with a sized or series of indefinite length array that = ended > with no items. I think it's best to just read the first "element", = and > ignore the rest though. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 From nobody Wed Nov 7 09:06:46 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DEE12D4F1 for ; Wed, 7 Nov 2018 09:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=endpoint.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 sJOxEkPevCvu for ; Wed, 7 Nov 2018 09:06:44 -0800 (PST) Received: from mail.endcrypt.com (mail.endcrypt.com [IPv6:2607:f0d0:1301:23::3]) (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 7AFF6129C6A for ; Wed, 7 Nov 2018 09:06:44 -0800 (PST) Received: from [192.168.1.8] (96-33-3-51.dhcp.jcsn.tn.charter.com [96.33.3.51]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.endcrypt.com (Postfix) with ESMTPSA id BE99B803B4 for ; Wed, 7 Nov 2018 17:06:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=endpoint.com; s=mail; t=1541610403; bh=GwGIT6xc716d9FpQReJ+UpYi7HoDyySUmW9Bv810xBc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=aZajv90hW6XPMbe2U5cbeeFgoLydrRB7aOyOrS2tVjN/gxJpNcsqV30jmlO7fnDq2 tw1uRlVVa7Wh8IDqrXsh2DhwV98oSHiFzwdkuGjnkU+00PBaTCjRwHjaPjUu+PGm8G Oa22VXY2cinNKClSGJyDUEVwrer1pf/y3mgeH9Iku0nThpLizd28e0RRjngvSmgjDy aB3eN4z7TDuLokyANCLuEaBOFDYShKAqsd4i4YKZkBn6ed0BVblhfIWjJdGBBuEM/g 7/zzJGUxGPAB00HryfmtCNqxTIYklbZdXMl3KqePp4SiXADhuJjy/1qBfE6tDSHHka vekS45/Deu32Q== To: cbor@ietf.org References: From: Matt Vollrath Message-ID: Date: Wed, 7 Nov 2018 12:06:42 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A26EF5DA3CBBE6B8572EC387" Content-Language: en-US Archived-At: Subject: Re: [Cbor] Question about CBOR padding X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 17:06:46 -0000 This is a multi-part message in MIME format. --------------A26EF5DA3CBBE6B8572EC387 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Michael Richardson ; wrote: > Thiago Macieira ; wrote: >     > CBOR has no need for padding and it does not have any byte sequence that can >     > fill in for padding. > > True. > > You could pad with a sized or series of indefinite length array that ended > with no items.  I think it's best to just read the first "element", and > ignore the rest though. I agree with reading the first element and ignoring the rest. My experience with JavaScript CBOR libraries has not been kind, though.  Every library I've tested ('cbor', 'cbor-js', 'fast-cbor') fails when there are any trailing bytes, even when using a method that should only return the first element.  This behavior appears to be in line with the spec, which says that decoders can handle anomalous data basically however they like. The spec suggests that any attempt at padding is unsupported in 3.2: > CBOR data is well-formed if it uses > the initial bytes, as well as the byte strings and/or data items that > are implied by their values, in the manner defined by CBOR, and no > extraneous data follows (Appendix C). So it seems like if somebody has a good reason to stuff CBOR data into PNG pixels, they'll need to separately convey the number of bytes to chop off of the end or use a decoder implementation that specifically supports the case.  I can see how this makes the decoder implementation requirements leaner. The Python 'cbor' library gets a gold star for not being broken when there are trailing bytes. Thanks mv --------------A26EF5DA3CBBE6B8572EC387 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Michael Richardson <mcr+ietf@sandelman.ca>; wrote:
> Thiago Macieira <thiago.macieira@intel.com>; wrote:
>     > CBOR has no need for padding and it does not have any byte sequence that can
>     > fill in for padding.
>
> True.
>
> You could pad with a sized or series of indefinite length array that ended
> with no items.  I think it's best to just read the first "element", and
> ignore the rest though.

I agree with reading the first element and ignoring the rest.

My experience with JavaScript CBOR libraries has not been kind, though.  Every library I've tested ('cbor', 'cbor-js', 'fast-cbor') fails when there are any trailing bytes, even when using a method that should only return the first element.  This behavior appears to be in line with the spec, which says that decoders can handle anomalous data basically however they like.

The spec suggests that any attempt at padding is unsupported in 3.2:

> CBOR data is well-formed if it uses
> the initial bytes, as well as the byte strings and/or data items that
> are implied by their values, in the manner defined by CBOR, and no
> extraneous data follows (Appendix C).

So it seems like if somebody has a good reason to stuff CBOR data into PNG pixels, they'll need to separately convey the number of bytes to chop off of the end or use a decoder implementation that specifically supports the case.  I can see how this makes the decoder implementation requirements leaner.

The Python 'cbor' library gets a gold star for not being broken when there are trailing bytes.

Thanks
mv
--------------A26EF5DA3CBBE6B8572EC387-- From nobody Sun Nov 18 15:55:29 2018 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB164126BED; Sun, 18 Nov 2018 15:55:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-cbor-cddl@ietf.org, Barry Leiba , cbor-chairs@ietf.org, barryleiba@computer.org, cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154258532777.2578.8591857608340815014.idtracker@ietfa.amsl.com> Date: Sun, 18 Nov 2018 15:55:27 -0800 Archived-At: Subject: [Cbor] Benjamin Kaduk's No Objection on draft-ietf-cbor-cddl-05: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 23:55:28 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-cbor-cddl-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for updating the editor's copy pursuant to the secdir review! As I was reading, I wondered about potential confusion between a numerical value and the corresponding text string when used as a keytype, especially for barewords. The bareword ABNF requires a leading EALPHA, which should force the right parsing, while the memberkey ABNF still allows literal values to be used as keys. I do wonder, though, if the 'id' ABNF's limitations on textual names (i.e., strings that could be interpreted as numbers are disallowed) should be mentioned in the main text as how disambiguation is enforced in general. It's a little weird to use PersonalData as an example, given the privacy considerations inherent in storing personal data, but I guess this is not really a flaw in the spec. Section 1 Nit: bullet (G3) lacks grammatical parallelism with its sibling bullets; something like "Be able to" would restore parity. Section 2 1. Instead of defining all four types of composition in CDDL separately, or even defining one kind for arrays (vectors and records) and one kind for maps (tables and structs), there is only one kind of composition in CDDL: the _group_ (Section 2.1). This perhaps reads a bit strongly, as we do go on to define syntactic sugar for arrays and maps, even though they build on the shared group abstraction. Section 2.1 Note that the (curly) braces signify the creation of a map; the groups themselves are neutral as to whether they will be used in a map or an array. [...] Note that the lists inside the braces in the above definitions constitute (anonymous) groups, while "identity" is a named group. I might add another sentence in one of these places foreshadowing the behavior that groups are "macro-like" the sense that when used in the description of another group, their contents are siblings of the elements that are new in the other group, as opposed to being part of a nested structure. Section 3.1 o CDDL uses UTF-8 [RFC3629] for its encoding. It's pretty rare for it to be sufficient to just say "UTF-8" in a technical spec; what kind of internationalization review has been done? Do we need to specify anything about normalization or canonicalization? Section 3.5.1 The "struct" usage of maps is similar to the way JSON objects are used in many JSON applications. A map is defined in the same way as defining an array (see Section 3.4), except for using curly braces "{}" instead of square brackets "[]". Taken together, these paragraphs read as if (1) a struct is a type of map, and (2) a map uses curly brackets. But the following example shows a struct as enclosed within square brackets. Where am I going wrong? GpsCoordinates = { longitude : uint, ; multiplied by 10^7 latitude : uint, ; multiplied by 10^7 } It is perhaps irresponsible to include an example that does not specify the units of the measurement (e.g., degrees or radians). Section 3.8.6 value from being sent over the wire. This control is only meaningful when the control type is used in an optional context; otherwise there would be no way to express the default value. Maybe s/express/utilize/? That is, the ".default" control still expresses what the default value would be, but that information would never be used. Section 5 o Where the CDDL includes extension points, the impact of extensions on the security of the system needs to be carefully considered. Would it make sense to also add guidance for judicious use of .within to constrain extension points? Writers of CDDL specifications are strongly encouraged to value simplicity and transparency of the specification over its elegance. Keep it as simple as possible while still expressing the needed data model. Perhaps "simplicity of [type] constructions", since some readers may equate simplicity [of design] and elegance. Section 6.1 I don't really understand why there's a need for distinctions based on the presence of an internal dot, especially given that this document does not define any such operators. What would such a control operator look like? Section 7.2 It seems that RFC 4648 might need to be a normative reference given that it specifies how some byte string literals are interpreted in EDN. Appendix B On first glance I wonder if some of the S should be 1*WS to avoid parsing ambiguities, but I did not think about it very hard. Note that this ABNF does not attempt to reflect the detailed rules of what can be in a prefixed byte string. Before I made it this far, I was going to note that the "bytes" definition seems to allow me to use a "h" or b64" prefix with "arbitrary" contents; it seems that an alternate construction could embody the semantic restrictions for such strings into the ABNF. How bad would it be if a future update to this document attempted to actually reflect the "detailed rules of what can be in a prefixed byte string"? Appendix D I can't decide if most of the "#" entries need double-quotes around them to parse properly as ABNF. Is it best to think about this CBOR major/minor notation as an extension to standard ABNF? From nobody Sun Nov 18 16:37:46 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F14129385; Sun, 18 Nov 2018 16:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3Zx_nL1caQEa; Sun, 18 Nov 2018 16:37:34 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 6CC451293FB; Sun, 18 Nov 2018 16:37:34 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id z11so10384784pgu.0; Sun, 18 Nov 2018 16:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=AOLxLR5LKBrBl7Z9SggAfRgfx4mENdDU0g3zaTZuIwU=; b=CbX5SOg3PwZlwrI9ZOLTH9G+nIMFSUEcGwsP6zg2iWjvZBhW5RS4Z5hq4XtbNUG/P0 LUGHpshj1csdAIxrzqcBvV32yGEbj00NfYGIVxrtLZS9bk2qMlQ9zXzAroEQLTRxbC8D L3cfVLlysMlGzRJL/4fV4X2ZGvA14ady5LZ8S9IQiJTHwGRpj2jTlBFAe5wLXxeo8qGS wHUEMCv9OeieVyq9gFN16jsFbkGsOfkM5qXnOOJvLfDeL8Swpw/q5glofDSzx/ztv9+I nd9xk8vMtKSVbdw40rYBq4PMMjmPxtmMiMIa1DH25S8Trkryz6UrehDgOEqS+b5s/87m ouOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AOLxLR5LKBrBl7Z9SggAfRgfx4mENdDU0g3zaTZuIwU=; b=dWAluHH6Rfl/SkAzm6Hs6x6OoRnbKRb5WUBWuivj44xZcABW9VHsmJTNnsg/Hf/5Y5 ZgpLV5Pl62dFd7iHu9y9ic5l+1eeFDwUt4oTtdhiBmdnoYDPWgbtu29q67CNUsFcgVjZ m7sDe7ibvgSJhsPSa6LAqYPhiHtD2sCZLm3FAZUpM6NMT7Y3mC+tGFyfcoihQoN6C2jR /Bp8wscGAwPf3ld+nkYrFve+0alFcdao+5o/j1BYL6oNxGkxCuf/p6M7ZqTTlLOLFPo9 9LUitsMMqxvqq0Oo439E+c/vnC9NDYXna4tYIk7ZRlfHzge/cOYe1/8i4RivDyhdDkcP cu0g== X-Gm-Message-State: AGRZ1gK1gPtdNI4FnT9HfzWm2DYt1oIFUfuQVTuaDXzrO1ktGi5/6VbQ XSRGS1cevlzstzLnTcf5hVFrdA04 X-Google-Smtp-Source: AJdET5eWFnGWl71CAbg6e7T3b22ENZlpmYM6nRCrkf6t8WirsrCXX8qQq6ZUiKlS6PcaBlwe9D7Dsw== X-Received: by 2002:a62:fc86:: with SMTP id e128mr21560028pfh.54.1542587853702; Sun, 18 Nov 2018 16:37:33 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id g190sm38228199pgc.28.2018.11.18.16.37.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Nov 2018 16:37:32 -0800 (PST) To: Benjamin Kaduk , The IESG Cc: cbor@ietf.org, barryleiba@computer.org, cbor-chairs@ietf.org, draft-ietf-cbor-cddl@ietf.org References: <154258532777.2578.8591857608340815014.idtracker@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <7cdb2d28-3f6c-a013-b5f3-337930854c45@gmail.com> Date: Mon, 19 Nov 2018 13:37:29 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <154258532777.2578.8591857608340815014.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cbor] Benjamin Kaduk's No Objection on draft-ietf-cbor-cddl-05: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 00:37:37 -0000 On 2018-11-19 12:55, Benjamin Kaduk wrote: ...> Section 3.1 > > o CDDL uses UTF-8 [RFC3629] for its encoding. > > It's pretty rare for it to be sufficient to just say "UTF-8" in a technical > spec; what kind of internationalization review has been done? Do we need > to specify anything about normalization or canonicalization? IMHO there is nothing to say here, but of course a protocol definition that uses UTF-8 needs to cover these questions. Worked example: objective = [objective-name, objective-flags, loop-count, ?objective-value] objective-name = text objective-value = any loop-count = 0..255 All objectives are identified by a unique name which is a UTF-8 string [RFC3629], to be compared byte by byte. [draft-ietf-anima-grasp-15 page 37] It might be worth a note in CDDL to say that CDDL is agnostic on this but protocol specs need to cover it. Brian From nobody Sun Nov 18 16:40:43 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD804129385; Sun, 18 Nov 2018 16:40:41 -0800 (PST) X-Quarantine-ID: <0oPco3NI_oVc> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 0oPco3NI_oVc; Sun, 18 Nov 2018 16:40:39 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 E906D1293FB; Sun, 18 Nov 2018 16:40:38 -0800 (PST) X-AuditID: 1209190d-bb7ff70000004457-9a-5bf20685b43f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id BE.1E.17495.58602FB5; Sun, 18 Nov 2018 19:40:37 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wAJ0eZnE004414; Sun, 18 Nov 2018 19:40:36 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAJ0eU8w001911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Nov 2018 19:40:33 -0500 Date: Sun, 18 Nov 2018 18:40:30 -0600 From: Benjamin Kaduk To: Brian E Carpenter Cc: The IESG , cbor@ietf.org, barryleiba@computer.org, cbor-chairs@ietf.org, draft-ietf-cbor-cddl@ietf.org Message-ID: <20181119004030.GR11132@kduck.kaduk.org> References: <154258532777.2578.8591857608340815014.idtracker@ietfa.amsl.com> <7cdb2d28-3f6c-a013-b5f3-337930854c45@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7cdb2d28-3f6c-a013-b5f3-337930854c45@gmail.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA01SbUgTYRznuZd5W7s4T8VHzQ/NAp1MrawG2cuHQPNDRX0onFSXd7rhdlt3 05wIWZaIYqml52ZlpFCIoJOsFHxpJOUqScOQyiCSRDEsv4Wbdufw5dvv//+98Tz8CZS+g8cS Ft7JCTxj1ak0GK2OSjDcUi2Z0lo+6o2+tgncWDk+iBhbgs+A0V0lYcbPU02IsTlQjx5TZd3s qEWz+jzTYVnt7f+Q02iOJoPlrJZiTkg9ckljbpxsxh09REnXiwq0HPSpqoGagFQ6DHi+ylhD 0FQnAruDM1ho8ALYK42B0DCNwGDzsCwjCIzaDaX6NMWtonbB8ppPqIIjqX3wevU7XNGj1A0A lxq9uEJEUBfg0O/7QMGkXLfwqhJTcmjqGvR2GULrcDjqVorVslcPp1bmEEWCUnHwyQqhrNXU YVjr9a1VRVEJcOC2L6wOUJ4tbs8Wt2fT/QigHSCetZUabIzFKnJ5BjGP4XlOMOxNsVmcKRxb 1APW/jqGfAlWprN9gCKATksOv/5ronGmWHTZfCCGQHRR5H5syURvv2xnXWZGNF8Uiqyc6AOQ QHWRpLvzj4kmWcZVygn2dSqOwHTR5HLkTxNNFTBOrpDjHJywzu4gCB0k3+ByaLjAFXAl+Rar c5NGCLUSrpXD3ysaUnQwNtFSEOL9wED4F2bdKI3xdp6LjSYlRUQpInMRv5Gj3BEsHCqbB9Hy syLICkWlla9sI2leLkHkktnJRaXEyWxSseVgKuFAtlRWRzrOpjdmbNPfTU49l8IODqwGpDPS xNNVbVtL+L3Eo49NP+JPsjV4nNWd6W+YmdMs93xzfX/Ympb4oMHwYbQ/ub3/RO/xfinYdP5g K973hR38xXt2YqeSAvmHxq+O5b69Yq8YybRktKKLVfNJ3S1tzxNzY/wjvUiODhPNzB49KojM f59zk+MiAwAA Archived-At: Subject: Re: [Cbor] Benjamin Kaduk's No Objection on draft-ietf-cbor-cddl-05: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 00:40:42 -0000 On Mon, Nov 19, 2018 at 01:37:29PM +1300, Brian E Carpenter wrote: > On 2018-11-19 12:55, Benjamin Kaduk wrote: > ...> Section 3.1 > > > > o CDDL uses UTF-8 [RFC3629] for its encoding. > > > > It's pretty rare for it to be sufficient to just say "UTF-8" in a technical > > spec; what kind of internationalization review has been done? Do we need > > to specify anything about normalization or canonicalization? > > IMHO there is nothing to say here, but of course a protocol definition that > uses UTF-8 needs to cover these questions. > > Worked example: > > objective = [objective-name, objective-flags, loop-count, ?objective-value] > objective-name = text > objective-value = any > loop-count = 0..255 > > All objectives are identified by a unique name which is a UTF-8 > string [RFC3629], to be compared byte by byte. > > [draft-ietf-anima-grasp-15 page 37] > > It might be worth a note in CDDL to say that CDDL is agnostic on this > but protocol specs need to cover it. It might, yeah. Thanks, Benjamin From nobody Mon Nov 19 00:32:53 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914ED12DDA3 for ; Mon, 19 Nov 2018 00:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=gia3zrfA; dkim=pass (1024-bit key) header.d=ericsson.com header.b=AO1KXzPn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b00OG5IydxhS for ; Mon, 19 Nov 2018 00:32:49 -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 B75C1130D7A for ; Mon, 19 Nov 2018 00:32:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1542616366; x=1545208366; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uXA+1IVH896bNOZWuTvD9E7E5/d2EPILFSsoESZdYrY=; b=gia3zrfAgJTKcGh1qiVwuF/3zMagV4rmwtEavVFWrpM7vsu2N1WUC1PGer/C6hD7 rDI//wlr4JBwqIjQN/4klBfuGDAVBUIUyPSQcbnM2OAz0dh6WEHqIM78PC8m2zzs hhMKFBoLvpHUB9ZMwurnOnFt8wW4zjRPnH/1mXAPpD8=; X-AuditID: c1b4fb3a-8d8849e000002747-65-5bf2752e5d63 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A3.47.10055.E2572FB5; Mon, 19 Nov 2018 09:32:46 +0100 (CET) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 19 Nov 2018 09:32:45 +0100 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 19 Nov 2018 09:32:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uXA+1IVH896bNOZWuTvD9E7E5/d2EPILFSsoESZdYrY=; b=AO1KXzPnW4zeRywPPuub6RvHk/UK3FfHkHoBUIp5l07arF1PMMXSk+4B1cqKOtTa+fCPtLL0WrIiXNXkZvD4VFcW+ZlcEIc1kiCp9DpuyXvawU+0Ti/I90tMEXvsJuXLoCr097aI2BBsFzbp585ttFmoLydhDw/Y35d2+/bMhRo= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2249.eurprd07.prod.outlook.com (10.168.36.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.13; Mon, 19 Nov 2018 08:32:44 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::5d31:ff09:b9ba:29c3]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::5d31:ff09:b9ba:29c3%11]) with mapi id 15.20.1339.025; Mon, 19 Nov 2018 08:32:44 +0000 From: Francesca Palombini To: Barry Leiba , "cbor@ietf.org" Thread-Topic: [Cbor] CBOR conference calls from IETF 103 to IETF 104 Thread-Index: AQHUdk56NdoXJcN51Eap7OLu0J9tNaVW6QeA Date: Mon, 19 Nov 2018 08:32:44 +0000 Message-ID: <92BE0A54-12DE-4868-8003-0FAC9B72B611@ericsson.com> References: In-Reply-To: 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.80] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2249; 6:RZTK1botnB503gFu0H94xBgGtOZBa2BZUZgeSYoq4vOCKeASikHLCRfbnXD/x2bflbs/m+qj3KKdF9ZgsQnkZSuSXyx5MXez9aPdtcbNJjJI3QsX1yzVhIduGmZxt5sGJ2jV4+N8ubI8kwBOvj+A8StaXhcp8IfpLsg1QBmdtrKw/BDEVZD4hezYYu2gpStpipdiLrgPqnswDYvUjdNw7pgrkwavzjaNZRJu6xtsD2S5Ebkme41UgQmuioaz8Zb5Pyf0tQlZwRUoJUnT5NOuGmpyMZLhdn3JaYRj5itIWn+fV1TyQfZ8uH87++DiGGDn18NJ3Bu5pAP+VNybjh3lr/QIQGdNIOckqfRJCz40ih5tR91GQx/H2E3Wqyb8I/FpgXJ4U4NyKWqA4a3Jb/uh+edmH11lLZFihhyZcsrtKN1R7P96hDG+YSjem8cN1Te2RtlfGsWGgFF9CDO9aRrImw==; 5:mBETjlYqETgn4L7kZik+jqMmg92uU6s+hvWjvTbubYqv3KfIlCiQI7gsttDvj8uSM+uZg08nX4CYB1XlJlZKs80JiiUSFKdNelZW4NBp9S5nEsz7NS0BNC/2aoNXLpeRpj7cRWEkPuwAJ+c5adRDGY8CX6wM1DXZ3wduiZdqaQs=; 7:FVoY4tVAzh10esu2gJs0DyIkAMwCsfR0w3lDXbYlz/mNejsr2yLB0tiXov+FReErl9gcpi20j4RsirzRJUseiFwoUb9VqrLGyAXlZo1DVWiOZ1stj3IOkJHU87XCzepPcAS4EXzzU3IW59K7lTnT+g== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a927a7ce-87f0-4bb9-9eb4-08d64df99424 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2249; x-ms-traffictypediagnostic: HE1PR0701MB2249: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231415)(944501410)(52105112)(148016)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:HE1PR0701MB2249; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2249; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(396003)(376002)(366004)(39860400002)(53754006)(52024003)(189003)(199004)(2900100001)(25786009)(44832011)(8936002)(68736007)(478600001)(966005)(7736002)(82746002)(6436002)(6246003)(6506007)(256004)(229853002)(14454004)(26005)(186003)(6116002)(14444005)(97736004)(2906002)(6486002)(86362001)(71190400001)(3846002)(102836004)(71200400001)(83716004)(53936002)(76176011)(33656002)(305945005)(2501003)(66066001)(6306002)(6512007)(81156014)(81166006)(36756003)(446003)(316002)(11346002)(105586002)(110136005)(99286004)(2616005)(486006)(5660300001)(476003)(106356001)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2249; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: wNnasz6B2eLdEOBiB51N3Ki4GW/cKmmlJoQkFWFGqkf572G+rvpxbBWJ5hZyHk0s9aKNvicY5spMxw0z/ECWlenaQPXnFd/YPQZD2t4nUGRCM9kJLUBtENy7MK9puNBt6aHxSS6WFcCnU0qp3J2L7cIawf7zXLFuTnQ9E9AqFbL3zreBgzPq6S5PTlqT4TWXH9X3pR3u20VSe0Mhy8BVZDyXYOikouncA12bEJeVJlovf6RosZBLHsgDVJqMI/b9BUGGncglfhqc6/pOvDfn34BE7IUMoGnKMVgdWEmER2wxsPSFtW6yDnDV2woNqGxZfFbzZcYIrt/y1PqMEGTagoIH519J1spTrCo2h5PupJQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a927a7ce-87f0-4bb9-9eb4-08d64df99424 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2018 08:32:44.5946 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2249 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUyM2J7la5e6adog48HrS0OLb7EajGzYzqL A5NHy6peZo8lS34yBTBFcdmkpOZklqUW6dslcGX8f3GApeCYYMXJV0vYGxh7BLsYOTkkBEwk 1r9bwNrFyMUhJHCEUWLB96PsIAkhgW+MEks/RkAkljBJbLy/gRHEYRGYwCzxb+EHZojMDCaJ Rfe7oVqeM0q8/usBYrMJ2EhcePieFcQWEfCSmPdmHjOILSzgLLHv6Hp2iLiLRNfsqWwQtpHE jWk/wWpYBFQlrp4+wAJi8wrYS7zd084IMT9AYveyzWA2p0CgxOHbR8DqGQVkJb40rgazmQXE JW49mc8E8ZuAxJI955khbFGJl4//sULUJ0tcud3HDhFXkFjyZSKULStxaX432JcSAjfYJN5u vMEKkdCV+DB1KtQgX4kVPzZCFV1ilOjuOgvUzQHk6EjcexsAUZMv0bJwLRuELSexqvchC0T9 aWaJ5/+OQG2Tkfh34zDzBEaDWUgOnwU0illAU2L9Ln2IsIfE7Z9b2SBsRYkp3Q/ZZ4HDRVDi 5MwnLAsYWVcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBKaTg1t+W+1gPPjc8RCjAAejEg+v QPynaCHWxLLiytxDjBIczEoivJnhQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8TmkWUUIC6Ykl qdmpqQWpRTBZJg5OqQbG4KeZbXq3b59aJsp3539O6bUJnf8cHHLfPeNdcKOeq0zyk7/1K+Nb 82cadmwWE5P5Jr3A/YdI3JOMudtnf1HwOfFrb0NdqdqyvXOe8DUpla1JfLFuwT9G7808ywQE 9DP23fp4NVtMrWdW3kqhwllPQ96lqbgwLq7jOXrt+PG3vVJPr/g9NXt8VYmlOCPRUIu5qDgR AOEYZQgjAwAA Archived-At: Subject: Re: [Cbor] CBOR conference calls from IETF 103 to IETF 104 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 08:32:52 -0000 SGkgYWxsLA0KDQpSZW1pbmRlcjogcGxlYXNlIGRvbid0IGZvcmdldCB0byBlbnRlciB5b3VyIHBy ZWZlcmVuY2VzISBodHRwczovL2Rvb2RsZS5jb20vcG9sbC9jN2ZocXZxZXhyN2t4bmJwDQoNCldl IHdpbGwgYmUgY2hvb3NpbmcgYSB0aW1lIHNvb24uDQoNCkZyYW5jZXNjYQ0KDQrvu79PbiAwNy8x MS8yMDE4LCAwNTowMCwgIkNCT1Igb24gYmVoYWxmIG9mIEJhcnJ5IExlaWJhIiA8Y2Jvci1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4gd3JvdGU6 DQoNCiAgICBXZSBkZWNpZGVkIGluIHRoaXMgbW9ybmluZydzIENCT1Igc2Vzc2lvbiBhdCBJRVRG IDEwMyB0aGF0IHdlIHdvdWxkDQogICAgbGlrZSB0byBjb250aW51ZSB0aGUgYmktd2Vla2x5IGNv bmZlcmVuY2UgY2FsbHMsIGFzIHRoZXkgaGF2ZSBiZWVuDQogICAga2VlcGluZyB1cyBtb3Zpbmcg Zm9yd2FyZCBhcGFjZSAoYW5kIHRoYXQgbWFrZXMgeW91ciBjaGFpcnMgaGFwcHk7IGENCiAgICBo YXBweSBjaGFpciBpcyBhLi4uIHdlbGwsIGEgaGFwcHkgY2hhaXIsIEkgc3VwcG9zZSkuDQogICAg DQogICAgV2UgY2hvc2UgYSBkYXkvdGltZSBpbiByZWxhdGl2ZSBoYXN0ZSBiZWZvcmUsIGJlY2F1 c2Ugd2UgaGFkIGxpbWl0ZWQNCiAgICB0aW1lIHRvIGdldCBhbiBhbm5vdW5jZW1lbnQgb3V0IGFu ZCB0byBnZXQgdGhlIGNhbGxzIHN0YXJ0ZWQuICBUaGlzDQogICAgdGltZSwgd2UnZCBsaWtlIHRv IGRvIGEgYnJvYWRlciBwb2xsIG9mIHRoZSB3b3JraW5nIGdyb3VwIHRvIHRyeSB0bw0KICAgIHBp Y2sgYSB0aW1lIHRoYXQgd29ya3MgZm9yIGFzIG1hbnkgb2YgdXMgYXMgcG9zc2libGUuDQogICAg DQogICAgVG8gdGhhdCBlbmQsIEkndmUgY3JlYXRlZCB0aGUgZm9sbG93aW5nIGRvb2RsZSBwb2xs Og0KICAgIGh0dHBzOi8vZG9vZGxlLmNvbS9wb2xsL2M3ZmhxdnFleHI3a3huYnANCiAgICANCiAg ICBUaGUgcG9sbCBzcGVjaWZpZXMgZGF0ZXMgZHVyaW5nIHRoZSB3ZWVrIG9mIDEwIERlYywgYnV0 IHBsZWFzZSBETyBOT1QNCiAgICBhbnN3ZXIgdGhlIHBvbGwgd2l0aCB0aGF0IHNwZWNpZmljIHdl ZWsgaW4gbWluZC4gIFVzZSB0aG9zZSBkYXlzIGFzDQogICAgZGF5cyBvZiB0aGUgd2VlayBmb3Ig cmVwZWF0aW5nIGNhbGxzLCBhbmQgbGV0IHVzIGtub3cgd2hpY2ggZGF5cyBhbmQNCiAgICB0aW1l cyB3b3JrIGZvciB5b3UuDQogICAgDQogICAgUGxlYXNlIHJlc3BvbmQgdG8gdGhlIGRvb2RsZSBi eSAxNiBOb3ZlbWJlciwgYW5kIHdlJ2xsIHBpY2sgYSBkYXkvdGltZQ0KICAgIGFuZCBnZXQgYW4g YW5ub3VuY2VtZW50IG91dC4gIFdlJ2xsIHN0YXJ0IHRoZSBjYWxscyBlaXRoZXIgaW4NCiAgICBt aWQtRGVjZW1iZXIgKHRoZSB3ZWVrIG9mIDEwIERlYywgYXMgaW4gdGhlIGRvb2RsZSkgb3IgaW4g SmFudWFyeQ0KICAgIChsaWtlbHkgdGhlIHdlZWsgb2YgNyBKYW4pLg0KICAgIA0KICAgIEJhcnJ5 DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICBDQk9SIG1haWxpbmcgbGlzdA0KICAgIENCT1JAaWV0Zi5vcmcNCiAgICBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3INCiAgICANCg0K From nobody Mon Nov 19 07:40:07 2018 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A614130DD3; Mon, 19 Nov 2018 07:39:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <154264199757.5256.8061470840524592223@ietfa.amsl.com> Date: Mon, 19 Nov 2018 07:39:57 -0800 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-cddl-06.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 15:39:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF. Title : Concise data definition language (CDDL): a notational convention to express CBOR and JSON data structures Authors : Henk Birkholz Christoph Vigano Carsten Bormann Filename : draft-ietf-cbor-cddl-06.txt Pages : 60 Date : 2018-11-19 Abstract: This document proposes a notational convention to express CBOR data structures (RFC 7049, Concise Binary Object Representation). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-cddl-06 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-cddl-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-cddl-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 19 08:11:17 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7CE1286E7 for ; Mon, 19 Nov 2018 08:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 bPUjJ0VUjEUv for ; Mon, 19 Nov 2018 08:11:12 -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 8D016130DDD for ; Mon, 19 Nov 2018 08:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wAJGAwSg023328 for ; Mon, 19 Nov 2018 17:11:03 +0100 (CET) Received: from [192.168.217.114] (p54A6CE66.dip0.t-ipconnect.de [84.166.206.102]) (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 42zDN21hBBz1Bqf; Mon, 19 Nov 2018 17:10:58 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <154264199757.5256.8061470840524592223@ietfa.amsl.com> Date: Mon, 19 Nov 2018 17:10:57 +0100 X-Mao-Original-Outgoing-Id: 564336653.4558541-bdb1877babbd7f8e16ca9c0ee53aa41c Content-Transfer-Encoding: quoted-printable Message-Id: <126AE66D-3D12-4E4B-97A6-F9C7D29E0A7C@tzi.org> References: <154264199757.5256.8061470840524592223@ietfa.amsl.com> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-cddl-06.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 16:11:15 -0000 We have submitted a version of CDDL that should address all the comments = from AD review and IETF last call, including the discussions at the = Bangkok IETF meeting. Diff is at: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-06.txt Most of the changes were editorial. A technical decision that we made = at the Bangkok meeting was prompted by the Gen-ART comment number 3: the = behavior of reverse ranges (e.g., 10..0) was not defined. The text now = says: 2.2.2.1. Ranges Instead of naming all the values that make up a choice, CDDL allows building a _range_ out of two values that are in an ordering relationship: A lower bound (first value) and an upper bound (second value). A range can be inclusive of both bounds given (denoted by joining two values by ".."), or include the lower bound and exclude the upper bound (denoted by instead using "..."). If the lower bound exceeds the upper bound, the resulting type is the empty set (this behavior can be desirable when generics, Section 3.10, are being used). So, of the potential meanings of 10..0, we chose the empty set. This is now in -06; if that is a problem for you, we would like to know = about that. Gr=C3=BC=C3=9Fe, Carsten > On Nov 19, 2018, at 16:39, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Concise Binary Object Representation = Maintenance and Extensions WG of the IETF. >=20 > Title : Concise data definition language (CDDL): a = notational convention to express CBOR and JSON data structures > Authors : Henk Birkholz > Christoph Vigano > Carsten Bormann > Filename : draft-ietf-cbor-cddl-06.txt > Pages : 60 > Date : 2018-11-19 >=20 > Abstract: > This document proposes a notational convention to express CBOR data > structures (RFC 7049, Concise Binary Object Representation). Its > main goal is to provide an easy and unambiguous way to express > structures for protocol messages and data formats that use CBOR or > JSON. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-cbor-cddl-06 > https://datatracker.ietf.org/doc/html/draft-ietf-cbor-cddl-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Mon Nov 19 11:40:02 2018 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E183F1292F1; Mon, 19 Nov 2018 11:40:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-cbor-cddl@ietf.org, Barry Leiba , cbor-chairs@ietf.org, barryleiba@computer.org, cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154265640086.5290.12522790793284758388.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2018 11:40:00 -0800 Archived-At: Subject: [Cbor] Alissa Cooper's No Objection on draft-ietf-cbor-cddl-06: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 19:40:01 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-cbor-cddl-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for a clear document and for addressing the Gen-ART review comments. From nobody Mon Nov 19 11:40:51 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D7D12F1AB; Mon, 19 Nov 2018 11:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_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=cooperw.in header.b=hsGONsOq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wbDLOubo Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMIPbK8XOm0L; Mon, 19 Nov 2018 11:40:42 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227CF1292F1; Mon, 19 Nov 2018 11:40:42 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 330C1A33; Mon, 19 Nov 2018 14:40:41 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 19 Nov 2018 14:40:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=s WeH8hCY6zRgMQbF4CTJ5GkZVffMqjeU8myUKET1tAc=; b=hsGONsOqWKsVkMj5h WcDKvJ8lwrK/+XD5MbAPgdaSxBLrbqgAgmmcofgm9RB9C/2SY+mWL/Q3EMFoc6bA zGpaTs9FyKCYi8vNJEuvaWQdnjmoZCbcNxow6t7zPO1Txiym4tLA0f8GLi8BfWVu DByo6QLVoeWHHMffPQTewguPT7oF+FOoc4g7cguBnjQIswVheDJx6fYM9Zek5EUL XA9rRayNMBxpyMod/2QuWllGruWUF0HkjhkkmOamdorE/NXpv4kWnhFl10RM2c9y gudP0GXnZcCKYlNG5fuvY7RziyPy6HUOsuYB4vpBDShM+crf80a8INkiWNMC1eo1 E6wfg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=sWeH8hCY6zRgMQbF4CTJ5GkZVffMqjeU8myUKET1t Ac=; b=wbDLOubo5pZbgGKLTjHevbxEFLdnwNGMFKev29WDTbZTg9PVrXp9ThZHZ AkL+ljYKwudx89bQSEKx/kYgZ6v71gYtLXqd8iFYf+NHgfCVehMl+DP8gAL1+Y0e jOBIWfrYq4wOWxitZ2WeLie23pQq48QyAayjet97ejEoGqP84OYEtMv3GPudTN0R /jbZEVhghQGXIurJjb/f1g7FupCZVUkuf5NKINirP2NPGnpHqA7S6jxxhRrvISqz R/GMrYHsVZpQDZ7ye7/Tgxb91TUK6giwlBWE8BRjRUmczZrnhVeHhL4oVGeL5/PG EcXkBF7qdn123DO0df2OynHZf6gxg== X-ME-Sender: X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.73]) by mail.messagingengine.com (Postfix) with ESMTPA id BB87A10331; Mon, 19 Nov 2018 14:40:39 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <10456266-70D0-43FD-8FB2-00A5EF01A6A4@tzi.org> Date: Mon, 19 Nov 2018 14:40:38 -0500 Cc: cbor@ietf.org, General Area Review Team , draft-ietf-cbor-cddl.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <169C8F84-81B9-414A-9123-F3CD69A49B77@cooperw.in> References: <153817214335.26462.1312093989723950989@ietfa.amsl.com> <10456266-70D0-43FD-8FB2-00A5EF01A6A4@tzi.org> To: Carsten Bormann , Ines Robles X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] [Gen-art] Genart last call review of draft-ietf-cbor-cddl-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 19:40:44 -0000 Ines, thanks for your review. Carsten, thanks for addressing the review = comments. I have entered a No Objection ballot. Alissa > On Nov 6, 2018, at 6:51 PM, Carsten Bormann wrote: >=20 > Hi Ines, >=20 > Thank you very much for the review and the slight embarrassment it = causes to the authors=E2=80=A6 >=20 > Comment 3 below we will pick up in the WG meeting today; I=E2=80=99ll = report about that later. > The other comments are now addressed in the editor=E2=80=99s copy: >=20 > https://github.com/cbor-wg/cddl/commits/master > (Individual commits referenced below; the CI build is failing right = now because of a weird connectivity issue.) >=20 > We plan to submit the fixes as part of -06 early next week. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 >> On Sep 29, 2018, at 05:02, Ines Robles = wrote: >>=20 >> Reviewer: Ines Robles >> Review result: Ready with Nits >>=20 >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >>=20 >> For more information, please see the FAQ at >>=20 >> . >>=20 >> Document: draft-ietf-cbor-cddl-05 >> Reviewer: Ines Robles >> Review Date: 2018-09-28 >> IETF LC End Date: 2018-10-04 >> IESG Telechat date: Not scheduled for a telechat >>=20 >> Summary: >>=20 >> I believe the draft is technically good. This document is well = written and >> clear to understand. >>=20 >> The document proposes a notational convention named Concise data = definition >> language (CDDL) to express Concise Binary Object Representation = (CBOR) data >> structures. Its main goal is to provide an easy and unambiguous way = to express >> structures for protocol messages and data formats that use CBOR or = JSON. >>=20 >> I have some minor questions. The document presents nits that should = be solved >> before publication. >>=20 >> Major issues: Not found. >>=20 >> Minor issues: Not found. >>=20 >> Nits/editorial comments: >>=20 >> 1)-Abstract: It would be nice to expand CBOR the first time that it = is >> mentioned. >=20 > Indeed. Fixed in 88e9a00 >=20 >> 2)-Section 2: Page 8, You mention anonymous group. >> Does it would be a good definition for an anonymous group?: =E2=80=9CLi= sts of >> group_entries_ (between curly braces)that can be assigned to any = type of >> composition (arrays, maps)=E2=80=9D >=20 > The groups are anonymous because they are used right away in a pair of = curly braces (for a map) or square brackets (for an array). > The examples in this section all happen to be in braces. > I=E2=80=99m not sure that =E2=80=9Canonymous group=E2=80=9D needs to = be defined as a separate term, though, because it is just that: a group = that is anonymous. >=20 >> 3)- Section 2.2.2.1 - Page 11: the ordering I think is ascendant, = right? So, >> maybe, would it be nice to add =E2=80=9Cnatural ordering = relationship=E2=80=9D? question: is >> the following valid?: >>=20 >> Take-off =3D { >> takeoffcounting=3D 10..0 ; Is it valid? Is it = applicable? >> } >=20 > The type constituted by the range does not have any ordering = relationship (except that implied by numbering in general). > The example you give would not make a difference from saying 0..10 =E2=80= =94 in both cases, the eleven numbers 0 to 10 constitute the type. >=20 > It is probably not so good that the current text seems to leave open = whether 10..0 means the same as 0..10. >=20 > (There is no obvious right answer, so we will discuss this in the CBOR = WG meeting today and come back.) >=20 >> 4)- In this paragraph: =E2=80=9C...When using a name as the left hand = side of a range >> operator, use spacing as in >> "min .. max" to separate off the range operator...." >> =3D> Question: Is =E2=80=9Cmin .. max" equivalent to "min=E2=80=9D .. = =E2=80=9Cmax"? >=20 > Sorry for leading the reader into quoting hell. > The quotes here are generated by XML2RFC to delimit a code span, i.e., = they identify the example. > Maybe we should make small figures out of these (ignoring that some = people don=E2=80=99t like sentences running over figures). >=20 > Fixed in a530564 >=20 >>=20 >> 5)- There are some mismatches between Appendix B and Appendix C: >>=20 >> Appendix B: cddl =3D S 1*(rule S) >> Appendix C: cddl =3D S 1*rule >> ------------------------------------------------------------ >>=20 >> Appendix B: >> rule =3D typename [genericparm] S assignt S type >> / groupname [genericparm] S assigng S grpent >>=20 >> Appendix C: >> rule =3D typename [genericparm] S assignt S type S >> / groupname [genericparm] S assigng S grpent S >> ------------------------------------------------------------ >>=20 >> Appendix B: type =3D type1 *(S "/" S type1) >> Appendix C: type =3D type1 S *("/" S type1 S) >>=20 >> ------------------------------------------------------------ >> Appendix B: group =3D grpchoice *(S "//" S grpchoice) >> Appendix C: group =3D grpchoice S *("//" S grpchoice S) >>=20 >> ------------------------------------------------------------ >> Appendix B: grpchoice =3D *(grpent optcom) >> Appendix C: grpchoice =3D *grpent >>=20 >> ------------------------------------------------------------ >>=20 >> Appendix B: grpent =3D [occur S] [memberkey S] type >> Appendix C: grpent =3D [occur S] [memberkey S] type optcom >>=20 >> ------------------------------------------------------------ >>=20 >> Appendix B: / [occur S] groupname [genericarg] ; preempted = by above >> Appendix C: / [occur S] groupname [genericarg] optcom ; = preempted by >> above >>=20 >> ------------------------------------------------------------ >>=20 >> Appendix B: / [occur S] "(" S group S ")" >> Appendix C: / [occur S] =E2=80=9C(" S group S ")" optcom >=20 > This is the embarrassing part. We recently cleaned up the whitespace = processing in the ABNF a bit, and I was sure all the changes made it to = the matching appendix. D=E2=80=99oh. Another case of =E2=80=9Ca = feature isn=E2=80=99t there if it isn=E2=80=99t checked by continuous = integration checking=E2=80=9D. >=20 > Fixed in bfdecd8 >=20 >>=20 >> 6)- It would be nice to expand I-JSON to (=E2=80=9CInternet JSON") in = page 54 >=20 > Fixed in cc43317 >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Mon Nov 19 11:47:37 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7827130DE2; Mon, 19 Nov 2018 11:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=googlemail.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 DrjxUvAWt3eH; Mon, 19 Nov 2018 11:47:33 -0800 (PST) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 F10E0126CC7; Mon, 19 Nov 2018 11:47:32 -0800 (PST) Received: by mail-it1-x136.google.com with SMTP id x124so8174702itd.1; Mon, 19 Nov 2018 11:47:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NRdMQYN1LKRA0h3ZeLmvgQXBareI9NnpcKnu2/qnW2E=; b=a479gBf+EPIDizl7oM98ZWJxpYmv4ZZVe2cqe+rqwBazguc7MZ3tghQposlmVl2/ng ZhB2XYsDcdW5gHt/5/USitLop7NJ7jTSV5KVQSMR98IXyFOQdxk5Et3Vu4sQCb2ob5fC +STxrxaA79Zu9ej4P9eZZjg3dWBYF7aYsYKfSIxP4R1RRrQFw0M9tNPxioNcIcY39faB 3k1R8rSQAiHDqCV1CUIzEWDXN/JgVt4/8O801Sidi7RMF9Dl2QMwOmlTg481uJLX01Xk +2n2y3d15qgciFdgDFIw7bTKiXxa3Dsc+bI5mS7Pr01pFaqNfxoVD6yb87kaQaTBEwDM zWVw== 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=NRdMQYN1LKRA0h3ZeLmvgQXBareI9NnpcKnu2/qnW2E=; b=J0HtXquMmgJ5UnNMQ/OuIbthbUxYP7mS2Z3ptk+t94Y19+BqNFFwKapa44c9/UjcCK tXcVdRJU+meDP/8ts2zyj1MFebktc+JdYAYODpGWAL7KOEcqjpuOTUa0KIzzYx8op8/a G3Zd+mmujdwTrhlW9mJiPXEVILHlsO9iI1X58sJxYmHKOmvkh/aPooSyMRZrHfvFIyeL 04rSsh7xxyz5tTcaqG5+uoQOXtQjhh3l6Zrrg2TvSuPW6SHU6QkHNRN9y4SYYifU5+1+ T4cFRUi6A8AFkJ9+mXl0TSiflDPUofi271I5dVMlFgFU25oWs5fSyptGdj0+Up7dXqqB J6ew== X-Gm-Message-State: AA+aEWaYP5zFFEcXWTZ8y7utbllCRE06Rpn8wZJYRsavspuSgtShj9+G fOnSjq9b0ZAye+ccxrIZ4P9WLHKP67ibAH1cu1/H3w== X-Google-Smtp-Source: AFSGD/WVxpfgsuOU/5txxYR2O4ODIeoj6njPe6+xgLI9/uAJqbNsHOx/e+CyPrNFeM4aVh6/HriNYMCLsW7KbmBEBX8= X-Received: by 2002:a24:1582:: with SMTP id 124mr1873159itq.98.1542656852054; Mon, 19 Nov 2018 11:47:32 -0800 (PST) MIME-Version: 1.0 References: <153817214335.26462.1312093989723950989@ietfa.amsl.com> <10456266-70D0-43FD-8FB2-00A5EF01A6A4@tzi.org> <169C8F84-81B9-414A-9123-F3CD69A49B77@cooperw.in> In-Reply-To: <169C8F84-81B9-414A-9123-F3CD69A49B77@cooperw.in> From: Ines Robles Date: Mon, 19 Nov 2018 21:47:21 +0200 Message-ID: To: Carsten Bormann Cc: cbor@ietf.org, draft-ietf-cbor-cddl.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000ad5939057b09c9eb" Archived-At: Subject: Re: [Cbor] [Gen-art] Genart last call review of draft-ietf-cbor-cddl-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 19:47:36 -0000 --000000000000ad5939057b09c9eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Carsten for addressing the comments, Best regards, Ines. On Mon, Nov 19, 2018 at 9:40 PM Alissa Cooper wrote: > Ines, thanks for your review. Carsten, thanks for addressing the review > comments. I have entered a No Objection ballot. > > Alissa > > > On Nov 6, 2018, at 6:51 PM, Carsten Bormann wrote: > > > > Hi Ines, > > > > Thank you very much for the review and the slight embarrassment it > causes to the authors=E2=80=A6 > > > > Comment 3 below we will pick up in the WG meeting today; I=E2=80=99ll r= eport > about that later. > > The other comments are now addressed in the editor=E2=80=99s copy: > > > > https://github.com/cbor-wg/cddl/commits/master > > (Individual commits referenced below; the CI build is failing right now > because of a weird connectivity issue.) > > > > We plan to submit the fixes as part of -06 early next week. > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > >> On Sep 29, 2018, at 05:02, Ines Robles > wrote: > >> > >> Reviewer: Ines Robles > >> Review result: Ready with Nits > >> > >> I am the assigned Gen-ART reviewer for this draft. The General Area > >> Review Team (Gen-ART) reviews all IETF documents being processed > >> by the IESG for the IETF Chair. Please treat these comments just > >> like any other last call comments. > >> > >> For more information, please see the FAQ at > >> > >> . > >> > >> Document: draft-ietf-cbor-cddl-05 > >> Reviewer: Ines Robles > >> Review Date: 2018-09-28 > >> IETF LC End Date: 2018-10-04 > >> IESG Telechat date: Not scheduled for a telechat > >> > >> Summary: > >> > >> I believe the draft is technically good. This document is well written > and > >> clear to understand. > >> > >> The document proposes a notational convention named Concise data > definition > >> language (CDDL) to express Concise Binary Object Representation (CBOR) > data > >> structures. Its main goal is to provide an easy and unambiguous way to > express > >> structures for protocol messages and data formats that use CBOR or JSO= N. > >> > >> I have some minor questions. The document presents nits that should be > solved > >> before publication. > >> > >> Major issues: Not found. > >> > >> Minor issues: Not found. > >> > >> Nits/editorial comments: > >> > >> 1)-Abstract: It would be nice to expand CBOR the first time that it is > >> mentioned. > > > > Indeed. Fixed in 88e9a00 > > > >> 2)-Section 2: Page 8, You mention anonymous group. > >> Does it would be a good definition for an anonymous group?: =E2=80=9CL= ists of > >> group_entries_ (between curly braces)that can be assigned to any type > of > >> composition (arrays, maps)=E2=80=9D > > > > The groups are anonymous because they are used right away in a pair of > curly braces (for a map) or square brackets (for an array). > > The examples in this section all happen to be in braces. > > I=E2=80=99m not sure that =E2=80=9Canonymous group=E2=80=9D needs to be= defined as a separate > term, though, because it is just that: a group that is anonymous. > > > >> 3)- Section 2.2.2.1 - Page 11: the ordering I think is ascendant, > right? So, > >> maybe, would it be nice to add =E2=80=9Cnatural ordering relationship= =E2=80=9D? > question: is > >> the following valid?: > >> > >> Take-off =3D { > >> takeoffcounting=3D 10..0 ; Is it valid? Is it applicable= ? > >> } > > > > The type constituted by the range does not have any ordering > relationship (except that implied by numbering in general). > > The example you give would not make a difference from saying 0..10 =E2= =80=94 in > both cases, the eleven numbers 0 to 10 constitute the type. > > > > It is probably not so good that the current text seems to leave open > whether 10..0 means the same as 0..10. > > > > (There is no obvious right answer, so we will discuss this in the CBOR > WG meeting today and come back.) > > > >> 4)- In this paragraph: =E2=80=9C...When using a name as the left hand = side of a > range > >> operator, use spacing as in > >> "min .. max" to separate off the range operator...." > >> =3D> Question: Is =E2=80=9Cmin .. max" equivalent to "min=E2=80=9D .. = =E2=80=9Cmax"? > > > > Sorry for leading the reader into quoting hell. > > The quotes here are generated by XML2RFC to delimit a code span, i.e., > they identify the example. > > Maybe we should make small figures out of these (ignoring that some > people don=E2=80=99t like sentences running over figures). > > > > Fixed in a530564 > > > >> > >> 5)- There are some mismatches between Appendix B and Appendix C: > >> > >> Appendix B: cddl =3D S 1*(rule S) > >> Appendix C: cddl =3D S 1*rule > >> ------------------------------------------------------------ > >> > >> Appendix B: > >> rule =3D typename [genericparm] S assignt S type > >> / groupname [genericparm] S assigng S grpent > >> > >> Appendix C: > >> rule =3D typename [genericparm] S assignt S type S > >> / groupname [genericparm] S assigng S grpent S > >> ------------------------------------------------------------ > >> > >> Appendix B: type =3D type1 *(S "/" S type1) > >> Appendix C: type =3D type1 S *("/" S type1 S) > >> > >> ------------------------------------------------------------ > >> Appendix B: group =3D grpchoice *(S "//" S grpchoice) > >> Appendix C: group =3D grpchoice S *("//" S grpchoice S) > >> > >> ------------------------------------------------------------ > >> Appendix B: grpchoice =3D *(grpent optcom) > >> Appendix C: grpchoice =3D *grpent > >> > >> ------------------------------------------------------------ > >> > >> Appendix B: grpent =3D [occur S] [memberkey S] type > >> Appendix C: grpent =3D [occur S] [memberkey S] type optcom > >> > >> ------------------------------------------------------------ > >> > >> Appendix B: / [occur S] groupname [genericarg] ; preempted b= y > above > >> Appendix C: / [occur S] groupname [genericarg] optcom ; > preempted by > >> above > >> > >> ------------------------------------------------------------ > >> > >> Appendix B: / [occur S] "(" S group S ")" > >> Appendix C: / [occur S] =E2=80=9C(" S group S ")" optcom > > > > This is the embarrassing part. We recently cleaned up the whitespace > processing in the ABNF a bit, and I was sure all the changes made it to t= he > matching appendix. D=E2=80=99oh. Another case of =E2=80=9Ca feature isn= =E2=80=99t there if it > isn=E2=80=99t checked by continuous integration checking=E2=80=9D. > > > > Fixed in bfdecd8 > > > >> > >> 6)- It would be nice to expand I-JSON to (=E2=80=9CInternet JSON") in = page 54 > > > > Fixed in cc43317 > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > _______________________________________________ > > Gen-art mailing list > > Gen-art@ietf.org > > https://www.ietf.org/mailman/listinfo/gen-art > > --000000000000ad5939057b09c9eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Carsten for addressing the comments,

Best regards,

Ines.

On Mon, Nov 19, 2018 at 9:40 PM Alissa= Cooper <alissa@cooperw.in> = wrote:
Ines, thanks for your review= . Carsten, thanks for addressing the review comments. I have entered a No O= bjection ballot.

Alissa

> On Nov 6, 2018, at 6:51 PM, Carsten Bormann <cabo@tzi.org> wrote:
>
> Hi Ines,
>
> Thank you very much for the review and the slight embarrassment it cau= ses to the authors=E2=80=A6
>
> Comment 3 below we will pick up in the WG meeting today; I=E2=80=99ll = report about that later.
> The other comments are now addressed in the editor=E2=80=99s copy:
>
> https://github.com/cbor-wg/cddl/commits/master
> (Individual commits referenced below; the CI build is failing right no= w because of a weird connectivity issue.)
>
> We plan to submit the fixes as part of -06 early next week.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>
>
>> On Sep 29, 2018, at 05:02, Ines Robles <mariainesrobles@googlemail.com= > wrote:
>>
>> Reviewer: Ines Robles
>> Review result: Ready with Nits
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Are= a
>> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair.=C2=A0 Please treat these comments = just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> <https://trac.ietf.org/trac/gen/wiki/GenAr= tfaq>.
>>
>> Document: draft-ietf-cbor-cddl-05
>> Reviewer: Ines Robles
>> Review Date: 2018-09-28
>> IETF LC End Date: 2018-10-04
>> IESG Telechat date: Not scheduled for a telechat
>>
>> Summary:
>>
>> I believe the draft is technically good. This document is well wri= tten and
>> clear to understand.
>>
>> The document proposes a notational convention named Concise data d= efinition
>> language (CDDL) to express Concise Binary Object Representation (C= BOR) data
>> structures. Its main goal is to provide an easy and unambiguous wa= y to express
>> structures for protocol messages and data formats that use CBOR or= JSON.
>>
>> I have some minor questions. The document presents nits that shoul= d be solved
>> before publication.
>>
>> Major issues: Not found.
>>
>> Minor issues: Not found.
>>
>> Nits/editorial comments:
>>
>> 1)-Abstract: It would be nice to expand CBOR the first time that i= t is
>> mentioned.
>
> Indeed.=C2=A0 Fixed in 88e9a00
>
>> 2)-Section 2:=C2=A0 Page 8,=C2=A0 You mention anonymous group.
>> Does it would be a good definition for an anonymous group?: =E2=80= =9CLists of
>> group_entries_=C2=A0 (between curly braces)that can be assigned to= any type of
>> composition (arrays, maps)=E2=80=9D
>
> The groups are anonymous because they are used right away in a pair of= curly braces (for a map) or square brackets (for an array).
> The examples in this section all happen to be in braces.
> I=E2=80=99m not sure that =E2=80=9Canonymous group=E2=80=9D needs to b= e defined as a separate term, though, because it is just that: a group that= is anonymous.
>
>> 3)- Section 2.2.2.1 - Page 11: the ordering I think is ascendant, = right? So,
>> maybe, would it be nice to add =E2=80=9Cnatural ordering relations= hip=E2=80=9D? question: is
>> the following valid?:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Take-off =3D {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0takeoffcount= ing=3D 10..0 ; Is it valid? Is it applicable?
>> }
>
> The type constituted by the range does not have any ordering relations= hip (except that implied by numbering in general).
> The example you give would not make a difference from saying 0..10 =E2= =80=94 in both cases, the eleven numbers 0 to 10 constitute the type.
>
> It is probably not so good that the current text seems to leave open w= hether 10..0 means the same as 0..10.
>
> (There is no obvious right answer, so we will discuss this in the CBOR= WG meeting today and come back.)
>
>> 4)- In this paragraph: =E2=80=9C...When using a name as the left h= and side of a range
>> operator, use spacing as in
>>=C2=A0 "min .. max" to separate off the range operator...= ."
>> =3D> Question: Is =E2=80=9Cmin .. max" equivalent to "= ;min=E2=80=9D .. =E2=80=9Cmax"?
>
> Sorry for leading the reader into quoting hell.
> The quotes here are generated by XML2RFC to delimit a code span, i.e.,= they identify the example.
> Maybe we should make small figures out of these (ignoring that some pe= ople don=E2=80=99t like sentences running over figures).
>
> Fixed in a530564
>
>>
>> 5)- There are some mismatches between Appendix B and Appendix C: >>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix B: cddl =3D S 1*(rule S)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix C: cddl =3D S 1*rule
>> ------------------------------------------------------------
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix B:
>> rule =3D typename [genericparm] S assignt S type
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 / groupname [genericparm] S assigng S g= rpent
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix C:
>> rule =3D typename [genericparm] S assignt S type S
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0/ groupname [genericparm] S assigng S gr= pent S
>> ------------------------------------------------------------
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix B:=C2=A0 =C2=A0 type =3D type1 = *(S "/" S type1)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix C:=C2=A0 =C2=A0 type =3D type1 = S *("/" S type1 S)
>>
>> ------------------------------------------------------------
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix B:=C2=A0 =C2=A0group =3D grpcho= ice *(S "//" S grpchoice)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix C:=C2=A0 =C2=A0group =3D grpcho= ice S *("//" S grpchoice S)
>>
>> ------------------------------------------------------------
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix B:=C2=A0 =C2=A0 grpchoice =3D *= (grpent optcom)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix C:=C2=A0 =C2=A0 grpchoice =3D *= grpent
>>
>> ------------------------------------------------------------
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix B:=C2=A0 =C2=A0 grpent =3D [occ= ur S] [memberkey S] type
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix C:=C2=A0 =C2=A0 grpent =3D [occ= ur S] [memberkey S] type optcom
>>
>> ------------------------------------------------------------
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix B:=C2=A0 =C2=A0 / [occur S] gro= upname [genericarg]=C2=A0 ; preempted by above
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix C:=C2=A0 =C2=A0 / [occur S] gro= upname [genericarg] optcom ; preempted by
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0above
>>
>> ------------------------------------------------------------
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix B:=C2=A0 =C2=A0/ [occur S] &quo= t;(" S group S ")"
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix C:=C2=A0 =C2=A0/ [occur S] =E2= =80=9C(" S group S ")" optcom
>
> This is the embarrassing part.=C2=A0 We recently cleaned up the whites= pace processing in the ABNF a bit, and I was sure all the changes made it t= o the matching appendix.=C2=A0 D=E2=80=99oh.=C2=A0 Another case of =E2=80= =9Ca feature isn=E2=80=99t there if it isn=E2=80=99t checked by continuous = integration checking=E2=80=9D.
>
> Fixed in bfdecd8
>
>>
>> 6)- It would be nice to expand I-JSON to (=E2=80=9CInternet JSON&q= uot;) in page 54
>
> Fixed in cc43317
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org=
> https://www.ietf.org/mailman/listinfo/gen-art<= br>
--000000000000ad5939057b09c9eb-- From nobody Mon Nov 19 17:46:28 2018 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D404124C04; Mon, 19 Nov 2018 17:46:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: cbor@ietf.org, Barry Leiba , barryleiba@computer.org, cbor-chairs@ietf.org, draft-ietf-cbor-cddl@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154267838656.26631.4178048052675609107.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2018 17:46:26 -0800 Archived-At: Subject: [Cbor] Eric Rescorla's Discuss on draft-ietf-cbor-cddl-06: (with DISCUSS and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 01:46:27 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-cbor-cddl-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4234 I am marking this document discussed because I have concerns about whether this document can be interoperably implemented. I have noted a number of points below. DETAIL S 3.5.2. > point.) > > 3.5.2. Tables > > A table can be specified by defining a map with entries where the > keytype is not single-valued, e.g.: this is the first use of the term single-valued, so I don't know how to interpret this. More generally: it seems like: ``` square-roots = {x => y} x = int y = float ``` Defines a map and yet ``` square-roots = {x => y} y = float ``` Defines a struct. Is that correct? If so, does that mean that I don't know whether something is a map or a struct until I ahve parsed the whole definition? S 3.5.3. > mynumber = int / float > > 3.5.3. Non-deterministic order > > While the way arrays are matched is fully determined by the Parsing > Expression Grammar (PEG) algorithm, matching is more complicated for PEG is an informative reference, and this text seems to create a normative dependency. S 3.6. > * tstr => any > } > > 3.6. Tags > > A type can make use of a CBOR tag (major type 6) by using the What happens if I define a type twice? Is that permitted? S 3.7. > buuid = #6.37(bstr) > > In the following example, usage of the tag 32 for URIs is optional: > > my_uri = #6.32(tstr) / tstr > I am basically unable to make sense of this section. Your previous example of tags used #7.25 but here you are specifying everything as using 6. It seems like the semantics here are something to the effect of: X = #6.Y(Z) means: act as if this were a thing of type Z but it's tagged by Y. Is that correct? But then is this about the wire encoding or the interpretation or both? And in either case, what if what appears on the wire has a different tag. S 3.8.2. > cwr: 15, > ns: 0, > ) / (4..7) ; data offset bits > > rwxbits = uint .bits rwx > rwx = &(r: 2, w: 1, x: 0) What is the scope of the definition for r, w, and x? is it global. S 3.9. > $$tcp-option //= ( > sack-permitted: true > ) > > Names that start with a single "$" are "type sockets", names with a > double "$$" are "group sockets". It is not an error if there is no what is the difference between these two? S 7.3. > order of the rules given. (It is not an error to extend a rule name > that has not yet been defined; this makes the right hand side the > first entry in the choice being created.) > > genericparm = "<" S id S *("," S id S ) ">" > genericarg = "<" S type1 S *("," S type1 S ) ">" What is the meaning of ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 1.2. > capitals, as shown here. > > 1.2. Terminology > > New terms are introduced in _cursive_. CDDL text in the running text > is in "typewriter". I think you mean that these types of text will be indicated by being bracketed by _ or ", but this isn't clear from this text. It's especially not clear when you then quote byte and octet. S 2. > There are a number of more or less atomic elements of a CBOR data > model, such as numbers, simple values (false, true, nil), text and > byte strings; CDDL does not focus on specifying their structure. > CDDL of course also allows adding a CBOR tag to a data item. > > The more important components of a data structure definition language More important than what? S 2.1. > } > > Figure 1: Using a group directly in a map > > The three entries of the group are written between the curly braces > that create the map: Here, "age", "name", and "employer" are the This is kind of a confusing way to introduce this. Its seems like the relevant point is that: () makes a group {()} or {} makes a map. No? S 2.1. > } > > dog = { > identity, > leash-length: float, > } So to be clear, this is a mixin, as in Go structs? S 2.1.2. > only one big protocol data unit that has all definitions ad hoc where > needed. > > 2.1.2. Syntax > > The composition syntax intends to be concise and easy to read: Syntax does not intend. perhasp you mean it is intended to be. S 2.2.3. > tool when displaying integers that are taken from that choice). > > 2.2.3. Representation Types > > CDDL allows the specification of a data item type by referring to the > CBOR representation (major and minor numbers). How this is used RFC 7049 does not refer to "minor" numbers. S 2.2.3. > in the prelude: > > my_breakfast = #6.55799(breakfast) ; cbor-any is too general! > breakfast = cereal / porridge > cereal = #6.998(tstr) > porridge = #6.999([liquid, solid]) What is the parenthetical syntax here? S 3.1. > according to the respective syntactic rules of that definition. > > o A name can consist of any of the characters from the set {'A', > ..., 'Z', 'a', ..., 'z', '0', ..., '9', '_', '-', '@', '.', '$'}, > starting with an alphabetic character (including '@', '_', '$') > and ending in one or a digit. This seems to say that names end in a digit, but none of your name examples do. S 3.2. > An optional _occurrence_ indicator can be given in front of a group > entry. It is either one of the characters '?' (optional), '*' (zero > or more), or '+' (one or more), or is of the form n*m, where n and m > are optional unsigned integers and n is the lower limit (default 0) > and m is the upper limit (default no limit) of occurrences. > isn't bare * then just a degenerate case of n*m S 3.5.1. > written with quoted strings in the member key positions. More > generally, all the types defined can be used in a keytype position by > following them with a double arrow -- in particular, the double arrow > is necessary if a type is named by an identifier (which would be > interpreted as a string before a colon). A string also is a (single- > valued) type, so another form for this example is: I'm sorry, I'm not following this. Can you give an example of when you have to use => S 3.10. > message = {type: t, value: v} > > When using a generic rule, the formal parameters are bound to the > actual arguments supplied (also using angle brackets), within the > scope of the generic rule (as if there were a rule of the form > parameter = argument). This looks more like a macro than a generic. S 7.3. > definition with different member names); RFC 7071 could be read to > forbid the repetition of ext-value ("A specific reputon-element MUST > NOT appear more than once" is ambiguous.) > > The CDDL tool (which hasn't quite been trained for polite > conversation) says: It seems like it might be a good idea to clean up the examples here so they are in fact polite. S 7.3. > "Thumbnail": {"Width": 1111, "Height": 176, "Url": 32("scrog")}, > "IDs": []}} > > Appendix B. ABNF grammar > > The following is a formal definition of the CDDL syntax in Augmented It's pretty odd to have the formal specification -- which clearly is needed to understand and implement this document -- in an appendix. S 7.3. > CRLF = %x0A / %x0D.0A > > Figure 14: CDDL ABNF > > Note that this ABNF does not attempt to reflect the detailed rules of > what can be in a prefixed byte string. I am trusting others to have read the ABNF. S 7.3. > for a group expression (production "grpent"), with the intention that > the semantics does not change when the name is replaced by its > (parenthesized if needed) definition. Note that whether the name > defined by a rule stands for a type or a group isn't always > determined by syntax alone: e.g., "a = b" can make "a" a type if "b" > is one, or a group if "b" is one. More subtly, in "a = (b)", "a" may It would be clearer to say 'if "b" is a type' and 'if "b" is a group' S 7.3. > type = type1 S *("/" S type1 S) > > A type can be given as a choice between one or more types. The > choice matches a data item if the data item matches any one of the > types given in the choice. The choice uses Parsing Expression > Grammar [PEG] semantics: The first choice that matches wins. (As a Is this the only information I need? S 7.3. > control operators. > > group = grpchoice S *("//" S grpchoice S) > > A group matches any sequence of key/value pairs that matches any of > the choices given (again using Parsing Expression Grammar semantics). This also seems not fully defined. From nobody Mon Nov 19 21:22:34 2018 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 421141293FB; Mon, 19 Nov 2018 21:22:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-cbor-cddl@ietf.org, Barry Leiba , cbor-chairs@ietf.org, barryleiba@computer.org, cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154269134623.26525.15947501642666003321.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2018 21:22:26 -0800 Archived-At: Subject: [Cbor] Adam Roach's Discuss on draft-ietf-cbor-cddl-06: (with DISCUSS and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 05:22:26 -0000 Adam Roach has entered the following ballot position for draft-ietf-cbor-cddl-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for all the work that went into creating this document. I have one point that I think needs discussion, although it's entirely possible that I'm thinking about this the wrong way. §3.8: Given that the list of control operators can be expanded in the future, it's not clear what automated tools are supposed to do if they encounter controls that they do not understand. I initially thought that it might be possible to just ignore control operators (and their parameters) if they aren't understood, as this would simply result in a more permissive validation of data against a schema; but the ".and" control gives an example of a control operator where this kind of elision would fail. With the lack of any version indicators in CDDL, this seems like a straight-up interoperability issue. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I also have a handful of non-critical comments of varying importance. Please expand "CBOR": (1) In the title (2) Upon first use in the document body See https://www.rfc-editor.org/materials/abbrev.expansion.txt for details. --------------------------------------------------------------------------- §1.2: > New terms are introduced in _cursive_. CDDL text in the running text > is in "typewriter". This is perplexing, as I know of no tool that will render the canonical form of current RFCs in the way being described. Is the intention to hold this document until the new RFC format is available? --------------------------------------------------------------------------- §2: > The rest of this section introduces a number of basic concepts of > CDDL, and section Section 3 defines additional syntax. Appendix C Nit: "...and Section 3..." --------------------------------------------------------------------------- §2.2.2: > delimited by a "//" (double slash). Note that the "//" operators > binds much more weakly than the other CDDL operators, so each line Nit: "...operator binds..." or "...operators bind..." --------------------------------------------------------------------------- §3.1: > o A name can consist of any of the characters from the set {'A', > ..., 'Z', 'a', ..., 'z', '0', ..., '9', '_', '-', '@', '.', '$'}, This looks like a formal syntax of some kind, but I don't know where it's defined. Notably, since this document has just defined ".." to be an inclusive range operator and "..." to be an exclusive range operator, defining the set of allowed characters in this way seems to run the risk of interpreting, e.g., "Z" to be disallowed. I suggest either defining the set of allowed characters using a formally defined and cited grammar (e.g., ABNF), or using prose. --------------------------------------------------------------------------- §3.1: > o outside strings, whitespace (spaces, newlines, and comments) is > used to separate syntactic elements for readability (and to > separate identifiers or numbers that follow each other); it is > otherwise completely optional. This seems nominally at odds with the following text in §2.2.2.1, which points to at least one other case where whitespace is mandatory: > When using a name as > the left hand side of a range operator, use spacing as in > > min .. max > > to separate off the range operator. --------------------------------------------------------------------------- §3.1: > If prefixed as "h" or "b64", the string is > interpreted as a sequence of pairs of hex digits (base16) or a > base64(url) string, respectively Please normatively cite RFC 4648, sections 8 and 5 respectively. --------------------------------------------------------------------------- §3.8.1: > When applied to an unsigned integer, the ".size" control restricts > the range of that integer by giving a maximum number of bytes that > should be needed in a computer representation of that unsigned > integer. In other words, "uint .size N" is equivalent to > "0...BYTES_N", where BYTES_N == 256**N. > > audio_sample = uint .size 3 ; 24-bit, equivalent to 0..16777215 > > Figure 9: Control for integer size in bytes While they're semantically the same, the example is oddly mismatched with the preceding text. Consider instead: audio_sample = uint .size 3 ; 24-bit, equivalent to 0...16777216 --------------------------------------------------------------------------- Appendix B: > / "#" "6" ["." uint] "(" S type S ")" ; note no space! No space where? I see two space productions in that rule (so it clearly applies to some specific location), and there are several places where spaces cannot appear. > type1 = type2 [S (rangeop / ctlop) S type2] This rule doesn't seem to properly capture the ambiguity of "a...b". There is a terribly complex way to address this by defining parallel "type2" and "type3" rules that differ only in whether a dot is allowed to appear in their value, and defining type1 as requiring a space after the type that can contain dots -- but that is probably overkill. It's probably sufficient to reiterate the warning about requiring a space under such circumstances as a comment on this rule. > HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" It is a common implementor mistake to forget that ABNF is, by default, case-insensitive. It is probably worth adding a comment here as a reminder. (The same applies to "0x", "0b", "e", and "p" above, but these seem less likely to appear in arbitrary case.) --------------------------------------------------------------------------- Appendix B: > SCHAR = %x20-21 / %x23-5B / %x5D-10FFFD / SESC > SESC = "\" %x20-10FFFD ... > PCHAR = %x20-10FFFD These almost certainly should be: SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC SESC = "\" %x20-7E / %x80-10FFFD ... PCHAR = %x20-7E / %x80-10FFFD (i.e., exclude the control character %x7F) --------------------------------------------------------------------------- Appendix C: > (It is not an error to extend a rule name > that has not yet been defined; this makes the right hand side the > first entry in the choice being created.) Is it an error to redefine a rule name that has already been defined? From nobody Tue Nov 20 03:58:39 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45665130DFE; Tue, 20 Nov 2018 03:58:28 -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 XbCIi_LWX5YI; Tue, 20 Nov 2018 03:58:24 -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 66B22130DF9; Tue, 20 Nov 2018 03:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wAKBwDHW023282; Tue, 20 Nov 2018 12:58:19 +0100 (CET) Received: from sev.informatik.uni-bremen.de (sev.informatik.uni-bremen.de [134.102.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42zkjx66fJz1Bqf; Tue, 20 Nov 2018 12:58:13 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <154269134623.26525.15947501642666003321.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 12:58:13 +0100 Cc: The IESG , cbor@ietf.org, barryleiba@computer.org, cbor-chairs@ietf.org, draft-ietf-cbor-cddl@ietf.org X-Mao-Original-Outgoing-Id: 564407889.444203-6f3da67be008b4ca3463d7df84430379 Content-Transfer-Encoding: quoted-printable Message-Id: <91495E47-A203-472E-8FFB-19A648D537C0@tzi.org> References: <154269134623.26525.15947501642666003321.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Adam Roach's Discuss on draft-ietf-cbor-cddl-06: (with DISCUSS and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 11:58:28 -0000 Hi Adam, thank you for this detailed review. My comments inline below. Gr=C3=BC=C3=9Fe, Carsten > On Nov 20, 2018, at 06:22, Adam Roach wrote: >=20 > Adam Roach has entered the following ballot position for > draft-ietf-cbor-cddl-06: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks for all the work that went into creating this document. I have = one point > that I think needs discussion, although it's entirely possible that = I'm thinking > about this the wrong way. >=20 > =C2=A73.8: >=20 > Given that the list of control operators can be expanded in the = future, it's > not clear what automated tools are supposed to do if they encounter = controls > that they do not understand. I initially thought that it might be = possible to > just ignore control operators (and their parameters) if they aren't = understood, > as this would simply result in a more permissive validation of data = against a > schema; but the ".and" control gives an example of a control operator = where this > kind of elision would fail. >=20 > With the lack of any version indicators in CDDL, this seems like a = straight-up > interoperability issue. There is no expectation that a tool that does not implement a control = operator is particularly useful with a specification that does use it. Since CDDL is not intended as an on-the-wire format, this does not per = se create an interoperability issue. (The situation is similar to the situation we have with ABNF and RFC = 7405: If a specification uses %s, this does not create interoperability = problems, but makes it harder to employ tools that do not implement %s. = In both cases, version numbers do not help.) Introduction of a new control operator does limit the set of tools that = can be used with specifications that use it, so it should not be done = lightly. However, the WG considered it important to open up CDDLs to SDOs that = may have specific requirements in this space (e.g., imagine a format for = carrying MODBUS binary data around =E2=80=94 it is unlikely that the = IETF would be the right body to create any CDDL extension needed for = that). Explicitly exposing control operators as the preferred extension point = makes it more likely that tools can then be adapted to adopt such = extensions. The registry is intended to help avoid parallel development of control = operators with the same name. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I also have a handful of non-critical comments of varying importance. >=20 > Please expand "CBOR": > (1) In the title > (2) Upon first use in the document body >=20 > See https://www.rfc-editor.org/materials/abbrev.expansion.txt for = details. CBOR may be at the right stage to adopt it as a =E2=80=9Cwell-known=E2=80=9D= abbreviation. The title becomes very unwieldy with an expansion: Concise data definition language (CDDL): a notational convention to express CBOR (Concise Binary Object Representation) and JSON data = structures I expect the RFC editor will have an opinion on this; I=E2=80=99d like = to defer to that. > = --------------------------------------------------------------------------= - >=20 > =C2=A71.2: >=20 >> New terms are introduced in _cursive_. CDDL text in the running text >> is in "typewriter". >=20 > This is perplexing, as I know of no tool that will render the = canonical form > of current RFCs in the way being described. Is the intention to hold = this > document until the new RFC format is available? The intention is to live with the limitations of the current format, but = to also make versions available that make use of fonts. Using underscores to simulate cursive text is an established convention; = unfortunately conventions for typewriter text are less well-established = (and XML2RFC uses simple quotes). > = --------------------------------------------------------------------------= - >=20 > =C2=A72: >=20 >> The rest of this section introduces a number of basic concepts of >> CDDL, and section Section 3 defines additional syntax. Appendix C >=20 > Nit: =E2=80=9C...and Section 3..." Thanks. Now c77a2b6 in the github version. > = --------------------------------------------------------------------------= - >=20 > =C2=A72.2.2: >=20 >> delimited by a "//" (double slash). Note that the "//" operators >> binds much more weakly than the other CDDL operators, so each line >=20 > Nit: =E2=80=9C...operator binds..." or "...operators bind..." Now 1c64571. > = --------------------------------------------------------------------------= - >=20 > =C2=A73.1: >=20 >> o A name can consist of any of the characters from the set {'A', >> ..., 'Z', 'a', ..., 'z', '0', ..., '9', '_', '-', '@', '.', '$'}, >=20 > This looks like a formal syntax of some kind, but I don't know where = it's > defined. Notably, since this document has just defined ".." to be an = inclusive > range operator and "..." to be an exclusive range operator, defining = the set of > allowed characters in this way seems to run the risk of interpreting, = e.g., "Z" > to be disallowed. >=20 > I suggest either defining the set of allowed characters using a = formally defined > and cited grammar (e.g., ABNF), or using prose. I went for prose: {=E2=80=98A' to 'Z', 'a' to 'z', '0' to '9', '\_', '-', '@', '.', [=E2=80=A6] Now a6c183a. > = --------------------------------------------------------------------------= - >=20 > =C2=A73.1: >=20 >> o outside strings, whitespace (spaces, newlines, and comments) is >> used to separate syntactic elements for readability (and to >> separate identifiers or numbers that follow each other); it is >> otherwise completely optional. >=20 > This seems nominally at odds with the following text in =C2=A72.2.2.1, = which points > to at least one other case where whitespace is mandatory: >=20 >> When using a name as >> the left hand side of a range operator, use spacing as in >>=20 >> min .. max >>=20 >> to separate off the range operator. Case added: to separate syntactic elements for readability (and to separate identifiers, range operators, or numbers that follow each other); it = is otherwise completely optional. Now a3ecb14. > = --------------------------------------------------------------------------= - >=20 > =C2=A73.1: >=20 >> If prefixed as "h" or "b64", the string is >> interpreted as a sequence of pairs of hex digits (base16) or a >> base64(url) string, respectively >=20 > Please normatively cite RFC 4648, sections 8 and 5 respectively. Oops. RFC 4648 indeed is a required normative reference. Also added = the reference in section 3.1. Note that both the CDDL and the extended diagnostic notation are = agnostic between RFC 4648=E2=80=99s base64 variants, so both section 4 = and 5 of that do apply. Now 1fa4fd1. > = --------------------------------------------------------------------------= - >=20 > =C2=A73.8.1: >=20 >> When applied to an unsigned integer, the ".size" control restricts >> the range of that integer by giving a maximum number of bytes that >> should be needed in a computer representation of that unsigned >> integer. In other words, "uint .size N" is equivalent to >> "0...BYTES_N", where BYTES_N =3D=3D 256**N. >>=20 >> audio_sample =3D uint .size 3 ; 24-bit, equivalent to 0..16777215 >>=20 >> Figure 9: Control for integer size in bytes >=20 > While they're semantically the same, the example is oddly mismatched = with the > preceding text. Consider instead: >=20 > audio_sample =3D uint .size 3 ; 24-bit, equivalent to = 0=E2=80=A616777216 Indeed. Now 0dd510d > = --------------------------------------------------------------------------= - >=20 > Appendix B: >=20 >> / "#" "6" ["." uint] "(" S type S ")" ; note no space! >=20 > No space where? I see two space productions in that rule (so it = clearly > applies to some specific location), and there are several places where = spaces > cannot appear. We tried to be brief while alerting the reader. Removed. >> type1 =3D type2 [S (rangeop / ctlop) S type2] >=20 > This rule doesn't seem to properly capture the ambiguity of "a...b". = There is a > terribly complex way to address this by defining parallel "type2" and = "type3" > rules that differ only in whether a dot is allowed to appear in their = value, and > defining type1 as requiring a space after the type that can contain = dots -- but > that is probably overkill. It's probably sufficient to reiterate the = warning > about requiring a space under such circumstances as a comment on this = rule. Added. >> HEXDIG =3D DIGIT / "A" / "B" / "C" / "D" / "E" / "F" >=20 > It is a common implementor mistake to forget that ABNF is, by default, > case-insensitive. It is probably worth adding a comment here as a = reminder. > (The same applies to "0x", "0b", "e", and "p" above, but these seem = less likely > to appear in arbitrary case.) The clarification went into the beginning of Appendix B, as there is no = single place inside where it would fit. All these editorial changes to Appendix B are now 5aacd34. > = --------------------------------------------------------------------------= - >=20 > Appendix B: >=20 >> SCHAR =3D %x20-21 / %x23-5B / %x5D-10FFFD / SESC >> SESC =3D "\" %x20-10FFFD > ... >> PCHAR =3D %x20-10FFFD >=20 > These almost certainly should be: >=20 > SCHAR =3D %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC > SESC =3D "\" %x20-7E / %x80-10FFFD > ... > PCHAR =3D %x20-7E / %x80-10FFFD >=20 > (i.e., exclude the control character %x7F) Good point. Now bf39464. > = --------------------------------------------------------------------------= - >=20 > Appendix C: >=20 >> (It is not an error to extend a rule name >> that has not yet been defined; this makes the right hand side the >> first entry in the choice being created.) >=20 > Is it an error to redefine a rule name that has already been defined? It seems we never say so. The CDDL tool discussed in Appendix F makes it an error only if the new = definition differs from the existing one. This is now written down in 60c22df. .oOo. From nobody Tue Nov 20 06:08:48 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9961286E3; Tue, 20 Nov 2018 06:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 tTRvsL5P3wqY; Tue, 20 Nov 2018 06:08:42 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CCA861274D0; Tue, 20 Nov 2018 06:08:42 -0800 (PST) Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wAKE8cUY088042 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Nov 2018 08:08:40 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at To: Carsten Bormann Cc: The IESG , cbor@ietf.org, barryleiba@computer.org, cbor-chairs@ietf.org, draft-ietf-cbor-cddl@ietf.org References: <154269134623.26525.15947501642666003321.idtracker@ietfa.amsl.com> <91495E47-A203-472E-8FFB-19A648D537C0@tzi.org> From: Adam Roach Message-ID: <1f32fece-f5cf-d375-e962-5899bdfc58b5@nostrum.com> Date: Tue, 20 Nov 2018 08:08:31 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <91495E47-A203-472E-8FFB-19A648D537C0@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Cbor] Adam Roach's Discuss on draft-ietf-cbor-cddl-06: (with DISCUSS and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 14:08:45 -0000 On 11/20/18 5:58 AM, Carsten Bormann wrote: > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Thanks for all the work that went into creating this document. I have one point >> that I think needs discussion, although it's entirely possible that I'm thinking >> about this the wrong way. >> >> §3.8: >> >> Given that the list of control operators can be expanded in the future, it's >> not clear what automated tools are supposed to do if they encounter controls >> that they do not understand. I initially thought that it might be possible to >> just ignore control operators (and their parameters) if they aren't understood, >> as this would simply result in a more permissive validation of data against a >> schema; but the ".and" control gives an example of a control operator where this >> kind of elision would fail. >> >> With the lack of any version indicators in CDDL, this seems like a straight-up >> interoperability issue. > There is no expectation that a tool that does not implement a control operator is particularly useful with a specification that does use it. > Since CDDL is not intended as an on-the-wire format, this does not per se create an interoperability issue. > (The situation is similar to the situation we have with ABNF and RFC 7405: If a specification uses %s, this does not create interoperability problems, but makes it harder to employ tools that do not implement %s. In both cases, version numbers do not help.) Thanks for the analogy. This makes sense, and so I'm clearing my DISCUSS. /a From nobody Tue Nov 20 08:08:25 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78093129C6A for ; Tue, 20 Nov 2018 08:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeHHMJ4QGRc7 for ; Tue, 20 Nov 2018 08:08:21 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19A612008A for ; Tue, 20 Nov 2018 08:08:21 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0EAD820089 for ; Tue, 20 Nov 2018 11:08:16 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 686E7E32; Tue, 20 Nov 2018 11:08:20 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 669CCE30 for ; Tue, 20 Nov 2018 11:08:20 -0500 (EST) From: Michael Richardson To: cbor@ietf.org In-Reply-To: <91495E47-A203-472E-8FFB-19A648D537C0@tzi.org> References: <154269134623.26525.15947501642666003321.idtracker@ietfa.amsl.com> <91495E47-A203-472E-8FFB-19A648D537C0@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] Adam Roach's Discuss on draft-ietf-cbor-cddl-06: (with DISCUSS and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 16:08:24 -0000 --=-=-= Content-Type: text/plain Adam> With the lack of any version indicators in CDDL, this seems like a Adam> straight-up interoperability issue. Carsten Bormann wrote: > There is no expectation that a tool that does not implement a control > operator is particularly useful with a specification that does use it. okay, but wouldn't it still be good if there was a declaration at the top of the file as to which revision of the specification the CDDL is assuming, just so that the tool can fail gracefully? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlv0MXQACgkQgItw+93Q 3WWMeAf+P+FCDZhohvXW+7a9Uw2yn8kWP0XHFZ7Z9dbgBJquJ3j5j0EEb1nkiZcO wP1/2MgveMweHdSG7wgeamYxJqlMd7gYaAXCQ3+T93lptlputqe8ReYyhC0B8aWg 3mouwBjR/tivHrYmyEvM8ACwDV17hNgsGJhhVpDD/78vyrzMSMkRcAFh+uM5c/0P D6vnvfwjKjW721raqywh2/EC3tTkQl2bHzhA543eyySnylaznMvaghD31kYrNxD2 ICxhyEiG0qbNVELUjLNQZjMJXZuIRa38xFuS02zThwV9D/19N742jcaW/XlB0TZ7 mLiSINQtr024YBdPO+8Br8jMYk5mWw== =0Wr9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 20 08:14:47 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D47A12D4F2; Tue, 20 Nov 2018 08:14:37 -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 R659oQGWosT7; Tue, 20 Nov 2018 08:14:33 -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 384D612426A; Tue, 20 Nov 2018 08:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wAKGEM7C014390; Tue, 20 Nov 2018 17:14:28 +0100 (CET) Received: from sev.informatik.uni-bremen.de (sev.informatik.uni-bremen.de [134.102.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42zrPV6CKJz1Bqk; Tue, 20 Nov 2018 17:14:22 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <154267838656.26631.4178048052675609107.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 17:14:22 +0100 Cc: The IESG , cbor@ietf.org, Barry Leiba , cbor-chairs@ietf.org, draft-ietf-cbor-cddl@ietf.org X-Mao-Original-Outgoing-Id: 564423258.791311-e1cccfca3be5c9f99d81d554ce62e51c Content-Transfer-Encoding: quoted-printable Message-Id: References: <154267838656.26631.4178048052675609107.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Eric Rescorla's Discuss on draft-ietf-cbor-cddl-06: (with DISCUSS and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 16:14:38 -0000 Hi Eric, thank you for this detailed review. Comments below. Gr=C3=BC=C3=9Fe, Carsten > On Nov 20, 2018, at 02:46, Eric Rescorla wrote: >=20 > Eric Rescorla has entered the following ballot position for > draft-ietf-cbor-cddl-06: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D4234 >=20 >=20 > I am marking this document discussed because I have concerns about > whether this document can be interoperably implemented. I have noted a > number of points below. >=20 > DETAIL > S 3.5.2. >> point.) >>=20 >> 3.5.2. Tables >>=20 >> A table can be specified by defining a map with entries where the >> keytype is not single-valued, e.g.: >=20 > this is the first use of the term single-valued, so I don't know how > to interpret this. A single-valued type is a type that consists of only a single value. (In CDDL, constants give rise to single-valued types =E2=80=94 there is = no separate concept for carrying around values.) I have made this more explicit now: before a colon). A string also is a type (that contains a single value only =E2=80=94 the given string), so another form for this example is: (567e8ee in the current github version https://github.com/cbor-wg/cddl ) > More generally: it seems like: >=20 > ``` > square-roots =3D {x =3D> y} > x =3D int > y =3D float > ``` >=20 > Defines a map and yet >=20 > ``` > square-roots =3D {x =3D> y} > y =3D float > ``` >=20 > Defines a struct. Is that correct? If so, does that mean that I don't > know whether something is a map or a struct until I ahve parsed the > whole definition? Struct, table, etc. are " four loosely distinguishable styles of composition=E2=80=9D. =20 There is no interoperability semantics to these usage styles. Maps and arrays are the two kinds of containers offered by CBOR. Maps = are suitable for carrying around tables and structs, arrays for vectors = and records. In the table/vector case, the map/array is indeed the high = level semantics implied by the style; for struct/record map/array are = just convenient containers. CDDL could be defined without discussing these usage styles. The text is meant to lead in to the way CDDL is composed of types and = the construct of a _group_, which enables the description of structs and = records (maps/arrays that are not homogeneous tables or vectors). > S 3.5.3. >> mynumber =3D int / float >>=20 >> 3.5.3. Non-deterministic order >>=20 >> While the way arrays are matched is fully determined by the = Parsing >> Expression Grammar (PEG) algorithm, matching is more complicated = for >=20 > PEG is an informative reference, and this text seems to create a > normative dependency. Many of our specifications make use of theory in one form or another = without needing a normative dependency to a textbook. RFC 5234 does not even have a reference for BNF. Since PEGs have been a = staple for parsing theory only for less than 15 years, we thought a = reference might be useful. > S 3.6. >> * tstr =3D> any >> } >>=20 >> 3.6. Tags >>=20 >> A type can make use of a CBOR tag (major type 6) by using the >=20 > What happens if I define a type twice? Is that permitted? Adam Roach also brought this up =E2=80=94 which led to 60c22df. > S 3.7. >> buuid =3D #6.37(bstr) >>=20 >> In the following example, usage of the tag 32 for URIs is = optional: >>=20 >> my_uri =3D #6.32(tstr) / tstr >>=20 >=20 > I am basically unable to make sense of this section. Your previous > example of tags used #7.25 but here you are specifying everything as > using 6. 6 is CBOR=E2=80=99s major type for tags. #7.25 is not a tag, but a = (16-bit) floating point value. The example shows how to construct tagged items by using the #6.xxx(ttt) = syntax, where xxx is a tag value and ttt is the type of the data item = enclosed by the tag. > It seems like the semantics here are something to the effect of: >=20 > X =3D #6.Y(Z) >=20 > means: act as if this were a thing of type Z but it's tagged by Y. >=20 > Is that correct? But then is this about the wire encoding or the > interpretation or both? And in either case, what if what appears on > the wire has a different tag. Tags are visible at the CBOR data model level. A tag with a different value than Y would not match #6.Y(Z), independent = of whether the enclosed data item maps Z. > S 3.8.2. >> cwr: 15, >> ns: 0, >> ) / (4..7) ; data offset bits >>=20 >> rwxbits =3D uint .bits rwx >> rwx =3D &(r: 2, w: 1, x: 0) >=20 > What is the scope of the definition for r, w, and x? is it global. There is no scope =E2=80=94 everything is global. (The only scopes are for the formal parameters of generics.) > S 3.9. >> $$tcp-option //=3D ( >> sack-permitted: true >> ) >>=20 >> Names that start with a single "$" are "type sockets", names with = a >> double "$$" are "group sockets". It is not an error if there is = no >=20 > what is the difference between these two? Type sockets take additional types via /=3D. Group sockets take alternative groups via //=3D. > S 7.3. >> order of the rules given. (It is not an error to extend a rule = name >> that has not yet been defined; this makes the right hand side the >> first entry in the choice being created.) >>=20 >> genericparm =3D "<" S id S *("," S id S ) ">" >> genericarg =3D "<" S type1 S *("," S type1 S ) ">" >=20 > What is the meaning of I don=E2=80=99t know =E2=80=94 currently it is not allowed to have type = choices in a generic argument. (Maybe I=E2=80=99m missing some context.) > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > S 1.2. >> capitals, as shown here. >>=20 >> 1.2. Terminology >>=20 >> New terms are introduced in _cursive_. CDDL text in the running = text >> is in "typewriter". >=20 > I think you mean that these types of text will be indicated by being > bracketed by _ or ", but this isn't clear from this text. It's > especially not clear when you then quote byte and octet. XML2RFC currently uses quotes for indicating typewriter text. The text also uses quotes for the usual purposes. The intro could be improved, but the gamut in XML2RFC is right now = limited. > S 2. >> There are a number of more or less atomic elements of a CBOR data >> model, such as numbers, simple values (false, true, nil), text = and >> byte strings; CDDL does not focus on specifying their structure. >> CDDL of course also allows adding a CBOR tag to a data item. >>=20 >> The more important components of a data structure definition = language >=20 > More important than what? Than the atomic elements (because these are mostly trivial to specify). > S 2.1. >> } >>=20 >> Figure 1: Using a group directly in a map >>=20 >> The three entries of the group are written between the curly = braces >> that create the map: Here, "age", "name", and "employer" are the >=20 > This is kind of a confusing way to introduce this. Its seems like the > relevant point is that: >=20 > () makes a group > {()} or {} makes a map. >=20 > No? We have tried a number of ways to say this. Maybe this very short form = can work better as an introduction. > S 2.1. >> } >>=20 >> dog =3D { >> identity, >> leash-length: float, >> } >=20 > So to be clear, this is a mixin, as in Go structs? Yes. > S 2.1.2. >> only one big protocol data unit that has all definitions ad hoc = where >> needed. >>=20 >> 2.1.2. Syntax >>=20 >> The composition syntax intends to be concise and easy to read: >=20 > Syntax does not intend. perhasp you mean it is intended to be. Yes. Now 09f6b55 >=20 >=20 > S 2.2.3. >> tool when displaying integers that are taken from that choice). >>=20 >> 2.2.3. Representation Types >>=20 >> CDDL allows the specification of a data item type by referring to = the >> CBOR representation (major and minor numbers). How this is used >=20 > RFC 7049 does not refer to =E2=80=9Cminor" numbers. (Already fixed in -06, 05b34be.) > S 2.2.3. >> in the prelude: >>=20 >> my_breakfast =3D #6.55799(breakfast) ; cbor-any is too = general! >> breakfast =3D cereal / porridge >> cereal =3D #6.998(tstr) >> porridge =3D #6.999([liquid, solid]) >=20 > What is the parenthetical syntax here? This is the syntax for specifying tags and the type for their enclosed = value. > S 3.1. >> according to the respective syntactic rules of that = definition. >>=20 >> o A name can consist of any of the characters from the set {'A', >> ..., 'Z', 'a', ..., 'z', '0', ..., '9', '_', '-', '@', '.', = '$'}, >> starting with an alphabetic character (including '@', '_', = '$') >> and ending in one or a digit. >=20 > This seems to say that names end in a digit, but none of your name > examples do. Clarified in 9a611bb > S 3.2. >> An optional _occurrence_ indicator can be given in front of a = group >> entry. It is either one of the characters '?' (optional), '*' = (zero >> or more), or '+' (one or more), or is of the form n*m, where n = and m >> are optional unsigned integers and n is the lower limit (default = 0) >> and m is the upper limit (default no limit) of occurrences. >>=20 >=20 > isn=E2=80=99t bare * then just a degenerate case of n*m Yes. It is still useful to also show * besides ? and +. > S 3.5.1. >> written with quoted strings in the member key positions. More >> generally, all the types defined can be used in a keytype = position by >> following them with a double arrow -- in particular, the double = arrow >> is necessary if a type is named by an identifier (which would be >> interpreted as a string before a colon). A string also is a = (single- >> valued) type, so another form for this example is: >=20 > I'm sorry, I'm not following this. Can you give an example of when you > have to use =3D> If you need to use a name for a type. With =E2=80=9C:=E2=80=9D, names = become bare words (strings without the =E2=80=9C=E2=80=A6=E2=80=9D = decoration). > S 3.10. >> message =3D {type: t, value: v} >>=20 >> When using a generic rule, the formal parameters are bound to the >> actual arguments supplied (also using angle brackets), within the >> scope of the generic rule (as if there were a rule of the form >> parameter =3D argument). >=20 > This looks more like a macro than a generic. It is not just lexical replacement, which is what =E2=80=9Cmacro=E2=80=9D = usually implies. (Strictly speaking, it is comparable to a =E2=80=9Cmacro=E2=80=9D in the = Scheme tradition, but the way this concept is used in CDDL is now better = known as =E2=80=9Cgeneric type=E2=80=9D.) > S 7.3. >> definition with different member names); RFC 7071 could be read = to >> forbid the repetition of ext-value ("A specific reputon-element = MUST >> NOT appear more than once" is ambiguous.) >>=20 >> The CDDL tool (which hasn't quite been trained for polite >> conversation) says: >=20 > It seems like it might be a good idea to clean up the examples here so > they are in fact polite. We can do that if it is considered desirable. > S 7.3. >> "Thumbnail": {"Width": 1111, "Height": 176, "Url": = 32("scrog")}, >> "IDs": []}} >>=20 >> Appendix B. ABNF grammar >>=20 >> The following is a formal definition of the CDDL syntax in = Augmented >=20 > It's pretty odd to have the formal specification -- which clearly is > needed to understand and implement this document =E2=80=94 in an = appendix. In -06, we have prefixed the normative appendices with This appendix is normative. (So many documents reference specific appendices of draft-ietf-cbor-cddl = that we tried to minimize confusion by minimizing moving them around.) > S 7.3. >> CRLF =3D %x0A / %x0D.0A >>=20 >> Figure 14: CDDL ABNF >>=20 >> Note that this ABNF does not attempt to reflect the detailed = rules of >> what can be in a prefixed byte string. >=20 > I am trusting others to have read the ABNF. >=20 >=20 > S 7.3. >> for a group expression (production "grpent"), with the intention = that >> the semantics does not change when the name is replaced by its >> (parenthesized if needed) definition. Note that whether the name >> defined by a rule stands for a type or a group isn't always >> determined by syntax alone: e.g., "a =3D b" can make "a" a type = if "b" >> is one, or a group if "b" is one. More subtly, in "a =3D (b)", = "a" may >=20 > It would be clearer to say =E2=80=98if "b" is a type' and 'if "b" is a = group' Now 9afb8cb. > S 7.3. >> type =3D type1 S *("/" S type1 S) >>=20 >> A type can be given as a choice between one or more types. The >> choice matches a data item if the data item matches any one of = the >> types given in the choice. The choice uses Parsing Expression >> Grammar [PEG] semantics: The first choice that matches wins. (As = a >=20 > Is this the only information I need? I think that is the essence; it certainly helps to be familiar with PEG = theory. > S 7.3. >> control operators. >>=20 >> group =3D grpchoice S *("//" S grpchoice S) >>=20 >> A group matches any sequence of key/value pairs that matches any = of >> the choices given (again using Parsing Expression Grammar = semantics). >=20 > This also seems not fully defined. Similar. We did add Section 3.5.3 to provide more details for the more = complicated map matching case. .oOo. From nobody Tue Nov 20 08:17:26 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A1712D4F2 for ; Tue, 20 Nov 2018 08:17:24 -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 5myLVQsI1Kvr for ; Tue, 20 Nov 2018 08:17:23 -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 A617412426A for ; Tue, 20 Nov 2018 08:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wAKGHEtI016279; Tue, 20 Nov 2018 17:17:19 +0100 (CET) Received: from sev.informatik.uni-bremen.de (sev.informatik.uni-bremen.de [134.102.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42zrSp5Dxsz1Bqf; Tue, 20 Nov 2018 17:17:14 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <29344.1542730100@localhost> Date: Tue, 20 Nov 2018 17:17:14 +0100 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 564423430.041322-a67e59d21489fe7c406ec4b5cf32d48b Content-Transfer-Encoding: quoted-printable Message-Id: <91D62AC5-769E-4D8A-915F-CD6E4902DB43@tzi.org> References: <154269134623.26525.15947501642666003321.idtracker@ietfa.amsl.com> <91495E47-A203-472E-8FFB-19A648D537C0@tzi.org> <29344.1542730100@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Adam Roach's Discuss on draft-ietf-cbor-cddl-06: (with DISCUSS and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 16:17:25 -0000 On Nov 20, 2018, at 17:08, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Adam> With the lack of any version indicators in CDDL, this seems = like a > Adam> straight-up interoperability issue. >=20 > Carsten Bormann wrote: >> There is no expectation that a tool that does not implement a control >> operator is particularly useful with a specification that does use = it. >=20 > okay, but wouldn't it still be good if there was a declaration at the = top of > the file as to which revision of the specification the CDDL is = assuming, > just so that the tool can fail gracefully? Once there is such a revision, that might make sense. Adding a control operator is not a revision =E2=80=94 that is the whole = point about exposing an extension point. (A tool can easily compare its inventory of control operators with the = set used in the specification; no need for a separate declaration here.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Nov 20 10:56:25 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A64A12D4E9 for ; Tue, 20 Nov 2018 10:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUC-YfyVOhjE for ; Tue, 20 Nov 2018 10:56:22 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30D1D1277BB for ; Tue, 20 Nov 2018 10:56:22 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A6C2320089; Tue, 20 Nov 2018 13:56:15 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 0DFC5E32; Tue, 20 Nov 2018 13:56:20 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0C2AA9DB; Tue, 20 Nov 2018 13:56:20 -0500 (EST) From: Michael Richardson To: Carsten Bormann cc: cbor@ietf.org In-Reply-To: <91D62AC5-769E-4D8A-915F-CD6E4902DB43@tzi.org> References: <154269134623.26525.15947501642666003321.idtracker@ietfa.amsl.com> <91495E47-A203-472E-8FFB-19A648D537C0@tzi.org> <29344.1542730100@localhost> <91D62AC5-769E-4D8A-915F-CD6E4902DB43@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] Adam Roach's Discuss on draft-ietf-cbor-cddl-06: (with DISCUSS and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 18:56:24 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: Adam> With the lack of any version indicators in CDDL, this seems like a Adam> straight-up interoperability issue. >> Carsten Bormann wrote: >>> There is no expectation that a tool that does not implement a contr= ol >>> operator is particularly useful with a specification that does use = it. >> >> okay, but wouldn't it still be good if there was a declaration at th= e top of >> the file as to which revision of the specification the CDDL is assum= ing, >> just so that the tool can fail gracefully? > Once there is such a revision, that might make sense. Not really. It needs to in this version. Something like: "CDDL RFC9123" at the top.... > Adding a control operator is not a revision =E2=80=94 that is the who= le point > about exposing an extension point. Sure. > (A tool can easily compare its inventory of control operators with the > set used in the specification; no need for a separate declaration > here.) So, the error is: "RFC9756 control operator found in specification that claims RFC9123" =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlv0WNMACgkQgItw+93Q 3WUGjgf/dJoR99QCi/orfeeHQzOe37DN8g3MIP6M6VftivH32dEQY80no/IvV2B4 ZMHGz9+oxGVhW8/5vsM1MPvjvHxP0rfOsOMug4YaBD+ODI5S9bljWym29Uf+725Q JiQG9SO7H5aGU0TM0ogb2josxo8Xjm8wEualO6wvkvHdF4ymZ3cWM8kpMQtzd+wf +UNqrK31JmkPQubxsLvymGnEqNCGP2NU46xQcWewGDvP4V7tDKj9eRZ4hwnvbMgQ i0CHNaa+NrxweoIhqPiB2N/I8kk1JC0vbHP1y5I2H6GJViDztR7dIFe7dBi4BXx5 tlwbFTJ5RzgwH7yjZjPn5Oi5V6VFwg== =Hr7S -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 20 11:16:28 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07029130DDA for ; Tue, 20 Nov 2018 11:16:22 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biae2LJ2TELH for ; Tue, 20 Nov 2018 11:16:19 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 A71A3130DD2 for ; Tue, 20 Nov 2018 11:16:14 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id l15-v6so2631701lja.9 for ; Tue, 20 Nov 2018 11:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TnVfGCDhCWv7BLAlt9mPybFBxJMhqnnfEaX0cC59nfU=; b=uIyx6cebtglt1gJbniqenDVpfu8g5LhDionDw729T0LwXQZb2/5eDThdIVBs4r3MUo LjrIwignE99IK4TFGLDeRT8Zr6wbC6NQL6Haoy2jgQmgfpl2DO71gHwDxUGQv6rSLJkR udLMy4W7GUadozcL1XVLDaRqLAVA/llEJ8WGvpUOqYFZlW+11XaqAeZiVjiABQoxi5Rz aUMlp4Z3XiHm3a/Nvftzr0menK2KFoBNzpspvnZTnmnkdOH8tCLrN8un00XZrFxRuS2C 61bA3oPvTLOKx77cfynNT10YxLglLtOUd70ewV2Ikje6atobsbUz2vXKFfb94m4v2ty8 2zrg== 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=TnVfGCDhCWv7BLAlt9mPybFBxJMhqnnfEaX0cC59nfU=; b=KAp77A+Qo+3rojYF1hgjPzsn4ZWjB1hU50eiPG+C+oKBiJYjK16HhWczOFf4ZSFf2o pMVd8j0lapinIADM1um7EF2W2QvM+VtbyItkkO+PGAACYJIIflrbH0Ycbvzcyo2Y/O2S /sud7USyCfY87Ix67XK5D/pYX5AJcmwGkMhUEgfttvx3aC6r+Yfh1MFlr4Eb8trwkgqU URVUoOAl7o2ix04y967AcYDVs8TcxL31j5krQQksuQ2psJyUCfSHncPn0F3HEnJPAa4D GSMrN9NspZ46A2+Jg8QbGo7Oq7G3s3Tjo9oXX1hpWjW1woNpTd+d+ylCxWnC1DUg3nxr +IFg== X-Gm-Message-State: AA+aEWY3D/EJWjZnk64QM84RJhwoRDzBnzSM0VBaEQpKNlTr2RHhsHax VKfoSLwcibtjRgocS/UVUmDspLYP0s/GgfhxrLmkTg== X-Google-Smtp-Source: AFSGD/WOcQDILoE1GUnzyfWT/PsKKFr/wZDJ+jWnEvwcP6BgvwfgwEBh3RNtzXXdSRJNznaWzvZW51M14KdDbO3/iYE= X-Received: by 2002:a2e:5418:: with SMTP id i24-v6mr2153090ljb.51.1542741372748; Tue, 20 Nov 2018 11:16:12 -0800 (PST) MIME-Version: 1.0 References: <154267838656.26631.4178048052675609107.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Tue, 20 Nov 2018 11:15:36 -0800 Message-ID: To: Carsten Bormann Cc: IESG , cbor@ietf.org, Barry Leiba , cbor-chairs@ietf.org, draft-ietf-cbor-cddl@ietf.org Content-Type: multipart/alternative; boundary="00000000000080e2c7057b1d77f6" Archived-At: Subject: Re: [Cbor] Eric Rescorla's Discuss on draft-ietf-cbor-cddl-06: (with DISCUSS and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 19:16:22 -0000 --00000000000080e2c7057b1d77f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 20, 2018 at 8:14 AM Carsten Bormann wrote: > Hi Eric, > > thank you for this detailed review. > > Comments below. > > Gr=C3=BC=C3=9Fe, Carsten > > > > > On Nov 20, 2018, at 02:46, Eric Rescorla wrote: > > > > Eric Rescorla has entered the following ballot position for > > draft-ietf-cbor-cddl-06: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D4234 > > > > > > I am marking this document discussed because I have concerns about > > whether this document can be interoperably implemented. I have noted a > > number of points below. > > > > DETAIL > > S 3.5.2. > >> point.) > >> > >> 3.5.2. Tables > >> > >> A table can be specified by defining a map with entries where the > >> keytype is not single-valued, e.g.: > > > > this is the first use of the term single-valued, so I don't know how > > to interpret this. > > A single-valued type is a type that consists of only a single value. > (In CDDL, constants give rise to single-valued types =E2=80=94 there is n= o > separate concept for carrying around values.) > > I have made this more explicit now: > > before a colon). A string also is a type (that contains a single > value only =E2=80=94 the given string), so another > form for this example is: > If you want to say "single-valued type" later, you need to define it here > > (567e8ee in the current github version https://github.com/cbor-wg/cddl ) > > > More generally: it seems like: > > > > ``` > > square-roots =3D {x =3D> y} > > x =3D int > > y =3D float > > ``` > > > > Defines a map and yet > > > > ``` > > square-roots =3D {x =3D> y} > > y =3D float > > ``` > > > > Defines a struct. Is that correct? If so, does that mean that I don't > > know whether something is a map or a struct until I ahve parsed the > > whole definition? > > Struct, table, etc. are " four loosely > distinguishable styles of composition=E2=80=9D. > There is no interoperability semantics to these usage styles. > > Maps and arrays are the two kinds of containers offered by CBOR. Maps ar= e > suitable for carrying around tables and structs, arrays for vectors and > records. In the table/vector case, the map/array is indeed the high leve= l > semantics implied by the style; for struct/record map/array are just > convenient containers. > I get that, but I don't think it's responsive here. In the former case {1: 1.0} is a valid input, whereas in the latter case, {"x": 1.0} is a valid input. And as far as I can tell, until I have seen the definition for |x| I can't tell which one. Is that correct? > S 3.5.3. > >> mynumber =3D int / float > >> > >> 3.5.3. Non-deterministic order > >> > >> While the way arrays are matched is fully determined by the Parsin= g > >> Expression Grammar (PEG) algorithm, matching is more complicated f= or > > > > PEG is an informative reference, and this text seems to create a > > normative dependency. > > Many of our specifications make use of theory in one form or another > without needing a normative dependency to a textbook. > RFC 5234 does not even have a reference for BNF. Since PEGs have been a > staple for parsing theory only for less than 15 years, we thought a > reference might be useful. > Then you need to rewrite this text, because here and below, it implies that I need to read PEG in order to understand this specification. > > S 3.6. > >> * tstr =3D> any > >> } > >> > >> 3.6. Tags > >> > >> A type can make use of a CBOR tag (major type 6) by using the > > > > What happens if I define a type twice? Is that permitted? > > Adam Roach also brought this up =E2=80=94 which led to 60c22df. > I'm surprised that you allow any redefinition or all. > > S 3.7. > >> buuid =3D #6.37(bstr) > >> > >> In the following example, usage of the tag 32 for URIs is optional= : > >> > >> my_uri =3D #6.32(tstr) / tstr > >> > > > > I am basically unable to make sense of this section. Your previous > > example of tags used #7.25 but here you are specifying everything as > > using 6. > > 6 is CBOR=E2=80=99s major type for tags. #7.25 is not a tag, but a (16-b= it) > floating point value. > Yes, I understand that. The example shows how to construct tagged items by using the #6.xxx(ttt) > syntax, where xxx is a tag value and ttt is the type of the data item > enclosed by the tag. > > > It seems like the semantics here are something to the effect of: > > > > X =3D #6.Y(Z) > > > > means: act as if this were a thing of type Z but it's tagged by Y. > > > > Is that correct? But then is this about the wire encoding or the > > interpretation or both? And in either case, what if what appears on > > the wire has a different tag. > > Tags are visible at the CBOR data model level. > A tag with a different value than Y would not match #6.Y(Z), independent > of whether the enclosed data item maps Z. > I don't understand what this means. Can you please answer the specific questions I asked above? > > S 3.8.2. > >> cwr: 15, > >> ns: 0, > >> ) / (4..7) ; data offset bits > >> > >> rwxbits =3D uint .bits rwx > >> rwx =3D &(r: 2, w: 1, x: 0) > > > > What is the scope of the definition for r, w, and x? is it global. > > There is no scope =E2=80=94 everything is global. > (The only scopes are for the formal parameters of generics.) > So, r, w, and x are global? > > S 3.9. > >> $$tcp-option //=3D ( > >> sack-permitted: true > >> ) > >> > >> Names that start with a single "$" are "type sockets", names with = a > >> double "$$" are "group sockets". It is not an error if there is n= o > > > > what is the difference between these two? > > Type sockets take additional types via /=3D. > Group sockets take alternative groups via //=3D. > Please add this to the text. > S 7.3. > >> order of the rules given. (It is not an error to extend a rule na= me > >> that has not yet been defined; this makes the right hand side the > >> first entry in the choice being created.) > >> > >> genericparm =3D "<" S id S *("," S id S ) ">" > >> genericarg =3D "<" S type1 S *("," S type1 S ) ">" > > > > What is the meaning of > > I don=E2=80=99t know =E2=80=94 currently it is not allowed to have type c= hoices in a > generic argument. > (Maybe I=E2=80=99m missing some context.) > No, I misread the ABNF for type a stype1. > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > S 1.2. > >> capitals, as shown here. > >> > >> 1.2. Terminology > >> > >> New terms are introduced in _cursive_. CDDL text in the running > text > >> is in "typewriter". > > > > I think you mean that these types of text will be indicated by being > > bracketed by _ or ", but this isn't clear from this text. It's > > especially not clear when you then quote byte and octet. > > XML2RFC currently uses quotes for indicating typewriter text. > Well, this just turns into quoted text in the text version of the RFC, so it's not typewriter text. If you're going to use syntactic conventions, you need to more clearly state them for the text version. > > S 2. > >> There are a number of more or less atomic elements of a CBOR data > >> model, such as numbers, simple values (false, true, nil), text and > >> byte strings; CDDL does not focus on specifying their structure. > >> CDDL of course also allows adding a CBOR tag to a data item. > >> > >> The more important components of a data structure definition > language > > > > More important than what? > > Than the atomic elements (because these are mostly trivial to specify). > Please add this to the text. > > > S 2.2.3. > >> in the prelude: > >> > >> my_breakfast =3D #6.55799(breakfast) ; cbor-any is too genera= l! > >> breakfast =3D cereal / porridge > >> cereal =3D #6.998(tstr) > >> porridge =3D #6.999([liquid, solid]) > > > > What is the parenthetical syntax here? > > This is the syntax for specifying tags and the type for their enclosed > value. > I don't understand that. Please expand. > > S 3.1. > >> according to the respective syntactic rules of that definition. > >> > >> o A name can consist of any of the characters from the set {'A', > >> ..., 'Z', 'a', ..., 'z', '0', ..., '9', '_', '-', '@', '.', '$'= }, > >> starting with an alphabetic character (including '@', '_', '$') > >> and ending in one or a digit. > > > > This seems to say that names end in a digit, but none of your name > > examples do. > > Clarified in 9a611bb > > > S 3.2. > >> An optional _occurrence_ indicator can be given in front of a grou= p > >> entry. It is either one of the characters '?' (optional), '*' (ze= ro > >> or more), or '+' (one or more), or is of the form n*m, where n and= m > >> are optional unsigned integers and n is the lower limit (default 0= ) > >> and m is the upper limit (default no limit) of occurrences. > >> > > > > isn=E2=80=99t bare * then just a degenerate case of n*m > > Yes. > It is still useful to also show * besides ? and +. > Sure. I just meant that you might just explain n*m rather than * > > S 3.5.1. > >> written with quoted strings in the member key positions. More > >> generally, all the types defined can be used in a keytype position > by > >> following them with a double arrow -- in particular, the double > arrow > >> is necessary if a type is named by an identifier (which would be > >> interpreted as a string before a colon). A string also is a > (single- > >> valued) type, so another form for this example is: > > > > I'm sorry, I'm not following this. Can you give an example of when you > > have to use =3D> > > If you need to use a name for a type. With =E2=80=9C:=E2=80=9D, names be= come bare words > (strings without the =E2=80=9C=E2=80=A6=E2=80=9D decoration). > OK, this isn't clear, so maybe you can rewrite it. > > S 3.10. > >> message =3D {type: t, value: v} > >> > >> When using a generic rule, the formal parameters are bound to the > >> actual arguments supplied (also using angle brackets), within the > >> scope of the generic rule (as if there were a rule of the form > >> parameter =3D argument). > > > > This looks more like a macro than a generic. > > It is not just lexical replacement, which is what =E2=80=9Cmacro=E2=80=9D= usually implies. > In what way is it not lexical replacement (Strictly speaking, it is comparable to a =E2=80=9Cmacro=E2=80=9D in the Sc= heme tradition, > but the way this concept is used in CDDL is now better known as =E2=80=9C= generic > type=E2=80=9D.) > > > S 7.3. > >> definition with different member names); RFC 7071 could be read to > >> forbid the repetition of ext-value ("A specific reputon-element MU= ST > >> NOT appear more than once" is ambiguous.) > >> > >> The CDDL tool (which hasn't quite been trained for polite > >> conversation) says: > > > > It seems like it might be a good idea to clean up the examples here so > > they are in fact polite. > > We can do that if it is considered desirable. > Near-mandatory, I would think. > > S 7.3. > >> "Thumbnail": {"Width": 1111, "Height": 176, "Url": 32("scrog")}= , > >> "IDs": []}} > >> > >> Appendix B. ABNF grammar > >> > >> The following is a formal definition of the CDDL syntax in Augment= ed > > > > It's pretty odd to have the formal specification -- which clearly is > > needed to understand and implement this document =E2=80=94 in an append= ix. > > In -06, we have prefixed the normative appendices with > > This appendix is normative. > > (So many documents reference specific appendices of draft-ietf-cbor-cddl > that we tried to minimize confusion by minimizing moving them around.) > > > > > S 7.3. > >> type =3D type1 S *("/" S type1 S) > >> > >> A type can be given as a choice between one or more types. The > >> choice matches a data item if the data item matches any one of the > >> types given in the choice. The choice uses Parsing Expression > >> Grammar [PEG] semantics: The first choice that matches wins. (As = a > > > > Is this the only information I need? > > I think that is the essence; it certainly helps to be familiar with PEG > theory. > Then you should probably rewrite this text to make thatclear. -Ekr > > S 7.3. > >> control operators. > >> > >> group =3D grpchoice S *("//" S grpchoice S) > >> > >> A group matches any sequence of key/value pairs that matches any o= f > >> the choices given (again using Parsing Expression Grammar > semantics). > > > > This also seems not fully defined. > > Similar. We did add Section 3.5.3 to provide more details for the more > complicated map matching case. > > .oOo. > > --00000000000080e2c7057b1d77f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Hi Eric,

thank you for this detailed review.

Comments below.

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



> On Nov 20, 2018, at 02:46, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-cbor-cddl-06: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ie= tf-cbor-cddl/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D4234<= /a>
>
>
> I am marking this document discussed because I have concerns about
> whether this document can be interoperably implemented. I have noted a=
> number of points below.
>
> DETAIL
> S 3.5.2.
>>=C2=A0 =C2=A0 =C2=A0point.)
>>
>>=C2=A0 3.5.2.=C2=A0 Tables
>>
>>=C2=A0 =C2=A0 =C2=A0A table can be specified by defining a map with= entries where the
>>=C2=A0 =C2=A0 =C2=A0keytype is not single-valued, e.g.:
>
> this is the first use of the term single-valued, so I don't know h= ow
> to interpret this.

A single-valued type is a type that consists of only a single value.
(In CDDL, constants give rise to single-valued types =E2=80=94 there is no = separate concept for carrying around values.)

I have made this more explicit now:

=C2=A0 =C2=A0before a colon).=C2=A0 A string also is a type (that contains = a single
=C2=A0 =C2=A0value only =E2=80=94 the given string), so another
=C2=A0 =C2=A0form for this example is:


(567e8ee in the current github version https://github.com/cbor-wg/cdd= l )

> More generally: it seems like:
>
> ```
>=C2=A0 square-roots =3D {x =3D> y}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0x =3D int
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0y =3D float
> ```
>
> Defines a map and yet
>
> ```
>=C2=A0 square-roots =3D {x =3D> y}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0y =3D float
> ```
>
> Defines a struct. Is that correct? If so, does that mean that I don= 9;t
> know whether something is a map or a struct until I ahve parsed the > whole definition?

Struct, table, etc. are " four loosely
distinguishable styles of composition=E2=80=9D.=C2=A0
There is no interoperability semantics to these usage styles.

Maps and arrays are the two kinds of containers offered by CBOR.=C2=A0 Maps= are suitable for carrying around tables and structs, arrays for vectors an= d records.=C2=A0 In the table/vector case, the map/array is indeed the high= level semantics implied by the style; for struct/record map/array are just= convenient containers.

I get that, but= I don't think it's responsive here. In the former case {1: 1.0} is= a valid input, whereas in the latter case, {"x": 1.0} is a valid= input. And as far as I can tell, until I have seen the definition for |x| = I can't tell which one. Is that correct?


<= /div>
> S 3.5.3.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 mynumber =3D int / float
>>
>>=C2=A0 3.5.3.=C2=A0 Non-deterministic order
>>
>>=C2=A0 =C2=A0 =C2=A0While the way arrays are matched is fully deter= mined by the Parsing
>>=C2=A0 =C2=A0 =C2=A0Expression Grammar (PEG) algorithm, matching is= more complicated for
>
> PEG is an informative reference, and this text seems to create a
> normative dependency.

Many of our specifications make use of theory in one form or another withou= t needing a normative dependency to a textbook.
RFC 5234 does not even have a reference for BNF.=C2=A0 Since PEGs have been= a staple for parsing theory only for less than 15 years, we thought a refe= rence might be useful.

Then you need to= rewrite this text, because here and below, it implies that I need to read = PEG in order to understand this specification.

=C2=A0
> S 3.6.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * tstr =3D> any
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 }
>>
>>=C2=A0 3.6.=C2=A0 Tags
>>
>>=C2=A0 =C2=A0 =C2=A0A type can make use of a CBOR tag (major type 6= ) by using the
>
> What happens if I define a type twice? Is that permitted?

Adam Roach also brought this up =E2=80=94 which led to 60c22df.

I'm surprised that you allow any redefinition = or all.


> S 3.7.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 buuid =3D #6.37(bstr)
>>
>>=C2=A0 =C2=A0 =C2=A0In the following example, usage of the tag 32 f= or URIs is optional:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 my_uri =3D #6.32(tstr) / tstr
>>
>
> I am basically unable to make sense of this section. Your previous
> example of tags used #7.25 but here you are specifying everything as > using 6.

6 is CBOR=E2=80=99s major type for tags.=C2=A0 #7.25 is not a tag, but a (1= 6-bit) floating point value.

Yes, I und= erstand that.


The example shows how to construct tagged items by using the #6.xxx(ttt) sy= ntax, where xxx is a tag value and ttt is the type of the data item enclose= d by the tag.

> It seems like the semantics here are something to the effect of:
>
> X =3D #6.Y(Z)
>
> means: act as if this were a thing of type Z but it's tagged by Y.=
>
> Is that correct? But then is this about the wire encoding or the
> interpretation or both? And in either case, what if what appears on > the wire has a different tag.

Tags are visible at the CBOR data model level.
A tag with a different value than Y would not match #6.Y(Z), independent of= whether the enclosed data item maps Z.

I don't understand what this means. Can you please answer the specific= questions I asked above?

=C2=A0
> S 3.8.2.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 cwr: 15,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ns: 0,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 ) / (4..7) ; data offset bits
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 rwxbits =3D uint .bits rwx
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 rwx =3D &(r: 2, w: 1, x: 0)
>
> What is the scope of the definition for r, w, and x? is it global.

There is no scope =E2=80=94 everything is global.
(The only scopes are for the formal parameters of generics.)

So, r, w, and x are global?


> S 3.9.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 $$tcp-option //=3D= (
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sack-permitted: tr= ue
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 )
>>
>>=C2=A0 =C2=A0 =C2=A0Names that start with a single "$" ar= e "type sockets", names with a
>>=C2=A0 =C2=A0 =C2=A0double "$$" are "group sockets&q= uot;.=C2=A0 It is not an error if there is no
>
> what is the difference between these two?

Type sockets take additional types via /=3D.
Group sockets take alternative groups via //=3D.

<= /div>
Please add this to the text.


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> > S 7.3.
>>=C2=A0 =C2=A0 =C2=A0order of the rules given.=C2=A0 (It is not an e= rror to extend a rule name
>>=C2=A0 =C2=A0 =C2=A0that has not yet been defined; this makes the r= ight hand side the
>>=C2=A0 =C2=A0 =C2=A0first entry in the choice being created.)
>>
>>=C2=A0 =C2=A0 =C2=A0genericparm =3D "<" S id S *("= ;," S id S ) ">"
>>=C2=A0 =C2=A0 =C2=A0genericarg =3D "<" S type1 S *(&qu= ot;," S type1 S ) ">"
>
> What is the meaning of=C2=A0 <a/b>

I don=E2=80=99t know =E2=80=94 currently it is not allowed to have type cho= ices in a generic argument.
(Maybe I=E2=80=99m missing some context.)

No, I misread the ABNF for type a stype1.

<= br>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> S 1.2.
>>=C2=A0 =C2=A0 =C2=A0capitals, as shown here.
>>
>>=C2=A0 1.2.=C2=A0 Terminology
>>
>>=C2=A0 =C2=A0 =C2=A0New terms are introduced in _cursive_.=C2=A0 CD= DL text in the running text
>>=C2=A0 =C2=A0 =C2=A0is in "typewriter".
>
> I think you mean that these types of text will be indicated by being > bracketed by _ or ", but this isn't clear from this text. It&= #39;s
> especially not clear when you then quote byte and octet.

XML2RFC currently uses quotes for indicating typewriter text.

Well, this just turns into quoted text in the text v= ersion of the RFC, so it's
not typewriter text. If you're= going to use syntactic conventions, you need
to more clearly sta= te them for the text version.



=

> S 2.
>>=C2=A0 =C2=A0 =C2=A0There are a number of more or less atomic eleme= nts of a CBOR data
>>=C2=A0 =C2=A0 =C2=A0model, such as numbers, simple values (false, t= rue, nil), text and
>>=C2=A0 =C2=A0 =C2=A0byte strings; CDDL does not focus on specifying= their structure.
>>=C2=A0 =C2=A0 =C2=A0CDDL of course also allows adding a CBOR tag to= a data item.
>>
>>=C2=A0 =C2=A0 =C2=A0The more important components of a data structu= re definition language
>
> More important than what?

Than the atomic elements (because these are mostly trivial to specify).
=

Please add this to the text.

=C2=A0

> S 2.2.3.
>>=C2=A0 =C2=A0 =C2=A0in the prelude:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 my_breakfast =3D #6.55799(breakfast)=C2= =A0 =C2=A0; cbor-any is too general!
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 breakfast =3D cereal / porridge
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 cereal =3D #6.998(tstr)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 porridge =3D #6.999([liquid, solid]) >
> What is the parenthetical syntax here?

This is the syntax for specifying tags and the type for their enclosed valu= e.

I don't understand that. Please = expand.


> S 3.1.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 according to the respective syntactic r= ules of that definition.
>>
>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 A name can consist of any of the charac= ters from the set {'A',
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ..., 'Z', 'a', ..., = 9;z', '0', ..., '9', '_', '-', '@&#= 39;, '.', '$'},
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 starting with an alphabetic character (= including '@', '_', '$')
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 and ending in one or a digit.
>
> This seems to say that names end in a digit, but none of your name
> examples do.

Clarified in 9a611bb

> S 3.2.
>>=C2=A0 =C2=A0 =C2=A0An optional _occurrence_ indicator can be given= in front of a group
>>=C2=A0 =C2=A0 =C2=A0entry.=C2=A0 It is either one of the characters= '?' (optional), '*' (zero
>>=C2=A0 =C2=A0 =C2=A0or more), or '+' (one or more), or is o= f the form n*m, where n and m
>>=C2=A0 =C2=A0 =C2=A0are optional unsigned integers and n is the low= er limit (default 0)
>>=C2=A0 =C2=A0 =C2=A0and m is the upper limit (default no limit) of = occurrences.
>>
>
> isn=E2=80=99t bare * then just a degenerate case of n*m

Yes.
It is still useful to also show * besides ? and +.
Sure. I just meant that you might just explain n*m rather than = *

=C2=A0
> S 3.5.1.
>>=C2=A0 =C2=A0 =C2=A0written with quoted strings in the member key p= ositions.=C2=A0 More
>>=C2=A0 =C2=A0 =C2=A0generally, all the types defined can be used in= a keytype position by
>>=C2=A0 =C2=A0 =C2=A0following them with a double arrow -- in partic= ular, the double arrow
>>=C2=A0 =C2=A0 =C2=A0is necessary if a type is named by an identifie= r (which would be
>>=C2=A0 =C2=A0 =C2=A0interpreted as a string before a colon).=C2=A0 = A string also is a (single-
>>=C2=A0 =C2=A0 =C2=A0valued) type, so another form for this example = is:
>
> I'm sorry, I'm not following this. Can you give an example of = when you
> have to use =3D>

If you need to use a name for a type.=C2=A0 With =E2=80=9C:=E2=80=9D, names= become bare words (strings without the =E2=80=9C=E2=80=A6=E2=80=9D decorat= ion).

OK, this isn't clear, so mayb= e you can rewrite it.


> S 3.10.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 message<t, v> =3D {type: t, value= : v}
>>
>>=C2=A0 =C2=A0 =C2=A0When using a generic rule, the formal parameter= s are bound to the
>>=C2=A0 =C2=A0 =C2=A0actual arguments supplied (also using angle bra= ckets), within the
>>=C2=A0 =C2=A0 =C2=A0scope of the generic rule (as if there were a r= ule of the form
>>=C2=A0 =C2=A0 =C2=A0parameter =3D argument).
>
> This looks more like a macro than a generic.

It is not just lexical replacement, which is what =E2=80=9Cmacro=E2=80=9D u= sually implies.

In what way is it not l= exical replacement


(Strictly speaking, it is comparable to a =E2=80=9Cmacro=E2=80=9D in the Sc= heme tradition, but the way this concept is used in CDDL is now better know= n as =E2=80=9Cgeneric type=E2=80=9D.)

> S 7.3.
>>=C2=A0 =C2=A0 =C2=A0definition with different member names); RFC 70= 71 could be read to
>>=C2=A0 =C2=A0 =C2=A0forbid the repetition of ext-value ("A spe= cific reputon-element MUST
>>=C2=A0 =C2=A0 =C2=A0NOT appear more than once" is ambiguous.)<= br> >>
>>=C2=A0 =C2=A0 =C2=A0The CDDL tool (which hasn't quite been trai= ned for polite
>>=C2=A0 =C2=A0 =C2=A0conversation) says:
>
> It seems like it might be a good idea to clean up the examples here so=
> they are in fact polite.

We can do that if it is considered desirable.

Near-mandatory, I would think.


> S 7.3.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Thumbnail": {"Width&quo= t;: 1111, "Height": 176, "Url": 32("scrog")},=
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "IDs": []}}
>>
>>=C2=A0 Appendix B.=C2=A0 ABNF grammar
>>
>>=C2=A0 =C2=A0 =C2=A0The following is a formal definition of the CDD= L syntax in Augmented
>
> It's pretty odd to have the formal specification -- which clearly = is
> needed to understand and implement this document =E2=80=94 in an appen= dix.

In -06, we have prefixed the normative appendices with

=C2=A0 =C2=A0This appendix is normative.

(So many documents reference specific appendices of draft-ietf-cbor-cddl th= at we tried to minimize confusion by minimizing moving them around.)



> S 7.3.
>>=C2=A0 =C2=A0 =C2=A0type =3D type1 S *("/" S type1 S)
>>
>>=C2=A0 =C2=A0 =C2=A0A type can be given as a choice between one or = more types.=C2=A0 The
>>=C2=A0 =C2=A0 =C2=A0choice matches a data item if the data item mat= ches any one of the
>>=C2=A0 =C2=A0 =C2=A0types given in the choice.=C2=A0 The choice use= s Parsing Expression
>>=C2=A0 =C2=A0 =C2=A0Grammar [PEG] semantics: The first choice that = matches wins.=C2=A0 (As a
>
> Is this the only information I need?

I think that is the essence; it certainly helps to be familiar with PEG the= ory.

Then you should probably rewrite t= his text to make thatclear.

-Ekr


> S 7.3.
>>=C2=A0 =C2=A0 =C2=A0control operators.
>>
>>=C2=A0 =C2=A0 =C2=A0group =3D grpchoice S *("//" S grpcho= ice S)
>>
>>=C2=A0 =C2=A0 =C2=A0A group matches any sequence of key/value pairs= that matches any of
>>=C2=A0 =C2=A0 =C2=A0the choices given (again using Parsing Expressi= on Grammar semantics).
>
> This also seems not fully defined.

Similar.=C2=A0 We did add Section 3.5.3 to provide more details for the mor= e complicated map matching case.

.oOo.

--00000000000080e2c7057b1d77f6-- From nobody Tue Nov 20 11:59:34 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7E4130DFF for ; Tue, 20 Nov 2018 11:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.72 X-Spam-Level: X-Spam-Status: No, score=-9.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] 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 prAdtGpTAuOh for ; Tue, 20 Nov 2018 11:59:19 -0800 (PST) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 DA8D1130DC6 for ; Tue, 20 Nov 2018 11:59:18 -0800 (PST) Received: by mail-yb1-xb2c.google.com with SMTP id u103-v6so1251245ybi.5 for ; Tue, 20 Nov 2018 11:59:18 -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=4VcUhH2u21mi/6t/WaEwsBBRokujxkxUYHmdBfcVMeY=; b=iK17xa3YRoEcpa0ZLpR4sDhR/M9TyjGyPf1olDG7sqEBr+IkhJ+CMcm72dcj0K/D1O BL5He4cnFYiPsMek6psCRL6bHbb2xaqK0rSYTSC+Rj9pel4VWxDuyiuJpUPnVd41Umks bXsCnovupktKXnFmm42D3y4wREw02VxKwseYY= 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=4VcUhH2u21mi/6t/WaEwsBBRokujxkxUYHmdBfcVMeY=; b=WxI094+4hUpuHcFAksRJutMKN/9k5K759B82fPLSRpD27Na4u7r+Ly69dFHFoRZTNZ EquiNTes4NuQhScWPCBtGZqAtATH8cficYm7bLYn+0xvMcHm/alQkWsZ0T7n0EhT6NCG HbIOa6Xd8zkEwEw+AykVcB8REVSdXIAmGrxTEc7H5/rf9L/UIZdpAq7PAiz+fat3VEIg VnjS3HwikZYyUc9zz5qXHtNAao59Jv+heDMN7dDFZaWCCZ7b5iI3i14f8kwoZOzkl2IK 53CwIY64IdSWGxhwf23w/CniLB/48Zje1YUPZnKIcx4b6dN5kfnDizC08KeDT+y9RKof KUkg== X-Gm-Message-State: AA+aEWbiQSYp0e+dgG2CPYQ+GdtCGJa6EwrMnkoloKLeIG+ohtJlM25u m0R8RdIW8eT6WThiX/7wRWz2ihD1vngksHCabPvAOBx6dEU= X-Google-Smtp-Source: AFSGD/VJgq8Hb4w8tCCNgVeYjxiP2tKwoOjJ9C1rIOUFrv2VqJUZ34MNYzGvNl+d/nydFtFlaY1HttRctQxnBnHX++M= X-Received: by 2002:a25:c441:: with SMTP id u62-v6mr3366864ybf.424.1542743957557; Tue, 20 Nov 2018 11:59:17 -0800 (PST) MIME-Version: 1.0 References: <154269134623.26525.15947501642666003321.idtracker@ietfa.amsl.com> <91495E47-A203-472E-8FFB-19A648D537C0@tzi.org> <29344.1542730100@localhost> <91D62AC5-769E-4D8A-915F-CD6E4902DB43@tzi.org> <5807.1542740180@localhost> In-Reply-To: <5807.1542740180@localhost> From: Jeffrey Yasskin Date: Tue, 20 Nov 2018 11:59:05 -0800 Message-ID: To: mcr+ietf@sandelman.ca Cc: Carsten Bormann , cbor@ietf.org Content-Type: multipart/alternative; boundary="000000000000927d1f057b1e1166" Archived-At: Subject: Re: [Cbor] Adam Roach's Discuss on draft-ietf-cbor-cddl-06: (with DISCUSS and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 19:59:25 -0000 --000000000000927d1f057b1e1166 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 20, 2018 at 10:56 AM Michael Richardson wrote: > > Carsten Bormann wrote: > Adam> With the lack of any version indicators in CDDL, this seems lik= e > a > Adam> straight-up interoperability issue. > > >> Carsten Bormann wrote: > >>> There is no expectation that a tool that does not implement a > control > >>> operator is particularly useful with a specification that does us= e > it. > >> > >> okay, but wouldn't it still be good if there was a declaration at > the top of > >> the file as to which revision of the specification the CDDL is > assuming, > >> just so that the tool can fail gracefully? > > > Once there is such a revision, that might make sense. > > Not really. It needs to in this version. > Something like: > "CDDL RFC9123" > > at the top.... > > > Adding a control operator is not a revision =E2=80=94 that is the w= hole point > > about exposing an extension point. > > Sure. > > > (A tool can easily compare its inventory of control operators with > the > > set used in the specification; no need for a separate declaration > > here.) > > So, the error is: > "RFC9756 control operator found in specification that claims RFC9123" > I think Carsten's point is that in order to declare the set of control operators in use, it's not sufficient to declare just the CDDL RFC. A CDDL document might be using CDDL RFC9123 and also control operators from RFC9234, ISO123456, and W3C REC better-cddl-1. Needing to list all of those, or even just explicitly list the control operators in use, seems like a pain, and doesn't seem to help old tools reject new controls much earlier in processing. Jeffrey --000000000000927d1f057b1e1166 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 20= , 2018 at 10:56 AM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Carsten Bormann <cabo@= tzi.org> wrote:
=C2=A0 =C2=A0 Adam> With the lack of any version indicators in CDDL, thi= s seems like a
=C2=A0 =C2=A0 Adam> straight-up interoperability issue.

=C2=A0 =C2=A0 >> Carsten Bormann <cabo@tzi.org> wrote:
=C2=A0 =C2=A0 >>> There is no expectation that a tool that does no= t implement a control
=C2=A0 =C2=A0 >>> operator is particularly useful with a specifica= tion that does use it.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> okay, but wouldn't it still be good if there was= a declaration at the top of
=C2=A0 =C2=A0 >> the file as to which revision of the specification t= he CDDL is assuming,
=C2=A0 =C2=A0 >> just so that the tool can fail gracefully?

=C2=A0 =C2=A0 > Once there is such a revision, that might make sense.
Not really. It needs to in this version.
Something like:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "CDDL RFC9123"

at the top....

=C2=A0 =C2=A0 > Adding a control operator is not a revision =E2=80=94 th= at is the whole point
=C2=A0 =C2=A0 > about exposing an extension point.

Sure.

=C2=A0 =C2=A0 > (A tool can easily compare its inventory of control oper= ators with the
=C2=A0 =C2=A0 > set used in the specification; no need for a separate de= claration
=C2=A0 =C2=A0 > here.)

So, the error is:
=C2=A0 =C2=A0 "RFC9756 control operator found in specification that cl= aims RFC9123"

I think Carsten'= s point is that in order to declare the set of control operators in use, it= 's not sufficient to declare just the CDDL RFC. A CDDL document might b= e using CDDL RFC9123 and also control operators from RFC9234, ISO123456, an= d W3C REC better-cddl-1.

Needing to list all of th= ose, or even just explicitly list the control operators in use, seems like = a pain, and doesn't seem to help old tools reject new controls much ear= lier in processing.

Jeffrey
--000000000000927d1f057b1e1166-- From nobody Tue Nov 20 12:18:14 2018 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10784130DCC; Tue, 20 Nov 2018 12:18:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-cbor-cddl@ietf.org, Barry Leiba , cbor-chairs@ietf.org, barryleiba@computer.org, cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154274508600.29845.1211433401636524348.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 12:18:06 -0800 Archived-At: Subject: [Cbor] Ben Campbell's No Objection on draft-ietf-cbor-cddl-06: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 20:18:06 -0000 Ben Campbell has entered the following ballot position for draft-ietf-cbor-cddl-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Most of my comments have already been captured by others, save one: Is there a specific reason the normative appendices are not part of the main body? I think a lot of RFC readers assume that appendices are optional to read. We should not surprise them without reason. From nobody Tue Nov 20 12:33:37 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18508130DCC; Tue, 20 Nov 2018 12:33:36 -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 6oXbkReH56sk; Tue, 20 Nov 2018 12:33:34 -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 92EC412785F; Tue, 20 Nov 2018 12:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wAKKXN0e006997; Tue, 20 Nov 2018 21:33:29 +0100 (CET) Received: from sev.informatik.uni-bremen.de (sev.informatik.uni-bremen.de [134.102.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42zy8M63rjz1Bqf; Tue, 20 Nov 2018 21:33:23 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <154274508600.29845.1211433401636524348.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 21:33:23 +0100 Cc: The IESG , cbor@ietf.org, barryleiba@computer.org, cbor-chairs@ietf.org, draft-ietf-cbor-cddl@ietf.org X-Mao-Original-Outgoing-Id: 564438799.2329021-70e9880d0a35f4697abf2f7a1f26a370 Content-Transfer-Encoding: quoted-printable Message-Id: <64BB562B-45B1-436D-A413-4FD2FAE71AF6@tzi.org> References: <154274508600.29845.1211433401636524348.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Ben Campbell's No Objection on draft-ietf-cbor-cddl-06: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 20:33:36 -0000 Hi Ben, On Nov 20, 2018, at 21:18, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-cbor-cddl-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Most of my comments have already been captured by others, save one: >=20 > Is there a specific reason the normative appendices are not part of = the main > body? I think a lot of RFC readers assume that appendices are optional = to read. > We should not surprise them without reason. The original reason is that none of the authors is part of the tradition = that you can ignore appendices. (To the contrary, I=E2=80=99m used to documents where *all* the meat is = in the appendices; this is almost the normal state in the world of FDT.) The reason we didn=E2=80=99t reshuffle things when we heard that this = appears to be a widespread concept in the minds of IETFers is that there = are so many documents that refer to specific appendices of the draft, so = we didn=E2=80=99t want to disturb all those references. If you think this is a big enough problem that disturbing all these = references is worth fixing it, we can reshuffle. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Nov 20 13:39:22 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E948130E5E; Tue, 20 Nov 2018 13:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sB5R-GksnOIn; Tue, 20 Nov 2018 13:39:11 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0D311130E96; Tue, 20 Nov 2018 13:39:11 -0800 (PST) Received: from [10.0.1.24] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wAKLZslw061995 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Nov 2018 15:35:55 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.24] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_686CBBBA-62B0-4A9D-AA9F-0C0D729B0A73"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Tue, 20 Nov 2018 15:35:54 -0600 In-Reply-To: <64BB562B-45B1-436D-A413-4FD2FAE71AF6@tzi.org> Cc: cbor@ietf.org, Barry Leiba , The IESG , draft-ietf-cbor-cddl@ietf.org, cbor-chairs@ietf.org To: Carsten Bormann References: <154274508600.29845.1211433401636524348.idtracker@ietfa.amsl.com> <64BB562B-45B1-436D-A413-4FD2FAE71AF6@tzi.org> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [Cbor] Ben Campbell's No Objection on draft-ietf-cbor-cddl-06: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 21:39:20 -0000 --Apple-Mail=_686CBBBA-62B0-4A9D-AA9F-0C0D729B0A73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 20, 2018, at 2:33 PM, Carsten Bormann wrote: >=20 > Hi Ben, >=20 > On Nov 20, 2018, at 21:18, Ben Campbell wrote: >>=20 >> Ben Campbell has entered the following ballot position for >> draft-ietf-cbor-cddl-06: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Most of my comments have already been captured by others, save one: >>=20 >> Is there a specific reason the normative appendices are not part of = the main >> body? I think a lot of RFC readers assume that appendices are = optional to read. >> We should not surprise them without reason. >=20 > The original reason is that none of the authors is part of the = tradition that you can ignore appendices. > (To the contrary, I=E2=80=99m used to documents where *all* the meat = is in the appendices; this is almost the normal state in the world of = FDT.) > The reason we didn=E2=80=99t reshuffle things when we heard that this = appears to be a widespread concept in the minds of IETFers is that there = are so many documents that refer to specific appendices of the draft, so = we didn=E2=80=99t want to disturb all those references. >=20 > If you think this is a big enough problem that disturbing all these = references is worth fixing it, we can reshuffle. No, I don=E2=80=99t think it is that big of a problem. Thanks! Ben. --Apple-Mail=_686CBBBA-62B0-4A9D-AA9F-0C0D729B0A73 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlv0fjoACgkQgFZKbJXz 1A321Q//aZHvZNw9wXhKb2PYS8N9iTHs7dm0OnzhniLfPDlC6/pSuSLS/uie0Wht +rLYxyWT3+pAC7hlTmt/NEg99L1TqfWsR2FnZkEbTTlr+RvTGYuzsWYqK5zrb4qx Q4qIq4vU9x/mQHYcPNnq3SAix6Wj4R4qXqzi9gDAtN22P8sGpkMdFJfciKZ218yA Lmw4YPG25XPNpt9t/xqJwmlmuIqAkupU6QCO/1zsUB/j1GoYc5QG/dwgex0rjKa6 5+bWByTx4v3LYfKvgL2MCckjeLAh8AsuTGKqYQsbc4D2ldsr3GhN6Ce9tQIVOetm aG3iRrEm1mHyynV+XaRp71xHQ4+7FsT3fKLHcnVYhEsQXFnWDaC/TX3xXcyz/ty/ JU7ActQkVwWiedmjyfRHekUbecySPZMow+Av6XZCM6O+SyiTOTuKgAa2Dv4LhntB xAvTZLwQ5gF0uVuG5xLZcDACRYVGPLy5/6pxkYQrkTADaB/VoD33cC4TPWaVFuDV o+GgWgfaRlv/42TUatKXKYV9mxKptPS52gt/A/KzKayTGE2WRwZtZDWBPtfU/zhp OQFjzHi9MV7fBUBHyIOym3O22ixRvFudQW3LF/dIDW5x25MuCToBBMJ/UNskUHny Ba+dmn0lrmnWycX5Ps0RkN4C6r6so23lGBf0aL/QpSVEuYo8VCY= =59sq -----END PGP SIGNATURE----- --Apple-Mail=_686CBBBA-62B0-4A9D-AA9F-0C0D729B0A73-- From nobody Wed Nov 21 05:10:43 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CBE130DBE; Wed, 21 Nov 2018 05:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 ue2u8-lYXffS; Wed, 21 Nov 2018 05:10:37 -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 32F0612EB11; Wed, 21 Nov 2018 05:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wALDAQHh023223; Wed, 21 Nov 2018 14:10:31 +0100 (CET) Received: from [192.168.217.114] (p54A6CE66.dip0.t-ipconnect.de [84.166.206.102]) (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 430NGn3356z1Bqk; Wed, 21 Nov 2018 14:10:25 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 21 Nov 2018 14:10:24 +0100 Cc: IESG , cbor@ietf.org, Barry Leiba , cbor-chairs@ietf.org, draft-ietf-cbor-cddl@ietf.org X-Mao-Original-Outgoing-Id: 564498620.182718-bd85c8e7d25904cbd6a2d7057ac33b2e Content-Transfer-Encoding: quoted-printable Message-Id: <6882FA6E-B656-4539-AB4D-CF9272B7A269@tzi.org> References: <154267838656.26631.4178048052675609107.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Eric Rescorla's Discuss on draft-ietf-cbor-cddl-06: (with DISCUSS and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 13:10:41 -0000 Hi Eric, you probably won=E2=80=99t have time to read this before the telechat, = but I would like to keep the ball rolling. (For some reason, my mail reader doesn=E2=80=99t pick up the quoting = correctly in this reply; I hope it is still readable enough.) Gr=C3=BC=C3=9Fe, Carsten > On Nov 20, 2018, at 20:15, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, Nov 20, 2018 at 8:14 AM Carsten Bormann wrote: > Hi Eric, >=20 > thank you for this detailed review. >=20 > Comments below. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 > > On Nov 20, 2018, at 02:46, Eric Rescorla wrote: > >=20 > > Eric Rescorla has entered the following ballot position for > > draft-ietf-cbor-cddl-06: Discuss > >=20 > > When responding, please keep the subject line intact and reply to = all > > email addresses included in the To and CC lines. (Feel free to cut = this > > introductory paragraph, however.) > >=20 > >=20 > > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ > >=20 > >=20 > >=20 > > = ---------------------------------------------------------------------- > > DISCUSS: > > = ---------------------------------------------------------------------- > >=20 > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D4234 > >=20 > >=20 > > I am marking this document discussed because I have concerns about > > whether this document can be interoperably implemented. I have noted = a > > number of points below. > >=20 > > DETAIL > > S 3.5.2. > >> point.) > >>=20 > >> 3.5.2. Tables > >>=20 > >> A table can be specified by defining a map with entries where = the > >> keytype is not single-valued, e.g.: > >=20 > > this is the first use of the term single-valued, so I don't know how > > to interpret this. >=20 > A single-valued type is a type that consists of only a single value. > (In CDDL, constants give rise to single-valued types =E2=80=94 there = is no separate concept for carrying around values.) >=20 > I have made this more explicit now: >=20 > before a colon). A string also is a type (that contains a single > value only =E2=80=94 the given string), so another > form for this example is: >=20 > If you want to say =E2=80=9Csingle-valued type" later, you need to = define it here I now expanded the overly terse expression single-valued (and one = instance of multi-valued), in 9b06c30 > (567e8ee in the current github version https://github.com/cbor-wg/cddl = ) >=20 > > More generally: it seems like: > >=20 > > ``` > > square-roots =3D {x =3D> y} > > x =3D int > > y =3D float > > ``` > >=20 > > Defines a map and yet > >=20 > > ``` > > square-roots =3D {x =3D> y} > > y =3D float > > ``` > >=20 > > Defines a struct. Is that correct? If so, does that mean that I = don't > > know whether something is a map or a struct until I ahve parsed the > > whole definition? >=20 > Struct, table, etc. are " four loosely > distinguishable styles of composition=E2=80=9D. =20 > There is no interoperability semantics to these usage styles. >=20 > Maps and arrays are the two kinds of containers offered by CBOR. Maps = are suitable for carrying around tables and structs, arrays for vectors = and records. In the table/vector case, the map/array is indeed the high = level semantics implied by the style; for struct/record map/array are = just convenient containers. >=20 > I get that, but I don't think it's responsive here. In the former case = {1: 1.0} is a valid input, whereas in the latter case, {"x": 1.0} is a = valid input. And as far as I can tell, until I have seen the definition = for |x| I can't tell which one. Is that correct? I=E2=80=99m not sure I understand the question; maybe you mean > square-roots =3D {x: y} > y =3D float =E2=80=A6 for the second case? x is not an identifier then, but a bare word, which gets translated to > square-roots =3D {=E2=80=9Cx=E2=80=9D =3D> y} > y =3D float Am I on the right track understanding your question? > > S 3.5.3. > >> mynumber =3D int / float > >>=20 > >> 3.5.3. Non-deterministic order > >>=20 > >> While the way arrays are matched is fully determined by the = Parsing > >> Expression Grammar (PEG) algorithm, matching is more = complicated for > >=20 > > PEG is an informative reference, and this text seems to create a > > normative dependency. >=20 > Many of our specifications make use of theory in one form or another = without needing a normative dependency to a textbook. > RFC 5234 does not even have a reference for BNF. Since PEGs have been = a staple for parsing theory only for less than 15 years, we thought a = reference might be useful. >=20 > Then you need to rewrite this text, because here and below, it implies = that I need to read PEG in order to understand this specification.=20 That will be a bit more work than I can do today, so there will be a = separate e-mail when that is done. =20 > > S 3.6. > >> * tstr =3D> any > >> } > >>=20 > >> 3.6. Tags > >>=20 > >> A type can make use of a CBOR tag (major type 6) by using the > >=20 > > What happens if I define a type twice? Is that permitted? >=20 > Adam Roach also brought this up =E2=80=94 which led to 60c22df. >=20 > I=E2=80=99m surprised that you allow any redefinition or all. That turned up to be useful when we started to add often-used = definitions to the prelude =E2=80=94 old specs that contained those = definitions already just continued to work (while specs that conflicted = with those new prelude definitions got an error). While there is no plan to further expand the prelude, a process of = combining two specifications by naively concatenating them is still = helped by allowing identical redefinitions. > > S 3.7. > >> buuid =3D #6.37(bstr) > >>=20 > >> In the following example, usage of the tag 32 for URIs is = optional: > >>=20 > >> my_uri =3D #6.32(tstr) / tstr > >>=20 > >=20 > > I am basically unable to make sense of this section. Your previous > > example of tags used #7.25 but here you are specifying everything as > > using 6. >=20 > 6 is CBOR=E2=80=99s major type for tags. #7.25 is not a tag, but a = (16-bit) floating point value. >=20 > Yes, I understand that. >=20 >=20 > The example shows how to construct tagged items by using the = #6.xxx(ttt) syntax, where xxx is a tag value and ttt is the type of the = data item enclosed by the tag. >=20 > > It seems like the semantics here are something to the effect of: > >=20 > > X =3D #6.Y(Z) > >=20 > > means: act as if this were a thing of type Z but it=E2=80=99s tagged = by Y. That is not how I would describe what tags are about. E.g., using CBOR diagnostic notation, h=E2=80=99123456789a=E2=80=99 is a = byte string, but 2(h=E2=80=99123456789a=E2=80=99) is the number = 78187493520. This does no longer act as if it were a byte string. It is tagged by = the tag number 2 (which stands for unsigned bignum). A type for tagged data items like this is described in the prelude by: biguint =3D #6.2(bstr) > >=20 > > Is that correct? But then is this about the wire encoding or the > > interpretation or both? It is about the interpretation (data model), which of course influences = the wire encoding (but only as much as that is dictated by the data = model). > And in either case, what if what appears on > > the wire has a different tag. That would then not match #6.Y(Z). > Tags are visible at the CBOR data model level. > A tag with a different value than Y would not match #6.Y(Z), = independent of whether the enclosed data item maps Z. >=20 > I don't understand what this means. Can you please answer the specific = questions I asked above? I now tried harder. =20 > > S 3.8.2. > >> cwr: 15, > >> ns: 0, > >> ) / (4..7) ; data offset bits > >>=20 > >> rwxbits =3D uint .bits rwx > >> rwx =3D &(r: 2, w: 1, x: 0) > >=20 > > What is the scope of the definition for r, w, and x? is it global. >=20 > There is no scope =E2=80=94 everything is global. > (The only scopes are for the formal parameters of generics.) >=20 > So, r, w, and x are global? The answer is a bit more complicated, as =E2=80=9Cr=E2=80=9D, =E2=80=9Cw=E2= =80=9D, and =E2=80=9Cx=E2=80=9D are constants (text strings), due to the = way r: 2 =E2=80=A6is a shorthand for =E2=80=9Cr=E2=80=9D =3D> 2 > > S 3.9. > >> $$tcp-option //=3D ( > >> sack-permitted: true > >> ) > >>=20 > >> Names that start with a single "$" are "type sockets", names = with a > >> double "$$" are "group sockets". It is not an error if there = is no > >=20 > > what is the difference between these two? >=20 > Type sockets take additional types via /=3D. > Group sockets take alternative groups via //=3D. >=20 > Please add this to the text. Now in b2b2b3b. > > S 7.3. > >> order of the rules given. (It is not an error to extend a rule = name > >> that has not yet been defined; this makes the right hand side = the > >> first entry in the choice being created.) > >>=20 > >> genericparm =3D "<" S id S *("," S id S ) ">" > >> genericarg =3D "<" S type1 S *("," S type1 S ) ">" > >=20 > > What is the meaning of >=20 > I don=E2=80=99t know =E2=80=94 currently it is not allowed to have = type choices in a generic argument. > (Maybe I=E2=80=99m missing some context.) >=20 > No, I misread the ABNF for type a stype1. >=20 >=20 > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > >=20 > > S 1.2. > >> capitals, as shown here. > >>=20 > >> 1.2. Terminology > >>=20 > >> New terms are introduced in _cursive_. CDDL text in the = running text > >> is in "typewriter". > >=20 > > I think you mean that these types of text will be indicated by being > > bracketed by _ or ", but this isn't clear from this text. It's > > especially not clear when you then quote byte and octet. >=20 > XML2RFC currently uses quotes for indicating typewriter text. >=20 > Well, this just turns into quoted text in the text version of the RFC, = so it's > not typewriter text. If you're going to use syntactic conventions, you = need > to more clearly state them for the text version. Now in 98c2bd3 > > S 2. > >> There are a number of more or less atomic elements of a CBOR = data > >> model, such as numbers, simple values (false, true, nil), text = and > >> byte strings; CDDL does not focus on specifying their = structure. > >> CDDL of course also allows adding a CBOR tag to a data item. > >>=20 > >> The more important components of a data structure definition = language > >=20 > > More important than what? >=20 > Than the atomic elements (because these are mostly trivial to = specify). >=20 > Please add this to the text.=20 Well, maybe it=E2=80=99s not that important that they are more important = (which is subjective, anyway). Now in 0289e69 > > S 2.2.3. > >> in the prelude: > >>=20 > >> my_breakfast =3D #6.55799(breakfast) ; cbor-any is too = general! > >> breakfast =3D cereal / porridge > >> cereal =3D #6.998(tstr) > >> porridge =3D #6.999([liquid, solid]) > >=20 > > What is the parenthetical syntax here? >=20 > This is the syntax for specifying tags and the type for their enclosed = value. >=20 > I don't understand that. Please expand. Maybe I don=E2=80=99t understand what part you mean by parenthetical = syntax? The part in parentheses, i.e. the Y in #6.X(Y), is the data type of the = data item to be tagged. In these examples, the data types are breakfast tstr [liquid, solid] (an array with exactly two members, the first of type = liquid, the second of type solid). > > S 3.1. > >> according to the respective syntactic rules of that = definition. > >>=20 > >> o A name can consist of any of the characters from the set = {'A', > >> ..., 'Z', 'a', ..., 'z', '0', ..., '9', '_', '-', '@', '.', = '$'}, > >> starting with an alphabetic character (including '@', '_', = '$') > >> and ending in one or a digit. > >=20 > > This seems to say that names end in a digit, but none of your name > > examples do. >=20 > Clarified in 9a611bb >=20 > > S 3.2. > >> An optional _occurrence_ indicator can be given in front of a = group > >> entry. It is either one of the characters '?' (optional), '*' = (zero > >> or more), or '+' (one or more), or is of the form n*m, where n = and m > >> are optional unsigned integers and n is the lower limit = (default 0) > >> and m is the upper limit (default no limit) of occurrences. > >>=20 > >=20 > > isn=E2=80=99t bare * then just a degenerate case of n*m >=20 > Yes. > It is still useful to also show * besides ? and +. >=20 > Sure. I just meant that you might just explain n*m rather than * Right, the bare * is redundant, but we still like it to be in this list. Should we make the fact that * is just n*m more explicit? (We were assuming readers would recognize this from ABNF.) > > S 3.5.1. > >> written with quoted strings in the member key positions. More > >> generally, all the types defined can be used in a keytype = position by > >> following them with a double arrow -- in particular, the double = arrow > >> is necessary if a type is named by an identifier (which would = be > >> interpreted as a string before a colon). A string also is a = (single- > >> valued) type, so another form for this example is: > >=20 > > I'm sorry, I'm not following this. Can you give an example of when = you > > have to use =3D> >=20 > If you need to use a name for a type. With =E2=80=9C:=E2=80=9D, names = become bare words (strings without the =E2=80=9C=E2=80=A6=E2=80=9D = decoration). >=20 > OK, this isn=E2=80=99t clear, so maybe you can rewrite it. Now in 3ebf61d >=20 >=20 > > S 3.10. > >> message =3D {type: t, value: v} > >>=20 > >> When using a generic rule, the formal parameters are bound to = the > >> actual arguments supplied (also using angle brackets), within = the > >> scope of the generic rule (as if there were a rule of the form > >> parameter =3D argument). > >=20 > > This looks more like a macro than a generic. >=20 > It is not just lexical replacement, which is what =E2=80=9Cmacro=E2=80=9D= usually implies. >=20 > In what way is it not lexical replacement The arguments need to be well-formed, parseable as a type1, and they are = handed in as such to the rule. E.g., this does not work like lexical substitution would foo =3D { alice: parm } bar =3D foo< int =20 bob: float > does not give you bar =3D { alice: int bob: float } which could also be written bar =3D { alice: int, bob: float } > (Strictly speaking, it is comparable to a =E2=80=9Cmacro=E2=80=9D in = the Scheme tradition, but the way this concept is used in CDDL is now = better known as =E2=80=9Cgeneric type=E2=80=9D.) >=20 > > S 7.3. > >> definition with different member names); RFC 7071 could be read = to > >> forbid the repetition of ext-value ("A specific reputon-element = MUST > >> NOT appear more than once" is ambiguous.) > >>=20 > >> The CDDL tool (which hasn't quite been trained for polite > >> conversation) says: > >=20 > > It seems like it might be a good idea to clean up the examples here = so > > they are in fact polite. >=20 > We can do that if it is considered desirable. >=20 > Near-mandatory, I would think. I gave the tool another chance. (It still has a much larger vocabulary than I have, but the new result = sounds trigger-free to me.) Now in f107464 >=20 >=20 > > S 7.3. > >> "Thumbnail": {"Width": 1111, "Height": 176, "Url": = 32("scrog")}, > >> "IDs": []}} > >>=20 > >> Appendix B. ABNF grammar > >>=20 > >> The following is a formal definition of the CDDL syntax in = Augmented > >=20 > > It's pretty odd to have the formal specification -- which clearly is > > needed to understand and implement this document =E2=80=94 in an = appendix. >=20 > In -06, we have prefixed the normative appendices with >=20 > This appendix is normative. >=20 > (So many documents reference specific appendices of = draft-ietf-cbor-cddl that we tried to minimize confusion by minimizing = moving them around.) >=20 >=20 >=20 > > S 7.3. > >> type =3D type1 S *("/" S type1 S) > >>=20 > >> A type can be given as a choice between one or more types. The > >> choice matches a data item if the data item matches any one of = the > >> types given in the choice. The choice uses Parsing Expression > >> Grammar [PEG] semantics: The first choice that matches wins. = (As a > >=20 > > Is this the only information I need? >=20 > I think that is the essence; it certainly helps to be familiar with = PEG theory. >=20 > Then you should probably rewrite this text to make thatclear. I=E2=80=99ll put that into the PEG rewrite bin, for the next round. >=20 > -Ekr >=20 >=20 > > S 7.3. > >> control operators. > >>=20 > >> group =3D grpchoice S *("//" S grpchoice S) > >>=20 > >> A group matches any sequence of key/value pairs that matches = any of > >> the choices given (again using Parsing Expression Grammar = semantics). > >=20 > > This also seems not fully defined. >=20 > Similar. We did add Section 3.5.3 to provide more details for the = more complicated map matching case. >=20 > .oOo. From nobody Wed Nov 21 06:33:32 2018 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFF2128CE4; Wed, 21 Nov 2018 06:33:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-cbor-cddl@ietf.org, Barry Leiba , cbor-chairs@ietf.org, barryleiba@computer.org, cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154281081024.11490.7408989329662108022.idtracker@ietfa.amsl.com> Date: Wed, 21 Nov 2018 06:33:30 -0800 Archived-At: Subject: [Cbor] Suresh Krishnan's No Objection on draft-ietf-cbor-cddl-06: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 14:33:30 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-cbor-cddl-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 3.8.1 Looks like there is an off-by-one error here. Shouldn't BYTES_N == 256**N be BYTES_N == 256**N-1 instead? From nobody Wed Nov 21 12:34:25 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA19130DC7; Wed, 21 Nov 2018 12:34:23 -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, HTML_MESSAGE=0.001, 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 z7o3aQR1WjbU; Wed, 21 Nov 2018 12:34:20 -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 39B55130DC5; Wed, 21 Nov 2018 12:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wALKYAA6020505; Wed, 21 Nov 2018 21:34:16 +0100 (CET) Received: from [192.168.217.114] (p54A6CE66.dip0.t-ipconnect.de [84.166.206.102]) (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 430Z6p2fB4z1Bqf; Wed, 21 Nov 2018 21:34:10 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_1B87B330-3C11-437F-B247-017B090BA316" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <154281081024.11490.7408989329662108022.idtracker@ietfa.amsl.com> Date: Wed, 21 Nov 2018 21:34:09 +0100 Cc: The IESG , cbor@ietf.org, Barry Leiba , cbor-chairs@ietf.org, draft-ietf-cbor-cddl@ietf.org X-Mao-Original-Outgoing-Id: 564525244.8497601-b4bad3a9f548a6e2c0cb9b26856f5305 Message-Id: <1D4773AD-0BC0-4ADB-890A-D1BE74B7BD2D@tzi.org> References: <154281081024.11490.7408989329662108022.idtracker@ietfa.amsl.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Suresh Krishnan's No Objection on draft-ietf-cbor-cddl-06: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 20:34:23 -0000 --Apple-Mail=_1B87B330-3C11-437F-B247-017B090BA316 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Suresh, > On Nov 21, 2018, at 15:33, Suresh Krishnan > wrote: >=20 > Suresh Krishnan has entered the following ballot position for > draft-ietf-cbor-cddl-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ = >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > * Section 3.8.1 >=20 > Looks like there is an off-by-one error here. Shouldn't >=20 > BYTES_N =3D=3D 256**N >=20 > be >=20 > BYTES_N =3D=3D 256**N-1 That would be correct if the line said=20 =E2=80=9C0..BYTES_N=E2=80=9D, where BYTES_N =3D=3D 256**N-1. But it says: "0...BYTES_N=E2=80=9D, where BYTES_N =3D=3D 256**N. where =E2=80=9C=E2=80=A6=E2=80=9D is the half-closed range operator that = is closed on the left and open on the right, i.e., does not include the = upper bound in the interval (=E2=80=9C..=E2=80=9D is closed on both = sides and therefore does). Please see Section 2.2.2.1 about the two range operators =E2=80=9C..=E2=80= =9D and =E2=80=9C=E2=80=A6=E2=80=9D. (And, yes, I=E2=80=99m now aware that Swift uses =E2=80=9C...=E2=80=9D = for the closed and =E2=80=9C..<=E2=80=9C for the half-closed range = operator (originally the latter even was =E2=80=9C..=E2=80=9D, the other = way around from CDDL=E2=80=A6). Nice, but we nailed down those for CDDL = quite a while ago, based on the range operators in Ruby, which are in = turn somewhat, but not quite, based on those in Perl, which of course = were informed by subranges in Pascal, where =E2=80=9C..=E2=80=9D also is = a closed range. Maybe we can add =E2=80=9C..<=E2=80=9C for more visual = attention in CDDL 2.0, keeping =E2=80=9C...=E2=80=9D to also mean = half-closed.) Gr=C3=BC=C3=9Fe, Carsten PS.: Yes, I admit I constructed the example to induce attentive readers = to do a double-take, so they look up the two range operators again. =20 Apparently, it kind of almost worked :-)= --Apple-Mail=_1B87B330-3C11-437F-B247-017B090BA316 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Suresh,

On = Nov 21, 2018, at 15:33, Suresh Krishnan <suresh@kaloom.com> = wrote:

Suresh Krishnan has entered the = following ballot position for
draft-ietf-cbor-cddl-06: No = Objection

When responding, please keep the = subject line intact and reply to all
email addresses = included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

* Section 3.8.1

Looks like there is an off-by-one error here. Shouldn't

BYTES_N =3D=3D 256**N

be

BYTES_N =3D=3D = 256**N-1

That would be correct if the line = said 

  =  =E2=80=9C0..BYTES_N=E2=80=9D, where BYTES_N =3D=3D 256**N-1.

But it says:

 =  "0...BYTES_N=E2=80=9D, where BYTES_N =3D=3D 256**N.

where =E2=80=9C=E2=80=A6=E2=80=9D is = the half-closed range operator that is closed on the left and open on = the right, i.e., does not include the upper bound in the interval = (=E2=80=9C..=E2=80=9D is closed on both sides and therefore = does).
Please see Section 2.2.2.1 about the = two range operators =E2=80=9C..=E2=80=9D and =E2=80=9C=E2=80=A6=E2=80=9D.<= /div>

(And, = yes, I=E2=80=99m now aware that Swift uses =E2=80=9C...=E2=80=9D for the = closed and =E2=80=9C..<=E2=80=9C for the half-closed range operator = (originally the latter even was =E2=80=9C..=E2=80=9D, the other way = around from CDDL=E2=80=A6).  Nice, but we nailed down those for = CDDL quite a while ago, based on the range operators in Ruby, which are = in turn somewhat, but not quite, based on those in Perl, which of course = were informed by subranges in Pascal, where =E2=80=9C..=E2=80=9D also is = a closed range.  Maybe we can add =E2=80=9C..<=E2=80=9C for more = visual attention in CDDL 2.0, keeping =E2=80=9C...=E2=80=9D to also mean = half-closed.)

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

PS.: Yes, I admit I constructed the = example to induce attentive readers to do a double-take, so they look up = the two range operators again.  
Apparently, it kind of almost worked :-)
= --Apple-Mail=_1B87B330-3C11-437F-B247-017B090BA316-- From nobody Wed Nov 21 17:24:52 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF4D130E61; Wed, 21 Nov 2018 17:24:50 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEscPBr4Zrwp; Wed, 21 Nov 2018 17:24:49 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 987E9130DFF; Wed, 21 Nov 2018 17:24:48 -0800 (PST) X-AuditID: 1209190d-625ff70000004e3b-06-5bf6055e1be8 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id EF.EB.20027.E5506FB5; Wed, 21 Nov 2018 20:24:47 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.14.7/8.9.2) with ESMTP id wAM1OfcB028019; Wed, 21 Nov 2018 20:24:42 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAM1OYYI027860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Nov 2018 20:24:38 -0500 Date: Wed, 21 Nov 2018 19:24:34 -0600 From: Benjamin Kaduk To: Carsten Bormann Cc: Eric Rescorla , cbor@ietf.org, Barry Leiba , IESG , draft-ietf-cbor-cddl@ietf.org, cbor-chairs@ietf.org Message-ID: <20181122012434.GB11132@kduck.kaduk.org> References: <154267838656.26631.4178048052675609107.idtracker@ietfa.amsl.com> <6882FA6E-B656-4539-AB4D-CF9272B7A269@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6882FA6E-B656-4539-AB4D-CF9272B7A269@tzi.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsUixG6nohvP+i3aYOksdotDiy+xWhyZcpfV YvbfLYwWMzums1hcuzGNyWLF63PsFjP+TGR2YPdoWdXL7LFkyU8mj8mP25g9pi3KDGCJ4rJJ Sc3JLEst0rdL4Mq4/3Q/W8FhgYol5z8xNzBO5uli5OSQEDCROHTtAmMXIxeHkMAaJonXu85D ORsZJTYv38wO4dxlkji2bRo7SAuLgKrE3f43zCA2m4CKREP3ZTBbREBJ4sLFNWwgDcwCmxkl Dv7pBWsQFoiVWH1qJiOIzQu0727HbagV3xglPry6zwyREJQ4OfMJC4jNLKAu8WfeJaA4B5At LbH8HwdEWF6ieetssHJOAWuJN51NbCC2qICyxN6+Q+wTGAVnIZk0C8mkWQiTZiGZtICRZRWj bEpulW5uYmZOcWqybnFyYl5eapGukV5uZoleakrpJkZQfHBK8u5g/HfX6xCjAAejEg+vRuTX aCHWxLLiytxDjJIcTEqivGzZQCG+pPyUyozE4oz4otKc1OJDjBIczEoivBdWAOV4UxIrq1KL 8mFS0hwsSuK8v0UeRwsJpCeWpGanphakFsFkZTg4lCR43Vm+RQsJFqWmp1akZeaUIKSZODhB hvMADRcHqeEtLkjMLc5Mh8ifYlSUEuetB0kIgCQySvPgekHpSyJ7f80rRnGgV4R5DUGqeICp D677FdBgJqDBsmc+gwwuSURISTUwBq/S+cqovuz0IQbD5EifB5UxGVdqWdvmFyz6K7/x/yuf 7Mldc76v2ucnkWanpLdP3vnPwYdyh5x+cyVsWl7JmrRmqt21+gtPrCZfeN2yJan37I6s4mp7 00Oady/YH555R5ZR8ceRb7xaPw+kXVr3Q75tZ6Df738PQ37t0Ehw/PHtZvGOTbdYbJRYijMS DbWYi4oTAd4GgKU6AwAA Archived-At: Subject: Re: [Cbor] Eric Rescorla's Discuss on draft-ietf-cbor-cddl-06: (with DISCUSS and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 01:24:51 -0000 On Wed, Nov 21, 2018 at 02:10:24PM +0100, Carsten Bormann wrote: > Hi Eric, > > you probably won’t have time to read this before the telechat, but I would like to keep the ball rolling. Jumping in on one specific point... > (For some reason, my mail reader doesn’t pick up the quoting correctly in this reply; I hope it is still readable enough.) > > Grüße, Carsten > > > > On Nov 20, 2018, at 20:15, Eric Rescorla wrote: > > > > On Tue, Nov 20, 2018 at 8:14 AM Carsten Bormann wrote: > > > > > On Nov 20, 2018, at 02:46, Eric Rescorla wrote: > > > [...] > > > S 3.7. > > >> buuid = #6.37(bstr) > > >> > > >> In the following example, usage of the tag 32 for URIs is optional: > > >> > > >> my_uri = #6.32(tstr) / tstr > > >> > > > > > > I am basically unable to make sense of this section. Your previous > > > example of tags used #7.25 but here you are specifying everything as > > > using 6. > > > > 6 is CBOR’s major type for tags. #7.25 is not a tag, but a (16-bit) floating point value. > > > > Yes, I understand that. > > > > > > The example shows how to construct tagged items by using the #6.xxx(ttt) syntax, where xxx is a tag value and ttt is the type of the data item enclosed by the tag. > > > > > It seems like the semantics here are something to the effect of: > > > > > > X = #6.Y(Z) > > > > > > means: act as if this were a thing of type Z but it’s tagged by Y. > > That is not how I would describe what tags are about. > > E.g., using CBOR diagnostic notation, h’123456789a’ is a byte string, but 2(h’123456789a’) is the number 78187493520. > This does no longer act as if it were a byte string. It is tagged by the tag number 2 (which stands for unsigned bignum). > > A type for tagged data items like this is described in the prelude by: > > biguint = #6.2(bstr) I'm still a bit confused on where the #M.N(x) syntax is formally defined. Is it supposed to be part of CDDL's ABNF? -Benjamin From nobody Wed Nov 21 17:37:11 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571E9130E90; Wed, 21 Nov 2018 17:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 OJzVhS4ALOSM; Wed, 21 Nov 2018 17:37:06 -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 21EF1130E9B; Wed, 21 Nov 2018 17:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wAM1ap57003721; Thu, 22 Nov 2018 02:36:56 +0100 (CET) Received: from [192.168.217.114] (p54A6CE66.dip0.t-ipconnect.de [84.166.206.102]) (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 430hr303JPz1Bqf; Thu, 22 Nov 2018 02:36:50 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20181122012434.GB11132@kduck.kaduk.org> Date: Thu, 22 Nov 2018 02:36:50 +0100 Cc: Eric Rescorla , cbor@ietf.org, Barry Leiba , IESG , draft-ietf-cbor-cddl@ietf.org, cbor-chairs@ietf.org X-Mao-Original-Outgoing-Id: 564543406.416725-14c278dc311c2cdf1817e67bb90af868 Content-Transfer-Encoding: quoted-printable Message-Id: <8B6ECC91-D56F-4DA5-BC8D-7F51D3E677CB@tzi.org> References: <154267838656.26631.4178048052675609107.idtracker@ietfa.amsl.com> <6882FA6E-B656-4539-AB4D-CF9272B7A269@tzi.org> <20181122012434.GB11132@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Eric Rescorla's Discuss on draft-ietf-cbor-cddl-06: (with DISCUSS and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 01:37:10 -0000 On Nov 22, 2018, at 02:24, Benjamin Kaduk wrote: >=20 > [=E2=80=A6] > Jumping in on one specific point... >=20 > [=E2=80=A6] > I'm still a bit confused on where the #M.N(x) syntax is formally = defined. > Is it supposed to be part of CDDL=E2=80=99s ABNF? Yes, it is right here in appendix B: type2 =3D [,,,] / "#" "6" ["." uint] "(" S type S ")" / "#" DIGIT ["." uint] ; major/ai / "#" ; any (=E2=80=A6and quoting the matching rules from appendix C): / "#" "6" ["." uint] "(" S type S ")" a tagged data item, tagged with the "uint" given and containing the type given as the tagged value, or / "#" DIGIT ["." uint] ; major/ai a data item of a major type (given by the DIGIT), optionally constrained to the additional information given by the uint, or / "#" ; any any data item. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Nov 21 19:53:32 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C36130F84 for ; Wed, 21 Nov 2018 19:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.958 X-Spam-Level: X-Spam-Status: No, score=-10.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 eUnLC3Tss3Ac for ; Wed, 21 Nov 2018 19:53:22 -0800 (PST) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 70E58130F7C for ; Wed, 21 Nov 2018 19:53:19 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id g192-v6so3086724ybf.3 for ; Wed, 21 Nov 2018 19:53:19 -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=vS9RJg9E70k5fNwZXKSYrociXcEtRWMsvRg3yjh85tk=; b=gI7UQMXjPEyYE01T4isNvoPpdJxjcAyIH1M9CEFtYfOySVm763vzH+l1mrbfh7Dt3u q5GUirAVFVjlfZy3unpRNExwVTyWLVb+Wl0b/344Ckc6Jlbyx//oh+UbSSOWH3Kjm3ni 6blPf6miwbL8WYV/oW0ttKqhIM2ok3Tn0p8TI= 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=vS9RJg9E70k5fNwZXKSYrociXcEtRWMsvRg3yjh85tk=; b=QhkRZqymD94HOr4X+uwFXnaTdQht+elafErbGe5JmBxW1j3HVbe0w63lRYAD6OXjDQ f9SVtrIzv/G23lJQ3O3kiBiPeN0YSvxONC/uqw8puZZWgZZ7CEY0jj/RirJGJpjDOdRZ NOvNkHSTShz1xXkMDpR+u97tWUeY8GeTZ4DViAJEnmVipEVQMNSW+JOzEEKzhlXF1D3J AVU6ZsPqqgZcsyexU32sd/IuppSorlQ7KLLW9bqUZ9vB81TfLM+DnLENwziYsmgOqXGE 5M8xIFr+rxroVSJ/r80qxc69cu7hosXlQuWlT743VrQbaFzb0eL1AiqhMV3wl5f08pK/ s5pw== X-Gm-Message-State: AA+aEWYF772SQJqTA3CCBadx+SwMIXUbnGj3NJibNhtMCPLXqybrC3h1 keG1v+F8sziGdk87kFiUDqgGX2uZhAK4c1J4If7LWw== X-Google-Smtp-Source: AFSGD/WEASLfnHYNLKPAs1bePqs/aGhnDQaTYtBu29KgPgzkkP2+TlSHxX4n7Fw1nUundiGBI86Mk9X6Y7F9e6qkT/Q= X-Received: by 2002:a25:b4f:: with SMTP id 76-v6mr9163965ybl.50.1542858798216; Wed, 21 Nov 2018 19:53:18 -0800 (PST) MIME-Version: 1.0 References: <154267838656.26631.4178048052675609107.idtracker@ietfa.amsl.com> <6882FA6E-B656-4539-AB4D-CF9272B7A269@tzi.org> <20181122012434.GB11132@kduck.kaduk.org> <8B6ECC91-D56F-4DA5-BC8D-7F51D3E677CB@tzi.org> In-Reply-To: <8B6ECC91-D56F-4DA5-BC8D-7F51D3E677CB@tzi.org> From: Jeffrey Yasskin Date: Wed, 21 Nov 2018 19:53:06 -0800 Message-ID: To: Carsten Bormann Cc: kaduk@mit.edu, Eric Rescorla , cbor@ietf.org, iesg@ietf.org, barryleiba@computer.org, cbor-chairs@ietf.org, draft-ietf-cbor-cddl@ietf.org Content-Type: multipart/alternative; boundary="0000000000009ba809057b38ce06" Archived-At: Subject: Re: [Cbor] Eric Rescorla's Discuss on draft-ietf-cbor-cddl-06: (with DISCUSS and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 03:53:24 -0000 --0000000000009ba809057b38ce06 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 21, 2018 at 5:37 PM Carsten Bormann wrote: > On Nov 22, 2018, at 02:24, Benjamin Kaduk wrote: > > > > [=E2=80=A6] > > Jumping in on one specific point... > > > > [=E2=80=A6] > > I'm still a bit confused on where the #M.N(x) syntax is formally define= d. > > Is it supposed to be part of CDDL=E2=80=99s ABNF? > > Yes, it is right here in appendix B: > > type2 =3D [,,,] > / "#" "6" ["." uint] "(" S type S ")" > / "#" DIGIT ["." uint] ; major/ai > / "#" ; any > > > (=E2=80=A6and quoting the matching rules from appendix C): > > / "#" "6" ["." uint] "(" S type S ")" > > a tagged data item, tagged with the "uint" given and containing the > type given as the tagged value, or > > / "#" DIGIT ["." uint] ; major/ai > > > a data item of a major type (given by the DIGIT), optionally > constrained to the additional information given by the uint, or > > / "#" ; any > > any data item. > > This is one reason I've pushed to move the Appendix C rules into the body of the RFC (and possibly the tutorial that makes up most of the body into an appendix): folks don't realize they need to look in two places to get the full definition of CDDL rules. Jeffrey --0000000000009ba809057b38ce06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 21= , 2018 at 5:37 PM Carsten Bormann <cabo@= tzi.org> wrote:
On Nov 22, 2018, at 02:24, Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> [=E2=80=A6]
> Jumping in on one specific point...
>
> [=E2=80=A6]
> I'm still a bit confused on where the #M.N(x) syntax is formally d= efined.
> Is it supposed to be part of CDDL=E2=80=99s ABNF?

Yes, it is right here in appendix B:

=C2=A0 =C2=A0 =C2=A0type2 =3D [,,,]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ "#" "6" [&qu= ot;." uint] "(" S type S ")"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ "#" DIGIT [".&quo= t; uint]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; major/ai<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ "#"=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0; any


(=E2=80=A6and quoting the matching rules from appendix C):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ "#" "6" [".&qu= ot; uint] "(" S type S ")"

=C2=A0 =C2=A0a tagged data item, tagged with the "uint" given and= containing the
=C2=A0 =C2=A0type given as the tagged value, or

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ "#" DIGIT ["." uint= ]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; major/ai


=C2=A0 =C2=A0a data item of a major type (given by the DIGIT), optionally =C2=A0 =C2=A0constrained to the additional information given by the uint, o= r

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ "#"=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0; any

=C2=A0 =C2=A0any data item.


This is one reason I've pushed to = move the Appendix C rules into the body of the RFC (and possibly the tutori= al that makes up most of the body into an appendix): folks don't realiz= e they need to look in two places to get the full definition of CDDL rules.=

Jeffrey=C2=A0
--0000000000009ba809057b38ce06-- From nobody Wed Nov 21 20:56:49 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A59130FD9; Wed, 21 Nov 2018 20:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.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 L1MOApg96zFb; Wed, 21 Nov 2018 20:56:44 -0800 (PST) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670137.outbound.protection.outlook.com [40.107.67.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35BD130DE4; Wed, 21 Nov 2018 20:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ppYL4f2ucQwGE/UK3rbA/OfgWv135R/39QkpzhDZbcY=; b=nXv5T2CqmlkwgorHz6JWWGuUFG+F96XksxF82iy0Zea7yvfJskss45Q+1D445x8x+I6uZEG+FOktPRqaXQeIwk9oRpuOpdpnkXt2PGuITv9+x16ZYs6Z/TiGTUy5Isdt1iEprx+qTHNunTq9OnGLt5J4je+ZmkJ3Un8clWB8OFg= Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM (52.132.44.159) by YTOPR0101MB2314.CANPRD01.PROD.OUTLOOK.COM (52.132.51.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.26; Thu, 22 Nov 2018 04:56:42 +0000 Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::5cb8:6da5:fffa:d207]) by YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::5cb8:6da5:fffa:d207%3]) with mapi id 15.20.1294.048; Thu, 22 Nov 2018 04:56:41 +0000 From: Suresh Krishnan To: Carsten Bormann CC: The IESG , "cbor@ietf.org" , Barry Leiba , "cbor-chairs@ietf.org" , "draft-ietf-cbor-cddl@ietf.org" Thread-Topic: [Cbor] Suresh Krishnan's No Objection on draft-ietf-cbor-cddl-06: (with COMMENT) Thread-Index: AQHUgdmYtwZ0KIvfY0Kq+tn7BRrez6VbO86A Date: Thu, 22 Nov 2018 04:56:41 +0000 Message-ID: <9C4CA15B-8E19-4DA9-8B1F-3206A1922B9E@kaloom.com> References: <154281081024.11490.7408989329662108022.idtracker@ietfa.amsl.com> <1D4773AD-0BC0-4ADB-890A-D1BE74B7BD2D@tzi.org> In-Reply-To: <1D4773AD-0BC0-4ADB-890A-D1BE74B7BD2D@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com; x-originating-ip: [45.19.110.76] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB2314; 6:w6wRGRfJUyyUbaQG4qe+e3nYlwaNES0OULVw5524s39pqPdX8CGRJTGNifL8UcPZkUm9HRUeldr+R52CMbpz9syiaLiLXC+dcgzec6z7mEdyGhncxz/YK6Rszzh81dfMMOY0NuXdT7xdlmDwnLl+85U7TNEoml2npnvKIWX2n5oXG3SGz7TkhlCtVYwyOPQ6QdLic7GyCbOYVZYR/QBndx2Sb/Iz7W1zC4N/P9Tq7CxfYRUZ9zc+5kyRDn15o2tFItYaCEZ7gqGA+Hq4UnXBvvtXwwGmYsPKV/u8sTemsB10ZtQD+mJzu6lmUuiqPVtAGDC0fV7sgsX8ROqaUQfBF70zWzBG8pS31s5OUWU6HZAqraj2Gtrbk/xjY5bqGQOujqyddiJbHUZlGkT2MXGvRF4+/QFJP58ecvOuWip0N8fVQpfMaF5uRCeWJhg6Dgz7ntFyq4YIRf3EDtNWB5X8/Q==; 5:qQv7i/LodiMkALzVqStKA6GaQYBtF9cIdbLMs/jVZxJmfQWuDpQPdi+LBS4A2GyHrwmcKR+vi5POEA8sOgFjTG7+Po08hmHdIFJdxCnNqt1aHuPxzB/0iuEUQ2kMQGUU0iTkmrX53ZAyM5ZhRKRxyUapRM5LGnxIWzqYpRa2JzY=; 7:ZSWfTr0WrG6zpuGSAeb6VCU0tdWKT9y/pXKh7LtfKgUO+xfe3NVqZNWWOtPB2PtOlgMbeSQtuGvoFdWxnvO0UU05on0sQggwdkKo/5F2qufGC0wBhjKy0rQ95N7/yjT8mccXERMWSeo67rRSulL3gw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: abdc3074-dc6e-4d3c-cc28-08d65036e4f8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB2314; x-ms-traffictypediagnostic: YTOPR0101MB2314: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231442)(944501410)(52105112)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(2016111802025)(6043046)(201708071742011)(7699051)(76991095); SRVR:YTOPR0101MB2314; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB2314; x-forefront-prvs: 0864A36BBF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39840400004)(136003)(366004)(376002)(346002)(189003)(199004)(51914003)(68736007)(2906002)(66066001)(97736004)(14454004)(508600001)(6486002)(4326008)(76176011)(26005)(5660300001)(7736002)(6436002)(25786009)(36756003)(2616005)(11346002)(476003)(2900100001)(33656002)(21615005)(186003)(72206003)(82746002)(8936002)(53936002)(236005)(54906003)(6512007)(86362001)(606006)(81166006)(316002)(81156014)(54896002)(3846002)(6116002)(8676002)(256004)(6306002)(966005)(486006)(106356001)(53546011)(102836004)(6506007)(80792005)(229853002)(105586002)(446003)(99286004)(6246003)(71190400001)(71200400001)(83716004)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:YTOPR0101MB2314; H:YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: cfK9rSGLWDtUk4GoZFaWCHKC4dLPW4p9XOZN4ysx08FQpLLRmckmDE7pDhot/GOQlKNLpqc8ThABkq+O3qsR4lR2bjo1jrh091uAh0IhR7SW8i3346YB6DP66KX3LdG3sp3iVemf7WfHrlcoaE2AUKodDQfKW0ovmfS15K0QCm8UkS+zKLo+iG1Upokw1IrGVp+VM/RXFg5JjU6ZxMbKlf93xmRsHdZQmvob9tnMM1rLGSixunUFlGDOj1G09ybVYi8C9H8PyKty7fuRzmJyUAIFiafncnfDzUj6ocgZC/xO6fE+1BlG9Cegg8kHLhKxltH3MUvoXab2rhKAnrMW2hbU74N5I0/HKz9+Hh8Fvog= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_9C4CA15B8E194DA98B1F3206A1922B9Ekaloomcom_" MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: abdc3074-dc6e-4d3c-cc28-08d65036e4f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2018 04:56:41.8129 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2314 Archived-At: Subject: Re: [Cbor] Suresh Krishnan's No Objection on draft-ietf-cbor-cddl-06: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 04:56:47 -0000 --_000_9C4CA15B8E194DA98B1F3206A1922B9Ekaloomcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIE5vdiAyMSwgMjAxOCwgYXQgMzozNCBQTSwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6 aS5vcmc8bWFpbHRvOmNhYm9AdHppLm9yZz4+IHdyb3RlOg0KDQpIaSBTdXJlc2gsDQoNCk9uIE5v diAyMSwgMjAxOCwgYXQgMTU6MzMsIFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNoQGthbG9vbS5jb208 bWFpbHRvOnN1cmVzaEBrYWxvb20uY29tPj4gd3JvdGU6DQoNClN1cmVzaCBLcmlzaG5hbiBoYXMg ZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtY2Jv ci1jZGRsLTA2OiBObyBPYmplY3Rpb24NCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0 aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQplbWFpbCBhZGRyZXNzZXMg aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0K aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0 dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0K Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0 aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9u cywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWNib3ItY2RkbC8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCiogU2VjdGlvbiAzLjguMQ0KDQpMb29rcyBsaWtlIHRoZXJlIGlzIGFuIG9m Zi1ieS1vbmUgZXJyb3IgaGVyZS4gU2hvdWxkbid0DQoNCkJZVEVTX04gPT0gMjU2KipODQoNCmJl DQoNCkJZVEVTX04gPT0gMjU2KipOLTENCg0KVGhhdCB3b3VsZCBiZSBjb3JyZWN0IGlmIHRoZSBs aW5lIHNhaWQNCg0KICAg4oCcMC4uQllURVNfTuKAnSwgd2hlcmUgQllURVNfTiA9PSAyNTYqKk4t MS4NCg0KQnV0IGl0IHNheXM6DQoNCiAgICIwLi4uQllURVNfTuKAnSwgd2hlcmUgQllURVNfTiA9 PSAyNTYqKk4uDQoNCndoZXJlIOKAnOKApuKAnSBpcyB0aGUgaGFsZi1jbG9zZWQgcmFuZ2Ugb3Bl cmF0b3IgdGhhdCBpcyBjbG9zZWQgb24gdGhlIGxlZnQgYW5kIG9wZW4gb24gdGhlIHJpZ2h0LCBp LmUuLCBkb2VzIG5vdCBpbmNsdWRlIHRoZSB1cHBlciBib3VuZCBpbiB0aGUgaW50ZXJ2YWwgKOKA nC4u4oCdIGlzIGNsb3NlZCBvbiBib3RoIHNpZGVzIGFuZCB0aGVyZWZvcmUgZG9lcykuDQpQbGVh c2Ugc2VlIFNlY3Rpb24gMi4yLjIuMSBhYm91dCB0aGUgdHdvIHJhbmdlIG9wZXJhdG9ycyDigJwu LuKAnSBhbmQg4oCc4oCm4oCdLg0KDQooQW5kLCB5ZXMsIEnigJltIG5vdyBhd2FyZSB0aGF0IFN3 aWZ0IHVzZXMg4oCcLi4u4oCdIGZvciB0aGUgY2xvc2VkIGFuZCDigJwuLjzigJwgZm9yIHRoZSBo YWxmLWNsb3NlZCByYW5nZSBvcGVyYXRvciAob3JpZ2luYWxseSB0aGUgbGF0dGVyIGV2ZW4gd2Fz IOKAnC4u4oCdLCB0aGUgb3RoZXIgd2F5IGFyb3VuZCBmcm9tIENEREzigKYpLiAgTmljZSwgYnV0 IHdlIG5haWxlZCBkb3duIHRob3NlIGZvciBDRERMIHF1aXRlIGEgd2hpbGUgYWdvLCBiYXNlZCBv biB0aGUgcmFuZ2Ugb3BlcmF0b3JzIGluIFJ1YnksIHdoaWNoIGFyZSBpbiB0dXJuIHNvbWV3aGF0 LCBidXQgbm90IHF1aXRlLCBiYXNlZCBvbiB0aG9zZSBpbiBQZXJsLCB3aGljaCBvZiBjb3Vyc2Ug d2VyZSBpbmZvcm1lZCBieSBzdWJyYW5nZXMgaW4gUGFzY2FsLCB3aGVyZSDigJwuLuKAnSBhbHNv IGlzIGEgY2xvc2VkIHJhbmdlLiAgTWF5YmUgd2UgY2FuIGFkZCDigJwuLjzigJwgZm9yIG1vcmUg dmlzdWFsIGF0dGVudGlvbiBpbiBDRERMIDIuMCwga2VlcGluZyDigJwuLi7igJ0gdG8gYWxzbyBt ZWFuIGhhbGYtY2xvc2VkLikNCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQpQUy46IFllcywgSSBhZG1p dCBJIGNvbnN0cnVjdGVkIHRoZSBleGFtcGxlIHRvIGluZHVjZSBhdHRlbnRpdmUgcmVhZGVycyB0 byBkbyBhIGRvdWJsZS10YWtlLCBzbyB0aGV5IGxvb2sgdXAgdGhlIHR3byByYW5nZSBvcGVyYXRv cnMgYWdhaW4uDQpBcHBhcmVudGx5LCBpdCBraW5kIG9mIGFsbW9zdCB3b3JrZWQgOi0pDQoNCkhh aGEuIFRvdWNow6kuIEFncmVlIHRoYXQgYSBtb3JlIGRpc3RpbmN0IHZpc3VhbCBjYWxsb3V0IHdv dWxkIGJlIGhlbHBmdWwgaW4gdGhlIGZ1dHVyZS4gVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlv bi4NCg0KUmVnYXJkcw0KU3VyZXNoDQoNCg== --_000_9C4CA15B8E194DA98B1F3206A1922B9Ekaloomcom_ Content-Type: text/html; charset="utf-8" Content-ID: <185DAE42362B4D4E8ACB00BC98DAB5E9@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IE5vdiAyMSwgMjAxOCwgYXQgMzozNCBQTSwgQ2Fyc3RlbiBCb3JtYW5uICZsdDs8YSBocmVmPSJt YWlsdG86Y2Fib0B0emkub3JnIiBjbGFzcz0iIj5jYWJvQHR6aS5vcmc8L2E+Jmd0OyB3cm90ZTo8 L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNz PSIiPjxzcGFuIGNsYXNzPSIiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyBmb250LWZhbWlseTogTWVubG8tUmVndWxhcjsgZm9udC1zaXplOiAxM3B4 OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7Ij5IaQ0KIFN1cmVzaCw8 L3NwYW4+PGJyIGNsYXNzPSIiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyBmb250LWZhbWlseTogTWVubG8tUmVndWxhcjsgZm9udC1zaXplOiAxM3B4 OyI+DQo8YnIgY2xhc3M9IiIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IGZvbnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDEzcHg7 Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiIHN0eWxlPSJmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTNweDsiPg0K T24gTm92IDIxLCAyMDE4LCBhdCAxNTozMywgU3VyZXNoIEtyaXNobmFuICZsdDs8YSBocmVmPSJt YWlsdG86c3VyZXNoQGthbG9vbS5jb20iIGNsYXNzPSIiPnN1cmVzaEBrYWxvb20uY29tPC9hPiZn dDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU3VyZXNoIEtyaXNobmFuIGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcjxiciBjbGFzcz0iIj4N CmRyYWZ0LWlldGYtY2Jvci1jZGRsLTA2OiBObyBPYmplY3Rpb248YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUg aW50YWN0IGFuZCByZXBseSB0byBhbGw8YnIgY2xhc3M9IiI+DQplbWFpbCBhZGRyZXNzZXMgaW5j bHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpczxiciBj bGFzcz0iIj4NCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKTxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClBsZWFzZSByZWZlciB0bzxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwiIGNsYXNzPSIi Pmh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRt bDwvYT48YnIgY2xhc3M9IiI+DQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NV U1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRp b25zLCBjYW4gYmUgZm91bmQgaGVyZTo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNib3ItY2RkbC8iIGNsYXNzPSIiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2Jvci1jZGRsLzwvYT48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyIGNsYXNzPSIiPg0KQ09NTUVOVDo8YnIgY2xhc3M9IiI+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKiBTZWN0aW9uIDMuOC4xPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTG9va3MgbGlrZSB0aGVyZSBpcyBhbiBvZmYtYnkt b25lIGVycm9yIGhlcmUuIFNob3VsZG4ndDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJZ VEVTX04gPT0gMjU2KipOPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KYmU8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpCWVRFU19OID09IDI1NioqTi0xPC9ibG9ja3F1b3RlPg0KPGRp diBjbGFzcz0iIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTNweDsiPg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8c3BhbiBjbGFzcz0iIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXI7 IGZvbnQtc2l6ZTogMTNweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyI+VGhhdA0KIHdvdWxkIGJlIGNvcnJlY3QgaWYgdGhlIGxpbmUgc2FpZCZuYnNwOzwvc3Bhbj4N CjxkaXYgY2xhc3M9IiIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp b246IG5vbmU7IGZvbnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDEzcHg7Ij4N CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0iY2FyZXQtY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3Vs YXI7IGZvbnQtc2l6ZTogMTNweDsiPg0KJm5ic3A7ICZuYnNwO+KAnDAuLkJZVEVTX07igJ0sIHdo ZXJlIEJZVEVTX04gPT0gMjU2KipOLTEuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQnV0 IGl0IHNheXM6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyZxdW90 OzAuLi5CWVRFU19O4oCdLCB3aGVyZSBCWVRFU19OID09IDI1NioqTi48L2Rpdj4NCjxkaXYgY2xh c3M9IiIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 IGZvbnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDEzcHg7Ij4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXI7IGZvbnQt c2l6ZTogMTNweDsiPg0Kd2hlcmUg4oCc4oCm4oCdIGlzIHRoZSBoYWxmLWNsb3NlZCByYW5nZSBv cGVyYXRvciB0aGF0IGlzIGNsb3NlZCBvbiB0aGUgbGVmdCBhbmQgb3BlbiBvbiB0aGUgcmlnaHQs IGkuZS4sIGRvZXMgbm90IGluY2x1ZGUgdGhlIHVwcGVyIGJvdW5kIGluIHRoZSBpbnRlcnZhbCAo 4oCcLi7igJ0gaXMgY2xvc2VkIG9uIGJvdGggc2lkZXMgYW5kIHRoZXJlZm9yZSBkb2VzKS48L2Rp dj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IGZvbnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDEzcHg7 Ij4NClBsZWFzZSBzZWUgU2VjdGlvbiAyLjIuMi4xIGFib3V0IHRoZSB0d28gcmFuZ2Ugb3BlcmF0 b3JzIOKAnC4u4oCdIGFuZCDigJzigKbigJ0uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmb250LWZhbWlseTog TWVubG8tUmVndWxhcjsgZm9udC1zaXplOiAxM3B4OyI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp b246IG5vbmU7IGZvbnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDEzcHg7Ij4N CihBbmQsIHllcywgSeKAmW0gbm93IGF3YXJlIHRoYXQgU3dpZnQgdXNlcyDigJwuLi7igJ0gZm9y IHRoZSBjbG9zZWQgYW5kIOKAnC4uJmx0O+KAnCBmb3IgdGhlIGhhbGYtY2xvc2VkIHJhbmdlIG9w ZXJhdG9yIChvcmlnaW5hbGx5IHRoZSBsYXR0ZXIgZXZlbiB3YXMg4oCcLi7igJ0sIHRoZSBvdGhl ciB3YXkgYXJvdW5kIGZyb20gQ0RETOKApikuICZuYnNwO05pY2UsIGJ1dCB3ZSBuYWlsZWQgZG93 biB0aG9zZSBmb3IgQ0RETCBxdWl0ZSBhIHdoaWxlIGFnbywgYmFzZWQgb24gdGhlIHJhbmdlDQog b3BlcmF0b3JzIGluIFJ1YnksIHdoaWNoIGFyZSBpbiB0dXJuIHNvbWV3aGF0LCBidXQgbm90IHF1 aXRlLCBiYXNlZCBvbiB0aG9zZSBpbiBQZXJsLCB3aGljaCBvZiBjb3Vyc2Ugd2VyZSBpbmZvcm1l ZCBieSBzdWJyYW5nZXMgaW4gUGFzY2FsLCB3aGVyZSDigJwuLuKAnSBhbHNvIGlzIGEgY2xvc2Vk IHJhbmdlLiAmbmJzcDtNYXliZSB3ZSBjYW4gYWRkIOKAnC4uJmx0O+KAnCBmb3IgbW9yZSB2aXN1 YWwgYXR0ZW50aW9uIGluIENEREwgMi4wLCBrZWVwaW5nIOKAnC4uLuKAnSB0byBhbHNvDQogbWVh biBoYWxmLWNsb3NlZC4pPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmb250LWZhbWlseTogTWVubG8tUmVndWxh cjsgZm9udC1zaXplOiAxM3B4OyI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZv bnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDEzcHg7Ij4NCkdyw7zDn2UsIENh cnN0ZW48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiIg c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZvbnQt ZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDEzcHg7Ij4NClBTLjogWWVzLCBJIGFk bWl0IEkgY29uc3RydWN0ZWQgdGhlIGV4YW1wbGUgdG8gaW5kdWNlIGF0dGVudGl2ZSByZWFkZXJz IHRvIGRvIGEgZG91YmxlLXRha2UsIHNvIHRoZXkgbG9vayB1cCB0aGUgdHdvIHJhbmdlIG9wZXJh dG9ycyBhZ2Fpbi4gJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmb250LWZhbWlseTogTWVubG8tUmVn dWxhcjsgZm9udC1zaXplOiAxM3B4OyI+DQpBcHBhcmVudGx5LCBpdCBraW5kIG9mIGFsbW9zdCB3 b3JrZWQgOi0pPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdj5IYWhhLiBUb3VjaMOpLiBBZ3JlZSB0aGF0IGEgbW9yZSBkaXN0aW5jdCB2aXN1 YWwgY2FsbG91dCB3b3VsZCBiZSBoZWxwZnVsIGluIHRoZSBmdXR1cmUuIFRoYW5rcyBmb3IgdGhl IGNsYXJpZmljYXRpb24uPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5S ZWdhcmRzPC9kaXY+DQo8ZGl2PlN1cmVzaDwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_9C4CA15B8E194DA98B1F3206A1922B9Ekaloomcom_-- From nobody Thu Nov 22 05:02:52 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843A9129AB8 for ; Thu, 22 Nov 2018 05:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.759 X-Spam-Level: X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=WqRwAi1B; dkim=pass (1024-bit key) header.d=ericsson.com header.b=XnbjTNxE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLl-9_MTYUFj for ; Thu, 22 Nov 2018 05:02:47 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 C92E31271FF for ; Thu, 22 Nov 2018 05:02:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1542891765; x=1545483765; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mMKJp/Ma0klWn5g5tx4Pyw0kHVK4djxwIMWC8K5XW94=; b=WqRwAi1BeoaBTZLlVgXVEMgAZhSk9T8CVvcfNl22Qoy+r87rYYHEkWOneo8xoVBb dGYRYxPP3Y5u5lg0YIRXazZMCYTawyrf0BK3DwXkYYnHZg/ff7OVyMYfu/KMuu0U 6QTwm0WaFyuRngn0ywZW5D7uawn+wESDoQGUDn4h/6o=; X-AuditID: c1b4fb30-f15ff700000043c4-63-5bf6a8f5819a Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 67.A6.17348.5F8A6FB5; Thu, 22 Nov 2018 14:02:45 +0100 (CET) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 22 Nov 2018 14:02:44 +0100 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 22 Nov 2018 14:02:44 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mMKJp/Ma0klWn5g5tx4Pyw0kHVK4djxwIMWC8K5XW94=; b=XnbjTNxEA704/WSGWkLKYVWu14Ru/ZOEqmmTuDlx4PjjYO0PeXRCVLd5DcclXodHi//xOwaW4XpSwo8glSIpQJsryljffF0Yrybbshv9Yyp3rbbxR1LJ+Atv3PqdZlfxvf3Ss3SoXCdeCTqLyiCN+ZUubcuJ4TT+UeMZ+JtWFko= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2378.eurprd07.prod.outlook.com (10.168.128.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.6; Thu, 22 Nov 2018 13:02:43 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::5d31:ff09:b9ba:29c3]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::5d31:ff09:b9ba:29c3%11]) with mapi id 15.20.1361.016; Thu, 22 Nov 2018 13:02:43 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: IETF103 Minutes CBOR Thread-Index: AQHUgmOnH47Wzil53EWH+FsbBwAuBw== Date: Thu, 22 Nov 2018 13:02:43 +0000 Message-ID: <3F12AE16-0E87-4855-9D88-BCC00FD65EDB@ericsson.com> 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.93] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2378; 6:WE6+tGK1W3yiiQBdhBOkqFx5uc6+aIpcVLys9zIiTvAUCL0kyOGsZvNj21caFgUFrJrPw63PcjcLKg2g8BQdlVFfqwmeg5bB+6FGi+jd2zMXE9z9f3+uPh6SUCYD+h+ysmavO/ScT4OtsUk0CgGZqrlGJOrXrfX5AHHoi72HhBiUXyn55oJzVfzslWEsuN85e/lHYVhoTUNcJQyFCyRXEM0DkfzftGv98Uvb0aZarLOZBVxzeHZLiwNjYMvPTvhIscOBIh37uCXo8XKMazUVi0ERE/1bdXhULMWuDaBya6eiY+GF+66gXgcPdv0WK/8weMl7wTsLQn0Z6yeSN/gi8TzqX1ECTlwdLYB0d/1G0V2vX5RdxC8uWbZvoN5rh3+5lAtn711cXMPIn4Re8uUBrvWupCK/4wzqRK3cbCJ+zry1IQrNJlMCVKBfiaAaBc852sAhK9pRHFxVZ0pmbi+byA==; 5:QB2BxTmlzdWzsPiRRMArdokaTtto/qoXO3yREddqyNAGkdNL/8mpJ/dXv/f0qGQhmObwDAPdD1es8VF91CU4xzhHloz42RW+At0MTILvbKlxN5+E97t9WbKjLoT5FtNLJIUU8SGvfcAmX6CLmthAsmqCdYXsAd5nUtQ3QoBkQiI=; 7:rpL/0WjsSoCgwcd5kNqm48P2momp7grho293UNSeCvx1xdEzLJwjUHY9PpHmZiqYsSmL1if5HLLeM6jt6MA446GketB1VeChjFjs2eP0BK3TVEVkEPZPjGyFRRsG2D2mwJf0enEFyKrpupxaoee4sQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 45a67a39-c005-454d-d117-08d6507aca7f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2378; x-ms-traffictypediagnostic: HE1PR0701MB2378: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231442)(944501410)(52105112)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1PR0701MB2378; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2378; x-forefront-prvs: 0864A36BBF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(136003)(376002)(366004)(53754006)(189003)(199004)(83716004)(8936002)(6436002)(71190400001)(2501003)(105586002)(106356001)(97736004)(53936002)(71200400001)(5640700003)(36756003)(561944003)(54896002)(6306002)(6486002)(236005)(6512007)(33656002)(316002)(68736007)(476003)(2351001)(3846002)(5660300001)(81166006)(8676002)(7116003)(7736002)(606006)(450100002)(6506007)(102836004)(4326008)(6116002)(6916009)(25786009)(26005)(478600001)(99286004)(1730700003)(256004)(81156014)(14444005)(14454004)(966005)(2900100001)(66066001)(186003)(2906002)(86362001)(2616005)(486006)(44832011)(82746002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2378; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: arf9xheBAcz7ogk8SoJFqn64b1y4Nx4DqIJ3rWfhx7ygA9L/pSTeS+8BzerdRyK2RxMm49lsVu502Rpa7KdPH0BTlfqOMzWlFvbaK6iT4Kl+7hkquixDZZRQdOr7l4HhlU14CkpOMHzqPTOPhfa4flwndbClTzQzPxU49h8hWp6w26Ao7yQUZ4AC7RzqNj4TJ2uZEe4vqzIKvnUpwFQDjP0l9hF0DLEnJN4ZuwBPzmcoXuDyEb4Q7j+ussfoS8Uh5+cKxwkJqNFlwVKUy78YDcG1aSVHIpKgypAR1HWIjikYfE7NlkvGNnYVexJ0f6CkLAd8WMGofjDHFjRo72ZhkRKLXYhEDZ/hAUbFFAYm7SQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_3F12AE160E8748559D88BCC00FD65EDBericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 45a67a39-c005-454d-d117-08d6507aca7f X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2018 13:02:43.1999 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2378 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMKsWRmVeSWpSXmKPExsUyM2J7ie7XFd+iDea3sVnM/ruF0WJmx3QW ByaPJUt+MgUwRnHZpKTmZJalFunbJXBl7G7Zxljw5gJjxbwLp5gbGJefZuxi5OSQEDCRuHH3 CJDNxSEkcIRR4tDfHywQzjdGiVeLJkE5S5gk+ja/YgdxWAQmMEtcnj6bFSIzjUni+qb5UGXP GSUe9J9jB5nMJmAjceHhe1YQW0RAWWLqlMNsXYwcHMwChhI/9xSChIUFZCWuLdkCVaIk8Wxy PzuErSexrn8DWJxFQFXiytUnbCA2r4C9xPp/i1lAbEag3i+Nq5lBbGYBcYlbT+YzQTwkILFk z3lmCFtU4uXjf6wQ9ckSV273sYOcICGgIHH/ZhREiazEpfndYP9LCNxgk3j+4AM7REJX4sPU qVBzfCX2TlnHBlF0iVFiX9N5aOjpSJyY9B1qcb7EybNtUA1yEqt6H7JANJxmljjR+RlqqoxE 77PNUInFbBIbXzawTmDUnYXkCwg7WeLV/qeMs8C+FpQ4OfMJyyxw4GlKrN+lD1GiKDGl+yE7 hK0h0TpnLpTtIdE84RErspoFjByrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQKT0sEtvw12 ML587niIUYCDUYmH9/uCb9FCrIllxZW5hxglOJiVRHgvOwKFeFMSK6tSi/Lji0pzUosPMUpz sCiJ81r4bY4SEkhPLEnNTk0tSC2CyTJxcEo1MLa9fhc889ZqvfOTl0yd0X4z/azIQuZzj5QP VP4xV2XK+cr/PCbr15ofF+YZPFp6LE3x0wHTB00TF/le+H/RZselO1v+aenlzZG7yMfIcy7d tfHneuUmmz4t+U+JbwqT/1gqiU8prD+f80XVlXta2dUWkb+nH1m11H9ZaJr9vEhM9u/OtxWv v0cqsRRnJBpqMRcVJwIAuEL7UEYDAAA= Archived-At: Subject: [Cbor] IETF103 Minutes CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 13:02:52 -0000 --_000_3F12AE160E8748559D88BCC00FD65EDBericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHVwbG9hZGVkIHRoZSBtaW51dGVzIGZvciB0aGUgQ0JPUiBtZWV0aW5nIGF0 IElFVEYxMDMgb24gdGhlIGRhdGF0cmFja2VyOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9taW51dGVzLTEwMy1jYm9yLw0KDQpQbGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IGhhdmUg YW55IGNvbW1lbnQsIGFuZCBpZiB5b3UgaGF2ZSBhY3RpdmVseSBwYXJ0aWNpcGF0ZWQsIHRha2Ug YSBzZWNvbmQgdG8gbWFrZSBzdXJlIHRoYXQgeW91ciBjb21tZW50cyB3ZXJlIGNvcnJlY3RseSBj YXB0dXJlZC4gSSBhZGRlZCBsaW5rcyB0byBzbGlkZXMgYW5kIHlvdXR1YmUgdmlkZW8gcmVjb3Jk aW5ncy4NCg0KDQpGcmFuY2VzY2ENCg0KLS0NCg0KQ0JPUiBXRyBNZWV0aW5nDQpJRVRGIDEwMyAt IEJhbmdrb2sNCldlZG5lc2RheSwgTm92ZW1iZXIgNywgMjAxOCwgMDk6MDAgLSAxMTowMA0KQ2hh aXJzOiBCYXJyeSBMZWliYSwgRnJhbmNlc2NhIFBhbG9tYmluaQ0KDQpNaW51dGUgdGFrZXJzOiBQ YXVsIEhvZmZtYW4sIEZyYW5jZXNjYSBQYWxvbWJpbmkNCg0KKiBDaGFpcnMgaW50cm8gLSBodHRw czovL3lvdXR1LmJlL3czNHVxbXRwQ21RP3Q9MTE2DQogIFNsaWRlczogaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy1jYm9yLWNoYWly cy0wMC5wZGYNCg0KICAgIC0gRGVjaWRlZCB0byBjb250aW51ZSBiaS13ZWVrbHkgY2FsbHMsIHdp bGwgaGF2ZSBhIHBvbGwgdG8gZGV0ZXJtaW5lIHRoZSB0aW1lDQoNCiogQ0RETCAoQ2Fyc3Rlbikg LSBodHRwczovL3lvdXR1LmJlL3czNHVxbXRwQ21RP3Q9NDgwDQogIFNsaWRlczogaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy1jYm9y LWNvbnNvbGlkYXRlZC1zbGlkZXMtMDEucGRmIChzbC4gMS04KQ0KDQogICAgLSByZXBseSB0byBJ QU5BIChuZXcgQ0RETCBwYWdlLCBvcmRlciBvZiByZWdpc3RyeSAiYXMgaXQgY2FtZSBpbiB1bmxl c3Mgc3BlY2lmaWVkIG90aGVyd2lzZSIpDQogICAgLSBhc2sgS2V2aW4gQnJhdW4gZm9yIHdoYXQg aXMgbm90IGNsZWFyIGluIENEREwgMi4yLjMuDQogICAgLSBpbmNsdWRlIEFsZXhleSdzIGNvbW1l bnRzIChzZW50IG9mZiBsaXN0KSBpbmNsdWRpbmcgbWFyayBhbGwgbm9ybWF0aXZlIGFwcGVuZGlj ZXMgbm9ybWF0aXZlDQogICAgLSBpbmNsdWRlIFNFQ0RJUiByZXZpZXcNCiAgICAtIGluY2x1ZGUg R0VOQVJUIHJldmlldy4gQVAgQ2Fyc3RlbjogcG9zdCB0byB0aGUgbGlzdCB0aGF0IGFsbCBkZXNj ZW5kaW5nIHNlcXVlbmNlIChlLmcuIDEwLi4wKSBtZWFucyBlbXB0eQ0KICAgIC0gY291cGxlIG9m IG1vcmUgZWRpdG9yaWFscw0KICAgIC0gUGxhbiB0byBzdWJtaXQgdi0wNiAxMy8xMSB3aXRoIGFs bCBvZiB0aGUgYWJvdmUNCg0KKiBDRERMIHBvc3QgMS4wIC0gaHR0cHM6Ly95b3V0dS5iZS93MzR1 cW10cENtUT90PTE1NDYNCiAgU2xpZGVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21l ZXRpbmcvMTAzL21hdGVyaWFscy9zbGlkZXMtMTAzLWNib3ItY29uc29saWRhdGVkLXNsaWRlcy0w MS5wZGYgKHNsLiA5KQ0KDQogICAgLSBTVUlUIHdvdWxkIGxpa2UgYW4gaW1wb3J0IGZ1bmN0aW9u OiBwb3NzaWJseSByZXBvcnQgdG8gdGhlIGxpc3QNCiAgICAtIEFQIFBhdWw6IG91dHJlYWNoIHRv IGF1dGhvcnMgb2Ygc3BlY3MgdXNpbmcgQ0RETCwgQ0JPUiwgb3IgSlNPTiBhc2tpbmcgd2hhdCB0 aGV5IG1pZ2h0IHdhbnQNCg0KKiBDQk9SYmlzIC0gaHR0cHM6Ly95b3V0dS5iZS93MzR1cW10cENt UT90PTE4NTINCiAgU2xpZGVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcv MTAzL21hdGVyaWFscy9zbGlkZXMtMTAzLWNib3ItY29uc29saWRhdGVkLXNsaWRlcy0wMS5wZGYg KHNsLiAxMC0xOCkNCg0KICAgIHNvbWUgaXNzdWVzIHRvIGRlY2lkZSBvbjoNCiAgICAtICMzNTog a2VlcCBpbmZpbml0eSBpbmNsdWRlZA0KICAgIC0gMC4wMCAtMC4wMCA6IG5vIG9waW5pb24gZnJv bSB0aGUgd2cgKHNvIGRvIGFzIGltcGxlbWVudGVycyBzYXkgYW5kIGRvIG5vdCBoYXZlIGJvdGgp DQogICAgLSAjMzc6IG5vdCBzdHJvbmcgb3Bpbmlvbg0KICAgIC0gSUFOQTogc3BlYyByZXF1aXJl ZCBidXQgYWRkaXRpb25hbCBndWlkZWxpbmVzIHRvIGV4cGVydA0KICAgIC0gSUFOQTogMSsyIHJh bmdlOiBhZGQgc3BlYyByZXF1aXJlZA0KDQogICAgLSBpc3N1ZXM6IGh0dHBzOi8vZ2l0aHViLmNv bS9jYm9yLXdnL0NCT1JiaXMvaXNzdWVzDQogICAgICAgIC0gMzY6IGNoYW5nZSB0byBzZWxmLWRl c2NyaWJlZA0KICAgICAgICAtIDM4OiBmaXggdGhlIHRleHQgdGhhdCBpcyB0b28gaGFyZA0KICAg ICAgICAtIDI5OiByZXF1aXJlcyBzb21lIGFuYWx5c2lzLCBtYXliZSAyIHNvbHV0aW9ucyAoMSBm b3IgYmFzZTY0IGFuZCBvbmUgZm9yIGJhc2U2NHVybCkgLSBQYXVsIHRoaW5rcyB3ZSBkb24ndCBu ZWVkIHRvIHNwZWNpZnkgdGhpczogInlvdSBtaWdodCBkbyB0aGlzIiB3ZSBkb24ndCBuZWVkIGlu dGVyb3BlcmFiaWxpdHkgZm9yIHRhZ3MgLSBDaHJpcyBMZW1tb25zICgrMSBmcm9tIEFsZXhleSkg Z29vZCB3aXRoIGludGVyb3BlcmFibGUgdGFncywgQVAgQ2Fyc3RlbjogcG9zdCB0byB0aGUgbWFp bGluZyBsaXN0DQogICAgICAgIC0gMjU6IENhcnN0ZW4gdGhpbmtzIGNoYW5naW5nIHRlcm1pbm9s b2d5IGlzIG5vdCBhIGdvb2QgaWRlYSBub3cuIExhdXJlbmNlIHdvdWxkIGxpa2UgdG8gY2hhbmdl IG1hcCBrZXkgZm9yIGxhYmVsLiBDYXJzdGVuOiBtYXAga2V5IGFyZSBub3Qgb25seSBsYWJlbHMu DQogICAgICAgIC0gTGF1cmVuY2Ugb24gY2Fub25pY2FsaXphdGlvbjogd291bGQgbGlrZSBzb21l IG1vdGl2YXRpb24gYWJvdXQgd2h5IGl0IGV4aXN0cywgd2h5IGFuZCB3aGVuIHlvdSBtaWdodCB3 YW50IHRvIHVzZSBpdC4gQVAgTGF1cmVuY2U6IHdyaXRlIHByb3Bvc2FsICh3ZyBzZWVtZWQgdG8g dGhpbmsgdGhhdCBpcyBhIGJhZCBpZGVhLCBtb3JlIGNvbmZ1c2luZykNCiAgICAgICAgLSBBUCBD YXJzdGVuOiBjaGVjayAjMjEgYW5kIHNlZSBpZiBpdCB3YXMgZG9uZQ0KICAgICAgICAtIDE2OiBl eGFtcGxlcyBpbiB0aGUgc3BlYzogYWRkIGEgcG9pbnRlciB0byBjb3NlIGdpdGh1Yg0KICAgICAg ICAtIDM6IGNoZWNrIHdpdGggSmVmZnJleSB0byBzZWUgaWYgaGUgaXMgc2F0aXNmaWVkDQogICAg ICAgIC0gcHVsbCByZXF1ZXN0czogQVAgYXV0aG9yczogY2hlY2sgdGhhdCB3aGF0IHdhcyBpbmNs dWRlZCBpcyBvayB3aXRoIEplZmZyZXkNCg0KDQoqIFRhZ3MgLSBodHRwczovL3lvdXR1LmJlL3cz NHVxbXRwQ21RP3Q9NTQwMA0KICBTbGlkZXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv bWVldGluZy8xMDMvbWF0ZXJpYWxzL3NsaWRlcy0xMDMtY2Jvci1jb25zb2xpZGF0ZWQtc2xpZGVz LTAxLnBkZiAoc2wuIDE5LTI1KQ0KDQogICAgLSAxKzEgZm9yIGJ5dGUgdGFnczogcG9zdCB0byB0 aGUgbWFpbGluZyBsaXN0DQogICAgLSBwbGFuOiBhZnRlciB0aGUgYWJvdmUsIHN1Ym1pdCB2LTAx DQogICAgLSBHZXQgbW9yZSBwZW9wbGUgdG8gcmVhZCBBcnJheSB0YWcgZG9jIGFuZCB0aGVuIGdv IHRvIFdHIExhc3QgQ2FsbCBzb29uDQoNCg== --_000_3F12AE160E8748559D88BCC00FD65EDBericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXtt c28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGlu az0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGkgYWxsLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0 bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRv d3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+SSB1cGxvYWRlZCB0aGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+bWludXRlczxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5mb3IgdGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPkNCT1I8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+bWVldGluZyBhdCBJRVRGMTAzIG9uIHRoZQ0KIGRhdGF0cmFja2VyOjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9taW51dGVzLTEwMy1jYm9yLyI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvbWludXRlcy0xMDMtY2Jv ci88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRl eHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQt c3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1h bGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+UGxlYXNlIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSBjb21t ZW50LCBhbmQgaWYgeW91IGhhdmUgYWN0aXZlbHkgcGFydGljaXBhdGVkLCB0YWtlIGEgc2Vjb25k IHRvIG1ha2Ugc3VyZSB0aGF0IHlvdXIgY29tbWVudHMgd2VyZSBjb3JyZWN0bHkgY2FwdHVyZWQu IEkgYWRkZWQgbGlua3MgdG8gc2xpZGVzIGFuZCB5b3V0dWJlIHZpZGVvIHJlY29yZGluZ3MuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRv O3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3Rl eHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0 bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNC T1IgV0cgTWVldGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JRVRGIDEwMyAtIEJhbmdrb2s8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+V2VkbmVz ZGF5LCBOb3ZlbWJlciA3LCAyMDE4LCAwOTowMCAtIDExOjAwPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoYWlyczogQmFy cnkgTGVpYmEsIEZyYW5jZXNjYSBQYWxvbWJpbmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1p bnV0ZSB0YWtlcnM6IFBhdWwgSG9mZm1hbiwgRnJhbmNlc2NhIFBhbG9tYmluaTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+KiBDaGFpcnMgaW50cm8gLSBodHRwczovL3lvdXR1LmJlL3czNHVxbXRw Q21RP3Q9MTE2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyBTbGlkZXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvbWVldGluZy8xMDMvbWF0ZXJpYWxzL3NsaWRlcy0xMDMtY2Jvci1jaGFpcnMtMDAucGRm PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgLSBEZWNpZGVkIHRv IGNvbnRpbnVlIGJpLXdlZWtseSBjYWxscywgd2lsbCBoYXZlIGEgcG9sbCB0byBkZXRlcm1pbmUg dGhlIHRpbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiogQ0RETCAoQ2Fyc3RlbikgLSBodHRw czovL3lvdXR1LmJlL3czNHVxbXRwQ21RP3Q9NDgwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyBTbGlkZXM6IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDMvbWF0ZXJpYWxzL3NsaWRlcy0x MDMtY2Jvci1jb25zb2xpZGF0ZWQtc2xpZGVzLTAxLnBkZiAoc2wuIDEtOCk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyAtIHJlcGx5IHRvIElBTkEgKG5ldyBDRERM IHBhZ2UsIG9yZGVyIG9mIHJlZ2lzdHJ5ICZxdW90O2FzIGl0IGNhbWUgaW4gdW5sZXNzIHNwZWNp ZmllZCBvdGhlcndpc2UmcXVvdDspPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyAtIGFzayBL ZXZpbiBCcmF1biBmb3Igd2hhdCBpcyBub3QgY2xlYXIgaW4gQ0RETCAyLjIuMy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gaW5jbHVkZSBBbGV4ZXkncyBjb21tZW50cyAoc2VudCBvZmYg bGlzdCkgaW5jbHVkaW5nIG1hcmsgYWxsIG5vcm1hdGl2ZSBhcHBlbmRpY2VzIG5vcm1hdGl2ZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgLSBpbmNsdWRlIFNFQ0RJUiByZXZpZXc8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gaW5jbHVkZSBHRU5BUlQgcmV2aWV3LiBBUCBDYXJzdGVu OiBwb3N0IHRvIHRoZSBsaXN0IHRoYXQgYWxsIGRlc2NlbmRpbmcgc2VxdWVuY2UgKGUuZy4gMTAu LjApIG1lYW5zIGVtcHR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyAtIGNvdXBsZSBvZiBt b3JlIGVkaXRvcmlhbHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gUGxhbiB0byBzdWJt aXQgdi0wNiAxMy8xMSB3aXRoIGFsbCBvZiB0aGUgYWJvdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiogQ0RETCBwb3N0IDEuMCAtIGh0dHBzOi8veW91dHUuYmUvdzM0dXFtdHBDbVE/dD0xNTQ2 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyBTbGlkZXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVl dGluZy8xMDMvbWF0ZXJpYWxzL3NsaWRlcy0xMDMtY2Jvci1jb25zb2xpZGF0ZWQtc2xpZGVzLTAx LnBkZiAoc2wuIDkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsg LSBTVUlUIHdvdWxkIGxpa2UgYW4gaW1wb3J0IGZ1bmN0aW9uOiBwb3NzaWJseSByZXBvcnQgdG8g dGhlIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gQVAgUGF1bDogb3V0cmVhY2gg dG8gYXV0aG9ycyBvZiBzcGVjcyB1c2luZyBDRERMLCBDQk9SLCBvciBKU09OIGFza2luZyB3aGF0 IHRoZXkgbWlnaHQgd2FudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+KiBDQk9SYmlzIC0gaHR0 cHM6Ly95b3V0dS5iZS93MzR1cW10cENtUT90PTE4NTI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7IFNsaWRlczog aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVz LTEwMy1jYm9yLWNvbnNvbGlkYXRlZC1zbGlkZXMtMDEucGRmIChzbC4gMTAtMTgpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgc29tZSBpc3N1ZXMgdG8gZGVjaWRl IG9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgLSAjMzU6IGtlZXAgaW5maW5pdHkgaW5j bHVkZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gMC4wMCAtMC4wMCA6IG5vIG9waW5p b24gZnJvbSB0aGUgd2cgKHNvIGRvIGFzIGltcGxlbWVudGVycyBzYXkgYW5kIGRvIG5vdCBoYXZl IGJvdGgpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyAtICMzNzogbm90IHN0cm9uZyBvcGlu aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyAtIElBTkE6IHNwZWMgcmVxdWlyZWQgYnV0 IGFkZGl0aW9uYWwgZ3VpZGVsaW5lcyB0byBleHBlcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0gSUFOQTogMSYjNDM7MiByYW5nZTogYWRkIHNwZWMgcmVxdWlyZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyAtIGlzc3VlczogaHR0cHM6Ly9naXRodWIu Y29tL2Nib3Itd2cvQ0JPUmJpcy9pc3N1ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gMzY6IGNoYW5nZSB0byBzZWxmLWRlc2NyaWJlZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSAzODogZml4 IHRoZSB0ZXh0IHRoYXQgaXMgdG9vIGhhcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gMjk6IHJlcXVpcmVzIHNvbWUgYW5hbHlzaXMsIG1heWJl IDIgc29sdXRpb25zICgxIGZvciBiYXNlNjQgYW5kIG9uZSBmb3IgYmFzZTY0dXJsKSAtIFBhdWwg dGhpbmtzIHdlIGRvbid0IG5lZWQgdG8gc3BlY2lmeSB0aGlzOiAmcXVvdDt5b3UgbWlnaHQgZG8g dGhpcyZxdW90OyB3ZSBkb24ndA0KIG5lZWQgaW50ZXJvcGVyYWJpbGl0eSBmb3IgdGFncyAtIENo cmlzIExlbW1vbnMgKCYjNDM7MSBmcm9tIEFsZXhleSkgZ29vZCB3aXRoIGludGVyb3BlcmFibGUg dGFncywgQVAgQ2Fyc3RlbjogcG9zdCB0byB0aGUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIDI1OiBDYXJzdGVuIHRoaW5r cyBjaGFuZ2luZyB0ZXJtaW5vbG9neSBpcyBub3QgYSBnb29kIGlkZWEgbm93LiBMYXVyZW5jZSB3 b3VsZCBsaWtlIHRvIGNoYW5nZSBtYXAga2V5IGZvciBsYWJlbC4gQ2Fyc3RlbjogbWFwIGtleSBh cmUgbm90IG9ubHkgbGFiZWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLSBMYXVyZW5jZSBvbiBjYW5vbmljYWxpemF0aW9uOiB3b3VsZCBsaWtl IHNvbWUgbW90aXZhdGlvbiBhYm91dCB3aHkgaXQgZXhpc3RzLCB3aHkgYW5kIHdoZW4geW91IG1p Z2h0IHdhbnQgdG8gdXNlIGl0LiBBUCBMYXVyZW5jZTogd3JpdGUgcHJvcG9zYWwgKHdnIHNlZW1l ZCB0bw0KIHRoaW5rIHRoYXQgaXMgYSBiYWQgaWRlYSwgbW9yZSBjb25mdXNpbmcpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIEFQIENhcnN0ZW46 IGNoZWNrICMyMSBhbmQgc2VlIGlmIGl0IHdhcyBkb25lPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIDE2OiBleGFtcGxlcyBpbiB0aGUgc3BlYzog YWRkIGEgcG9pbnRlciB0byBjb3NlIGdpdGh1YjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSAzOiBjaGVjayB3aXRoIEplZmZyZXkgdG8gc2VlIGlm IGhlIGlzIHNhdGlzZmllZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLSBwdWxsIHJlcXVlc3RzOiBBUCBhdXRob3JzOiBjaGVjayB0aGF0IHdoYXQg d2FzIGluY2x1ZGVkIGlzIG9rIHdpdGggSmVmZnJleTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4qIFRhZ3MgLSBodHRwczovL3lvdXR1LmJlL3czNHVx bXRwQ21RP3Q9NTQwMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPlNsaWRlczogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5n LzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy1jYm9yLWNvbnNvbGlkYXRlZC1zbGlkZXMtMDEucGRm IChzbC4gMTktMjUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsg LSAxJiM0MzsxIGZvciBieXRlIHRhZ3M6IHBvc3QgdG8gdGhlIG1haWxpbmcgbGlzdDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsgLSBwbGFuOiBhZnRlciB0aGUgYWJvdmUsIHN1Ym1pdCB2LTAx PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyAtIEdldCBtb3JlIHBlb3BsZSB0byByZWFkIEFy cmF5IHRhZyBkb2MgYW5kIHRoZW4gZ28gdG8gV0cgTGFzdCBDYWxsIHNvb248bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_3F12AE160E8748559D88BCC00FD65EDBericssoncom_-- From nobody Thu Nov 22 06:23:56 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E03130EFE for ; Thu, 22 Nov 2018 06:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.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 GhfIDor_adux for ; Thu, 22 Nov 2018 06:23:49 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 1F42F130EE3 for ; Thu, 22 Nov 2018 06:23:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=haggis-2018; h=Date:Subject:From:To; bh=57IkbCz4DIxaKyTK+3ELIm02LbRI9/F07Fq3o6jg5mc=; b=xBGCto5w03n1OFKDkbFnu4x5Hb ytCA2oDy0l3T8EgceDgkUimZZ96Syk4TZLYjzfzMyZQbv/TP3N4by0JXNJsF0OkJizOj9qHINvJEM GZ+FjyRjvmrFGsLEanOaSc7d+VoOMaYq0txEZIqPhSTHJE6RY8shqNs5YoqYGMLIJSXpKAZvg8ZyN uCzOrbXFzhfhNLdnLO0u97NWoSKNar8jaGvUayECQFB3y6r1DyJl84RmvO8toWc6N/LEGHirYuYIJ 9tQvA8AuFsnoSAdKq/xdQQK4lBh5KhGrsAOL4WZjUOtRK/jIyloWNeq0WwaKf/BooWSIpEYS+TWU0 UeCzaZ4Q==; Received: from [2001:b98:204:102:fff1::11] (port=63445 helo=Jims-iMac.local) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gPptT-0005lI-Jj for cbor@ietf.org; Thu, 22 Nov 2018 14:23:47 +0000 To: "cbor@ietf.org" From: Jim Hague Openpgp: preference=signencrypt Autocrypt: addr=jim@sinodun.com; prefer-encrypt=mutual; keydata= xsFNBFjma08BEADHz5x1FKpV7GGMzaXlnC88O+f9iJjkajqdk8YJFS9GBB4X0RnJvew5Ek/Q yTbalhhg8lkMcDkJlW6/l+XPuwTeChLdF83c8yUW49gJ1xN2YP0pew38JzXUpeHC/JLY1FYb canohDqWojY/chE4tscGKehmmHRkneTdtZgreCNMi4cpqu4PsWiJkbBLwRlTTtq0eIUBLCcF 3/Q8Um3SXuKcXhO9XVSNIP/wHUKkZcIBJ2ZWIQYHefuos56BAZOuaV5lPkgaAcb/o72hyU+l yKF87J/srK0PIXK9WcyOYW77N8XDjr9z9W9YIPVrYfX/9DuwibJd9KfdN36T7MbYZW4sensn FsJ9SRhv7cCAcpYCLQtzVYaJ8d8OY4UJSpV3uXH/TZ0lmIH2h0M9m+5LxjyFkoeR1Dbb+OO5 P7X+lx+7kNz34fbwFoXgSWqCPOtJLHR4qejUG3oXGgfi4rBC2336Fv26og27j7TVwRlLeYF1 79/drAcsNS2SiH4v2/Frf44nKh0f6GlufcZVJSnXviMzubDedgTWsqqf8t2pjHDwWTfcGa1s plQ5rClRv43aa/QLC4+lid1MA3bHgtufPDZWz1kFmEMm+lAuFNzoQakcWm8OweN5s/MgkUFj lV/VtvmsrIt9D3BL4F5fxDG9hWwOOIwUXiCRAg57XYdTqTwa6wARAQABzRxKaW0gSGFndWUg PGppbUBsdW5jaC5vcmcudWs+wsF6BBMBCgAkAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheA BQJY5mwQAhkBAAoJEO4RoliWIemRZnEQAJMfSE1ylcKl22uaFKyE2Yg5sH0FyEdTiA8cFr2w 3Xc05Aqpv2MDko39iUfqR9AROPZNyHJtVrWrG4xicEVI/ZVHq5ujtFgllHWeoTD9X3LzvvJr 6Xogh6ZHtuJkRW05sA6dz0J/eD1bGAi7vcE0/hUo7+zpaUxNMXhn9eSjMLcSNPTfCRbeLSZb 1ooe88jNzJ5oDHz8+rCckTe38Qea+jGI0+EeG5fZkRGZiNcOV7xEcjJPRRsANX71oufj+7ZH rYAF0zSst+W29siAxL/rpMcZzqakt8bt25uMvbLlqgusLYeyKKkNRPaGYmqVzekWL2OceaLf yKr05X2LsZqcvgDfnpK0XJqOqztHudQdgutyhuzsla1JEV8TBg0Siqv7i7/osGo36EO5+FTr BQmX8tqQUiGTAOuEowr9UxznBlflGTrwd1Nfln6bNeGaAFs9k9yPQSlbnnY+VAU0fuffGYt/ Yyp3r3R+EyBWsejbXiba0/wBNczDqaJPJAhnswel1qSV1Aw6UyvG673ewLwqPdI+qz67x7yO K0MRTDW/5Vec3MyTBHjcycbkvP9gr1hyNZhHLUiK3/vfzhocMUGzRYpFuF82r/ouPuFgRsC7 KHVh2LKJk7tKvxB3ozpnHv8GAgQ3GvFVrGIzzYxF3ZL3mVJO1JNH+cJU84F9RRgErdcVzsFN BFjma08BEADxnGIWD0IRk/SMBL/nIebJN2i86SNLmjGWBbzM/DAIFylRrxzGL3eewsPd15Va IToMb7OsxK22aAXv/CqoTQFpLvNIV3gKuSvUiUun2Aas9V3yKFWnjyvmJpSzWIfhr+IsBdC5 StlQtgVlk9jcFoIpqaVTgPK8DUZzrWKEHObqeUQde9rbqlbL3wUiYaAsC9R2JQrdoSEG8fhS jdmDGicTFJPJdyoaHQz/YhyqpH5aEs5eLTgtWMeNRkgBH7wgJmH0Gn8oSHEf4JVmSdz+TgWK DaHvoP9KgoLOZEK3Q1pCDT6/EQgo9B07nej1e22ld7JGEbVCWy9IeQrOZ95YHypWiqXyQsi4 vYTp4bYhLqW4aHZJeF2Ic+3sTng53OrV5oqL4ExuIYbNbG/6To7xxvcnVlQme5x7bNbPuiZy rPyj8Cid0xI0FuWiGOh9v0nEC0zVTaAwjX82h5f9f0USYRfdYTIkoQiVE57kCQdNF7aJnJdB lxWIxKlrsfN2WgMVv4NBSgQCbq6uZF3bHPfAhF82j47JeC1sFkRnJf5y7EsKNkvT++1J6bRJ 0qD6WC+1v53iMh3Nx63/F4a7L3iBY6Q/4ITUPzA0OkVqw4oqHHgIsqx18pIzeDgCYMK7d/Vx awWiFsNNExtIpTjsSYJyxB9rOJO3yccVjxO1C1pExwMXTQARAQABwsFfBBgBCgAJBQJY5mtP AhsMAAoJEO4RoliWIemRBRUP/3LMVCCtcvHUAd61nkr2LTSPQW7Y9+he/BU672mUp3OPrtL/ wF3Cg+JQR30bJC6ztY5wAWrKoB8A380GmhhBa4havapzfp+vXvHxU4LW+ie/lE0sGneRDN1t wGkvhLRH6NGhjOEd5zWDm4D/zOzubBB5FZ4E70yadzZmzsQC7XIk28WfGDHysHJTEMmOklWy UEMF6oWvygaEMHC/lgxXYORYDA5LeElOtPbvHeRaazX74yUCTaA7w4810Dxd7aXMS+7yK3/e 2qucM6VVWb5O7bdKckJBrBxAe7BpzH2in+nA2TDoMQRCukGsnOQreQX8ulQVDC3ZEmvHmErd NHVBrcbxb5hBrnykNHy7jkNqxsS5xNJqfdo0Xa0NdD5QIZGydF4Q2J102f1eB3FpzGCugx+z sPdMFv0YKEBfS00GwCZepv/2TS0fMRwgVsjKuxkTFWklIgOWIiDrq8taSS5VXiOzxWmG0/CK XUXRviyrZ7ATwI+CqJvnbKVat1Tzu2AjtsY/jtCOpDsfwNrESQllrh4LIclNi5EojBC+h5H9 6bByZCh2/UszlhlEewHglNXSAXElQJRmC/R8ON0uHU30ZcWTzS1ohTTz1Rzo2Y27A54OxXRM IjMZr6g+IfF9Ya5kMWMIK/+c7y0Q2YWmpCO0cAWQjYN0TPWSQ0H08pfNFG9P Organization: Sinodun Internet Technologies Ltd. Message-ID: <5073d637-0608-7503-b323-2e37a644b445@sinodun.com> Date: Thu, 22 Nov 2018 14:23:41 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BlackCat-Spam-Score: 0 Archived-At: Subject: [Cbor] CDDL style questions X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 14:23:55 -0000 A couple of CDDL style questions arising from the progress of our C-DNS draft, which includes a CDDL spec. I'm not asking for any 'right' answer, more curious to know whether there is such a thing as an emerging consensus on CDDL style. Or just whether CDDL users out there Have Opinions. o Specifying fields with constant values. Should field types be explicit or implicit? FileHeader = { "identifier1" => "A string", "identifier2" => tstr .eq "Another string", "value1" => 1, "value2" => uint .eq 2, } I'm torn on this at the moment. Assuming the implementer of the format is not a CDDL/CBOR sophisticate, including explicit types may be valuable. But implicit is pleasingly succinct. o Use of .size and ranges to restrict contents of fields. The C-DNS file format obviously includes a lot of IP and DNS specific quantities. In the main, I have not attempted to specify value ranges/storage sizes for these - apart from anything else, I started on this before the necessary facilities were added to CDDL: ? server-port => uint, ? query-opcode => uint, ? query-rcode => uint, The exception is for IP addresses where we take our lead from the CDDL draft: IPv4Address = bstr .size 4 IPv6Address = bstr .size 16 IPAddress = IPv4Address / IPv6Address I think my motivation here is to try minimise 'magic numbers' and define a type rather than have 'bstr .size 16' all over the place. It's been suggested, though, that we could: Port = uint .size 2 OpCode = 0..15 RCode = 0..15 .... ? server-port => Port, ? query-opcode => OpCode, ? query-rcode => RCode, My initial reaction was that this isn't a clear-cut win; it feels like I'm duplicating IP/DNS protocol definitions which are specified elsewhere. However, the more I look at it, the more I wonder if the extra info is in fact valuable to an implementer. -- Jim Hague - jim@sinodun.com Never trust a computer you can't lift. From nobody Thu Nov 22 07:04:15 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2EB131031 for ; Thu, 22 Nov 2018 07:04:10 -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 DCvB9Dv6czix for ; Thu, 22 Nov 2018 07:03:42 -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 01C07127133 for ; Thu, 22 Nov 2018 07:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wAMF3XFx029326; Thu, 22 Nov 2018 16:03:38 +0100 (CET) Received: from [192.168.217.102] (p54A6CE66.dip0.t-ipconnect.de [84.166.206.102]) (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 4312ks1PDjz1Bqf; Thu, 22 Nov 2018 16:03:33 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <5073d637-0608-7503-b323-2e37a644b445@sinodun.com> Date: Thu, 22 Nov 2018 16:03:32 +0100 Cc: "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 564591808.176324-7aeb342cc35400ee5442b5998c993aba Content-Transfer-Encoding: quoted-printable Message-Id: <551B3855-C0BF-45E9-A481-97908A5609A1@tzi.org> References: <5073d637-0608-7503-b323-2e37a644b445@sinodun.com> To: Jim Hague X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] CDDL style questions X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 15:04:14 -0000 Hi Jim, as CDDL was developed, the various groups that have picked it up have = evolved their own style. I=E2=80=99m not sure we are ready to say there is a received style for = writing CDDL. So: > On Nov 22, 2018, at 15:23, Jim Hague wrote: >=20 > A couple of CDDL style questions arising from the progress of our = C-DNS > draft, which includes a CDDL spec. I'm not asking for any 'right' > answer, more curious to know whether there is such a thing as an > emerging consensus on CDDL style. Inquiries like yours are great for exposing the questions that such a = style would answer. > Or just whether CDDL users out there > Have Opinions. This one. Here is my opinion=E2=80=A6 > o Specifying fields with constant values. Should field types be = explicit > or implicit? >=20 > FileHeader =3D { > "identifier1" =3D> "A string", > "identifier2" =3D> tstr .eq "Another string", > "value1" =3D> 1, > =E2=80=9Cvalue2" =3D> uint .eq 2, > } In CDDL, =E2=80=9CA string=E2=80=9D is a type. With just one member in = the set, that specific string. Saying that this member of the type is also a member of a larger type = doesn=E2=80=99t really buy you a lot. (It is also rarely clear, which type. Is 2 an uint or an int? Or a = number? An unsigned?) If I were writing the above, it might look like: > FileHeader =3D { > identifier1: =E2=80=9CA string", > identifier2: =E2=80=9CAnother string", > value1: 1, > value2: 2, > } (Not a very realistic example, but I think it should illustrate my = answer to the question.) Of course, it gets interesting once you need extensibility: > FileHeader =3D { > identifier1: =E2=80=9CA string", > identifier2: =E2=80=9CAnother string", > value1: 1, > value2: 2, * label =3D> value > } label =3D text value =3D text / uint Here you are indeed making a statement about what types you expect = future additions to lie in. > I'm torn on this at the moment. Assuming the implementer of the format > is not a CDDL/CBOR sophisticate, including explicit types may be > valuable. Well, when they see =E2=80=9Cfoo=E2=80=9D in C, do they know it is a = char[], or do they always write char mystring[] =3D =E2=80=9Cfoo=E2=80=9D; before using a string? > But implicit is pleasingly succinct. Indeed. > o Use of .size and ranges to restrict contents of fields. >=20 > The C-DNS file format obviously includes a lot of IP and DNS specific > quantities. In the main, I have not attempted to specify value > ranges/storage sizes for these - apart from anything else, I started = on > this before the necessary facilities were added to CDDL: >=20 > ? server-port =3D> uint, > ? query-opcode =3D> uint, > ? query-rcode =3D> uint, >=20 > The exception is for IP addresses where we take our lead from the CDDL > draft: >=20 > IPv4Address =3D bstr .size 4 > IPv6Address =3D bstr .size 16 > IPAddress =3D IPv4Address / IPv6Address >=20 > I think my motivation here is to try minimise 'magic numbers' and = define > a type rather than have =E2=80=98bstr .size 16' all over the place. Looks good to me. > It's been suggested, though, that we could: >=20 > Port =3D uint .size 2 > OpCode =3D 0..15 > RCode =3D 0..15 > .... > ? server-port =3D> Port, > ? query-opcode =3D> OpCode, > ? query-rcode =3D> RCode, >=20 > My initial reaction was that this isn't a clear-cut win; it feels like > I'm duplicating IP/DNS protocol definitions which are specified > elsewhere. However, the more I look at it, the more I wonder if the > extra info is in fact valuable to an implementer. I don=E2=80=99t think there is a right answer to that. Ultimately, the application will need to check that the port number is = in range. Whether you simply leave it to the application to do that or include = information such as .size 2 in the CDDL is a tradeoff. On one hand, the CDDL becomes longer. On the other hand, it is more expressive of what you actually want to = exchange; you may need less English text to add. On the third hand, there are tons of application constraints that CDDL = cannot express. In the extreme, FileHeader =3D any is a valid CDDL specification for FileHeader, too :-) Without knowing all the details of C-DNS, I would expect that=20 > Port =3D uint .size 2 is a good type to have at hand and use where the semantics ask for a = TCP/UDP port. (It also immediately exposes the question whether it shouldn=E2=80=99t = really be Port =3D 1..0xFFFF i.e., whether 0 should be excluded here. Of course, I don=E2=80=99t know = what the answer to that question would be for C-DNS.) By the way, you are exposing another style issue in your examples: You seem to use CamelCase for your type names, and kebab-case for the = map labels. Looks good to me, but is not the only style in use. Maybe we can evolve something like a PEP-8 [1] or the golang guidelines = [2] for CDDL=E2=80=A6 (We can already copy the text about =E2=80=9CKnow when to be = inconsistent=E2=80=9D from PEP-8 :-) Oh, and we need a style guide for diagnostic notation, too=E2=80=A6 Is it: [ / protected / << { / alg / 1: 1 / AES-GCM 128 / } >> , / unprotected / { / iv / 5: h=E2=80=9902d1f7e6f26c43d4868d87ce' }, =E2=80=A6 Or is it: [ << { / protected / 1: 1 / alg: AES-GCM 128 / } >>, { / unprotected / 5: h=E2=80=9902d1f7e6f26c43d4868d87ce' / iv / }, =E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten [1]: https://www.python.org/dev/peps/pep-0008/ [2]: https://github.com/golang/go/wiki/CodeReviewComments= From nobody Thu Nov 22 11:37:55 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7D412426A for ; Thu, 22 Nov 2018 11:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 930rEO0QXVWy for ; Thu, 22 Nov 2018 11:37:52 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 294B212875B for ; Thu, 22 Nov 2018 11:37:52 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id w73so2309938pfk.10 for ; Thu, 22 Nov 2018 11:37:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/friAKPIEqg484+90qNDLwXQgxnpmKeApdz9b3swQgA=; b=NkQdjkFbFfl8aOshNnDkS/jAibrizC7Fjru8NRLO+GYWR41QKaTJDEeNXlwhfvULJX sCG1mRfmrpkT8I306vbHYhfdUIioI54Uo+Zk9PrnbPfuqDVEk7l25rAnfASs6NESlLkb hOWqkoOE5eUR22p8qOS6Jn1kdwPq8n+u/Svz8nCo8VFsbamPVk7sVZmQRfOaHPEIW+wj PPyKPQ1AtNQMlxi4jbTw0ee0LSDMQTULsvHCXCdpwB3fgH2hYcpflXLj394SFbOmdCvQ rrOYghaMZ9l9dDsWvjxY9KaPxieI354ORHhBz6tvPzfKegHxTTLcl4yE7iOYTJR9KIdI d8fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/friAKPIEqg484+90qNDLwXQgxnpmKeApdz9b3swQgA=; b=hARMzdJTjS9GwFgokcC/pG8SNk6erAntSoAb6fOWmoOfjMHyhXgjxrHmBGJnQb3OoI SyE/mNzcPV4I4SywOZKNTl5Xy4EYZKAYPL9O6mG2q46XLoLGz0ANxs4U2ogosET6yfiY 3eIMx3BqWtt6BLEpDekDCA0TPU4bGZoACYWq8RktoijzP2DDFRZEg7DBCpqmQ8mkIZQz Vh9OQ9OTk9St4WF1RheQPXXQDtZwb1Im7JHq7NFE8poWkoP6l2YgZT+4Tz6SvTxq46FY ci545/L6Fg26i5aGgAPIN0zfYGncYuga6YIvNGQ5asExfikzrK4Ng+5xax1ZJ5mhyA7s lQgQ== X-Gm-Message-State: AGRZ1gLi6svVtKfqGM4ZFsOzphwceYwN33HBoPjFZoKqfJuq0j3PMh8q WXsK0F5E/jNPLSRgKC0cBCYfLGia X-Google-Smtp-Source: AJdET5fm0oI7HkQhnIE/K46pXvMzxDICoMAVJtnC7e3JcMsqG7rUuw9KAoB0/A3XvLMQYHebfFdVGQ== X-Received: by 2002:aa7:8354:: with SMTP id z20mr12530070pfm.81.1542915471314; Thu, 22 Nov 2018 11:37:51 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id l72-v6sm59409032pfi.149.2018.11.22.11.37.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Nov 2018 11:37:50 -0800 (PST) To: Carsten Bormann , Jim Hague Cc: "cbor@ietf.org" References: <5073d637-0608-7503-b323-2e37a644b445@sinodun.com> <551B3855-C0BF-45E9-A481-97908A5609A1@tzi.org> From: Brian E Carpenter Message-ID: <9ee9e096-e13d-be17-af71-22f205ca208c@gmail.com> Date: Fri, 23 Nov 2018 08:37:46 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <551B3855-C0BF-45E9-A481-97908A5609A1@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] CDDL style questions X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 19:37:54 -0000 Mainly I agree with Carsten, perhaps because I developed the CDDL for GRA= SP under his tuition. So I have snipped everything except one point. On 2018-11-23 04:03, Carsten Bormann wrote: =2E.. > Without knowing all the details of C-DNS, I would expect that=20 >=20 >> Port =3D uint .size 2 >=20 > is a good type to have at hand and use where the semantics ask for a TC= P/UDP port. >=20 > (It also immediately exposes the question whether it shouldn=E2=80=99t = really be >=20 > Port =3D 1..0xFFFF >=20 > i.e., whether 0 should be excluded here. Of course, I don=E2=80=99t kno= w what the answer to that question would be for C-DNS.) For GRASP we ended up with: port-number =3D 0..65535 one reason being that you can indicate an undefined port number by using = 0. So it rather depends whether you are defining the type to use in a sig= naling message (as for GRASP) or to use in an actual transport header. If anyone cares, the full GRASP CDDL is at https://tools.ietf.org/html/dr= aft-ietf-anima-grasp-15#section-5 . I did have one regret - using hyphens in names. When writing Python code = using the same names, I had to change them all to underscore. Not serious= , but a bit annoying. I felt bad about including: IPPROTO_TCP =3D 6 IPPROTO_UDP =3D 17 I wished I could have imported those from somewhere. As an extension to t= he style question, is there a role for a library of include files? Brian From nobody Fri Nov 30 03:12:04 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862D4130DC6 for ; Fri, 30 Nov 2018 03:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.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 kLWs0yumMGiR for ; Fri, 30 Nov 2018 03:12:00 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 887B912D4EC for ; Fri, 30 Nov 2018 03:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=balrog-2018; h=Date:Subject:From:To; bh=wfDrZMmmaeo9ppkqdhK6FjyKHRoB7kgFC1o+4FEUzAw=; b=CPVuNcGl3+TXDGHCHBr7DpxC/Z 0GMlcvmFiClYG5tMVoDIgPyIxJddUvHmPTbeb46CvquGpbRtOb9UVGBBMnSNQ7FaXFjoWFpVh/Wq6 Fetcus6A1ieLnC3UOHFU8ysvnJ89VcuKwicEwx9DEJ23EgIrt3/xsfmS8nXG5c4IYRzEizYr4qFiw nOKMDWz4N1/rfQB30w45DmHSi2zgVN/osp6T2Y3t/e56av2oBLQy/5DVT3eJR+vqOu9Jd/+JPK0Sn UU/fISha/3AgdsYMzCIE0ILElN13/vSLjDMorXivLh/yzlqOKTvlElZNVZzNJwbsAUHm7y40vRMQP HX+2b1FA==; Received: from [2001:b98:204:102:fff1::11] (port=60785 helo=Jims-iMac.local) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gSgiB-0004K0-3N for cbor@ietf.org; Fri, 30 Nov 2018 11:11:59 +0000 To: "cbor@ietf.org" From: Jim Hague Openpgp: preference=signencrypt Autocrypt: addr=jim@sinodun.com; prefer-encrypt=mutual; keydata= xsFNBFjma08BEADHz5x1FKpV7GGMzaXlnC88O+f9iJjkajqdk8YJFS9GBB4X0RnJvew5Ek/Q yTbalhhg8lkMcDkJlW6/l+XPuwTeChLdF83c8yUW49gJ1xN2YP0pew38JzXUpeHC/JLY1FYb canohDqWojY/chE4tscGKehmmHRkneTdtZgreCNMi4cpqu4PsWiJkbBLwRlTTtq0eIUBLCcF 3/Q8Um3SXuKcXhO9XVSNIP/wHUKkZcIBJ2ZWIQYHefuos56BAZOuaV5lPkgaAcb/o72hyU+l yKF87J/srK0PIXK9WcyOYW77N8XDjr9z9W9YIPVrYfX/9DuwibJd9KfdN36T7MbYZW4sensn FsJ9SRhv7cCAcpYCLQtzVYaJ8d8OY4UJSpV3uXH/TZ0lmIH2h0M9m+5LxjyFkoeR1Dbb+OO5 P7X+lx+7kNz34fbwFoXgSWqCPOtJLHR4qejUG3oXGgfi4rBC2336Fv26og27j7TVwRlLeYF1 79/drAcsNS2SiH4v2/Frf44nKh0f6GlufcZVJSnXviMzubDedgTWsqqf8t2pjHDwWTfcGa1s plQ5rClRv43aa/QLC4+lid1MA3bHgtufPDZWz1kFmEMm+lAuFNzoQakcWm8OweN5s/MgkUFj lV/VtvmsrIt9D3BL4F5fxDG9hWwOOIwUXiCRAg57XYdTqTwa6wARAQABzRxKaW0gSGFndWUg PGppbUBsdW5jaC5vcmcudWs+wsF6BBMBCgAkAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheA BQJY5mwQAhkBAAoJEO4RoliWIemRZnEQAJMfSE1ylcKl22uaFKyE2Yg5sH0FyEdTiA8cFr2w 3Xc05Aqpv2MDko39iUfqR9AROPZNyHJtVrWrG4xicEVI/ZVHq5ujtFgllHWeoTD9X3LzvvJr 6Xogh6ZHtuJkRW05sA6dz0J/eD1bGAi7vcE0/hUo7+zpaUxNMXhn9eSjMLcSNPTfCRbeLSZb 1ooe88jNzJ5oDHz8+rCckTe38Qea+jGI0+EeG5fZkRGZiNcOV7xEcjJPRRsANX71oufj+7ZH rYAF0zSst+W29siAxL/rpMcZzqakt8bt25uMvbLlqgusLYeyKKkNRPaGYmqVzekWL2OceaLf yKr05X2LsZqcvgDfnpK0XJqOqztHudQdgutyhuzsla1JEV8TBg0Siqv7i7/osGo36EO5+FTr BQmX8tqQUiGTAOuEowr9UxznBlflGTrwd1Nfln6bNeGaAFs9k9yPQSlbnnY+VAU0fuffGYt/ Yyp3r3R+EyBWsejbXiba0/wBNczDqaJPJAhnswel1qSV1Aw6UyvG673ewLwqPdI+qz67x7yO K0MRTDW/5Vec3MyTBHjcycbkvP9gr1hyNZhHLUiK3/vfzhocMUGzRYpFuF82r/ouPuFgRsC7 KHVh2LKJk7tKvxB3ozpnHv8GAgQ3GvFVrGIzzYxF3ZL3mVJO1JNH+cJU84F9RRgErdcVzsFN BFjma08BEADxnGIWD0IRk/SMBL/nIebJN2i86SNLmjGWBbzM/DAIFylRrxzGL3eewsPd15Va IToMb7OsxK22aAXv/CqoTQFpLvNIV3gKuSvUiUun2Aas9V3yKFWnjyvmJpSzWIfhr+IsBdC5 StlQtgVlk9jcFoIpqaVTgPK8DUZzrWKEHObqeUQde9rbqlbL3wUiYaAsC9R2JQrdoSEG8fhS jdmDGicTFJPJdyoaHQz/YhyqpH5aEs5eLTgtWMeNRkgBH7wgJmH0Gn8oSHEf4JVmSdz+TgWK DaHvoP9KgoLOZEK3Q1pCDT6/EQgo9B07nej1e22ld7JGEbVCWy9IeQrOZ95YHypWiqXyQsi4 vYTp4bYhLqW4aHZJeF2Ic+3sTng53OrV5oqL4ExuIYbNbG/6To7xxvcnVlQme5x7bNbPuiZy rPyj8Cid0xI0FuWiGOh9v0nEC0zVTaAwjX82h5f9f0USYRfdYTIkoQiVE57kCQdNF7aJnJdB lxWIxKlrsfN2WgMVv4NBSgQCbq6uZF3bHPfAhF82j47JeC1sFkRnJf5y7EsKNkvT++1J6bRJ 0qD6WC+1v53iMh3Nx63/F4a7L3iBY6Q/4ITUPzA0OkVqw4oqHHgIsqx18pIzeDgCYMK7d/Vx awWiFsNNExtIpTjsSYJyxB9rOJO3yccVjxO1C1pExwMXTQARAQABwsFfBBgBCgAJBQJY5mtP AhsMAAoJEO4RoliWIemRBRUP/3LMVCCtcvHUAd61nkr2LTSPQW7Y9+he/BU672mUp3OPrtL/ wF3Cg+JQR30bJC6ztY5wAWrKoB8A380GmhhBa4havapzfp+vXvHxU4LW+ie/lE0sGneRDN1t wGkvhLRH6NGhjOEd5zWDm4D/zOzubBB5FZ4E70yadzZmzsQC7XIk28WfGDHysHJTEMmOklWy UEMF6oWvygaEMHC/lgxXYORYDA5LeElOtPbvHeRaazX74yUCTaA7w4810Dxd7aXMS+7yK3/e 2qucM6VVWb5O7bdKckJBrBxAe7BpzH2in+nA2TDoMQRCukGsnOQreQX8ulQVDC3ZEmvHmErd NHVBrcbxb5hBrnykNHy7jkNqxsS5xNJqfdo0Xa0NdD5QIZGydF4Q2J102f1eB3FpzGCugx+z sPdMFv0YKEBfS00GwCZepv/2TS0fMRwgVsjKuxkTFWklIgOWIiDrq8taSS5VXiOzxWmG0/CK XUXRviyrZ7ATwI+CqJvnbKVat1Tzu2AjtsY/jtCOpDsfwNrESQllrh4LIclNi5EojBC+h5H9 6bByZCh2/UszlhlEewHglNXSAXElQJRmC/R8ON0uHU30ZcWTzS1ohTTz1Rzo2Y27A54OxXRM IjMZr6g+IfF9Ya5kMWMIK/+c7y0Q2YWmpCO0cAWQjYN0TPWSQ0H08pfNFG9P Organization: Sinodun Internet Technologies Ltd. Message-ID: Date: Fri, 30 Nov 2018 11:11:53 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BlackCat-Spam-Score: 0 Archived-At: Subject: [Cbor] CDDL tool runtime error X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 11:12:02 -0000 Hi all, I've been unable to turn up a Github or Gitlab for the CDDL tool, so I'm asking here... CDDL 0.8.6 frequently (but not always - I guess there's a problem with an optional item) errors on my CDDL for C-DNS. 0.8.5 doesn't. Is this likely to be because I have some subtle error in my CDDL, or can I hope it's a tool problem? Partial backtrace: /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:332:in `generate1': grpent in map [:grpent, [:member, 1, 1, [:int, 4], [:array, [:member, 1, Infinity, nil, [:array, [:member, 1, Infinity, nil, [:prim, 0]]]]]], [:member, 1, 1, [:int, 5], [:array, [:member, 1, Infinity, nil, [:map, [:member, 1, 1, [:int, 0], [:prim, 0]], [:member, 1, 1, [:int, 1], [:prim, 0]]]]]]] (RuntimeError) from /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in `block in generate1' from /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in `each' from /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in `flat_map' from /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in `generate1' from /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:347:in `block in generate1' from /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:346:in `initialize' from /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:346:in `new' from /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:346:in `generate1' from /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in `block in generate1' from /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in `each' from /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in `flat_map' from /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in `generate1' from /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:347:in `block in generate1' from /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:346:in `initialize' from /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:346:in `new' -- Jim Hague - jim@sinodun.com Never trust a computer you can't lift. From nobody Fri Nov 30 04:09:59 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0970130DDF for ; Fri, 30 Nov 2018 04:09:58 -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 VeKrLBowYRFF for ; Fri, 30 Nov 2018 04:09:57 -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 C84AA1294D7 for ; Fri, 30 Nov 2018 04:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wAUC9mvc026339; Fri, 30 Nov 2018 13:09:53 +0100 (CET) Received: from [192.168.217.102] (p54A6CE66.dip0.t-ipconnect.de [84.166.206.102]) (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 435tVh2t22z1Bqf; Fri, 30 Nov 2018 13:09:48 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Fri, 30 Nov 2018 13:09:47 +0100 Cc: "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 565272585.554087-47fd59ed952fe0778fff34cf24354c0c Content-Transfer-Encoding: quoted-printable Message-Id: <211180A0-5EA4-405B-9B4D-17001790CF22@tzi.org> References: To: Jim Hague X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] CDDL tool runtime error X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 12:09:59 -0000 Hi Jim, This looks like a bug I had been chasing for a while before I decided to = reimplement the map matcher/generator (which, unfortunately, isn=E2=80=99t= done). Can you send me the CDDL that triggered this? Gr=C3=BC=C3=9Fe, Carsten > On Nov 30, 2018, at 12:11, Jim Hague wrote: >=20 > Hi all, >=20 > I've been unable to turn up a Github or Gitlab for the CDDL tool, so = I'm > asking here... >=20 > CDDL 0.8.6 frequently (but not always - I guess there's a problem with > an optional item) errors on my CDDL for C-DNS. 0.8.5 doesn't. Is this > likely to be because I have some subtle error in my CDDL, or can I = hope > it's a tool problem? >=20 > Partial backtrace: >=20 > /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:332:in > `generate1': grpent in map [:grpent, [:member, 1, 1, [:int, 4], = [:array, > [:member, 1, Infinity, nil, [:array, [:member, 1, Infinity, nil, = [:prim, > 0]]]]]], [:member, 1, 1, [:int, 5], [:array, [:member, 1, Infinity, = nil, > [:map, [:member, 1, 1, [:int, 0], [:prim, 0]], [:member, 1, 1, [:int, > 1], [:prim, 0]]]]]]] (RuntimeError) > from = /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in > `block in generate1' > from = /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in > `each' > from = /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in > `flat_map' > from = /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in > `generate1' > from = /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:347:in > `block in generate1' > from = /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:346:in > `initialize' > from = /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:346:in > `new' > from = /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:346:in > `generate1' > from = /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in > `block in generate1' > from = /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in > `each' > from = /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in > `flat_map' > from = /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:298:in > `generate1' > from = /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:347:in > `block in generate1' > from = /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:346:in > `initialize' > from = /usr/local/lib/ruby/gems/2.4.0/gems/cddl-0.8.6/lib/cddl.rb:346:in > `new' > --=20 > Jim Hague - jim@sinodun.com Never trust a computer you can't = lift. >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20