From nobody Sat Oct 8 18:24:06 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 A1CA012945B for ; Sat, 8 Oct 2016 18:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996, 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 ZAPPlNg9XFYl for ; Sat, 8 Oct 2016 18:24:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC35C129440 for ; Sat, 8 Oct 2016 18:24:03 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 40F732009E; Sat, 8 Oct 2016 21:38:05 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 70AD86392D; Sat, 8 Oct 2016 21:24:02 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , cbor@ietf.org In-Reply-To: <57F9605F.9090908@tzi.org> References: <18978.1475960271@obiwan.sandelman.ca> <57F9605F.9090908@tzi.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Sat, 08 Oct 2016 21:24:02 -0400 Message-ID: <17370.1475976242@obiwan.sandelman.ca> Archived-At: Subject: Re: [Cbor] mailing list or github for cddl 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, 09 Oct 2016 01:24:05 -0000 {conversation mid-way through} Carsten Bormann wrote: > Well, [0] is a valid grasp message... Just not a very interesting one. > Unfortunately, the current version of the CDDL tool can't annotate > numbers. So, for instance, for the following message: > $ cddl 57be316fdc565354a9df521187a73138/gistfile1.txt gp > /grasp-message/ [8, 7025801, > /objective/ [/objective-name/ "decalcifier", 7, 228]] > you'd need to look up the 8 (SYNCH) by yourself. Aha, so I'm supposed to put an encoded message in there, I guess? I had much difficulties understanding the grasp.cddl. I thought that cddl would help me, but I see now what is really does. Slowly how the data is described is sinking in for me. I thought that the CDDL tool was going to grok the file definition somehow and spit out some kind of JSON definition that I could understand better. (like on page 26...) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Sat Oct 8 18:27: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 82A1312945B for ; Sat, 8 Oct 2016 18:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996, 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 brrsz2H20_cd for ; Sat, 8 Oct 2016 18:27:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9882C126D74 for ; Sat, 8 Oct 2016 18:27:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A3DDF2009E for ; Sat, 8 Oct 2016 21:41:12 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DD4A16392D for ; Sat, 8 Oct 2016 21:27:09 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] mailing list or github for cddl (fwd) Carsten Bormann: Re: mailing list or github for cddl 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, 09 Oct 2016 01:27:12 -0000 --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=181 Content-Transfer-Encoding: 8bit Content-Description: forwarded message Replied: Sat, 08 Oct 2016 21:24:02 -0400 Replied: "Carsten Bormann , cbor@ietf.org "Brian E. Carpenter" " Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3:216:3eff:fe7c:d1f3] by obiwan.sandelman.ca with IMAP (fetchmail-6.3.26) for (single-drop); Sat, 08 Oct 2016 21:03:48 -0400 (EDT) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus v2.4.16-Debian-2.4.16-4+deb7u2) with LMTPA; Sat, 08 Oct 2016 17:22:16 -0400 X-Sieve: CMU Sieve 2.4 Received: from colo19.roaringpenguin.com (unknown [IPv6:2604:1f80:1:478::19]) by tuna.sandelman.ca (Postfix) with ESMTPS id 9D0CB2009E for ; Sat, 8 Oct 2016 17:22:16 -0400 (EDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by colo19.roaringpenguin.com (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id u98L8BTG009232 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 8 Oct 2016 17:08:13 -0400 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 u98L88Nm011745; Sat, 8 Oct 2016 23:08:08 +0200 (CEST) Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3srzWC6Xrcz2jPg; Sat, 8 Oct 2016 23:08:07 +0200 (CEST) Message-ID: <57F9605F.9090908@tzi.org> Date: Sat, 08 Oct 2016 23:08:47 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Michael Richardson CC: "Brian E. Carpenter" Subject: Re: mailing list or github for cddl References: <18978.1475960271@obiwan.sandelman.ca> In-Reply-To: <18978.1475960271@obiwan.sandelman.ca> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: mcr, @@RPTN) X-Spam-Score: 0.00 () [Hold at 5.10] SPF(none:0),DKIM(none:0) X-CanIt-Geo: ip=2001:638:708:30c9::12; country=DE; region=Bremen; city=Bremen; latitude=53.0938; longitude=8.7830; http://maps.google.com/maps?q=53.0938,8.7830&z=6 X-CanItPRO-Stream: sandelman-ca:mcr (inherits from sandelman-ca:default,rp-01:default,base:default) X-Canit-Stats-ID: 0gRR98cD3 - 88b26c27124e - 20161008 X-Antispam-Training-Forget: https://antispam.roaringpenguin.com/canit/b.php?i=0gRR98cD3&m=88b26c27124e&t=20161008&c=f X-Antispam-Training-Nonspam: https://antispam.roaringpenguin.com/canit/b.php?i=0gRR98cD3&m=88b26c27124e&t=20161008&c=n X-Antispam-Training-Phish: https://antispam.roaringpenguin.com/canit/b.php?i=0gRR98cD3&m=88b26c27124e&t=20161008&c=p X-Antispam-Training-Spam: https://antispam.roaringpenguin.com/canit/b.php?i=0gRR98cD3&m=88b26c27124e&t=20161008&c=s X-CanIt-Archive-Cluster: irqpXI7aJGyo4Ewta7qVH399FOg Received-SPF: none (colo19.roaringpenguin.com: domain of cabo@tzi.org does not designate permitted sender hosts) receiver=colo19.roaringpenguin.com; client-ip=2001:638:708:30c9::12; envelope-from=; helo=mailhost.informatik.uni-bremen.de; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) Hi Michael, Michael Richardson wrote: > I did: "gem install cddl", and I can apparently run it against an extraction > of the GRASP CDDL. I put the file at: > https://gist.github.com/mcr/57be316fdc565354a9df521187a73138 > > Is there a mailing list or github I can ask questions on? The cbor@ietf.org mailing list is pretty quiet. > I could look at Brian's python code, but for the moment, I think it's better > for the documents if I avoid using the source code. > > But, I'm not really sure what is going on here. I was hoping that the CDDL > utility would help me understand the translation from the grasp.cddl > definition to the actual structure of the resulting CDDL, but I don't see the > link at this point. > > obiwan-[unstrung/lib/libgrasp](2.2.1) mcr 10335 %cddl grasp.cddl generate > [7, 10136900, 2756652087] > > obiwan-[unstrung/lib/libgrasp](2.2.1) mcr 10336 %cddl grasp.cddl json-generate > [ > 0 > ] Well, [0] is a valid grasp message... Just not a very interesting one. Unfortunately, the current version of the CDDL tool can't annotate numbers. So, for instance, for the following message: $ cddl 57be316fdc565354a9df521187a73138/gistfile1.txt gp /grasp-message/ [8, 7025801, /objective/ [/objective-name/ "decalcifier", 7, 228]] you'd need to look up the 8 (SYNCH) by yourself. I hope I can get that limitation fixed at some point... Apart from the (incomplete) support for annotating instances, the tool is mainly used for validating and (as you used it) for randomly generating some. The latter is rather useful, but it is random... Adding a repeat count may help: $ cddl 57be316fdc565354a9df521187a73138/gistfile1.txt gp 10 /grasp-message/ [6, 15496815, [102, /reason/ "orthotoluidin"]] /grasp-message/ [6, 2025599, [102]] /grasp-message/ [6, 11295853, [102]] /grasp-message/ [9, 3493548, /initiator/ h'539fd268', 3640223346, [], /objective/ [/objective-name/ "strenuously", 7, 19, /any/ "Pamirian"], /objective/ [/objective-name/ "usucapt", 7, 177], /objective/ [/objective-name/ "securiform", 7, 136], /objective/ [/objective-name/ "decapodiform", 7, 249, /any/ "spun"]] /grasp-message/ [0] /grasp-message/ [0] /grasp-message/ [4, 2927293, /objective/ [/objective-name/ "garavance", 7, 60, /any/ "justiciarship"]] /grasp-message/ [0] /grasp-message/ [0] /grasp-message/ [8, 4239061, /objective/ [/objective-name/ "molman", 7, 52, /any/ "Fabrikoid"]] Need to get annotation of numbers fixed. Grüße, Carsten --=-=-= Content-Type: text/plain -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-=-- From nobody Sat Oct 8 21:07: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 037FF129456 for ; Sat, 8 Oct 2016 21:07:46 -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 T5N9D8kkxV-d for ; Sat, 8 Oct 2016 21:07:44 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD13129420 for ; Sat, 8 Oct 2016 21:07:43 -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 u9947eCx012840; Sun, 9 Oct 2016 06:07:40 +0200 (CEST) Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ss8qH6XdRz2jSQ; Sun, 9 Oct 2016 06:07:39 +0200 (CEST) Message-ID: <57F9C2B4.5060906@tzi.org> Date: Sun, 09 Oct 2016 06:08:20 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Michael Richardson References: <18978.1475960271@obiwan.sandelman.ca> <57F9605F.9090908@tzi.org> <17370.1475976242@obiwan.sandelman.ca> In-Reply-To: <17370.1475976242@obiwan.sandelman.ca> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: cbor@ietf.org Subject: Re: [Cbor] mailing list or github for cddl 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, 09 Oct 2016 04:07:46 -0000 Michael Richardson wrote: > {conversation mid-way through} > > Carsten Bormann wrote: > > Well, [0] is a valid grasp message... Just not a very interesting one. > > > Unfortunately, the current version of the CDDL tool can't annotate > > numbers. So, for instance, for the following message: > > > $ cddl 57be316fdc565354a9df521187a73138/gistfile1.txt gp > > /grasp-message/ [8, 7025801, > > /objective/ [/objective-name/ "decalcifier", 7, 228]] > > > you'd need to look up the 8 (SYNCH) by yourself. > > Aha, so I'm supposed to put an encoded message in there, I guess? That would be the validate (or vp = validate/pretty) command for the CDDL tool. > I had much difficulties understanding the grasp.cddl. I thought that > cddl would help me, but I see now what is really does. Slowly how the > data is described is sinking in for me. Great. If you are used to what ABNF does, CDDL should seem natural. > I thought that the CDDL tool was going to grok the file definition somehow > and spit out some kind of JSON definition that I could understand better. > (like on page 26...) Page 26? That has the overall CDDL, grasp-message = (message .within message-structure) / noop-message message-structure = [MESSAGE_TYPE, session-id, ?initiator, *grasp-option] MESSAGE_TYPE = 1..255 session-id = 0..16777215 ;up to 24 bits grasp-option = any Then the rest of the CDDL just adds more detailed alternatives to "message". Grüße, Carsten From nobody Sun Oct 9 12:03:58 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 6415F12956A for ; Sun, 9 Oct 2016 12:03:57 -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 ZcyzxbRZg7LI for ; Sun, 9 Oct 2016 12:03:55 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 2112212954F for ; Sun, 9 Oct 2016 12:03:55 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id 128so25684499pfz.2 for ; Sun, 09 Oct 2016 12:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=mvSA992P69igNe/jvF2cCWrvMLJb7zVYz4wILHzwgrw=; b=nPzW3aUPjkbvXCi/tLYdF/PwcK2azyoXRlNpjxinKBlAY+xauKI/RG9K1aWZ6R03Vv cCbh5N63+b+p0Q1abuvvrhUkIi0T+UnWGEtbJiAJk/BKySID5bIi/9u9um/MOMt8h2t1 C97m2QC94C/5IFzlRNp4PR6mUdsdQAg6tbJJcOqWsv041T4mi0UCrvQto5s76IT5Z2nk aM07TeVXNi8qyXL7ftofRgfJdfToYm9RI7YU44qK2igkhrJx6fObAizahJDxx2B6RJKz Pgx6HfMVQTXtgrkUQ/ORawcIBPzgFikJoTISB9p8JSvnvl0WlomyrKIlCqTtEnHpRKGP x2Pw== 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:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=mvSA992P69igNe/jvF2cCWrvMLJb7zVYz4wILHzwgrw=; b=jfcVBo4Iniq3BPIKLWpB3VpfZRHlupcWKU4RnEuK50faWJApn3U64XOb03ORI16jJJ R00p8OuKFt8/KaKs1NJgCAy7HiABXUmLNWYqispBjBbjEvKsgdo4P/kFjeWQ3QAtr2Ke VgtpS+cYQo4/EaXahhrO4koChdzRkZiwHmxv/lHGt4YwPNehKUgY3LJXpcM/ca+dkSPh 9b78xwjGGAwqrzQeegrszLycd4W/M4mywGrJNSiOphrHsnkbF4M5YhGjqaJmFRvMh97K /Lf+L6YhLfuZG/dt5UL2tA+rdp+KVCl7xg2yAN60T3cfIwsp6KPrp6+cBuWPVL5WU6DP ZhEw== X-Gm-Message-State: AA6/9Rkno6NCIPZP4JNqsrFHq/MtvFGADXKQszUaSG7T6hUbRMS4VuSzIznY54iteW1o/g== X-Received: by 10.98.33.214 with SMTP id o83mr38763036pfj.149.1476039834541; Sun, 09 Oct 2016 12:03:54 -0700 (PDT) Received: from [192.168.178.23] ([118.148.64.35]) by smtp.gmail.com with ESMTPSA id fg2sm29151277pad.23.2016.10.09.12.03.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Oct 2016 12:03:53 -0700 (PDT) To: cbor@ietf.org References: <18978.1475960271@obiwan.sandelman.ca> <57F9605F.9090908@tzi.org> <17370.1475976242@obiwan.sandelman.ca> <57F9C2B4.5060906@tzi.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 10 Oct 2016 08:03:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <57F9C2B4.5060906@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cbor] mailing list or github for cddl 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, 09 Oct 2016 19:03:57 -0000 On 09/10/2016 17:08, Carsten Bormann wrote: > > > Michael Richardson wrote: ... >> I had much difficulties understanding the grasp.cddl. I thought that >> cddl would help me, but I see now what is really does. Slowly how the >> data is described is sinking in for me. If there's anything we can do to make the spec easier to understand, please make suggestions. [For the cbor list: we're talking about https://tools.ietf.org/html/draft-ietf-anima-grasp-07#section-6, and there's already a plan to add some example messages as an Appendix.] Brian From nobody Tue Oct 11 12:48:33 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 A68B2129684 for ; Tue, 11 Oct 2016 12:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.017 X-Spam-Level: X-Spam-Status: No, score=-10.017 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=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 DAsyX2mAR3uW for ; Tue, 11 Oct 2016 12:48:30 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8041294B7 for ; Tue, 11 Oct 2016 12:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1476215310; x=1507751310; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=/ihSCBh5cOT/CKc7jZRTcSBy4PSLRKOgwQAWPG4Hst4=; b=jCQ41rtU95ir1FTpyC0TEKs/m9QcQWOy/wqNj3aKfyW2M0HIIm8MuNOq VHYtxvhLCc5pcYnkwi3i/PdWIs+2k6dyubbfXxv0LsGay7aPLtKWqPAx7 aXaI0GC4GkmDUgdNsWgfbjNK4PXuK5LvwHrnY6rAcFuVPnjCJktgrlaup c=; X-IronPort-AV: E=Sophos;i="5.31,330,1473145200"; d="scan'208";a="230899973" Received: from unknown (HELO Ironmsg03-L.qualcomm.com) ([10.53.140.110]) by wolverine01.qualcomm.com with ESMTP; 11 Oct 2016 12:48:29 -0700 X-IronPort-AV: E=McAfee;i="5700,7163,8315"; a="1240373587" Received: from nasanexm01b.na.qualcomm.com ([10.85.0.82]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Oct 2016 12:48:29 -0700 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01B.na.qualcomm.com (10.85.0.82) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 11 Oct 2016 12:48:29 -0700 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1178.000; Tue, 11 Oct 2016 12:48:29 -0700 From: "Lundblade, Laurence" To: "cbor@ietf.org" Thread-Topic: Examples of tag 21,22 and 23? Thread-Index: AQHSI/hwDq15oC7z1ECYjn7DoWt/Vg== Date: Tue, 11 Oct 2016 19:48:28 +0000 Message-ID: <210809AA-7E76-4DBD-B860-E7C3B6FF4225@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.107.6] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Cbor] Examples of tag 21,22 and 23? 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, 11 Oct 2016 19:48:31 -0000 Can someone give some clear and concrete examples of the tags to hint at B6= 4, B64url and B16 encoding? Perhaps I haven=92t done enough work in JSON a= nd web-type apps to know. Maybe this is trying accommodate translation of = some extant JSON protocols into CBOR? If I was doing something new, then I = don=92t have to be bound by these? More specifically - What would you do with a bstr if you didn=92t encode in one of these if = you are translating to JSON? Would you just drop it? - What are the data types / use cases where you=92d want to use B64url?=20 - Would you agree that B16 should be avoided unless there is some backward= s compatibility need? Thx LL= From nobody Tue Oct 11 14:18:43 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 C716512956E for ; Tue, 11 Oct 2016 14:18:41 -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 krTyuPJB0PK7 for ; Tue, 11 Oct 2016 14:18: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 B47D0129592 for ; Tue, 11 Oct 2016 14:18: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 u9BLIQVq022360; Tue, 11 Oct 2016 23:18:26 +0200 (CEST) Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3stqbk3vG2z2jLF; Tue, 11 Oct 2016 23:18:26 +0200 (CEST) Message-ID: <57FD575B.2040000@tzi.org> Date: Tue, 11 Oct 2016 23:19:23 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "Lundblade, Laurence" References: <210809AA-7E76-4DBD-B860-E7C3B6FF4225@qti.qualcomm.com> In-Reply-To: <210809AA-7E76-4DBD-B860-E7C3B6FF4225@qti.qualcomm.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "cbor@ietf.org" Subject: Re: [Cbor] Examples of tag 21,22 and 23? 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, 11 Oct 2016 21:18:42 -0000 Hi Laurence, > Can someone give some clear and concrete examples of the tags to hint at B64, B64url and B16 encoding? Perhaps I haven’t done enough work in JSON and web-type apps to know. Maybe this is trying accommodate translation of some extant JSON protocols into CBOR? If I was doing something new, then I don’t have to be bound by these? RFC 7049 says (Section 2.4.4.2): Tags 21 to 23 indicate that a byte string might require a specific encoding when interoperating with a text-based representation. These tags are useful when an encoder knows that the byte string data it is writing is likely to be later converted to a particular JSON-based usage. So the area of application is interworking with text-based formats (such as JSON), assuming the (potential) presence of a CBOR-to-JSON converter or similar. I you don't have to interwork with JSON legacy, these Tags are not for you. > More specifically > - What would you do with a bstr if you didn’t encode in one of these if you are translating to JSON? Would you just drop it? I believe a sane generic CBOR-to-JSON converter (that is not operating in some strict mode) would encode untagged byte strings as base64url (without padding), as this is what modern JSON-based protocols tend to use for byte strings. (Of course, this conversion loses information, but that is not avoidable in this case.) I don't know how to "drop" data in a CBOR to JSON conversion; JSON does not even have a convenient data replacement indicator (null is pretty overloaded). > - What are the data types / use cases where you’d want to use B64url? Imagine that you want to interwork with a JOSE implementation. (Of course, there now is COSE, but there are JOSE implementations you might want to talk to.) You could send all the base64url data that would need to be in a JOSE object (JWS, outer layer in JWE) as unencoded CBOR byte strings, trusting the CBOR-to-JSON converter to correctly interpret the Tag 21 you put on the whole CBOR-encoded JOSE structure. (Of course, this assumes that you are using the JSON form of JWS/JWE, which most JOSE doesn't.) > - Would you agree that B16 should be avoided unless there is some backwards compatibility need? All of Tag 21 to 23 is either about backward compatibility, about designing for a mixed CBOR-JSON world, or usually both. Tag 23: Well, there are some JSON-based protocols that require hex coding of binary data (e.g., often cryptographic hashes are transferred in hex, for reasons I don't quite get). Anecdote 1: When we designed Tag 21 to 23, I was actively looking for protocols that use base32 in a JSON string environment. I didn't find any (just base64url, base64, and hex), so there are no additional tags for base32 (there would need to be multiple ones because of the large number of base32 variants, only two of which are even described in RFC4648). (Anecdote 2: When RFC 6920 was designed, I tried to get base32 into the "nih" URL scheme. There were implementer comments that base32 was "too complicated to implement". OK....) Grüße, Carsten From nobody Tue Oct 11 14:41:29 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 F1D9D1295B1 for ; Tue, 11 Oct 2016 14:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.017 X-Spam-Level: X-Spam-Status: No, score=-10.017 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=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 WyWlhitrklRp for ; Tue, 11 Oct 2016 14:41:25 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB391295AB for ; Tue, 11 Oct 2016 14:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1476222085; x=1507758085; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Yh7ey0BQr6r+lq+IP6/Uc9BfSrUNafK2Sk+Fe8aCSiE=; b=mUmDL/WrdZlhbe4A2yN2Iz76sUYSM8+4WQlBsez+NuXuqZbJ66kZBR+J n7sbnZ7xPH7Ws8Emeq5NGxXIxRrRWqzr85o8W/o0/2OaEusCeha/RrB6N Vb4sJPNhlOIALlyvDY8KiTBZUt6ZcjQfssH+vM5v5U752wkxZntvUKaDm A=; X-IronPort-AV: E=Sophos;i="5.31,330,1473145200"; d="scan'208";a="326126163" Received: from unknown (HELO Ironmsg03-L.qualcomm.com) ([10.53.140.110]) by wolverine02.qualcomm.com with ESMTP; 11 Oct 2016 14:41:24 -0700 X-IronPort-AV: E=McAfee;i="5700,7163,8315"; a="1240424503" Received: from nasanexm01g.na.qualcomm.com ([10.85.0.33]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Oct 2016 14:41:23 -0700 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01G.na.qualcomm.com (10.85.0.33) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 11 Oct 2016 14:41:23 -0700 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1178.000; Tue, 11 Oct 2016 14:41:23 -0700 From: "Lundblade, Laurence" To: Carsten Bormann Thread-Topic: [Cbor] Examples of tag 21,22 and 23? Thread-Index: AQHSI/hwDq15oC7z1ECYjn7DoWt/VqCkN66AgAAGI4A= Date: Tue, 11 Oct 2016 21:41:22 +0000 Message-ID: <38C105C9-6BFD-455B-BB24-AB068F56D515@qti.qualcomm.com> References: <210809AA-7E76-4DBD-B860-E7C3B6FF4225@qti.qualcomm.com> <57FD575B.2040000@tzi.org> In-Reply-To: <57FD575B.2040000@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.107.6] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5A7D9169832DF14981CEC7215195AED7@qualcomm.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cbor@ietf.org" Subject: Re: [Cbor] Examples of tag 21,22 and 23? 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, 11 Oct 2016 21:41:28 -0000 Thanks for the info. To be more specific, if one were designing a brand new protocol in CBOR and= you wanted it to be easily transformed into JSON, how would you use these = tags? Could you just assume that all bstr items get encoded with B64URL a= nd not even use these tags? Or maybe to be safe you tag every bstr with 22= ? LL On Oct 11, 2016, at 2:19 PM, Carsten Bormann wrote: > Hi Laurence, >=20 >> Can someone give some clear and concrete examples of the tags to hint at= B64, B64url and B16 encoding? Perhaps I haven=92t done enough work in JSO= N and web-type apps to know. Maybe this is trying accommodate translation = of some extant JSON protocols into CBOR? If I was doing something new, then= I don=92t have to be bound by these? >=20 > RFC 7049 says (Section 2.4.4.2): >=20 > Tags 21 to 23 indicate that a byte string might require a specific > encoding when interoperating with a text-based representation. These > tags are useful when an encoder knows that the byte string data it is > writing is likely to be later converted to a particular JSON-based > usage. >=20 > So the area of application is interworking with text-based formats (such > as JSON), assuming the (potential) presence of a CBOR-to-JSON converter > or similar. >=20 > I you don't have to interwork with JSON legacy, these Tags are not for yo= u. >=20 >> More specifically >> - What would you do with a bstr if you didn=92t encode in one of these i= f you are translating to JSON? Would you just drop it? >=20 > I believe a sane generic CBOR-to-JSON converter (that is not operating > in some strict mode) would encode untagged byte strings as base64url > (without padding), as this is what modern JSON-based protocols tend to > use for byte strings. (Of course, this conversion loses information, > but that is not avoidable in this case.) >=20 > I don't know how to "drop" data in a CBOR to JSON conversion; JSON does > not even have a convenient data replacement indicator (null is pretty > overloaded). >=20 >> - What are the data types / use cases where you=92d want to use B64url?= =20 >=20 > Imagine that you want to interwork with a JOSE implementation. > (Of course, there now is COSE, but there are JOSE implementations you > might want to talk to.) > You could send all the base64url data that would need to be in a JOSE > object (JWS, outer layer in JWE) as unencoded CBOR byte strings, > trusting the CBOR-to-JSON converter to correctly interpret the Tag 21 > you put on the whole CBOR-encoded JOSE structure. > (Of course, this assumes that you are using the JSON form of JWS/JWE, > which most JOSE doesn't.) >=20 >> - Would you agree that B16 should be avoided unless there is some backwa= rds compatibility need? >=20 > All of Tag 21 to 23 is either about backward compatibility, about > designing for a mixed CBOR-JSON world, or usually both. >=20 > Tag 23: Well, there are some JSON-based protocols that require hex > coding of binary data (e.g., often cryptographic hashes are transferred > in hex, for reasons I don't quite get). >=20 > Anecdote 1: When we designed Tag 21 to 23, I was actively looking for > protocols that use base32 in a JSON string environment. I didn't find > any (just base64url, base64, and hex), so there are no additional tags > for base32 (there would need to be multiple ones because of the large > number of base32 variants, only two of which are even described in RFC464= 8). > (Anecdote 2: When RFC 6920 was designed, I tried to get base32 into the > "nih" URL scheme. There were implementer comments that base32 was "too > complicated to implement". OK....) >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Tue Oct 11 23:16:24 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 4F3B112940B for ; Tue, 11 Oct 2016 23:16:23 -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 GcfPN9AJ6rua for ; Tue, 11 Oct 2016 23:16:21 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 317A01293D8 for ; Tue, 11 Oct 2016 23:16:21 -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 u9C6GIrQ006030; Wed, 12 Oct 2016 08:16:18 +0200 (CEST) Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3sv3XK6GSGz2jRK; Wed, 12 Oct 2016 08:16:17 +0200 (CEST) Message-ID: <57FDD56B.1070201@tzi.org> Date: Wed, 12 Oct 2016 08:17:15 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "Lundblade, Laurence" References: <210809AA-7E76-4DBD-B860-E7C3B6FF4225@qti.qualcomm.com> <57FD575B.2040000@tzi.org> <38C105C9-6BFD-455B-BB24-AB068F56D515@qti.qualcomm.com> In-Reply-To: <38C105C9-6BFD-455B-BB24-AB068F56D515@qti.qualcomm.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "cbor@ietf.org" Subject: Re: [Cbor] Examples of tag 21,22 and 23? 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, 12 Oct 2016 06:16:23 -0000 > To be more specific, if one were designing a brand new protocol in CBOR and you wanted it to be easily transformed into JSON, how would you use these tags? Could you just assume that all bstr items get encoded with B64URL and not even use these tags? Again, assuming sane CBOR-to-JSON converters, this is what I would do. Alternatively/additionally, you could tag the whole structure with Tag 21 (outermost Tag), which is equivalent to prepending single byte with the value 0xd5. This would allow a CBOR-to-JSON converter that operates in a strict mode to make this conversion safely as well. Note that, in the inverse direction, your CBOR consumer must be prepared to find text strings where it expects byte strings, and it must convert them back to byte strings via base64url (a generic JSON-to-CBOR converter can not do this for you as it doesn't have any hints to go by). > Or maybe to be safe you tag every bstr with 22? That is not needed (see above). (It would be Tag 21 for base64url.) Grüße, Carsten From nobody Thu Oct 20 13:02:36 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 3B26F1295DE for ; Thu, 20 Oct 2016 13:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.553 X-Spam-Level: X-Spam-Status: No, score=-5.553 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 0PDGqhOBjh7k for ; Thu, 20 Oct 2016 13:02:33 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6694F1294FE for ; Thu, 20 Oct 2016 13:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1476993752; x=1508529752; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=vP65cWhdsmwiUn69+Y5RmqhJ7JP434uBlWleB3DXSoM=; b=ixQdMFjFZbX8Fh89wYe5samFp5401AcJyxFT+ss2aEAXnC8N1eWs3XeU sj8EHFW0ap6IjyQFfKP+BZKTWmw2ew7mQYDQBxvHpfJeXrIZ9nfhymng9 AblwrFcNPOj8Xp902DXNvhGIqVrtfjD006nS5U5zvBgLO81fyRuFToMM4 g=; X-IronPort-AV: E=Sophos;i="5.31,372,1473145200"; d="scan'208";a="233532939" Received: from unknown (HELO ironmsg02-L.qualcomm.com) ([10.53.140.109]) by wolverine01.qualcomm.com with ESMTP; 20 Oct 2016 13:02:32 -0700 X-IronPort-AV: E=McAfee;i="5700,7163,8324"; a="798237316" Received: from nasanexm01b.na.qualcomm.com ([10.85.0.82]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Oct 2016 13:02:31 -0700 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01B.na.qualcomm.com (10.85.0.82) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 20 Oct 2016 13:02:31 -0700 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1178.000; Thu, 20 Oct 2016 13:02:31 -0700 From: "Lundblade, Laurence" To: "cbor@ietf.org" Thread-Topic: translating simple value undef to JSON Thread-Index: AQHSKwzj/cT1ZCRk7UGqZLk6uj+HNw== Date: Thu, 20 Oct 2016 20:02:30 +0000 Message-ID: <9D6916CA-7DDC-4691-BC16-0050E128016C@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.107.6] Content-Type: text/plain; charset="Windows-1252" Content-ID: <48DAD018C29A4B4886BE5EB5698CAE5F@qualcomm.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Cbor] translating simple value undef to JSON 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, 20 Oct 2016 20:02:34 -0000 Seems like JSON doesn=92t have the value =93undef=94 but CBOR does. Is ther= e some thinking on how to translate it, or should any protocol designed to = convert to JSON just not use undef? Thx LL From nobody Thu Oct 20 15:58:49 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 42A9D1294A4 for ; Thu, 20 Oct 2016 15:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-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 j6H3GBZ0CfBd for ; Thu, 20 Oct 2016 15:58:47 -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 2ADE1129469 for ; Thu, 20 Oct 2016 15:58:47 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.90.60.238]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6EC8A22E255 for ; Thu, 20 Oct 2016 18:58:40 -0400 (EDT) To: cbor@ietf.org References: <9D6916CA-7DDC-4691-BC16-0050E128016C@qti.qualcomm.com> From: Sean Leonard Message-ID: Date: Thu, 20 Oct 2016 15:59:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9D6916CA-7DDC-4691-BC16-0050E128016C@qti.qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] translating simple value undef to JSON 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, 20 Oct 2016 22:58:48 -0000 On 10/20/2016 1:02 PM, Lundblade, Laurence wrote: > Seems like JSON doesn=92t have the value =93undef=94 but CBOR does. Is = there some thinking on how to translate it, or should any protocol design= ed to convert to JSON just not use undef? Don't use undef. At least, not in "that way" (i.e., where you expect undefined to exist=20 in JSON). It won't round-trip. You would need to co-opt another value=20 and mark it "special", but that would take away from being able to use=20 that value in your protocol. I.e., adds complexity. I suppose you might consider using an invalid UTF-16 sequence, such as=20 the single character "\uDFFF". That will not round-trip into CBOR=20 strings because CBOR only permits UTF-8, which /should/ be well-formed.=20 (There is leeway in RFC 7049 that leaves open the possibility that=20 ill-formed UTF-8 might be acceptable; check it out.) Your special=20 encoder or decoder could recognize this special character and convert=20 accordingly. Sean From nobody Thu Oct 20 16:08:08 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 88AF112951F for ; Thu, 20 Oct 2016 16:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 XfeNh0gPV7tE for ; Thu, 20 Oct 2016 16:08:06 -0700 (PDT) Received: from p3plwbeout03-01.prod.phx3.secureserver.net (p3plsmtp03-01-2.prod.phx3.secureserver.net [72.167.218.213]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE061294E7 for ; Thu, 20 Oct 2016 16:08:06 -0700 (PDT) Received: from localhost ([72.167.218.131]) by p3plwbeout03-01.prod.phx3.secureserver.net with bizsmtp id xz851t0022qhQio01z85XW; Thu, 20 Oct 2016 16:08:05 -0700 X-SID: xz851t0022qhQio01 Received: (qmail 15071 invoked by uid 99); 20 Oct 2016 23:08:05 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.189 User-Agent: Workspace Webmail 6.5.2 Message-Id: <20161020160803.665a7a7059d7ee80bb4d670165c8327d.2ddbc991db.wbe@email03.godaddy.com> From: "Doug Ewell" To: "Sean Leonard" , cbor@ietf.org Date: Thu, 20 Oct 2016 16:08:03 -0700 Mime-Version: 1.0 Archived-At: Subject: Re: [Cbor] translating simple value undef to JSON 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, 20 Oct 2016 23:08:07 -0000 Sean Leonard wrote:=0A=0A> I suppose you might consider using an invalid UT= F-16 sequence, such=0A> as the single character "\uDFFF".=0A=0AEww.=0A=0A--= =0ADoug Ewell | Thornton, CO, US | ewellic.org From nobody Thu Oct 20 18:11:48 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 BF3DB1293F2 for ; Thu, 20 Oct 2016 18:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.452 X-Spam-Level: X-Spam-Status: No, score=-7.452 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=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 81gE9vDEbbPj for ; Thu, 20 Oct 2016 18:11:45 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76092124281 for ; Thu, 20 Oct 2016 18:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1477012305; x=1508548305; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GsK0MWb6NmXCkSbJTtxZVIUDGRqEGt4jrmBcZrjcXSQ=; b=Vs60/QV34r6Ox7BafEMHt6+ArFaI7yBjbg5QfqKVbJx5hkOuRDnM/9nv fl8tZLyq2jzVtq1XqdkafHoRpAEXdoG5J0EWrFcUQXfBK+edlg7Ym/smf RLFNimp8je0DPvwXs+erKlyfgxFVABhzjOLuWmZj7tK3FcTHsvgTdu5BV U=; X-IronPort-AV: E=Sophos;i="5.31,521,1473145200"; d="scan'208";a="233625213" Received: from unknown (HELO Ironmsg03-L.qualcomm.com) ([10.53.140.110]) by wolverine01.qualcomm.com with ESMTP; 20 Oct 2016 18:11:43 -0700 X-IronPort-AV: E=McAfee;i="5700,7163,8324"; a="1246294575" Received: from nasanexm01c.na.qualcomm.com ([10.85.0.83]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Oct 2016 18:11:42 -0700 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01C.na.qualcomm.com (10.85.0.83) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 20 Oct 2016 18:11:42 -0700 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1178.000; Thu, 20 Oct 2016 18:11:42 -0700 From: "Lundblade, Laurence" To: Sean Leonard Thread-Topic: [Cbor] translating simple value undef to JSON Thread-Index: AQHSKwzj/cT1ZCRk7UGqZLk6uj+HN6CyamEAgAAlAoA= Date: Fri, 21 Oct 2016 01:11:41 +0000 Message-ID: <7E010F09-E6B7-4E8D-8F5F-19A5B98D9399@qti.qualcomm.com> References: <9D6916CA-7DDC-4691-BC16-0050E128016C@qti.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.107.6] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cbor@ietf.org" Subject: Re: [Cbor] translating simple value undef to JSON 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, 21 Oct 2016 01:11:47 -0000 OK. Thx. Didn=92t have my heart set on it and have lots of other reasonable= options.=20 LL On Oct 20, 2016, at 3:59 PM, Sean Leonard wrote: > On 10/20/2016 1:02 PM, Lundblade, Laurence wrote: >> Seems like JSON doesn=92t have the value =93undef=94 but CBOR does. Is t= here some thinking on how to translate it, or should any protocol designed = to convert to JSON just not use undef? >=20 > Don't use undef. >=20 > At least, not in "that way" (i.e., where you expect undefined to exist in= JSON). It won't round-trip. You would need to co-opt another value and mar= k it "special", but that would take away from being able to use that value = in your protocol. I.e., adds complexity. >=20 > I suppose you might consider using an invalid UTF-16 sequence, such as th= e single character "\uDFFF". That will not round-trip into CBOR strings bec= ause CBOR only permits UTF-8, which /should/ be well-formed. (There is leew= ay in RFC 7049 that leaves open the possibility that ill-formed UTF-8 might= be acceptable; check it out.) Your special encoder or decoder could recogn= ize this special character and convert accordingly. >=20 > Sean >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor