From nobody Mon Jun 12 11:20:17 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 C139612EB56 for ; Mon, 12 Jun 2017 11:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxJX5zB5UzvZ for ; Mon, 12 Jun 2017 11:20:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 F1D4412957F for ; Mon, 12 Jun 2017 11:20:13 -0700 (PDT) Received: from [192.168.91.196] ([80.92.114.129]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LkBPy-1dqmYo2xZq-00c5ua; Mon, 12 Jun 2017 20:20:04 +0200 To: cbor@ietf.org Cc: Kepeng Li , Hannes Tschofenig From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Mon, 12 Jun 2017 20:20:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:EK0ToAjxGKYQSWK/0/arOOv9Co9LSmkG88hSjxDKSYvw8bO/cVK bc9Pmldkl7ayw0OtJ0rL3DdwC/f7iqH95h0eD07uvs6/zWeVNvQZmPWUiLLLX5w69I7zRdU VojJlwzGAmePXX8apJRB77dSQI3fwOgFkWH9hsvge1PiPvlle9jxC+KToyUBxUSRGGPDHEh jcYHqIhJHYJwU1blnXinA== X-UI-Out-Filterresults: notjunk:1;V01:K0:c2LqygW1+HA=:TIwKsxjdkXAgG0T4wphju5 TAaEtxfD3Qphw1I1Iw8NQ0QYpe2D2II+ovmYN8ADaVXQT9nl2Zlal2HvH7bF7BeGf3oeTGoyw qSknk1yEfTUSsz9aRrbEtvrdFC8bZFJAm7QgS9SPC7wRFbXkbOGzWhVc4rqdxgobCi6ihrQ1Y SzAZ82YsjoV0tZVfNkZo7uViNs3QFmawUAq8OKWRIAl4Fs+DEwr6FMUo4fZx2C/jE75yUp0mH jzezZi5BlveDepIAtFrhz2ySjNWcJpT2PqT3BHz3rEoPDv5KsOxRzXcidxKP4vh5P1pL0c5vo oT4vMO7Tf+Z4nYNZ6Q9h+eumJMZkVwdJp0wpo/mY2J260HmsvNS8v5fiMlfhzYzuoqV2c1ue8 imAXgvtd+LeUGZ8NKJngp3nzwy1dhkoL6+ghAcx6w3r42uDOFlkGca9qdN9X5iwdm/M7IHrXL LnxzrygkSlyY1wpgZXEn8BGJEJWT5IZR63QJoUBbNo9DLiS4MlLZQjJwzmcORPas/VO1GZ4KR UYTpdYqUsxy5ySvUDPgmZXLCDNq21eNH5tvJ2pLGKNh+Asl5Du0UBd/5tk5eVhLxfA4M5wXnl g0EJfmQsOg+k8eipg1qZzxGSiJfRSd18+AJ1JyKfyIsz9QMiapLNFyuTNLqawUodAB3htfHZ0 Nj16mqZMGQ1Xyl1/UNHl8f/5TluplyepooupRmqPa4qRvtfbJ64ya7bbutJx85DvAaf2l6+Hh qtvKUoCHW3fgcP5Pg31i38e/iabfjAIqRJ+vOHcZxrJLQVx6GJpt3YxcfnpgTYZmzClWA6Xv1 Nf5AA7V Archived-At: Subject: [Cbor] Potential uses of PoP keys in CBOR Web Tokens (CWTs) 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: Mon, 12 Jun 2017 18:20:16 -0000 Hi all, RFC 7800 defines how to communicate Proof of Possession (PoP) keys for JSON Web Tokens (JWTs) [RFC 7519]. The CBOR Web Token (CWT) draft-ietf-ace-cbor-web-token spec defines the CBOR/COSE equivalent of the JSON/JOSE JWT spec. The ACE working group is planning to also define a CBOR/COSE equivalent of RFC 7800 and is interested in knowing how you might use CBOR proof-of-possession keys for CWTs. Please drop us a message if you are using CBOR PoP keys for CWTs. We would like to learn more about your usage. Ciao Hannes & Kepeng From nobody Fri Jun 16 16:56:44 2017 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB520129540; Fri, 16 Jun 2017 16:56:36 -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 nM8JdYlIWS9x; Fri, 16 Jun 2017 16:56:35 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB18F12953F; Fri, 16 Jun 2017 16:56:34 -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 v5GNuUVG003810; Sat, 17 Jun 2017 01:56:30 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (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 3wqHMd617KzDK04; Sat, 17 Jun 2017 01:56:29 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 519350189.453979-e3b2d906e8bab442948f66a848a5cc63 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 17 Jun 2017 01:56:29 +0200 Message-Id: <2DB0474F-900D-42FD-B2C5-F61F396B751C@tzi.org> To: ace , core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Cbor] Constrained Node/Network Cluster @ IETF99: DRAFT AGENDA 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, 16 Jun 2017 23:56:37 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF99. Remember that there is still quite some potential for changes. ACE people are going to miss DISPATCH (ARTAREA) again -- not sure if there would have been be any discussions relevant to Constrained Nodes/Networks in ARTAREA, but it doesn't make sense with this scheduling. CORE people will miss both ANIMA and (in-week) ICNRG. ROLL people will miss SAAG, ouch. And LPWAN is on the second half of QUIC. All no disasters, AFAICS, but not pain-free. All times are CEST (UTC+0200). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- T2TRG -- ICNRG -- Hackathon (including various interops) MONDAY, July 17, 2017 0930-1200 Morning Session I Congress H III ART dispatch Dispatch WG - 09:30-11:30 Grand Hilton BR INT 6man IPv6 Maintenance WG Congress H I SEC *** ace Authentication and Authorization for = Constrained Environments WG Congress H III SEC curdle CURves, Deprecating and a Little more = Encryption WG - 11:30-12:00 1330-1530 Afternoon Session I Karlin I/II INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Grand Hilton BR INT homenet Home Networking WG 1550-1720 Afternoon Session II Karlin I/II ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Berlin/Brussels SEC tokbind Token Binding WG 1740-1840 Afternoon Session III Athens/Barcel. RTG babel Babel routing protocol WG Grand Hilton BR TSV tsvarea Transport Area Open Meeting TUESDAY, July 18, 2017 0930-1200 Morning Session I Congress H II OPS v6ops IPv6 Operations WG Congress H I TSV taps Transport Services WG 1330-1530 Afternoon Session I Grand Hilton BR IRTF*** t2trg Thing-to-Thing Berlin/Brussels SEC oauth Web Authorization Protocol WG Congress H I TSV tsvwg Transport Area Working Group WG 1550-1750 Afternoon Session II Karlin I/II INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Congress H I IRTF cfrg Crypto Forum WEDNESDAY, July 19, 2017 0930-1200 Morning Session I Congress H I ART *** core Constrained RESTful Environments WG Karlin I/II IRTF icnrg Information-Centric Networking Congress H III OPS anima Autonomic Networking Integrated Model = and Approach WG Congress H II RTG rtgarea Routing Area Open Meeting Grand Hilton BR SEC tls Transport Layer Security WG Karlin III TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1330-1500 Afternoon Session I Grand Hilton BR ART httpbis Hypertext Transfer Protocol WG Congress H III IRTF panrg Proposed Path Aware Networking Congress H II RTG ideas IDentity Enabled Networks BOF 1520-1650 Afternoon Session II Grand Hilton BR ART httpbis Hypertext Transfer Protocol WG THURSDAY, July 20, 2017 0930-1200 Morning Session I Grand Hilton BR INT intarea Internet Area Working Group WG Congress H II IRTF maprg Measurement and Analysis for Protocols Congress H I RTG detnet Deterministic Networking WG 1330-1530 Afternoon Session I Berlin/Brussels ART ice Interactive Connectivity Establishment = WG Grand Hilton BR OPS v6ops IPv6 Operations WG Karlin I/II RTG *** roll Routing Over Low power and Lossy = networks WG Congress H III SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Athens/Barcel. INT ipwave IP Wireless Access in Vehicular = Environments WG Grand Hilton BR TSV quic QUIC WG 1810-1910 Afternoon Session III Berlin/Brussels ART uta Using TLS in Applications WG Athens/Barcel. INT *** lwig Light-Weight Implementation Guidance WG Karlin I/II RTG bier Bit Indexed Explicit Replication WG Congress H III TSV tsvwg Transport Area Working Group WG FRIDAY, July 21, 2017 0930-1130 Morning Session I Berlin/Brussels INT dnssd Extensions for Scalable DNS Service = Discovery WG Karlin I/II INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Karlin III SEC oauth Web Authorization Protocol WG Grand Hilton BR TSV quic QUIC WG 1150-1320 Afternoon Session II Congress H III ART *** core Constrained RESTful Environments WG Grand Hilton BR SEC acme Automated Certificate Management = Environment WG From nobody Sun Jun 18 04:42: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 59FC61205D3 for ; Sun, 18 Jun 2017 04:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 HByvgAeTgLfs for ; Sun, 18 Jun 2017 04:42:34 -0700 (PDT) Received: from smtp26.services.sfr.fr (smtp26.services.sfr.fr [93.17.128.10]) (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 1FCED120454 for ; Sun, 18 Jun 2017 04:42:34 -0700 (PDT) Received: from [192.168.1.4] (87.52.134.77.rev.sfr.net [77.134.52.87]) by msfrf2622.sfr.fr (SMTP Server) with ESMTP id 350671C00086E for ; Sun, 18 Jun 2017 13:42:32 +0200 (CEST) Received: from [192.168.1.4] (87.52.134.77.rev.sfr.net [77.134.52.87]) (Authenticated sender: christophe.lohr@cegetel.net) by msfrf2622.sfr.fr (SMTP Server) with ESMTPA for ; Sun, 18 Jun 2017 13:42:32 +0200 (CEST) Authentication-Results: sfr.fr; auth=pass (PLAIN) smtp.auth=christophe.lohr@cegetel.net To: cbor@ietf.org From: Christophe Lohr Message-ID: Date: Sun, 18 Jun 2017 13:42:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 X-sfr-mailing: LEGIT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Cbor] CDDL Prelude 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: Sun, 18 Jun 2017 11:42:36 -0000 Hello, I have questions about the CDDL prelude. First, why not defining uint8/16/32/64 such as for floatXX: uint8 = #0.24 uint16 = #0.25 uint32 = #0.26 uint64 = #0.27 nint8 = #1.24 nint16 = #1.25 nint32 = #1.26 nint64 = #1.27 Then, how to restrict data to (in)definite structures? Can I write the following? bstr_indefinite = #2.31 bytes_indefinite = bstr_indefinite tstr_indefinite = #3.31 text_indefinite = tstr_indefinite bstr_definite8 = #2.24 bstr_definite16 = #2.25 bstr_definite32 = #2.26 bstr_definite64 = #2.27 bstr_definite = bstr_definite8 / bstr_definite16 / bstr_definite32 / bstr_definite64 bytes_definite = bstr_definite tstr_definite8 = #2.24 tstr_definite16 = #2.25 tstr_definite32 = #2.26 tstr_definite64 = #2.27 tstr_definite = tstr_definite8 / tstr_definite16 / tstr_definite32 / tstr_definite64 text_definite = tstr_definite Best regards Christophe From nobody Sun Jun 18 05:01: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 0138F12702E for ; Sun, 18 Jun 2017 05:01:02 -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 g8mRsPpqGosR for ; Sun, 18 Jun 2017 05:01:00 -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 5797D1243FE for ; Sun, 18 Jun 2017 05:00:59 -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 v5IC0tpf017572; Sun, 18 Jun 2017 14:00:55 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (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 3wrCP30kvvzDKBf; Sun, 18 Jun 2017 14:00:55 +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: Sun, 18 Jun 2017 14:00:54 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 519480054.36297-84be08df09c88e9bb026bdd576bea993 Content-Transfer-Encoding: quoted-printable Message-Id: <4E0F514B-B688-4DD7-B478-C3A27C1591F8@tzi.org> References: To: Christophe Lohr X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] CDDL Prelude 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: Sun, 18 Jun 2017 12:01:02 -0000 On Jun 18, 2017, at 13:42, Christophe Lohr = wrote: >=20 > Hello, > I have questions about the CDDL prelude. >=20 > First, why not defining uint8/16/32/64 such as for floatXX: >=20 > uint8 =3D #0.24 > uint16 =3D #0.25 > uint32 =3D #0.26 > uint64 =3D #0.27 Hi Christophe, it is not clear to me what you think the semantics of uint64 would be. = Should this be a data model level restriction? Or are you further = trying to restrict the serialization? Or, in other words, if the value = of a uint64 is 42, would 0x182a be an allowable serialization, or are = you really trying to specify that the serialization should be = 0x1b000000000000002a? CDDL actually is a data model level specification language. As a matter = of style, a data model specification should not restrict the = serialization choices that an implementation may make. (We haven=E2=80=99t really solved the issue for float16/32/64 yet, = either. I think this would be a good discussion to have. Much of the need for this comes from the few implementers that don=E2=80=99= t want to add the 10 lines of code needed to decode float16. But there = also is a genuine need to be specific about float32 vs. float64 support = in a format =E2=80=94 except that it isn=E2=80=99t clear that this is = needed at the data model level.) I could very well imagine that uint32 =3D uint .size 4 might be a rule that you might want to use in your specification. Should that rule be in the prelude? So, I summary, yes, this is a discussion that we should continue to a = conclusion. > Then, how to restrict data to (in)definite structures? Similar to the above, it is not really the data model that should be = making these serialization choices. I think it might be useful to have a (simple) mechanism to control the = small number of serialization choices that CBOR provides at a global = level. I don=E2=80=99t think we want to attach serialization controls = to the individual types of CDDL, but I would be interested in learning = why we should. In that vein, I=E2=80=99m curious what kind of application you had in = mind when you wrote your message. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jun 18 13:28:35 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 8ED591293E3 for ; Sun, 18 Jun 2017 13:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] 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 TPVJrO6mtrkw for ; Sun, 18 Jun 2017 13:28:32 -0700 (PDT) Received: from smtp26.services.sfr.fr (smtp26.services.sfr.fr [93.17.128.163]) (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 0161F126FB3 for ; Sun, 18 Jun 2017 13:28:31 -0700 (PDT) Received: from [192.168.1.4] (87.52.134.77.rev.sfr.net [77.134.52.87]) by msfrf2606.sfr.fr (SMTP Server) with ESMTP id 517D81C000435 for ; Sun, 18 Jun 2017 22:28:29 +0200 (CEST) Received: from [192.168.1.4] (87.52.134.77.rev.sfr.net [77.134.52.87]) (Authenticated sender: christophe.lohr@cegetel.net) by msfrf2606.sfr.fr (SMTP Server) with ESMTPA for ; Sun, 18 Jun 2017 22:28:28 +0200 (CEST) Authentication-Results: sfr.fr; auth=pass (PLAIN) smtp.auth=christophe.lohr@cegetel.net To: cbor@ietf.org References: <4E0F514B-B688-4DD7-B478-C3A27C1591F8@tzi.org> From: Christophe Lohr Message-ID: <309e2037-f97a-c240-58aa-01231893563c@cegetel.net> Date: Sun, 18 Jun 2017 22:28:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4E0F514B-B688-4DD7-B478-C3A27C1591F8@tzi.org> X-sfr-mailing: LEGIT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] CDDL Prelude 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: Sun, 18 Jun 2017 20:28:34 -0000 On 18/06/2017 14:00, Carsten Bormann wrote: >> uint64 =3D #0.27 > it is not clear to me what you think the semantics of uint64 would be. = Should this be a data model level restriction? Or are you further tryin= g to restrict the serialization? Or, in other words, if the value of a u= int64 is 42, would 0x182a be an allowable serialization, or are you reall= y trying to specify that the serialization should be 0x1b000000000000002a= ? Yes, this is what I had in mind: uint64 should accept 0x1b000000000000002a and reject 0x182a Well, to be honest I have no concrete example where forcing the size of a "uint" could be mandatory. It's not a big deal to do a "cast" if I receive 8 bits where I would expected 64. However, I wonder if in some circumstances having a stable predictable size of data would be more important than having the smallest possible or of an indefinite size. So, how to specify it? Or maybe this is a bad question. A concern for dinosaurs of computer-science. ;-) > CDDL actually is a data model level specification language. As a matte= r of style, a data model specification should not restrict the serializat= ion choices that an implementation may make. Hum. There is a data description model level, and a data presentation model level. The concern of CDDL is the former. Does I understand well? > I could very well imagine that > uint32 =3D uint .size 4 > might be a rule that you might want to use in your specification. > Should that rule be in the prelude? I thought that this means "up to 4 bytes". I had wished to express "exactly 4". >> Then, how to restrict data to (in)definite structures? > Similar to the above, it is not really the data model that should be ma= king these serialization choices. > I think it might be useful to have a (simple) mechanism to control the = small number of serialization choices that CBOR provides at a global leve= l. I don=E2=80=99t think we want to attach serialization controls to the= individual types of CDDL, but I would be interested in learning why we s= hould. Let's consider a communication protocol based on CBOR messages that are specified with CDDL. The emitter is free to produce definite or indefinite bytes/text strings. Maybe, the choice is equal from its point of view. However, from the receiver point of view, decoding indefinite bytes/text strings introduces an extra cost: it needs an additional buffer to assemble chunks. (Think about constrained nodes.) So, in this example, this would be preferable if the protocol specification has a mean to restrict things to the use of definite data serialization. Well, from the other side, if one wants to specify serialization constraints, the CDDL syntax may need some extensions. For instance if I want to specify a rule where the litteral "42" must be presented into a uint64, I would need some syntax for "casting": answer =3D (#0.27)(42) ??? > In that vein, I=E2=80=99m curious what kind of application you had in m= ind when you wrote your message. Here are my first tests with cbor: https://svn.telecom-bretagne.eu/svn-public/xAAL/code/C/branches/testing_c= bor/ and a global presentation of the project: http://recherche.telecom-bretagne.eu/xaal/ Best regards Christophe From nobody Sun Jun 18 18:08: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 B1205126B6D for ; Sun, 18 Jun 2017 18:08:37 -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 9sOIDqKfDsKf for ; Sun, 18 Jun 2017 18:08:35 -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 87AF81200C5 for ; Sun, 18 Jun 2017 18:08:35 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id f185so41361485pgc.0 for ; Sun, 18 Jun 2017 18:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zj7ekb5jKMeC5gJ94YJS7niIDNqS118akNB4t56xB7s=; b=r3EY9tR26OnwHSVhDdVHDpmpsV5thiJLNoOXKdiFyf0KJpG4hIi+vnBqVOW25q0eR5 rvxActp6oC2Y4IlYuW8WHybnw9wu91j2bOfWIWJvc0tw3GnhmC8DRF54W4zLj9HQjklQ 1WZIMmnM+ujW/Pxj1SkMwX2acJm5tOsyGwzmkrybUVy5qIckLIRasS+hUhauxJ3XS0d+ YlyLJWF9Rx7VaCZBKPEc2rjPQjQ03bdBAlXbFL9JPgBvXuggTB8OnHoNf2ptiqJbsG3z QNuI0zSPY/dQ3AqVtYC1abMWwd1IdCnh6u5lcKlOddx1XCatv9JPVr8m1mXkCdg103HF Zr0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=zj7ekb5jKMeC5gJ94YJS7niIDNqS118akNB4t56xB7s=; b=Wke1+Xrx1lo6rL1sCz+1VE/LVXFaZNuUZf1GdCYt2Amid4oHS0s9mZynyL6DzGjVR0 yzsaO59JVf6Mfp7iRpmYYX6V64goZfa9WQzJ+rAGGmKnufql8SxyWC3JBVcnx2/CT1zL jrfxr+6ZFI/fCXbd9Q9YmAhhgMtFk5w9JBZ99Kdl6giv8iFJ5Sk/jq6PYTMGCRcN9vCp DoE2/OPZjt1clylWhW+UKytrYXDWIdgS8uwEnzUtDIR2EyJTzzv7nivxofHf3tCrk/a5 GcOjG9lkrAMghcEwk4HkgTuyKxVN9wZMPnHr2R9jG3WRtEgUYZds3N7bCy45VcpbIrYp yVvg== X-Gm-Message-State: AKS2vOwbyYGqYXVNHeD7/EdJXp28RGH99qYNerHApbBKI4oedPYZQ8Qw It3UXvObEqUKhI7j X-Received: by 10.98.21.9 with SMTP id 9mr22265978pfv.46.1497834514737; Sun, 18 Jun 2017 18:08:34 -0700 (PDT) Received: from [10.100.109.213] (125-236-219-163.adsl.xtra.co.nz. [125.236.219.163]) by smtp.gmail.com with ESMTPSA id m11sm17419348pfg.85.2017.06.18.18.08.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Jun 2017 18:08:34 -0700 (PDT) To: cbor@ietf.org References: <4E0F514B-B688-4DD7-B478-C3A27C1591F8@tzi.org> <309e2037-f97a-c240-58aa-01231893563c@cegetel.net> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4965c9ff-a6a4-fa7b-76ce-d5ec90ec271a@gmail.com> Date: Mon, 19 Jun 2017 13:08:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <309e2037-f97a-c240-58aa-01231893563c@cegetel.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] CDDL Prelude 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: Mon, 19 Jun 2017 01:08:38 -0000 On 19/06/2017 08:28, Christophe Lohr wrote: > On 18/06/2017 14:00, Carsten Bormann wrote: >>> uint64 =3D #0.27 >> it is not clear to me what you think the semantics of uint64 would be.= Should this be a data model level restriction? Or are you further tryi= ng to restrict the serialization? Or, in other words, if the value of a = uint64 is 42, would 0x182a be an allowable serialization, or are you real= ly trying to specify that the serialization should be 0x1b000000000000002= a? >=20 > Yes, this is what I had in mind: uint64 should accept > 0x1b000000000000002a and reject 0x182a >=20 > Well, to be honest I have no concrete example where forcing the size of= > a "uint" could be mandatory. > It's not a big deal to do a "cast" if I receive 8 bits where I would > expected 64. >=20 > However, I wonder if in some circumstances having a stable predictable > size of data would be more important than having the smallest possible > or of an indefinite size. > So, how to specify it? > Or maybe this is a bad question. A concern for dinosaurs of > computer-science. ;-) I think it depends on the programming language of the recipient, doesn't it? Suppose a field is described in CDDL as session-id =3D 0..4294967295 ;up to 32 bits (a real example) In Python, I just don't care; cbor.loads() just returns an integer and th= at's the end of it. In C, I would presumably want to store the result in a uint32_t, regardless of how the sender happens to encode it in CBOR. According to the Postel principle I should accept any CBOR integer encoding as long as the result is < 4294967296. There's no type mismatch from a high level view, so the computer scientist in me doesn't worry. Brian >=20 >> CDDL actually is a data model level specification language. As a matt= er of style, a data model specification should not restrict the serializa= tion choices that an implementation may make. >=20 > Hum. There is a data description model level, and a data presentation > model level. The concern of CDDL is the former. Does I understand well?= >=20 >> I could very well imagine that >> uint32 =3D uint .size 4 >> might be a rule that you might want to use in your specification. >> Should that rule be in the prelude? >=20 > I thought that this means "up to 4 bytes". > I had wished to express "exactly 4". >=20 >=20 >>> Then, how to restrict data to (in)definite structures? >> Similar to the above, it is not really the data model that should be m= aking these serialization choices. >> I think it might be useful to have a (simple) mechanism to control the= small number of serialization choices that CBOR provides at a global lev= el. I don=E2=80=99t think we want to attach serialization controls to th= e individual types of CDDL, but I would be interested in learning why we = should. >=20 > Let's consider a communication protocol based on CBOR messages that are= > specified with CDDL. > The emitter is free to produce definite or indefinite bytes/text > strings. Maybe, the choice is equal from its point of view. > However, from the receiver point of view, decoding indefinite bytes/tex= t > strings introduces an extra cost: it needs an additional buffer to > assemble chunks. (Think about constrained nodes.) >=20 > So, in this example, this would be preferable if the protocol > specification has a mean to restrict things to the use of definite data= > serialization. >=20 >=20 > Well, from the other side, if one wants to specify serialization > constraints, the CDDL syntax may need some extensions. For instance if = I > want to specify a rule where the litteral "42" must be presented into a= > uint64, I would need some syntax for "casting": > answer =3D (#0.27)(42) ??? >=20 >=20 >> In that vein, I=E2=80=99m curious what kind of application you had in = mind when you wrote your message. >=20 > Here are my first tests with cbor: > https://svn.telecom-bretagne.eu/svn-public/xAAL/code/C/branches/testing= _cbor/ >=20 > and a global presentation of the project: > http://recherche.telecom-bretagne.eu/xaal/ >=20 > Best regards > Christophe >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Mon Jun 19 06:44: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 0C4AD131472 for ; Mon, 19 Jun 2017 06:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCOJDgiRNJnO for ; Mon, 19 Jun 2017 06:43:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FDB913146F for ; Mon, 19 Jun 2017 06:43:56 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 761C64A011; Mon, 19 Jun 2017 09:45:24 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A0B986380F; Mon, 19 Jun 2017 09:43:55 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org cc: Christophe Lohr In-Reply-To: <309e2037-f97a-c240-58aa-01231893563c@cegetel.net> References: <4E0F514B-B688-4DD7-B478-C3A27C1591F8@tzi.org> <309e2037-f97a-c240-58aa-01231893563c@cegetel.net> 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] CDDL Prelude 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: Mon, 19 Jun 2017 13:43:59 -0000 --=-=-= Content-Type: text/plain Christophe Lohr wrote: > On 18/06/2017 14:00, Carsten Bormann wrote: >>> uint64 = #0.27 >> it is not clear to me what you think the semantics of uint64 would be. >Should this be a data model level restriction? Or are you further >trying to restrict the serialization? Or, in other words, if the value >of a uint64 is 42, would 0x182a be an allowable serialization, or are >you really trying to specify that the serialization should be >0x1b000000000000002a? > Yes, this is what I had in mind: uint64 should accept > 0x1b000000000000002a and reject 0x182a I think that this is reasonable. 1) Having a consistent representative is critical if signing an object. 2) If the size of the packets changes based upon the content (particularly when it will encrypted), then it is often possible to derive information based upon the size. It may be better to pad the result rather than make every item be exactly 64-bits, but that's a decision for the designer, not CDDL. > Well, to be honest I have no concrete example where forcing the size of > a "uint" could be mandatory. > It's not a big deal to do a "cast" if I receive 8 bits where I would > expected 64. > However, I wonder if in some circumstances having a stable predictable > size of data would be more important than having the smallest possible > or of an indefinite size. > So, how to specify it? > Or maybe this is a bad question. A concern for dinosaurs of > computer-science. ;-) I think that it's a reasonable thing to ask. > Let's consider a communication protocol based on CBOR messages that are > specified with CDDL. > The emitter is free to produce definite or indefinite bytes/text > strings. Maybe, the choice is equal from its point of view. > However, from the receiver point of view, decoding indefinite bytes/text > strings introduces an extra cost: it needs an additional buffer to > assemble chunks. (Think about constrained nodes.) It's also a possible DDoS. Even with definite bytes/text, one can send a "here is a 1 billion byte stream" and then just never send much. Over UDP/CoAP it may be obvious that there is more data coming, but with TCP or CoAP with-block-mode, the CBOR layer may go and allocate and just sit there. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAllH1RsACgkQgItw+93Q 3WV9DAf+LsFnY7kdi/3TrnNcIitp0HwFlkAoQ+cUWyskHfjrTEWJYfuwIP2kjfTi LebAhqAkJp5b+VNPoCnxiVbiM5ODEzl1qyBLlNES8FNlzvEXKjwPt5NfrBEC3P8x 3g47RsqRC8nnXCNyNROzAY7hBrqRwKmnxopBxEWt8vJmhS0gImwMKKkY4TLnQGDC 2FiBPZuOwzqr9WK+YjJOoLURg3/P5/G4HWxAjPizoYvbN7y36vjILyg3m/GH0LfW /9QwT2ehEsCqcmJ8uqVqUCKjhiziy6DvjkLm5gIRGEtKbzLYtir0jhQCj3kH4xNZ Stmsowi+MIAgzmSJMBufmXRLfQbgQA== =xSzC -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 19 07:51:34 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 31FAD131505 for ; Mon, 19 Jun 2017 07:51:33 -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 8Be8Kg77zFbC for ; Mon, 19 Jun 2017 07:51:30 -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 04CBD131500 for ; Mon, 19 Jun 2017 07:51:29 -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 v5JEpOuZ023932; Mon, 19 Jun 2017 16:51:24 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (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 3wrv7J12pZzDKhH; Mon, 19 Jun 2017 16:51:24 +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: <309e2037-f97a-c240-58aa-01231893563c@cegetel.net> Date: Mon, 19 Jun 2017 16:51:23 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 519576683.386795-4b94efdaac07cd0e164c16a452dfce6a Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0F514B-B688-4DD7-B478-C3A27C1591F8@tzi.org> <309e2037-f97a-c240-58aa-01231893563c@cegetel.net> To: Christophe Lohr X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] CDDL Prelude 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: Mon, 19 Jun 2017 14:51:33 -0000 On Jun 18, 2017, at 22:28, Christophe Lohr = wrote: >=20 > On 18/06/2017 14:00, Carsten Bormann wrote: >>> uint64 =3D #0.27 >> it is not clear to me what you think the semantics of uint64 would = be. Should this be a data model level restriction? Or are you further = trying to restrict the serialization? Or, in other words, if the value = of a uint64 is 42, would 0x182a be an allowable serialization, or are = you really trying to specify that the serialization should be = 0x1b000000000000002a? >=20 > Yes, this is what I had in mind: uint64 should accept > 0x1b000000000000002a and reject 0x182a >=20 > Well, to be honest I have no concrete example where forcing the size = of > a "uint" could be mandatory. > It's not a big deal to do a "cast" if I receive 8 bits where I would > expected 64. >=20 > However, I wonder if in some circumstances having a stable predictable > size of data would be more important than having the smallest possible > or of an indefinite size. Since publishing CBOR in 2013, we ran into one case so far. IIRC, this was about embedding forward pointers into a directory of = sections that are later in the data stream; you wouldn=E2=80=99t know = from the outset what length would be required for these pointers. Certainly not your garden variety use of CBOR=E2=80=A6 (The solution was to embed a fixed length byte string and encode the = pointer there.) > So, how to specify it? > Or maybe this is a bad question. A concern for dinosaurs of > computer-science. ;-) I think the question is really what style of use of CBOR should be = supported by CDDL. Or more generally, what style of use of CBOR should we foster in the = CBOR ecosystem. >=20 >> CDDL actually is a data model level specification language. As a = matter of style, a data model specification should not restrict the = serialization choices that an implementation may make. >=20 > Hum. There is a data description model level, and a data presentation > model level. The concern of CDDL is the former. Does I understand = well? >=20 >> I could very well imagine that >> uint32 =3D uint .size 4 >> might be a rule that you might want to use in your specification. >> Should that rule be in the prelude? >=20 > I thought that this means "up to 4 bytes". > I had wished to express "exactly 4". >=20 >=20 >>> Then, how to restrict data to (in)definite structures? >> Similar to the above, it is not really the data model that should be = making these serialization choices. >> I think it might be useful to have a (simple) mechanism to control = the small number of serialization choices that CBOR provides at a global = level. I don=E2=80=99t think we want to attach serialization controls = to the individual types of CDDL, but I would be interested in learning = why we should. >=20 > Let's consider a communication protocol based on CBOR messages that = are > specified with CDDL. > The emitter is free to produce definite or indefinite bytes/text > strings. Maybe, the choice is equal from its point of view. > However, from the receiver point of view, decoding indefinite = bytes/text > strings introduces an extra cost: it needs an additional buffer to > assemble chunks. (Think about constrained nodes.) >=20 > So, in this example, this would be preferable if the protocol > specification has a mean to restrict things to the use of definite = data > serialization. >=20 >=20 > Well, from the other side, if one wants to specify serialization > constraints, the CDDL syntax may need some extensions. For instance if = I > want to specify a rule where the litteral "42" must be presented into = a > uint64, I would need some syntax for "casting": > answer =3D (#0.27)(42) ??? >=20 >=20 >> In that vein, I=E2=80=99m curious what kind of application you had in = mind when you wrote your message. >=20 > Here are my first tests with cbor: > = https://svn.telecom-bretagne.eu/svn-public/xAAL/code/C/branches/testing_cb= or/ >=20 > and a global presentation of the project: > http://recherche.telecom-bretagne.eu/xaal/ >=20 > Best regards > Christophe >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 >=20 From nobody Mon Jun 19 08:02:51 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 1600413152D for ; Mon, 19 Jun 2017 08:02:49 -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 reF635fGOn05 for ; Mon, 19 Jun 2017 08:02:47 -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 E852713151B for ; Mon, 19 Jun 2017 08:02:42 -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 v5JF2cg6003165; Mon, 19 Jun 2017 17:02:39 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (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 3wrvNG5ydbzDKhh; Mon, 19 Jun 2017 17:02: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: <309e2037-f97a-c240-58aa-01231893563c@cegetel.net> Date: Mon, 19 Jun 2017 17:02:38 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 519577358.225179-03435e4d5d3ee7b93a430c75ff0ca9ac Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0F514B-B688-4DD7-B478-C3A27C1591F8@tzi.org> <309e2037-f97a-c240-58aa-01231893563c@cegetel.net> To: Christophe Lohr X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] CDDL Prelude 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: Mon, 19 Jun 2017 15:02:49 -0000 (Sorry, message escaped early =E2=80=94 one of the wonderful features of = the Mac touch bar :-) On Jun 18, 2017, at 22:28, Christophe Lohr = wrote: >=20 > On 18/06/2017 14:00, Carsten Bormann wrote: >>> uint64 =3D #0.27 >> it is not clear to me what you think the semantics of uint64 would = be. Should this be a data model level restriction? Or are you further = trying to restrict the serialization? Or, in other words, if the value = of a uint64 is 42, would 0x182a be an allowable serialization, or are = you really trying to specify that the serialization should be = 0x1b000000000000002a? >=20 > Yes, this is what I had in mind: uint64 should accept > 0x1b000000000000002a and reject 0x182a >=20 > Well, to be honest I have no concrete example where forcing the size = of > a "uint" could be mandatory. > It's not a big deal to do a "cast" if I receive 8 bits where I would > expected 64. >=20 > However, I wonder if in some circumstances having a stable predictable > size of data would be more important than having the smallest possible > or of an indefinite size. Since publishing CBOR in 2013, we ran into one case so far. IIRC, this was about embedding forward pointers into a directory of = sections that are later in the data stream; you wouldn=E2=80=99t know = from the outset what length would be required for these pointers. Certainly not your garden variety use of CBOR=E2=80=A6 (The solution was to embed a fixed length byte string and encode the = pointer there.) > So, how to specify it? > Or maybe this is a bad question. A concern for dinosaurs of > computer-science. ;-) I think the question is really what style of use of CBOR should be = supported by CDDL. Or more generally, what style of use of CBOR should we foster in the = CBOR ecosystem. >=20 >> CDDL actually is a data model level specification language. As a = matter of style, a data model specification should not restrict the = serialization choices that an implementation may make. >=20 > Hum. There is a data description model level, and a data presentation > model level. The concern of CDDL is the former. Does I understand = well? (Having worked on the original OSI "presentation layer=E2=80=9D, I = prefer not to use this term for representation, which in this case is = best termed =E2=80=9Cserialization=E2=80=9D.) Yes, that is what I wanted to say. >=20 >> I could very well imagine that >> uint32 =3D uint .size 4 >> might be a rule that you might want to use in your specification. >> Should that rule be in the prelude? >=20 > I thought that this means "up to 4 bytes=E2=80=9D. Yes. I was just saying a (data model level) shortcut for =E2=80=9Cuint = .size 4=E2=80=9D or the equivalent =E2=80=9C0..4294967295=E2=80=9D would = also be useful, and would be a plausible use of =E2=80=9Cuint32=E2=80=9D. = I wasn=E2=80=99t sure yet which one you meant. > I had wished to express "exactly 4=E2=80=9D. Right, I understand now. >>> Then, how to restrict data to (in)definite structures? >> Similar to the above, it is not really the data model that should be = making these serialization choices. >> I think it might be useful to have a (simple) mechanism to control = the small number of serialization choices that CBOR provides at a global = level. I don=E2=80=99t think we want to attach serialization controls = to the individual types of CDDL, but I would be interested in learning = why we should. >=20 > Let's consider a communication protocol based on CBOR messages that = are > specified with CDDL. > The emitter is free to produce definite or indefinite bytes/text > strings. Maybe, the choice is equal from its point of view. > However, from the receiver point of view, decoding indefinite = bytes/text > strings introduces an extra cost: it needs an additional buffer to > assemble chunks. (Think about constrained nodes.) Yes, I can understand the need making a global restriction =E2=80=9Cdo = not use indefinite [byte/text] strings=E2=80=9D. I=E2=80=99m not so sure about embedding such restrictions into the = structure description, switching it on here and off there. > So, in this example, this would be preferable if the protocol > specification has a mean to restrict things to the use of definite = data > serialization. Right now, I think the best way to do this is doing it orthogonal to = CDDL. As in (YAML syntax, sorry): canonical: no float: [16, 32, 64] indefinite-containers: yes indefinite-strings: no (I think this is about it in terms of what actually came up in real = protocols; this could even be cooked down to 6 booleans.) > Well, from the other side, if one wants to specify serialization > constraints, the CDDL syntax may need some extensions. For instance if = I > want to specify a rule where the litteral "42" must be presented into = a > uint64, I would need some syntax for "casting": > answer =3D (#0.27)(42) ??? Yes. I=E2=80=99m not sure that we want this in CDDL, but if we do, we = could use something like .and for attaching serialization constraints to = a data type. >> In that vein, I=E2=80=99m curious what kind of application you had in = mind when you wrote your message. >=20 > Here are my first tests with cbor: > = https://svn.telecom-bretagne.eu/svn-public/xAAL/code/C/branches/testing_cb= or/ >=20 > and a global presentation of the project: > http://recherche.telecom-bretagne.eu/xaal/ Will look into this at the next opportunity=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jun 19 08:14: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 49D58131525 for ; Mon, 19 Jun 2017 08:14:48 -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 CKob-N2d_zev for ; Mon, 19 Jun 2017 08:14:46 -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 64326127977 for ; Mon, 19 Jun 2017 08:14:46 -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 v5JFEga2012544; Mon, 19 Jun 2017 17:14:42 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (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 3wrvfB4p64zDKht; Mon, 19 Jun 2017 17:14:42 +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: <26743.1497879835@obiwan.sandelman.ca> Date: Mon, 19 Jun 2017 17:14:42 +0200 Cc: cbor@ietf.org, Christophe Lohr X-Mao-Original-Outgoing-Id: 519578082.052984-9f48052d1f49d3ed765c16c2c2795875 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0F514B-B688-4DD7-B478-C3A27C1591F8@tzi.org> <309e2037-f97a-c240-58aa-01231893563c@cegetel.net> <26743.1497879835@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] CDDL Prelude 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: Mon, 19 Jun 2017 15:14:48 -0000 >> Yes, this is what I had in mind: uint64 should accept >> 0x1b000000000000002a and reject 0x182a >=20 > I think that this is reasonable. > 1) Having a consistent representative is critical if signing an = object. We have canonical for that. That is a single bit you just flip, instead = of having to expose zillions of little serialization concerns in the = model. (More generally speaking, much of the simplicity of actually using CBOR = comes from decoupling the application from serialization concerns. You = have that one six-liner that handles the variants for everything in your = implementation=E2=80=A6 So that is actually the style that I would like = to support best in the CBOR ecosystem.) > 2) If the size of the packets changes based upon the content = (particularly > when it will encrypted), then it is often possible to derive = information > based upon the size. It may be better to pad the result rather than > make every item be exactly 64-bits, but that's a decision for the > designer, not CDDL. We decided against putting a form of padding into CBOR =E2=80=94 I = probably should be publishing the simple design I have for that in the = drawer. Of course you can always put the padding outside CBOR. > It's also a possible DDoS. > Even with definite bytes/text, one can send a "here is a 1 billion = byte stream" > and then just never send much. Over UDP/CoAP it may be obvious that = there is > more data coming, but with TCP or CoAP with-block-mode, the CBOR layer = may > go and allocate and just sit there. Yes, but that is more of a quality-of-implementation issue =E2=80=94 = your implementation should not blow up when it encounters = 9b1234567812345678. Not much for the data model designer to think about = here. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jun 23 17:10:07 2017 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF98B129B29; Fri, 23 Jun 2017 17:07:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: cbor@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282297.7840.16337324491760398830.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:02 -0700 Archived-At: Subject: [Cbor] cbor - Requested session has been scheduled for IETF 99 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:03 -0000 Dear Francesca Palombini, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. cbor Session 1 (1:30:00) Monday, Afternoon Session II 1550-1720 Room Name: Karlin I/II size: 150 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Concise Binary Object Representation Maintenance and Extensions Area Name: Applications and Real-Time Area Session Requester: Francesca Palombini Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: artarea dispatch core ace anima t2trg 6tisch dtn Second Priority: saag webpush sacm lpwan httpbis dots lwig roll Third Priority: detnet dnsop appsawg People who must be present: Joe Hildebrand Francesca Palombini Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jun 24 01:58:48 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 9EA86129413; Sat, 24 Jun 2017 01:58:20 -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 rCkuqw2dVVni; Sat, 24 Jun 2017 01:58:18 -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 76C331242F5; Sat, 24 Jun 2017 01:58:18 -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 v5O8wFiL024355; Sat, 24 Jun 2017 10:58:15 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (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 3wvq3V5hTTz3Z2D; Sat, 24 Jun 2017 10:58:14 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <2DB0474F-900D-42FD-B2C5-F61F396B751C@tzi.org> Date: Sat, 24 Jun 2017 10:58:14 +0200 X-Mao-Original-Outgoing-Id: 519987494.231328-86f3961023977340577980ee6f18d1af Content-Transfer-Encoding: quoted-printable Message-Id: <26509597-910C-48F9-B004-86322AD123F3@tzi.org> References: <2DB0474F-900D-42FD-B2C5-F61F396B751C@tzi.org> To: ace , core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Cbor] Constrained Node/Network Cluster @ IETF99: "FINAL" AGENDA 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, 24 Jun 2017 08:58:21 -0000 Here is my usual eclectic condensed agenda, now based on the "FINAL" AGENDA for IETF99. Compared to the last week's draft agenda, dnssd and acme were moved. (It is likely that there still will be some more changes after this "FINAL" agenda.) ACE people are going to miss DISPATCH (ARTAREA) again -- not sure if there would have been be any discussions relevant to Constrained Nodes/Networks in ARTAREA, but it doesn't make sense with this scheduling. CORE people will miss both ANIMA and (in-week) ICNRG. ROLL people will miss SAAG, ouch. And LPWAN is on the second half of QUIC. All no disasters, AFAICS, but not pain-free. All times are CEST (UTC+0200). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) SATURDAY, July 15, 2017 0900-1700 ACM, IRTF & ISOC Applied Networking Research Workshop 2017 = (Registration Required) - Athens/Barcelona 0900-1800 T2TRG Interim Meeting - Berlin/Brussels 0900-2100 IETF Hackathon - Chez Louis SUNDAY, July 16, 2017 0900-1600 T2TRG Interim Meeting - Berlin/Brussels 0900-1600 IETF Hackathon - Chez Louis 1345-1445 IEEE 802.1 Time-Sensitive Networking - Congress Hall III 1345-1445 IRTF Overview - Congress Hall I 1345-1445 TEEP Tutorial - Karlin I/II 1600-1700 Newcomers' Meet and Greet (open to Newcomers, WG chairs and = Mentors only) - Garden Terrace 1700-1900 Welcome Reception - Grand Hilton Ballroom & Foyer MONDAY, July 17, 2017 0930-1200 Morning Session I Congress H III ART dispatch Dispatch WG - 09:30-11:30 Grand Hilton BR INT 6man IPv6 Maintenance WG Congress H I SEC *** ace Authentication and Authorization for = Constrained Environments WG Congress H III SEC curdle CURves, Deprecating and a Little more = Encryption WG - 11:30-12:00 1330-1530 Afternoon Session I Karlin I/II INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Grand Hilton BR INT homenet Home Networking WG 1550-1720 Afternoon Session II Karlin I/II ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Berlin/Brussels SEC tokbind Token Binding WG 1740-1840 Afternoon Session III Athens/Barcel. RTG babel Babel routing protocol WG Grand Hilton BR TSV tsvarea Transport Area Open Meeting TUESDAY, July 18, 2017 0930-1200 Morning Session I Congress H II OPS v6ops IPv6 Operations WG Congress H I TSV taps Transport Services WG 1330-1530 Afternoon Session I Grand Hilton BR IRTF*** t2trg Thing-to-Thing Berlin/Brussels SEC oauth Web Authorization Protocol WG Congress H I TSV tsvwg Transport Area Working Group WG 1550-1750 Afternoon Session II Karlin I/II INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Congress H I IRTF cfrg Crypto Forum WEDNESDAY, July 19, 2017 0930-1200 Morning Session I Congress H I ART *** core Constrained RESTful Environments WG Karlin I/II IRTF icnrg Information-Centric Networking Congress H III OPS anima Autonomic Networking Integrated Model = and Approach WG Congress H II RTG rtgarea Routing Area Open Meeting Grand Hilton BR SEC tls Transport Layer Security WG Karlin III TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1330-1500 Afternoon Session I Grand Hilton BR ART httpbis Hypertext Transfer Protocol WG Congress H III IRTF panrg Proposed Path Aware Networking Congress H II RTG ideas IDentity Enabled Networks BOF 1520-1650 Afternoon Session II Grand Hilton BR ART httpbis Hypertext Transfer Protocol WG Athens/Barcel. INT dnssd Extensions for Scalable DNS Service = Discovery WG THURSDAY, July 20, 2017 0930-1200 Morning Session I Grand Hilton BR INT intarea Internet Area Working Group WG Congress H II IRTF maprg Measurement and Analysis for Protocols Congress H I RTG detnet Deterministic Networking WG 1330-1530 Afternoon Session I Berlin/Brussels ART ice Interactive Connectivity Establishment = WG Grand Hilton BR OPS v6ops IPv6 Operations WG Karlin I/II RTG *** roll Routing Over Low power and Lossy = networks WG Congress H III SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Athens/Barcel. INT ipwave IP Wireless Access in Vehicular = Environments WG Grand Hilton BR TSV quic QUIC WG 1810-1910 Afternoon Session III Berlin/Brussels ART uta Using TLS in Applications WG Athens/Barcel. INT *** lwig Light-Weight Implementation Guidance WG Karlin I/II RTG bier Bit Indexed Explicit Replication WG Congress H III TSV tsvwg Transport Area Working Group WG FRIDAY, July 21, 2017 0930-1130 Morning Session I Karlin I/II INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Athens/Barcel. SEC acme Automated Certificate Management = Environment WG Karlin III SEC oauth Web Authorization Protocol WG Grand Hilton BR TSV quic QUIC WG 1150-1320 Afternoon Session II Congress H III ART *** core Constrained RESTful Environments WG From nobody Sun Jun 25 06:34:51 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 3AE2A127F0E; Sun, 25 Jun 2017 06:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AkXpJhvab8G; Sun, 25 Jun 2017 06:34:48 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38B3126B6D; Sun, 25 Jun 2017 06:34:44 -0700 (PDT) X-AuditID: c1b4fb2d-54bff70000001f08-31-594fbbf22fe9 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 37.6E.07944.2FBBF495; Sun, 25 Jun 2017 15:34:43 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.352.0; Sun, 25 Jun 2017 15:34:42 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=o/oUhTUUg5mjQ42k5Wc9VWEqghhBEJmhszCdD1uFegU=; b=RJ2VYymQvbW5G1y8FSDZt3Rq+Sg3hGmlhE1Dml5QxTPCrRHhvY68p3/PgmAM7Vob5WUDXW7OHYuGWWa+apwhms2aTLoStb4D4YxUDk6VmqAhjMperWSFTlCAgUI71KrqjzILidHpZxX8+dhCXGqjsXfz6ptc4QOouAJUOnWLvoo= Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com (10.168.129.17) by HE1PR0701MB2331.eurprd07.prod.outlook.com (10.168.127.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Sun, 25 Jun 2017 13:34:41 +0000 Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com ([fe80::3c5e:24a4:ebf7:5e87]) by HE1PR0701MB2539.eurprd07.prod.outlook.com ([fe80::3c5e:24a4:ebf7:5e87%18]) with mapi id 15.01.1199.017; Sun, 25 Jun 2017 13:34:41 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: Slot requests for IETF99 Thread-Index: AdLtt7O52CIZ/CWwSe+7lD2M/GgOxg== Date: Sun, 25 Jun 2017 13:34:40 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2.44.104.118] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2331; 7:NMlSEOnYs8+9vQgSEeLs61P1Vft0WqhNzlcYFNlyIRt9AuAACvJ5nsii3wM/23FwZIOI7dfpS1tlK6cbeFEyYF3asMXDJePgGCygMODB20IeRPwxS5XuuWAUPumGgb1yqHHwwhBbj9/DBhkatJ8wLRhg6Gnm82PjBFOhtkJEKvrSKtFDmQFGHoKcCCfzzeGLtT0iNA3Fftxnb1j+yxoPKFWbMJeprg/mbq3C4BO+OARYRV/Let6AGVqZVZPvAmgalWoYJywxrfss31Uxb/G0bWVw71WwHULt24LnxtDjoRnIi20zmf+V4jkRAxtY7cHF6brksz7kaAhoSQKwihUzilV7fTsc21fdvCFPSpjVzWaYDPeXcDwrlSkraph0KQIvHZrsx/rNXk0JjQSIjExAWYzVetReBuxdUkDJjOkzJpCLjQqV7AbRo6i6PJJA319bBv7K2vRkFgohMCa1b7plMXOEoA9DE0g0Td0kE/CHfct91MnfNNJdxjsZbLbBXVBYVU8hhu3IrDQe4LxpADhvNSvOwEzGJ0rUQtH+7b9OUaD1LqGOSAQDemK2nqSKepm/KiQfaSCC0oHGOXRCyHc9cI3x1ii4cmdPY6bVqUu/mOXjvw1hcZ3pITxsl1PerOkvQVuvYlmrv1LoQdJelIiXQjFPGxYj8lHneFpgcgeCkpkseJYA8Lcnn8bOdBmUWCHZZE7OnP2ik+TKUd/MVtD1znyqQnHvjitcpX3lbgbxNxPx38CCO1p/+pd3iRse6xldnQgddhE3urX/K9l4VUmU7BF6cugcQDr/PR07OvDv2oU= x-ms-office365-filtering-correlation-id: b94e5825-f19d-422b-d89a-08d4bbceeecf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506067)(300135500095); SRVR:HE1PR0701MB2331; x-ms-traffictypediagnostic: HE1PR0701MB2331: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(26388249023172)(236129657087228)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB2331; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB2331; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39860400002)(39850400002)(39450400003)(39400400002)(39410400002)(53754006)(66544003)(38730400002)(110136004)(6306002)(54896002)(14454004)(7736002)(99286003)(55016002)(1730700003)(8676002)(9686003)(97736004)(2501003)(189998001)(6116002)(5250100002)(3846002)(790700001)(81166006)(8936002)(102836003)(6436002)(54356999)(50986999)(450100002)(2900100001)(5640700003)(5630700001)(6916009)(106356001)(2351001)(74316002)(25786009)(66066001)(478600001)(3660700001)(3280700002)(86362001)(2906002)(33656002)(53936002)(7696004)(4326008)(6506006)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2331; H:HE1PR0701MB2539.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2539E4F4B9899A7E0E297D4998DE0HE1PR0701MB2539_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2017 13:34:40.7996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2331 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHO/cxr6PBaSr+WFq2WEq5maUiJD7+ECIwrSCm5GO4i1q62a5Z RoGGRCmRoWU2fKRLTYtUzAy1fC0mKoqVltofPqBEKJ+lZZrXe4X++5zv93u+nC8chpQ/oRVM kiGNNRl0yUqJlCrSvlKrF1vCIw8PjpD+5r+NyL/oViEVTBy3WFaJCBQlDdCzyUnprMkrME6a OPB+CqVm7bnSMlpDZKJ7ihxkzwD2geXFPEkOkjJy3I2gtGsDCQcbgvxa25ZD4TskND8zi04x ATM/i8Q7XxFszBdSfJkEB8DgxA+aZ0e8H+4XdG2GGIbE3rDaepFHB7wPBstThMQByGvsF9Ma WLEt2fFMYRVMFs/SfFyG46CpfascYVdYyqoleSaxM4xOlxLCAgyW1gFSYCeYmVqn+ZchnItg rmRYDLlBb90KEtgVhkpzt7YAnpTAyPc2iWCEwdBCrUQwPhLw/OaaWOsJ5o0RkY1Q/7qaFvg6 1LffEJve0VD1a0NscoHxiQbRWKUhe6pka4QDVsCXD7eRwC7wbbyNzkMej/7bJLAR8szdFM8y vAt6iqYpQfeEspYFicCHoPLxLLnNfe1TxP96GbKrQU4cy3EpCUeOalhTUjzHGQ0aA5vWgDY/ T0fjH3Uzqp0N6USYQcqdMmtleKSc1qVzGSmdCBhS6Sg7lbgpyfS6jKusyRhrupTMcp1oN0Mp nWXBbwa1cpygS2MvsGwqa9p2CcZekYncHhYEXYt3s6k8qs8ZxiAmZl6/qIoNrXLRRIckZK11 lOp9KvOXeo0DYT34cl1/jN/yA5X7XavWD82PDESd5Qg1V+HSNFcS+LvP61PbelqEZkd09plj n7OenrZZ13tbieEK64mgk6EvZFrLy70qr3KzddxXOka599W7+749P6akuESd90HSxOn+AZhm aKY4AwAA Archived-At: Subject: [Cbor] Slot requests for IETF99 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: Sun, 25 Jun 2017 13:34:50 -0000 --_000_HE1PR0701MB2539E4F4B9899A7E0E297D4998DE0HE1PR0701MB2539_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We are starting to plan the CBOR session for the IETF99. If you are interes= ted in having a presentation slot, please send a request to the chairs by T= uesday July 4th, with the following details: - Draft - Abstract: A couple of lines about the document or topic. - Objective: Present an idea, get adoption, ask for feedback/reviewers/... - Time: How much time you think you will need See you soon in Prague, Francesca & Joe --_000_HE1PR0701MB2539E4F4B9899A7E0E297D4998DE0HE1PR0701MB2539_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We are starting to plan the CBOR session for the = IETF99. If you are interested in having a presentation slot, please send a = request to the chairs by Tuesday July 4th, with the following details:

 

- Draft

- Abstract: A couple of lines about the document = or topic.

- Objective: Present an idea, get adoption, ask f= or feedback/reviewers/...

- Time: How much time you think you will need

 

See you soon in Prague,

Francesca & Joe

--_000_HE1PR0701MB2539E4F4B9899A7E0E297D4998DE0HE1PR0701MB2539_--