From nobody Tue Aug 1 09:50:45 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F23C131DF7 for ; Tue, 1 Aug 2017 09:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVdH_MK0tWyk for ; Tue, 1 Aug 2017 09:50:41 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BBAC126C7A for ; Tue, 1 Aug 2017 09:50:41 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1501606216; h=from:subject:to:date:message-id; bh=yFG3MLisDFl9lh1sh7VmXL5sHQm30QbxLEmRv1JYzWs=; b=CgapqkqnuZw8tiGBk4r3dxP4IwgwakY0cq/dQ+3U63H3et6i2u+sr0rhZpKPrwYxv2mY0TVwIKY knB7yX52Y1GlXgHwODGduQmEz0giVyMlC1RIl72SpiYtGZ2og5Q722BgaZIPbc86+ySc3yha/GgTB xGmSC0BmyxqsQeL9cVUCLKLah8wQJLP8gTj42PG27V33ZYyHdPB94EiMFXBxNCHpY7RAzN6X2LX6U Y1uVD/mvYcvkbQ63I7U5aG+yTnirVv0DyBnAKmbU7TJqmh+FNO9U0j5P6L3YKVE2EkyBG84wd5r6b mZqaEszP+6l/zMFS8QzlznQLfJBAVjPIqIKQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 1 Aug 2017 09:50:16 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 1 Aug 2017 09:50:13 -0700 From: Jim Schaad To: References: <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com> <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com> <6B06F9C0-8002-4FB6-AF01-8C049C0FE7BB@seantek.com> <2531.1500631522@dooku.sandelman.ca> In-Reply-To: Date: Tue, 1 Aug 2017 09:50:31 -0700 Message-ID: <01b401d30ae6$4b4d0150$e1e703f0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQC23CxXMuAhsr9yZd6r6qcWiGB1BwIIC7gbAXV0BKEBiZWvPgLtw3lIAlTk7LykVcTnwA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Does CDDL need to be standards track to be referenced normatively by standards track documents? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 16:50:43 -0000 >From the state of the draft, I find myself being happy at this point = that COSE does not have a normative reference to CDDL at the moment. = Doing so would almost surely result in a problem in trying to take the = draft to standard level. Given the amount of things that seem to pop up = in the draft at odd intervals, I almost find myself thinking it should = be labeled as experimental since I don't know how much practical usage = has gone into them. I would really like to see the first version of this document published = as informational and really soon. (Like last month.) And then move the = next version to the standards track. That would give one a fixed = version of the document that could potentially be reference as a down = ref for the purpose of publishing documents today and potentially moving = them to standards level in the future. We can then have arguments about = what features need to be in the document, what it means to specify = certain idioms and how to make us all agree what the language means at a = partial leisurely pace rather than rushing it through to get Brian's = draft (among others) published. Jim > -----Original Message----- > From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Brian E = Carpenter > Sent: Friday, July 21, 2017 1:22 PM > To: Michael Richardson ; cbor@ietf.org > Cc: Sean Leonard > Subject: Re: [Cbor] Does CDDL need to be standards track to be = referenced > normatively by standards track documents? >=20 > On 21/07/2017 22:05, Michael Richardson wrote: > > > > Between starting this email, and pushing send, I went to find = RFC-editor. > > She happened to be sitting with the AD responsible for GRASP. Both > > said that the downref would be permitted only when the use of CDDL = was > > very loose. Otherwise, it would be a problem. >=20 > Actually that's an IESG decision. But why we'd contort ourselves in = that way is > beyond me. >=20 > Brian >=20 > > > > I feel strongly that we need it to be standards track. > > > > Sean Leonard wrote: > > > It's needed now. The IESG just approved at least one draft = that has > > > it as a normative reference. How else do you plan to precisely = specify > > > CBOR message formats? > > > > > > > =E2=80=9CNeed=E2=80=9D is a very subjective word. It is nice = to have. It is better to > > > have a stable reference. But =E2=80=9Cstable = references=E2=80=9D are also harder to > > > make technical changes to as more people rely on it and come = up with > > > arguments for how things can never change because they already > > > wrote/deployed stuff. > > > > This doesn't matter for CDDL the way it does for, i.e. IPv6. > > > > A specification is going to reference a *SPECIFIC* version of CDDL, > > and it just fine if we make changes in a new version. We do need an > > annotation for the compilers/checkers/, etc. what version they = should > > process, but for the purposes of referencing CDDL, we do not have to > > worry if it changes afterwards. > > > > > It=E2=80=99s not just the documents that reference this one: = it=E2=80=99s also the > > > documents that CDDL references. By way of example, CDDL = depends on > > > regular expressions, and specifically calls out PCRE. PCRE is = great but > > > is in no way a Standard; it=E2=80=99s a single implementation. = There is a lot > > > of variation in regular expression engines, and the most = useful ones > > > (thinking about PCRE, Python, Perl, and .NET) are not SDO > > > standards. There are some features in this draft that have not = even > > > been implemented yet. > > > > The lack of a specification for PCRE sounds like a more serious > > problem regardless of the status we intend for the document. > > > > > For now, you can precisely define your CBOR message format = using > > > prose. Or you can use some combination of CDDL and prose. Just > > > reference CDDL informatively. > > > > That just isn't useful. > > If you tell us to use prose, then our next step will be to write a > > specification so that we don't have to be so imprecise. > > > > -- > > ] Never tell me the odds! | ipv6 mesh = networks [ > > ] Michael Richardson, Sandelman Software Works | network = architect > [ > > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ > > > > > > > > > > > > > > -- > > Michael Richardson , Sandelman Software Works > > -=3D IPv6 IoT consulting =3D- > > > > > > >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Fri Aug 11 15:21:54 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047E91326BA for ; Fri, 11 Aug 2017 15:21:42 -0700 (PDT) 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=google.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 ZXyX6cVmD1t2 for ; Fri, 11 Aug 2017 15:21:30 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 E8516132643 for ; Fri, 11 Aug 2017 15:21:29 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id m85so1682399wma.0 for ; Fri, 11 Aug 2017 15:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Moj8eXbinKCK0BJgW1XacbTMtoqrsK/Lo/yum2/YzK4=; b=F3JrZ/E9M1Y/Y/PXf8/i2DGwaNebYwdaRtRpHq3UTwDUsfhPX9svag1gqTa86i8t9t c3RqMCdBNbfroiN3uXcOnxzQVV6j7yOmPbY878GjBIPc2MOaO7ivYGPMmsi0Z3ur3l7h iE9GFKB0KjgT0pzDmWhcVISDaVgqQF0LyNESa7T5Ywfa8dMkltNo8DL2CChRrW3gXCoF lnSMjL5KoiGfCXxRRfw+2pfbnlhKpgkjLtlA1Vv89KNeJY5UYebrU974hrBv81Sp6PbY 8SJi5inOWpFtMIIIKdi0P8zeDDJe8cjbgYBp1hoZBtYasKgHrZrfhfCOl/IRh0wHkzJy nCYQ== 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=Moj8eXbinKCK0BJgW1XacbTMtoqrsK/Lo/yum2/YzK4=; b=NlXjRhh46j9c0sd2xl5O2e4XrJSewWL0r/Dljhr2Nr5UiUzOBiqaFLZG6Ht+QhSniY 3p8fd85cJnOQBlD4jaCKYXLMt9IYa3HhZ8yAFfhLT4yFZBIBxJz8XWVwM84xc2CKZuTH hzWHkmpRN5zzOHpE/0OPntftK1wN43pR62GUEgssC8Mg9dmd3uTmE3R46uTBNilvwUEC 5Q8VnCkQVcd7L08sy8FbxQjQJC5lAtf8DDRoszRCpW0a95s8vhbbdniNEM5Az101R2FT MyyWVkMUGpc1dwFpN/+EJvipq+NHH1py1kjhKVtWHsg8oWt+83ZWRAtR1kELw7XmTno4 lYog== X-Gm-Message-State: AHYfb5ioUvm7v/EgF/4vPH27FLgPlWi9PY63opqx9bN3tj5LN53hB0HK qxEo7xZOOXopK8GUdFSV8VIzjeL/BPLGO92++A== X-Received: by 10.28.131.193 with SMTP id f184mr87466wmd.117.1502490087867; Fri, 11 Aug 2017 15:21:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.146.84 with HTTP; Fri, 11 Aug 2017 15:21:07 -0700 (PDT) From: Jeffrey Yasskin Date: Fri, 11 Aug 2017 15:21:07 -0700 Message-ID: To: cbor@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cbor] Terminology for parts of CBOR items X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 22:21:42 -0000 I'd like CBOR-bis to, if possible, provide some clearer terminology for the pieces of a CBOR item, mostly so that implementations of CBOR can use the terms and so be easier to read. Take a 32-byte byte string. We have: * Type 2 * Additional information 24 * Length 32 * Some data. The Type+Additional Info is the "initial byte" per https://tools.ietf.org/html/rfc7049#section-2. Are we happy with this term? I don't see a term for the Type+Additional Info+Length. [1] For the negative integer -32, we have: * Type 1 * Additional Information 24 * Value 31 I don't see a term that includes both the byte string's length and the integer's value. [2] I don't have strong opinions about what these terms should be, but in the spirit of not complaining without offering a path forward, I'll propose: [1] "Item header"? For integers and simple items, the item header would be the same as the item. [2] "Argument"? This isn't very good, but I don't have a better idea. Jeffrey From nobody Fri Aug 11 15:26:04 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A134C132668 for ; Fri, 11 Aug 2017 15:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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=google.com header.b=CzeIjnwv; dkim=pass (1024-bit key) header.d=chromium.org header.b=Uid4ZD+D Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3rQZIYeeB5U for ; Fri, 11 Aug 2017 15:26:00 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 6911013266B for ; Fri, 11 Aug 2017 15:26:00 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id 33so17694745wrz.4 for ; Fri, 11 Aug 2017 15:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=180ybSO1nrabp9IfpI4WPy4xTdT4gwkgjm7b3ZmH6vg=; b=CzeIjnwvJymauTuW/sHf1UF0mWQJsfOWrnOw6IxwU7xS40AVSS+rHV/K65/LUvXgoI +vpqkejx3K+SaIzxJMfLq4yp+P37YqBoHK9e6c+G3zLPLPuwegjRiJW221vbm64Mo/yl iiBkPNn3w2eLwVxMrxsj94nCORjl+73k5c2oZVwdUI7b3L3I1h6pbSKUk4Qf8qO3kbk0 zQ3CQj5v1q+OFQjVgHK491t50qYLm5RGudJHda1JJg1b+rDTnDhVjkew6gWYcwx28F/7 JFpcVRrqacoBUOOucb4UIkdFq1925DRszQ3p0r024vqUwG+BatNhOMiBBdI2BU4KHXYT c6EQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:from:date:message-id:subject:to; bh=180ybSO1nrabp9IfpI4WPy4xTdT4gwkgjm7b3ZmH6vg=; b=Uid4ZD+DJjJn00aVq5qQIRVwiTd3lH7Xn9iqki8tCQGeETYdAI3q3rX7o+FjdbQIkk 8HzK44JAUxyWjjMpCKzB8WHiV2d7TlX3/ocbKCpfge2St2TBBLktKS6llNBMH2WHtN5R XdL/qbrQkl9ikGH1aeqtpCDZiS6k+f09+ohvA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=180ybSO1nrabp9IfpI4WPy4xTdT4gwkgjm7b3ZmH6vg=; b=T4ZVDmCEaBVSEKKoggQ3XiErJZGb88bzmDtMg1ony1Ez2teM8tRWI58C6QfVbWLoGN 5UuMGszT3Hlj8PUMZsSx+l/IbrxPHhwaeLMTLpgPjAA2ix2wp2qlQLBOBI0P6uLsD+Qx RRHl4YdZA1kK1h4X88OPFl4fD1ha457LRwtil+/FyNiWmzf5BAdvWjK55Dl6BUkLSugq vqHk0LA8XhdvUhSps2Er1OCcLvO7MTP4Os8FbhzxVs8WxkaGwQTkNP83OhzfaC1N0niT 8IwYYz48PTpMb4Qnxsfs0jaVPXf8UA3LLY64hkp7XBOkwJFV68eWH4wf/NM3wMwJWFUm foNA== X-Gm-Message-State: AHYfb5ioIjJdFGg8U6NwsGOgdyjKyzXhB8SXDb/D5CVfQN7sTuAnv+6t EabFO72neHJKfc0wobELEWanQKr76yHNpDDdnw== X-Received: by 10.223.135.87 with SMTP id 23mr11140196wrz.258.1502490358263; Fri, 11 Aug 2017 15:25:58 -0700 (PDT) MIME-Version: 1.0 Sender: jyasskin@google.com Received: by 10.28.146.84 with HTTP; Fri, 11 Aug 2017 15:25:37 -0700 (PDT) From: Jeffrey Yasskin Date: Fri, 11 Aug 2017 15:25:37 -0700 X-Google-Sender-Auth: NQBQGD8sXDyGj-hleIzx8P9KPNc Message-ID: To: cbor@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cbor] Terminology for parts of CBOR items X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 22:26:03 -0000 I'd like CBOR-bis to, if possible, provide some clearer terminology for the pieces of a CBOR item, mostly so that implementations of CBOR can use the terms and so be easier to read. Take a 32-byte byte string. We have: * Type 2 * Additional information 24 * Length 32 * Some data. The Type+Additional Info is the "initial byte" per https://tools.ietf.org/html/rfc7049#section-2. Are we happy with this term? I don't see a term for the Type+Additional Info+Length. [1] For the negative integer -32, we have: * Type 1 * Additional Information 24 * Value 31 I don't see a term that includes both the byte string's length and the integer's value. [2] I don't have strong opinions about what these terms should be, but in the spirit of not complaining without offering a path forward, I'll propose: [1] "Item header"? For integers and simple items, the item header would be the same as the item. [2] "Argument"? This isn't very good, but I don't have a better idea. Jeffrey From nobody Fri Aug 11 21:40:38 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C05132410 for ; Fri, 11 Aug 2017 21:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIoqS4eboyid for ; Fri, 11 Aug 2017 21:40:35 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 1B3D1132445 for ; Fri, 11 Aug 2017 21:40:35 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id c28so22878126pfe.3 for ; Fri, 11 Aug 2017 21:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:organization:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=uP7c6hqqZvKqefoYLiIahroESBPwYHwKOjmcPIF9iHY=; b=Gg9WULpLyPsnAImrsWINZ4HR9MUX5NsasviNCMSZTjYwAcs+TLZ1ynSUxmyCOjB+Wn QN5fwYN4LAyyVy/tuovp3JBkGJbAWB0GA2V9mjDuIuFUYSqPgdEJO0BC3byB815S2tbA TOEQfPtOKb2SertEZwZdjkaTQEYDErrudaY0t3H009n1wVPYx4D8gKjABEz2nTp94z/v mB84rt5qOc1OFuCWxWa18fU1O38rl6B9Xu9slS2trgMJ6RmHUzFDLnLml9+DBRseUjpP hqnhsY/znqGT2z+jeDdD0LuAU1X4ESGs6XVR4ltIJ45W/9AxLBr8dlx5c2J1nSLgj9NE Fw0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:organization:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=uP7c6hqqZvKqefoYLiIahroESBPwYHwKOjmcPIF9iHY=; b=V2X7yovXEzdWGej6EFr2NFh/oO694R9DvpTEbfjzcALTnv8uZcF3ETITzB1Sn864+F TvpqLDz63mpOJa9n9vx6rSFKoU67oHgdp7AIGfQre3fcZU+aftA4z7duvPGtHbIK8mr/ d5f+VReWcWkypkVKErOwxglG3JA6i5dU5MF6Jw8f/rnKVV1YAPMjVdu5VwMy1mY/62pP z0Kv7wVLAuuLKd8omVegaTOwodFQWqrhGsRSwy9Ih1bUIxZ2JYpS73p8XwIddLx57+R4 LZMYILk3AGspzNxQNDo+FQSvj+R0IOUAzhScWKRIk4HqPh2khixq7CSGvzOEPiDQEU02 3yAg== X-Gm-Message-State: AHYfb5jUfBrqaW0HsHpzpcTShL8TjxSpzqryCy00zOZMtL+HoDGGl+/O zVqz8shuD9eHJfXQ X-Received: by 10.84.128.73 with SMTP id 67mr20044108pla.155.1502512834329; Fri, 11 Aug 2017 21:40:34 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e128sm3724439pfg.114.2017.08.11.21.40.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 21:40:33 -0700 (PDT) To: cbor@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <5e895b01-1530-e476-d4b3-1e8974c846d5@gmail.com> Date: Sat, 12 Aug 2017 16:40:40 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cbor] Predicting the size of a CBOR byte string X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 04:40:37 -0000 Hi, I have a practical question. Does anyone have any tips for predicting the size of a CBOR byte string in advance? Yes, I realise that looks like a silly question, so I'd better explain. In some contexts there may be a practical limit on the size of CBOR byte string that can be sent. (The GRASP protocol, for example, has a maximum allowed message size.) So, it would be very useful before starting to encode a series of objects into CBOR to be able to predict the resulting number of bytes (or more realistically, an upper bound). (I'm quite aware that doing the actual encoding is the only reasonable way to get an exact answer.) Of course it isn't hard to invent a rule of thumb for a particular environment, but I've noticed that (in Python 3) the ratio between Python object size and CBOR size is different between my Windows and my Linux machines. So my rule of thumb isn't portable. Any ideas? Regards Brian From nobody Fri Aug 11 23:51:18 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C14A1327B8 for ; Fri, 11 Aug 2017 23:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_8vTEEvMb5O for ; Fri, 11 Aug 2017 23:51:15 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35E31327B3 for ; Fri, 11 Aug 2017 23:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v7C6pAnU014126; Sat, 12 Aug 2017 08:51:10 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xTswG3Dj0zDLWC; Sat, 12 Aug 2017 08:51:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Sat, 12 Aug 2017 08:51:08 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 524213468.530305-4da5fc55cb315d9f0d7a9ca61ae7d305 Content-Transfer-Encoding: quoted-printable Message-Id: <66D998D0-3FF9-4811-BF80-3283FE44833B@tzi.org> References: To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] Terminology for parts of CBOR items X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 06:51:17 -0000 In some implementations, we have called the parts of a CBOR data item: * the head (initial byte plus any additional bytes needed to convey the = unsigned integer) and=20 * the body (the string or additional data items contained in that data = item). So if head(n) stands for the initial byte and additional bytes that = convey the unsigned integer n, we get the following summary of (definite = length) CBOR data items: Major type Head Body 0, 1, 7 head(n) =E2=80=93 (Head only) 2, 3 head(n) n bytes 4 head(n) n data items 5 head(n) 2n data items 6 head(n) 1 data item We did not come up with very good terms for the indefinite length case = (as in RFC 7049 we called 0xFF the =E2=80=9Cbreak"; the initial byte for = indefinite length of course also could be called a head; both together = are the =E2=80=9Cbrackets"). Gr=C3=BC=C3=9Fe, Carsten > On Aug 12, 2017, at 00:25, Jeffrey Yasskin = wrote: >=20 > I'd like CBOR-bis to, if possible, provide some clearer terminology > for the pieces of a CBOR item, mostly so that implementations of CBOR > can use the terms and so be easier to read. >=20 > Take a 32-byte byte string. We have: >=20 > * Type 2 > * Additional information 24 > * Length 32 > * Some data. >=20 > The Type+Additional Info is the "initial byte" per > https://tools.ietf.org/html/rfc7049#section-2. Are we happy with this > term? I don't see a term for the Type+Additional Info+Length. [1] >=20 > For the negative integer -32, we have: >=20 > * Type 1 > * Additional Information 24 > * Value 31 >=20 > I don't see a term that includes both the byte string's length and the > integer's value. [2] >=20 > I don't have strong opinions about what these terms should be, but in > the spirit of not complaining without offering a path forward, I'll > propose: >=20 > [1] "Item header"? For integers and simple items, the item header > would be the same as the item. > [2] "Argument"? This isn't very good, but I don't have a better idea. >=20 >=20 > Jeffrey >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Sat Aug 12 00:02:24 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63591324B8 for ; Sat, 12 Aug 2017 00:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE6Z5NjubVyL for ; Sat, 12 Aug 2017 00:02:21 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1311324AC for ; Sat, 12 Aug 2017 00:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v7C72HX5022992; Sat, 12 Aug 2017 09:02:17 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xTt954kNPzDLWK; Sat, 12 Aug 2017 09:02:17 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <5e895b01-1530-e476-d4b3-1e8974c846d5@gmail.com> Date: Sat, 12 Aug 2017 09:02:15 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 524214135.77418-1fb0abfe133041d0501b612d6274f867 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5e895b01-1530-e476-d4b3-1e8974c846d5@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] Predicting the size of a CBOR byte string X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 07:02:22 -0000 Hi Brian, > On Aug 12, 2017, at 06:40, Brian E Carpenter = wrote: >=20 > Hi, >=20 > I have a practical question. Does anyone have any tips for > predicting the size of a CBOR byte string in advance? Are you talking about a single CBOR byte string and its serialization (=3D= encoded data item)? The (definite length) serialization is the size of the byte string, = which becomes the body of the data item, plus the size of the head, = which is 1 for 0..23 bytes 2 for 24..255 bytes 3 for 256..65535 bytes 5 for 2^16 to 2^32-1 bytes 9 for 2^32 to 2^64-1 bytes > Yes, I realise that looks like a silly question, so I'd better > explain. In some contexts there may be a practical limit on the > size of CBOR byte string that can be sent. (The GRASP protocol, > for example, has a maximum allowed message size.) >=20 > So, it would be very useful before starting to encode a series > of objects into CBOR to be able to predict the resulting number > of bytes (or more realistically, an upper bound). Hmm, maybe you aren=E2=80=99t talking about a single byte string. The size of a encoded CBOR data item is the size of the heads + the size = of the bodies. The heads are one byte (initial byte) plus any additional bytes for = exceeding 23 bytes/data items (see above). The bodies are the data themselves. So, essentially, add all string sizes (text string, byte string), add = one byte for each node in the tree, and then add additional bytes for = any nodes that are "larger than 23=E2=80=9D (integer size, number of = bytes, number of data items, tag number, floating point value). >=20 > (I'm quite aware that doing the actual encoding is the only > reasonable way to get an exact answer.) An encoder could provide a less expensive counting mechanism that = exercises the serialization mechanism without actually creating an = output, just producing a byte count. > Of course it isn't hard to invent a rule of thumb for a particular > environment, but I've noticed that (in Python 3) the ratio between > Python object size and CBOR size is different between my Windows and = my > Linux machines. The CBOR objects are the same in both cases, no? How do you measure what you call the =E2=80=9CPython object size=E2=80=9D?= (Obviously, there are also 32-bit and 64-bit implementations of Python = and many other languages, which will differ in the size of internal = representations.) Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Aug 12 09:20:36 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CC81324E6 for ; Sat, 12 Aug 2017 09:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 tQXe3P20U-Um for ; Sat, 12 Aug 2017 09:20:33 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 F22141324E4 for ; Sat, 12 Aug 2017 09:20:32 -0700 (PDT) Received: from [192.168.123.151] (unknown [76.90.60.238]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C1FA5509BB; Sat, 12 Aug 2017 12:20:31 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Leonard In-Reply-To: Date: Sat, 12 Aug 2017 09:20:30 -0700 Cc: cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <706A42C8-3F04-4E58-960C-93DE2CA7F341@seantek.com> References: To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] Terminology for parts of CBOR items X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 16:20:35 -0000 Just my two cents, I don=E2=80=99t think it needs to be overthought=E2=80=A6= CBOR falls into the general category of a binary TLV (type-length-value) = encoding. The =E2=80=9CAdditional information=E2=80=9D portion does not = change this. In ASN.1 BER, the length can be encoded directly in the = first length octet (=E2=80=9Cshort form=E2=80=9D), or the bits in the = first length octet can specify how many octets follow that represent the = length of octets of the content (=E2=80=9Clong form=E2=80=9D). CBOR = compacts the major type and initial length into one octet; otherwise, = this is pretty much the same philosophically as CBOR. Note that = zero-length data items still count as TLV, and the sentinel that signals = the end of an indefinite-length data item is a special double case of a = complete data item, as well as the last portion of a valid TLV encoding. = (So the 0xff =E2=80=9Cbreak=E2=80=9D in CBOR is exactly analogous to the = =E2=80=9Cend-of-contents octets=E2=80=9D in ASN.1 BER, see X.690 (2015) = Section 8.1.5.) The term =E2=80=9Cheader=E2=80=9D usually refers to, well, headers: a = run of =E2=80=9Cheader fields, each consisting of a header name, a colon = [or other delimiter], and data=E2=80=9D [RFC5322], separated by = newlines. A =E2=80=9Cbody=E2=80=9D is the stuff after the =E2=80=9Cheader = section=E2=80=9D ends. It is a more macro-thing for text-oriented = protocols/data formats. In CBOR, =E2=80=9CType+Additional Info+Length=E2=80=9D is the =E2=80=9CTL=E2= =80=9D of =E2=80=9CTLV=E2=80=9D. An entire Major Type+Additional Info+Length+Data(optional +Break) would = be CBOR=E2=80=99s protocol data unit (PDU); RFC 7049 calls it = =E2=80=9CCBOR-encoded data item=E2=80=9D (basically the same thing). It=E2=80=99s not productive to call out the =E2=80=9Cboth the byte = string's length and the integer's value=E2=80=9D independently of the major type bits, because = how one interprets additional information, length, and data (value) = depends entirely on the major type bits. The additional information bits = are always about =E2=80=9Clength of string=E2=80=9D for byte and UTF-8 = text strings, but the data can be compacted into the additional = information for integers, maps, and arrays. Major type 7 can go all = sorts of ways and there is extensibility in the spec for future work (AI = values 28-30) to do any sort of thing. The incidence of data-less / body-less PDUs can be high in CBOR, in = contrast some other formats (e.g., ASN.1 BER). For simple protocols one = can easily imagine a PDU on the wire that contains nothing more than a = few maps and arrays that contain integers and true/false/null values, = none of which require a =E2=80=9Cbody=E2=80=9D/=E2=80=9Ccontent=E2=80=9D = (i.e., data that requires a length of octets specified in the Ai bits). Regards, Sean > On Aug 11, 2017, at 3:25 PM, Jeffrey Yasskin = wrote: >=20 > I'd like CBOR-bis to, if possible, provide some clearer terminology > for the pieces of a CBOR item, mostly so that implementations of CBOR > can use the terms and so be easier to read. >=20 > Take a 32-byte byte string. We have: >=20 > * Type 2 > * Additional information 24 > * Length 32 > * Some data. >=20 > The Type+Additional Info is the "initial byte" per > https://tools.ietf.org/html/rfc7049#section-2. Are we happy with this > term? I don't see a term for the Type+Additional Info+Length. [1] >=20 > For the negative integer -32, we have: >=20 > * Type 1 > * Additional Information 24 > * Value 31 >=20 > I don't see a term that includes both the byte string's length and the > integer's value. [2] >=20 > I don't have strong opinions about what these terms should be, but in > the spirit of not complaining without offering a path forward, I'll > propose: >=20 > [1] "Item header"? For integers and simple items, the item header > would be the same as the item. > [2] "Argument"? This isn't very good, but I don't have a better idea. >=20 >=20 > Jeffrey >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Aug 16 20:03:43 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166A413217D; Wed, 16 Aug 2017 20:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 u7opcR0pIHCm; Wed, 16 Aug 2017 20:03:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2496132638; Wed, 16 Aug 2017 20:03:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BAA02201AC; Wed, 16 Aug 2017 23:06:16 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1D77780B17; Wed, 16 Aug 2017 23:03:36 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org, core@ietf.org reply-to: core@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+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: [Cbor] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 03:03:41 -0000 --=-=-= Content-Type: text/plain Hi. I was trying to generate some code to implement a YANG model in CBOR using: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2 which quite clearly says that I'm to use a CBOR map type (5). Except that my understanding of SIDs is that they are deltas for the key part. (My other problem is that I don't have a SID until the SID document progresses, but I can use the experimental range for now) In many languages for which there are easy to use CBOR bindings, ruby, python, perl, js, java, the CBOR map translates to a hash or directionary. So I wondered how I could do deltas on keys in such an unordered structure... My reading of: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2 about type 5, and then I read: https://tools.ietf.org/html/rfc7049#section-3.7 which says: The CBOR data model for maps does not allow ascribing semantics to the order of the key/value pairs in the map representation. so, it seems that the SID concept as described in ietf-core-yang-cbor can not work using the map type!!! At first I thought it was just a language binding issue; that I needed ordered sets of some kind, but no... It violates the above property. Solutions that I can imagine: 1) use an array of 2-element arrays (requires an extra byte for each inner array!) 2) use an array 2x the size, and let the application reconstruct things as a hash after taking in account the SID delta. 3) use one of the discussed point/multi-dimensional-array/etc. structures that I believe were presented at IETF99... I think draft-jroatch-cbor-tags was the document. I think that I favour (2), as being the most expedient and easiest to implement. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmVB4cACgkQgItw+93Q 3WWl8ggAnqlA8iHXjQiYSuIQ2t+9go5uw1bpM4XIAlbcThozf2ow1OZgC6hQ7JXo Hq7qbL67/SrbOBXh0TGGvmPxxuH9pLuhivWNO+xQ7QtPP2b8gOt1CSwMtDE3E4Kq xl+kZi9p/19HIGUEUiWXX/1V2X7vxaVXGGvLfF0k4iD9I57je9bJnHXyA9LH92Zi KSC6CXgFMYTgYe2Ha8Kv1qRxlq78fPHbZtHuBbAglU4d1+qTz9yjDt3OBRcec5tf a/TOB9QtYte0V4c6W7lRMrDvg5pPOt252gnrOBoXp8EL8t7zA4MV2vLbphFhxzeN iclfi0sYRZQgvI9olc7z0IjLFEdG8g== =/I+1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 16 22:48:30 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1046124E15; Wed, 16 Aug 2017 22:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0hjTWoi84vJ; Wed, 16 Aug 2017 22:48:26 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3281323B2; Wed, 16 Aug 2017 22:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v7H5mLbV019929; Thu, 17 Aug 2017 07:48:21 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xXwHT0m9RzDLbQ; Thu, 17 Aug 2017 07:48:21 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <13753.1502939016@obiwan.sandelman.ca> Date: Thu, 17 Aug 2017 07:48:20 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 524641700.331557-e714c0e8394a04a63bb401ec92b1aabd Content-Transfer-Encoding: quoted-printable Message-Id: <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> References: <13753.1502939016@obiwan.sandelman.ca> To: core WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] [core] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 05:48:29 -0000 Hi Michael, SID deltas in maps are parent-referenced (and not sibling-referenced) = for this reason. Do you see anything that makes you think they are sibling-referenced? That would indeed not work in maps. (We discussed using one or more of your solutions for introducing = =E2=80=9Cordered maps=E2=80=9D, but then it seemed parent-referenced was = good enough.) Gr=C3=BC=C3=9Fe, Carsten > On Aug 17, 2017, at 05:03, Michael Richardson = wrote: >=20 >=20 > Hi. I was trying to generate some code to implement a YANG model in > CBOR using: > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2 >=20 > which quite clearly says that I'm to use a CBOR map type (5). Except = that > my understanding of SIDs is that they are deltas for the key part. > (My other problem is that I don't have a SID until the SID document > progresses, but I can use the experimental range for now) >=20 > In many languages for which there are easy to use CBOR bindings, ruby, > python, perl, js, java, the CBOR map translates to a hash or = directionary. > So I wondered how I could do deltas on keys in such an unordered = structure... >=20 > My reading of: > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2 > about type 5, and then I read: > https://tools.ietf.org/html/rfc7049#section-3.7 >=20 > which says: > The CBOR data model for maps does not allow ascribing semantics to > the order of the key/value pairs in the map representation. >=20 > so, it seems that the SID concept as described in ietf-core-yang-cbor = can not > work using the map type!!! > At first I thought it was just a language binding issue; that I needed > ordered sets of some kind, but no... It violates the above property. >=20 > Solutions that I can imagine: > 1) use an array of 2-element arrays (requires an extra byte for each = inner > array!) > 2) use an array 2x the size, and let the application reconstruct = things as a > hash after taking in account the SID delta. > 3) use one of the discussed point/multi-dimensional-array/etc. = structures > that I believe were presented at IETF99... I think = draft-jroatch-cbor-tags > was the document. >=20 > I think that I favour (2), as being the most expedient and easiest to = implement. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Aug 16 23:54:37 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E77126B7E; Wed, 16 Aug 2017 23:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dWxJ2T-GL_Bm; Wed, 16 Aug 2017 23:54:33 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F459124BAC; Wed, 16 Aug 2017 23:54:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 58BFF6AA; Thu, 17 Aug 2017 08:54:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id GP2eaB5w8V7s; Thu, 17 Aug 2017 08:54:32 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 17 Aug 2017 08:54:32 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36BEF200C5; Thu, 17 Aug 2017 08:54:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5g2w2uE5MPh8; Thu, 17 Aug 2017 08:54:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 963DE200C3; Thu, 17 Aug 2017 08:54:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 317F3404117B; Thu, 17 Aug 2017 08:54:30 +0200 (CEST) Date: Thu, 17 Aug 2017 08:54:30 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: core WG , cbor@ietf.org Message-ID: <20170817065430.wp3gqiui37f26ki6@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , core WG , cbor@ietf.org References: <13753.1502939016@obiwan.sandelman.ca> <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Cbor] [core] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 06:54:36 -0000 Carsten, if I search for 'delta' or 'reference SID', I do not find text that says what the reference SID is. Where do I have to look at to understand that delta SIDs are parent-referenced? /js PS: Why do we have this, I mean, why is there a $ for some of these? pattern 'Module|Submodule|feature|' + 'identity$|node$|notification$|rpc$|action$'; Why is this not an enum in the first place? And why are the first two capitalized? PS: Why do you not import yang-identifier from ietf-yang-types? On Thu, Aug 17, 2017 at 07:48:20AM +0200, Carsten Bormann wrote: > Hi Michael, > > SID deltas in maps are parent-referenced (and not sibling-referenced) for this reason. > Do you see anything that makes you think they are sibling-referenced? > That would indeed not work in maps. > > (We discussed using one or more of your solutions for introducing “ordered maps”, but then it seemed parent-referenced was good enough.) > > Grüße, Carsten > > > > On Aug 17, 2017, at 05:03, Michael Richardson wrote: > > > > > > Hi. I was trying to generate some code to implement a YANG model in > > CBOR using: > > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2 > > > > which quite clearly says that I'm to use a CBOR map type (5). Except that > > my understanding of SIDs is that they are deltas for the key part. > > (My other problem is that I don't have a SID until the SID document > > progresses, but I can use the experimental range for now) > > > > In many languages for which there are easy to use CBOR bindings, ruby, > > python, perl, js, java, the CBOR map translates to a hash or directionary. > > So I wondered how I could do deltas on keys in such an unordered structure... > > > > My reading of: > > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2 > > about type 5, and then I read: > > https://tools.ietf.org/html/rfc7049#section-3.7 > > > > which says: > > The CBOR data model for maps does not allow ascribing semantics to > > the order of the key/value pairs in the map representation. > > > > so, it seems that the SID concept as described in ietf-core-yang-cbor can not > > work using the map type!!! > > At first I thought it was just a language binding issue; that I needed > > ordered sets of some kind, but no... It violates the above property. > > > > Solutions that I can imagine: > > 1) use an array of 2-element arrays (requires an extra byte for each inner > > array!) > > 2) use an array 2x the size, and let the application reconstruct things as a > > hash after taking in account the SID delta. > > 3) use one of the discussed point/multi-dimensional-array/etc. structures > > that I believe were presented at IETF99... I think draft-jroatch-cbor-tags > > was the document. > > > > I think that I favour (2), as being the most expedient and easiest to implement. > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 17 00:04:21 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B48A13217D; Thu, 17 Aug 2017 00:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kh5eI1tQF0C; Thu, 17 Aug 2017 00:04:12 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34E61326F6; Thu, 17 Aug 2017 00:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v7H747wm024055; Thu, 17 Aug 2017 09:04:08 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xXxyv5QLyzDLcR; Thu, 17 Aug 2017 09:04:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <20170817065430.wp3gqiui37f26ki6@elstar.local> Date: Thu, 17 Aug 2017 09:04:07 +0200 Cc: core WG , cbor@ietf.org X-Mao-Original-Outgoing-Id: 524646247.003675-9304050efac4903fa3d2a088a0851070 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13753.1502939016@obiwan.sandelman.ca> <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> <20170817065430.wp3gqiui37f26ki6@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] [core] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 07:04:13 -0000 On Aug 17, 2017, at 08:54, Juergen Schoenwaelder = wrote: >=20 > Carsten, >=20 > if I search for 'delta' or 'reference SID', I do not find text that > says what the reference SID is. Where do I have to look at to > understand that delta SIDs are parent-referenced? 4.2.1 (of yang-cbor) says: o The delta value is equal to the SID of the current schema node minus the SID of the parent schema node. When no parent exists in But maybe there is indeed potential for editorial improvement here. Clearly phrasing this always in terms of the reference SID, and then = saying where that reference SID comes from (e.g., zero at the root of = the tree), might help. This probably also should be buttressed some more by examples. > /js >=20 > PS: Why do we have this, I mean, why is there a $ for some of these? >=20 > pattern 'Module|Submodule|feature|' + > 'identity$|node$|notification$|rpc$|action$'; >=20 > Why is this not an enum in the first place? And why are the > first two capitalized? (Now you are in core-sid, I think.) Good questions; I=E2=80=99d defer to the YANG specialists here. > PS: Why do you not import yang-identifier from ietf-yang-types? Ditto. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Aug 17 00:29:15 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190A51327EC; Thu, 17 Aug 2017 00:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 S9GgEMCPwgii; Thu, 17 Aug 2017 00:29:06 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24552132436; Thu, 17 Aug 2017 00:29:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E9914EF9; Thu, 17 Aug 2017 09:29:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id UjP5eNr_HqSw; Thu, 17 Aug 2017 09:29:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 17 Aug 2017 09:29:04 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C8D2F200C5; Thu, 17 Aug 2017 09:29:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4jCkAb8urc2C; Thu, 17 Aug 2017 09:29:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CA36200C3; Thu, 17 Aug 2017 09:29:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C82D0404125E; Thu, 17 Aug 2017 09:29:03 +0200 (CEST) Date: Thu, 17 Aug 2017 09:29:03 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: core WG , cbor@ietf.org Message-ID: <20170817072903.sce5vxgckv3q3njt@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , core WG , cbor@ietf.org References: <13753.1502939016@obiwan.sandelman.ca> <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> <20170817065430.wp3gqiui37f26ki6@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Cbor] [core] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 07:29:08 -0000 Carsten, I looked into core-sid to understand how sids work, I did not expect that the definition how delta sids work is in core-cbor... /js On Thu, Aug 17, 2017 at 09:04:07AM +0200, Carsten Bormann wrote: > On Aug 17, 2017, at 08:54, Juergen Schoenwaelder wrote: > > > > Carsten, > > > > if I search for 'delta' or 'reference SID', I do not find text that > > says what the reference SID is. Where do I have to look at to > > understand that delta SIDs are parent-referenced? > > 4.2.1 (of yang-cbor) says: > > o The delta value is equal to the SID of the current schema node > minus the SID of the parent schema node. When no parent exists in > > But maybe there is indeed potential for editorial improvement here. > Clearly phrasing this always in terms of the reference SID, and then saying where that reference SID comes from (e.g., zero at the root of the tree), might help. > This probably also should be buttressed some more by examples. > > > /js > > > > PS: Why do we have this, I mean, why is there a $ for some of these? > > > > pattern 'Module|Submodule|feature|' + > > 'identity$|node$|notification$|rpc$|action$'; > > > > Why is this not an enum in the first place? And why are the > > first two capitalized? > > (Now you are in core-sid, I think.) > Good questions; I’d defer to the YANG specialists here. > > > PS: Why do you not import yang-identifier from ietf-yang-types? > > Ditto. > > Grüße, Carsten > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 17 00:34:03 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507F51327FE; Thu, 17 Aug 2017 00:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1x8DjEefHMc; Thu, 17 Aug 2017 00:33:51 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 692211327EC; Thu, 17 Aug 2017 00:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v7H7XmF7019034; Thu, 17 Aug 2017 09:33:48 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xXyd81VJszDLdK; Thu, 17 Aug 2017 09:33:48 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <20170817072903.sce5vxgckv3q3njt@elstar.local> Date: Thu, 17 Aug 2017 09:33:47 +0200 Cc: cbor@ietf.org, core WG X-Mao-Original-Outgoing-Id: 524648027.541033-8d9006c7919cd41c44fdc3168b152d27 Content-Transfer-Encoding: quoted-printable Message-Id: <9449DAD7-723C-46DE-96BE-6D46DE6E7BBE@tzi.org> References: <13753.1502939016@obiwan.sandelman.ca> <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> <20170817065430.wp3gqiui37f26ki6@elstar.local> <20170817072903.sce5vxgckv3q3njt@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] [core] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 07:33:54 -0000 > On Aug 17, 2017, at 09:29, Juergen Schoenwaelder = wrote: >=20 > Carsten, >=20 > I looked into core-sid to understand how sids work, That document tells you how to get SIDs. > I did not expect > that the definition how delta sids work is in core-cbor=E2=80=A6 That document tells you how to encode the SIDs you have into deltas in = the CBOR serialization of YANG models. I think that is a quite reasonable division of work, but maybe again = there is potential for explaining this better editorially. One problem in the past has been that people have been referring to the = deltas as SIDs =E2=80=94 they aren=E2=80=99t, and we need to root any = remnant of that usage out of the documents. Gr=C3=BC=C3=9Fe, Carsten >=20 > /js >=20 > On Thu, Aug 17, 2017 at 09:04:07AM +0200, Carsten Bormann wrote: >> On Aug 17, 2017, at 08:54, Juergen Schoenwaelder = wrote: >>>=20 >>> Carsten, >>>=20 >>> if I search for 'delta' or 'reference SID', I do not find text that >>> says what the reference SID is. Where do I have to look at to >>> understand that delta SIDs are parent-referenced? >>=20 >> 4.2.1 (of yang-cbor) says: >>=20 >> o The delta value is equal to the SID of the current schema node >> minus the SID of the parent schema node. When no parent exists = in >>=20 >> But maybe there is indeed potential for editorial improvement here. >> Clearly phrasing this always in terms of the reference SID, and then = saying where that reference SID comes from (e.g., zero at the root of = the tree), might help. >> This probably also should be buttressed some more by examples. >>=20 >>> /js >>>=20 >>> PS: Why do we have this, I mean, why is there a $ for some of these? >>>=20 >>> pattern 'Module|Submodule|feature|' + >>> 'identity$|node$|notification$|rpc$|action$'; >>>=20 >>> Why is this not an enum in the first place? And why are the >>> first two capitalized? >>=20 >> (Now you are in core-sid, I think.) >> Good questions; I=E2=80=99d defer to the YANG specialists here. >>=20 >>> PS: Why do you not import yang-identifier from ietf-yang-types? >>=20 >> Ditto. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 >=20 From nobody Thu Aug 17 01:41:56 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D00132418; Thu, 17 Aug 2017 01:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bIVq05NQ1ZYs; Thu, 17 Aug 2017 01:41:48 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC8F132386; Thu, 17 Aug 2017 01:41:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8BC80EC1; Thu, 17 Aug 2017 10:41:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id LKlMrE2uwim0; Thu, 17 Aug 2017 10:41:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 17 Aug 2017 10:41:47 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C263200C5; Thu, 17 Aug 2017 10:41:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mNFfvRYnEcVa; Thu, 17 Aug 2017 10:41:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19D5A200C3; Thu, 17 Aug 2017 10:41:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D4C4C404147F; Thu, 17 Aug 2017 10:41:45 +0200 (CEST) Date: Thu, 17 Aug 2017 10:41:45 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: cbor@ietf.org, core WG Message-ID: <20170817084145.crttu7egrha6oxoq@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , cbor@ietf.org, core WG References: <13753.1502939016@obiwan.sandelman.ca> <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> <20170817065430.wp3gqiui37f26ki6@elstar.local> <20170817072903.sce5vxgckv3q3njt@elstar.local> <9449DAD7-723C-46DE-96BE-6D46DE6E7BBE@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <9449DAD7-723C-46DE-96BE-6D46DE6E7BBE@tzi.org> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Cbor] [core] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 08:41:50 -0000 On Thu, Aug 17, 2017 at 09:33:47AM +0200, Carsten Bormann wrote: > > > On Aug 17, 2017, at 09:29, Juergen Schoenwaelder wrote: > > > > Carsten, > > > > I looked into core-sid to understand how sids work, > > That document tells you how to get SIDs. > > > I did not expect > > that the definition how delta sids work is in core-cbor… > > That document tells you how to encode the SIDs you have into deltas in the CBOR serialization of YANG models. > Ehem, you referred to core-cbor in order to explain how deltas work, i.e. what the reference SID actually are that core-sid introduces. It is not just encoding as far as I can tell. > I think that is a quite reasonable division of work, but maybe again there is potential for explaining this better editorially. > > One problem in the past has been that people have been referring to the deltas as SIDs — they aren’t, and we need to root any remnant of that usage out of the documents. > I would appreciate if delta SIDs are defined in core-sid and core-cbor would only talk about how that delta number is encoded but not how that delta number is determined. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 17 07:03:00 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A8A126BFD; Thu, 17 Aug 2017 07:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 eBp0Y0F-250I; Thu, 17 Aug 2017 07:02:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A585213242C; Thu, 17 Aug 2017 07:02:52 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A22452009E; Thu, 17 Aug 2017 10:05:33 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 82C0F806D2; Thu, 17 Aug 2017 10:02:51 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: core WG , cbor@ietf.org In-Reply-To: <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> References: <13753.1502939016@obiwan.sandelman.ca> <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> X-Mailer: MH-E 8.6; nmh 1.6+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] [core] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 14:02:59 -0000 --=-=-= Content-Type: text/plain Carsten Bormann wrote: cb> SID deltas in maps are parent-referenced (and not sibling-referenced) cb> for this reason. Okay. I don't think I understand the resulting structure then. cb> Do you see anything that makes you think they are sibling-referenced? draft> When no parent exists in draft> the context of use of this container, the delta is set to the SID draft> of the current schema node (i.e., a parent with SID equal to zero draft> is assumed). This was the text that made me think the the "parent" was the previous entry in the dictionary. If we want to encode: 20: fruit 24: bats 28: snow that we would do this with: 20: fruit +4: bats +4: snow I re-read the example and it's clearer now, but I was reading the rules. My appologies for the confusion. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmVogsACgkQgItw+93Q 3WX5Mgf/WEN3cdG/FyxmeAXQkTDJgN2AUtDJ5mb6xrHfEJ/S6MRgOu6nJM4ef93A EhxGmLaNbbltLJGNpZe8JS80/OzQgxYbSW/UB1ybIeRSt0Sh1zdf1SCkqJ+Eaz7K bhREGSfMIKJ70EfnFBIaHBjOLloEDaqmUP2V/BvWmUUpPC6Qy+aWIDF8+FE1z0IJ cMjQCy7jMIOkwYSc4k7J2eEj2cbIy7Xk8q53NmYvXlKezS8L3DLRIK6QUIaW8joz k9rqtaFoOy3fAIlgCDP4PlV7QeHmXR6wJHa9R4X7+6e3z0ObMAbkW/PwQDhk7ZXD oYLHCLhdCeAHjWB55TDvqZ+6q25BJA== =Wy1B -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 21 17:10:20 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618DA132AE0 for ; Mon, 21 Aug 2017 17:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1IOHEj1aRrT for ; Mon, 21 Aug 2017 17:10:16 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 41875132ADD for ; Mon, 21 Aug 2017 17:10:16 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id s14so3976193pgs.1 for ; Mon, 21 Aug 2017 17:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=hd2HpnchtR/cg4ahQtrkwgkZCDIxOoIMF2KxIQs/Lyg=; b=TJqMA6secKH6Xnu/yYdP56XtSqJ2Y5dWRV7Tn1l6ejjvBA+a03AukBqSHBErJqBDJm 243qFW4THhrSusS9GqfhR++cnrGfpMrdwBzrlsF7AN7s3I3bj8taRBEC/0uK80a0Vxxh 9B/gM+SDxGlrU62EeN2UY2TB813mPtup0nhz3xMgBGfaeBPwNuTP8VjTd6bDHw1LbK1g NwVhFRjONuWQymmUsxhPu58EACGgD4IVcm3666HHllRRzWiZ18wqv+xAjwRKnD/Krk/M bmRRLVqEcSsYeOSDBbHY8eiA+V4AHDX2j01TFY7uzETOnPgAOoKHcL/fG5w67LcFHgVk 9ShA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=hd2HpnchtR/cg4ahQtrkwgkZCDIxOoIMF2KxIQs/Lyg=; b=lnuQIAgsgOT7L4Uh8Qc8TB441/FpNwkwCOvGI+uD1J7q01SBr+OVzMAvlGvcdCurwZ UGQVgBrjXT5HniET8PxeMTMkQqlg7R9kxcEnY9v6gmgqbDBOxKxQ8dy7IZFo4nLT3w/H 5Nukfl2upx1ho3oCei28GJRqOVlxXv7jdDKpfM87o3P2nFdRPxVA5l2ohNrU7oNZDFUZ qvicMKwM/aDjxNhJbJlB0NB6rJwSOOZ3zn92xXNQUqLRnpY0UMRSV12zNLgQwTp5x6Ci X3bssGn7JYrGtIAzhm2PYoRA9wi3jADfAVD8JXztm/qqZVE2I2bVcevZRZjhT9Qmg56M Gqcw== X-Gm-Message-State: AHYfb5j36bHRAilOvtvSy7+K3dibHxl6+XOTnsE0KdHHMbU0ryiTfKnb 3lWQQf2mfHzh948s X-Received: by 10.98.97.6 with SMTP id v6mr15103594pfb.25.1503360615648; Mon, 21 Aug 2017 17:10:15 -0700 (PDT) Received: from [130.216.38.3] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.3]) by smtp.gmail.com with ESMTPSA id e8sm383381pfm.117.2017.08.21.17.10.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Aug 2017 17:10:15 -0700 (PDT) To: cbor@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 22 Aug 2017 12:10:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cbor] FYI: bug in CBOR Python packages X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 00:10:18 -0000 Hi, Not a standards issue, but this may be useful: I recently discovered the hard way that in both the cbor and cbor2 packages for CBOR handling in Python, when using cbor.loads() or cbor2.loads(), the length of byte strings is not checked. For example, when decoding an instance of Tag 24, if the target byte string is truncated, .loads() does not throw an exception; it simply returns the truncated bytes object. I raised an issue for both packages. cbor2 was fixed within 24 hours; version cbor2-4.0.1 is fixed and throws an exception: cbor2.decoder.CBORDecodeError: premature end of stream (expected to read 233 bytes, got 225 instead) The older cbor package still has the problem. (All this applies to both Python 2 and Python 3.) Regards Brian Carpenter From nobody Mon Aug 21 21:43:49 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4116C1321A2 for ; Mon, 21 Aug 2017 21:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZYKGzpxo6xF for ; Mon, 21 Aug 2017 21:43:44 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80EAB1321B7 for ; Mon, 21 Aug 2017 21:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v7M4hdZN028595; Tue, 22 Aug 2017 06:43:39 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xbycW04p5zDLG6; Tue, 22 Aug 2017 06:43:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Tue, 22 Aug 2017 06:43:38 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 525069818.225048-eb2fdd29a0e8c6b09974a0dae4b0591f Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] FYI: bug in CBOR Python packages X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 04:43:47 -0000 If we ever write an implementers=E2=80=99 guide, this would be one thing = to mention there. We could write up a list of errors that need to be handled, and mention = that premature end of input cannot be handled by silent truncation of = ongoing data items. Maybe it would make sense to collect test cases such as 19 01 63 66 6f 82 01 A2 01 02 03 c1 etc. (So far, I haven=E2=80=99t seen much need for an implementers=E2=80=99 = guide, though. But maybe that will start to make sense as the body of knowledge on how = to implement CBOR well increases.) Gr=C3=BC=C3=9Fe, Carsten > On Aug 22, 2017, at 02:10, Brian E Carpenter = wrote: >=20 > Hi, >=20 > Not a standards issue, but this may be useful: >=20 > I recently discovered the hard way that in both the cbor and cbor2 > packages for CBOR handling in Python, when using cbor.loads() or > cbor2.loads(), the length of byte strings is not checked. For example, > when decoding an instance of Tag 24, if the target byte string is > truncated, .loads() does not throw an exception; it simply returns > the truncated bytes object. >=20 > I raised an issue for both packages. cbor2 was fixed within 24 hours; > version cbor2-4.0.1 is fixed and throws an exception: > cbor2.decoder.CBORDecodeError: premature end of stream (expected to = read 233 bytes, got 225 instead) >=20 > The older cbor package still has the problem. >=20 > (All this applies to both Python 2 and Python 3.) >=20 > Regards > Brian Carpenter >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Fri Aug 25 03:06:14 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E1D132195 for ; Fri, 25 Aug 2017 03:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VIym_GSu-dH for ; Fri, 25 Aug 2017 03:06:10 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46ACF12426E for ; Fri, 25 Aug 2017 03:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v7PA633H019150 for ; Fri, 25 Aug 2017 12:06:05 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xdxd74P5bzDMLL; Fri, 25 Aug 2017 12:06:03 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 525348362.53061-4382a4ecad9973c043fca1c9d287621e Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 25 Aug 2017 12:06:02 +0200 Message-Id: <34D71124-E5CC-4B96-BA4D-01C99638C041@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Cbor] Tag for (mathematical) sets X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 10:06:13 -0000 Several implementation environments have a data type for sets of items = (sets in the mathematical sense). These generally are represented in CBOR by putting the items in an = array. Today, there is no way to identify that array as a set, so a generic = CBOR decoder cannot put back the items into whatever the implementation = environment uses for representing sets, without help from the = application. There is a proposal for registering such a tag: = https://github.com/input-output-hk/cbor-sets-spec/blob/master/CBOR_SETS.md= I don=E2=80=99t think any WG action is needed here except for the FYI. However, this proposal raises one question in the context of the = discussions we have had: This proposal currently uses FCFS space, i.e. the tag is represented in = three bytes. Should we encourage the authors to go for the =E2=80=9Cspecification = required=E2=80=9D space (a two-byte tag)? Sets are fundamental enough that there should be no question about wide = applicability. While some sets are large (and a short tag therefore doesn=E2=80=99t = make a difference for them), some aren=E2=80=99t. Any opinions on this? (I believe the authors would also welcome comments to the spec right at = the github repo.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 25 05:05:56 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F44132BE1 for ; Fri, 25 Aug 2017 05:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3mfByuJh8O2p for ; Fri, 25 Aug 2017 05:05:53 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 B04FB132BE0 for ; Fri, 25 Aug 2017 05:05:53 -0700 (PDT) Received: from [10.47.60.53] (173-162-6-134-charleston.hfc.comcastbusiness.net [173.162.6.134]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v7PC4oHN034692 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Aug 2017 05:04:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 173-162-6-134-charleston.hfc.comcastbusiness.net [173.162.6.134] claimed to be [10.47.60.53] From: "Paul Hoffman" To: "Carsten Bormann" Cc: cbor@ietf.org Date: Fri, 25 Aug 2017 08:05:52 -0400 Message-ID: <2E6A5A2B-6E83-4354-BD44-20B297F66368@vpnc.org> In-Reply-To: <34D71124-E5CC-4B96-BA4D-01C99638C041@tzi.org> References: <34D71124-E5CC-4B96-BA4D-01C99638C041@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [Cbor] Tag for (mathematical) sets X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 12:05:55 -0000 On 25 Aug 2017, at 6:06, Carsten Bormann wrote: > Several implementation environments have a data type for sets of items > (sets in the mathematical sense). > These generally are represented in CBOR by putting the items in an > array. > Today, there is no way to identify that array as a set, so a generic > CBOR decoder cannot put back the items into whatever the > implementation environment uses for representing sets, without help > from the application. > > There is a proposal for registering such a tag: > https://github.com/input-output-hk/cbor-sets-spec/blob/master/CBOR_SETS.md > > I don’t think any WG action is needed here except for the FYI. > > However, this proposal raises one question in the context of the > discussions we have had: > This proposal currently uses FCFS space, i.e. the tag is represented > in three bytes. > Should we encourage the authors to go for the “specification > required” space (a two-byte tag)? No, but it's fine to alert them of the possibility. > Sets are fundamental enough that there should be no question about > wide applicability. > While some sets are large (and a short tag therefore doesn’t make a > difference for them), some aren’t. Even if a set is "not large", an extra byte is not a lot for a set. A developer is already incurring an overhead by tagging at all. --Paul Hoffman From nobody Fri Aug 25 16:14:28 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5571321BF for ; Fri, 25 Aug 2017 16:14:26 -0700 (PDT) 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 ujmUyrR1dPKA for ; Fri, 25 Aug 2017 16:14:24 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 6072D13235C for ; Fri, 25 Aug 2017 16:14:24 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id t3so6249395pgt.0 for ; Fri, 25 Aug 2017 16:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AEMlli06dcJznRsAsx5vRKKoCEfeJO/DLqaXkqqKYpM=; b=l5zM3k8sqUlgV3Sv2bm7gSoNdK0rEEKudSlw3aCIWpES9D102MfAzixo3mhQLo6YLz 9mthr3D/RrXtyK8y4Za2szj4BH/CZF1SbSQTZn2IDJTmep998dIBEqbDOGIIxrq9aD/r 2B+wA2uvH5vSxcBYso9n8sG/V7HBuSKo52g0/xjf9Y8aA36iq8HUpH+pVEWUTNkssKhv pHL3giO+wPNHDBe4qwgIvKsA3Ut63KD4IyZjzmRu6Fc2jwc+UTqRju4e70joWDFzXe2V UgWRJl59rOY8XeP7GXST4mo7IcdC7MncHjbRzRo6Ly7Y/uCFsctP7UpB8xGJhBcV38Y+ iqSg== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=AEMlli06dcJznRsAsx5vRKKoCEfeJO/DLqaXkqqKYpM=; b=V5hehXBr20T8D6wC6iXNKe1n/6MLHd5miGIykO+zS2WXXb+vYNpYCuq5dUZeIsVCkl X5Wf0jRahbKU8vpKIrt8lxbbcVbfW4jsccG36OMu/txqhzoiqc3LKu0booJ/7taFoJyi k2nJebARUcBIPZxF5wioiThbMRLMSg1LUrvAPcSqIcjjpQtWEt4854HDcOMcj4r7eU2m kcSyjvOonHrV8GN8xOOxoATTHhj5MIdiFcmeyUq97HqFr5E0aI15I5OMXXnLqhKuSJS7 uKIIDy1q/Wq2DNCtQKLBAL+NVZDKQkVz9g+N+QBSNzxQYfwPh3cmuLhpfAjT6Im12G3L ERVA== X-Gm-Message-State: AHYfb5jo2xbSUpDqKgBsJkAVxmSuD4GjazUf0m65jjmrTlLX6hkF14Yh OmrMStHBA8ttbmiW X-Received: by 10.98.60.206 with SMTP id b75mr74363pfk.25.1503702863487; Fri, 25 Aug 2017 16:14:23 -0700 (PDT) Received: from ?IPv6:2406:e007:560e:1:28cc:dc4c:9703:6781? ([2406:e007:560e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 15sm12770581pfo.57.2017.08.25.16.14.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Aug 2017 16:14:22 -0700 (PDT) To: Carsten Bormann Cc: cbor@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <6c832f10-304d-1d92-6d87-bed0c59abb95@gmail.com> Date: Sat, 26 Aug 2017 11:14:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] FYI: bug in CBOR Python packages X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 23:14:26 -0000 On 22/08/2017 16:43, Carsten Bormann wrote: > If we ever write an implementers=E2=80=99 guide, this would be one thin= g to mention there. > We could write up a list of errors that need to be handled, and mention= that premature end of input cannot be handled by silent truncation of on= going data items. > Maybe it would make sense to collect test cases such as >=20 > 19 01 > 63 66 6f > 82 01 > A2 01 02 03 > c1 > etc. >=20 > (So far, I haven=E2=80=99t seen much need for an implementers=E2=80=99 = guide, though. > But maybe that will start to make sense as the body of knowledge on how= to implement CBOR well increases.) Perhaps an implementer's wiki would be a useful start, as a repository fo= r such items. Here's another related point: Both the Python libraries do a decent job o= f decoding tagged items into high-level language objects, but the implementers took = different decisions about naming the class for the decoded object. One chose and the other chose = Not a big deal, but would it be useful to recommend class names, in the general interest of portability and the Law of Least Astonishment? Brian >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On Aug 22, 2017, at 02:10, Brian E Carpenter wrote: >> >> Hi, >> >> Not a standards issue, but this may be useful: >> >> I recently discovered the hard way that in both the cbor and cbor2 >> packages for CBOR handling in Python, when using cbor.loads() or >> cbor2.loads(), the length of byte strings is not checked. For example,= >> when decoding an instance of Tag 24, if the target byte string is >> truncated, .loads() does not throw an exception; it simply returns >> the truncated bytes object. >> >> I raised an issue for both packages. cbor2 was fixed within 24 hours; >> version cbor2-4.0.1 is fixed and throws an exception: >> cbor2.decoder.CBORDecodeError: premature end of stream (expected to re= ad 233 bytes, got 225 instead) >> >> The older cbor package still has the problem. >> >> (All this applies to both Python 2 and Python 3.) >> >> Regards >> Brian Carpenter >> >> >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >> >=20 >=20