From nobody Thu Jul 7 15:18:59 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F22612D8DB for ; Thu, 7 Jul 2016 15:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 DENfh4D-zTDE for ; Thu, 7 Jul 2016 15:18:56 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC20012D8CD for ; Thu, 7 Jul 2016 15:18:55 -0700 (PDT) Received: from mfilter26-d.gandi.net (mfilter26-d.gandi.net [217.70.178.154]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 4B94D41C08A; Fri, 8 Jul 2016 00:18:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter26-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter26-d.gandi.net (mfilter26-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id SpDoQ6qetoYb; Fri, 8 Jul 2016 00:18:52 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 4EC9041C074; Fri, 8 Jul 2016 00:18:51 +0200 (CEST) Message-ID: <577ED54A.3050705@tzi.org> Date: Fri, 08 Jul 2016 00:18:50 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: glenn_engel@keysight.com, cbor@ietf.org References: <04EFF12F483FA149B07653989B86861F217A069F@wcosexch01k.cos.is.keysight.com> <577416B1.3090308@tzi.org> In-Reply-To: <577416B1.3090308@tzi.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cbor] Next steps for additional data types X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 22:18:58 -0000 Carsten Bormann wrote: > glenn_engel@keysight.com wrote: >> > Hi, has there been any discussion of where these two proposals fit with the existing TypedArray proposal? > > No, not yet. There are still a few days up to the Internet-Draft > deadline for the Berlin meeting... I now went ahead and submitted https://tools.ietf.org/html/draft-jroatch-cbor-tags-04 For diffs, see: https://www.ietf.org/rfcdiff?url2=draft-jroatch-cbor-tags-04 Thank you, Glenn! I hope we get some F2F time to discuss this in Berlin. The natural meeting point would be the artarea/dispatch meeting on Monday morning, unfortunately that conflicts with 6lo: MONDAY, July 18, 2016 1000-1230 Morning Session I Potsdam II ART artarea Applications and Real-Time Area Open Meeting - Combined with DISPATCH Potsdam III INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG I think we will find some other time and announce it here. Grüße, Carsten From nobody Fri Jul 8 12:58:28 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5EC12D149 for ; Fri, 8 Jul 2016 12:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQf4AxJiWUeA for ; Fri, 8 Jul 2016 12:58:25 -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 D7FA512B04F for ; Fri, 8 Jul 2016 12:58:24 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F1039509B6 for ; Fri, 8 Jul 2016 15:58:23 -0400 (EDT) From: Sean Leonard To: cbor@ietf.org References: <20160708153240.32131.15645.idtracker@ietfa.amsl.com> Message-ID: <81ae4d42-78d0-a30e-eb14-d67c79c496f3@seantek.com> Date: Fri, 8 Jul 2016 12:57:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160708153240.32131.15645.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Cbor] New Version Notification for draft-bormann-cbor-tags-oid-04.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:58:27 -0000 Hi CBOR mailing list: We present the latest version of CBOR Tags and Techniques. Without changing the wire protocol, it talks about: * Object Identifiers (the original purpose) * Binary (Internet) messages and MIME entities * Enumeration and Set/Multiset techniques * Regular Expressions The main changes occurred in version-03. Based on (rather limited but pointed) feedback, version-04 mainly revised the title and the abstract so that it more accurately reflects the current contents. Hope to get quality feedback. Regards, Sean PS As stated in the -03 announcement, the details of Sections 6 and onwards were mostly written by me (although Carsten and I talked about them in person in the past). -------- Forwarded Message -------- Subject: New Version Notification for draft-bormann-cbor-tags-oid-04.txt Date: Fri, 08 Jul 2016 08:32:40 -0700 From: internet-drafts@ietf.org A new version of I-D, draft-bormann-cbor-tags-oid-04.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-bormann-cbor-tags-oid Revision: 04 Title: Concise Binary Object Representation (CBOR) Tags and Techniques for Object Identifiers, Enumerations, Binary Entities, Regular Expressions, and Sets Document date: 2016-07-08 Group: Individual Submission Pages: 32 URL: https://www.ietf.org/internet-drafts/draft-bormann-cbor-tags-oid-04.txt Status: https://datatracker.ietf.org/doc/draft-bormann-cbor-tags-oid/ Htmlized: https://tools.ietf.org/html/draft-bormann-cbor-tags-oid-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-bormann-cbor-tags-oid-04 Abstract: The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. Useful tags and techniques have emerged since the publication of RFC 7049; the present document makes use of CBOR's built-in major types to define and refine several useful constructs, without changing the wire protocol. This document adds object identifiers (OIDs) to CBOR with CBOR tags <> and <> [values TBD]. It is intended as the reference document for the IANA registration of the CBOR tags so defined. Useful techniques for enumerations and sets are presented (without new tags). As the documentation for MIME entities (tag 36) and regular expressions (tag 35) RFC 7049 left much out, this document provides more comprehensive specifications. From nobody Fri Jul 15 03:11:19 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7D112DC8A for ; Fri, 15 Jul 2016 03:11:18 -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] 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 o5d7MV9FLKhl for ; Fri, 15 Jul 2016 03:11:16 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94CF512D5FB for ; Fri, 15 Jul 2016 03:11:15 -0700 (PDT) Received: from mfilter45-d.gandi.net (mfilter45-d.gandi.net [217.70.178.176]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 41A95FB8A0; Fri, 15 Jul 2016 12:11:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter45-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter45-d.gandi.net (mfilter45-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id OXvEpSkHL0DV; Fri, 15 Jul 2016 12:11:12 +0200 (CEST) X-Originating-IP: 195.37.142.72 Received: from nar-3.local (unknown [195.37.142.72]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 6D15EFB882; Fri, 15 Jul 2016 12:11:12 +0200 (CEST) Message-ID: <5788B6C4.5040405@tzi.org> Date: Fri, 15 Jul 2016 12:11:16 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: cbor@ietf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Cbor] cbor.me (and coap.me) down X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 10:11:18 -0000 Construction workers have destroyed the network equipment that connects cbor.me (and coap.me) to the Internet. ETR ~ 1300Z. Maybe this is a good time to install the local version of the cbor.me tool: gem install cbor-diag which gives you the tools: cbor2diag.rb cbor2json.rb cbor2pretty.rb cbor2yaml.rb diag2cbor.rb diag2pretty.rb json2cbor.rb json2pretty.rb which do pretty much what you would expect them to do, given these definitions: "cbor" is binary CBOR. "diag" is CBOR's diagnostic notation. "json" is JSON. "pretty" is the pretty-printed representation of binary CBOR as used by cbor.me.). "yaml" is YAML. Output is to stdout, input from stdin or files given as command line arguments). (json2cbor.rb also has a -v option.) Grüße, Carsten From nobody Sun Jul 17 06:01:05 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1E012B05E for ; Sun, 17 Jul 2016 06:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 PU2vZ8zG5EwJ for ; Sun, 17 Jul 2016 06:01:01 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB83D12B02E for ; Sun, 17 Jul 2016 06:01:01 -0700 (PDT) Received: from dhcp-9a4a.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:659e:1860:ddaa:fd4a]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id C988FA80CE; Sun, 17 Jul 2016 15:00:59 +0200 (CEST) Message-ID: <578B818A.1090603@tzi.org> Date: Sun, 17 Jul 2016 15:00:58 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: cbor@ietf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Cbor] CDDL Tool 0.8.0 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 13:01:03 -0000 I have pushed version 0.8.0 of the CDDL tool, now with some support for the new annotations of CDDL draft -08 (.lt, .le, .gt, .ge, .eq, .ne). There is also code that properly ignores .default for validation or generation -- the tool currently does not have modes to fill in defaults (when deserializing) or to elide default values (when serializing); this could come later. As always gem update (or `gem install cddl` if you are just getting started). If you walk into me this week at IETF96 and have any feedback on the tool, please don't hold back! Grüße, Carsten From nobody Mon Jul 18 01:26:12 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC8B12D095 for ; Mon, 18 Jul 2016 01:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAQBFiB5nIQ8 for ; Mon, 18 Jul 2016 01:26:09 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196B012B034 for ; Mon, 18 Jul 2016 01:26:09 -0700 (PDT) Received: from dhcp-9a4a.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:1af:9be2:4f9b:1525]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 66B441720B3; Mon, 18 Jul 2016 10:26:07 +0200 (CEST) Message-ID: <578C92A0.5020600@tzi.org> Date: Mon, 18 Jul 2016 10:26:08 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: cbor@ietf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Cbor] cbor.me and Appendix G.4 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 08:26:11 -0000 cbor.me has been up again now for a while. Due to popular request (thanks, Peter!), it now supports the input of hex/oct/binary numbers as per Appendix G.4 of CDDL (hex floats are still to do, though). Get the same functionality on your laptops via gem update cbor-diag (now version 0.2.2) or, if you didn't have it yet gem install cbor-diag Grüße, Carsten From nobody Tue Jul 19 09:45:11 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C090C12D74F for ; Tue, 19 Jul 2016 09:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUm6BPkMdyr9 for ; Tue, 19 Jul 2016 09:45:08 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0121.outbound.protection.outlook.com [104.47.42.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532AB12D1B7 for ; Tue, 19 Jul 2016 09:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=goeUso3G7HcssUrSK27Bv6fHz91MM0l+M1VXAoeIPe4=; b=eAccS7hO7bjfpI9xNGke5afppinCdjx+7pp6gtE4g+av7ruvLpA2OGsmNArAtMa7Asa0UfsCqQ0riIxXBaLB1zMBg3A/ky4VCUAusFzrLsarrfKZYmD+jeIMh8EpoZuRKrH3/uh+fOei32OLfxlf2OE82yHCzjnXNifilIBLdcQ= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 19 Jul 2016 16:45:06 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0539.021; Tue, 19 Jul 2016 16:45:06 +0000 From: Michel Veillette To: Carsten Bormann , "cbor@ietf.org" Thread-Topic: [Cbor] cbor.me and Appendix G.4 Thread-Index: AQHR4M4NvLy16zPClEe82TgN8iZSlqAf9qow Date: Tue, 19 Jul 2016 16:45:06 +0000 Message-ID: References: <578C92A0.5020600@tzi.org> In-Reply-To: <578C92A0.5020600@tzi.org> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 9cfdfc7f-fdb2-4130-e6dc-08d3aff40a38 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 6:H13CTwM5WxNpAO6WgndYWcEhsS3LyjjcvBXLbyTmxMkf9yWDi6yDPKjtRob7Y/FcGsJDASe67meyiForaNVvnwiOHkvTitwJRoL4QEHwsbQ/GK1LfGwWYR4/WNmd++T/WPAF14geaNF4vMa3bl/q47JE5jEe0ZAPP5IPFYLAYul5uauv9Zl/SvTpLNGGwGi6jenEVoF0AKVtdlf1DFh5ZLZJ4xJbpc1atDioWOytz5kVPvtaTSHWRF1LAAw1tjOt9Ryd/0xI4zhSSFmFdWiyLHlYMVxViQYe+9W19uGOHGg=; 5:EY+sbA4jyowLkbXUp3eu6AOliMfYyrCIcqJoNWncYX0nsgdFNit88I6/bdno5E7VbBssWkbhNCZVAz5Nsx/wUpOYJ4UFpSuKwXRL+sZBbu4ystj09bhlV38V4ADiJ2+AT8BNi+X/yRH3U8m7t+YWsw==; 24:Xo4FqR3y3iRgHKQG1KUcPZpBarq+pmNO6DpNYrLum2zeBdwTtsH6l7kLPNDjIKciFjy35DNjuIS9Y/qmK66Ej1CTCchRkshRvnNneQc179M=; 7:tUkyU0+aEuM6bscXtLZgbXWhTXit/nhzevlY/cfIKlEL2NsHzf5xvsWa9xZZmGs/tRHHXIHWVOgb/W83Rnc9npSqHgXq0u9VSRI6GhhYTMFTdwy+W27pBdrRbkUlxxQYYWnIV2hSbx/Aw2PSxhwCGDgT1gforpIXgvphUlC9BWtJAuwdShFGml1bUyI+v8RrvLMZWYGI1wMHB5boW5NxE4sShvt3em47JXpKJKygaAnsS4tx0Ld+7otiuupXArNq x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1763; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1763; x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(13464003)(199003)(102836003)(3846002)(10400500002)(6116002)(33656002)(92566002)(86362001)(586003)(66066001)(87936001)(8936002)(3280700002)(81166006)(81156014)(101416001)(11100500001)(68736007)(9686002)(106116001)(106356001)(2906002)(5002640100001)(76176999)(54356999)(50986999)(97736004)(5001770100001)(122556002)(2950100001)(2900100001)(19580405001)(19580395003)(107886002)(189998001)(305945005)(7846002)(7736002)(7696003)(5003600100003)(74316002)(3660700001)(2501003)(8676002)(99286002)(15975445007)(76576001)(77096005)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2016 16:45:06.5452 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 Archived-At: Subject: Re: [Cbor] cbor.me and Appendix G.4 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:45:11 -0000 SGkgQ2Fyc3Rlbg0KDQpXaWxsIGl0IGJlIHBvc3NpYmxlIHRvIGFkZCBzdXBwb3J0IGZvciBjb21t ZW50cyAoYXMgZGVmaW5lZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1jb3JlLXlhbmctY2Jvci0wMiNzZWN0aW9uLTIuMSkgdG8gImNib3IubWUiIC4gQ29tbWVudHMg YXJlIGFscmVhZHkgc3VwcG9ydGVkIG9uIHRoZSByaWdodCBjb2x1bW4sIHRoZSB0YXNrIGlzIHRv IGFkZCB0aGUgc2FtZSBmdW5jdGlvbmFsaXR5IG9uIHRoZSBsZWZ0IGNvbHVtbi4NCg0KUmVnYXJk cywNCk1pY2hlbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ0JPUiBbbWFp bHRvOmNib3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhcnN0ZW4gQm9ybWFubg0K U2VudDogTW9uZGF5LCBKdWx5IDE4LCAyMDE2IDQ6MjYgQU0NClRvOiBjYm9yQGlldGYub3JnDQpT dWJqZWN0OiBbQ2Jvcl0gY2Jvci5tZSBhbmQgQXBwZW5kaXggRy40DQoNCmNib3IubWUgaGFzIGJl ZW4gdXAgYWdhaW4gbm93IGZvciBhIHdoaWxlLg0KDQpEdWUgdG8gcG9wdWxhciByZXF1ZXN0ICh0 aGFua3MsIFBldGVyISksIGl0IG5vdyBzdXBwb3J0cyB0aGUgaW5wdXQgb2YgaGV4L29jdC9iaW5h cnkgbnVtYmVycyBhcyBwZXIgQXBwZW5kaXggRy40IG9mIENEREwgKGhleCBmbG9hdHMgYXJlIHN0 aWxsIHRvIGRvLCB0aG91Z2gpLg0KDQpHZXQgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eSBvbiB5b3Vy IGxhcHRvcHMgdmlhDQoNCglnZW0gdXBkYXRlIGNib3ItZGlhZw0KDQoobm93IHZlcnNpb24gMC4y LjIpIG9yLCBpZiB5b3UgZGlkbid0IGhhdmUgaXQgeWV0DQoNCglnZW0gaW5zdGFsbCBjYm9yLWRp YWcNCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KQ0JPUiBtYWlsaW5nIGxpc3QNCkNCT1JAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Jvcg0K From nobody Wed Jul 20 15:56:15 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BEA12B00F for ; Wed, 20 Jul 2016 15:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 UuHM2Y4JtA_v for ; Wed, 20 Jul 2016 15:56:12 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DAD412B00D for ; Wed, 20 Jul 2016 15:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=439; q=dns/txt; s=iport; t=1469055372; x=1470264972; h=date:from:to:subject:message-id:mime-version; bh=TmSgDqI5+noKIQKUida2GxFve41y2f7ppl6gXNAGukk=; b=h2u6F+86eOYuZenkJtiLPg4Tdi7wnJ3B7YnVN6FPN8ZdvCTwhpG+ZKBZ U2HrIned9h2KWxnNUfJEZ+wzsjWrrKKngjqr8TuFLuGhs5OiQ3JrXZaPO 589fje4KOMLWWkBbt3RpIXun+UeOmdnHB5upDo/MgB9jS3iB9rnbYxNvV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAgBnAJBX/5BdJa1dgz9WfLZQgg+Be?= =?us-ascii?q?yaCLRCEbjgUAQEBAQEBAWUnhR17NAWJDA6fXZ1FAQsBJI1DgkCFDwWPAIomhhO?= =?us-ascii?q?IRQqBVgFjjH0CkCAeNoQTHDIBhyYBAQE?= X-IronPort-AV: E=Sophos;i="5.28,396,1464652800"; d="scan'208";a="300199112" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 22:56:11 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u6KMuBsw017416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jul 2016 22:56:11 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6KMuACZ017035 for ; Wed, 20 Jul 2016 15:56:10 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6KMuAA8017034 for cbor@ietf.org; Wed, 20 Jul 2016 15:56:10 -0700 Date: Wed, 20 Jul 2016 15:56:10 -0700 From: Toerless Eckert To: cbor@ietf.org Message-ID: <20160720225610.GZ7377@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Subject: [Cbor] CBOR: Check out the competition! X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 22:56:14 -0000 http://www.oss.com/asn1/resources/standards-use-asn1.html http://www.itu.int/ITU-T/asn1/uses/index.htm 2002: https://www.sans.org/reading-room/whitepapers/protocols/snmp-potential-asn1-vulnerabilities-912 2016: http://arstechnica.com/security/2016/07/software-flaw-puts-mobile-phones-and-networks-at-risk-of-complete-takeover/ And to put the question for CBOR into Clint Eastwood words: "Do you feel lucky Punk?" ;-) From nobody Thu Jul 21 08:38:14 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2903912D5F7; Thu, 21 Jul 2016 08:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Np19zpTcJdH9; Thu, 21 Jul 2016 08:38:11 -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 88E9212D520; Thu, 21 Jul 2016 08:38:11 -0700 (PDT) Received: from [192.168.122.112] (unknown [98.176.33.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 86297509B6; Thu, 21 Jul 2016 11:38:10 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jul 2016 08:38:09 -0700 Message-Id: To: cbor@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: core@ietf.org Subject: [Cbor] CBOR Tag for IP address X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:38:13 -0000 Hello: Shall there be a CBOR tag for IP addresses? I would propose that one tag be allocated, <>; right now I=E2=80=99m = thinking in the range of 40-255. If the byte string is 4 bytes, then = it=E2=80=99s IPv4; if it=E2=80=99s 16 bytes, it=E2=80=99s IPv6; if = it=E2=80=99s > 16, then it=E2=80=99s some IPvFuture. And if people need arrays or maps of IP addresses, we can talk about = that too. Not sure if people need subnet masks. I recall that some hallway discussions in the past 2-3 IETFs suggested = that it should be done. However, it has not been added to = draft-bormann-cbor-tags-oid, or to any other draft, yet. I have been reviewing draft-ietf-core-yang-cbor-02, and noted that while = the example in Section 5.12 is =E2=80=9Cinteresting=E2=80=9D, it=E2=80=99s= quite inefficient for ipv4-address and ipv6-address. Rather than having = huge regular expression patterns, you can just transmit the octets, you = know, the way that IP itself transmits them. Regards, Sean= From nobody Thu Jul 21 08:48:47 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DD312D627; Thu, 21 Jul 2016 08:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmmsVzbOat0K; Thu, 21 Jul 2016 08:48:44 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 3918312B031; Thu, 21 Jul 2016 08:48:44 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id f93so65663404lfi.2; Thu, 21 Jul 2016 08:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=zNRPDOitRFiTRTiAfzAvLTSiEpor1G1SvSwTtVeMtEY=; b=FCfiNJf1SQa/dNj19VYDb6BY5q05fabN/EZAOKVRRJhq0+bFFscUkZZnqoZe0SHt2b A/JytPUh2Xo2BvOBvmPv0juaVDJbAAUVnfIn6T4Vyc0r1mj0cAMO1EXiDBqsr9pMFUW8 em5IPXCbwYG2KBo7HIx8sPpX6gtpQcR77NB6r/xRFN2Vv50eYoMRdG2V0kVINqgn2Fui 8jerTorgHqzOYJN92jDIyjdGtUW36aX0yvrVmFgZ47D3f5zoJIytk8/cie2CJwDNgKck ixB8kDG5059xbTOBhHm7MoeVlK5fGFydiJeD5O+grs0y3eoPK5eGwT3ARbGlRaxQe+kO AERg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=zNRPDOitRFiTRTiAfzAvLTSiEpor1G1SvSwTtVeMtEY=; b=KZfFLwieu4JuW9Ltu3/7886lTgFkVB2BoHhtmIo0wyz7MJMiLtWCnA+SbV0lS/OHVB xfNxgwI8rnIr51t3isq/vO977FkRldBsUJ89ifQCPemTnvgqijYltpWOWK+AJ6AOPcLA B3nUd04glYmEbg+yABYDS1aV+TopBaMX2mBqeqxMjMmPfkaeU1wAmlccvOghjiTeooNy ji7bcdtH+MKwA8CdqtT+o6r/swBUzL3UeBg8hQ/IViFKqg7INl7/IQ0wtLgyr0Ch/RaM jiS2FzTCZS93jsKeCNQsS3DVhA/MnfZ3E4+vUjQ6mydiT7MB92+c4ZdJDDCthHXCRvw+ 5vXg== X-Gm-Message-State: ALyK8tJrz7KJSe304ZssFCxUFTIJwD/lUB/0q5NYnXzAUUJNfrLd+OlWB2PsQHU5wOBC9g== X-Received: by 10.25.82.202 with SMTP id g193mr11290910lfb.141.1469116122066; Thu, 21 Jul 2016 08:48:42 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:28cc:dc4c:9703:6781? ([2001:67c:370:160:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g72sm1991456lji.43.2016.07.21.08.48.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 08:48:40 -0700 (PDT) To: Sean Leonard , cbor@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <203f3a1e-ad86-40c8-8c7b-fb723c7d5cd1@gmail.com> Date: Fri, 22 Jul 2016 03:48:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: core@ietf.org Subject: Re: [Cbor] CBOR Tag for IP address X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:48:46 -0000 I'm not convinced. I have running code based on (in CDDL) ipv4-address =3D bytes .size 4 ipv6-address =3D bytes .size 16 with no particular problems. Brian On 22/07/2016 03:38, Sean Leonard wrote: > Hello: >=20 > Shall there be a CBOR tag for IP addresses? >=20 > I would propose that one tag be allocated, <>; right now I=E2=80=99m= thinking in the range of 40-255. If the byte string is 4 bytes, then it=E2= =80=99s IPv4; if it=E2=80=99s 16 bytes, it=E2=80=99s IPv6; if it=E2=80=99= s > 16, then it=E2=80=99s some IPvFuture. >=20 > And if people need arrays or maps of IP addresses, we can talk about th= at too. Not sure if people need subnet masks. >=20 > I recall that some hallway discussions in the past 2-3 IETFs suggested = that it should be done. However, it has not been added to draft-bormann-c= bor-tags-oid, or to any other draft, yet. >=20 > I have been reviewing draft-ietf-core-yang-cbor-02, and noted that whil= e the example in Section 5.12 is =E2=80=9Cinteresting=E2=80=9D, it=E2=80=99= s quite inefficient for ipv4-address and ipv6-address. Rather than having= huge regular expression patterns, you can just transmit the octets, you = know, the way that IP itself transmits them. >=20 > Regards, >=20 > Sean > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Thu Jul 21 08:52:20 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B1212D665; Thu, 21 Jul 2016 08:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs7s6bTRxVFL; Thu, 21 Jul 2016 08:52:13 -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 C257512D69A; Thu, 21 Jul 2016 08:52:13 -0700 (PDT) Received: from [192.168.122.112] (unknown [98.176.33.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9C7D150A87; Thu, 21 Jul 2016 11:52:12 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: <203f3a1e-ad86-40c8-8c7b-fb723c7d5cd1@gmail.com> Date: Thu, 21 Jul 2016 08:52:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <203f3a1e-ad86-40c8-8c7b-fb723c7d5cd1@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: cbor@ietf.org, core@ietf.org Subject: Re: [Cbor] CBOR Tag for IP address X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:52:15 -0000 Semantic tagging is (almost) always optional. Whether you =E2=80=9Cneed=E2= =80=9D it or not depends on the higher-level protocol. RFC 7049: 2.4. Optional Tagging of Items In CBOR, a data item can optionally be preceded by a tag to give it additional semantics while retaining its structure. =20 ... Their primary purpose in this specification is to define common data types such as dates. A secondary purpose is to allow optional tagging when the decoder is a generic CBOR decoder that might be able to benefit from hints about the content of items. So actually, I think your example proves the point...of how easy it is = to specify IP addresses in a 4 or 16 byte string. Sean > On Jul 21, 2016, at 8:48 AM, Brian E Carpenter = wrote: >=20 > I'm not convinced. I have running code based on (in CDDL) >=20 > ipv4-address =3D bytes .size 4 > ipv6-address =3D bytes .size 16 >=20 > with no particular problems. >=20 > Brian >=20 >=20 > On 22/07/2016 03:38, Sean Leonard wrote: >> Hello: >>=20 >> Shall there be a CBOR tag for IP addresses? >>=20 >> I would propose that one tag be allocated, <>; right now I=E2=80=99m= thinking in the range of 40-255. If the byte string is 4 bytes, then = it=E2=80=99s IPv4; if it=E2=80=99s 16 bytes, it=E2=80=99s IPv6; if = it=E2=80=99s > 16, then it=E2=80=99s some IPvFuture. >>=20 >> And if people need arrays or maps of IP addresses, we can talk about = that too. Not sure if people need subnet masks. >>=20 >> I recall that some hallway discussions in the past 2-3 IETFs = suggested that it should be done. However, it has not been added to = draft-bormann-cbor-tags-oid, or to any other draft, yet. >>=20 >> I have been reviewing draft-ietf-core-yang-cbor-02, and noted that = while the example in Section 5.12 is =E2=80=9Cinteresting=E2=80=9D, = it=E2=80=99s quite inefficient for ipv4-address and ipv6-address. Rather = than having huge regular expression patterns, you can just transmit the = octets, you know, the way that IP itself transmits them. >>=20 >> Regards, >>=20 >> Sean >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >>=20 >=20 From nobody Thu Jul 21 09:31:21 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A8712D7A0; Thu, 21 Jul 2016 09:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75kFX_WvPgfY; Thu, 21 Jul 2016 09:31:17 -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 BF62112D79C; Thu, 21 Jul 2016 09:31:17 -0700 (PDT) Received: from [192.168.122.112] (unknown [98.176.33.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 51CB650A84; Thu, 21 Jul 2016 12:31:16 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: <203f3a1e-ad86-40c8-8c7b-fb723c7d5cd1@gmail.com> Date: Thu, 21 Jul 2016 09:31:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <203f3a1e-ad86-40c8-8c7b-fb723c7d5cd1@gmail.com> To: cbor@ietf.org, core@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Cbor] CBOR Tag for IP address X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 16:31:19 -0000 Actually I should have rearranged my original e-mail. It was not meant = to advocate for a particular outcome, but rather to generate discussion = of a perceived problem and a possible solution: Shall there be a CBOR tag for IP addresses? I recall that some hallway discussions in the past 2-3 IETFs suggested = that it should be done. However, it has not been added to = draft-bormann-cbor-tags-oid, or to any other draft, yet. I have been reviewing draft-ietf-core-yang-cbor-02, and noted that while = the example in Section 5.12 is =E2=80=9Cinteresting=E2=80=9D, it=E2=80=99s= quite inefficient for ipv4-address and ipv6-address. Rather than having = huge regular expression patterns, you can just transmit the octets, you = know, the way that IP itself transmits them. One proposal could go as follows: one tag be allocated, <>; right now = I=E2=80=99m thinking in the range of 40-255. If the byte string is 4 = bytes, then it=E2=80=99s IPv4; if it=E2=80=99s 16 bytes, it=E2=80=99s = IPv6; if it=E2=80=99s > 16, then it=E2=80=99s some IPvFuture. And if people need arrays or maps of IP addresses, we can talk about = that too. Not sure if people need subnet masks. (=46rom the CoRE/YANG perspective, typedef-ing IP addresses differently = could also work.) Regards, Sean= From nobody Thu Jul 21 10:44:21 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBF712B071; Thu, 21 Jul 2016 10:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 OZNjVALB82ke; Thu, 21 Jul 2016 10:44:18 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B0C512B006; Thu, 21 Jul 2016 10:44:18 -0700 (PDT) Received: from dhcp-9a4a.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:494c:7923:68d9:f968]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 80D4A1720AF; Thu, 21 Jul 2016 19:44:14 +0200 (CEST) Message-ID: <579109EC.1030209@tzi.org> Date: Thu, 21 Jul 2016 19:44:12 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Sean Leonard References: <203f3a1e-ad86-40c8-8c7b-fb723c7d5cd1@gmail.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: cbor@ietf.org, core@ietf.org Subject: Re: [Cbor] [core] CBOR Tag for IP address X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 17:44:20 -0000 We might take a page out of draft-ietf-anima-grasp-06.txt ipv4-address = bytes .size 4 ipv6-address = bytes .size 16 Grüße, Carsten Sean Leonard wrote: > Actually I should have rearranged my original e-mail. It was not meant to advocate for a particular outcome, but rather to generate discussion of a perceived problem and a possible solution: > > > Shall there be a CBOR tag for IP addresses? > > I recall that some hallway discussions in the past 2-3 IETFs suggested that it should be done. However, it has not been added to draft-bormann-cbor-tags-oid, or to any other draft, yet. > > I have been reviewing draft-ietf-core-yang-cbor-02, and noted that while the example in Section 5.12 is “interesting”, it’s quite inefficient for ipv4-address and ipv6-address. Rather than having huge regular expression patterns, you can just transmit the octets, you know, the way that IP itself transmits them. > > > One proposal could go as follows: one tag be allocated, <>; right now I’m thinking in the range of 40-255. If the byte string is 4 bytes, then it’s IPv4; if it’s 16 bytes, it’s IPv6; if it’s > 16, then it’s some IPvFuture. > > And if people need arrays or maps of IP addresses, we can talk about that too. Not sure if people need subnet masks. > > (From the CoRE/YANG perspective, typedef-ing IP addresses differently could also work.) > > Regards, > > Sean > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From nobody Thu Jul 21 12:30:02 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1786912D77D; Thu, 21 Jul 2016 12:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlZVafdC1hKz; Thu, 21 Jul 2016 12:29:59 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 2159D12D694; Thu, 21 Jul 2016 12:29:59 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id x25so49918426qtx.2; Thu, 21 Jul 2016 12:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cE2EwR+ScgMDKxf1ZSCtr/8YJ+WJM+9RVFnDPpHQjlI=; b=08qU50DNQ2odZiHrI7IKXjQ5eaLoJ8Y3+vTkkZh/AxK81yUTi2TvWvC2LCIP845taf OWtLbGf3bFStevoFCTT/Mu6Nco0RBtmI1bWTnFTeppLj9WPNgN4JmIGbP6Dcoe2h5r7G UuM03zwUCENpRDMCClUAhdx0YsvTooeZdsN+aYWp5UUC15jYSmefoBTf8/BWpOY5UTMt YnFRnLzVqm8ks0Dw6dol0bQk7g/Be7lulTMMnvoQwqX6fxLnWkFysKU0JCfwpOdmjoks jmhZrboLU2xTC/OdQxMyXwSTJqbmybjaXHsr3/ZmjMK6D8CwbQG9NyBgUQwBgjG81xyP 5Nfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=cE2EwR+ScgMDKxf1ZSCtr/8YJ+WJM+9RVFnDPpHQjlI=; b=EcIYMOjxMV0nYdGfpiSkiWRas/pa2wD09R0rAhhbrzrfegVmOKknUQK/gvLhHKqbSx XjumlcGp1YA9mVpo8uK6pAnsNho575P55b3pM51OoSKZjPplPL79ctR8Mi2zKscqRn4z Xi9m3h8Fh9rwGMjZ5blMcGtn0APNqGzNqS4ZJkow5ZNdJed0i8X/yF8zJAXWRHzIfL5n wCN6dAXOYT0TqolfWsbHH8AAPTtYGViuXKah1MnCa8WuT7Jy49ZWu3ykOiOp9/jJYjNd yaxaKzts+uAJZcMct7k0XE5xX098mVaXIrhL9pxvG5X/mT9TtDD5eYC+FEBa2NMxOsy/ RjvA== X-Gm-Message-State: ALyK8tISiv1Hz8YXGo9npfGx9rIQO9oX4b8QO5o9Mf85QUE3ub9DRQ+5LlmuKjpUI6EAvg== X-Received: by 10.200.37.252 with SMTP id f57mr86323977qtf.68.1469129398042; Thu, 21 Jul 2016 12:29:58 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:28cc:dc4c:9703:6781? ([2001:67c:370:136:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id j7sm5193701qkf.11.2016.07.21.12.29.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 12:29:57 -0700 (PDT) To: Carsten Bormann , Sean Leonard References: <203f3a1e-ad86-40c8-8c7b-fb723c7d5cd1@gmail.com> <579109EC.1030209@tzi.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <2afa99ae-303c-280d-1d2f-53b2c3ecb531@gmail.com> Date: Fri, 22 Jul 2016 07:30:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <579109EC.1030209@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cbor@ietf.org, core@ietf.org Subject: Re: [Cbor] [core] CBOR Tag for IP address X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 19:30:01 -0000 On 22/07/2016 05:44, Carsten Bormann wrote: > We might take a page out of draft-ietf-anima-grasp-06.txt > ipv4-address =3D bytes .size 4 > ipv6-address =3D bytes .size 16 And to expand a bit on that, once one of those has emerged from cbor.loads() as for example b, you do something like this (in Python): if len(b) =3D=3D 16: a =3D ipaddress.IPv6Address(b) elif len(b) =3D=3D 4: a =3D ipaddress.IPv4Address(b) else: # error handling and what you'd feed into cbor.dumps() would be a.packed The advantage of having a defined tag and appropriate support in dumps() and loads() would be to avoid that if statement and simply use an object of class ipaddress. Brian >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > Sean Leonard wrote: >> Actually I should have rearranged my original e-mail. It was not meant= to advocate for a particular outcome, but rather to generate discussion = of a perceived problem and a possible solution: >> >> >> Shall there be a CBOR tag for IP addresses? >> >> I recall that some hallway discussions in the past 2-3 IETFs suggested= that it should be done. However, it has not been added to draft-bormann-= cbor-tags-oid, or to any other draft, yet. >> >> I have been reviewing draft-ietf-core-yang-cbor-02, and noted that whi= le the example in Section 5.12 is =E2=80=9Cinteresting=E2=80=9D, it=E2=80= =99s quite inefficient for ipv4-address and ipv6-address. Rather than hav= ing huge regular expression patterns, you can just transmit the octets, y= ou know, the way that IP itself transmits them. >> >> >> One proposal could go as follows: one tag be allocated, <>; right n= ow I=E2=80=99m thinking in the range of 40-255. If the byte string is 4 b= ytes, then it=E2=80=99s IPv4; if it=E2=80=99s 16 bytes, it=E2=80=99s IPv6= ; if it=E2=80=99s > 16, then it=E2=80=99s some IPvFuture. >> >> And if people need arrays or maps of IP addresses, we can talk about t= hat too. Not sure if people need subnet masks. >> >> (From the CoRE/YANG perspective, typedef-ing IP addresses differently = could also work.) >> >> Regards, >> >> Sean >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> >=20 From nobody Mon Jul 25 02:45:13 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FC912D74F for ; Mon, 25 Jul 2016 02:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxUZX3WdudYq for ; Mon, 25 Jul 2016 02:45:10 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 61A3012D74D for ; Mon, 25 Jul 2016 02:45:10 -0700 (PDT) Received: from [10.9.112.178] (unknown [208.43.82.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 264D122E261; Mon, 25 Jul 2016 05:45:02 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2016 02:45:00 -0700 Message-Id: To: draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: cbor@ietf.org Subject: [Cbor] Regular Expression comments on draft-greevenbosch-appsawg-cbor-cddl-08 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 09:45:12 -0000 While reviewing draft-greevenbosch-appsawg-cbor-cddl-08, I wanted to = make a couple of comments. Not sure if this is the best place for them? = These comments are specific to regular expression issues. The annotation .regexp (B.1.3.) seems quite powerful; however, it is = underspecified. =E2=80=9CPCRE regular expression=E2=80=9D is kind of = redundant, since the RE in PCRE means =E2=80=9Cregular expression=E2=80=9D= . Actually PCRE is a superset of standardized regular expression = languages (such as those found in the POSIX or ECMA-262 aka Javascript = standards), which significantly limits interoperability to those who = actually import the PCRE engine itself. This may not be feasible for = constrained devices. Overall this needs to be better specified. While we = are at it, =E2=80=9C.regexp=E2=80=9D is not as appropriate as = =E2=80=9C.regex=E2=80=9D, because PCRE itself exclusively refers to it = as =E2=80=9Cregex=E2=80=9D, never =E2=80=9Cregexp=E2=80=9D. (POSIX also = refers to it as =E2=80=9Cregex=E2=80=9D, e.g, . =E2=80=9CRegExp=E2= =80=9D is a JavaScript/ECMAScript term. I strongly disagree with the regular expression being =E2=80=9Canchored = on both sides=E2=80=9D. This means that ^ and $ are at the ends of every = RE. This is bad because if you don=E2=80=99t want anchoring, or if you = want mixed anchoring and non-anchoring, it is very non-intuitive to = achieve. I shall use the verbs =E2=80=9Cmoor=E2=80=9D and =E2=80=9Cunmoor=E2= =80=9D to refer to adding and removing anchors ^ and $ (nouns). Suppose you want mixed anchoring, namely, the expression: foo|^bar$ means that the tstr can contain =E2=80=9Cfoo=E2=80=9D anywhere, or must = be comprised of exactly =E2=80=9Cbar=E2=80=9D. If you assume anchors, then you have: (^)foo|^bar($) First of all, this leads to unintended behavior because you can actually = sandwich unmoored expressions in between large quantities of = alternatives. How do you unmoor the first half of the alternative? It is proposed that = you use .*, as: (^).*foo|^bar($) .* is greedy; you may not want that behavior: it may be extremely = inefficient. Furthermore, .* sometimes consumes newlines and sometimes = does not, depending on switches. We see that ^bar is explicitly moored = on the left end, but not explicitly on the right end (it=E2=80=99s = implicit). But if we switched the order of the alternatives, it would be = bar$ instead (with the ^ implicit). It could be said that | unmoors the = expressions. This is confusing. Overall, the production after .regex(p) should just be a standard = (Perl-compatible) regular expression, sandwiched between / / and with = optional modifiers, namely i (case-insensitive) tacked on to the end. = (Currently, optional modifiers such as i have way to be expressed in the = draft-08 syntax.) This is how JavaScript does it, even though JavaScript = isn=E2=80=99t Perl, and it works great. Syntax highlighters can figure = out that it=E2=80=99s a RE and do the right coloring things with it too. I also propose a binary regex(p) annotation (=E2=80=9C.bregex=E2=80=9D = ?) on bstr, whose domain is the octets \0 - \xFF, in contrast to tstr, = whose domain include the Unicode scalar values in \0 - \u{10FFFF}. (Compare with the =E2=80=9Cbregex=E2=80=9D provided in = draft-bormann-cbor-tags-oid.) Best regards, Sean= From nobody Mon Jul 25 03:02:18 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC6F12B01B for ; Mon, 25 Jul 2016 03:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWQSn7rNTNt1 for ; Mon, 25 Jul 2016 03:02:14 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 A3C3C12D5AE for ; Mon, 25 Jul 2016 03:02:14 -0700 (PDT) Received: from [10.9.112.178] (unknown [208.43.82.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 146CC22E259; Mon, 25 Jul 2016 06:02:12 -0400 (EDT) From: Sean Leonard Content-Type: multipart/alternative; boundary="Apple-Mail=_94227082-2E6E-44C5-B7F6-D3E343C41C38" Date: Mon, 25 Jul 2016 03:02:11 -0700 Message-Id: To: draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: cbor@ietf.org Subject: [Cbor] comments x2 on draft-greevenbosch-appsawg-cbor-cddl-08 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 10:02:16 -0000 --Apple-Mail=_94227082-2E6E-44C5-B7F6-D3E343C41C38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 While reviewing draft-greevenbosch-appsawg-cbor-cddl-08, I wanted to = make a couple of comments. Not sure if this is the best place for them? = These comments are =E2=80=9Csome other issues=E2=80=9D. I am deeply suspicious of the .cbor and .cborseq annotations in B.1.4. I = understand why they are there, because specification designers may be = tempted to carve out a hole in a spec to put =E2=80=9Cwhatever=E2=80=9D, = as has happened with a lot of specs using ASN.1. Please, don=E2=80=99t = do that. The proper thing to say is in the current grammar is =E2=80=9Cany= =E2=80=9D, not something contained in a bstr. Don=E2=80=99t go down that = bad ASN.1 path; this is not the 1980s. See the late John Larmouth=E2=80=99= s book, ASN.1 Complete (available for free, just Google it) on why = it=E2=80=99s a bad idea. By dumping CBOR in a byte string, you=E2=80=99re = going back to ASN.1 BER, and not even the fixed up ASN.1 BER of today, = we=E2=80=99re talking about the BER from the 1980s. (Think about length = specifiers, which CBOR goes out of its way to incorporate as the number = of items, not the number of encoded bytes.) :( People like optionality when they can=E2=80=99t decide which alternative = is better, but this muddles the grammar. Currently =E2=80=9Cbstr=E2=80=9D = and =E2=80=9Cbytes=E2=80=9D are synonyms; =E2=80=9Ctstr=E2=80=9D and = =E2=80=9Ctext=E2=80=9D are also synonyms. Please pick one. I like = =E2=80=9Cbstr=E2=80=9D and =E2=80=9Ctstr=E2=80=9D because RFC 7049 = specifically calls them =E2=80=9Ca byte string=E2=80=9D and =E2=80=9Ca = text string=E2=80=9D, respectively. They are strings, not arrays per-se. The examples are correct according to the grammar, but are also = (literally) quite artificial. It would be better to replace the = nonsensical keys/values with keys/values that are more plausible. I am = happy to volunteer to change some of the examples. I have read through this draft several times, and remain utterly = confused by the choice of terms =E2=80=9Crecord=E2=80=9D and = =E2=80=9Cstruct=E2=80=9D. The term =E2=80=9Cstruct=E2=80=9D is a very = famous C/C++ thing, where the items are laid out positionally in memory = according to the struct definition. The names are not stored in memory = or serialized. However, this draft uses =E2=80=9Cstruct=E2=80=9D for = maps where the map keys are serialized, and =E2=80=9Crecord=E2=80=9D for = arrays with =E2=80=9Cpositionally defined semantics=E2=80=9D. This is = super-confusing for me as a C/C++ programmer. I really think that =E2=80=9Cstruct=E2=80=9D should be the term used for = a CBOR array whose elements have different, positionally defined = semantics. As for =E2=80=9Crecord=E2=80=9D, I suppose it could go either way, but = whenever I use the term =E2=80=9Crecord=E2=80=9D, I think of the = *fields* comprising the record, as having *field names*, so the *field = names* ought to be serialized along with the *field values*. I would = prefer a stronger search of the literature before settling upon = =E2=80=9Crecord=E2=80=9D. Honestly =E2=80=9Cmap=E2=80=9D is the most straightforward term to use, = but I understand that this draft is trying to distinguish the CBOR map = from the semantic things that are serialized as CBOR maps (also, = contrast needs to be provided with =E2=80=9Ctable=E2=80=9D, which is a = map). =E2=80=9CObject=E2=80=9D is not too bad (where each name/value = pair is a =E2=80=9Cmember=E2=80=9D), seeing as how they are mirroring = JSON objects. I am okay with =E2=80=9Cvector=E2=80=9D. =E2=80=9Clist=E2=80=9D could be = used but I suppose that =E2=80=9Cvector=E2=80=9D is better since the = items in the array are 0-indexed. I am only somewhat okay with =E2=80=9Ctable=E2=80=9D. The problem is = that =E2=80=9Ctable=E2=80=9D tends to imply multiple columns (more than = 2) as well as multiple rows; the meaning shades somewhat too close for = comfort into =E2=80=9Crecord=E2=80=9D. Something about =E2=80=9Ctuples=E2=80= =9D would probably be better, such as =E2=80=9Cpairs=E2=80=9D or = =E2=80=9C2-tuples=E2=80=9D. Other terms to consider would be = =E2=80=9Cdictionary=E2=80=9D, =E2=80=9Cdefinition list=E2=80=9D, or = =E2=80=9Cassociation=E2=80=9D. Personally I would go with =E2=80=9Cpairs=E2= =80=9D or =E2=80=9Cdictionary=E2=80=9D. Best regards, Sean= --Apple-Mail=_94227082-2E6E-44C5-B7F6-D3E343C41C38 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 While = reviewing draft-greevenbosch-appsawg-cbor-cddl-08, I wanted to make = a couple of comments. Not sure if this is the best place for them? These = comments are =E2=80=9Csome other issues=E2=80=9D.


I am deeply suspicious of = the .cbor and .cborseq annotations in B.1.4. I understand why they are = there, because specification designers may be tempted to carve out a = hole in a spec to put =E2=80=9Cwhatever=E2=80=9D, as has happened with a = lot of specs using ASN.1. Please, don=E2=80=99t do that. The proper = thing to say is in the current grammar is =E2=80=9Cany=E2=80=9D, not = something contained in a bstr. Don=E2=80=99t go down that bad ASN.1 = path; this is not the 1980s. See the late John Larmouth=E2=80=99s book, = ASN.1 Complete (available for free, just Google it) on why it=E2=80=99s = a bad idea. By dumping CBOR in a byte string, you=E2=80=99re going back = to ASN.1 BER, and not even the fixed up ASN.1 BER of today, we=E2=80=99re = talking about the BER from the 1980s. (Think about length specifiers, = which CBOR goes out of its way to incorporate as the number of items, = not the number of encoded bytes.) :(


People like optionality when they can=E2=80=99t = decide which alternative is better, but this muddles the grammar. = Currently =E2=80=9Cbstr=E2=80=9D and =E2=80=9Cbytes=E2=80=9D are = synonyms; =E2=80=9Ctstr=E2=80=9D and =E2=80=9Ctext=E2=80=9D are also = synonyms. Please pick one. I like =E2=80=9Cbstr=E2=80=9D and =E2=80=9Ctstr= =E2=80=9D because RFC 7049 specifically calls them =E2=80=9Ca byte = string=E2=80=9D and =E2=80=9Ca text string=E2=80=9D, respectively. They = are strings, not arrays per-se.


The examples are correct according to the = grammar, but are also (literally) quite artificial. It would be better = to replace the nonsensical keys/values with keys/values that are more = plausible. I am happy to volunteer to change some of the = examples.


I have read through this draft several times, and remain = utterly confused by the choice of terms =E2=80=9Crecord=E2=80=9D and = =E2=80=9Cstruct=E2=80=9D. The term =E2=80=9Cstruct=E2=80=9D is a very = famous C/C++ thing, where the items are laid out positionally in memory = according to the struct definition. The names are not stored in memory = or serialized. However, this draft uses =E2=80=9Cstruct=E2=80=9D for = maps where the map keys are serialized, and =E2=80=9Crecord=E2=80=9D for = arrays with =E2=80=9Cpositionally defined semantics=E2=80=9D. This is = super-confusing for me as a C/C++ programmer.

I really think that = =E2=80=9Cstruct=E2=80=9D should be the term used for a CBOR array whose = elements have different, positionally defined semantics.

As for =E2=80=9Crecord=E2=80=9D= , I suppose it could go either way, but whenever I use the term = =E2=80=9Crecord=E2=80=9D, I think of the *fields* comprising the record, = as having *field names*, so the *field names* ought to be serialized = along with the *field values*. I would prefer a stronger search of the = literature before settling upon =E2=80=9Crecord=E2=80=9D.

Honestly =E2=80=9Cmap=E2=80=9D= is the most straightforward term to use, but I understand that this = draft is trying to distinguish the CBOR map from the semantic things = that are serialized as CBOR maps (also, contrast needs to be provided = with =E2=80=9Ctable=E2=80=9D, which is a map). =E2=80=9CObject=E2=80=9D = is not too bad (where each name/value pair is a =E2=80=9Cmember=E2=80=9D),= seeing as how they are mirroring JSON objects.

I am okay with = =E2=80=9Cvector=E2=80=9D. =E2=80=9Clist=E2=80=9D could be used but I = suppose that =E2=80=9Cvector=E2=80=9D is better since the items in the = array are 0-indexed.

I am only somewhat okay with =E2=80=9Ctable=E2=80=9D. The = problem is that =E2=80=9Ctable=E2=80=9D tends to imply multiple columns = (more than 2) as well as multiple rows; the meaning shades somewhat too = close for comfort into =E2=80=9Crecord=E2=80=9D. Something about = =E2=80=9Ctuples=E2=80=9D would probably be better, such as =E2=80=9Cpairs=E2= =80=9D or =E2=80=9C2-tuples=E2=80=9D. Other terms to consider would be = =E2=80=9Cdictionary=E2=80=9D, =E2=80=9Cdefinition list=E2=80=9D, or = =E2=80=9Cassociation=E2=80=9D. Personally I would go with =E2=80=9Cpairs=E2= =80=9D or =E2=80=9Cdictionary=E2=80=9D.

Best regards,

Sean
= --Apple-Mail=_94227082-2E6E-44C5-B7F6-D3E343C41C38-- From nobody Thu Jul 28 18:11:32 2016 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C84612D7D0 for ; Thu, 28 Jul 2016 18:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUZ4fLepAQRG for ; Thu, 28 Jul 2016 18:11:29 -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 13A5E12B00A for ; Thu, 28 Jul 2016 18:11:29 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4AF4E509B8; Thu, 28 Jul 2016 21:11:23 -0400 (EDT) To: Carsten Bormann , glenn_engel@keysight.com, cbor@ietf.org References: <04EFF12F483FA149B07653989B86861F217A069F@wcosexch01k.cos.is.keysight.com> <577416B1.3090308@tzi.org> <577ED54A.3050705@tzi.org> From: Sean Leonard Message-ID: <3306456d-17d4-dfbb-9940-e304f5f73c61@seantek.com> Date: Thu, 28 Jul 2016 18:09:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <577ED54A.3050705@tzi.org> Content-Type: multipart/alternative; boundary="------------5FE44958F6A864FD81B23898" Archived-At: Cc: draft-jroatch-cbor-tags@tools.ietf.org Subject: [Cbor] draft-jroatch-cbor-tags-04 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 01:11:31 -0000 This is a multi-part message in MIME format. --------------5FE44958F6A864FD81B23898 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/7/2016 3:18 PM, Carsten Bormann wrote: > Carsten Bormann wrote: >> glenn_engel@keysight.com wrote: >>>> Hi, has there been any discussion of where these two proposals fit with the existing TypedArray proposal? >> > I now went ahead and submitted > > https://tools.ietf.org/html/draft-jroatch-cbor-tags-04 > > For diffs, see: > > https://www.ietf.org/rfcdiff?url2=draft-jroatch-cbor-tags-04 > > Thank you, Glenn! Greetings: I have reviewed draft-jroatch-cbor-tags-04. Here is my feedback. Section 2. Typed Arrays Okay; makes sense. However, the mismatch between [u/s]int8 and binary16 is jarring. It would seem a lot better if uint16/sint16/binary16..uint128/sint128/binary128. I checked the Typed Array Specification as part of this review. It's true that 128-bit integers aren't part of web Typed Arrays. But then again, neither 64-bit integers nor 128-bit floats are part of Typed Arrays either. Future-proof this thing: align ints and floats! __int128 is a thing in GCC, and there is a typedef in MSVC. It's also not uncommon for graphics and GPU-related work. In contrast, I don't see a lot of value to tagging an array as uint8...that would be called a plain old "byte string" by any definition of the term. Nevertheless, I see value in sint8 and possibly some minor value in the clamping thing. In view of these comments, I propose: +-----------+--------+--------+-----------+ | Length ll | uint | sint | float | +-----------+--------+--------+-----------+ | (-1) | uint8 | sint8 | N/A | | 0 | uint16 | sint16 | binary16 | | 1 | uint32 | sint32 | binary32 | | 2 | uint64 | sint64 | binary64 | | 3 | uint128| sint128| binary128 | +-----------+--------+--------+-----------+ Table 1: Length values For the case of uint8 and sint8, I propose that you allocate four tags in approximately 0b001111_c_s, where c = clamped, and s = signed. That would be tags 0x3C - 0x3F in the current formulation. If you want parity with the bit positions in the other tags, I would propose rearranging the 0b010_f_s_e_ll to: 0b010_ll_f_e_s (where when ll is -1, we are talking 0b00111, and f is always 1, even though it's not a float). I would also like to suggest using tags in the 2-byte space, such as 0x0220-0x0237 (or 0x021C - 0x0237). I suppose that you have thought of this already. I am less concerned about low-byte "pollution"; it has more to do with the need for expansion of typed arrays in the future. If you want to add binary256, int256, etc., you will have more guaranteed room to reserve and grow if you take a chunk out of the 2-byte space. Also, "since these typed arrays may carry significant amounts of data", the length of the tag is going to be dwarfed by each payload. One extra byte does not seem to hurt in this case. Ultimately, it is up to you, the authors. Section 3. No complaints. Looks all right. Tags 40 and 41 are okay with me. Sections 4-6. See prior comments (in case need to update consistent with Section 2). I do have a comment on the #6.xxx() CDDL in Section 5, but I guess that comment needs to be addressed to "the CDDL people", so I'll save that. Section 7. Security Considerations Shall improper byte string length be considered a coding error, be filled in with zeroes, or be considered undefined behavior? There is a risk that if you have a byte string that is tagged as containing binary64 or int64, if the byte string is not a multiple of 8 bytes, you are going to chomp on garbage memory. You could say "assume all bits are 0"; this will result in +0 according to IEEE 754 (which apparently compares equal to -0, but is a distinct bit pattern). It seems risky to me. There is an argument that you might want to permit "sparse arrays" where large quantities of the arrays are zeroes, which can result in optimal transmission by cutting off those bytes. But if you are relying on the length of the byte string, all you can save is (x / 8 - 1) bytes (where x is the bit length of the integers/floats). I consider an irregular-length array to be a coding error; that is with my security hat on. Regards, Sean --------------5FE44958F6A864FD81B23898 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/7/2016 3:18 PM, Carsten Bormann wrote:
Carsten Bormann wrote:

glenn_engel@keysight.com wrote:

Hi, has there been any discussion of where these two proposals fit with the existing TypedArray proposal?


I now went ahead and submitted

https://tools.ietf.org/html/draft-jroatch-cbor-tags-04

For diffs, see:

https://www.ietf.org/rfcdiff?url2=draft-jroatch-cbor-tags-04

Thank you, Glenn!

Greetings:

I have reviewed draft-jroatch-cbor-tags-04. Here is my feedback.

Section 2. Typed Arrays

Okay; makes sense. However, the mismatch between [u/s]int8 and binary16 is jarring. It would seem a lot better if uint16/sint16/binary16..uint128/sint128/binary128.

I checked the Typed Array Specification as part of this review. It's true that 128-bit integers aren't part of web Typed Arrays. But then again, neither 64-bit integers nor 128-bit floats are part of Typed Arrays either. Future-proof this thing: align ints and floats! __int128 is a thing in GCC, and there is a typedef in MSVC. It's also not uncommon for graphics and GPU-related work.

In contrast, I don't see a lot of value to tagging an array as uint8...that would be called a plain old "byte string" by any definition of the term. Nevertheless, I see value in sint8 and possibly some minor value in the clamping thing.

In view of these comments, I propose:

                +-----------+--------+--------+-----------+
                | Length ll | uint   | sint   | float     |
                +-----------+--------+--------+-----------+
                | (-1)      | uint8  | sint8  | N/A       |
                | 0         | uint16 | sint16 | binary16  |
                | 1         | uint32 | sint32 | binary32  |
                | 2         | uint64 | sint64 | binary64  |
                | 3         | uint128| sint128| binary128 |
                +-----------+--------+--------+-----------+

                          Table 1: Length values

For the case of uint8 and sint8, I propose that you allocate four tags in approximately 0b001111_c_s,
where c = clamped, and s = signed. That would be tags 0x3C - 0x3F in the current formulation. If you want parity with the bit positions in the other tags, I would propose rearranging the 0b010_f_s_e_ll to:
0b010_ll_f_e_s

(where when ll is -1, we are talking 0b00111, and f is always 1, even though it's not a float).

I would also like to suggest using tags in the 2-byte space, such as 0x0220-0x0237 (or 0x021C - 0x0237). I suppose that you have thought of this already. I am less concerned about low-byte "pollution"; it has more to do with the need for expansion of typed arrays in the future. If you want to add binary256, int256, etc., you will have more guaranteed room to reserve and grow if you take a chunk out of the 2-byte space. Also, "since these typed arrays may carry significant amounts of data", the length of the tag is going to be dwarfed by each payload. One extra byte does not seem to hurt in this case. Ultimately, it is up to you, the authors.

Section 3.
No complaints. Looks all right. Tags 40 and 41 are okay with me.

Sections 4-6.
See prior comments (in case need to update consistent with Section 2).

I do have a comment on the #6.xxx() CDDL in Section 5, but I guess that comment needs to be addressed to "the CDDL people", so I'll save that.

Section 7. Security Considerations
Shall improper byte string length be considered a coding error, be filled in with zeroes, or be considered undefined behavior? There is a risk that if you have a byte string that is tagged as containing binary64 or int64, if the byte string is not a multiple of 8 bytes, you are going to chomp on garbage memory. You could say "assume all bits are 0"; this will result in +0 according to IEEE 754 (which apparently compares equal to -0, but is a distinct bit pattern). It seems risky to me. There is an argument that you might want to permit "sparse arrays" where large quantities of the arrays are zeroes, which can result in optimal transmission by cutting off those bytes. But if you are relying on the length of the byte string, all you can save is (x / 8 - 1) bytes (where x is the bit length of the integers/floats).

I consider an irregular-length array to be a coding error; that is with my security hat on.

Regards,

Sean
--------------5FE44958F6A864FD81B23898--