From nobody Sat Aug 1 06:43:01 2020 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 87ABA3A044A for ; Sat, 1 Aug 2020 06:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 uUXGLFNZ7JCn for ; Sat, 1 Aug 2020 06:42:58 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 E48093A0433 for ; Sat, 1 Aug 2020 06:42:57 -0700 (PDT) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-05v.sys.comcast.net with ESMTP id 1rkzkFIYs5Foj1rmqkAwpU; Sat, 01 Aug 2020 13:42:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1596289376; bh=vI8gWDqJXknG005VAPYOfe5RhkSraR1TvnxFvXah5/U=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=TM/W988/HWVpAZ7UDEgvFDgxIqTeuZOaW5YQ8gA04PYtm3GuYLoitdtikkZu8hesi ZETI5RVk75FtRoLRoHEO/IzMLExBPQRDo1YTSztn1zZUnoo5YXNF3QzU1HQYufeT2f +uVWlpaN9OgqTeWf4fP/ea5obZ4OnkpSj3vwjOyLV4GTyC0Afw8YNnXffc5LRT3ws4 7F4/IsyG6+Sgqj+gbw3sdKNKXIjE9uIhu9kxK9bsYvMdmNmEJVsSKHyWb7ugH18suX n3rYDxSc2CjDA+RvogCJOJjJq51IaANnP+j85u8h3eCUrmjJnVfP+ni9yRYGf1YD0p TLPg7mxIpWG0g== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-03v.sys.comcast.net with ESMTPA id 1rmpk7JWXf3P01rmpkJNAA; Sat, 01 Aug 2020 13:42:56 +0000 X-Xfinity-VMeta: sc=0.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 071HgftT022386 for ; Sat, 1 Aug 2020 13:42:41 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 071HgfpH022383; Sat, 1 Aug 2020 13:42:41 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: cbor@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Sat, 01 Aug 2020 13:42:41 -0400 Message-ID: <87h7tmxnxq.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [Cbor] draft-ietf-cbor-tags-oid-00.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2020 13:43:00 -0000 Reading this (and having read an earlier version), I really like the concept because I have a fondness for OIDs and think they should be used to name everything. But there is a welter of problems around being able to "factor" an OID tag out of an array or map. Abstractly, if one can factor, one should be able to factor the tag out of any number of layers of structure. The trouble with that is that it makes decoding difficult, as the decoder needs to keep the application of the tag in mind as it descends through structures. It would seem consistent that other tags might be defined with this behavior, in which case a decoder might need to keep several factored tags in mind as it is descending through structures. Comparing with other types, a homogeneous array of OIDs is very like a homogeneous array of integers, for which we already have a mechanism for one-dimensional arrays. OID arrays could be handled similarly, although things are more complex because OIDs don't have a fixed-length encoding. What isn't parallel with previous mechanisms is factoring from *maps*. And that's novel because the factored tag applies to the keys but not the values. The reason for that is a bit arbitrary, and seems to be because that's convenient for encoding X.500 certificates. Factoring seems to be hard to do; trying to make it semantically consistent and aligned with possible future tags with similar behavor seems to require complex behaviors in the decoder. Though this proposal saves about 10% in X.500 distinguished name encoding. Then again, are distinguished names ever used when they aren't paired with keys (which are much longer)? Dale From nobody Sat Aug 1 07:21:53 2020 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 EA2693A0849 for ; Sat, 1 Aug 2020 07:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=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 OhKnZ8PWhMfM for ; Sat, 1 Aug 2020 07:21:41 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F1D3A0A9B for ; Sat, 1 Aug 2020 07:21:40 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BJmYF1G43zydy; Sat, 1 Aug 2020 16:21:36 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <87h7tmxnxq.fsf@hobgoblin.ariadne.com> Date: Sat, 1 Aug 2020 16:21:36 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 617984495.851436-ae95b6f0403eaec1c7c17a485153744c Content-Transfer-Encoding: quoted-printable Message-Id: <18B0842C-B5B6-4F6D-B2F3-180A26B8F002@tzi.org> References: <87h7tmxnxq.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-tags-oid-00.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2020 14:21:51 -0000 Hi Dale, > On 2020-08-01, at 19:42, Dale R. Worley wrote: >=20 > Reading this (and having read an earlier version), I really like the > concept because I have a fondness for OIDs and think they should be = used > to name everything. I hope not :-) > But there is a welter of problems around being able to "factor" an OID > tag out of an array or map. >=20 > Abstractly, if one can factor, one should be able to factor the tag = out > of any number of layers of structure. The trouble with that is that = it > makes decoding difficult, as the decoder needs to keep the application > of the tag in mind as it descends through structures. Indeed. I think we=E2=80=99ll have to restrict that to exactly one = layer, i.e., an OID tag applied to an array or a map influences the = elements/entries of that, nothing else. (Note that this is also related to prefix compression, which is provided = by packed cbor [draft-bormann-cbor-packed].) > It would seem consistent that other tags might be defined with this > behavior, in which case a decoder might need to keep several factored > tags in mind as it is descending through structures. I believe that is a complication worth arguing about. > Comparing with other types, a homogeneous array of OIDs is very like a > homogeneous array of integers, for which we already have a mechanism = for > one-dimensional arrays. OID arrays could be handled similarly, = although > things are more complex because OIDs don't have a fixed-length = encoding. (Integers also don=E2=80=99t have a fixed length encoding when used in a = tag 41 homogeneous array [RFC8746]; but there is no specific processing = specified for these.) > What isn't parallel with previous mechanisms is factoring from *maps*. > And that's novel because the factored tag applies to the keys but not > the values. The reason for that is a bit arbitrary, and seems to be > because that's convenient for encoding X.500 certificates. Exactly. Maps mapping OIDs to OIDs are not that useful, so applying the = factoring to both rarely makes sense, AFAICS. (Map) keys or values only = makes more sense. And I think keys wins, because that is a likely = case. > Factoring seems to be hard to do; trying to make it semantically > consistent and aligned with possible future tags with similar behavor > seems to require complex behaviors in the decoder. Though this = proposal > saves about 10% in X.500 distinguished name encoding. Then again, are > distinguished names ever used when they aren't paired with keys (which > are much longer)? (Crypto) keys don=E2=80=99t have to be much longer, see = https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-01#appe= ndix-A for a worked example. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Aug 1 16:29:25 2020 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 A87933A103D for ; Sat, 1 Aug 2020 16:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 W2wWVTvFzeqH for ; Sat, 1 Aug 2020 16:29:22 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1097A3A103C for ; Sat, 1 Aug 2020 16:29:21 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 1 Aug 2020 16:29:16 -0700 From: Jim Schaad To: 'Brendan Moran' CC: Date: Sat, 1 Aug 2020 16:29:14 -0700 Message-ID: <04b501d6685b$932fbbe0$b98f33a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdZoVSw+vsBVJFTHSuO8kQ2a2dqqlw== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] To be signed with packed CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2020 23:29:24 -0000 Brendan, I know that this is currently an academic question, but something you said in the SUIT meeting has me slightly worried. The problem with being the note taker is that you never have anytime to mentally go down the channels of ideas that pop up. One of the things that you said is that the use of packed CBOR would make things better when there are multiple authentication structures on what is basically the same data. The problem is that if you do the packing prior to doing the signature, then you end up in the situation where you need somehow to also include the packing dictionary in the data that is being signed. I don't have enough knowledge of how the manifest works but if after a signing, one can add more information to the manifest and then apply packing to that section which could add more items to the packed lookup tables thus breaking the signatures. All, This is one of the reasons that I was asking questions about doing the signature on a packed or unpacked version of the data. The idea of adding things which might alter the lookup tables at the root means that you have problems knowing that what was signed is what is validated without doing things like walking the content to extract a new pair of lookup tables to include as part of the signed content. Jim From nobody Sat Aug 1 23:24:27 2020 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 9E6BB3A08EE for ; Sat, 1 Aug 2020 23:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.949, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mxes.net 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 H2tucUnDlxx5 for ; Sat, 1 Aug 2020 23:24:23 -0700 (PDT) Received: from smtp-out-3.mxes.net (smtp-out-3.mxes.net [198.205.123.68]) (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 7FD003A08E4 for ; Sat, 1 Aug 2020 23:24:23 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DD03E75967 for ; Sun, 2 Aug 2020 02:24:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mxes.net; s=mta; t=1596349461; bh=NdN450WOJ50AN63JOzdxHRZwG3PY3+Wy6x68vozrmww=; h=Subject:To:References:From:Date:In-Reply-To:From; b=uy4IVzCywz2RYdc0i6j9dIhzUJJzuAPxYXXr5svRznuumoUn3RcJonYe2Egbji8qv kgnZ0q6qB0ZvE+Gt7n5KJeSa4InHDoiAZdkBVabWmoEly6lTFSEcMeV/dhWBycPRYQ k2GiyaA8XDemTODAVr9KMzKC81+a3WZEg9SEdI94= To: cbor@ietf.org References: <87h7tmxnxq.fsf@hobgoblin.ariadne.com> From: Sean Leonard Message-ID: <72e2157f-3915-542d-3b1e-2ef89b972cfe@seantek.com> Date: Sat, 1 Aug 2020 23:22:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <87h7tmxnxq.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sent-To: Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-tags-oid-00.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 06:24:26 -0000 On 8/1/2020 10:42 AM, Dale R. Worley wrote: > Reading this (and having read an earlier version), I really like the > concept because I have a fondness for OIDs and think they should be used > to name everything. Yep, me too. :-) > > But there is a welter of problems around being able to "factor" an OID > tag out of an array or map. > > Abstractly, if one can factor, one should be able to factor the tag out > of any number of layers of structure. The trouble with that is that it > makes decoding difficult, as the decoder needs to keep the application > of the tag in mind as it descends through structures. > > It would seem consistent that other tags might be defined with this > behavior, in which case a decoder might need to keep several factored > tags in mind as it is descending through structures. I believe in several earlier drafts (like the one from a couple of years ago), there was a lot more text on the issue of tag factoring in general--of which OIDs were just a notable example. See below. > > Comparing with other types, a homogeneous array of OIDs is very like a > homogeneous array of integers, for which we already have a mechanism for > one-dimensional arrays. OID arrays could be handled similarly, although > things are more complex because OIDs don't have a fixed-length encoding. The byte 0x80 *never* appears in an OID or Relative-OID ("ROID"). Therefore, the byte 0x80 can be used in a byte string to delimit multiple OIDs. In that regard it is similar to JSON Sequences (RFC 7464). > What isn't parallel with previous mechanisms is factoring from *maps*. > And that's novel because the factored tag applies to the keys but not > the values. The reason for that is a bit arbitrary, and seems to be > because that's convenient for encoding X.500 certificates. > > Factoring seems to be hard to do; trying to make it semantically > consistent and aligned with possible future tags with similar behavor > seems to require complex behaviors in the decoder. The original goal of the prior text was to come up with a semantically consistent way to factor tags out of arrays and maps, with the specific intention of saying "this is an array of identifiers" (e.g., OIDs or UUIDs) with one byte at the front, rather than an array with N tag bytes for N items. I believe the last extended discussion about this was in draft-bormann-cbor-tags-oid-06, which was considerably longer. Whether tags should be factored as a general semantic thing, might be more appropriately a topic of a different Internet-Draft. > Though this proposal > saves about 10% in X.500 distinguished name encoding. Then again, are > distinguished names ever used when they aren't paired with keys (which > are much longer)? It looks like draft-bormann-cbor-tags-oid-06 from a long time ago has an example of a distinguished name semantically transposed into CBOR, in Section 8.2. I am aware of two interchange formats for distinguished names: X.680 DER (aka "ASN.1") and LDAP string format, RFC 4514. I once wrote a parser that could go between the two with ease. Although I wrote the example of DN in CBOR in draft-bormann-cbor-tags-oid-06, I am not sure what other implementations would prefer to do. If the DN is (from that application's perspective) just a binary blob to lob over to the crypto stack, maybe a tag for a DER-encoded distinguished name would be better than a CBOR transliteration. In such a case, the distinguished name tag could be defined as <> bstr = DER, <> tstr = LDAP string format, and <> array of maps of OIDs to values = CBOR structured format. Sean From nobody Sat Aug 1 23:40:58 2020 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 506303A0919 for ; Sat, 1 Aug 2020 23:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 SYVh-c2rSC1B for ; Sat, 1 Aug 2020 23:40:55 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087613A094B for ; Sat, 1 Aug 2020 23:40:54 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BKBH86r3bzysQ; Sun, 2 Aug 2020 08:40:52 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <72e2157f-3915-542d-3b1e-2ef89b972cfe@seantek.com> Date: Sun, 2 Aug 2020 08:40:52 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 618043252.51878-6695f7a214818291d0fffe7b4eabc526 Content-Transfer-Encoding: quoted-printable Message-Id: <3CB26038-56EC-43A9-A4EF-7FF89E36FFA0@tzi.org> References: <87h7tmxnxq.fsf@hobgoblin.ariadne.com> <72e2157f-3915-542d-3b1e-2ef89b972cfe@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-tags-oid-00.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 06:40:57 -0000 On 2020-08-02, at 08:22, Sean Leonard wrote: >=20 > The byte 0x80 *never* appears in an OID or Relative-OID ("ROID").=20 Huh? 1.2.3.16384 =3D=3D h=E2=80=992a 03 81 80 00=E2=80=99 Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Aug 2 06:07:27 2020 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 F0A263A0DF3 for ; Sun, 2 Aug 2020 06:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.949, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mxes.net 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 M_rVO6tmwEdN for ; Sun, 2 Aug 2020 06:07:23 -0700 (PDT) Received: from smtp-out-3.mxes.net (smtp-out-3.mxes.net [198.205.123.68]) (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 3A1B73A0DF7 for ; Sun, 2 Aug 2020 06:07:23 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4BAF17599E for ; Sun, 2 Aug 2020 09:07:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mxes.net; s=mta; t=1596373641; bh=fuqpSwiC7clKNY1rxTZrCyTk7nKaX8n3VKb2UQJ5nl4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=HknpRPmzpt/+28sG0YdZL8nDhyV4ExswnWwjqB/qohhCL4D3LGQzj4kfnkXs7GqX6 h+2cGeBPmexJF/Lt3RqrjU1e+wvykJj3fhmmP95DuEB8zdmAWoc06Sboz0X2+kxFaX zmBwZGf5udnEFsgaz7ANvqW7rjq+jeiSHGAvP75Y= To: cbor@ietf.org References: <87h7tmxnxq.fsf@hobgoblin.ariadne.com> <72e2157f-3915-542d-3b1e-2ef89b972cfe@seantek.com> <3CB26038-56EC-43A9-A4EF-7FF89E36FFA0@tzi.org> From: Sean Leonard Message-ID: <522ce728-c6ea-f7aa-ef3c-240db0908815@seantek.com> Date: Sun, 2 Aug 2020 06:05:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <3CB26038-56EC-43A9-A4EF-7FF89E36FFA0@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Sent-To: Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-tags-oid-00.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 13:07:26 -0000 On 8/1/2020 11:40 PM, Carsten Bormann wrote: > On 2020-08-02, at 08:22, Sean Leonard wrote: >> The byte 0x80 *never* appears in an OID or Relative-OID ("ROID"). > Huh? > > 1.2.3.16384 =3D=3D h=E2=80=992a 03 81 80 00=E2=80=99 Whoops, you are right. I think I was thinking of something else, namely,=20 that bit 8 cannot appear at the end of an encoded OID: it has to end=20 with 0x00-0x7F. So yeah, 0x80-0xFF at the end of a bstr is an out-of-band signal, but it=20 does not appear that it can be followed by a new OID, since 0x00-0x7F=20 would just mean a new arc of the current OID. Sean > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Sun Aug 2 20:06:27 2020 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 D84DF3A0FB2 for ; Sun, 2 Aug 2020 20:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.975 X-Spam-Level: X-Spam-Status: No, score=0.975 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 rRbdv0A_3QFE for ; Sun, 2 Aug 2020 20:06:25 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 7A1CA3A0FAF for ; Sun, 2 Aug 2020 20:06:25 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id 2QjBkeuTX9HJI2QnvkleTH; Mon, 03 Aug 2020 03:06:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1596423983; bh=0gEVVt7NxnDcbA4fu5oIkUYvt4R8DCRD+inw0rS5u4s=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=G43p7uFX9myKATpiZG0KEIWysIEoo+6fg8Z01zoaCN2zWh07DWzR6klC2xksx2hnL VLs5y9EvMoGQPkcrwlHno3hrOEXNajKDPwPTNLKav79O4HGjhBh+EL6ckiyhN/0yWs xllqTGvO9TAQHYRKxOW0TL4Lka6/SXuvY+vt92t7m5uRUJeXJVxme0m/MGtS8qgYmI iKotwuv2SAYUOGwFhenqwdGFwZk2rkkQMLrigRhS9wCsTJI7FlydpKy4qibqxYAGGO r3Me0DuQUq8uy7+B438FBd1jlovdwTw8SMSX6oBy2RwSnRzCURwPRltSzbyZyaSCCB +R/jJDaVFwK1A== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-09v.sys.comcast.net with ESMTPA id 2Qnmk9bftvArG2QnvkMrGy; Mon, 03 Aug 2020 03:06:23 +0000 X-Xfinity-VMeta: sc=0.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 07375xcd024352; Mon, 3 Aug 2020 03:05:59 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 07375xcN024349; Mon, 3 Aug 2020 03:05:59 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Sean Leonard Cc: cbor@ietf.org In-Reply-To: <522ce728-c6ea-f7aa-ef3c-240db0908815@seantek.com> (dev+ietf@seantek.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 03 Aug 2020 03:05:58 -0400 Message-ID: <87zh7cw6nd.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-tags-oid-00.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 03:06:27 -0000 Sean Leonard writes: > Whoops, you are right. I think I was thinking of something else, namely, > that bit 8 cannot appear at the end of an encoded OID: it has to end > with 0x00-0x7F. Well, you could delimit a sequence of concatenated OIDs by *prefixing* each one with 0x80, so you can scan the byte string for occurrences of 0x80 immediately preceded by a byte 0x00-0x7F. That costs 1 byte per OID, and is probably the best you can do with a simple system. OTOH, a sequence of CBOR-encoded octet strings that are less than ~23 octets only requires a one byte prefix for each as well, if the OID-ness is implied by some mechanism. Dale From nobody Sun Aug 2 20:23:37 2020 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 7C6CB3A044A for ; Sun, 2 Aug 2020 20:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.975 X-Spam-Level: X-Spam-Status: No, score=0.975 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 LmseEUE9QUEr for ; Sun, 2 Aug 2020 20:23:31 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 81A933A043A for ; Sun, 2 Aug 2020 20:23:31 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id 2QyBkQQvTPdj92R4Ukr4mh; Mon, 03 Aug 2020 03:23:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1596425010; bh=xYuy2azE8PbT3i8aWqEzGBD6cH9yPvsUQEhqIVKuzvg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=qrC6b1nwZDx1r+oyFD8JQjNC+2jDU89G3Rkaryj3NWSglVoT1t98yiqkFBvXY3Ftb d3zfdkmSoLqVXY+TKokJ3f1Qn2KQaE2trroz5gcvK+gM4auW4R417m5hXe7KNQtFie QQqtRmZ2tFwFNgwJnhmIPPfcDCqvT5PmJGpMpSRpVvSZRg9XBFXclHisrD/UtMhkeq EkVL6jczpr9UxF2aeUDFRamqXDym05FjvoIIn+/QnbAg/VLehkR/S8T3wRZI20fLrU EOwDaVGfLHltJkaoEa49aCpiaB5Dh66wSP5Kq0/2awp8NmUOO4v9XhF5PgMdyv4Juq rrnjLHQLn3Kvw== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-17v.sys.comcast.net with ESMTPA id 2R4Skjtz1gljM2R4TkHkww; Mon, 03 Aug 2020 03:23:30 +0000 X-Xfinity-VMeta: sc=0.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 0737NDA5025861 for ; Mon, 3 Aug 2020 03:23:13 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 0737NCfK025858; Mon, 3 Aug 2020 03:23:12 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: cbor@ietf.org In-Reply-To: <18B0842C-B5B6-4F6D-B2F3-180A26B8F002@tzi.org> (cabo@tzi.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 03 Aug 2020 03:23:12 -0400 Message-ID: <87v9i0w5un.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-tags-oid-00.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 03:23:35 -0000 Carsten Bormann writes: > (Crypto) keys don't have to be much longer, see > https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-01#appendix-A > for a worked example. I don't know elliptic-curve crypto well enough to follow that, but it seems to me that you're going to have a hard time putting a 2048 bit key in less than about 256 octets, and the signature will need a similar number of octets. So all overheads should be counted against a minimum of 512 octets of essentially binary data. From: Sean Leonard writes: > The most authoritative dotted-decimal OID style definition that I could > find is in the LDAP specs, namely in RFC 4512. There is an OID namespace for URNs which uses dotted-decimal syntax; the first version is RFC 3001 (Apr 2000), which refers to RFC 1778 section 2.15 (Mar 1995). Dale From nobody Sun Aug 2 22:38:50 2020 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 53E863A0B2B for ; Sun, 2 Aug 2020 22:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 peCegBHLkPRv for ; Sun, 2 Aug 2020 22:38:45 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCFF13A0B2D for ; Sun, 2 Aug 2020 22:38:44 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BKmry2trMzyTN; Mon, 3 Aug 2020 07:38:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <87v9i0w5un.fsf@hobgoblin.ariadne.com> Date: Mon, 3 Aug 2020 07:38:42 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 618125921.952752-d94cf930ba64bde14452fe8d0360924f Content-Transfer-Encoding: quoted-printable Message-Id: References: <87v9i0w5un.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-tags-oid-00.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 05:38:48 -0000 On 2020-08-03, at 09:23, Dale R. Worley wrote: >=20 > Carsten Bormann writes: >> (Crypto) keys don't have to be much longer, see >> = https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-01#appe= ndix-A >> for a worked example. >=20 > I don't know elliptic-curve crypto well enough to follow that, but it > seems to me that you're going to have a hard time putting a 2048 bit = key That would be RSA. Applications that care about certificate size today = use ECC, with 256-bit keys (32 bytes). > in less than about 256 octets, and the signature will need a similar > number of octets. So all overheads should be counted against a = minimum > of 512 octets of essentially binary data. Five years ago, yes. But now it is worth to use ECC as a yard stick. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 3 01:58:11 2020 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 737683A0CBA for ; Mon, 3 Aug 2020 01:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=MtiQnOEV; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=MtiQnOEV 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 x1Es_kIGmCDF for ; Mon, 3 Aug 2020 01:58:07 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10066.outbound.protection.outlook.com [40.107.1.66]) (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 168F33A0CB7 for ; Mon, 3 Aug 2020 01:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hj/cqDpAhw8yGtu2vR0csqRSqluvjhHXqnpQU8Si5Gs=; b=MtiQnOEVYF5Smb+UIwq80I2n8I9RQJUwa3/fWf/+YwSyFiyoBcodRxzPFJiri72qCR4x64t9gI1b3b6u49/Rjy5lEbs4BXekfnQEnzGbwrdmWFWwZiX2xcAkMuZHzYs/L6P2zWx9qrBfn27DHRsm8qEY4jL5TfIwnYlxVIlPi5k= Received: from AM5P194CA0006.EURP194.PROD.OUTLOOK.COM (2603:10a6:203:8f::16) by VI1PR0802MB2334.eurprd08.prod.outlook.com (2603:10a6:800:9d::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Mon, 3 Aug 2020 08:57:59 +0000 Received: from AM5EUR03FT025.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:8f:cafe::b5) by AM5P194CA0006.outlook.office365.com (2603:10a6:203:8f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Mon, 3 Aug 2020 08:57:59 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT025.mail.protection.outlook.com (10.152.16.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20 via Frontend Transport; Mon, 3 Aug 2020 08:57:58 +0000 Received: ("Tessian outbound 1c27ecaec3d6:v62"); Mon, 03 Aug 2020 08:57:58 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: cbd44d147d2fb159 X-CR-MTA-TID: 64aa7808 Received: from 9b70d5c6e891.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id DD1DE17C-9B1F-4CC4-B8CC-FD600926A972.1; Mon, 03 Aug 2020 08:57:53 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 9b70d5c6e891.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 03 Aug 2020 08:57:53 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dp0xIL43m2xjx1kTgR0+9Z4qdwwOgCtajBx6M5o79sXqlG1EYq3uDLgvS9DTrzEZ/TtAP7BAuLP1csd2IHaZedVsUyZEuXEdjM87m/jSvKKnP2JbwVR42Os6TpukU4GdsdAoMmZOp3SN17YFVmyVWjiVSEzmH+Ie3C3aTAuPJ3PMkAW8snAaOU1yuqk5k6tEsSL3sO/3BwESC52v7laGzQazDOBHDGfyAxtEqGp8InbSGUp19SufcjP1l0nJKzHCnI7rSSXpSzllc4mqqDaCTltALFteOTHWW2CtcIXmgaXVDdyLJKgAjRm6zzPafSDq9ZPPy2R7Wh8DLvCjoySp5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hj/cqDpAhw8yGtu2vR0csqRSqluvjhHXqnpQU8Si5Gs=; b=aSZduVQYZ14xrd4x2Q9OIvkBN8n9r4pjjuYJ6CySRqNnqHI54Y94hjP7g8sOXrnoUkPku40Le0zDqDfGjJeKPXQdbxR0fsOiCZFDytHvlDyU41ZhYTazGKrh6C32wk+u5sRMIEHnpakN+NBxbjRu5WPRuyWK35ULnQzfX5utruF+cvCJSu1jjzhXBYk5zc6RnSpvJlc9o+jv2g4SdjmmEB3mKEX7XACAxFgbVqj9/lwrKRhgPzTciKEI8ZqCMke3nzA8u64q0Sao3KjHQ4YifmGc43LRSo9TOwvF+i5af/18q6E2FSooS97vwha6x5neQXbbfnQlE/iELbf4uGXe8A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hj/cqDpAhw8yGtu2vR0csqRSqluvjhHXqnpQU8Si5Gs=; b=MtiQnOEVYF5Smb+UIwq80I2n8I9RQJUwa3/fWf/+YwSyFiyoBcodRxzPFJiri72qCR4x64t9gI1b3b6u49/Rjy5lEbs4BXekfnQEnzGbwrdmWFWwZiX2xcAkMuZHzYs/L6P2zWx9qrBfn27DHRsm8qEY4jL5TfIwnYlxVIlPi5k= Received: from AM6PR08MB4738.eurprd08.prod.outlook.com (2603:10a6:20b:cf::10) by AM6PR08MB4804.eurprd08.prod.outlook.com (2603:10a6:20b:c9::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Mon, 3 Aug 2020 08:57:51 +0000 Received: from AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56]) by AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56%3]) with mapi id 15.20.3239.021; Mon, 3 Aug 2020 08:57:51 +0000 From: Brendan Moran To: Jim Schaad CC: "cbor@ietf.org" Thread-Topic: To be signed with packed CBOR Thread-Index: AdZoVSw+vsBVJFTHSuO8kQ2a2dqqlwBHv4AA Date: Mon, 3 Aug 2020 08:57:51 +0000 Message-ID: References: <04b501d6685b$932fbbe0$b98f33a0$@augustcellars.com> In-Reply-To: <04b501d6685b$932fbbe0$b98f33a0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) Authentication-Results-Original: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.20.19.206] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 3cb0f286-cf80-4401-23b7-08d8378b51f4 x-ms-traffictypediagnostic: AM6PR08MB4804:|VI1PR0802MB2334: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: G+EolOmY8U1FulnS3GU2bWkAa+9w2Q2sKD/5g8uJ1wdRtFRjUqR/ohvAWcJXqNnLrw/tLqNR9f7tqPNXyqhPe4vXf6jdGF+bZhqRlcdwEkCRFM8Rk0xx8a0tu8E8hmH/mAkFCgsCNfiHIfCVM7HTtBtxfohIumvy4qubFxLB3vzc++Hw7hCcLVmLC9RlWywVnhi4Vmbp8dn7ljWMfcWdr8RTgceipr6Aib6n3bQJLoARGDAlASlnb0Y+MqfL95e042bmS8SJRGEEnD20l/7fqz6XyaatDXsOmcPN2VJrWGV6QKdHXf6tMLALQIYibTGqewNiOX9U2i74nUhspFlacw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4738.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(136003)(396003)(346002)(366004)(8676002)(36756003)(83380400001)(2616005)(6916009)(316002)(33656002)(4326008)(2906002)(64756008)(66446008)(26005)(91956017)(66946007)(66476007)(5660300002)(66556008)(6486002)(186003)(6512007)(71200400001)(86362001)(53546011)(6506007)(478600001)(76116006)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: CYvnU3qxGXk37ow3H8GxFj1Fpe4SOacCwtUG2VQTGjiticdRiwd3STPsAWfttjpN2GHfPAaA/T+hln5fC95hp9MVdV4CrvLztqOeE/psUIX+gvb/NuzvHmcHCRKeMqyFVOXiE10iM9CbfMc7Ck26+1KpT01OgfSJRGaPkdxKkSRDXWgjO9p1DPRKkPjMyv8eR+CNeJ7nUlgViViU274GU7Ig/DEEmSr7lyoF9XZdEwxLBokPMJCTQB89UuZ288E2wekDSJ74giIhSJ+BjOmJUpLyVMvfgdAV1SxdhkGpGnnbRiBJ9ph7C9Ja7vXoeeyIDhAGIWVhUMdOwsshb6P0Zfm+9Zr1Wr3lWAIo8OVs9gfMG/EN57b6y330I7vqKsJTLzEFibMsf7UJnSHviQZJkIb2RqB6Mu1fbM7SNmmVxMZXEN9KkbtjbBH+1QvktWy26y127poBRK0dmVYmoDu/cze1CAYhbHHroHrVpNYx53b7mHNWCyWqRNzFKNgm4nk3+A8d+YSZZ5htxf3Js5iNNh9a8K+XXvvUlm7k4XVFTlCN4e3ugtanXQloeb7B6d/hcRMVUQubtSZUxKaRQjmT76AFz3Ga+XI4PYK8u9nR5yaCfvPuOjBvwNn8pGFOzioahKdRR8458L9/p/ExfJNBTQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <29E33F1C46A3654083A3FE43CC28E0AD@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4804 Original-Authentication-Results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT025.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 179ab597-ee7f-4510-8d76-08d8378b4dac X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 594MrQNcxI0yNbLWShdqFmr2uEEuyGowz+Xoa5LsLVZljRpGTkiCNmy29pLfqDDDPdwxLz7OwoSx0ZpcWbT9h3bw55Utp7fCihP75HGlkSRjXC7a7IryZy5dq8F7L5mS5IzgM9RVjJ8v/mvLVtmYBmEwrSrk1GiN6YpuChxe6slnmOBEiPR9gb1wk1uqMot/m3BrHecvUzcNwzws5sDbhiMXWGBIupgdjCqGJl1IrSVmXMhG1+4aRn/EOmuCOhf7TP/W6TqwuHe4MRLcfpLAg0EqJZThd8EKoh2sIleogYKEle4mEFU0VIfxT3tfHclR1xxrGtKqXM9wnc5LBfIvqgY2NtGAK48HxO2H1rQYUguSqr0B86/lGdntSR2P68upfA/DMyaJc8EIVGiWn1+Svw== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(376002)(346002)(46966005)(5660300002)(82740400003)(26005)(70586007)(47076004)(36906005)(186003)(83380400001)(53546011)(33656002)(6506007)(81166007)(70206006)(356005)(316002)(82310400002)(336012)(2616005)(6862004)(6512007)(8936002)(86362001)(2906002)(6486002)(36756003)(8676002)(4326008)(478600001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2020 08:57:58.7212 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3cb0f286-cf80-4401-23b7-08d8378b51f4 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT025.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2334 Archived-At: Subject: Re: [Cbor] To be signed with packed CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 08:58:09 -0000 SGkgSmltLA0KDQo+IE9uIDIgQXVnIDIwMjAsIGF0IDAwOjI5LCBKaW0gU2NoYWFkIDxpZXRmQGF1 Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCj4NCj4gQnJlbmRhbiwNCj4NCj4gSSBrbm93IHRoYXQg dGhpcyBpcyBjdXJyZW50bHkgYW4gYWNhZGVtaWMgcXVlc3Rpb24sIGJ1dCBzb21ldGhpbmcgeW91 IHNhaWQNCj4gaW4gdGhlIFNVSVQgbWVldGluZyBoYXMgbWUgc2xpZ2h0bHkgd29ycmllZC4gIFRo ZSBwcm9ibGVtIHdpdGggYmVpbmcgdGhlDQo+IG5vdGUgdGFrZXIgaXMgdGhhdCB5b3UgbmV2ZXIg aGF2ZSBhbnl0aW1lIHRvIG1lbnRhbGx5IGdvIGRvd24gdGhlIGNoYW5uZWxzDQo+IG9mIGlkZWFz IHRoYXQgcG9wIHVwLg0KPg0KPiBPbmUgb2YgdGhlIHRoaW5ncyB0aGF0IHlvdSBzYWlkIGlzIHRo YXQgdGhlIHVzZSBvZiBwYWNrZWQgQ0JPUiB3b3VsZCBtYWtlDQo+IHRoaW5ncyBiZXR0ZXIgd2hl biB0aGVyZSBhcmUgbXVsdGlwbGUgYXV0aGVudGljYXRpb24gc3RydWN0dXJlcyBvbiB3aGF0IGlz DQo+IGJhc2ljYWxseSB0aGUgc2FtZSBkYXRhLiAgVGhlIHByb2JsZW0gaXMgdGhhdCBpZiB5b3Ug ZG8gdGhlIHBhY2tpbmcgcHJpb3IgdG8NCj4gZG9pbmcgdGhlIHNpZ25hdHVyZSwgdGhlbiB5b3Ug ZW5kIHVwIGluIHRoZSBzaXR1YXRpb24gd2hlcmUgeW91IG5lZWQgc29tZWhvdw0KPiB0byBhbHNv IGluY2x1ZGUgdGhlIHBhY2tpbmcgZGljdGlvbmFyeSBpbiB0aGUgZGF0YSB0aGF0IGlzIGJlaW5n IHNpZ25lZC4gIEkNCj4gZG9uJ3QgaGF2ZSBlbm91Z2gga25vd2xlZGdlIG9mIGhvdyB0aGUgbWFu aWZlc3Qgd29ya3MgYnV0IGlmIGFmdGVyIGENCj4gc2lnbmluZywgb25lIGNhbiBhZGQgbW9yZSBp bmZvcm1hdGlvbiB0byB0aGUgbWFuaWZlc3QgYW5kIHRoZW4gYXBwbHkgcGFja2luZw0KPiB0byB0 aGF0IHNlY3Rpb24gd2hpY2ggY291bGQgYWRkIG1vcmUgaXRlbXMgdG8gdGhlIHBhY2tlZCBsb29r dXAgdGFibGVzIHRodXMNCj4gYnJlYWtpbmcgdGhlIHNpZ25hdHVyZXMuDQoNCkkgdGhpbmsgd2Ug cHJvYmFibHkgZ290IG91ciB3aXJlcyBjcm9zc2VkIGhlcmUuIFRoZXJl4oCZcyBhIGZldyBwb2lu dHMgdG8gdGhpczoNCg0KMS4gU1VJVCBpcyBvcmdhbmlzZWQgaW4gc3VjaCBhIHdheSB0aGF0IG9u ZSB3b3VsZCBwcm9iYWJseSBwYWNrIHRoZSBDT1NFIG9iamVjdHMgYW5kIHRoZSBub24tQ09TRSBv YmplY3RzIGluIHNlcGFyYXRlLCBub24tb3ZlcmxhcHBpbmcgcGFja2VkIENCT1Igc3RydWN0dXJl cy4gVGhpcyBzaG91bGQgbWVhbiB0aGF0IHlvdSBkbyBub3QgcmVxdWlyZSBhIHNpZ25hdHVyZSBv dmVyIHRoZSBkaWN0aW9uYXJ5IGZvciBDT1NFIHBhY2tpbmcuDQoNCjIuIFdpdGggbmVzdGVkIHBh Y2tlZCBDQk9SLCB3ZSBtaWdodCBuZWVkIGEgd2F5IHRvIHNwZWNpZnkgd2hldGhlciB0aGUgcGFj a2VyIHJlY3Vyc2VkIGludG8gYW4gYWxyZWFkeS1wYWNrZWQgb2JqZWN0IG9yIG5vdC4gVGhhdCB3 b3VsZCBicmluZyB1cyBiYWNrIHRvIHRoZSBzaXR1YXRpb24gaW4gMS4NCg0KQXMgYSBydWxlLCBJ IHN1c3BlY3Qgd2Ugc2hvdWxkIGFzc3VtZSB0aGF0IGFueSBkaWN0aW9uYXJ5IHNob3VsZCBhcHBs eSB0byBlaXRoZXIgdW5hdXRoZW50aWNhdGVkIG9iamVjdHMgT1IgYXV0aGVudGljYXRlZCBvYmpl Y3RzLCBidXQgTkVWRVIgYm90aC4gVGhpcyB3aWxsIHJlcXVpcmUgdXMgdG8gZGlzdGluZ3Vpc2gg YmV0d2VlbiByZWN1cnNpdmVseSBwYWNrZWQgKG5lc3RlZCBvYmplY3QgY29udGFpbnMgcmVmZXJl bmNlcyB0byBlbmNsb3Npbmcgb2JqZWN0IGRpY3Rpb25hcnkpIGFuZCBzaW1wbHkgcGFja2VkIChu ZXN0ZWQgb2JqZWN0IGNvbnRhaW5zIG5vIHJlZmVyZW5jZXMgdG8gZW5jbG9zaW5nIG9iamVjdCBk aWN0aW9uYXJ5KSBvYmplY3RzLiBUaGlzIG1heSByZXF1aXJlIGEgdGFnLg0KDQpCcmVuZGFuDQoN Cj4NCj4gQWxsLA0KPg0KPiBUaGlzIGlzIG9uZSBvZiB0aGUgcmVhc29ucyB0aGF0IEkgd2FzIGFz a2luZyBxdWVzdGlvbnMgYWJvdXQgZG9pbmcgdGhlDQo+IHNpZ25hdHVyZSBvbiBhIHBhY2tlZCBv ciB1bnBhY2tlZCB2ZXJzaW9uIG9mIHRoZSBkYXRhLiAgVGhlIGlkZWEgb2YgYWRkaW5nDQo+IHRo aW5ncyB3aGljaCBtaWdodCBhbHRlciB0aGUgbG9va3VwIHRhYmxlcyBhdCB0aGUgcm9vdCBtZWFu cyB0aGF0IHlvdSBoYXZlDQo+IHByb2JsZW1zIGtub3dpbmcgdGhhdCB3aGF0IHdhcyBzaWduZWQg aXMgd2hhdCBpcyB2YWxpZGF0ZWQgd2l0aG91dCBkb2luZw0KPiB0aGluZ3MgbGlrZSB3YWxraW5n IHRoZSBjb250ZW50IHRvIGV4dHJhY3QgYSBuZXcgcGFpciBvZiBsb29rdXAgdGFibGVzIHRvDQo+ IGluY2x1ZGUgYXMgcGFydCBvZiB0aGUgc2lnbmVkIGNvbnRlbnQuDQo+DQo+IEppbQ0KPg0KPg0K DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0 dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRo ZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Mon Aug 3 10:22:17 2020 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 2A7083A0F8C for ; Mon, 3 Aug 2020 10:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=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 5nTe_oLpMtVM for ; Mon, 3 Aug 2020 10:22:12 -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 AC2F93A1113 for ; Mon, 3 Aug 2020 10:21:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6197B389A2; Mon, 3 Aug 2020 13:01:08 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id brScOaXjdPSR; Mon, 3 Aug 2020 13:01:07 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ADE13389A0; Mon, 3 Aug 2020 13:01:07 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id ECC9D63B; Mon, 3 Aug 2020 13:21:44 -0400 (EDT) From: Michael Richardson To: Jim Schaad , 'Brendan Moran' , cbor@ietf.org In-Reply-To: <04b501d6685b$932fbbe0$b98f33a0$@augustcellars.com> References: <04b501d6685b$932fbbe0$b98f33a0$@augustcellars.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] To be signed with packed CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 17:22:15 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: > This is one of the reasons that I was asking questions about doing the > signature on a packed or unpacked version of the data. The idea of adding > things which might alter the lookup tables at the root means that you have > problems knowing that what was signed is what is validated without doing > things like walking the content to extract a new pair of lookup tables to > include as part of the signed content. Yes, I agree that this is a concern. I really think one needs to sign the packed content. The unpacking process seems like a place where exploitable bugs could surface, so allowing an attacker to control that input seems imprudent. Signing the packed content keeps attackers from being able to change things. A manufacturer that became aware of a problem in some path of the unpack code could avoid that kind of compression. Bootloaders may be hard/inconvenient to upgrade outside of controlled environments. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8oR6gACgkQgItw+93Q 3WXfSAf/UklmjQXW1Jz8ucxVC4iiTi5zZc5kK8mNW6ZPt/bJomCvt4Eu/92u0g8T ohaLvvy17MwCQDggBTxApss/HNlHDAxz7orcyRR1fJvJcN7LuGOKqVinO8TefMkR V1kvOWcA5CY08FvUsYlmZoQD/SNCwM+UjsLs2Ft/O0VfNsGHJUqGKYokJUnChdsr 0tQ/iQdqcK6ppPtg3f5wUorg2PwuOwF96u08leCyT9LUHkwiXbWGUVhR8GvQUXAZ CLkqhGU1bXt+Ku8V9s7RfygMlcTr6rFRbxJ8rKouDrKo4QpYVedkPB7lIQlSuyem A2E4yjsAMDrRPjmN30EP30zBA9RDZQ== =719C -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 3 12:39:56 2020 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 E43383A0ADA for ; Mon, 3 Aug 2020 12:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=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 dX8S-sYDdK7q for ; Mon, 3 Aug 2020 12:39:47 -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 66FD63A0A6D for ; Mon, 3 Aug 2020 12:39:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DBDEA389A2; Mon, 3 Aug 2020 15:19:08 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id afpp88gATHSX; Mon, 3 Aug 2020 15:19:05 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id EF5BC389A0; Mon, 3 Aug 2020 15:19:04 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4C60063E; Mon, 3 Aug 2020 15:39:42 -0400 (EDT) From: Michael Richardson To: Brendan Moran , "cbor\@ietf.org" In-Reply-To: References: <04b501d6685b$932fbbe0$b98f33a0$@augustcellars.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] To be signed with packed CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 19:39:52 -0000 --=-=-= Content-Type: text/plain Brendan Moran wrote: > As a rule, I suspect we should assume that any dictionary should apply > to either unauthenticated objects OR authenticated objects, but NEVER > both. Why? I don't understand. I think you are talking about external dictionaries, right? I agree that one needs to be sure that any dictionary is securely identified. A hash over the dictionary, included into the packed headers, and within the COSE signature should be enough. If another unauthenticated object wants to reference the same dictionary, how can that hurt? --- Now if we want to be able to form expandable dictionaries, maybe this won't quite work. I can imagine that it would be nice to have a dictionary that could be expanded with new items placed at the end, while still being able to serve older packed content. What if one asked for a dictionary with X items, with hash Y? > This will require us to distinguish between recursively packed > (nested object contains references to enclosing object dictionary) and > simply packed (nested object contains no references to enclosing object > dictionary) objects. This may require a tag. I think that I don't understand the origin of the attack you are concerned about here. Maybe some diagrams would help. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8oZ/4ACgkQgItw+93Q 3WUDgQgAnVqXQjJ+bMGz7bZigOqj9UfvX5lOJ7ZMf1j4C32LuJy9ySVQN50m9iSH 78gezsTbpXwvdU4Agg4Kazb7A/i/LnzM/o1qmXbQBxaociToE8u8iz/rDfl2dfY1 O9iwaKbpg25e6Bp+ZCWmXoE9/FooJ2Gv0Fr+rqizJCSpT2w5jBuAwpZvtbaXnQr4 XrCvnMR+vKRMpejRFW84v/3ZdSK/z47FOob8ONaaOBFgVI+i3AenmFKtc2IIuPo3 q6S2WBTwAaT8zBb9uoSISo+VtXi7IAt+LHSHyoNjFTr/knqEnVX7d3MeT6ZzNuj5 grT0bESk3pMsow+m5uuP0tnYltDtYQ== =+Rh2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 3 15:24:57 2020 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 E14803A0CF1 for ; Mon, 3 Aug 2020 15:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 9D5IL8jsQqpf for ; Mon, 3 Aug 2020 15:24:53 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC363A0CB0 for ; Mon, 3 Aug 2020 15:24:53 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BLC9v1430zyTb; Tue, 4 Aug 2020 00:24:51 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <24290.1596475304@localhost> Date: Tue, 4 Aug 2020 00:24:50 +0200 Cc: Jim Schaad , Brendan Moran , cbor@ietf.org X-Mao-Original-Outgoing-Id: 618186289.6268409-2194261e2eeb274e7647d77bc14495a8 Content-Transfer-Encoding: quoted-printable Message-Id: <6E7FE97D-3333-43E7-8BD2-D1554796E774@tzi.org> References: <04b501d6685b$932fbbe0$b98f33a0$@augustcellars.com> <24290.1596475304@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] To be signed with packed CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 22:24:56 -0000 On 2020-08-03, at 19:21, Michael Richardson = wrote: >=20 > I really think one needs to sign the packed content. Generally, we don=E2=80=99t sign the content (XMLDSig anyone?), but the = message. And that was packed. (And the whole point about packed CBOR = is that you may never need to fully unpack it.) The signing input does not need to be limited to that. So if there is = an external context that provides, e.g., dictionary IDs, I would expect = that to be part of the signing input (where the =E2=80=9CID=E2=80=9D = needs to uniquely identify an immutable dictionary for a signature, = either by hash, or by registry). Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 3 17:37:44 2020 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 1C4CD3A11B1; Mon, 3 Aug 2020 17:37:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: draft-ietf-cbor-date-tag.all@ietf.org, last-call@ietf.org, cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159650146206.14996.18192684961495413978@ietfa.amsl.com> Reply-To: Linda Dunbar Date: Mon, 03 Aug 2020 17:37:42 -0700 Archived-At: Subject: [Cbor] Genart last call review of draft-ietf-cbor-date-tag-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 00:37:42 -0000 Reviewer: Linda Dunbar Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-cbor-date-tag-05 Reviewer: Linda Dunbar Review Date: 2020-08-03 IETF LC End Date: 2020-08-14 IESG Telechat date: Not scheduled for a telechat Summary: This is a very simple draft, describing how calendar dates are represented, the same way as common knowledge on how calendar dates are represented. I am surprised that the draft is "STANDARD track". Why? The only thing might be that Tag 1004 is Text String, and Tag 100 is a negative integer. Is it all for a RFC? Section 1.3 states that Dates cannot be properly compared unless Time Zone is attached. Strangely, the Time Zone is not included in the tag 1004 or Tag 100. Why? Major issues: Minor issues: Nits/editorial comments: Best regards, Linda Dunbar From nobody Mon Aug 3 17:57:51 2020 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 391D33A11C8; Mon, 3 Aug 2020 17:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=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 IQBBeg8k4YDs; Mon, 3 Aug 2020 17:57:45 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0FB3A11C7; Mon, 3 Aug 2020 17:57:44 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 3 Aug 2020 17:57:37 -0700 From: Jim Schaad To: 'Linda Dunbar' , CC: , , References: <159650146206.14996.18192684961495413978@ietfa.amsl.com> In-Reply-To: <159650146206.14996.18192684961495413978@ietfa.amsl.com> Date: Mon, 3 Aug 2020 17:57:35 -0700 Message-ID: <053e01d669fa$4003f530$c00bdf90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQG9ChEKlhdJWGulY6hItQwMxaY9t6lZ3+rQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Genart last call review of draft-ietf-cbor-date-tag-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 00:57:46 -0000 -----Original Message----- From: Linda Dunbar via Datatracker =20 Sent: Monday, August 3, 2020 5:38 PM To: gen-art@ietf.org Cc: draft-ietf-cbor-date-tag.all@ietf.org; last-call@ietf.org; = cbor@ietf.org Subject: Genart last call review of draft-ietf-cbor-date-tag-05 Reviewer: Linda Dunbar Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area = Review Team (Gen-ART) reviews all IETF documents being processed by the = IESG for the IETF Chair. Please treat these comments just like any = other last call comments. For more information, please see the FAQ at . Document: draft-ietf-cbor-date-tag-05 Reviewer: Linda Dunbar Review Date: 2020-08-03 IETF LC End Date: 2020-08-14 IESG Telechat date: Not scheduled for a telechat Summary: This is a very simple draft, describing how calendar dates are = represented, the same way as common knowledge on how calendar dates are = represented. I am surprised that the draft is "STANDARD track". Why? The only = thing might be that Tag 1004 is Text String, and Tag 100 is a negative = integer.=20 Is it all for a RFC? Section 1.3 states that Dates cannot be properly compared unless Time = Zone is attached. Strangely, the Time Zone is not included in the tag = 1004 or Tag 100.=20 Why? [JLS] Linda, This section deals not with comparing Dates with each = other, but comparing Dates with Date/Time Values. This would mean that = comparing 01/01/2020 with 01/01/2020 3:59 PST does not make any sense = because one has a Time Zone and the other does not. Jim Major issues: Minor issues: Nits/editorial comments: Best regards, Linda Dunbar From nobody Tue Aug 4 12:28:18 2020 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 618C43A10EE for ; Tue, 4 Aug 2020 12:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 Z1wbUk6f9pej for ; Tue, 4 Aug 2020 12:28:15 -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 CE4EE3A0CD6 for ; Tue, 4 Aug 2020 12:28:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5E2D138996; Tue, 4 Aug 2020 15:07:31 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HTBa6GBRaTKh; Tue, 4 Aug 2020 15:07:30 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EAB7F38991; Tue, 4 Aug 2020 15:07:29 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2D7651F7; Tue, 4 Aug 2020 15:28:08 -0400 (EDT) From: Michael Richardson To: Brendan Moran , "cbor\@ietf.org" In-Reply-To: References: <5E28C6E2-DFEC-4AF5-96CE-75E8F0927818@arm.com> <01d901d66503$2bbd93c0$8338bb40$@augustcellars.com> <7216D806-3473-463E-B6F2-AD8724AC56C6@tzi.org> <021e01d66535$57827d90$068778b0$@augustcellars.com> <406B6702-3045-4490-8CD0-8E352F924714@arm.com> <24543.1596045216@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] Review: draft-bormann-cbor-packed-00 & SUIT X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 19:28:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brendan Moran wrote: >> Unless you mean that dictionaries should be sorted so that they alwa= ys (can only) >> reference forward, and you can start at the current location in the = current >> dictionary. > Possibly, but I=E2=80=99m not sure that=E2=80=99s universally advanta= geous. Remember > that we want high reference frequency items to be at the start. Suppo= se > that I have the prefixes [=E2=80=9Chttps://=E2=80=9C, =E2=80=9Cwww.= =E2=80=9D, =E2=80=9Cfiles.=E2=80=9D, > =E2=80=9Cdomain.com=E2=80=9D]. Clearly, I want to be able to compose = these in one of > two ways: I agree that sorting by frequency of us has CPU advantages. I'm not sure that this is important enough ("premature optimization is the root of all evil"). I think that I can put them together in any order in my CBOR, regardless of the order. The ordering just restrictions how the internal reference in the dictionary can work, right? > I think we need to be very clear about what=E2=80=99s allowed because > otherwise, there will be a lot of varied implementations with varied > limitations. Yes, as Carsten said, we need to tightly define the decoder :-) >>> - The compressor has to be aware of the dictionaries of packed CBOR >>> objects it traverses in order to pack anything that appears within = an >>> already packed CBOR object. >> >> In the SUIT case, the compressor is "cloud" :-) > Yup. Let=E2=80=99s not make things hard for constrained nodes because= it=E2=80=99s easier for unconstrained ones. If you are saying that sometimes the compressor will be a constrained node, because CBOR is used outside of SUIT (who knew?), then I would like to retract my comment involving that five-letter word. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8ptscACgkQgItw+93Q 3WX12Af+JtDKvzloxqab1OGSUuOfBY6ma2ulp0naFWAhXm37jgC52hhRLVTu1kzl F0//vj20eiBa2PHVRAXm3/9KFm+3pyn5JE8iGrlPZ+REhOiQ9ihOcynLH6qj4/Vq uHNQLL1b3u+pDmpczLVqmv19vyuzMv9pFFN1rovMvCGj7mTmxZel25ro+Bdr3bWS UzU5BuzhiZM+fZiwFoQTxF6E1P/nTy1/f3rCVUqAThvczxkV7NAxNlu4gyHns066 1spZbsNGmxjdxwkgSkHUIZrWhFTDo7Sc0ANm+97f2YwN4mXPruuZw+nYOX9wnEeN rHQwX8Pj3kSKx0pbTXsh7r+9b/cENg== =ngU4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 4 12:30:48 2020 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 1DA573A1128 for ; Tue, 4 Aug 2020 12:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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 fkZ2G4876FnE for ; Tue, 4 Aug 2020 12:30:45 -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 01B3F3A111A for ; Tue, 4 Aug 2020 12:30:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C814938996 for ; Tue, 4 Aug 2020 15:10:05 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wP0vD1VRIAKi for ; Tue, 4 Aug 2020 15:10:01 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4E63138991 for ; Tue, 4 Aug 2020 15:10:01 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 871E11F7 for ; Tue, 4 Aug 2020 15:30:39 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org In-Reply-To: <6E7FE97D-3333-43E7-8BD2-D1554796E774@tzi.org> References: <04b501d6685b$932fbbe0$b98f33a0$@augustcellars.com> <24290.1596475304@localhost> <6E7FE97D-3333-43E7-8BD2-D1554796E774@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] To be signed with packed CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 19:30:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 2020-08-03, at 19:21, Michael Richardson w= rote: >> >> I really think one needs to sign the packed content. > Generally, we don=E2=80=99t sign the content (XMLDSig anyone?), but t= he > message. And that was packed. (And the whole point about packed CBOR > is that you may never need to fully unpack it.) So we are all in agreement. > The signing input does not need to be limited to that. So if there is > an external context that provides, e.g., dictionary IDs, I would expe= ct > that to be part of the signing input (where the =E2=80=9CID=E2=80=9D= needs to uniquely > identify an immutable dictionary for a signature, either by hash, or = by > registry). We both agree that dictionary IDs (or hashes) have to be part of the signed content. But, are you saying that dictionaries used would be visible at the COSE level, such as in the protected bucket? I would think it's part of the signing input, because it's part of the "tag= -6" structure. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8pt18ACgkQgItw+93Q 3WXiAAf/UR38hkl8Vw4UVRyREEdpR097usKERaXw/UHH5n9+mFtQUXr1ILTmO5Le k/jQeEgppd/T3CKB08Oa8uQj5ZPEbCQXEIRpQ4dytg+8iQR9Rr/VqWjxGlsrSrDv SeMrPLg/l5By8wjTPwBhduaUKlCRK6wIi+8TWpv55JtGoESaFBgnIF+thXaK89mf s5Fn8WGn7dszd3NWLny1jS2tbBDMVLwK1MzJxXXjkOF0SVd1gMwCyVlnHr79vMJt f6wgkWk7QTsu2e8fLGcGM+f8EqoFCQD4ackXUOIQjai7Ak5mdDwJECbo0IRXQBvh MAbSUQmh2yhBTbC9P95uDlYccT8qVA== =5DRj -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 4 12:36:30 2020 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 344FA3A118E for ; Tue, 4 Aug 2020 12:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 8WXaRdtNmvPO for ; Tue, 4 Aug 2020 12:36:28 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1A03A1185 for ; Tue, 4 Aug 2020 12:36:27 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BLlP62crgzyhB; Tue, 4 Aug 2020 21:36:26 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <16372.1596569439@localhost> Date: Tue, 4 Aug 2020 21:36:23 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 618262583.9194109-8714c94052450835e965278c46561f43 Content-Transfer-Encoding: quoted-printable Message-Id: <76982161-384B-49E3-A093-F9109A6D4A72@tzi.org> References: <04b501d6685b$932fbbe0$b98f33a0$@augustcellars.com> <24290.1596475304@localhost> <6E7FE97D-3333-43E7-8BD2-D1554796E774@tzi.org> <16372.1596569439@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] To be signed with packed CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 19:36:30 -0000 On 2020-08-04, at 21:30, Michael Richardson = wrote: >=20 > I would think it's part of the signing input, because it's part of the = "tag-6" structure. It is conceivable that an application has pre-defined dictionaries = (e.g., see RFC 3485). You would never send these on the wire, possibly = not even a hash. So the signing input somehow needs to uniquely imply = the context that makes you include that dictionary. By the way, the order in the prefix/sharing tables is only relevant at = the boundaries between 1-byte, 2-byte, and 3-byte references. There = will be very few 1-byte references (in the current proposal, 16 for = sharing and 1 for prefix), so the packer should have control over what = goes there. It is getting a bit more relaxed after that. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Aug 5 09:44:10 2020 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 7C7803A0CDF; Wed, 5 Aug 2020 09:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 vfILJUXmzF61; Wed, 5 Aug 2020 09:44:08 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650112.outbound.protection.outlook.com [40.107.65.112]) (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 C3C563A0CD7; Wed, 5 Aug 2020 09:44:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L61EKwXMKS9CWK8Wjoh1q2cX77dgeG157nuE6HACqn9kB6IkucwdaDd9zB3X8e+5pgVZeq64+tfVieGBuB57+b2zpZJ1L6SObqY/6pHO0nh586zqJg3tJWxGeYsNPJV3DEv7eROdWahPuTvc9i2viC1JIz8+6Zn0yO+o9XPBgACpIxWeM0Ro+aJYCLlWmY1TNDq/ur2UWKSUNFyTazwY4BFF6EelDCcv89iSXhgR+j99ZKYry7mBwatlLkzJkhr6PKWtbnI8R99cWvHKNsG4wb84tNSb14c2Xj1wb+IsuFAgHAZexl1Ts4GNuq/KM+PpsX7SH+XveGHeTb3dIQnBdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TlP8pwk2uIKuLzVZpKzDffAV8t/LBBA1FOAsxiI/Sjk=; b=mxEMQbMEfyL6NZdFS/buLow5aO7gdH7a+kjGFX/8JKxE7WVhVp+RseNq49BV9u3fnfQAqNoyHA/GlW+LrG9sGoQaA3blVvh12FIX5gCMm/oWZs+2csqdWQDIoyfeG9I/fnJRAMwRdyk0sd38EhFuI3TNcplNPD9Y2ZUMJ/ChgGtSnYR/KaP1idgHxSAWYH3vUBCceZGt8Smhz3zH0HpqMRLRN1KsEdtqtzBnj9Ume5+9bgt598gBjle7qAjQbSgPzTSt7nFjtnbQQaJTzSCAEXkKGXHjAVSR7slqUREtOwK9fNFd64TrwH/nRxluxSLl9UqV4Qn6ihtrTkcVVAXkTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TlP8pwk2uIKuLzVZpKzDffAV8t/LBBA1FOAsxiI/Sjk=; b=jig3lC4MPWf/QzNT9otMjEtPWuZRNBGqWaqsafm4QyJ+fRJ1O2TCq/xa0ey5NDpmhDasKQHaytC6WRvN4EbUkwZzplUDjkt/IRPBJVxoU02d+l75GV7+WSBI9pAxPtzZzCon2DpgtEn0HW+rYrVuPurvDeQ6B9GmX32hqMcNfPg= Received: from BY5PR00MB0676.namprd00.prod.outlook.com (2603:10b6:a03:20c::15) by BY5PR00MB0758.namprd00.prod.outlook.com (2603:10b6:a03:1d2::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3296.0; Wed, 5 Aug 2020 16:44:05 +0000 Received: from BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::646d:8d71:fe30:cab1]) by BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::646d:8d71:fe30:cab1%8]) with mapi id 15.20.3303.000; Wed, 5 Aug 2020 16:44:05 +0000 From: Mike Jones To: Jim Schaad , 'Linda Dunbar' , "gen-art@ietf.org" CC: "draft-ietf-cbor-date-tag.all@ietf.org" , "last-call@ietf.org" , "cbor@ietf.org" Thread-Topic: Genart last call review of draft-ietf-cbor-date-tag-05 Thread-Index: AdZrR56iR8VziRpJSYCLGwUlJdjbXA== Date: Wed, 5 Aug 2020 16:44:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-05T16:30:45Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=7fc028a0-9745-4ec0-a6bf-bc63d3b6eba3; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.88.234] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b2e97b97-a473-400e-2021-08d8395ec45f x-ms-traffictypediagnostic: BY5PR00MB0758: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gQTSCToHaHNdbMTbRp5z+78OKQ5/FT97t4A/r3Olv5HA4ZWkuBvADOoHGAM4rB5eQ3gnQAw4CtpCScEcMk09t6gpN/FLenh05IoZQLxCFGmNdunNJ/hnLAGjHsrxfGuAAQl0q34nN2BHHoxswWlSonOqBCA6MMTB/GM2hp2MqFebZirVC7gkA7dcGuUb25u0PV7/m0lqWtc7yr6k9rcsZKAYAdTnfkemMPgKL4UX07tjLZR3uKi4IGaL5zvioA3yuBmtuCoyEQHFpgFTGhaDSIdAgE7keNZN+mxXB2PXomnXSF0x+owv7bv7DrJNuxLLEH0jhA2mgAn3QkV8LSLlYwGVlPGBbWYRcQeamE6OsJN5vTYuo2+APvj4fTI0c4PQrc8CH/ycKJVg7EuSwfo/BA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR00MB0676.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(136003)(366004)(376002)(346002)(7696005)(10290500003)(66446008)(66556008)(66946007)(53546011)(33656002)(83380400001)(316002)(54906003)(64756008)(76116006)(66476007)(2906002)(6506007)(478600001)(110136005)(4326008)(71200400001)(8936002)(86362001)(82960400001)(26005)(8990500004)(55016002)(82950400001)(9686003)(5660300002)(966005)(8676002)(52536014)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ZhCfD1MZjYlC0MjLMvvRzYeKBzjKiMnkIGHG2zBbtEhG9HmGJSVs6Xpq3xwqSK3ZFkh2PJioFzS2aZwIDKX5NTJIEeEirXwdWCq2yn9s7HrdbinE1V6qgrX+D3cBGoUQ+BBBKfR5HERCx3JeZzWmJ2hqUApRl/uXrLYg2do9EqX3cDu8gD6ScHS0t7Dw6PG8UbVP+p0wpJ474ZtDT2P9yXRPnd4mOM69voaE/+HHBYblWAI7zTdOSci6SmOX1U7Ts08ObsgyTqttufWJe/hp1rLTs/yTaEsCEC+bBPNi9maTJYaEdfi0SS2O1e4QtDR5mpFOOKoUB88yfFXUL8MDc+YhBYoLxKeH75nI7gvMUYSwRWmI3kz6DPx86T74DHjzVDn4nvNR3tMi4bHpiy3EN4S8DMc4Rys/A7a4rSNeigL+3mCWsFJpSxu7FMpL/OLF9nZqSPKA1eoVPUzrmpISoO6a/Z4wNEtMXctdv1duk3+g8zW4x/W4SFkVatNwHAWgrjqTcntNiKRE7qSjx7TzKPlLSRv6yITtE2S1Ov9SxeZ2o+nPCJBG1wHF45FQdx2VzXzbBwba0Wny4HAC7wp8kMgD0lempP7MkNRrJeNVNeQp94G72siE9ahgEeGLhMA4aXfltgAvShIHfF9kQ6drxQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR00MB0676.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b2e97b97-a473-400e-2021-08d8395ec45f X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2020 16:44:05.4882 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Jf7iWTDMSjsgzpJPooadqiDfMRPOBt2WCtzdFe3U0re+hL3+/vq/maX+0Y0Hz2FnlDwfSsXy7mNfkj2R0uy5VQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR00MB0758 Archived-At: Subject: Re: [Cbor] Genart last call review of draft-ietf-cbor-date-tag-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 16:44:10 -0000 SSBhZ3JlZSB3aXRoIEppbSdzIHJlc3BvbnNlIHRvIHRoZSBjb21wYXJpc29uIHF1ZXN0aW9uLg0K DQpBbiBSRkMgaXMgYmVpbmcgY3JlYXRlZCBiZWNhdXNlIGEgdGFnIGlzIGJlaW5nIHJlZ2lzdGVy ZWQgaW4gdGhlIFNwZWNpZmljYXRpb24gUmVxdWlyZWQgcmFuZ2Ugb2YgdGhlIFRhZ3MgUmVnaXN0 cnkgc3BlY2lmaWVkIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDQ5I3NlY3Rp b24tNy4yLg0KDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4gDQpTZW50OiBNb25kYXksIEF1 Z3VzdCAzLCAyMDIwIDU6NTggUE0NClRvOiAnTGluZGEgRHVuYmFyJyA8bGluZGEuZHVuYmFyQGZ1 dHVyZXdlaS5jb20+OyBnZW4tYXJ0QGlldGYub3JnDQpDYzogZHJhZnQtaWV0Zi1jYm9yLWRhdGUt dGFnLmFsbEBpZXRmLm9yZzsgbGFzdC1jYWxsQGlldGYub3JnOyBjYm9yQGlldGYub3JnDQpTdWJq ZWN0OiBSRTogR2VuYXJ0IGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jYm9yLWRhdGUt dGFnLTA1DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExpbmRhIER1bmJh ciB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+IA0KU2VudDogTW9uZGF5LCBBdWd1 c3QgMywgMjAyMCA1OjM4IFBNDQpUbzogZ2VuLWFydEBpZXRmLm9yZw0KQ2M6IGRyYWZ0LWlldGYt Y2Jvci1kYXRlLXRhZy5hbGxAaWV0Zi5vcmc7IGxhc3QtY2FsbEBpZXRmLm9yZzsgY2JvckBpZXRm Lm9yZw0KU3ViamVjdDogR2VuYXJ0IGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jYm9y LWRhdGUtdGFnLTA1DQoNClJldmlld2VyOiBMaW5kYSBEdW5iYXINClJldmlldyByZXN1bHQ6IFJl YWR5IHdpdGggSXNzdWVzDQoNCkkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9y IHRoaXMgZHJhZnQuIFRoZSBHZW5lcmFsIEFyZWEgUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmll d3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRyBmb3IgdGhl IElFVEYgQ2hhaXIuICBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBv dGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNCkZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ug c2VlIHRoZSBGQVEgYXQNCg0KPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dl bkFydGZhcT4uDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLWNib3ItZGF0ZS10YWctMDUNClJldmll d2VyOiBMaW5kYSBEdW5iYXINClJldmlldyBEYXRlOiAyMDIwLTA4LTAzDQpJRVRGIExDIEVuZCBE YXRlOiAyMDIwLTA4LTE0DQpJRVNHIFRlbGVjaGF0IGRhdGU6IE5vdCBzY2hlZHVsZWQgZm9yIGEg dGVsZWNoYXQNCg0KU3VtbWFyeToNCiAgICBUaGlzIGlzIGEgdmVyeSBzaW1wbGUgZHJhZnQsIGRl c2NyaWJpbmcgaG93IGNhbGVuZGFyIGRhdGVzIGFyZSByZXByZXNlbnRlZCwNCiAgICB0aGUgc2Ft ZSB3YXkgYXMgY29tbW9uIGtub3dsZWRnZSAgb24gaG93IGNhbGVuZGFyIGRhdGVzIGFyZSByZXBy ZXNlbnRlZC4gIEkNCiAgICBhbSBzdXJwcmlzZWQgdGhhdCB0aGUgZHJhZnQgaXMgIlNUQU5EQVJE IHRyYWNrIi4gIFdoeT8gIFRoZSBvbmx5IHRoaW5nDQogICAgbWlnaHQgYmUgdGhhdCBUYWcgMTAw NCBpcyBUZXh0IFN0cmluZywgYW5kIFRhZyAxMDAgaXMgYSBuZWdhdGl2ZSBpbnRlZ2VyLiANCiAg ICBJcyBpdCBhbGwgZm9yIGEgUkZDPw0KDQpTZWN0aW9uIDEuMyBzdGF0ZXMgdGhhdCBEYXRlcyBj YW5ub3QgYmUgcHJvcGVybHkgY29tcGFyZWQgdW5sZXNzIFRpbWUgWm9uZSBpcyBhdHRhY2hlZC4g U3RyYW5nZWx5LCB0aGUgVGltZSBab25lIGlzIG5vdCBpbmNsdWRlZCBpbiB0aGUgdGFnIDEwMDQg b3IgVGFnIDEwMC4gDQogV2h5Pw0KDQpbSkxTXSBMaW5kYSwgVGhpcyBzZWN0aW9uIGRlYWxzIG5v dCB3aXRoIGNvbXBhcmluZyBEYXRlcyB3aXRoIGVhY2ggb3RoZXIsIGJ1dCBjb21wYXJpbmcgRGF0 ZXMgd2l0aCBEYXRlL1RpbWUgVmFsdWVzLiAgVGhpcyB3b3VsZCBtZWFuIHRoYXQgY29tcGFyaW5n IDAxLzAxLzIwMjAgd2l0aCAwMS8wMS8yMDIwIDM6NTkgUFNUIGRvZXMgbm90IG1ha2UgYW55IHNl bnNlIGJlY2F1c2Ugb25lIGhhcyBhIFRpbWUgWm9uZSBhbmQgdGhlIG90aGVyIGRvZXMgbm90Lg0K DQpKaW0NCg0KDQpNYWpvciBpc3N1ZXM6DQoNCk1pbm9yIGlzc3VlczoNCg0KTml0cy9lZGl0b3Jp YWwgY29tbWVudHM6DQoNCkJlc3QgcmVnYXJkcywNCkxpbmRhIER1bmJhcg0KDQoNCg0K From nobody Mon Aug 10 02:00:57 2020 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 1D1893A1414; Mon, 10 Aug 2020 02:00:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: cbor@ietf.org, last-call@ietf.org, draft-ietf-cbor-7049bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159705005508.2366.4819563096010229406@ietfa.amsl.com> Reply-To: Yaron Sheffer Date: Mon, 10 Aug 2020 02:00:55 -0700 Archived-At: Subject: [Cbor] Secdir last call review of draft-ietf-cbor-7049bis-14 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 09:00:55 -0000 Reviewer: Yaron Sheffer Review result: Has Nits This is an editorial, fully compatible update of RFC 7049 (the CBOR encoding). The Security Considerations have been significantly expanded, and they make sense to me. However, while the prose is all sensible, it doesn't seem like the best practical guidance for implementers. I would have appreciated a bullet list of potential implementation pitfalls, as well as a bullet list of decoder validation capabilities, such as are alluded to by the last sentence of the section. Upon a quick read, it is not even clear to me which parts of Sec. 5 are required/expected in a validating-mode decoder. From nobody Mon Aug 10 11:47:49 2020 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 6D3F33A0B10; Mon, 10 Aug 2020 11:47:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kyle Rose via Datatracker To: Cc: draft-ietf-cbor-date-tag.all@ietf.org, last-call@ietf.org, cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159708526736.13725.2565339809870274299@ietfa.amsl.com> Reply-To: Kyle Rose Date: Mon, 10 Aug 2020 11:47:47 -0700 Archived-At: Subject: [Cbor] Secdir last call review of draft-ietf-cbor-date-tag-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 18:47:47 -0000 Reviewer: Kyle Rose Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready with nits. I see no issues of interest to the security directorate. I do have three comments, however: * In the security considerations section, a better example might be the potential inappropriateness of using an imprecise mechanism for specifying certificate expiration. * It's not clear how this is intended to work for dates prior to the start of the Gregorian calendar in 1582. What do negative integer values mean when they imply a date before 15-Oct-1582? Is the Gregorian calendar defined for all time? In a brief investigation, I've been unable to find the answer to this. * In a very gross sense, this specification *is* actually tied to the prevailing timescale, leap seconds and all: if the whole world were to transition from UTC to TAI and stop adding leap seconds, presumably implementations would continue to generate dates for this specification by truncating the local timestamp to the date, which would cause it to drift along with TAI away from UTC over time. There wouldn't be a huge practical effect here given how little they are expected to diverge over the foreseeable future, but it would mean that dates encoded in this format today would not carry enough information to precisely indicate a date in the far future even if the target timescale were understood throughout since the source timescale isn't part of the encoding. From nobody Mon Aug 10 12:27:20 2020 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 3DC453A0CC9 for ; Mon, 10 Aug 2020 12:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 0HbzIDajtXuW for ; Mon, 10 Aug 2020 12:27:15 -0700 (PDT) Received: from p3plsmtpa09-01.prod.phx3.secureserver.net (p3plsmtpa09-01.prod.phx3.secureserver.net [173.201.193.230]) (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 535073A0C8E for ; Mon, 10 Aug 2020 12:27:11 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 5DPjkCbls3pta5DPkk3dLg; Mon, 10 Aug 2020 12:24:56 -0700 X-CMAE-Analysis: v=2.3 cv=ea1DgIMH c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=48vgC7mUAAAA:8 a=83biogrR7TfdnlKm6MUA:9 a=CjuIK1q_8ugA:10 a=-lDN3miqRCKsXIsiMS0A:9 a=RqEnPhNPTZkw_uGG:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_ACC591DB-889D-4050-85EF-D388D1BE4D85" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 10 Aug 2020 12:24:55 -0700 In-Reply-To: <159705005508.2366.4819563096010229406@ietfa.amsl.com> Cc: secdir@ietf.org, cbor@ietf.org, draft-ietf-cbor-7049bis.all@ietf.org, last-call@ietf.org To: Yaron Sheffer References: <159705005508.2366.4819563096010229406@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfIbeHPiwZF4IonxJzsDM5rW5WvhFRTxqsxC1OmatxkGRbpK2MBUz0nES+hvuLzV+XZB1Fma0L4kyXgYdBqrCNuTAvLSrR41SyvYB7Leu4vdplKVnF0VI dGc1bOsXG/n6pPmavKKj92SRJMloZuUz9FSQZpNQN9Ze0D1/+e6nw6wr/puhxggTkPWzsbIy0u+a+t5Q0u1jdwfLOS2EL9yoG+aF6NLcIu2q0qXmBGtatZHZ GCnWgc5GWxjlzKasHSy3bOMZJxyozBFrpzBU8OWUxGy8StwAOmgWRgNPbbIhs//hUdJXNYl+bVApGyb50A6N8Q== Archived-At: Subject: Re: [Cbor] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:27:19 -0000 --Apple-Mail=_ACC591DB-889D-4050-85EF-D388D1BE4D85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 10, 2020, at 2:00 AM, Yaron Sheffer via Datatracker = wrote: >=20 > Upon a quick read, it is not even clear to me which parts of Sec. 5 > are required/expected in a validating-mode decoder. A generic decoder can do as little or as much validity checking as it = wants to. What is required is that it documents what validity checking = it does not do and that it does not prevent the user of the generic = decoder from doing the validity checks. The reason for this is that some validity checking is expensive for a = CBOR decoder and is inexpensive for the consumer of the data. Checking = the validity of UTF-8 or MIME-encoded messages are examples of this. LL= --Apple-Mail=_ACC591DB-889D-4050-85EF-D388D1BE4D85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Aug 10, 2020, at 2:00 AM, Yaron Sheffer via Datatracker <noreply@ietf.org> = wrote:

Upon a quick read, it is not = even clear to me which parts of Sec. 5
are required/expected in a validating-mode = decoder.

A = generic decoder can do as little or as much validity checking as it = wants to. What is required is that it documents what validity checking = it does not do and that it does not prevent the user of the generic = decoder from doing the validity checks.

The reason for this is that some = validity checking is expensive for a CBOR decoder and is inexpensive for = the consumer of the data. Checking the validity of UTF-8 or MIME-encoded = messages are examples of this.

LL
= --Apple-Mail=_ACC591DB-889D-4050-85EF-D388D1BE4D85-- From nobody Mon Aug 10 13:24:55 2020 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 B64143A0D2B; Mon, 10 Aug 2020 13:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.573, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Og2E5w1YjSrW; Mon, 10 Aug 2020 13:24:48 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 408563A0D23; Mon, 10 Aug 2020 13:24:48 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id a5so9404428wrm.6; Mon, 10 Aug 2020 13:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=AKfSvr1qGuFtK9wmI2mKX+3hnGeItBCCnnZZ5gyPh7o=; b=GxXvMXUpWoreJTJkb4lUz29qZk0tGszqmL3hqjPnTnwuZScpXHSIYzaZacNKQ9C6n2 eEsqwWuaGLD9KMfmJLXUomJWk1hC1cbpc2JO5VSSTX5JWNr0jMVWxUbqVrGnMLZD+3LD JVjCUFzrvFSih2QR58ptBy1VHuj6GXs8Vms5pHC0lA8Qgh0Rh3A4NhpffDIWiKSMLJse pAt1oHbgpApWbzp2sN/O3XdizodWmH/p6k2TA/0SaIInpdjAlqtsK8Z7n76vcxCZcvwy 9z9DejuQLIFlzrUoIf6bTIBMBoFdg/uns8wXEh+6W3MZXjYZV06QC0OTcbilasHq/Mmt H7Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=AKfSvr1qGuFtK9wmI2mKX+3hnGeItBCCnnZZ5gyPh7o=; b=QV/P9hDAtZA9YEBriPBnP0Uijtd2759Ff2AdWGlj0O56qEXgnypqJuG9vT+O3CGdVC w67FNtOD+1yTuUdTRi4DOaAAbDtA3/h+8wEKkLFj8LqrWex1qHqCSkqJquapl9Ei7/Mf qzWS7+mUYbBTIAXiEGBcneSXEybasOcB1/wtumGn2u60ASn5HHrecpmraTWU0hBywo6A Vkg9CW25FXb3WATamTKzXWpjZE1TxOXRXNfc5bY5plANQJnnl/i5MSBt4CSqtGGh2/oh wyWcPN6UL2cQRxSCjjGI2Z+9YUlTMDLDbPxE6V1Lr08bzzZ2yuBnWkiITYi6BFD9DHbR Eifw== X-Gm-Message-State: AOAM530JsGjYYIahYBYejryhRArJ3yDhdwiYiS6NXhIGo6RNSjr6MqVL oeWeRgYIPsvPYZA4NNPTV3M= X-Google-Smtp-Source: ABdhPJykGYa+NKNrPKOTSnvnPIOSZWtcrIFZUCqJap+PdQlCWE5m+IX3F5OTyl+1e5kI+2MoQR1ioA== X-Received: by 2002:a5d:400e:: with SMTP id n14mr2911146wrp.75.1597091086812; Mon, 10 Aug 2020 13:24:46 -0700 (PDT) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id p6sm21626062wru.33.2020.08.10.13.24.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2020 13:24:46 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Mon, 10 Aug 2020 23:24:44 +0300 From: Yaron Sheffer To: Laurence Lundblade CC: , , , Message-ID: Thread-Topic: [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 References: <159705005508.2366.4819563096010229406@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3679946685_595924970" Archived-At: Subject: Re: [Cbor] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 20:24:50 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3679946685_595924970 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On Aug 10, 2020, at 2:00 AM, Yaron Sheffer via Datatracker wrote: =20 Upon a quick read, it is not even clear to me which parts of Sec. 5 are required/expected in a validating-mode decoder. =20 A generic decoder can do as little or as much validity checking as it wants= to. What is required is that it documents what validity checking it does no= t do and that it does not prevent the user of the generic decoder from doing= the validity checks. =20 The reason for this is that some validity checking is expensive for a CBOR = decoder and is inexpensive for the consumer of the data. Checking the validi= ty of UTF-8 or MIME-encoded messages are examples of this. =20 LL =20 I understand that, but realistically, without a list of (potential) validit= y checks in the RFC, there will be wide variance in what is documented by de= coders =E2=80=93 if any. In fact I checked a few implementations just now, and mos= t of them do not document what validity checks they perform. Those that docu= ment something are hard to compare. If you make a canonical list, people wou= ld have a starting point. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron --B_3679946685_595924970 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

On Aug 10, 2020, at 2:00 AM, Yaron Sheffer via Dat= atracker <noreply@ietf.org> wrot= e:

 

Upon a quick read, it is not even= clear to me which parts of Sec. 5
are required/expected in a validating-= mode decoder.

 

A generic decoder can do as = little or as much validity checking as it wants to. What is required is that= it documents what validity checking it does not do and that it does not pre= vent the user of the generic decoder from doing the validity checks.

 

The reason for this is that some validity checking is expensive = for a CBOR decoder and is inexpensive for the consumer of the data. Checking= the validity of UTF-8 or MIME-encoded messages are examples of this.

 

LL

 

I understand that, but realistically, without a list of (potent= ial) validity checks in the RFC, there will be wide variance in what is docu= mented by decoders =E2=80=93 if any. In fact I checked a few implementations just = now, and most of them do not document what validity checks they perform. Tho= se that document something are hard to compare. If you make a canonical list= , people would have a starting point.

=  

Thanks,

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

--B_3679946685_595924970-- From nobody Mon Aug 10 13:31:29 2020 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 2CC2C3A0D23 for ; Mon, 10 Aug 2020 13:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 SRlRe-9W_cfs for ; Mon, 10 Aug 2020 13:31:26 -0700 (PDT) Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (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 65E873A0D32 for ; Mon, 10 Aug 2020 13:31:26 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 5ES5khEwTIGql5ES5kTCjl; Mon, 10 Aug 2020 13:31:26 -0700 X-CMAE-Analysis: v=2.3 cv=DMrxHBFb c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=LrfFbBZ_wH084i7_Up0A:9 a=QEXdDO2ut3YA:10 a=-RC9aWaX5pnV8SCgf80A:9 a=FkYPizaky_nWIz-_:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0F3FBFC2-638C-4BCC-B7FB-140628B61867" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 10 Aug 2020 13:31:25 -0700 In-Reply-To: Cc: secdir@ietf.org, cbor@ietf.org, draft-ietf-cbor-7049bis.all@ietf.org, last-call@ietf.org To: Yaron Sheffer References: <159705005508.2366.4819563096010229406@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfKN/6HdOYYBE+KfQcZObCH+tvjgMdeoFo8uPNc8ZdjbzNH/yF0EU2G2E7c6sErcBvJOjFzD8vZzEMULk3qtUlJvGYVR8r0NRys7mS44H0YMQg8s+Pyzy GvNIiKcbTIdF4GQuR0PSpeGnkxHgBwhFzHIE0eLyfLtoGbolzHOMYaWQGUDP6Y9fiNwdnirSNVL9iBd3RrrrNGFtbjal/OGzTTT+mOQE4ccpR+Y0oBdhB2vk vFvTtRxe19PUkN+1/IhjdZsbvyLNcB6RGT7B1wzueVD/sicNfdqvYDTrQtkl1aEhht7241sgzoy7y/34J7mbsw== Archived-At: Subject: Re: [Cbor] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 20:31:28 -0000 --Apple-Mail=_0F3FBFC2-638C-4BCC-B7FB-140628B61867 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 10, 2020, at 1:24 PM, Yaron Sheffer = wrote: >=20 > On Aug 10, 2020, at 2:00 AM, Yaron Sheffer via Datatracker = > wrote: >> =20 >> Upon a quick read, it is not even clear to me which parts of Sec. 5 >> are required/expected in a validating-mode decoder. >=20 > =20 > A generic decoder can do as little or as much validity checking as it = wants to. What is required is that it documents what validity checking = it does not do and that it does not prevent the user of the generic = decoder from doing the validity checks. > =20 > The reason for this is that some validity checking is expensive for a = CBOR decoder and is inexpensive for the consumer of the data. Checking = the validity of UTF-8 or MIME-encoded messages are examples of this. > =20 > LL > =20 > I understand that, but realistically, without a list of (potential) = validity checks in the RFC, there will be wide variance in what is = documented by decoders =E2=80=93 if any. In fact I checked a few = implementations just now, and most of them do not document what validity = checks they perform. Those that document something are hard to compare. = If you make a canonical list, people would have a starting point. Having made a few crude lists of validity checks myself to try to = understand what was what, such a list seems reasonable to me. LL --Apple-Mail=_0F3FBFC2-638C-4BCC-B7FB-140628B61867 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 10, 2020, at 1:24 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

On Aug 10, 2020, at 2:00 = AM, Yaron Sheffer via Datatracker <noreply@ietf.org> wrote:
 
Upon a = quick read, it is not even clear to me which parts of Sec. 5
are required/expected in a validating-mode = decoder.
 
A generic decoder can do as little or = as much validity checking as it wants to. What is required is that it = documents what validity checking it does not do and that it does not = prevent the user of the generic decoder from doing the validity = checks.
 
The reason for this is that some = validity checking is expensive for a CBOR decoder and is inexpensive for = the consumer of the data. Checking the validity of UTF-8 or MIME-encoded = messages are examples of this.
 
LL
 
I understand that, but = realistically, without a list of (potential) validity checks in the RFC, = there will be wide variance in what is documented by decoders =E2=80=93 = if any. In fact I checked a few implementations just now, and most of = them do not document what validity checks they perform. Those that = document something are hard to compare. If you make a canonical list, = people would have a starting = point.

Having made a few crude lists of validity checks = myself to try to understand what was what, such a list seems reasonable = to me.

LL


= --Apple-Mail=_0F3FBFC2-638C-4BCC-B7FB-140628B61867-- From nobody Mon Aug 10 15:45:41 2020 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 8E45C3A0DCD; Mon, 10 Aug 2020 15:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 muF9-6YiCddL; Mon, 10 Aug 2020 15:45:32 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7A23A0DCC; Mon, 10 Aug 2020 15:45:31 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BQWJP1DWVzyX6; Tue, 11 Aug 2020 00:45:25 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Tue, 11 Aug 2020 00:45:24 +0200 Cc: Laurence Lundblade , cbor@ietf.org, draft-ietf-cbor-7049bis.all@ietf.org, last-call@ietf.org, secdir@ietf.org X-Mao-Original-Outgoing-Id: 618792324.550929-fcd412e65053451cdfda2e66f3582eb2 Content-Transfer-Encoding: quoted-printable Message-Id: <6A1090D8-D012-4A04-BC4A-9CF23E791DA2@tzi.org> References: <159705005508.2366.4819563096010229406@ietfa.amsl.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 22:45:35 -0000 On 2020-08-10, at 22:24, Yaron Sheffer wrote: >=20 > I understand that, but realistically, without a list of (potential) = validity checks in the RFC, there will be wide variance in what is = documented by decoders =E2=80=93 if any. In fact I checked a few = implementations just now, and most of them do not document what validity = checks they perform. Those that document something are hard to compare. = If you make a canonical list, people would have a starting point. To be fair, you probably checked RFC 7049 implementations, and RFC 7049 = didn=E2=80=99t have such a requirement (improving the discussion of = validity was one of the major work items in 7049bis, see Appendix G.3). One point to keep in mind is that, with CBOR, most validity processing = happens in the processing of tags, and that is an extension point. So a = list in 7049bis will never be complete. Even if it only covers base = CBOR and the tags registered in 7049/7049bis, a detailed version is = likely to be tedious and highly dependent of specific implementation = approaches. Trying to imagine the outcome of this exercise, my visual image right = now is a PICS Proforma, so I think I=E2=80=99ll better stop here... Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Aug 11 12:14:46 2020 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 A93B53A09B8; Tue, 11 Aug 2020 12:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.573, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 qQHJO8e2k6XC; Tue, 11 Aug 2020 12:14:43 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 463463A08B9; Tue, 11 Aug 2020 12:14:43 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id z18so12494516wrm.12; Tue, 11 Aug 2020 12:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=FHCW0B6tNxV3sMDbqtqd1CpBIpQUPnBYH2zwF02eVO8=; b=ofnvDpdgnaGhZfJ7K89cLO5+xxu1ZiQuyX7+70vOmdAizmJg2OsX9jWCFCCS0z0HLW 5Q5Rk2+TK0Rev3WwAQGLlsk5BmXqqyJPeh0XZzZScOb3lWkCxLQjbBnO/oMh0h7hKsxP zLyNA4sRtLH5OYFEPBEXiwY920zF37WarDBQ+2ctfkc1/Ukv9yULQrAz1/WMV7BePO9+ Uyfj/l8833m+ySGO8KFanCzEDComR6y0TJU8wiFwoW2NTZofmXNQ1xMRj5Xn7nRtFVVy 7P0l3GI1oMmNsLl/kvUXa1Qi2nqFlcpwWf7gXmGRFhSUV3UPkjgoKWNcsVKy1fHQihHE x6jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=FHCW0B6tNxV3sMDbqtqd1CpBIpQUPnBYH2zwF02eVO8=; b=uUnceyi6vDMtc84Am7RnEhl/IlTrghm7efoMZtiyCPzZHpCazhlXOkyk5x4f6TlRnC QTymK7uBpSzd0Kxgso9lyubtvaVXj0o3aIfYHwKmgpqCD6xJcziDlrxm2SLB92HoK0bu nqZaFv5+4TbbjpuxOhN1YKaS4xAlA+5k1XxZV3V1ttR+cBtUclUrPCErb104SZ8YVYys 2iuwAM2+BmFxQlJ+1iSjR8Zdpxg/4a9jhCWOHNDOg5CkX3eZ4zOFF24cCoN2yL9wKjFa 3Y962I6VI5xAki3r7bw3/geiG30x2qcnrIjG19qALRb2Y481ctcgHj6WrKCIZIIwNlPm bCfg== X-Gm-Message-State: AOAM5339OAldFLeBygTmeILZq4pXM5tM+61Hs0gT86MdHfryUE4q9Fik t9t6ImBNq7lyUR7y8RLL+Oo= X-Google-Smtp-Source: ABdhPJxe/jFFV+V2LN0r9rcZN4+LDD/p8Oi9OEIOPZoHkIWZXoFZWATrbiVEJuEbK7+kYfaSKY/fpA== X-Received: by 2002:adf:fac8:: with SMTP id a8mr30810494wrs.368.1597173281626; Tue, 11 Aug 2020 12:14:41 -0700 (PDT) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id o125sm6998874wma.27.2020.08.11.12.14.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2020 12:14:41 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Tue, 11 Aug 2020 22:14:39 +0300 From: Yaron Sheffer To: Carsten Bormann CC: Laurence Lundblade , , , , Message-ID: Thread-Topic: [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 References: <159705005508.2366.4819563096010229406@ietfa.amsl.com> <6A1090D8-D012-4A04-BC4A-9CF23E791DA2@tzi.org> In-Reply-To: <6A1090D8-D012-4A04-BC4A-9CF23E791DA2@tzi.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Cbor] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 19:14:45 -0000 >=20 > I understand that, but realistically, without a list of (potential) v= alidity checks in the RFC, there will be wide variance in what is documented= by decoders =E2=80=93 if any. In fact I checked a few implementations just now, a= nd most of them do not document what validity checks they perform. Those tha= t document something are hard to compare. If you make a canonical list, peop= le would have a starting point. To be fair, you probably checked RFC 7049 implementations, and RFC 7049= didn=E2=80=99t have such a requirement (improving the discussion of validity was = one of the major work items in 7049bis, see Appendix G.3). One point to keep in mind is that, with CBOR, most validity processing = happens in the processing of tags, and that is an extension point. So a lis= t in 7049bis will never be complete. Even if it only covers base CBOR and t= he tags registered in 7049/7049bis, a detailed version is likely to be tedio= us and highly dependent of specific implementation approaches. Trying to imagine the outcome of this exercise, my visual image right n= ow is a PICS Proforma, so I think I=E2=80=99ll better stop here... Gr=C3=BC=C3=9Fe, Carsten Hi Carsten, You are addressing this issue from the point of view of a spec writer, I su= ggest you take the POV of the implementer, the user of a decoder. Those peop= le are not CBOR experts, and when faced with free-form and probably terse do= cumentation of a decoder's validity checking would never know what they need= to consider to add as application-level checking. I realize that tags are an extension point, but if we are to avoid decoding= -related vulnerabilities, I suggest you list validity checks for the base CB= OR and tags in RFC7049+bis. Thanks, Yaron From nobody Tue Aug 11 16:24:25 2020 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 8D8173A0DC9; Tue, 11 Aug 2020 16:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 wvmCShEXtLIO; Tue, 11 Aug 2020 16:24:20 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A6FA3A0DBE; Tue, 11 Aug 2020 16:24:19 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BR86R6B8Sz17r5; Wed, 12 Aug 2020 01:23:59 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 12 Aug 2020 01:24:01 +0200 Cc: cbor@ietf.org, secdir@ietf.org, Last Call , Laurence Lundblade , draft-ietf-cbor-7049bis.all@ietf.org X-Mao-Original-Outgoing-Id: 618881041.389055-e7d65e16d11098fbbf08f2f18de616d3 Content-Transfer-Encoding: quoted-printable Message-Id: References: <159705005508.2366.4819563096010229406@ietfa.amsl.com> <6A1090D8-D012-4A04-BC4A-9CF23E791DA2@tzi.org> To: Yaron Sheffer X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 23:24:24 -0000 On 2020-08-11, at 21:14, Yaron Sheffer wrote: >=20 >>=20 >> I understand that, but realistically, without a list of (potential) = validity checks in the RFC, there will be wide variance in what is = documented by decoders =E2=80=93 if any. In fact I checked a few = implementations just now, and most of them do not document what validity = checks they perform. Those that document something are hard to compare. = If you make a canonical list, people would have a starting point. >=20 > To be fair, you probably checked RFC 7049 implementations, and RFC = 7049 didn=E2=80=99t have such a requirement (improving the discussion of = validity was one of the major work items in 7049bis, see Appendix G.3). >=20 > One point to keep in mind is that, with CBOR, most validity = processing happens in the processing of tags, and that is an extension = point. So a list in 7049bis will never be complete. Even if it only = covers base CBOR and the tags registered in 7049/7049bis, a detailed = version is likely to be tedious and highly dependent of specific = implementation approaches. >=20 > Trying to imagine the outcome of this exercise, my visual image = right now is a PICS Proforma, so I think I=E2=80=99ll better stop = here... >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > Hi Carsten, >=20 > You are addressing this issue from the point of view of a spec writer, = I suggest you take the POV of the implementer, I took the view of the implementer of a generic decoder (which I happen = to also be IRL), faced with a PICS Proforma. Just in case that term doesn=E2=80=99t already send you running for the = hills, there are some standards that come with a [not so] little word = document that you are supposed to fill in to describe what your = implementation of that standard really does. > the user of a decoder. Those people are not CBOR experts, and when = faced with free-form and probably terse documentation of a decoder's = validity checking would never know what they need to consider to add as = application-level checking. I certainly can agree with that. Still, I would like to learn about = other places where IETF has done something like that, so we can learn = from those efforts. > I realize that tags are an extension point, but if we are to avoid = decoding-related vulnerabilities, I suggest you list validity checks for = the base CBOR and tags in RFC7049+bis. Would that also be a good thing for a separate document, possibly = including more tags? Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Aug 13 16:49:52 2020 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 010BD3A0B2A; Thu, 13 Aug 2020 16:49:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tim Evens via Datatracker To: Cc: draft-ietf-cbor-7049bis.all@ietf.org, cbor@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159736258595.2650.16667320289344139601@ietfa.amsl.com> Reply-To: Tim Evens Date: Thu, 13 Aug 2020 16:49:45 -0700 Archived-At: Subject: [Cbor] Genart last call review of draft-ietf-cbor-7049bis-14 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 23:49:46 -0000 Reviewer: Tim Evens Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-cbor-7049bis-?? Reviewer: Tim Evens Review Date: 2020-08-13 IETF LC End Date: 2020-08-14 IESG Telechat date: Not scheduled for a telechat Summary: Overall good, but a little on the verbose side which can result in one skipping over important details. Major issues: Minor issues: Nits/editorial comments: From nobody Thu Aug 13 17:45:02 2020 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 D86CB3A0B76; Thu, 13 Aug 2020 17:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 8yzPY3Yx4m0G; Thu, 13 Aug 2020 17:44:59 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650118.outbound.protection.outlook.com [40.107.65.118]) (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 BD8663A0B79; Thu, 13 Aug 2020 17:44:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aQt40o+Z2JBE1kabBllY8SET2JRJ3J+7UwO4j4uQoEIdtf3MiXJcDa5UyVPmLJIOeKYrM7PbCE/+sqvABe3G794JVQ0L6uwHU6JE6LJuM0Y0dW6AwvGdaSkP/CwEOYR1+ehrokf0USwEYFBZJhYgFNolacOcs9QtsYxuT3JaMgwTQFESTeaPnO850QuUgXYIJDTjFK3qeh2pvHJBuSR6A0UPM6F6f7kj6wBs3w0zrdzgBDi/viSSMhiBMnpUf62PRjEOXqBddUQOlYDIq6aCniL8954nHUdnxF372QFpR5Xo+xpAI9/6tVkpZ4GF6BnIlq+OmkAAEn3YTdDh8p8hCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RaTrDM7coCJ4d+c6hVE3Sb0/0pzeUCq0wIWF9Tlaxgw=; b=kctF/Oc1VOlu0oAqzAguj9Z0nnxf2KGTPiex04UhofaLTF4F/EKaWkpCgC6dEJiVlQVWMdwo81k3TLcTQWN5DtJqNpcARKHAmDwTc8QFG/VDcTV8qIDi53WxWwrTtXC4opJurF7sq6/yD4r1Y87i/hkbcaIw+Tu6UXyv4kxz8AtDCNPsFvVHQx06mX4zYDNdMaCqFvLJe7D2jZ30+XEZ8wfTZP2rVynnzMlcex4m+sbE1Smx9jApQVz2+ToLzZMdHsSyesLWB3z784Rq7QIL7ojloNMSsjan7mChf8vZ5uiXofPHbCvIuzIb5KzWqs5AcFEO91/XHgB8feOX0692Ww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RaTrDM7coCJ4d+c6hVE3Sb0/0pzeUCq0wIWF9Tlaxgw=; b=ak+jpNUhwxqARQDJl28R7eCXrUXarhCdTY+j+nUnNikO2z8jSGRttDR2Yv+a6nbnWmkGWStVLkP3cgeCzVyhIL1Ak+sOGdxcUjQsNerIrNXEJBSPw/bIynYFZnomjuBMe3iGIYYDgKDykD0S96SlYPBH985KuGyEahXbDDONlyE= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0878.namprd00.prod.outlook.com (2603:10b6:208:a3::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3323.0; Fri, 14 Aug 2020 00:44:50 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::e9b3:c850:e214:627e]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::e9b3:c850:e214:627e%6]) with mapi id 15.20.3326.000; Fri, 14 Aug 2020 00:44:50 +0000 From: Mike Jones To: Kyle Rose , "secdir@ietf.org" CC: "draft-ietf-cbor-date-tag.all@ietf.org" , "last-call@ietf.org" , "cbor@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-cbor-date-tag-05 Thread-Index: AdZx1BxyoBjm9wtuR3uPvOkylOb0YQ== Date: Fri, 14 Aug 2020 00:44:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-14T00:28:56Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5ae9dac8-a305-4f45-8149-fa8770de83f5; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: krose.org; dkim=none (message not signed) header.d=none;krose.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.88.234] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b669ea15-e609-43f6-30e6-08d83feb40bd x-ms-traffictypediagnostic: MN2PR00MB0878: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cpDtXRWz6mB2XLOLZT4pUmxtLx8MGMK0h+++WNtyCqV08iWfGuKh4ZGWX2FuRN1TaWNfDDU9TTgQ3HkqGtaG6CYbB4DmjyU9hO9EQv5dzp1Lh6K6v+13Kug8tJgg96aNySDmo3imbYGR7xE4BH5s41lRuOVdK6t9VteTIqqN3fNEQdXD8KaO6rf+bHgrGTiixtJOaijz6vaP5Rdn2tHZuHBLlLoNF8Pcua7KpkwGiCaDvheqB6zgm+o91roFmVPLVR/4NkNH+i3xpKLVqOKWHS86cCro8Je9cKn64vgEw2sfmODmpD1upnTNXo3/MpzIuyTl1DXq6IINuds26udBNd9ie8NUtYeoddEhWw3+5uo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(346002)(136003)(366004)(396003)(83380400001)(186003)(6506007)(54906003)(53546011)(966005)(86362001)(26005)(8676002)(110136005)(71200400001)(166002)(478600001)(7696005)(10290500003)(316002)(8990500004)(33656002)(82960400001)(76116006)(66446008)(66556008)(66946007)(66476007)(64756008)(52536014)(82950400001)(2906002)(5660300002)(9686003)(55016002)(8936002)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: GXjoI7VzXnfDN1TIWIrhONg7PAxHkFcAD7EaqG23uO2Hfv52a2lhQEjckGBtjMVmFRbZY87YIaLHb08XQUUFun6Jj/H0hdwKiau3u4RwgCKLlcr25+7/4Q8p+He6pfxxzasVmk5D9H/KyqH0ibOk/ZhfDQ/VVQSeLuvKcJ8jnl2m7Lnm7ee+02GpBYmyBprv25KEusBy8kWxlZmy6kMevMnZMLy8ptNUkjDZG6fh7BlLMc7lYM14FyqbtKTpBY/sZ6EN89oghGE5YOptL66fDih9Ogx34SJB0cflpIb/TOgZ2LHlCCvfTQcXTVeMKNO4inNX+1hCSBwl1F9iK4Cn+P0iaqRCljvVBVb4SDWCm9JFwjod1y7OYbnESs7WFUvweosTLqT2n773sy2K2u6gmfCMrG6ojw/DjpoEv2rlxjXL3Yuv395iC31GIs5mF+LlQL2Vwy4YttFJlEEJroeMZqJvk8BBEwTiWA/yE1TCngknAT8kN/x+85ux+V6PaQT3+0AE21EFRgDaDXFCIsxmoPDhQLKAxB8ewJp0KyLRPiD6l1qGAiRkl/+9lbg4EuN2LOFkWsSezw0mEg4IHbZRMBPuddGLQZQGQF0DlurcBW1cZySgUT6gp8fDAzpSBQb9Fnhx79RZwkYxdZb+z7PrbA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB06860E2D4F9B897F47CB76C5F5401MN2PR00MB0686namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0686.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b669ea15-e609-43f6-30e6-08d83feb40bd X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 00:44:50.8223 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ehQizczDOTFqtMBSgjwtyc8OIz0aQelZHAhE7nCMRstkZpd0cvkt358SDgaR98sRXtlMYN79pJwut0XUryWhcA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0878 Archived-At: Subject: Re: [Cbor] Secdir last call review of draft-ietf-cbor-date-tag-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 00:45:01 -0000 --_000_MN2PR00MB06860E2D4F9B897F47CB76C5F5401MN2PR00MB0686namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIHRob3VnaHRmdWwgcmV2aWV3LCBLeWxlLiAgTXkgcmVwbGllcyB0byB5 b3VyIGNvbW1lbnRzIGFyZSBpbmxpbmUuLi4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBLeWxlIFJvc2UgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPg0K U2VudDogTW9uZGF5LCBBdWd1c3QgMTAsIDIwMjAgMTE6NDggQU0NClRvOiBzZWNkaXJAaWV0Zi5v cmcNCkNjOiBkcmFmdC1pZXRmLWNib3ItZGF0ZS10YWcuYWxsQGlldGYub3JnOyBsYXN0LWNhbGxA aWV0Zi5vcmc7IGNib3JAaWV0Zi5vcmcNClN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wNQ0KDQoNCg0KUmV2aWV3ZXI6IEt5bGUgUm9z ZQ0KDQpSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KDQoNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMg ZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVm Zm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUg SUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5l Zml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4NCg0KRG9jdW1lbnQgZWRpdG9ycyBh bmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90 aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KDQoNClRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgd2l0 aCBuaXRzLiBJIHNlZSBubyBpc3N1ZXMgb2YgaW50ZXJlc3QgdG8gdGhlIHNlY3VyaXR5IGRpcmVj dG9yYXRlLg0KDQoNCg0KSSBkbyBoYXZlIHRocmVlIGNvbW1lbnRzLCBob3dldmVyOg0KDQoNCg0K KiBJbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiwgYSBiZXR0ZXIgZXhhbXBs ZSBtaWdodCBiZSB0aGUgcG90ZW50aWFsIGluYXBwcm9wcmlhdGVuZXNzIG9mIHVzaW5nIGFuIGlt cHJlY2lzZSBtZWNoYW5pc20gZm9yIHNwZWNpZnlpbmcgY2VydGlmaWNhdGUgZXhwaXJhdGlvbi4N Cg0KDQoNCkknbGwgcGxhbiB0byBhZGQgdGhpcyBleGFtcGxlIHdoZW4gYWRkcmVzc2luZyBvdGhl ciBsYXN0IGNhbGwgY29tbWVudHMuDQoNCg0KDQoqIEl0J3Mgbm90IGNsZWFyIGhvdyB0aGlzIGlz IGludGVuZGVkIHRvIHdvcmsgZm9yIGRhdGVzIHByaW9yIHRvIHRoZSBzdGFydCBvZiB0aGUgR3Jl Z29yaWFuIGNhbGVuZGFyIGluIDE1ODIuIFdoYXQgZG8gbmVnYXRpdmUgaW50ZWdlciB2YWx1ZXMg bWVhbiB3aGVuIHRoZXkgaW1wbHkgYSBkYXRlIGJlZm9yZSAxNS1PY3QtMTU4Mj8gSXMgdGhlIEdy ZWdvcmlhbiBjYWxlbmRhciBkZWZpbmVkIGZvciBhbGwgdGltZT8gSW4gYSBicmllZiBpbnZlc3Rp Z2F0aW9uLCBJJ3ZlIGJlZW4gdW5hYmxlIHRvIGZpbmQgdGhlIGFuc3dlciB0byB0aGlzLg0KDQoN Cg0KU2VlIHRoZSBzZWN0aW9uIGluIHRoZSBJbnRyb2R1Y3Rpb24gb24gdGhlIHJlbGF0aW9uc2hp cCB0byB0aGUgTW9kaWZpZWQgSnVsaWFuIERhdGUgdmFsdWUgYW5kIHRoZW4gc2VlIGh0dHBzOi8v Y29yZTIuZ3NmYy5uYXNhLmdvdi90aW1lLyBmb3IgdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGUgTW9k aWZpZWQgSnVsaWFuIERhdGUgdG8gdGhlIEp1bGlhbiBEYXRlLCBhIHRpbWVzY2FsZSBkZWZpbmVk IGJ5IHRoZSBTbWl0aHNvbmlhbiBBc3Ryb25vbWljYWwgT2JzZXJ2YXRvcnkgYmVnaW5uaW5nIGF0 IG5vb24gMSBKYW51YXJ5IDQ3MTMgQi5DLiAgVGhhdCBzZWVtcyB0byBnbyBmYXIgYmFjayBlbm91 Z2ggZm9yIG1vc3QgcHJhY3RpY2FsIHB1cnBvc2VzLg0KDQoNCg0KSW50ZXJlc3RpbmdseSwgYWNj b3JkaW5nIHRvIGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0p1bGlhbl9kYXk6DQoNCuKA nFRoZSBNb2RpZmllZCBKdWxpYW4gRGF0ZSAoTUpEKSB3YXMgaW50cm9kdWNlZCBieSB0aGUgU21p dGhzb25pYW4gQXN0cm9waHlzaWNhbCBPYnNlcnZhdG9yeSBpbiAxOTU3IHRvIHJlY29yZCB0aGUg b3JiaXQgb2YgU3B1dG5payB2aWEgYW4gSUJNIDcwNCAoMzYtYml0IG1hY2hpbmUpIGFuZCB1c2lu ZyBvbmx5IDE4IGJpdHMgdW50aWwgQXVndXN0IDcsIDI1NzYuIE1KRCBpcyB0aGUgZXBvY2ggb2Yg VkFYL1ZNUyBhbmQgaXRzIHN1Y2Nlc3NvciBPcGVuVk1TLCB1c2luZyA2My1iaXQgZGF0ZS90aW1l LCB3aGljaCBhbGxvd3MgdGltZXMgdG8gYmUgc3RvcmVkIHVwIHRvIEp1bHkgMzEsIDMxMDg2LCAw Mjo0ODowNS40Ny5bMThdIFRoZSBNSkQgaGFzIGEgc3RhcnRpbmcgcG9pbnQgb2YgbWlkbmlnaHQg b24gTm92ZW1iZXIgMTcsIDE4NTggYW5kIGlzIGNvbXB1dGVkIGJ5IE1KRCA9IEpEIC0gMjQwMDAw MC41LuKAnQ0KDQoNCg0KKiBJbiBhIHZlcnkgZ3Jvc3Mgc2Vuc2UsIHRoaXMgc3BlY2lmaWNhdGlv biAqaXMqIGFjdHVhbGx5IHRpZWQgdG8gdGhlIHByZXZhaWxpbmcgdGltZXNjYWxlLCBsZWFwIHNl Y29uZHMgYW5kIGFsbDogaWYgdGhlIHdob2xlIHdvcmxkIHdlcmUgdG8gdHJhbnNpdGlvbiBmcm9t IFVUQyB0byBUQUkgYW5kIHN0b3AgYWRkaW5nIGxlYXAgc2Vjb25kcywgcHJlc3VtYWJseSBpbXBs ZW1lbnRhdGlvbnMgd291bGQgY29udGludWUgdG8gZ2VuZXJhdGUgZGF0ZXMgZm9yIHRoaXMgc3Bl Y2lmaWNhdGlvbiBieSB0cnVuY2F0aW5nIHRoZSBsb2NhbCB0aW1lc3RhbXAgdG8gdGhlIGRhdGUs IHdoaWNoIHdvdWxkIGNhdXNlIGl0IHRvIGRyaWZ0IGFsb25nIHdpdGggVEFJIGF3YXkgZnJvbSBV VEMgb3ZlciB0aW1lLiBUaGVyZSB3b3VsZG4ndCBiZSBhIGh1Z2UgcHJhY3RpY2FsIGVmZmVjdCBo ZXJlIGdpdmVuIGhvdyBsaXR0bGUgdGhleSBhcmUgZXhwZWN0ZWQgdG8gZGl2ZXJnZSBvdmVyIHRo ZSBmb3Jlc2VlYWJsZSBmdXR1cmUsIGJ1dCBpdCB3b3VsZCBtZWFuIHRoYXQgZGF0ZXMgZW5jb2Rl ZCBpbiB0aGlzIGZvcm1hdCB0b2RheSB3b3VsZCBub3QgY2FycnkgZW5vdWdoIGluZm9ybWF0aW9u IHRvIHByZWNpc2VseSBpbmRpY2F0ZSBhIGRhdGUgaW4gdGhlIGZhciBmdXR1cmUgZXZlbiBpZiB0 aGUgdGFyZ2V0IHRpbWVzY2FsZSB3ZXJlIHVuZGVyc3Rvb2QgdGhyb3VnaG91dCBzaW5jZSB0aGUg c291cmNlIHRpbWVzY2FsZSBpc24ndCBwYXJ0IG9mIHRoZSBlbmNvZGluZy4NCg0KDQoNCklmIGl0 4oCZcyBnb29kIGVub3VnaCBmb3IgdGhlIFNtaXRoc29uaWFuIEFzdHJvbm9taWNhbCBPYnNlcnZh dG9yeSAoYWxiZWl0LCB1dGlsaXppbmcgYSBkZWZpbmVkIGludGVnZXIgb2Zmc2V0KSwgaXTigJlz IGdvb2QgZW5vdWdoIGZvciBtZS4gOy0pICBUaW1la2VlcGluZyBpcyB1bHRpbWF0ZWx5IGEgaHVt YW4gY3VsdHVyYWwgZW5kZWF2b3IgYW5kIGl04oCZcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMg c3BlY2lmaWNhdGlvbiB0byBwcm9iZSBpdHMgbWFueSB2YXJpYXRpb25zIGFuZCBmb2libGVzLiAg VGhlIGVzc2VuY2Ugb2YgZGF0ZXMgaXMgdGhhdCBlYWNoIHRpbWUgdGhlIHdvcmxkIGdvZXMgcm91 bmQsIHRoZXNlIHZhbHVlcyBpbmNyZW1lbnQuICBUaGF0IHNhaWQsIGlmIHlvdSBoYXZlIHNwZWNp ZmljIHRleHQgeW914oCZZCBsaWtlIHRvIHNlZSBhZGRlZCwgSeKAmW0gb3BlbiB0byBpdC4NCg0K DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBCZXN0IHdpc2hlcywNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KDQoNClAuUy4gIEkgbmV2ZXIgZXhwZWN0ZWQgdGhh dCB3cml0aW5nIHRoaXMgdmVyeSBzaW1wbGUgc3BlY2lmaWNhdGlvbiB3b3VsZCByZXN1bHQgaW4g c3VjaCBpbnRlcmVzdGluZyBkaXNjdXNzaW9ucyBhYm91dCB0aW1la2VlcGluZyENCg0KDQo= --_000_MN2PR00MB06860E2D4F9B897F47CB76C5F5401MN2PR00MB0686namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQt d3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5UaGFua3MgZm9yIHlvdXIgdGhvdWdodGZ1bCByZXZpZXcsIEt5bGUuJm5i c3A7IE15IHJlcGxpZXMgdG8geW91ciBjb21tZW50cyBhcmUgaW5saW5lLi4uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTog S3lsZSBSb3NlIHZpYSBEYXRhdHJhY2tlciAmbHQ7bm9yZXBseUBpZXRmLm9yZyZndDsgPGJyPg0K U2VudDogTW9uZGF5LCBBdWd1c3QgMTAsIDIwMjAgMTE6NDggQU08YnI+DQpUbzogc2VjZGlyQGll dGYub3JnPGJyPg0KQ2M6IGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy5hbGxAaWV0Zi5vcmc7IGxh c3QtY2FsbEBpZXRmLm9yZzsgY2JvckBpZXRmLm9yZzxicj4NClN1YmplY3Q6IFNlY2RpciBsYXN0 IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wNTwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+UmV2aWV3ZXI6IEt5bGUgUm9zZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+UmV2aWV3IHJlc3VsdDogSGFzIE5pdHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJp dHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1l bnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4mbmJzcDsgVGhlc2UgY29tbWVudHMgd2Vy ZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEg ZGlyZWN0b3JzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RG9jdW1l bnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0 IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+VGhpcyBkb2N1bWVudCBpcyByZWFkeSB3aXRoIG5pdHMuIEkgc2VlIG5vIGlzc3Vl cyBvZiBpbnRlcmVzdCB0byB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkkgZG8gaGF2ZSB0aHJlZSBjb21tZW50cywgaG93ZXZlcjo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+KiBJbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg c2VjdGlvbiwgYSBiZXR0ZXIgZXhhbXBsZSBtaWdodCBiZSB0aGUgcG90ZW50aWFsIGluYXBwcm9w cmlhdGVuZXNzIG9mIHVzaW5nIGFuIGltcHJlY2lzZSBtZWNoYW5pc20gZm9yIHNwZWNpZnlpbmcg Y2VydGlmaWNhdGUgZXhwaXJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JJ2xsIHBsYW4gdG8gYWRkIHRoaXMgZXhhbXBsZSB3aGVu IGFkZHJlc3Npbmcgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+KiBJdCdz IG5vdCBjbGVhciBob3cgdGhpcyBpcyBpbnRlbmRlZCB0byB3b3JrIGZvciBkYXRlcyBwcmlvciB0 byB0aGUgc3RhcnQgb2YgdGhlIEdyZWdvcmlhbiBjYWxlbmRhciBpbiAxNTgyLiBXaGF0IGRvIG5l Z2F0aXZlIGludGVnZXIgdmFsdWVzIG1lYW4gd2hlbiB0aGV5IGltcGx5IGEgZGF0ZSBiZWZvcmUg MTUtT2N0LTE1ODI/IElzIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIgZGVmaW5lZCBmb3IgYWxsIHRp bWU/DQogSW4gYSBicmllZiBpbnZlc3RpZ2F0aW9uLCBJJ3ZlIGJlZW4gdW5hYmxlIHRvIGZpbmQg dGhlIGFuc3dlciB0byB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlNlZSB0aGUgc2VjdGlvbiBpbiB0aGUgSW50cm9kdWN0aW9uIG9u IHRoZSByZWxhdGlvbnNoaXAgdG8gdGhlIE1vZGlmaWVkIEp1bGlhbiBEYXRlIHZhbHVlIGFuZCB0 aGVuIHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly9jb3JlMi5nc2ZjLm5hc2EuZ292L3RpbWUvIj5odHRw czovL2NvcmUyLmdzZmMubmFzYS5nb3YvdGltZS88L2E+IGZvciB0aGUgcmVsYXRpb25zaGlwIG9m IHRoZSBNb2RpZmllZCBKdWxpYW4gRGF0ZSB0byB0aGUgSnVsaWFuIERhdGUsIGEgdGltZXNjYWxl IGRlZmluZWQgYnkgdGhlIFNtaXRoc29uaWFuIEFzdHJvbm9taWNhbCBPYnNlcnZhdG9yeSBiZWdp bm5pbmcgYXQgbm9vbiAxIEphbnVhcnkgNDcxMyBCLkMuJm5ic3A7IFRoYXQNCiBzZWVtcyB0byBn byBmYXIgYmFjayBlbm91Z2ggZm9yIG1vc3QgcHJhY3RpY2FsIHB1cnBvc2VzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JbnRlcmVzdGluZ2x5LCBhY2NvcmRpbmcgdG8g PGEgaHJlZj0iaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvSnVsaWFuX2RheSI+DQpodHRw czovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9KdWxpYW5fZGF5PC9hPjo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj7igJxUaGUgTW9kaWZpZWQgSnVsaWFuIERhdGUgKE1K RCkgd2FzIGludHJvZHVjZWQgYnkgdGhlIFNtaXRoc29uaWFuIEFzdHJvcGh5c2ljYWwgT2JzZXJ2 YXRvcnkgaW4gMTk1NyB0byByZWNvcmQgdGhlIG9yYml0IG9mIFNwdXRuaWsgdmlhIGFuIElCTSA3 MDQgKDM2LWJpdCBtYWNoaW5lKSBhbmQgdXNpbmcgb25seSAxOCBiaXRzDQogdW50aWwgQXVndXN0 IDcsIDI1NzYuIE1KRCBpcyB0aGUgZXBvY2ggb2YgVkFYL1ZNUyBhbmQgaXRzIHN1Y2Nlc3NvciBP cGVuVk1TLCB1c2luZyA2My1iaXQgZGF0ZS90aW1lLCB3aGljaCBhbGxvd3MgdGltZXMgdG8gYmUg c3RvcmVkIHVwIHRvIEp1bHkgMzEsIDMxMDg2LCAwMjo0ODowNS40Ny5bMThdIFRoZSBNSkQgaGFz IGEgc3RhcnRpbmcgcG9pbnQgb2YgbWlkbmlnaHQgb24gTm92ZW1iZXIgMTcsIDE4NTggYW5kIGlz IGNvbXB1dGVkIGJ5IE1KRA0KID0gSkQgLSAyNDAwMDAwLjUu4oCdPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4qIElu IGEgdmVyeSBncm9zcyBzZW5zZSwgdGhpcyBzcGVjaWZpY2F0aW9uICppcyogYWN0dWFsbHkgdGll ZCB0byB0aGUgcHJldmFpbGluZyB0aW1lc2NhbGUsIGxlYXAgc2Vjb25kcyBhbmQgYWxsOiBpZiB0 aGUgd2hvbGUgd29ybGQgd2VyZSB0byB0cmFuc2l0aW9uIGZyb20gVVRDIHRvIFRBSSBhbmQgc3Rv cCBhZGRpbmcgbGVhcCBzZWNvbmRzLCBwcmVzdW1hYmx5IGltcGxlbWVudGF0aW9ucyB3b3VsZCBj b250aW51ZQ0KIHRvIGdlbmVyYXRlIGRhdGVzIGZvciB0aGlzIHNwZWNpZmljYXRpb24gYnkgdHJ1 bmNhdGluZyB0aGUgbG9jYWwgdGltZXN0YW1wIHRvIHRoZSBkYXRlLCB3aGljaCB3b3VsZCBjYXVz ZSBpdCB0byBkcmlmdCBhbG9uZyB3aXRoIFRBSSBhd2F5IGZyb20gVVRDIG92ZXIgdGltZS4gVGhl cmUgd291bGRuJ3QgYmUgYSBodWdlIHByYWN0aWNhbCBlZmZlY3QgaGVyZSBnaXZlbiBob3cgbGl0 dGxlIHRoZXkgYXJlIGV4cGVjdGVkIHRvIGRpdmVyZ2Ugb3Zlcg0KIHRoZSBmb3Jlc2VlYWJsZSBm dXR1cmUsIGJ1dCBpdCB3b3VsZCBtZWFuIHRoYXQgZGF0ZXMgZW5jb2RlZCBpbiB0aGlzIGZvcm1h dCB0b2RheSB3b3VsZCBub3QgY2FycnkgZW5vdWdoIGluZm9ybWF0aW9uIHRvIHByZWNpc2VseSBp bmRpY2F0ZSBhIGRhdGUgaW4gdGhlIGZhciBmdXR1cmUgZXZlbiBpZiB0aGUgdGFyZ2V0IHRpbWVz Y2FsZSB3ZXJlIHVuZGVyc3Rvb2QgdGhyb3VnaG91dCBzaW5jZSB0aGUgc291cmNlIHRpbWVzY2Fs ZSBpc24ndCBwYXJ0DQogb2YgdGhlIGVuY29kaW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPklmIGl04oCZcyBnb29kIGVub3VnaCBmb3Ig dGhlIFNtaXRoc29uaWFuIEFzdHJvbm9taWNhbCBPYnNlcnZhdG9yeSAoYWxiZWl0LCB1dGlsaXpp bmcgYSBkZWZpbmVkIGludGVnZXIgb2Zmc2V0KSwgaXTigJlzIGdvb2QgZW5vdWdoIGZvciBtZS4g Oy0pICZuYnNwO1RpbWVrZWVwaW5nIGlzIHVsdGltYXRlbHkgYSBodW1hbiBjdWx0dXJhbCBlbmRl YXZvciBhbmQgaXTigJlzIGJleW9uZA0KIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24g dG8gcHJvYmUgaXRzIG1hbnkgdmFyaWF0aW9ucyBhbmQgZm9pYmxlcy4mbmJzcDsgVGhlIGVzc2Vu Y2Ugb2YgZGF0ZXMgaXMgdGhhdCBlYWNoIHRpbWUgdGhlIHdvcmxkIGdvZXMgcm91bmQsIHRoZXNl IHZhbHVlcyBpbmNyZW1lbnQuJm5ic3A7IFRoYXQgc2FpZCwgaWYgeW91IGhhdmUgc3BlY2lmaWMg dGV4dCB5b3XigJlkIGxpa2UgdG8gc2VlIGFkZGVkLCBJ4oCZbSBvcGVuIHRvIGl0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgQmVzdCB3aXNoZXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UC5TLiZuYnNw OyBJIG5ldmVyIGV4cGVjdGVkIHRoYXQgd3JpdGluZyB0aGlzIHZlcnkgc2ltcGxlIHNwZWNpZmlj YXRpb24gd291bGQgcmVzdWx0IGluIHN1Y2ggaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbnMgYWJvdXQg dGltZWtlZXBpbmchPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR00MB06860E2D4F9B897F47CB76C5F5401MN2PR00MB0686namp_-- From nobody Sun Aug 16 22:09:46 2020 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 9E4DB3A0948 for ; Sun, 16 Aug 2020 22:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 HL1U2wPBorlU for ; Sun, 16 Aug 2020 22:09:43 -0700 (PDT) Received: from p3plsmtpa08-02.prod.phx3.secureserver.net (p3plsmtpa08-02.prod.phx3.secureserver.net [173.201.193.103]) (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 A9A3E3A08CB for ; Sun, 16 Aug 2020 22:09:43 -0700 (PDT) Received: from [192.168.1.49] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 7XOwkVlEEccZp7XOxkxxB2; Sun, 16 Aug 2020 22:09:43 -0700 X-CMAE-Analysis: v=2.3 cv=c/HVvi1l c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=4x9wB5P1pbMlZxtjjd8A:9 a=QEXdDO2ut3YA:10 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <5F695632-CF27-40FF-BC23-E731AAA95771@island-resort.com> Date: Sun, 16 Aug 2020 22:09:42 -0700 To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-CMAE-Envelope: MS4wfBoUdDYL/daN6tTTWjL7tNd4hddqqL/NN4IbiAcCjU4s3Iv4NT6yQccPXwlSjYM3btSp+0b9yhaWD0uQQGHO7cS/mlWtldDU9RP9ETM+Zfw04NS8kKw8 zNnHWs0ckgcv7rEyhANlPkLnbE85z7gS2PDM7t9KS7U9yCXVS6sm4kAK Archived-At: Subject: [Cbor] Tagging requirement X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 05:09:45 -0000 My understanding is that the surrounding protocol that uses a tagged = type dictates whether the tag should be present or not. For example, CWT = dictates that tag 1 (epoch time) must not be used for the =E2=80=9Cexp=E2=80= =9D, =E2=80=9Cnbf=E2=80=9D and =E2=80=9Ciat" claims. So the surrounding protocol can pick one of these three when it use a = tagged type. - Tag is FORBIDDEN (e.g., date fields in CWT). Decode error if tag is = present. - Tag is REQUIRED tags (e.g., COSE type tag when CWT tag is present). = Error occurs if tag is absent, probably because item is not of the = expected type. - Tag is OPTIONAL (e.g., application/cwt and the CWT tag). Maybe an = error, maybe not.=20 As far as I can see there isn=E2=80=99t a clear rule about which of = these it is when the surrounding protocol doesn=E2=80=99t explicitly = pick. Deterministic encoding does disallow OPTIONAL. If I were to guess = as to which is the default, I would say it is OPTIONAL. Big floats and decimal fractions make use of the bignum type, but the = definition of big floats and decimal fractions doesn=E2=80=99t = explicitly say which of the three above it selects, so one might think = it is OPTIONAL if one assumes that is the default of the three and that = you could distinguish a bignum mantissa because it is a byte string not = an integer. One second though, you realize you can=E2=80=99t tell the = sign of the bignum unless there is a tag so it has to be REQUIRED to = work. My thought is that OPTIONAL adds no value. It is a form of =E2=80=9Cbe = liberal in what you receive=E2=80=9D that seems to be less in favor = these days. When you nest tagged type usage with OPTIONAL, you can get a = larger fan out. However, OPTIONAL is allowed in 7049 and things like = the application/cwt media type registry use it. My thought is that it would be helpful to say somewhere that users of = tagged types should explicitly say what the tagging requirement is and = should avoid OPTIONAL tagging. (I came to this trying to write code for tag handling for big float, = EAT, CWT, COSE and such. I=E2=80=99m trying not to be annoying, but also = think this is an issue :-) ) LL From nobody Mon Aug 17 00:41:02 2020 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 3C7843A095A for ; Mon, 17 Aug 2020 00:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 dZZo7WSPXLzO for ; Mon, 17 Aug 2020 00:40:57 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302483A08FF for ; Mon, 17 Aug 2020 00:40:56 -0700 (PDT) Received: from client-0100.vpn.uni-bremen.de (client-0100.vpn.uni-bremen.de [134.102.107.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BVQvW1YVWzyhL; Mon, 17 Aug 2020 09:40:55 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <5F695632-CF27-40FF-BC23-E731AAA95771@island-resort.com> Date: Mon, 17 Aug 2020 09:40:54 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 619342854.840881-f7a10bc290a3d7840905c033cfae9c63 Content-Transfer-Encoding: quoted-printable Message-Id: <895A3DF8-DF11-479F-9DC6-9EF98465A7E0@tzi.org> References: <5F695632-CF27-40FF-BC23-E731AAA95771@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Tagging requirement X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 07:41:00 -0000 On 2020-08-17, at 07:09, Laurence Lundblade = wrote: >=20 > My understanding is that the surrounding protocol that uses a tagged = type dictates whether the tag should be present or not. For example, CWT = dictates that tag 1 (epoch time) must not be used for the =E2=80=9Cexp=E2=80= =9D, =E2=80=9Cnbf=E2=80=9D and =E2=80=9Ciat" claims. Yes. More specifically, the CWT protocol does not use Tag 1 for exp, = nbf, iat, but instead borrows that Tag=E2=80=99s specification for its = internal tag content. > So the surrounding protocol can pick one of these three when it use a = tagged type. Yes. The application protocol needs to define the application protocol. > - Tag is FORBIDDEN (e.g., date fields in CWT). Decode error if tag is = present. That is not what the protocol says =E2=80=94 the protocol says it=E2=80=99= s a number. The Tag is FORBIDDEN as much as an array of four byte = strings would be FORBIDDEN. (I=E2=80=99m going with your upper case language here; not sure that = adds anything because it makes it seem these words are a menu to choose = from. They aren=E2=80=99t. FORBIDDEN really means =E2=80=9Cdoes not = use the Tag=E2=80=9D.) > - Tag is REQUIRED tags (e.g., COSE type tag when CWT tag is present). = Error occurs if tag is absent, probably because item is not of the = expected type. This case is similar: The protocol says what it is. The Tag may not be = =E2=80=9CREQUIRED" (there may be other choices for that position), but = to get the semantics of the Tag, you have to provide the Tag. (I.e., = you only get the Tag if you do use the Tag.) > - Tag is OPTIONAL (e.g., application/cwt and the CWT tag). Maybe an = error, maybe not.=20 That is indeed a special case that does not make a lot of sense *within* = an application protocol, but is useful at its outer boundary: If you = have context (such as a media type), you can use the unadorned data = structure for this protocol, otherwise you use the tag. > As far as I can see there isn=E2=80=99t a clear rule about which of = these it is when the surrounding protocol doesn=E2=80=99t explicitly = pick. There is no rule about arrays of four byte strings, either. The application protocol has to define the application protocol. > Deterministic encoding does disallow OPTIONAL. It says that this decision must be deterministic. There is nothing = wrong about OPTIONAL if all senders arrive at the same decision. > If I were to guess as to which is the default, I would say it is = OPTIONAL. I have no idea what a =E2=80=9Cdefault" is here. When would you get to = exercise this default? With all the language that argues against making = Tags optional in an application protocol, why or how would this be the = default for anything? > Big floats and decimal fractions make use of the bignum type, but the = definition of big floats and decimal fractions doesn=E2=80=99t = explicitly say which of the three above it selects, No, because Section 3.4.4 defines a couple of Tags. So for the = definition of the Tag, the Tag is =E2=80=9CREQUIRED=E2=80=9D, because = you only have a tag if you have the tag. Whether other protocols borrow = the specification of the tag content (array of e, m) is not relevant for = the definition of the Tag. > so one might think it is OPTIONAL if one assumes that is the default = of the three and that you could distinguish a bignum mantissa because it = is a byte string not an integer. Ah, that=E2=80=99s the confusion. RFC 7049 predates RFC 8610, so we are not formally describing the tag = content in RFC 7049. RFC 7049 is clear that m and e are integers, but = does not say which kind of integer (that may be a remnant of semantic = validity). Nowhere it says that if the mantissa is something else (like = an array of four byte strings), try to interpret this by guessing tags = that could be used to convert the mantissa into an integer. RFC 8610 actually does the work of fully defining the structure of = decfracs and bigfloats: decfrac =3D #6.4([e10: int, m: integer]) bigfloat =3D #6.5([e2: int, m: integer]) (integer is defined here: integer =3D int / bigint bigint =3D biguint / bignint biguint =3D #6.2(bstr) bignint =3D #6.3(bstr) int =3D uint / nint uint =3D #0 nint =3D #1 ) > One second though, you realize you can=E2=80=99t tell the sign of the = bignum unless there is a tag so it has to be REQUIRED to work. Yes. (More specifically, there are no Tag 2/3 bignums without tags, just as = there are no Tag 1 datetimes without Tag 1. In both cases, an = application protocol could borrow the definition of the structure of the = tag content =E2=80=94 I could define a protocol that accepts a byte = string in a specific position that is then interpreted as an integer by = the application like it would be if it carried Tag 2. Note that this = borrowing is common enough that the CDDL operator ~ (unwrap) directly = supports this, but it is entirely distinct from using the Tag.) > My thought is that OPTIONAL adds no value. It is a form of =E2=80=9Cbe = liberal in what you receive=E2=80=9D that seems to be less in favor = these days. When you nest tagged type usage with OPTIONAL, you can get a = larger fan out. =20 Don=E2=80=99t do that then [1]. > However, OPTIONAL is allowed in 7049 and things like the = application/cwt media type registry use it. What do you mean by =E2=80=9Cis allowed=E2=80=9D? The application protocol can indeed define (or use) a Tag that can be = used to identify a data item if the identification does not come from = the context. If it doe,s the tag doesn=E2=80=99t add value. Application/cwt could = have been defined such that it never includes the CWT Tag (i.e., the = COSE tag is outermost); I don=E2=80=99t have a strong opinion on whether = it should have done that. None of this is something that could be defined for Tags in general; the = application protocol (here: RFC 8392) needs to make the call. The media = type application/cwt now includes the unneeded choice; an application = might still make further restrictions (always tag 61, never tag 61). > My thought is that it would be helpful to say somewhere that users of = tagged types should explicitly say what the tagging requirement is and = should avoid OPTIONAL tagging. There is nothing wrong with what you call =E2=80=9COPTIONAL=E2=80=9D. = You wouldn=E2=80=99t use it on the inside of an application protocol. = You also would specific whether you want a Tag or not in all cases where = the application protocol is embedded into another application protocol. Tag 55799 is the prototype of all these =E2=80=9Csignature tags=E2=80=9D = =E2=80=94 you only use it if you don=E2=80=99t have other context to = detect that the byte sequence you have in hand is an encoded CBOR data = item. An application protocol does not allow or specify this tag unless it = allows or specifies it. Indeed, maybe we should say so in notable-tags. I=E2=80=99ll draft some text. > (I came to this trying to write code for tag handling for big float, = EAT, CWT, COSE and such. I=E2=80=99m trying not to be annoying, but also = think this is an issue :-) ) It becomes an issue if you somehow associate each Tag with your three = labels FORBIDDEN, REQUIRED, OPTIONAL. Don=E2=80=99t to that then... Gr=C3=BC=C3=9Fe, Carsten [1]: http://www.catb.org/~esr/jargon/html/D/Don-t-do-that-then-.html From nobody Mon Aug 17 10:56:27 2020 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 913B73A12CC for ; Mon, 17 Aug 2020 10:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 mh5Vl78L3EKQ for ; Mon, 17 Aug 2020 10:56:23 -0700 (PDT) Received: from p3plsmtpa06-06.prod.phx3.secureserver.net (p3plsmtpa06-06.prod.phx3.secureserver.net [173.201.192.107]) (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 F20B23A12CE for ; Mon, 17 Aug 2020 10:56:22 -0700 (PDT) Received: from [192.168.1.49] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 7jMrkaiKccPrZ7jMskLogg; Mon, 17 Aug 2020 10:56:22 -0700 X-CMAE-Analysis: v=2.3 cv=K7hc4BeI c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=gKmFwSsBAAAA:8 a=K6EGIJCdAAAA:8 a=LXL8el5rAAAA:8 a=9XquhrdV3ppfDJvA2GUA:9 a=SEwbdsqeENNFMSxp:21 a=xGOqiz8-qcL-fP7d:21 a=QEXdDO2ut3YA:10 a=YdbchcOiJdQA:10 a=TYPw6LfZSljyupAYXHcA:9 a=OXClMn2VRH8Lrw3V:21 a=Hr5-kW3BoJSU9MxF:21 a=ddrMlxdIdRYvZFYJ:21 a=_W_S_7VecoQA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=VxrG4A_UoVp_6Idp4yW2:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_66686154-B009-4DF4-B27C-737B5BBEC44B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 17 Aug 2020 10:56:21 -0700 In-Reply-To: <895A3DF8-DF11-479F-9DC6-9EF98465A7E0@tzi.org> Cc: cbor@ietf.org To: Carsten Bormann References: <5F695632-CF27-40FF-BC23-E731AAA95771@island-resort.com> <895A3DF8-DF11-479F-9DC6-9EF98465A7E0@tzi.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-CMAE-Envelope: MS4wfFn7FDFC5h5ZJfVIS4lQo7aFmRo8AEsSekwwYgg8CzyIjU413r7rjF4GepAomd0wPMhPa9EjvlyANFPq4dFKU2LR7JofD8k8TIkE0ACuizyq9HPK/9XO Ljy4G53X9/9rz1VS1m2gaH0InwpZKtfJS5oQqLRWRqizPjnr4HssN9t7foNvzLtCgWucyGZRGi4S7A== Archived-At: Subject: Re: [Cbor] Tagging requirement X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 17:56:26 -0000 --Apple-Mail=_66686154-B009-4DF4-B27C-737B5BBEC44B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have been thinking of the standardized tag definitions as data type = definitions first and the assignment and use of a tag to indicate the = type as second. So a protocol designer decides to use a type, say an epoch date, a CWT = or such first. Then, second, the designer decides how to identify it as = that type in the protocol. The second step is the choice between = FORBIDDEN, REQUIRED or OPTIONAL. The =E2=80=9Cdefault" I=E2=80=99m = talking about is when the protocol designer says the type is in use, but = doesn=E2=80=99t say how its type is indicated. 8392 more or less proceeds like this in the definition of NumericDate. = First it references 2.4.1 of 7049. Second, it says the tag MUST be = omitted (FORBIDDEN). You used the term =E2=80=9Cborrow=E2=80=9D below to say what CWT does = for NumericDate. We could describe it like this: BORROW means use the data type without the type 6 tag USE means a type 6 tag and the content as defined Then USE maps to my REQUIRED and BORROW maps to my FORBIDDEN and = OPTIONAL is when the protocol permits either BORROW or USE. BORROW and USE seem like an OK way to characterize too, but... At this point the word =E2=80=9Ctag=E2=80=9D is confusing to me. When = you say =E2=80=9Cuse Tag 1=E2=80=9D you seem to mean encode a type 6 = integer with value 1 followed by the content which is a number. Unless = explicitly allowed, the type 6 integer and number content are = inseparable. When you say USE tag 1, it means both the type 6 integer = and the number content. By contrast, when CWT refers to the =E2=80=9CCWT = tag=E2=80=9D it is just referring to the type 6 integer. Maybe this is it? CWT is defined first as a *protocol* not a tag. It is = not necessarily part of a CBOR structure. CWT then it says it can be = tagged as one means to identify it. You never need to BORROW the = definition of it. By contrast bignum and such are defined as tags first = so you have to explicitly BORROW if you want to use them without the = type 6 indicating integer. Bignums and friends are assume to be part of = a CBOR structure. With this distinction made manifest, it starts to make sense. Unless explicitly stated bignums, big floats and such always have the = type 6 integer because they are defined in terms of it. Protocols like CWT each state how they wish to be identified and tagging = may be one way. You have to know the nature of a particular tag definition to know = whether the type 6 integer is required or not. Section 6 of 8392 implies some mutual exclusion between the user of = application/cwt and #6.61 to identify a CWT, but it is only implied. In = another thread Jim thought it was OK to have both application/cwt and = #6.61 on the same CWT even though they are redundant. A few more comments below. > On Aug 17, 2020, at 12:40 AM, Carsten Bormann wrote: >=20 > On 2020-08-17, at 07:09, Laurence Lundblade = wrote: >>=20 >> My understanding is that the surrounding protocol that uses a tagged = type dictates whether the tag should be present or not. For example, CWT = dictates that tag 1 (epoch time) must not be used for the =E2=80=9Cexp=E2=80= =9D, =E2=80=9Cnbf=E2=80=9D and =E2=80=9Ciat" claims. >=20 > Yes. More specifically, the CWT protocol does not use Tag 1 for exp, = nbf, iat, but instead borrows that Tag=E2=80=99s specification for its = internal tag content. >=20 >> So the surrounding protocol can pick one of these three when it use a = tagged type. >=20 > Yes. The application protocol needs to define the application = protocol. >=20 >> - Tag is FORBIDDEN (e.g., date fields in CWT). Decode error if tag is = present. >=20 > That is not what the protocol says =E2=80=94 the protocol says it=E2=80=99= s a number. The Tag is FORBIDDEN as much as an array of four byte = strings would be FORBIDDEN. >=20 > (I=E2=80=99m going with your upper case language here; not sure that = adds anything because it makes it seem these words are a menu to choose = from. They aren=E2=80=99t. FORBIDDEN really means =E2=80=9Cdoes not = use the Tag=E2=80=9D.) >=20 >> - Tag is REQUIRED tags (e.g., COSE type tag when CWT tag is present). = Error occurs if tag is absent, probably because item is not of the = expected type. >=20 > This case is similar: The protocol says what it is. The Tag may not = be =E2=80=9CREQUIRED" (there may be other choices for that position), = but to get the semantics of the Tag, you have to provide the Tag. = (I.e., you only get the Tag if you do use the Tag.) >=20 >> - Tag is OPTIONAL (e.g., application/cwt and the CWT tag). Maybe an = error, maybe not.=20 >=20 > That is indeed a special case that does not make a lot of sense = *within* an application protocol, but is useful at its outer boundary: = If you have context (such as a media type), you can use the unadorned = data structure for this protocol, otherwise you use the tag. >=20 >> As far as I can see there isn=E2=80=99t a clear rule about which of = these it is when the surrounding protocol doesn=E2=80=99t explicitly = pick. >=20 > There is no rule about arrays of four byte strings, either. > The application protocol has to define the application protocol. >=20 >> Deterministic encoding does disallow OPTIONAL. >=20 > It says that this decision must be deterministic. There is nothing = wrong about OPTIONAL if all senders arrive at the same decision. >=20 >> If I were to guess as to which is the default, I would say it is = OPTIONAL. >=20 > I have no idea what a =E2=80=9Cdefault" is here. When would you get = to exercise this default? With all the language that argues against = making Tags optional in an application protocol, why or how would this = be the default for anything? >=20 >> Big floats and decimal fractions make use of the bignum type, but the = definition of big floats and decimal fractions doesn=E2=80=99t = explicitly say which of the three above it selects, >=20 > No, because Section 3.4.4 defines a couple of Tags. So for the = definition of the Tag, the Tag is =E2=80=9CREQUIRED=E2=80=9D, because = you only have a tag if you have the tag. Whether other protocols borrow = the specification of the tag content (array of e, m) is not relevant for = the definition of the Tag. >=20 >> so one might think it is OPTIONAL if one assumes that is the default = of the three and that you could distinguish a bignum mantissa because it = is a byte string not an integer. >=20 > Ah, that=E2=80=99s the confusion. >=20 > RFC 7049 predates RFC 8610, so we are not formally describing the tag = content in RFC 7049. RFC 7049 is clear that m and e are integers, but = does not say which kind of integer (that may be a remnant of semantic = validity). Nowhere it says that if the mantissa is something else (like = an array of four byte strings), try to interpret this by guessing tags = that could be used to convert the mantissa into an integer. >=20 > RFC 8610 actually does the work of fully defining the structure of = decfracs and bigfloats: >=20 > decfrac =3D #6.4([e10: int, m: integer]) > bigfloat =3D #6.5([e2: int, m: integer]) >=20 > (integer is defined here: >=20 > integer =3D int / bigint > bigint =3D biguint / bignint > biguint =3D #6.2(bstr) > bignint =3D #6.3(bstr) > int =3D uint / nint > uint =3D #0 > nint =3D #1 > ) But the definition of big floats and decimal fractions should stand on = their own without 8610. >=20 >> One second though, you realize you can=E2=80=99t tell the sign of the = bignum unless there is a tag so it has to be REQUIRED to work. >=20 > Yes. > (More specifically, there are no Tag 2/3 bignums without tags, just as = there are no Tag 1 datetimes without Tag 1. In both cases, an = application protocol could borrow the definition of the structure of the = tag content =E2=80=94 I could define a protocol that accepts a byte = string in a specific position that is then interpreted as an integer by = the application like it would be if it carried Tag 2. Note that this = borrowing is common enough that the CDDL operator ~ (unwrap) directly = supports this, but it is entirely distinct from using the Tag.) >=20 >> My thought is that OPTIONAL adds no value. It is a form of =E2=80=9Cbe= liberal in what you receive=E2=80=9D that seems to be less in favor = these days. When you nest tagged type usage with OPTIONAL, you can get a = larger fan out. =20 >=20 > Don=E2=80=99t do that then [1]. The point is to help other not do that. >=20 >> However, OPTIONAL is allowed in 7049 and things like the = application/cwt media type registry use it. >=20 > What do you mean by =E2=80=9Cis allowed=E2=80=9D? > The application protocol can indeed define (or use) a Tag that can be = used to identify a data item if the identification does not come from = the context. > If it doe,s the tag doesn=E2=80=99t add value. Application/cwt could = have been defined such that it never includes the CWT Tag (i.e., the = COSE tag is outermost); I don=E2=80=99t have a strong opinion on whether = it should have done that. >=20 > None of this is something that could be defined for Tags in general; = the application protocol (here: RFC 8392) needs to make the call. The = media type application/cwt now includes the unneeded choice; an = application might still make further restrictions (always tag 61, never = tag 61). >=20 >> My thought is that it would be helpful to say somewhere that users of = tagged types should explicitly say what the tagging requirement is and = should avoid OPTIONAL tagging. >=20 > There is nothing wrong with what you call =E2=80=9COPTIONAL=E2=80=9D. = You wouldn=E2=80=99t use it on the inside of an application protocol. = You also would specific whether you want a Tag or not in all cases where = the application protocol is embedded into another application protocol. >=20 > Tag 55799 is the prototype of all these =E2=80=9Csignature tags=E2=80=9D= =E2=80=94 you only use it if you don=E2=80=99t have other context to = detect that the byte sequence you have in hand is an encoded CBOR data = item. > An application protocol does not allow or specify this tag unless it = allows or specifies it. >=20 > Indeed, maybe we should say so in notable-tags. > I=E2=80=99ll draft some text. >=20 >> (I came to this trying to write code for tag handling for big float, = EAT, CWT, COSE and such. I=E2=80=99m trying not to be annoying, but also = think this is an issue :-) ) >=20 > It becomes an issue if you somehow associate each Tag with your three = labels FORBIDDEN, REQUIRED, OPTIONAL. Don=E2=80=99t to that then... The association is not with a tag, it is with an item in a protocol. The = APIs are to decode a protocol item as a bignum, an epoch date, a CWT, a = COSE and such and the API wants to know if the tag must be present, must = be absent or can be either. LL >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > [1]: http://www.catb.org/~esr/jargon/html/D/Don-t-do-that-then-.html >=20 --Apple-Mail=_66686154-B009-4DF4-B27C-737B5BBEC44B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = have been thinking of the standardized tag definitions as data type = definitions first and the assignment and use of a tag to indicate the = type as second.

So a = protocol designer decides to use a type, say an epoch date, a CWT or = such first. Then, second, the designer decides how to identify it as = that type in the protocol. The second step is the choice between = FORBIDDEN, REQUIRED or OPTIONAL. The =E2=80=9Cdefault" I=E2=80=99m = talking about is when the protocol designer says the type is in use, but = doesn=E2=80=99t say how its type is indicated.

8392 more or less proceeds like this in = the definition of NumericDate. First it references 2.4.1 of 7049. = Second, it says the tag MUST be omitted (FORBIDDEN).


You used the term =E2=80=9Cborrow=E2=80=9D below to say what = CWT does for NumericDate.  We could describe it like = this:
   BORROW means use the data type = without the type 6 tag
   USE means a = type 6 tag and the content as defined

Then USE maps to my REQUIRED and BORROW = maps to my FORBIDDEN and OPTIONAL is when the protocol permits either = BORROW or USE.

BORROW and USE seem like an OK way to characterize too, = but...


At this point the word =E2=80=9Ctag=E2=80= =9D is confusing to me.  When you say =E2=80=9Cuse Tag 1=E2=80=9D = you seem to mean encode a type 6 integer with value 1 followed by the = content which is a number. Unless explicitly allowed, the type 6 integer = and number content are inseparable. When you say USE tag 1, it means = both the type 6 integer and the number content. By contrast, when CWT = refers to the =E2=80=9CCWT tag=E2=80=9D it is just referring to the type = 6 integer.


Maybe this is it?  CWT is defined = first as a *protocol* not a tag. It is not necessarily part of a CBOR = structure. CWT then it says it can be tagged as one means to identify = it. You never need to BORROW the definition of it. By contrast bignum = and such are defined as tags first so you have to explicitly BORROW if = you want to use them without the type 6 indicating integer. Bignums and = friends are assume to be part of a CBOR structure.

With this distinction = made manifest, it starts to make sense.

Unless explicitly stated = bignums, big floats and such always have the type 6 integer because they = are defined in terms of it.

Protocols like CWT each state how they wish to be identified = and tagging may be one way.

You have to know the nature of a = particular tag definition to know whether the type 6 integer is required = or not.

Section = 6 of 8392 implies some mutual exclusion between the user of = application/cwt and #6.61 to identify a CWT, but it is only implied. In = another thread Jim thought it was OK to have both application/cwt and = #6.61 on the same CWT even though they are redundant.

A few more comments = below.


On Aug = 17, 2020, at 12:40 AM, Carsten Bormann <cabo@tzi.org> wrote:

On = 2020-08-17, at 07:09, Laurence Lundblade <lgl@island-resort.com> wrote:

My understanding is that the = surrounding protocol that uses a tagged type dictates whether the tag = should be present or not. For example, CWT dictates that tag 1 (epoch = time) must not be used for the =E2=80=9Cexp=E2=80=9D, =E2=80=9Cnbf=E2=80=9D= and =E2=80=9Ciat" claims.

Yes. =  More specifically, the CWT protocol does not use Tag 1 for exp, = nbf, iat, but instead borrows that Tag=E2=80=99s specification for its = internal tag content.

So the surrounding protocol can pick one of = these three when it use a tagged type.

Yes.  The application protocol needs to define the = application protocol.

- Tag is FORBIDDEN (e.g., date fields in CWT). = Decode error if tag is present.

That is not what the protocol says =E2=80=94 the protocol = says it=E2=80=99s a number.  The Tag is FORBIDDEN as much as an = array of four byte strings would be FORBIDDEN.

(I=E2=80=99m going with your upper case language here; not = sure that adds anything because it makes it seem these words are a menu = to choose from.  They aren=E2=80=99t.  FORBIDDEN really means = =E2=80=9Cdoes not use the Tag=E2=80=9D.)

- Tag is REQUIRED tags = (e.g., COSE type tag when CWT tag is present). Error occurs if tag is = absent, probably because item is not of the expected type.

This case is similar: The = protocol says what it is.  The Tag may not be =E2=80=9CREQUIRED" = (there may be other choices for that position), but to get the semantics = of the Tag, you have to provide the Tag.  (I.e., you only get the = Tag if you do use the Tag.)

- Tag is OPTIONAL (e.g., application/cwt and = the CWT tag). Maybe an error, maybe not.

That is indeed a special case that does not make a lot of = sense *within* an application protocol, but is useful at its outer = boundary: If you have context (such as a media type), you can use the = unadorned data structure for this protocol, otherwise you use the = tag.

As = far as I can see there isn=E2=80=99t a clear rule about which of these = it is when the surrounding protocol doesn=E2=80=99t explicitly pick.

There is no rule about arrays of = four byte strings, either.
The application protocol has to = define the application protocol.

Deterministic encoding does disallow = OPTIONAL.

It says that this = decision must be deterministic.  There is nothing wrong about = OPTIONAL if all senders arrive at the same decision.

If I were to guess as to = which is the default, I would say it is OPTIONAL.

I have no idea what a =E2=80=9Cdefa= ult" is here.  When would you get to exercise this default? =  With all the language that argues against making Tags optional in = an application protocol, why or how would this be the default for = anything?

Big floats and decimal fractions make use of the bignum type, = but the definition of big floats and decimal fractions doesn=E2=80=99t = explicitly say which of the three above it selects,

No, because Section 3.4.4 defines = a couple of Tags.  So for the definition of the Tag, the Tag is = =E2=80=9CREQUIRED=E2=80=9D, because you only have a tag if you have the = tag.  Whether other protocols borrow the specification of the tag = content (array of e, m) is not relevant for the definition of the = Tag.

so = one might think it is OPTIONAL if one assumes that is the default of the = three and that you could distinguish a bignum mantissa because it is a = byte string not an integer.

Ah, = that=E2=80=99s the confusion.

RFC 7049 = predates RFC 8610, so we are not formally describing the tag content in = RFC 7049.  RFC 7049 is clear that m and e are integers, but does = not say which kind of integer (that may be a remnant of semantic = validity).  Nowhere it says that if the mantissa is something else = (like an array of four byte strings), try to interpret this by guessing = tags that could be used to convert the mantissa into an integer.

RFC 8610 actually does the work of fully = defining the structure of decfracs and bigfloats:

=             &n= bsp;    decfrac =3D #6.4([e10: int, m: integer])
=             &n= bsp;    bigfloat =3D #6.5([e2: int, m: integer])

(integer is defined here:

=             &n= bsp;    integer =3D int / bigint
=             &n= bsp;    bigint =3D biguint / bignint
=             &n= bsp;    biguint =3D #6.2(bstr)
=             &n= bsp;    bignint =3D #6.3(bstr)
=             &n= bsp;    int =3D uint / nint
=             &n= bsp;    uint =3D #0
=             &n= bsp;    nint =3D #1
)

But = the definition of big floats and decimal fractions should stand on their = own without 8610.



One = second though, you realize you can=E2=80=99t tell the sign of the bignum = unless there is a tag so it has to be REQUIRED to work.

Yes.
(More = specifically, there are no Tag 2/3 bignums without tags, just as there = are no Tag 1 datetimes without Tag 1.  In both cases, an = application protocol could borrow the definition of the structure of the = tag content =E2=80=94 I could define a protocol that accepts a byte = string in a specific position that is then interpreted as an integer by = the application like it would be if it carried Tag 2.  Note that = this borrowing is common enough that the CDDL operator ~ (unwrap) = directly supports this, but it is entirely distinct from using the = Tag.)

My= thought is that OPTIONAL adds no value.  It is a form of =E2=80=9Cbe= liberal in what you receive=E2=80=9D that seems to be less in favor = these days. When you nest tagged type usage with OPTIONAL, you can get a = larger fan out.  

Don=E2=80= =99t do that then [1].

The point is to help other not do that.


However, = OPTIONAL is allowed in 7049 and things like the application/cwt media = type registry use it.

What do = you mean by =E2=80=9Cis allowed=E2=80=9D?
The application = protocol can indeed define (or use) a Tag that can be used to identify a = data item if the identification does not come from the context.
If it doe,s the tag doesn=E2=80=99t add value. =  Application/cwt could have been defined such that it never = includes the CWT Tag (i.e., the COSE tag is outermost); I don=E2=80=99t = have a strong opinion on whether it should have done that.

None of this is something that could be = defined for Tags in general; the application protocol (here: RFC 8392) = needs to make the call.  The media type application/cwt now = includes the unneeded choice; an application might still make further = restrictions (always tag 61, never tag 61).

My thought is that it = would be helpful to say somewhere that users of tagged types should = explicitly say what the tagging requirement is and should avoid OPTIONAL = tagging.

There is nothing = wrong with what you call =E2=80=9COPTIONAL=E2=80=9D.  You = wouldn=E2=80=99t use it on the inside of an application protocol. =  You also would specific whether you want a Tag or not in all cases = where the application protocol is embedded into another application = protocol.

Tag 55799 is the prototype of all = these =E2=80=9Csignature tags=E2=80=9D =E2=80=94 you only use it if you = don=E2=80=99t have other context to detect that the byte sequence you = have in hand is an encoded CBOR data item.
An application = protocol does not allow or specify this tag unless it allows or = specifies it.

Indeed, maybe we should say = so in notable-tags.
I=E2=80=99ll draft some text.

(I came = to this trying to write code for tag handling for big float, EAT, CWT, = COSE and such. I=E2=80=99m trying not to be annoying, but also think = this is an issue :-) )

It = becomes an issue if you somehow associate each Tag with your three = labels FORBIDDEN, REQUIRED, OPTIONAL.  Don=E2=80=99t to that = then...

The association is not with a tag, it is with an = item in a protocol. The APIs are to decode a protocol item as a bignum, = an epoch date, a CWT, a COSE and such and the API wants to know if the = tag must be present, must be absent or can be either.

LL



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

[1]: http://www.catb.org/~esr/jargon/html/D/Don-t-do-that-then-.html=


= --Apple-Mail=_66686154-B009-4DF4-B27C-737B5BBEC44B-- From nobody Mon Aug 17 11:23:37 2020 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 EFEEC3A154E for ; Mon, 17 Aug 2020 11:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 SqZ-4ZrKeKF5 for ; Mon, 17 Aug 2020 11:23:33 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58DF3A1576 for ; Mon, 17 Aug 2020 11:23:03 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BVj8P638RzytY; Mon, 17 Aug 2020 20:23:01 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 17 Aug 2020 20:23:01 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 619381381.37963-12b2a228f480908bd0f20f15a704a80c Content-Transfer-Encoding: quoted-printable Message-Id: <1FC978C4-5EB5-42D9-B522-28D72FDCA5B9@tzi.org> References: <5F695632-CF27-40FF-BC23-E731AAA95771@island-resort.com> <895A3DF8-DF11-479F-9DC6-9EF98465A7E0@tzi.org> To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Tagging requirement X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 18:23:36 -0000 On 2020-08-17, at 19:56, Laurence Lundblade = wrote: >=20 > At this point the word =E2=80=9Ctag=E2=80=9D is confusing to me. When = you say =E2=80=9Cuse Tag 1=E2=80=9D you seem to mean encode a type 6 = integer (The argument is not used as an integer, but as a tag number.) > with value 1 followed by the content which is a number. Yes. > Unless explicitly allowed, the type 6 integer and number content are = inseparable.=20 As long as you are talking about Tags, yes: Tags are a major-type 6 = container. You can also borrow the definition of a Tag content data structure for = an application protocol, but then you aren=E2=80=99t using a Tag, you = are using the definition of a Tag content data structure (or =E2=80=9Can = unwrapped tag=E2=80=9D, if you must say so). > When you say USE tag 1, it means both the type 6 integer and the = number content. By contrast, when CWT refers to the =E2=80=9CCWT tag=E2=80= =9D it is just referring to the type 6 integer. We recently revisited that terminology in 7049bis; this is a bit similar = (but inverse) to what are tags and elements in XML =E2=80=94 what are = called elements in XML (except by the 95 % who don=E2=80=99t know the = difference between a tag and an element) are tags in CBOR, and what are = tags in XML are not really discussed very much (they are briefly = referred to as =E2=80=9Cheads=E2=80=9D). Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 17 13:37:57 2020 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 4694F3A11E2 for ; Mon, 17 Aug 2020 13:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 FyTHpbnN5fc6 for ; Mon, 17 Aug 2020 13:37:49 -0700 (PDT) Received: from p3plsmtpa07-05.prod.phx3.secureserver.net (p3plsmtpa07-05.prod.phx3.secureserver.net [173.201.192.234]) (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 138D23A10FB for ; Mon, 17 Aug 2020 13:37:49 -0700 (PDT) Received: from [192.168.1.49] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 7lt6kkqphkxIh7lt6kd6Cw; Mon, 17 Aug 2020 13:37:48 -0700 X-CMAE-Analysis: v=2.3 cv=SPU8q9nH c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=gKmFwSsBAAAA:8 a=K6EGIJCdAAAA:8 a=ey7ATvvnupcXmTZE4YAA:9 a=v15LZa1yhbqMXTkt:21 a=-4PSTzjWFYep3vxg:21 a=QEXdDO2ut3YA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=L6pVIi0Kn1GYQfi8-iRI:22 X-SECURESERVER-ACCT: lgl@island-resort.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Laurence Lundblade In-Reply-To: <1FC978C4-5EB5-42D9-B522-28D72FDCA5B9@tzi.org> Date: Mon, 17 Aug 2020 13:37:47 -0700 Cc: cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <72CC1398-659B-4934-8851-50B8BB4752E1@island-resort.com> References: <5F695632-CF27-40FF-BC23-E731AAA95771@island-resort.com> <895A3DF8-DF11-479F-9DC6-9EF98465A7E0@tzi.org> <1FC978C4-5EB5-42D9-B522-28D72FDCA5B9@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3608.80.23.2.2) X-CMAE-Envelope: MS4wfJcjXT0W6Q5FbcXUwUr2oQEDOKblPFHZUDpvomgh4ndyuEpY3hzQzqzmf/Ck4n2iCWF9ZpMrzygpLRApJ1pLuYU+lSakqgCG3oEO1gzLjcVI21Ez/ell kZEBQNtDglMNjpHNxPOuztU9M6FIaSkyT+3uOLP53FD831bbx1pY+cBJgjT9EtY6GNRjuixu5F5F5w== Archived-At: Subject: Re: [Cbor] Tagging requirement X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 20:37:56 -0000 > On Aug 17, 2020, at 11:23 AM, Carsten Bormann wrote: >=20 > On 2020-08-17, at 19:56, Laurence Lundblade = wrote: >=20 >> with value 1 followed by the content which is a number. >=20 > Yes. >=20 >> Unless explicitly allowed, the type 6 integer and number content are = inseparable.=20 >=20 > As long as you are talking about Tags, yes: Tags are a major-type 6 = container. > You can also borrow the definition of a Tag content data structure for = an application protocol, but then you aren=E2=80=99t using a Tag, you = are using the definition of a Tag content data structure (or =E2=80=9Can = unwrapped tag=E2=80=9D, if you must say so). What do you think about defining CBOR protocol items that can be either = tag-contained or unwrapped? In CDDL, =E2=80=9Cdualistic_bigfloat =3D = bigfloat / ~bigfloat=E2=80=9D.=20 Making a distinction in the way CWT is defined and named from the way = epoch date, bignum and such are defined is what clears it up for me. The definition of the CBOR structure for CWT is independent of the CWT = tag. The CBOR structure for the CWT is defined first. Then the tag = definition comes a long and says is contents is a CWT. For tags epoch date, bignum and such there is no independent definition = of the contents. That content definite is wrapped up with the tag = definition. If you want to use the content without a tag-container you = have to unwrap it. That a tag is a =E2=80=9Ccontainer=E2=80=9D is really helpful to me. Thanks for the discussion on this! LL From nobody Tue Aug 18 12:04:08 2020 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 4918F3A0A34 for ; Tue, 18 Aug 2020 12:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 8i0UE1ka7bxF for ; Tue, 18 Aug 2020 12:04:05 -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 B63333A0917 for ; Tue, 18 Aug 2020 12:04:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2C23A389BE for ; Tue, 18 Aug 2020 14:43:12 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oTG_6u5z_45S for ; Tue, 18 Aug 2020 14:43:08 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5161A389B7 for ; Tue, 18 Aug 2020 14:43:08 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4C2447B for ; Tue, 18 Aug 2020 15:03:59 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org In-Reply-To: <1FC978C4-5EB5-42D9-B522-28D72FDCA5B9@tzi.org> References: <5F695632-CF27-40FF-BC23-E731AAA95771@island-resort.com> <895A3DF8-DF11-479F-9DC6-9EF98465A7E0@tzi.org> <1FC978C4-5EB5-42D9-B522-28D72FDCA5B9@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] Tagging requirement X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 19:04:07 -0000 --=-=-= Content-Type: text/plain Carsten, some year ago we had a lot of discussion when doing 7049bis about what would be described in 7049bis, and what belonged in the Protocol using document. I think that many of Laurence's questions fall into this. I wonder if we need either: 1) a guide to writing CBOR applicability statements. 2) a worked out example. Probably both. While a lot of the more normative advice all through 7049bis, it might be too diffuse to apply quickly. I think CDDL can be used to clarify things, but it might be that some of us need the specific ways beat over our heads. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl88Jh4ACgkQgItw+93Q 3WWLGgf9El98G3f03FIt9m4oIuR66HZ29Oh8jTE9jzcWp6W/txymblPfECM3JcFz 4FVXp9IiULE1rYdlank8PV7ZDKxh6wTrLWViCSR5w4yQGZDRY3gBmTKEjWv36M0x unrrsFV9hMs4aFpvkJu9AWN9mgohBqbT6LNgU0sVBU2yG1AeZalZylVUqMkxYIWs frQbqGXFtIqq7A6cnC420tLkK60kHtVXez5TQMpeMI8VfGDRjiJTzEcUelDRSZDI oL0IUWgk64WbMfD7xolu1pJYg9FX4VUUNqCt3+xRndeQNhV/9yuszoLe2QkfixGP akeIuxd09hFwSQ14rM20UbdjsR8Pew== =0NTb -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 18 12:11:36 2020 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 45EF83A0A41 for ; Tue, 18 Aug 2020 12:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 O6_jcWrV2iKm for ; Tue, 18 Aug 2020 12:11:32 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBEA93A0A3F for ; Tue, 18 Aug 2020 12:11:32 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BWL9t4Rzjz102J; Tue, 18 Aug 2020 21:11:30 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <23965.1597777439@localhost> Date: Tue, 18 Aug 2020 21:11:30 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 619470690.09121-2c32f0a5b76213930261494f3adbf850 Content-Transfer-Encoding: quoted-printable Message-Id: <209669F1-8F6D-4D80-B7B0-38116BE7A66E@tzi.org> References: <5F695632-CF27-40FF-BC23-E731AAA95771@island-resort.com> <895A3DF8-DF11-479F-9DC6-9EF98465A7E0@tzi.org> <1FC978C4-5EB5-42D9-B522-28D72FDCA5B9@tzi.org> <23965.1597777439@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Tagging requirement X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 19:11:35 -0000 Hi Michael, On 2020-08-18, at 21:03, Michael Richardson = wrote: >=20 > Carsten, some year ago we had a lot of discussion when doing 7049bis = about > what would be described in 7049bis, and what belonged in the Protocol = using > document. >=20 > I think that many of Laurence's questions fall into this. > I wonder if we need either: >=20 > 1) a guide to writing CBOR applicability statements. I=E2=80=99m not sure I=E2=80=99m parsing this correctly =E2=80=94 = writing CBOR applicability statements? What do we need an applicability statement for and why would we be = writing many of them? > 2) a worked out example. I think we have about 30 :-) https://datatracker.ietf.org/doc/rfc7049/referencedby/ (This is slightly confused =E2=80=94 it thinks that RFC 8392 has an = informative reference to 7049, and I=E2=80=99m sure the heuristics = failed in other places.) > Probably both. > While a lot of the more normative advice all through 7049bis, it might = be too > diffuse to apply quickly. >=20 > I think CDDL can be used to clarify things, but it might be that some = of > us need the specific ways beat over our heads. I think some of the material about tags could go into notable-tags. But maybe we do need a tutorial document. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Aug 18 12:18:41 2020 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 AC7963A0A6E for ; Tue, 18 Aug 2020 12:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 idML2tsdGusz for ; Tue, 18 Aug 2020 12:18:37 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA31E3A0A73 for ; Tue, 18 Aug 2020 12:18:36 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BWLL32vPLz102v; Tue, 18 Aug 2020 21:18:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <72CC1398-659B-4934-8851-50B8BB4752E1@island-resort.com> Date: Tue, 18 Aug 2020 21:18:34 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 619471114.825635-106db78117fa932f96bcd10defa78f2b Content-Transfer-Encoding: quoted-printable Message-Id: <7A845B58-9313-4B89-9A88-16A4E25A942B@tzi.org> References: <5F695632-CF27-40FF-BC23-E731AAA95771@island-resort.com> <895A3DF8-DF11-479F-9DC6-9EF98465A7E0@tzi.org> <1FC978C4-5EB5-42D9-B522-28D72FDCA5B9@tzi.org> <72CC1398-659B-4934-8851-50B8BB4752E1@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Tagging requirement X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 19:18:40 -0000 On 2020-08-17, at 22:37, Laurence Lundblade = wrote: >=20 >=20 >=20 >> On Aug 17, 2020, at 11:23 AM, Carsten Bormann wrote: >>=20 >> On 2020-08-17, at 19:56, Laurence Lundblade = wrote: >>=20 >>> with value 1 followed by the content which is a number. >>=20 >> Yes. >>=20 >>> Unless explicitly allowed, the type 6 integer and number content are = inseparable.=20 >>=20 >> As long as you are talking about Tags, yes: Tags are a major-type 6 = container. >> You can also borrow the definition of a Tag content data structure = for an application protocol, but then you aren=E2=80=99t using a Tag, = you are using the definition of a Tag content data structure (or =E2=80=9C= an unwrapped tag=E2=80=9D, if you must say so). >=20 > What do you think about defining CBOR protocol items that can be = either tag-contained or unwrapped? In CDDL, =E2=80=9Cdualistic_bigfloat = =3D bigfloat / ~bigfloat=E2=80=9D.=20 I think that this specific example is the OPTIONAL in your previous = message that we would normally try to avoid. > Making a distinction in the way CWT is defined and named from the way = epoch date, bignum and such are defined is what clears it up for me. Good. > The definition of the CBOR structure for CWT is independent of the CWT = tag. The CBOR structure for the CWT is defined first. Then the tag = definition comes a long and says is contents is a CWT. Right. Does it even say that a CWT with a tag 61 around it is a CWT? That is indeed some terminology thing we could try to normalize. > For tags epoch date, bignum and such there is no independent = definition of the contents. That content definite is wrapped up with the = tag definition. If you want to use the content without a tag-container = you have to unwrap it. Indeed. > That a tag is a =E2=80=9Ccontainer=E2=80=9D is really helpful to me. We are not using this term in 7049bis. But if you look at Table 1, there are three (definite-length) major = types that have data items in them: 4 (array), 5 (map), 6 (tag). (Table 2 then reveals that indefinite length strings are represented = like containers, but that is not really their semantics.) > Thanks for the discussion on this! Certainly! Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Aug 18 12:39:57 2020 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 0990C3A0AE2 for ; Tue, 18 Aug 2020 12:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 MggQL1bQ6bob for ; Tue, 18 Aug 2020 12:39:53 -0700 (PDT) Received: from p3plsmtpa07-10.prod.phx3.secureserver.net (p3plsmtpa07-10.prod.phx3.secureserver.net [173.201.192.239]) (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 6B2CA3A0A2E for ; Tue, 18 Aug 2020 12:39:53 -0700 (PDT) Received: from [192.168.1.49] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 87SZkSSD4nJ6Y87SakOQ9V; Tue, 18 Aug 2020 12:39:52 -0700 X-CMAE-Analysis: v=2.3 cv=CMdUoijD c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=gKmFwSsBAAAA:8 a=K6EGIJCdAAAA:8 a=y7ahmQfZmpKuHwsNqd4A:9 a=dStcDggSWP0pHJxe:21 a=DilzaZEiACOcxRui:21 a=QEXdDO2ut3YA:10 a=IXJhIi7PcXi8VagEURgA:9 a=Az6oztVmVF1LGvUA:21 a=_-yZ6xZlO5hdS9ib:21 a=D6ABdLweZOqYZM4z:21 a=_W_S_7VecoQA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=L6pVIi0Kn1GYQfi8-iRI:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <411B47FF-51D5-4D45-9637-FC078CAC9EB4@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_128050FD-B2D0-4C72-8E75-ED9C81C39F13" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 18 Aug 2020 12:39:51 -0700 In-Reply-To: <7A845B58-9313-4B89-9A88-16A4E25A942B@tzi.org> Cc: cbor@ietf.org To: Carsten Bormann References: <5F695632-CF27-40FF-BC23-E731AAA95771@island-resort.com> <895A3DF8-DF11-479F-9DC6-9EF98465A7E0@tzi.org> <1FC978C4-5EB5-42D9-B522-28D72FDCA5B9@tzi.org> <72CC1398-659B-4934-8851-50B8BB4752E1@island-resort.com> <7A845B58-9313-4B89-9A88-16A4E25A942B@tzi.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-CMAE-Envelope: MS4wfEkruDivqXwUPZQzddeg1x9yfFo492lc7uXr6W8kFCz+nm/8W4611Igjuy3N049PdTDCReNAEPFXUIRTEAfDhpAkR2ZWbB62lE8LBB3ljLrLn5Vrc0dM N99E8VPTOkf578b+uy2MMwJ1AL46uhqIjOw90PU0tOWMHz5S9FsIXh7a6xAZPKWnjfkzJYeHL0f3yA== Archived-At: Subject: Re: [Cbor] Tagging requirement X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 19:39:55 -0000 --Apple-Mail=_128050FD-B2D0-4C72-8E75-ED9C81C39F13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I went through some of the registered tags and sorted them as to which = has an independent definition and which do not. This really helps me get = my head straight on this. Pointing out the parallel with maps and arrays = is helpful too. These have tag-independent definitions. If you want to put one of them = into a CBOR item without a tag you just reference the independent = definition. For example, "the first item in an array is a UUID=E2=80=9D.=20= =20 Date string =E2=80=94 RFC 3339 and RFC 4287 URI Regex B64, b64URL=20 MIME CWT COSE_Untagged_Message (there is also COSE_Tagged_Message). These don=E2=80=99t have tag-independent definitions. If you want to = =E2=80=9Cborrow=E2=80=9D the definition, you refer to the tag and then = require it be unwrapped. For example, "the first item in the array is an = unwrapped CBOR numeric date". Or, like CWT, you say it is a =E2=80=9CCBOR = numeric date modified to require the tag be omitted=E2=80=9D.=20 Epoch Date Bignums Big float Decimal fraction Encoded CBOR If you want the tag for either category above you say =E2=80=9Cthe first = item in the array is tag X=E2=80=9D, The definition of tag X will tell = you want the content is. At this point, I think of tags more a typed content.=20 LL > On Aug 18, 2020, at 12:18 PM, Carsten Bormann wrote: >=20 > On 2020-08-17, at 22:37, Laurence Lundblade > wrote: >>=20 >>=20 >>=20 >>> On Aug 17, 2020, at 11:23 AM, Carsten Bormann wrote: >>>=20 >>> On 2020-08-17, at 19:56, Laurence Lundblade = wrote: >>>=20 >>>> with value 1 followed by the content which is a number. >>>=20 >>> Yes. >>>=20 >>>> Unless explicitly allowed, the type 6 integer and number content = are inseparable.=20 >>>=20 >>> As long as you are talking about Tags, yes: Tags are a major-type 6 = container. >>> You can also borrow the definition of a Tag content data structure = for an application protocol, but then you aren=E2=80=99t using a Tag, = you are using the definition of a Tag content data structure (or =E2=80=9C= an unwrapped tag=E2=80=9D, if you must say so). >>=20 >> What do you think about defining CBOR protocol items that can be = either tag-contained or unwrapped? In CDDL, =E2=80=9Cdualistic_bigfloat = =3D bigfloat / ~bigfloat=E2=80=9D.=20 >=20 > I think that this specific example is the OPTIONAL in your previous = message that we would normally try to avoid. >=20 >> Making a distinction in the way CWT is defined and named from the way = epoch date, bignum and such are defined is what clears it up for me. >=20 > Good. >=20 >> The definition of the CBOR structure for CWT is independent of the = CWT tag. The CBOR structure for the CWT is defined first. Then the tag = definition comes a long and says is contents is a CWT. >=20 > Right. Does it even say that a CWT with a tag 61 around it is a CWT? >=20 > That is indeed some terminology thing we could try to normalize. >=20 >> For tags epoch date, bignum and such there is no independent = definition of the contents. That content definite is wrapped up with the = tag definition. If you want to use the content without a tag-container = you have to unwrap it. >=20 > Indeed. >=20 >> That a tag is a =E2=80=9Ccontainer=E2=80=9D is really helpful to me. >=20 > We are not using this term in 7049bis. > But if you look at Table 1, there are three (definite-length) major = types that have data items in them: 4 (array), 5 (map), 6 (tag). > (Table 2 then reveals that indefinite length strings are represented = like containers, but that is not really their semantics.) >=20 >> Thanks for the discussion on this! >=20 > Certainly! >=20 > Gr=C3=BC=C3=9Fe, Carsten --Apple-Mail=_128050FD-B2D0-4C72-8E75-ED9C81C39F13 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I went through some of the registered tags = and sorted them as to which has an independent definition and which do = not. This really helps me get my head straight on this. Pointing out the = parallel with maps and arrays is helpful too.

These = have tag-independent definitions. If you want to put one of them into a = CBOR item without a tag you just reference the independent definition. = For example, "the first item in an array is a = UUID=E2=80=9D. 
  
 Date string =E2=80=94 RFC 3339 and RFC = 4287
 URI
 Regex
 B64, = b64URL 
 MIME
 CWT
COSE_Untagged_Message = (there is also COSE_Tagged_Message).


These don=E2=80=99t= have tag-independent definitions. If you want to =E2=80=9Cborrow=E2=80=9D= the definition, you refer to the tag and then require it be unwrapped. = For example, "the first item in the array is an unwrapped CBOR numeric = date". Or, like CWT, you say it is a =E2=80=9CCBOR numeric date modified = to require the tag be omitted=E2=80=9D. 

 Epoch = Date
 Bignums
 Big = float
 Decimal fraction
 Encoded = CBOR

If you = want the tag for either category above you say =E2=80=9Cthe first item = in the array is tag X=E2=80=9D, The definition of tag X will tell you = want the content is.


At this point, I think of tags more a typed = content. 

LL




On Aug = 18, 2020, at 12:18 PM, Carsten Bormann <cabo@tzi.org> wrote:

On 2020-08-17, at 22:37, = Laurence Lundblade <lgl@island-resort.com> wrote:



On Aug 17, 2020, at = 11:23 AM, Carsten Bormann <cabo@tzi.org> wrote:

On = 2020-08-17, at 19:56, Laurence Lundblade <lgl@island-resort.com> wrote:

with value 1 followed by = the content which is a number.

Yes.

Unless explicitly allowed, the type 6 integer and number = content are inseparable. 

As long as you are talking about = Tags, yes: Tags are a major-type 6 container.
You can also = borrow the definition of a Tag content data structure for an application = protocol, but then you aren=E2=80=99t using a Tag, you are using the = definition of a Tag content data structure (or =E2=80=9Can unwrapped = tag=E2=80=9D, if you must say so).

What do you think about defining CBOR protocol items that can = be either tag-contained or unwrapped?  In CDDL, = =E2=80=9Cdualistic_bigfloat =3D bigfloat / ~bigfloat=E2=80=9D. 

I think that this specific example is the OPTIONAL in your = previous message that we would normally try to avoid.

Making = a distinction in the way CWT is defined and named from the way epoch = date, bignum and such are defined is what clears it up for me.

Good.

The definition of the CBOR structure = for CWT is independent of the CWT tag. The CBOR structure for the CWT is = defined first. Then the tag definition comes a long and says is contents = is a CWT.

Right.  Does it even say that a CWT with a tag 61 around = it is a CWT?

That is = indeed some terminology thing we could try to normalize.

For = tags epoch date, bignum and such there is no independent definition of = the contents. That content definite is wrapped up with the tag = definition. If you want to use the content without a tag-container you = have to unwrap it.

Indeed.

That a tag is a =E2=80=9Ccontainer=E2=80= =9D is really helpful to me.

We are not using this term in = 7049bis.
But if you = look at Table 1, there are three (definite-length) major types that have = data items in them: 4 (array), 5 (map), 6 (tag).
(Table 2 then reveals that = indefinite length strings are represented like containers, but that is = not really their semantics.)

Thanks for the discussion on this!

Certainly!

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

= --Apple-Mail=_128050FD-B2D0-4C72-8E75-ED9C81C39F13-- From nobody Tue Aug 18 14:31:07 2020 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 B053E3A0CFC for ; Tue, 18 Aug 2020 14:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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 GvfanEvbSrZq for ; Tue, 18 Aug 2020 14:31:03 -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 EF9D13A0F30 for ; Tue, 18 Aug 2020 14:30:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D1DF7389B3; Tue, 18 Aug 2020 17:10:05 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8o-7opi9V6V8; Tue, 18 Aug 2020 17:10:05 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D52F2389B2; Tue, 18 Aug 2020 17:10:04 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E7DA465A; Tue, 18 Aug 2020 17:30:55 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: cbor@ietf.org In-Reply-To: <209669F1-8F6D-4D80-B7B0-38116BE7A66E@tzi.org> References: <5F695632-CF27-40FF-BC23-E731AAA95771@island-resort.com> <895A3DF8-DF11-479F-9DC6-9EF98465A7E0@tzi.org> <1FC978C4-5EB5-42D9-B522-28D72FDCA5B9@tzi.org> <23965.1597777439@localhost> <209669F1-8F6D-4D80-B7B0-38116BE7A66E@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] Tagging requirement X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 21:31:06 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 2020-08-18, at 21:03, Michael Richardson w= rote: >> >> Carsten, some year ago we had a lot of discussion when doing 7049bis= about >> what would be described in 7049bis, and what belonged in the Protoco= l using >> document. >> >> I think that many of Laurence's questions fall into this. >> I wonder if we need either: >> >> 1) a guide to writing CBOR applicability statements. > I=E2=80=99m not sure I=E2=80=99m parsing this correctly =E2=80=94 wri= ting CBOR applicability statements? > What do we need an applicability statement for and why would we be wr= iting many of them? No, it is about how, when doing EAT, or DOTS, or GRASP, or CoSWID, ... how are we applying CBOR. >> 2) a worked out example. > I think we have about 30 :-) > https://datatracker.ietf.org/doc/rfc7049/referencedby/ > (This is slightly confused =E2=80=94 it thinks that RFC 8392 has an i= nformative > reference to 7049, and I=E2=80=99m sure the heuristics failed in othe= r places.) Yes. But, if I wanted to tell someone which one to use, which one would I use? There are many which are not useful. >> Probably both. >> While a lot of the more normative advice all through 7049bis, it mig= ht be too >> diffuse to apply quickly. >> >> I think CDDL can be used to clarify things, but it might be that som= e of >> us need the specific ways beat over our heads. > I think some of the material about tags could go into notable-tags. > But maybe we do need a tutorial document. Yes, it's a tutorial about writing a document that references CBOR. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl88SI8ACgkQgItw+93Q 3WViIQgAtXgTMyl9497kJ0ARz6F8bF99Lyf69T6LRhQfEjpzAmYh/uxuXM77acvx +p056Vqh3TcSMp7kN6Hlb4frtxRxOUpVbJ5aD0IHBoloKMEwBfRKQ4UWwjZIQ1sO LWfTn3Wd3iS7ohSBnHxcMyJi1iZZ5jkq+bgVqhb09UE15Lsm5BsVHBBXElj5q/vI IQS6CNGmSBhquyBJRCC5LLyQ4xL/CDBAMkqKKBQOBBTLUFZXVlDxe9nPvu1OuJeQ cv+qgFKarel4XXOyL4Xg1wlwO0xE7PXI58/29YetvedvuqgEWoNlQTPtZsK6iydV bED4NFQpIQ2Dy8Ult19CLdvTwrQjGQ== =KAKY -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 26 15:30:05 2020 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 DF9BF3A0954; Wed, 26 Aug 2020 15:29:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <159848099883.24803.2854964028170482383@ietfa.amsl.com> Date: Wed, 26 Aug 2020 15:29:58 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-date-tag-06.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 22:29:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF. Title : Concise Binary Object Representation (CBOR) Tags for Date Authors : Michael B. Jones Anthony Nadalin Jörg Richter Filename : draft-ietf-cbor-date-tag-06.txt Pages : 7 Date : 2020-08-26 Abstract: The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (RFC 3339 date/time string) and tag 1 (Posix "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for an RFC 3339 date text string, for applications needing a textual date representation within the Gregorian calendar without a time. It also defines a CBOR tag for days since the date 1970-01-01 in the Gregorian calendar for applications needing a numeric date representation without a time. This specification is intended as the reference document for IANA registration of the CBOR tags defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-date-tag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-date-tag-06 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-date-tag-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-date-tag-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 26 15:33:51 2020 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 67B6C3A097E; Wed, 26 Aug 2020 15:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 Do0cW7-flZYb; Wed, 26 Aug 2020 15:33:47 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650099.outbound.protection.outlook.com [40.107.65.99]) (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 B84FE3A0965; Wed, 26 Aug 2020 15:33:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hCzEBvvmLlOmkXAba84oDtVGTE/L4gPHerj6n1iIH81zLfe/rs61jqmCUQAvoo+YD/w6xDUuXPgs2JXcbFwUuOy47l6fJ1IuY4jApDhdbKMvXWTeSCxw9UbcR3aNLsmSfrWnkK53FVZafG7UKCtkqTqImQhnprQZYeouLUHOZWQZcnhwu40liY+T0kFD06d2vyVrRSowTir9EsjnCoaxQGt0/4nauBmOit9JuH+4t2p7wKmAw95SvPb3Le8PiBo833cYusmTeMPnrmmea910fyjEkLq0HulSuiqxH0T3WoFusuAMqLp0H1rMOeYq/EVGLrPCZgqmqd0ui2IjTPK+jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ljksb4UioGm66w2regbo2/4obXm1aAcQFjX1YJPF8Wk=; b=kawAUJsQW4Dktqy7sXHa6m6j65BG2hU24eNfqJ9zJf7F2WHWlkURX9XHcW/gCqHjNNCScIvjiRSJCdEW9ITmyiEcemYfGvGe1ePnVob3Hu8Ya9dxF+i027trlnVYu7nk1v+FByLOo+cDGP8Vvi/jl5oUyttNTJ4eQpPP8QLnaO2Zw2VEEK6eMXh5oHroygMXSvo/brV1/Gb97+o0PFhuXJf+VvNSZikGsM/DHjC7X75A8zzcT7yffHmvZKXHP6OK1ERFB9FDC7GdiNjUm5YizG91KW/YCYEGL6URI7SHwQQU12HmbUIGFMpWBVvQbOCMNRyngJdniMWNZVoEx6uPjQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ljksb4UioGm66w2regbo2/4obXm1aAcQFjX1YJPF8Wk=; b=MCFfNTnU2ZippKIUZ7MNkPizysD8VcrJt4oyg8ky5KsWgZVItLMkIhCLREao45RDQXrnBCh4ebmBT4ZkZZ49+FNR287S/eBFWm05aLYZ63LfMK/rWYMmZOWWdAcmWO2U8NSUzzWQ7RygTNqIjceFSdvoQ1udmmJlvmEH5+52l4A= Received: from (2603:10b6:610:a9::23) by CH2PR00MB0711.namprd00.prod.outlook.com (2603:10b6:610:ad::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3367.0; Wed, 26 Aug 2020 22:33:41 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::b8b7:3f55:bae6:5458]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::b8b7:3f55:bae6:5458%6]) with mapi id 15.20.3368.000; Wed, 26 Aug 2020 22:33:41 +0000 From: Mike Jones To: Kyle Rose , "secdir@ietf.org" CC: "draft-ietf-cbor-date-tag.all@ietf.org" , "last-call@ietf.org" , "cbor@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-cbor-date-tag-05 Thread-Index: AdZx1BxyoBjm9wtuR3uPvOkylOb0YQKJJuNA Date: Wed, 26 Aug 2020 22:33:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-14T00:28:56Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5ae9dac8-a305-4f45-8149-fa8770de83f5; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: krose.org; dkim=none (message not signed) header.d=none;krose.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.86.243] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 70253109-12f4-4b27-665b-08d84a1015a0 x-ms-traffictypediagnostic: CH2PR00MB0711: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6GdMAxVwpLtJW4Zf3fe053sC9OpQwRHpPPWKegIi3oaXSghTGU34/I6dmUK7eQGlfKaoTp+3UrgCmwGJF04xNXbARnqVrgii6A8JTcvzHbZ2HCW95jvdknfMQYw9i/ot6iq/WczLo5W4CijP5SkIcXQBCgThD1vfeX8zD4x38UNbghaSVR3/kZlkF7Neij/oQnT1XfmYQ//dxCzLBU8Mb24FmnP3MaeNkRoDY3ITX56UouF+DetgtZGEmOw+PS5QBX0nQz9XNQ8K4YXm57WqRVHeOvfXctubabvd0v9JJS1gPn7bFTq+aZuzl0XRV3cLQN28sUDCIU1764sQqZ1xZJ+4sP2BzAwtgHPIy5umJAqeRjQ4rDh/VaCEJPoBTNDApBMlUgggnlNGtZPfa/pKEA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(376002)(136003)(366004)(346002)(33656002)(66946007)(66556008)(66446008)(66476007)(64756008)(52536014)(86362001)(71200400001)(966005)(4326008)(7696005)(478600001)(53546011)(83080400001)(55016002)(82950400001)(5660300002)(82960400001)(6506007)(83380400001)(316002)(166002)(8990500004)(26005)(186003)(9326002)(54906003)(2906002)(9686003)(8676002)(76116006)(110136005)(8936002)(10290500003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: US5Wd1nt1GBbkgQ5tc0Bk3YvfkqD2dctv/4E9dLbZyfJUGIb/51BluZNDWkHejQIW8/EYiAlcKWD2b1bFuPj2ioHGyMSkuxdF7KI+4jVLPhW9IcDhk6lgwI/aUGN7cTJpmLtthFgIWNutOSI07eaEKHwwrArkl68Mvi1InvN42cOYiSXl8ZG+7fuZ/YKU99qqmOWnJeoeCjHeFiyGgRkHvWQVKUT/LhqRaRSJGuQTjW/2vOkCfe7blsvOxP1mO2oJOpQwEa4ZvXD+6Q6KS8YQvm1RBIJLiunqAfFXE6NVKFeY7H573hnTNRu4gEKMFTe9PqMiVaqYuFahkx02cW7HxVQKkyw/mOVH8eFytBsqbY5odyj2yhEXDhEhcHStHxVxsryLYHQalmupTt9VcOZ7wP7dP1PFzDteoesPhuh05YJtWLAOVLbZVMbT6kAO3vz6zF/BCKIL7kUki6JqlgYmv6wMn8fO2kLfINMA/mo08t+mMA+7CUx8Y7g+jhO5fTDrxqaR+cY0RKLL8j4lASarbxDzDNyfY6UEmKEa7ZATDv8VP8sd0uqWIFA0Hu/jvZ6KAKVWeRl5v+FR2isvcrSQOt/SRgg5TKTbyB3DnVGvI82Z5EprQNqR9GO5VQQaKcJwXgJYvY+3vSv1gVaKKurjQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB067816A0AD84C4DFEA0D8B06F5541CH2PR00MB0678namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70253109-12f4-4b27-665b-08d84a1015a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2020 22:33:41.4247 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IGvMxMB8G8xNngRso5rotAiDGusC+ShPgNkbTclsq5+4aH/w8JXk8xIk1QCZlLBDjbjAaWnhASw2kSsShxfDUg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0711 Archived-At: Subject: Re: [Cbor] Secdir last call review of draft-ietf-cbor-date-tag-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 22:33:49 -0000 --_000_CH2PR00MB067816A0AD84C4DFEA0D8B06F5541CH2PR00MB0678namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS3lsZSwNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2Jvci1k YXRlLXRhZy0wNiBhZGRzIHRoZSBjZXJ0aWZpY2F0ZSBleHBpcmF0aW9uIGV4YW1wbGUgdGhhdCB5 b3Ugc3VnZ2VzdGVkLiAgVGhhbmtzIGFnYWluIGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmV2aWV3 IHRoZSBkcmFmdCENCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogTWlrZSBKb25lcw0KU2VudDogVGh1cnNkYXks IEF1Z3VzdCAxMywgMjAyMCA1OjQ1IFBNDQpUbzogJ0t5bGUgUm9zZScgPGtyb3NlQGtyb3NlLm9y Zz47IHNlY2RpckBpZXRmLm9yZw0KQ2M6IGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy5hbGxAaWV0 Zi5vcmc7IGxhc3QtY2FsbEBpZXRmLm9yZzsgY2JvckBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFNl Y2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wNQ0KDQoN ClRoYW5rcyBmb3IgeW91ciB0aG91Z2h0ZnVsIHJldmlldywgS3lsZS4gIE15IHJlcGxpZXMgdG8g eW91ciBjb21tZW50cyBhcmUgaW5saW5lLi4uDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogS3lsZSBSb3NlIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZzxt YWlsdG86bm9yZXBseUBpZXRmLm9yZz4+DQpTZW50OiBNb25kYXksIEF1Z3VzdCAxMCwgMjAyMCAx MTo0OCBBTQ0KVG86IHNlY2RpckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPg0KQ2M6 IGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYt Y2Jvci1kYXRlLXRhZy5hbGxAaWV0Zi5vcmc+OyBsYXN0LWNhbGxAaWV0Zi5vcmc8bWFpbHRvOmxh c3QtY2FsbEBpZXRmLm9yZz47IGNib3JAaWV0Zi5vcmc8bWFpbHRvOmNib3JAaWV0Zi5vcmc+DQpT dWJqZWN0OiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWNib3ItZGF0ZS10 YWctMDUNCg0KDQoNClJldmlld2VyOiBLeWxlIFJvc2UNCg0KUmV2aWV3IHJlc3VsdDogSGFzIE5p dHMNCg0KDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNl Y3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRv Y3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJl IHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBk aXJlY3RvcnMuDQoNCkRvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQg dGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoN Cg0KDQpUaGlzIGRvY3VtZW50IGlzIHJlYWR5IHdpdGggbml0cy4gSSBzZWUgbm8gaXNzdWVzIG9m IGludGVyZXN0IHRvIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZS4NCg0KDQoNCkkgZG8gaGF2ZSB0 aHJlZSBjb21tZW50cywgaG93ZXZlcjoNCg0KDQoNCiogSW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHNlY3Rpb24sIGEgYmV0dGVyIGV4YW1wbGUgbWlnaHQgYmUgdGhlIHBvdGVudGlhbCBp bmFwcHJvcHJpYXRlbmVzcyBvZiB1c2luZyBhbiBpbXByZWNpc2UgbWVjaGFuaXNtIGZvciBzcGVj aWZ5aW5nIGNlcnRpZmljYXRlIGV4cGlyYXRpb24uDQoNCg0KDQpJJ2xsIHBsYW4gdG8gYWRkIHRo aXMgZXhhbXBsZSB3aGVuIGFkZHJlc3Npbmcgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQoN Cg0KKiBJdCdzIG5vdCBjbGVhciBob3cgdGhpcyBpcyBpbnRlbmRlZCB0byB3b3JrIGZvciBkYXRl cyBwcmlvciB0byB0aGUgc3RhcnQgb2YgdGhlIEdyZWdvcmlhbiBjYWxlbmRhciBpbiAxNTgyLiBX aGF0IGRvIG5lZ2F0aXZlIGludGVnZXIgdmFsdWVzIG1lYW4gd2hlbiB0aGV5IGltcGx5IGEgZGF0 ZSBiZWZvcmUgMTUtT2N0LTE1ODI/IElzIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIgZGVmaW5lZCBm b3IgYWxsIHRpbWU/IEluIGEgYnJpZWYgaW52ZXN0aWdhdGlvbiwgSSd2ZSBiZWVuIHVuYWJsZSB0 byBmaW5kIHRoZSBhbnN3ZXIgdG8gdGhpcy4NCg0KDQoNClNlZSB0aGUgc2VjdGlvbiBpbiB0aGUg SW50cm9kdWN0aW9uIG9uIHRoZSByZWxhdGlvbnNoaXAgdG8gdGhlIE1vZGlmaWVkIEp1bGlhbiBE YXRlIHZhbHVlIGFuZCB0aGVuIHNlZSBodHRwczovL2NvcmUyLmdzZmMubmFzYS5nb3YvdGltZS8g Zm9yIHRoZSByZWxhdGlvbnNoaXAgb2YgdGhlIE1vZGlmaWVkIEp1bGlhbiBEYXRlIHRvIHRoZSBK dWxpYW4gRGF0ZSwgYSB0aW1lc2NhbGUgZGVmaW5lZCBieSB0aGUgU21pdGhzb25pYW4gQXN0cm9u b21pY2FsIE9ic2VydmF0b3J5IGJlZ2lubmluZyBhdCBub29uIDEgSmFudWFyeSA0NzEzIEIuQy4g IFRoYXQgc2VlbXMgdG8gZ28gZmFyIGJhY2sgZW5vdWdoIGZvciBtb3N0IHByYWN0aWNhbCBwdXJw b3Nlcy4NCg0KDQoNCkludGVyZXN0aW5nbHksIGFjY29yZGluZyB0byBodHRwczovL2VuLndpa2lw ZWRpYS5vcmcvd2lraS9KdWxpYW5fZGF5Og0KDQrigJxUaGUgTW9kaWZpZWQgSnVsaWFuIERhdGUg KE1KRCkgd2FzIGludHJvZHVjZWQgYnkgdGhlIFNtaXRoc29uaWFuIEFzdHJvcGh5c2ljYWwgT2Jz ZXJ2YXRvcnkgaW4gMTk1NyB0byByZWNvcmQgdGhlIG9yYml0IG9mIFNwdXRuaWsgdmlhIGFuIElC TSA3MDQgKDM2LWJpdCBtYWNoaW5lKSBhbmQgdXNpbmcgb25seSAxOCBiaXRzIHVudGlsIEF1Z3Vz dCA3LCAyNTc2LiBNSkQgaXMgdGhlIGVwb2NoIG9mIFZBWC9WTVMgYW5kIGl0cyBzdWNjZXNzb3Ig T3BlblZNUywgdXNpbmcgNjMtYml0IGRhdGUvdGltZSwgd2hpY2ggYWxsb3dzIHRpbWVzIHRvIGJl IHN0b3JlZCB1cCB0byBKdWx5IDMxLCAzMTA4NiwgMDI6NDg6MDUuNDcuWzE4XSBUaGUgTUpEIGhh cyBhIHN0YXJ0aW5nIHBvaW50IG9mIG1pZG5pZ2h0IG9uIE5vdmVtYmVyIDE3LCAxODU4IGFuZCBp cyBjb21wdXRlZCBieSBNSkQgPSBKRCAtIDI0MDAwMDAuNS7igJ0NCg0KDQoNCiogSW4gYSB2ZXJ5 IGdyb3NzIHNlbnNlLCB0aGlzIHNwZWNpZmljYXRpb24gKmlzKiBhY3R1YWxseSB0aWVkIHRvIHRo ZSBwcmV2YWlsaW5nIHRpbWVzY2FsZSwgbGVhcCBzZWNvbmRzIGFuZCBhbGw6IGlmIHRoZSB3aG9s ZSB3b3JsZCB3ZXJlIHRvIHRyYW5zaXRpb24gZnJvbSBVVEMgdG8gVEFJIGFuZCBzdG9wIGFkZGlu ZyBsZWFwIHNlY29uZHMsIHByZXN1bWFibHkgaW1wbGVtZW50YXRpb25zIHdvdWxkIGNvbnRpbnVl IHRvIGdlbmVyYXRlIGRhdGVzIGZvciB0aGlzIHNwZWNpZmljYXRpb24gYnkgdHJ1bmNhdGluZyB0 aGUgbG9jYWwgdGltZXN0YW1wIHRvIHRoZSBkYXRlLCB3aGljaCB3b3VsZCBjYXVzZSBpdCB0byBk cmlmdCBhbG9uZyB3aXRoIFRBSSBhd2F5IGZyb20gVVRDIG92ZXIgdGltZS4gVGhlcmUgd291bGRu J3QgYmUgYSBodWdlIHByYWN0aWNhbCBlZmZlY3QgaGVyZSBnaXZlbiBob3cgbGl0dGxlIHRoZXkg YXJlIGV4cGVjdGVkIHRvIGRpdmVyZ2Ugb3ZlciB0aGUgZm9yZXNlZWFibGUgZnV0dXJlLCBidXQg aXQgd291bGQgbWVhbiB0aGF0IGRhdGVzIGVuY29kZWQgaW4gdGhpcyBmb3JtYXQgdG9kYXkgd291 bGQgbm90IGNhcnJ5IGVub3VnaCBpbmZvcm1hdGlvbiB0byBwcmVjaXNlbHkgaW5kaWNhdGUgYSBk YXRlIGluIHRoZSBmYXIgZnV0dXJlIGV2ZW4gaWYgdGhlIHRhcmdldCB0aW1lc2NhbGUgd2VyZSB1 bmRlcnN0b29kIHRocm91Z2hvdXQgc2luY2UgdGhlIHNvdXJjZSB0aW1lc2NhbGUgaXNuJ3QgcGFy dCBvZiB0aGUgZW5jb2RpbmcuDQoNCg0KDQpJZiBpdOKAmXMgZ29vZCBlbm91Z2ggZm9yIHRoZSBT bWl0aHNvbmlhbiBBc3Ryb25vbWljYWwgT2JzZXJ2YXRvcnkgKGFsYmVpdCwgdXRpbGl6aW5nIGEg ZGVmaW5lZCBpbnRlZ2VyIG9mZnNldCksIGl04oCZcyBnb29kIGVub3VnaCBmb3IgbWUuIDstKSAg VGltZWtlZXBpbmcgaXMgdWx0aW1hdGVseSBhIGh1bWFuIGN1bHR1cmFsIGVuZGVhdm9yIGFuZCBp dOKAmXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24gdG8gcHJvYmUgaXRz IG1hbnkgdmFyaWF0aW9ucyBhbmQgZm9pYmxlcy4gIFRoZSBlc3NlbmNlIG9mIGRhdGVzIGlzIHRo YXQgZWFjaCB0aW1lIHRoZSB3b3JsZCBnb2VzIHJvdW5kLCB0aGVzZSB2YWx1ZXMgaW5jcmVtZW50 LiAgVGhhdCBzYWlkLCBpZiB5b3UgaGF2ZSBzcGVjaWZpYyB0ZXh0IHlvdeKAmWQgbGlrZSB0byBz ZWUgYWRkZWQsIEnigJltIG9wZW4gdG8gaXQuDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmVzdCB3aXNoZXMsDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN Cg0KDQpQLlMuICBJIG5ldmVyIGV4cGVjdGVkIHRoYXQgd3JpdGluZyB0aGlzIHZlcnkgc2ltcGxl IHNwZWNpZmljYXRpb24gd291bGQgcmVzdWx0IGluIHN1Y2ggaW50ZXJlc3RpbmcgZGlzY3Vzc2lv bnMgYWJvdXQgdGltZWtlZXBpbmchDQoNCg0K --_000_CH2PR00MB067816A0AD84C4DFEA0D8B06F5541CH2PR00MB0678namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1 NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5IaSBLeWxlLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jYm9y LWRhdGUtdGFnLTA2Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jYm9y LWRhdGUtdGFnLTA2PC9hPiBhZGRzIHRoZSBjZXJ0aWZpY2F0ZSBleHBpcmF0aW9uIGV4YW1wbGUg dGhhdCB5b3Ugc3VnZ2VzdGVkLiZuYnNwOyBUaGFua3MgYWdhaW4gZm9yIHRha2luZyB0aGUgdGlt ZSB0byByZXZpZXcgdGhlIGRyYWZ0ITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBNaWtlIEpvbmVzIDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDEz LCAyMDIwIDU6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+ICdLeWxlIFJvc2UnICZsdDtrcm9zZUBrcm9z ZS5vcmcmZ3Q7OyBzZWNkaXJAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LWlldGYtY2Jv ci1kYXRlLXRhZy5hbGxAaWV0Zi5vcmc7IGxhc3QtY2FsbEBpZXRmLm9yZzsgY2JvckBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTA1PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5UaGFua3MgZm9yIHlvdXIgdGhvdWdodGZ1bCByZXZpZXcsIEt5bGUuJm5ic3A7 IE15IHJlcGxpZXMgdG8geW91ciBjb21tZW50cyBhcmUgaW5saW5lLi4uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogS3ls ZSBSb3NlIHZpYSBEYXRhdHJhY2tlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5v cmciPm5vcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGJyPg0KU2VudDogTW9uZGF5LCBBdWd1c3Qg MTAsIDIwMjAgMTE6NDggQU08YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9y ZyI+c2VjZGlyQGlldGYub3JnPC9hPjxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0 Zi1jYm9yLWRhdGUtdGFnLmFsbEBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLmFs bEBpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86bGFzdC1jYWxsQGlldGYub3JnIj5sYXN0 LWNhbGxAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86Y2JvckBpZXRmLm9yZyI+DQpjYm9y QGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRy YWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wNTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5S ZXZpZXdlcjogS3lsZSBSb3NlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5SZXZpZXcgcmVzdWx0OiBIYXMgTml0czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5J IGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJl Y3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVp bmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiZuYnNwOyBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0 ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3Rv cnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Eb2N1bWVudCBlZGl0 b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBh bnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5UaGlzIGRvY3VtZW50IGlzIHJlYWR5IHdpdGggbml0cy4gSSBzZWUgbm8gaXNzdWVzIG9mIGlu dGVyZXN0IHRvIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+SSBkbyBoYXZlIHRocmVlIGNvbW1lbnRzLCBob3dldmVyOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4qIEluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9u LCBhIGJldHRlciBleGFtcGxlIG1pZ2h0IGJlIHRoZSBwb3RlbnRpYWwgaW5hcHByb3ByaWF0ZW5l c3Mgb2YgdXNpbmcgYW4gaW1wcmVjaXNlIG1lY2hhbmlzbSBmb3Igc3BlY2lmeWluZyBjZXJ0aWZp Y2F0ZSBleHBpcmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkknbGwgcGxhbiB0byBhZGQgdGhpcyBleGFtcGxlIHdoZW4gYWRkcmVz c2luZyBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4qIEl0J3Mgbm90IGNs ZWFyIGhvdyB0aGlzIGlzIGludGVuZGVkIHRvIHdvcmsgZm9yIGRhdGVzIHByaW9yIHRvIHRoZSBz dGFydCBvZiB0aGUgR3JlZ29yaWFuIGNhbGVuZGFyIGluIDE1ODIuIFdoYXQgZG8gbmVnYXRpdmUg aW50ZWdlciB2YWx1ZXMgbWVhbiB3aGVuIHRoZXkgaW1wbHkgYSBkYXRlIGJlZm9yZSAxNS1PY3Qt MTU4Mj8gSXMgdGhlIEdyZWdvcmlhbiBjYWxlbmRhciBkZWZpbmVkIGZvciBhbGwgdGltZT8NCiBJ biBhIGJyaWVmIGludmVzdGlnYXRpb24sIEkndmUgYmVlbiB1bmFibGUgdG8gZmluZCB0aGUgYW5z d2VyIHRvIHRoaXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+U2VlIHRoZSBzZWN0aW9uIGluIHRoZSBJbnRyb2R1Y3Rpb24gb24gdGhlIHJl bGF0aW9uc2hpcCB0byB0aGUgTW9kaWZpZWQgSnVsaWFuIERhdGUgdmFsdWUgYW5kIHRoZW4gc2Vl DQo8YSBocmVmPSJodHRwczovL2NvcmUyLmdzZmMubmFzYS5nb3YvdGltZS8iPmh0dHBzOi8vY29y ZTIuZ3NmYy5uYXNhLmdvdi90aW1lLzwvYT4gZm9yIHRoZSByZWxhdGlvbnNoaXAgb2YgdGhlIE1v ZGlmaWVkIEp1bGlhbiBEYXRlIHRvIHRoZSBKdWxpYW4gRGF0ZSwgYSB0aW1lc2NhbGUgZGVmaW5l ZCBieSB0aGUgU21pdGhzb25pYW4gQXN0cm9ub21pY2FsIE9ic2VydmF0b3J5IGJlZ2lubmluZyBh dCBub29uIDEgSmFudWFyeSA0NzEzIEIuQy4mbmJzcDsgVGhhdA0KIHNlZW1zIHRvIGdvIGZhciBi YWNrIGVub3VnaCBmb3IgbW9zdCBwcmFjdGljYWwgcHVycG9zZXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkludGVyZXN0aW5nbHksIGFjY29yZGluZyB0byA8YSBocmVm PSJodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9KdWxpYW5fZGF5Ij4NCmh0dHBzOi8vZW4u d2lraXBlZGlhLm9yZy93aWtpL0p1bGlhbl9kYXk8L2E+OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPuKAnFRoZSBNb2RpZmllZCBKdWxpYW4gRGF0ZSAoTUpEKSB3YXMg aW50cm9kdWNlZCBieSB0aGUgU21pdGhzb25pYW4gQXN0cm9waHlzaWNhbCBPYnNlcnZhdG9yeSBp biAxOTU3IHRvIHJlY29yZCB0aGUgb3JiaXQgb2YgU3B1dG5payB2aWEgYW4gSUJNIDcwNCAoMzYt Yml0IG1hY2hpbmUpIGFuZCB1c2luZyBvbmx5IDE4IGJpdHMNCiB1bnRpbCBBdWd1c3QgNywgMjU3 Ni4gTUpEIGlzIHRoZSBlcG9jaCBvZiBWQVgvVk1TIGFuZCBpdHMgc3VjY2Vzc29yIE9wZW5WTVMs IHVzaW5nIDYzLWJpdCBkYXRlL3RpbWUsIHdoaWNoIGFsbG93cyB0aW1lcyB0byBiZSBzdG9yZWQg dXAgdG8gSnVseSAzMSwgMzEwODYsIDAyOjQ4OjA1LjQ3LlsxOF0gVGhlIE1KRCBoYXMgYSBzdGFy dGluZyBwb2ludCBvZiBtaWRuaWdodCBvbiBOb3ZlbWJlciAxNywgMTg1OCBhbmQgaXMgY29tcHV0 ZWQgYnkgTUpEDQogPSBKRCAtIDI0MDAwMDAuNS7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiogSW4gYSB2ZXJ5 IGdyb3NzIHNlbnNlLCB0aGlzIHNwZWNpZmljYXRpb24gKmlzKiBhY3R1YWxseSB0aWVkIHRvIHRo ZSBwcmV2YWlsaW5nIHRpbWVzY2FsZSwgbGVhcCBzZWNvbmRzIGFuZCBhbGw6IGlmIHRoZSB3aG9s ZSB3b3JsZCB3ZXJlIHRvIHRyYW5zaXRpb24gZnJvbSBVVEMgdG8gVEFJIGFuZCBzdG9wIGFkZGlu ZyBsZWFwIHNlY29uZHMsIHByZXN1bWFibHkgaW1wbGVtZW50YXRpb25zIHdvdWxkIGNvbnRpbnVl DQogdG8gZ2VuZXJhdGUgZGF0ZXMgZm9yIHRoaXMgc3BlY2lmaWNhdGlvbiBieSB0cnVuY2F0aW5n IHRoZSBsb2NhbCB0aW1lc3RhbXAgdG8gdGhlIGRhdGUsIHdoaWNoIHdvdWxkIGNhdXNlIGl0IHRv IGRyaWZ0IGFsb25nIHdpdGggVEFJIGF3YXkgZnJvbSBVVEMgb3ZlciB0aW1lLiBUaGVyZSB3b3Vs ZG4ndCBiZSBhIGh1Z2UgcHJhY3RpY2FsIGVmZmVjdCBoZXJlIGdpdmVuIGhvdyBsaXR0bGUgdGhl eSBhcmUgZXhwZWN0ZWQgdG8gZGl2ZXJnZSBvdmVyDQogdGhlIGZvcmVzZWVhYmxlIGZ1dHVyZSwg YnV0IGl0IHdvdWxkIG1lYW4gdGhhdCBkYXRlcyBlbmNvZGVkIGluIHRoaXMgZm9ybWF0IHRvZGF5 IHdvdWxkIG5vdCBjYXJyeSBlbm91Z2ggaW5mb3JtYXRpb24gdG8gcHJlY2lzZWx5IGluZGljYXRl IGEgZGF0ZSBpbiB0aGUgZmFyIGZ1dHVyZSBldmVuIGlmIHRoZSB0YXJnZXQgdGltZXNjYWxlIHdl cmUgdW5kZXJzdG9vZCB0aHJvdWdob3V0IHNpbmNlIHRoZSBzb3VyY2UgdGltZXNjYWxlIGlzbid0 IHBhcnQNCiBvZiB0aGUgZW5jb2RpbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SWYgaXTigJlzIGdvb2QgZW5vdWdoIGZvciB0aGUgU21p dGhzb25pYW4gQXN0cm9ub21pY2FsIE9ic2VydmF0b3J5IChhbGJlaXQsIHV0aWxpemluZyBhIGRl ZmluZWQgaW50ZWdlciBvZmZzZXQpLCBpdOKAmXMgZ29vZCBlbm91Z2ggZm9yIG1lLiA7LSkgJm5i c3A7VGltZWtlZXBpbmcgaXMgdWx0aW1hdGVseSBhIGh1bWFuIGN1bHR1cmFsIGVuZGVhdm9yIGFu ZCBpdOKAmXMgYmV5b25kDQogdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiB0byBwcm9i ZSBpdHMgbWFueSB2YXJpYXRpb25zIGFuZCBmb2libGVzLiZuYnNwOyBUaGUgZXNzZW5jZSBvZiBk YXRlcyBpcyB0aGF0IGVhY2ggdGltZSB0aGUgd29ybGQgZ29lcyByb3VuZCwgdGhlc2UgdmFsdWVz IGluY3JlbWVudC4mbmJzcDsgVGhhdCBzYWlkLCBpZiB5b3UgaGF2ZSBzcGVjaWZpYyB0ZXh0IHlv deKAmWQgbGlrZSB0byBzZWUgYWRkZWQsIEnigJltIG9wZW4gdG8gaXQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBCZXN0IHdpc2hlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QLlMuJm5ic3A7IEkgbmV2 ZXIgZXhwZWN0ZWQgdGhhdCB3cml0aW5nIHRoaXMgdmVyeSBzaW1wbGUgc3BlY2lmaWNhdGlvbiB3 b3VsZCByZXN1bHQgaW4gc3VjaCBpbnRlcmVzdGluZyBkaXNjdXNzaW9ucyBhYm91dCB0aW1la2Vl cGluZyE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_CH2PR00MB067816A0AD84C4DFEA0D8B06F5541CH2PR00MB0678namp_-- From nobody Thu Aug 27 00:57:23 2020 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 A3DEF3A0E3C; Thu, 27 Aug 2020 00:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 aZytlccVkmIZ; Thu, 27 Aug 2020 00:57:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DF523A0E3B; Thu, 27 Aug 2020 00:57:15 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 27 Aug 2020 00:57:09 -0700 From: Jim Schaad To: CC: Date: Thu, 27 Aug 2020 00:57:07 -0700 Message-ID: <008c01d67c47$aaf73be0$00e5b3a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdZ8HUNl6mcdBpDzSxeWAllddNi0ng== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Packed CBOR and dictionaries X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 07:57:21 -0000 In the past two weeks packed CBOR has come up in two different contexts and I have started trying to think how I would write a compression routine that would be reasonable quick but still give good results. Part of the question that I keep running into is the fact that the use of a dictionary is going to change how I approach this. I may find that I want to put dictionary entries into the prefix or shared section of the packed structure depending on how far down in the dictionary the entries are. * Should we be doing an equivalent draft to CBOR packed about how to use dictionaries? I think that having a standard dictionary expansion is going to be important. * Should the dictionary expansion be separate or part of this draft? I am not sure how I want to address this. If you have a dictionary w/ 50,000 entries in it, that is going to change how things should be done. It may also be that one might want to use a dictionary entry for something that might otherwise be encoded as a prefix and the prefix might not be needed anymore. * When building a dictionary, do I only want to do compete substitutions, or it be recommended that prefixes also be encoded into the dictionary. This would mean that if dictionaries are treated completely separately that a prefix encoding is needed there as well, but that encoding might be to a substitution in the prefix section of the packed data followed by a prefix using the packed encoding. Being able to do packed is going to be of importance for doing CoRAL, but just as important is being able to do dictionaries. Dictionaries do have the downside that if they are not referenced internal to the structure then from a security point of view they can be problematic as the signed/encrypted CBOR byte stream is no longer self-contained. This is not a problem for packed CBOR as long as the packing does not cross the security boundary. Jim From nobody Thu Aug 27 01:05:34 2020 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 1D2ED3A0E51; Thu, 27 Aug 2020 01:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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 Vql25m3AYMx4; Thu, 27 Aug 2020 01:05:31 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAD753A0E4C; Thu, 27 Aug 2020 01:05:30 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 27 Aug 2020 01:05:24 -0700 From: Jim Schaad To: CC: Date: Thu, 27 Aug 2020 01:05:23 -0700 Message-ID: <008d01d67c48$d25c4440$7714ccc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdZ8SHGvHcW3bURCSR6HY4XY2dTJLA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Ordering of items in the prefix table X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 08:05:33 -0000 I was just going through an expansion algorithm and I started to wonder if we should have a requirement about order of items in the prefix table. Specifically if an entry in the prefix table uses a prefix itself (i.e. entry 3 in the table is 6.2872("foo")), does that entry need to occur after the entry it references? Jim From nobody Thu Aug 27 11:13:29 2020 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 7D4673A11C0; Thu, 27 Aug 2020 11:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 uHiFNFP-qZk9; Thu, 27 Aug 2020 11:13:25 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0683A11AA; Thu, 27 Aug 2020 11:13:24 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 27 Aug 2020 11:12:59 -0700 From: Jim Schaad To: CC: Date: Thu, 27 Aug 2020 11:12:57 -0700 Message-ID: <00b201d67c9d$b2fd1b10$18f75130$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdZ8mProVh929J/fRoqjhKb3w1O2sQ== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Review of draft-ietf-cbor-tags-oid-00 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 18:13:27 -0000 * Is (should) there be a way to have a map which can have a mix of OID and binary fields w/o having to individually apply the tag to every OID in the map? (Assuming we are just talking about keys.) ** Addressing the request for discussion in the draft: * Only doing one layer seems to me to be high preferable due to the inability to turn the tag off. I would be perfectly happy with [111({ h'550406': "US" }), 111({ h'550407': "Los Angeles", h'550408': "CA", h'550411': "90013" }), 111({ h'550409': "532 S Olive St" }), 111 ({ h'55040f': "Public Park", h'0992268993f22c640130': "Pershing Square" })] * A different, and strange, restriction would be to state that you can inherit though one array, one map, or one (array then map). This is going to cover all of the cases that we would every care about but makes sure that if you have an array within an array the tag does not continue to migrate downwards after the first array. You still have the question about canceling the effect on a true binary field. However the following would not be understood as doing the inheritance of the tag. 111([ { h'550406': "US" }, [{ h'550407': "Los Angeles"},{ h'550408': "CA"}, { h'550411': "90013" }], { h'550409': "532 S Olive St" }, [{ h'55040f': "Public Park"}, [ h'0992268993f22c640130': "Pershing Square" }] ]) 111([ [ h'550406', "US" ], [[ h'550407', "Los Angeles"], [h'550408', "CA"], [ h'550411', "90013"]], [ h'550409', "532 S Olive St"], [[ h'55040f', "Public Park"], [h'0992268993f22c640130', "Pershing Square"]] ]) (yes I know that this does not match the subject name of X.500 but it might be a better representation than what is there.) Jim From nobody Thu Aug 27 14:00:59 2020 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 407113A131F; Thu, 27 Aug 2020 14:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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 4RWs8y87j2BU; Thu, 27 Aug 2020 14:00:56 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09BB43A131B; Thu, 27 Aug 2020 14:00:55 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 27 Aug 2020 14:00:50 -0700 From: Jim Schaad To: CC: Date: Thu, 27 Aug 2020 14:00:48 -0700 Message-ID: <00c101d67cb5$2588b790$709a26b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdZ8s0xpKERBvw7yTZyxz2a31flriA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Interactions of packed CBOR and tags X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 21:00:57 -0000 While building a test library of strings for evaluating my algorithm, I ended up with a question of how tags interact with the idea of CBOR packing. Specifically, if I use a standard date/time string with tag 0, should that text string be considered as a candidate for packing? 0("1970-01-01T00:00Z") could potentially be compressed to 0(simple(3)) The problem is that this is no longer a valid CBOR encoding so it would not seem to be a legal thing to do. Question: Must packed CBOR be valid CBOR or does that requirement only apply to unpacked CBOR? Jim From nobody Thu Aug 27 14:32:29 2020 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 449223A138B; Thu, 27 Aug 2020 14:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 ZnwfxzQCRAmc; Thu, 27 Aug 2020 14:32:24 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F44F3A1389; Thu, 27 Aug 2020 14:32:23 -0700 (PDT) Received: from client-0051.vpn.uni-bremen.de (client-0051.vpn.uni-bremen.de [134.102.107.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BcwtD23Krz100g; Thu, 27 Aug 2020 23:32:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <00c101d67cb5$2588b790$709a26b0$@augustcellars.com> Date: Thu, 27 Aug 2020 23:32:19 +0200 Cc: draft-bormann-cbor-packed@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 620256739.813588-3ee99f684967157e218ac5249f0ecc41 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00c101d67cb5$2588b790$709a26b0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Interactions of packed CBOR and tags X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 21:32:27 -0000 > On 2020-08-27, at 23:00, Jim Schaad wrote: >=20 > While building a test library of strings for evaluating my algorithm, = I > ended up with a question of how tags interact with the idea of CBOR = packing. > Specifically, if I use a standard date/time string with tag 0, should = that > text string be considered as a candidate for packing? >=20 > 0("1970-01-01T00:00Z") could potentially be compressed to 0(simple(3)) >=20 > The problem is that this is no longer a valid CBOR encoding so it = would not > seem to be a legal thing to do. >=20 > Question: Must packed CBOR be valid CBOR or does that requirement = only > apply to unpacked CBOR? Great question. The cop-out could be: either. Since CBOR-valid packed CBOR is a subset of (just well-formed) packed = CBOR, it could be a parameter given to the compressor whether that is = allowed to use compression opportunities like the above or not. What are the benefits/drawbacks: * (just well-formed) packed CBOR may lead to trouble with a generic = decoder that cannot handle (present to the application) invalid = constructs like 0(simple(3)). The application can decide whether it wants to live with this limitation = or not. * the structural coherence of the packed structure (that this draft is = about) will be expressed as a validity constraint. It is a bit weird to = then relax validity of what goes in there, but not entirely without = precedent (e.g., tag 24, even though there is a more explicit firewall = here). * not using those compression opportunities can be wasteful, not just = for the example given above (tag 0), but also for tags like 32. I think I would emphasize the (just well-formed) packed CBOR, but still = introduce CBOR-valid packed CBOR as a selectable additional constraint = for applications that need to work with pre-packed (designed before = packed was invented) generic decoders. Do we need to encode this selection? (E.g., via different top-level = tags.) Probably not. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Aug 27 16:26:24 2020 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 C29B63A140B for ; Thu, 27 Aug 2020 16:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 oNu27OTjQk6P for ; Thu, 27 Aug 2020 16:26:21 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BAA73A1408 for ; Thu, 27 Aug 2020 16:26:21 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 27 Aug 2020 16:26:15 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: References: <00c101d67cb5$2588b790$709a26b0$@augustcellars.com> In-Reply-To: Date: Thu, 27 Aug 2020 16:26:14 -0700 Message-ID: <00cc01d67cc9$766c7b60$63457220$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHF41LwYmnJHHEpyMn9bwuLrqikDwI3uBqqqVwMZMA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Interactions of packed CBOR and tags X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 23:26:23 -0000 -----Original Message----- From: Carsten Bormann =20 Sent: Thursday, August 27, 2020 2:32 PM To: Jim Schaad Cc: draft-bormann-cbor-packed@ietf.org; cbor@ietf.org Subject: Re: [Cbor] Interactions of packed CBOR and tags > On 2020-08-27, at 23:00, Jim Schaad wrote: >=20 > While building a test library of strings for evaluating my algorithm,=20 > I ended up with a question of how tags interact with the idea of CBOR = packing. > Specifically, if I use a standard date/time string with tag 0, should=20 > that text string be considered as a candidate for packing? >=20 > 0("1970-01-01T00:00Z") could potentially be compressed to 0(simple(3)) >=20 > The problem is that this is no longer a valid CBOR encoding so it=20 > would not seem to be a legal thing to do. >=20 > Question: Must packed CBOR be valid CBOR or does that requirement=20 > only apply to unpacked CBOR? Great question. The cop-out could be: either. Since CBOR-valid packed CBOR is a subset of (just well-formed) packed = CBOR, it could be a parameter given to the compressor whether that is = allowed to use compression opportunities like the above or not. What are the benefits/drawbacks: * (just well-formed) packed CBOR may lead to trouble with a generic = decoder that cannot handle (present to the application) invalid = constructs like 0(simple(3)). The application can decide whether it wants to live with this limitation = or not. * the structural coherence of the packed structure (that this draft is = about) will be expressed as a validity constraint. It is a bit weird to = then relax validity of what goes in there, but not entirely without = precedent (e.g., tag 24, even though there is a more explicit firewall = here). * not using those compression opportunities can be wasteful, not just = for the example given above (tag 0), but also for tags like 32. I think I would emphasize the (just well-formed) packed CBOR, but still = introduce CBOR-valid packed CBOR as a selectable additional constraint = for applications that need to work with pre-packed (designed before = packed was invented) generic decoders. [JLS] Yes I agree that only requiring that the result be well-formed = makes the most sense. It probably makes sense to discuss the = implications in the document. A more interesting case might be tag 26 = which could have duplicate or prefix lines of text coming up frequently. I think it might make sense to reference tag 25 and say that this does = the same thing only much better. [/JLS] Do we need to encode this selection? (E.g., via different top-level = tags.) Probably not. [JLS] I don't think that there needs to be different top-level tags. =20 Jim Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 28 11:20:55 2020 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 B3CAD3A1090; Fri, 28 Aug 2020 11:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 FwGi5QTd_-73; Fri, 28 Aug 2020 11:20:45 -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 1A2F03A1060; Fri, 28 Aug 2020 11:20:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C3A73389D2; Fri, 28 Aug 2020 13:59:41 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZoJhx2Usfu1B; Fri, 28 Aug 2020 13:59:39 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CCB6E389D7; Fri, 28 Aug 2020 13:59:38 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4DD5E6D2; Fri, 28 Aug 2020 14:20:38 -0400 (EDT) From: Michael Richardson To: Jim Schaad , draft-bormann-cbor-packed@ietf.org, cbor@ietf.org In-Reply-To: <008c01d67c47$aaf73be0$00e5b3a0$@augustcellars.com> References: <008c01d67c47$aaf73be0$00e5b3a0$@augustcellars.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] Packed CBOR and dictionaries X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 18:20:53 -0000 --=-=-= Content-Type: text/plain I feel that the WG should adopt the document already. Jim Schaad wrote: > * Should the dictionary expansion be separate or part of this draft? I am > not sure how I want to address this. If you have a dictionary w/ 50,000 > entries in it, that is going to change how things should be done. It may > also be that one might want to use a dictionary entry for something that > might otherwise be encoded as a prefix and the prefix might not be needed > anymore. Once the dictionary is larger than 512, I guess 131072 is the next size. That uses four-byte references, and so the dictionary ought to provide at least four-byte substitutions, right? Otherwise, we'd be expanding rather then compressing. It seems that a (C,Python,etc.) array is probably always appropriate as the internal datastructure to perform lookups into the dictionary. It shouldn't require a sparse array, ever, should it? > Being able to do packed is going to be of importance for doing CoRAL, but > just as important is being able to do dictionaries. Dictionaries do have > the downside that if they are not referenced internal to the structure then > from a security point of view they can be problematic as the > signed/encrypted CBOR byte stream is no longer self-contained. This is not > a problem for packed CBOR as long as the packing does not cross the security > boundary. Agreed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9JSvYACgkQgItw+93Q 3WUCuQf9HM298bNAxhpOzLMwJwSSEh/fRSnfXRVJopd0UTAmGz3AsE92F/v++Xj8 4Zx313GVVW1fH8xFKUgFdSIky+4I7QQWRQfg2o9M7zICVMdHXzh8E6+V0y0ECgJm ToZ6KDHHEuE5S2joGm1s7UOEVyxBqsES31fobbpeXbdb7i2DcV4OHqqFrI+qd/cL pNWPEdW9G1K1V8FON5puQ24fOKMyqgHKkn1ln383xXTIibFrgL3mvT8K0MOSSDpL JDObwNokUy1BEycO4bYBdAz50xxLAwI2Q8yFDkwxOCGFNf7jNEFBEuzJOOEt5aSb 6G2TECwFDVbaw2ikqAC1PlfBoDTORw== =SjDq -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 28 11:24:55 2020 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 498413A0100; Fri, 28 Aug 2020 11:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 wOaffOQPaLao; Fri, 28 Aug 2020 11:24:52 -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 CCC6C3A0037; Fri, 28 Aug 2020 11:24:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 49A14389D5; Fri, 28 Aug 2020 14:03:51 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dUsLqmvyLU97; Fri, 28 Aug 2020 14:03:49 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BC6B3389D7; Fri, 28 Aug 2020 14:03:48 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A9486B3; Fri, 28 Aug 2020 14:24:46 -0400 (EDT) From: Michael Richardson To: Jim Schaad , draft-bormann-cbor-packed@ietf.org, cbor@ietf.org In-Reply-To: <008d01d67c48$d25c4440$7714ccc0$@augustcellars.com> References: <008d01d67c48$d25c4440$7714ccc0$@augustcellars.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] Ordering of items in the prefix table X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 18:24:54 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: > I was just going through an expansion algorithm and I started to wonder if > we should have a requirement about order of items in the prefix table. > Specifically if an entry in the prefix table uses a prefix itself (i.e. > entry 3 in the table is 6.2872("foo")), does that entry need to occur after > the entry it references? I also asked that question. If we don't enforce that rule, then the decoder has to take care of dealing with loops. This means either having a maximum loop depth, or, using a mark to refuse to expand any specific dictionary item more than once. I would prefer that all references are forward references. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9JS+4ACgkQgItw+93Q 3WVvzwgAvRobYajxR02Z53ryXkXzabnGmVSQTm3x48P6tF+e4kkKtHbpAz21ER1U Ls+O8RsPRFDmgawSvG51VPW5JfhQVMJIllE1UZG+QZjTm1AaR9Ylm+vVVqMk0HJp xqx8/O2ox4RPZ7wVl4MbM9ACDj/puc6Y4ePUJ9ADaYl4uEL2iU6Jis5rw6eFbEFE oDUGRFXLZL8kb/7kCWziTnAP0B3l9DFTDZsw9w+HiWJ3Nw6WcmNELHfQHpHj++Tf yHzP/egbqJdZVdyuharQKEtnMYlqYshid1f7I14cxcVYyo9XOsrv46APDMlBykvs 2iuAmi1BZ/Oa/vqHBbIEBZG0muC4CA== =qOyM -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 28 11:30:37 2020 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 020D43A0869; Fri, 28 Aug 2020 11:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 2sgr2Cjt-76V; Fri, 28 Aug 2020 11:30:27 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5A43A078C; Fri, 28 Aug 2020 11:30:24 -0700 (PDT) Received: from client-0018.vpn.uni-bremen.de (client-0018.vpn.uni-bremen.de [134.102.107.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BdSnp6b14zyX7; Fri, 28 Aug 2020 20:30:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <29638.1598639086@localhost> Date: Fri, 28 Aug 2020 20:30:22 +0200 Cc: Jim Schaad , draft-bormann-cbor-packed@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 620332222.440344-2f72313b827bdce7f9fd0ac2339e3acf Content-Transfer-Encoding: quoted-printable Message-Id: References: <008d01d67c48$d25c4440$7714ccc0$@augustcellars.com> <29638.1598639086@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Ordering of items in the prefix table X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 18:30:36 -0000 On 2020-08-28, at 20:24, Michael Richardson = wrote: >=20 >=20 > Jim Schaad wrote: >> I was just going through an expansion algorithm and I started to = wonder if >> we should have a requirement about order of items in the prefix = table. >> Specifically if an entry in the prefix table uses a prefix itself = (i.e. >> entry 3 in the table is 6.2872("foo")), does that entry need to occur = after >> the entry it references? >=20 > I also asked that question. > If we don't enforce that rule, then the decoder has to take care of = dealing > with loops. Right. > This means either having a maximum loop depth, or, using a mark to = refuse to > expand any specific dictionary item more than once. > I would prefer that all references are forward references. (Backward references?) This is easy with just one kind of table entry, but gets harder when = prefixes can reference shared items which can reference other prefixes = and so on. Of course, the tables could be merged, but that loses exactly one bit = per reference that can be derived from the prefix vs. shared reference. One other thing to keep in mind is that not all places in the table are = equal =E2=80=94 the compressor will likely sort the entries by frequency = of use. Requiring infrequent entries to occupy all the good positions = does not lead to very compact encoding. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 28 11:40:10 2020 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 9379A3A078C; Fri, 28 Aug 2020 11:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 KiATFakft9s8; Fri, 28 Aug 2020 11:40:06 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCABE3A07E3; Fri, 28 Aug 2020 11:40:05 -0700 (PDT) Received: from client-0018.vpn.uni-bremen.de (client-0018.vpn.uni-bremen.de [134.102.107.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BdT101JRfzyX7; Fri, 28 Aug 2020 20:40:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <28732.1598638838@localhost> Date: Fri, 28 Aug 2020 20:40:03 +0200 Cc: Jim Schaad , draft-bormann-cbor-packed@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 620332803.753612-8dbb63f4de4310a414328d79b9faf6e1 Content-Transfer-Encoding: quoted-printable Message-Id: <80C336B5-2A10-44BF-B214-7CFA1B159923@tzi.org> References: <008c01d67c47$aaf73be0$00e5b3a0$@augustcellars.com> <28732.1598638838@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Packed CBOR and dictionaries X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 18:40:09 -0000 OK, I think we need to answer a few questions first. Is there only ever one dictionary that is being referenced? Or can you reference multiple? (An alternative to referencing multiple is creating a way to merge = dictionaries, however that might also create combinatorial explosion.) How are shared items/prefixes from the packed data items merged with the = ones from the dictionary/ies to the number space actually used for = referencing? How are dictionaries identified (URI, hint pulling from context, digest, = any combination of that)? I have a design that is based on specific answers for all these = questions, but I=E2=80=99d like to hear what others think before pushing = that. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 28 12:00:39 2020 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 5BF5F3A0B75; Fri, 28 Aug 2020 12:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 Vnp-yrWcpEDY; Fri, 28 Aug 2020 12:00:26 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F9E3A09DF; Fri, 28 Aug 2020 12:00:24 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 28 Aug 2020 12:00:16 -0700 From: Jim Schaad To: 'Michael Richardson' , , References: <008c01d67c47$aaf73be0$00e5b3a0$@augustcellars.com> <28732.1598638838@localhost> In-Reply-To: <28732.1598638838@localhost> Date: Fri, 28 Aug 2020 12:00:15 -0700 Message-ID: <013401d67d6d$786e4c50$694ae4f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQEWrwsIZUXc1W2qApLXh9kZsjj9lAK3TH/EqrfA0BA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Packed CBOR and dictionaries X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 19:00:37 -0000 -----Original Message----- From: Michael Richardson Sent: Friday, August 28, 2020 11:21 AM To: Jim Schaad ; draft-bormann-cbor-packed@ietf.org; cbor@ietf.org Subject: Re: [Cbor] Packed CBOR and dictionaries I feel that the WG should adopt the document already. [JLS] The WG was promised an updated draft that dealt with a couple of issues before the adoption call was made. Jim Schaad wrote: > * Should the dictionary expansion be separate or part of this draft? I am > not sure how I want to address this. If you have a dictionary w/ 50,000 > entries in it, that is going to change how things should be done. It may > also be that one might want to use a dictionary entry for something that > might otherwise be encoded as a prefix and the prefix might not be needed > anymore. Once the dictionary is larger than 512, I guess 131072 is the next size. That uses four-byte references, and so the dictionary ought to provide at least four-byte substitutions, right? Otherwise, we'd be expanding rather then compressing. It seems that a (C,Python,etc.) array is probably always appropriate as the internal datastructure to perform lookups into the dictionary. It shouldn't require a sparse array, ever, should it? [JLS] That raises a different question. At one point when I was emailing Klaus about the fact that dictionaries in CoRAL are only defined to use positive integers, there was some discussion that the negative values would be for a more application specific version of a dictionary. That would make it 256 and 65,XXX. It might be interesting to have "sparse" dictionaries. Consider that you might want all of the URLs without a fragment to occur at a smaller section that the same set of all URLs with fragments. This means that you can get smaller compressions for CoRAL vocabulary that does not include all of the possible values using just the base URL. Jim > Being able to do packed is going to be of importance for doing CoRAL, but > just as important is being able to do dictionaries. Dictionaries do have > the downside that if they are not referenced internal to the structure then > from a security point of view they can be problematic as the > signed/encrypted CBOR byte stream is no longer self-contained. This is not > a problem for packed CBOR as long as the packing does not cross the security > boundary. Agreed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Fri Aug 28 12:21:03 2020 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 3315F3A094F; Fri, 28 Aug 2020 12:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 V2edO84GCI51; Fri, 28 Aug 2020 12:20:58 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE8B3A093C; Fri, 28 Aug 2020 12:20:57 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 28 Aug 2020 12:20:51 -0700 From: Jim Schaad To: 'Carsten Bormann' , 'Michael Richardson' CC: , References: <008c01d67c47$aaf73be0$00e5b3a0$@augustcellars.com> <28732.1598638838@localhost> <80C336B5-2A10-44BF-B214-7CFA1B159923@tzi.org> In-Reply-To: <80C336B5-2A10-44BF-B214-7CFA1B159923@tzi.org> Date: Fri, 28 Aug 2020 12:20:50 -0700 Message-ID: <013501d67d70$58fa34d0$0aee9e70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQEWrwsIZUXc1W2qApLXh9kZsjj9lAK3TH/EAmZ0d36qpI94gA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Packed CBOR and dictionaries X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 19:21:02 -0000 -----Original Message----- From: Carsten Bormann =20 Sent: Friday, August 28, 2020 11:40 AM To: Michael Richardson Cc: Jim Schaad ; = draft-bormann-cbor-packed@ietf.org; cbor@ietf.org Subject: Re: [Cbor] Packed CBOR and dictionaries OK, I think we need to answer a few questions first. Is there only ever one dictionary that is being referenced? Or can you reference multiple? [JLS] I believe that the correct answer is either one or two. The = ability to reference more than two seems to be more problematic than it = is worthwhile. Allowing for the ability to reference two allows for the = option of using "the" global CoRAL dictionary plus a more application = specific dictionary containing lots of problem details information. Two = also allows for easy identification as you can use negative vs = non-negative as the differentiation between them.=20 [JLS] I have a (currently) slight preference for allowing two, but it is = definitely not a hill I would die on. =20 (An alternative to referencing multiple is creating a way to merge = dictionaries, however that might also create combinatorial explosion.) How are shared items/prefixes from the packed data items merged with the = ones from the dictionary/ies to the number space actually used for = referencing? [JLS] I was not planning on packing dictionaries. Hmmmmmmm Seems = slightly problematic as items are added to the dictionary. How are dictionaries identified (URI, hint pulling from context, digest, = any combination of that)? [JLS] For cryptographic purposes it needs to be a digest. That does = cause problems with versioning however. One of the interesting question = is does an application need to be able to pull down a new dictionary or = does it only deal with dictionaries that it is pre-loaded with. Not = doing so means that dictionary version negotiation is needed (see = previous mails on dictionaries in CoRAL -- = https://mailarchive.ietf.org/arch/msg/t2trg/oVWf3x2ighHiU7b7K-xJte7jC_c/ = is an example). Doing so means that you might get surprises about not = being able to get the dictionary that you need. Naming for use and = naming for negotiation might be different identifiers.=20 I have a design that is based on specific answers for all these = questions, but I=E2=80=99d like to hear what others think before pushing = that. [JLS] Sounds good=20 Jim Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 28 14:16:12 2020 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 471E13A0C80; Fri, 28 Aug 2020 14:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 qh9VL2L2RJJV; Fri, 28 Aug 2020 14:16:10 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986003A0C7F; Fri, 28 Aug 2020 14:16:09 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 28 Aug 2020 14:16:01 -0700 From: Jim Schaad To: 'Carsten Bormann' , 'Michael Richardson' CC: , References: <008d01d67c48$d25c4440$7714ccc0$@augustcellars.com> <29638.1598639086@localhost> In-Reply-To: Date: Fri, 28 Aug 2020 14:16:00 -0700 Message-ID: <014101d67d80$6f9e4ea0$4edaebe0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQFtMUzFC8cyVB3HBTXm03SCxCjA2QFt+GF3AuvedJWp/bV+sA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Ordering of items in the prefix table X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 21:16:11 -0000 -----Original Message----- From: Carsten Bormann =20 Sent: Friday, August 28, 2020 11:30 AM To: Michael Richardson Cc: Jim Schaad ; = draft-bormann-cbor-packed@ietf.org; cbor@ietf.org Subject: Re: [Cbor] Ordering of items in the prefix table On 2020-08-28, at 20:24, Michael Richardson = wrote: >=20 >=20 > Jim Schaad wrote: >> I was just going through an expansion algorithm and I started to=20 >> wonder if we should have a requirement about order of items in the = prefix table. >> Specifically if an entry in the prefix table uses a prefix itself = (i.e. >> entry 3 in the table is 6.2872("foo")), does that entry need to occur = >> after the entry it references? >=20 > I also asked that question. > If we don't enforce that rule, then the decoder has to take care of=20 > dealing with loops. Right. > This means either having a maximum loop depth, or, using a mark to=20 > refuse to expand any specific dictionary item more than once. > I would prefer that all references are forward references. (Backward references?) This is easy with just one kind of table entry, but gets harder when = prefixes can reference shared items which can reference other prefixes = and so on. [JLS] I think my mind just crashed. For some reason I had made an = assumption that items in the shared space are never tagged, but that = does seem reasonable. Of course until earlier today I never thought = about the fact that a packed item could have an empty right value in the = case that V1 is a prefix of V2. Since I am just looking at getting the = tables started, I haven't looked hard yet at how I would encode this so = it may not end up that way. Jim Of course, the tables could be merged, but that loses exactly one bit = per reference that can be derived from the prefix vs. shared reference. One other thing to keep in mind is that not all places in the table are = equal =E2=80=94 the compressor will likely sort the entries by frequency = of use. Requiring infrequent entries to occupy all the good positions = does not lead to very compact encoding. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 28 14:46:33 2020 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 D53193A0CB8; Fri, 28 Aug 2020 14:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 W2AgImPWtk4X; Fri, 28 Aug 2020 14:46:28 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1049B3A0CB0; Fri, 28 Aug 2020 14:46:27 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 28 Aug 2020 14:46:16 -0700 From: Jim Schaad To: 'Carsten Bormann' , 'Michael Richardson' CC: , References: <008d01d67c48$d25c4440$7714ccc0$@augustcellars.com> <29638.1598639086@localhost> <014101d67d80$6f9e4ea0$4edaebe0$@augustcellars.com> In-Reply-To: <014101d67d80$6f9e4ea0$4edaebe0$@augustcellars.com> Date: Fri, 28 Aug 2020 14:46:14 -0700 Message-ID: <014601d67d84$a92e57b0$fb8b0710$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQFtMUzFC8cyVB3HBTXm03SCxCjA2QFt+GF3AuvedJUC3Z7Rrqnm6uGw X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Ordering of items in the prefix table X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 21:46:31 -0000 It dawns on me that enforcing the order might be an IoT vs the Ocean = choice. Jim -----Original Message----- From: CBOR On Behalf Of Jim Schaad Sent: Friday, August 28, 2020 2:16 PM To: 'Carsten Bormann' ; 'Michael Richardson' = Cc: cbor@ietf.org; draft-bormann-cbor-packed@ietf.org Subject: Re: [Cbor] Ordering of items in the prefix table -----Original Message----- From: Carsten Bormann Sent: Friday, August 28, 2020 11:30 AM To: Michael Richardson Cc: Jim Schaad ; = draft-bormann-cbor-packed@ietf.org; cbor@ietf.org Subject: Re: [Cbor] Ordering of items in the prefix table On 2020-08-28, at 20:24, Michael Richardson = wrote: >=20 >=20 > Jim Schaad wrote: >> I was just going through an expansion algorithm and I started to=20 >> wonder if we should have a requirement about order of items in the = prefix table. >> Specifically if an entry in the prefix table uses a prefix itself = (i.e. >> entry 3 in the table is 6.2872("foo")), does that entry need to occur = >> after the entry it references? >=20 > I also asked that question. > If we don't enforce that rule, then the decoder has to take care of=20 > dealing with loops. Right. > This means either having a maximum loop depth, or, using a mark to=20 > refuse to expand any specific dictionary item more than once. > I would prefer that all references are forward references. (Backward references?) This is easy with just one kind of table entry, but gets harder when = prefixes can reference shared items which can reference other prefixes = and so on. [JLS] I think my mind just crashed. For some reason I had made an = assumption that items in the shared space are never tagged, but that = does seem reasonable. Of course until earlier today I never thought = about the fact that a packed item could have an empty right value in the = case that V1 is a prefix of V2. Since I am just looking at getting the = tables started, I haven't looked hard yet at how I would encode this so = it may not end up that way. Jim Of course, the tables could be merged, but that loses exactly one bit = per reference that can be derived from the prefix vs. shared reference. One other thing to keep in mind is that not all places in the table are = equal =E2=80=94 the compressor will likely sort the entries by frequency = of use. Requiring infrequent entries to occupy all the good positions = does not lead to very compact encoding. Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ CBOR mailing list CBOR@ietf.org https://www.ietf.org/mailman/listinfo/cbor From nobody Fri Aug 28 14:56:21 2020 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 BE95F3A0CE1; Fri, 28 Aug 2020 14:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 35PQZOYUI8-B; Fri, 28 Aug 2020 14:56:18 -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 529863A0CDF; Fri, 28 Aug 2020 14:56:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4679F389C4; Fri, 28 Aug 2020 17:35:16 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jPp2ZessV8tM; Fri, 28 Aug 2020 17:35:15 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C8E9389B2; Fri, 28 Aug 2020 17:35:15 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A048191C; Fri, 28 Aug 2020 17:56:15 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , Jim Schaad , draft-bormann-cbor-packed@ietf.org, cbor@ietf.org In-Reply-To: <80C336B5-2A10-44BF-B214-7CFA1B159923@tzi.org> References: <008c01d67c47$aaf73be0$00e5b3a0$@augustcellars.com> <28732.1598638838@localhost> <80C336B5-2A10-44BF-B214-7CFA1B159923@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] Packed CBOR and dictionaries X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 21:56:20 -0000 --=-=-= Content-Type: text/plain Carsten Bormann wrote: > OK, I think we need to answer a few questions first. > Is there only ever one dictionary that is being referenced? > Or can you reference multiple? I've read the thread and I think that there are three places to look. Please correct me I'm wrong. 1) included in the packed CBOR. 2) included in specifically referenced dictionary (yes, by hash) 3) included in an application specific dictionary defined at the RFC-level. (what Klaus was doing with CoRAL, I think) I had previously thought that (3) was just a rather static, compiled-in version of (2), and only one or the other would be invoked. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9JfX8ACgkQgItw+93Q 3WUQYwf8C1y1nNu8+WvlnI22bWuAHESm6kYnc4FqrIO3Zcfp4mnwLZ6o0Souk3IS WsbpoSmHp/e6hhvquPFVt8RFRu+BshkHICOU6x8sAxSkZcbIELs5p8YyD9fD3iwr ADFpHVEQQuSLne54J85omJyfGsYw6PFrFmEaRgarnzYj2fqpGvvce1oJfr874HZu GF7zIUoR+5jvV0UW04eDZ29reXA/4uMmDe/O5s/VkYk85uLMm0d7l1GGiM/uMZAY Xm7IsZA826pTcoy6XKwMaeH7V7DpzOc6p0Q6uzNCWJUzW6LWk2316OueisIv/7aw irgk4RqrkFZuh4OoO1VnYdhE5kK38Q== =+B69 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 28 15:06:26 2020 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 195813A0CE6; Fri, 28 Aug 2020 15:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 3Ppx3TY1Q6aj; Fri, 28 Aug 2020 15:06:23 -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 324393A0CEE; Fri, 28 Aug 2020 15:06:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CD963389F7; Fri, 28 Aug 2020 17:45:21 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id y0CyAbOHuafj; Fri, 28 Aug 2020 17:45:18 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 09576389C0; Fri, 28 Aug 2020 17:45:18 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1E7A191C; Fri, 28 Aug 2020 18:06:18 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , Jim Schaad , draft-bormann-cbor-packed@ietf.org, cbor@ietf.org In-Reply-To: References: <008d01d67c48$d25c4440$7714ccc0$@augustcellars.com> <29638.1598639086@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] Ordering of items in the prefix table X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 22:06:25 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 2020-08-28, at 20:24, Michael Richardson w= rote: >> >> >> Jim Schaad wrote: >>> I was just going through an expansion algorithm and I started to wo= nder if >>> we should have a requirement about order of items in the prefix tab= le. >>> Specifically if an entry in the prefix table uses a prefix itself = (i.e. >>> entry 3 in the table is 6.2872("foo")), does that entry need to occ= ur after >>> the entry it references? >> >> I also asked that question. >> If we don't enforce that rule, then the decoder has to take care of = dealing >> with loops. > Right. >> This means either having a maximum loop depth, or, using a mark to r= efuse to >> expand any specific dictionary item more than once. >> I would prefer that all references are forward references. > (Backward references?) I guess it depends upon your point of view. All references need to point in the same direction :-) > This is easy with just one kind of table entry, but gets harder when > prefixes can reference shared items which can reference other prefixes > and so on. I think that things in the static dictionary(ies) can not reference things = in the shared (dynamic) dictionary. I am grumpy about the terminology now, bt= w. "shared" is a bit ambiguous now. I also think that my understanding of the prefix space is too shallow. But, it seems that we ought to be able to build a reasonable DAG. > Of course, the tables could be merged, but that loses exactly one bit > per reference that can be derived from the prefix vs. shared > reference. When you say merged, do you mean that they receive some kind of collective numbering? > One other thing to keep in mind is that not all places in the table a= re > equal =E2=80=94 the compressor will likely sort the entries by freque= ncy of > use. Requiring infrequent entries to occupy all the good positions > does not lead to very compact encoding. unidirectional references are just one way of dealing with the loop. Another is just to have a big enough bitmap to be able to mark things. A third loop detection involves two pointers, one which moves at half the rate of the other: I know this works for single-linked lists, but it might not work for a tree. I have think about this. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9Jf9kACgkQgItw+93Q 3WVSKQgAnm6MmqkYuYwvX3kWqXXtHMuhQAFlYx2iNmiao4gQnSFn1toDzXfOIdSq axMnvJ3nShinqc9xAPQssXYAtv2TGvk67ONRAGN569cVATGjYLvDeHuVgctFTGem hiBuCnfWL3AE8vslj7UmexWBvD5iOVcDzvjYacn/17hZDlHoCtMPtAf36Tn/QHga tItGzZMWuv3HyrM40pZxpXIAHggfYVP+2+HDOkkt/CrlGQ9ib5M0Put3Y/v/QG1X JjBLtaTD8B0dY1+ino2se4zpPkRTfPwxWfbj9MYl2Or29sn430l5BrkMroth9I9G sjARpvLCY7lEH8GUDDj3x/W629JkMg== =/sm0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 28 15:08:13 2020 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 59CF03A0D06; Fri, 28 Aug 2020 15:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 GKUDArzy4KCm; Fri, 28 Aug 2020 15:08:09 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8E43A0CFC; Fri, 28 Aug 2020 15:08:08 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BdYd30N5GzyXt; Sat, 29 Aug 2020 00:08:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <14972.1598651775@localhost> Date: Sat, 29 Aug 2020 00:08:06 +0200 Cc: Jim Schaad , draft-bormann-cbor-packed@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 620345286.611809-d082ee31ee6fe722c13ceb32f890e9d0 Content-Transfer-Encoding: quoted-printable Message-Id: <8624F30D-8575-41CF-A27B-237E54EB8CDC@tzi.org> References: <008c01d67c47$aaf73be0$00e5b3a0$@augustcellars.com> <28732.1598638838@localhost> <80C336B5-2A10-44BF-B214-7CFA1B159923@tzi.org> <14972.1598651775@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Packed CBOR and dictionaries X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 22:08:11 -0000 On 2020-08-28, at 23:56, Michael Richardson = wrote: >=20 >=20 > Carsten Bormann wrote: >> OK, I think we need to answer a few questions first. >=20 >> Is there only ever one dictionary that is being referenced? >> Or can you reference multiple? >=20 > I've read the thread and I think that there are three places to look. > Please correct me I'm wrong. >=20 > 1) included in the packed CBOR. Yes, but I=E2=80=99m not sure that this is a =E2=80=9Cdictionary=E2=80=9D = in the sense of being separate from the prefix and shared item tables. = Is that what you mean? > 2) included in specifically referenced dictionary (yes, by hash) A hash is not really a reference. It is an identifier that can be used = to check that you have referenced the right thing, so you can sign the = whole item. Like in RFC 6920, that identifier could be augmented with a = reference. A hash also is expensive, on the order of several dozen bytes, so see = below. > 3) included in an application specific dictionary defined at the = RFC-level. > (what Klaus was doing with CoRAL, I think) I would generalize this a bit. There may be some context that explains = where to get the dictionary for. To be able to sign such a packed item, = there would need to be an immutable relationship between a context hint = in the packed item and a dictionary (possibly identified by the hash of = that). An IANA registry can be used to maintain such a relationship. > I had previously thought that (3) was just a rather static, = compiled-in > version of (2), and only one or the other would be invoked. I think we need to enable these dictionaries to evolve, so static, = compiled-in may be true, but new versions of formats that employ packed = items should be able to make use of new static, compiled-in = dictionaries. (The dictionary defined in RFC 3485 was never updated, = but that is probably more about the deployment of SigComp.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 28 15:14:21 2020 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 5206D3A0CE6; Fri, 28 Aug 2020 15:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 xw73nYw6v7b0; Fri, 28 Aug 2020 15:14:16 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BCBC3A005E; Fri, 28 Aug 2020 15:14:16 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BdYm647PPzyY2; Sat, 29 Aug 2020 00:14:14 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_DAA8104E-7EAC-4245-A2AB-959E02F28BD1"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <17395.1598652378@localhost> Date: Sat, 29 Aug 2020 00:14:14 +0200 Cc: Jim Schaad , draft-bormann-cbor-packed@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 620345653.511453-e338e112feef434032d344f4aea1902a Content-Transfer-Encoding: quoted-printable Message-Id: <841AA64E-647F-49BF-B760-A6F5041DDC14@tzi.org> References: <008d01d67c48$d25c4440$7714ccc0$@augustcellars.com> <29638.1598639086@localhost> <17395.1598652378@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Ordering of items in the prefix table X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 22:14:20 -0000 --Apple-Mail=_DAA8104E-7EAC-4245-A2AB-959E02F28BD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2020-08-29, at 00:06, Michael Richardson = wrote: >=20 >> This is easy with just one kind of table entry, but gets harder when >> prefixes can reference shared items which can reference other = prefixes >> and so on. >=20 > I think that things in the static dictionary(ies) can not reference = things in > the shared (dynamic) dictionary. I am grumpy about the terminology = now, btw. > "shared" is a bit ambiguous now. The draft currently does not have dictionaries (which would be a term = for external dictionaries to be added to the information in the internal = tables). It has two tables: =E2=80=94 shared items =E2=80=94 prefix items The internal referencing works by giving the index of the item in the = table; these are the =E2=80=9Cnumbers=E2=80=9D I have been talking = about. The ordering of items in the number space is relevant for the = achievable compactness. Both shared items and prefix items can contain = references to shared items and prefix items. None of this is static or dynamic; adding external dictionaries might = give these terms a useful meaning (that I haven=E2=80=99t picked up = yet). Gr=C3=BC=C3=9Fe, Carsten --Apple-Mail=_DAA8104E-7EAC-4245-A2AB-959E02F28BD1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEcr05t4NZlx5Xee/8VkscnDT509sFAl9JgbUACgkQVkscnDT5 09uQcRAAoPmzBCePCi3fQ9Tw5cSH+OT4T+JP+clVbBtNGJh0rItwJLu3sffpnTeZ wRcMtVdZ8Ua0t45qPZtYv7jPqzf3oinWOaNUVMYHsnmyIplSfopE600VuDvG+WlI qh7aRjfncm9w1nWsiSAIjKQaxY4pyrkNyq3Uy7GtTPQAGTBGIjOhwVcDLLQxzXoh B0UumzGDdz/PB9KXnR7OcLexpHhvKf9jrSzLyO0No6yIOHSILvBWbUZBT3mEO+Gq hYqIXsZnvAxbN6NQWBUyvRdde1hEhUcTWoM2Vd/Ud2ioRWtF7Hwb+heggeYvsukN C0i2ZbhmpZlRsBS6816VmEogplnfkyNer3oQ+dF84CCjHVmgjIOGAbqtmOY1dYFY tA1UtekbNLyvdiyQVIkmTYN1iXfc9a2Q4EDLwhXE5+sIHYeeH+Pw0DpDX9jMfVbu vUkn4lDV5/nGmtVw6nGH4f7JNot/x3zopxSL/h9HKYxOgdESoU6olhDe6rbbdNln FIZ6jynqDpYNtaaog662pW4pG/TOk+cKX6i9xvM2bexpBkZ1UhSvnMpRNQSzJMbS p1wM5zm6+Twy9uTjMxnZYlZunPQC7aO51jNNxNU6AsnIUZ8YqfigEJWz3XDkHvTC EnMtCrE+3m6G/2s2zGIWNYyw+IaP+G7O4UzpUCbFJKNMQxysSY8= =NkpA -----END PGP SIGNATURE----- --Apple-Mail=_DAA8104E-7EAC-4245-A2AB-959E02F28BD1-- From nobody Fri Aug 28 15:33:46 2020 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 BFB283A0D4E; Fri, 28 Aug 2020 15:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 jI19zoKhurrU; Fri, 28 Aug 2020 15:33:42 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEC93A0D54; Fri, 28 Aug 2020 15:33:41 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 28 Aug 2020 15:33:36 -0700 From: Jim Schaad To: CC: Date: Fri, 28 Aug 2020 15:33:34 -0700 Message-ID: <015c01d67d8b$45aefb70$d10cf250$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdZ9ieeDz55DjiTsTXiMk4C6dS6haQ== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Combination tags and CBOR Packed X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 22:33:44 -0000 As a derivative thought from the question on loop detection and the ability to have things reference other things. Is it legal to stack up packing tags into a single item? Is 6.229(6.232(simple(1)) legal and does it do what I would expect it to do. Specifically it would concatenate three different value that are extracted from the packing tables. Jim From nobody Fri Aug 28 15:39:49 2020 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 C8B823A0D65; Fri, 28 Aug 2020 15:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 ma7-ZK66bl-r; Fri, 28 Aug 2020 15:39:45 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463BF3A0D5F; Fri, 28 Aug 2020 15:39:44 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BdZKW1Q1CzyY5; Sat, 29 Aug 2020 00:39:43 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <015c01d67d8b$45aefb70$d10cf250$@augustcellars.com> Date: Sat, 29 Aug 2020 00:39:42 +0200 Cc: draft-bormann-cbor-packed@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 620347182.685619-eaeb8b729a2ee32abcec2a6b36d4c9bb Content-Transfer-Encoding: quoted-printable Message-Id: References: <015c01d67d8b$45aefb70$d10cf250$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Combination tags and CBOR Packed X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 22:39:48 -0000 On 2020-08-29, at 00:33, Jim Schaad wrote: >=20 > Is it legal to stack up packing tags into a single item? Is > 6.229(6.232(simple(1)) legal and does it do what I would expect it to = do. > Specifically it would concatenate three different value that are = extracted > from the packing tables. Yes. (This has approximately the same complexity as an indefinite length = string with three components.) (In diagnostic notation, you don=E2=80=99t write the =E2=80=9C6.=E2=80=9D = =E2=80=94 that is for CDDL =E2=80=9C#6.=E2=80=9D.... Apologies for this discontinuity.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 28 16:04:46 2020 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 8E59C3A0D81; Fri, 28 Aug 2020 16:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 sGtIkmjBsBTj; Fri, 28 Aug 2020 16:04:44 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8333A0D5F; Fri, 28 Aug 2020 16:04:44 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 28 Aug 2020 16:04:37 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: , References: <015c01d67d8b$45aefb70$d10cf250$@augustcellars.com> In-Reply-To: Date: Fri, 28 Aug 2020 16:04:35 -0700 Message-ID: <016501d67d8f$9b2b7480$d1825d80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQFGgqOyKmrua/OttujfhS5auzsACwIYTJ/gql1XDsA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Combination tags and CBOR Packed X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 23:04:46 -0000 -----Original Message----- From: Carsten Bormann =20 Sent: Friday, August 28, 2020 3:40 PM To: Jim Schaad Cc: draft-bormann-cbor-packed@ietf.org; cbor@ietf.org Subject: Re: [Cbor] Combination tags and CBOR Packed On 2020-08-29, at 00:33, Jim Schaad wrote: >=20 > Is it legal to stack up packing tags into a single item? Is > 6.229(6.232(simple(1)) legal and does it do what I would expect it to = do. > Specifically it would concatenate three different value that are=20 > extracted from the packing tables. Yes. (This has approximately the same complexity as an indefinite length = string with three components.) [JLS] No this has much more complexity that the CBOR indefinite string. = It has the complexity of the ASN.1 indefinite string since each of the = first two elements could them selves be composite items of multiple = components. (In diagnostic notation, you don=E2=80=99t write the = =E2=80=9C6.=E2=80=9D =E2=80=94 that is for CDDL = =E2=80=9C#6.=E2=80=9D.... Apologies for this discontinuity.) [JLS] And should really know this. I guess I need to start writing CDDL = more often. Jim Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 28 17:47:26 2020 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 BFF7E3A0EA9 for ; Fri, 28 Aug 2020 17:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 3LifdVVSgXQ5 for ; Fri, 28 Aug 2020 17:47:23 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640120.outbound.protection.outlook.com [40.107.64.120]) (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 4EA5F3A0EA7 for ; Fri, 28 Aug 2020 17:47:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eJUfXAaVSPhYL5i+usPFPshTdaHCk8Q2F5DcmH31HVL2uKWpKQL3nkUh1PJmv6CXTjYyiYikGF8U9yG5IeFDIhbg+2qmmLTB1lcQJ2PpaY5A1JXJUtBCS/2FYIBNSKpG2F9WlD1qw+kHR/P+xP2Z47WdlV1djfETUTBZ5NXQmiyl9ki9GhRVvbck3uWlpWACOWuJoPYvOYfUfgsEc4TLHprNxIor2bzLkjIKwjZ2GmJW+jB7n+gXuT2/JqLJuawtIwlswOrp9cLTVYit8l2zvqgx6Ctmivtn2YNspGhvE+tytBmekZjWyVSdPT3COH9pHHGNFbGQb3PrZ9ip8G6lCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t27+NkxKAHTonl8WHGWAVTIQ2WeYYuB5sNuQSYQgyY4=; b=DrGYRm698DlYnIatZu+MndJp82UR/UFNpw6qKN4+Tt95cT5NhD1JJdO4GA3DpLXmqA+GlivD5gx0rRmGWx2JBN9WBmB5q0+/+Ou5cMoR5jB3a/sQN1pBNFfne9bxmTxJT/25JruF4M/PJ8zmWUxoX6JTqrNhFDDx1riHRyIGLQwgb/v4+J80evbaLpEBWzR1YVLpAZhTc1IeRIVRNlzAGH+n/dLTSbX6pyeHRvx6xW8sGXTGQHasGFNlyMjyQ5OGOnsAM9Dmi88s1E2GIMXtHUBlx4QACWZPsqLQmqc/u88arNjJSX5VTZgOqAfBtll3y9RyLGLe6xmFyaOECTuBKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t27+NkxKAHTonl8WHGWAVTIQ2WeYYuB5sNuQSYQgyY4=; b=VnZrMDtLpAUmRPzexmbNdvfM/ibJHVnUEBpfy1nqjhjAp/71Dcs/a9U90FNhPB/DOjt+kQdpDpcX84yKirIzSKR/xu+CzjmTFnW6JEqn3Pjbyb9zyXR7FMv9rkFnwjz5PqAawyKG1+ArrVe1ck2y9b61lGvEScp77vZCdbiXdnc= Received: from (2603:10b6:5:21c::8) by DM5PR00MB0921.namprd00.prod.outlook.com (2603:10b6:3:85::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3353.0; Sat, 29 Aug 2020 00:47:19 +0000 Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::201a:3483:38b9:fe9f]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::201a:3483:38b9:fe9f%3]) with mapi id 15.20.3375.000; Sat, 29 Aug 2020 00:47:19 +0000 From: Mike Jones To: "cbor@ietf.org" Thread-Topic: Concise Binary Object Representation (CBOR) Tags for Date progressed to IESG Evaluation Thread-Index: AdZ9mOp4cVXwrSyITIO+hDAzvQoHPg== Date: Sat, 29 Aug 2020 00:47:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=fd46330e-257f-4383-8c5a-2a9d0cb2861f; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-29T00:09:49Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.94.10] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2f66df37-2783-4d2a-fa7a-08d84bb51551 x-ms-traffictypediagnostic: DM5PR00MB0921: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kBD0N2SByDFmNla5dFaVQKY2fLDC+xANXP5NEF2ldX/1DVyh6Dc60qjiAmB3ziiBjX1OsU+ZC9MyLtiXeeXr2MDqFMc5+0JcDGlAWtOlrEHAQHMA1u5bqpFYsQfHyxpcQIrkqq4HnVAB6If0cyYx2SAydWoPQx+pJ13oeJtQ1mue5MWxSq6IQVp07AHbmsDetpv6OpOTIbMD8RgYLth2tQoBw3eXV/p45fN2OxZJcX0JWCIMEF6CjENblEVHQ9E+dEV6sTxEH/hUJuHcq+3i20eHBOyLkwqb+HMWFelaJqKsUF93uplV0mA2iQODnVReCpVgkNp/yifOT7BGNXwjbnhExL8Dg/aZ0HbejH3QuGRpEXi0iNeo8VGeHD3BQU0TXm7pYtEDRNCJALfzvzzUWvw+UfQbH6+o70z8xJyA/6eA9sVmHuEgDNZG+RtuCekd x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(366004)(136003)(39860400002)(396003)(71200400001)(10290500003)(2906002)(66556008)(33656002)(66476007)(166002)(478600001)(186003)(26005)(8676002)(8936002)(64756008)(66946007)(5660300002)(82950400001)(6916009)(76116006)(55016002)(82960400001)(316002)(7696005)(9686003)(66574015)(86362001)(52536014)(66446008)(83380400001)(6506007)(21615005)(8990500004)(4744005)(966005)(6606295002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 1vbW2r+VhVtt8fRCLcnQsL8ov01N/2qpgL3u2U+ApwIHLRu+Jk95be9PUVlWHhUH4YFHpuMDpfuzn1ridm04cpoW3b9xjLgKB5dLpy/DZRKk4Nm8lSvuAXdCPM6MRoDlH/fGvM9Nbt+XLtF0F8GUVyT/i87HV4brAMa+9IZuc8lW4FfjOzDA7e+KK4/JO7pDYuBdDm2YCFRWQ8DHlpAsyPWqznS99e7oMFkPqHzAWEbMtdjeRtttr2aqWTzHMm+8o3hZ9XQlP0TME/e0oC8YTydhanVlC0vaBccw+zQLhY/6gf4cLnQjuXq8L0PVEXXmzcg0FmSlsH5fIHZ4D3aidU6TTyeqgLKmCObLrLqD9nQdeCkY8YdyPAI/bMpnNWrQKcrBm8ZkSf4OybCpFJL6TaKx/U1uoST4ZftKFXrknVJ1ixRUyKj+i5Vm8wg0DSd7tlZsCIkgkLpFkt/ke1HzxoC3p+2bmLIC7obWwUL3EtHDMqf86Lgcv67EPjVV9TnRZaadexVi3yJ42S9BpXw+h1yJmIyoVg8JdlXzbJ9lLs+sjpRyD2BQ1te04UBav06hh0eODEFDNEzeDUGkl8Fi1hDasF6sg8nRtU6hL+3ZSypSkok/ghmwqX+ew0fWyQEK+Ss3miuUqALjXS2e83UHlA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB068411044B829EAE93E3C267F5531DM6PR00MB0684namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0684.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f66df37-2783-4d2a-fa7a-08d84bb51551 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2020 00:47:19.0657 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ODhxnuG/Ss1BTp2/Q/fteu/PxgDE9im4UPNX7FA2Dgm7RICmpOlPySsm6NBtovsUOyph9tZ6QNEyHvXJ6rAx6Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0921 Archived-At: Subject: [Cbor] Concise Binary Object Representation (CBOR) Tags for Date progressed to IESG Evaluation X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2020 00:47:25 -0000 --_000_DM6PR00MB068411044B829EAE93E3C267F5531DM6PR00MB0684namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The "Concise Binary Object Representation (CBOR) Tags for Date" specificati= on has completed IETF last call and advanced to evaluation by the Internet = Engineering Steering Group (IESG).= This is the specification that defines the full-date tag requested for us= e by the ISO Mobile Driver's License specification in the ISO/IEC JTC 1/SC = 17 "Cards and security devices fo= r personal identification" working group. The updated specification is available at: * https://tools.ietf.org/html/draft-ietf-cbor-date-tag-06 An HTML-formatted version is also available at: * https://self-issued.info/docs/draft-ietf-cbor-date-tag-06.html -- Mike P.S. This notice was also posted at https://self-issued.info/?p=3D2126 and= as @selfissued. --_000_DM6PR00MB068411044B829EAE93E3C267F5531DM6PR00MB0684namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The “Concise Binary Object Representation (= CBOR) Tags for Date” specification has completed IETF last call a= nd advanced to evaluation by the Internet Engineering St= eering Group (IESG).  This is the specification that defines the full-date tag re= quested for use by the ISO Mobile Driver’s License specification in t= he ISO/IEC JTC 1/SC 17 “Cards and security devices for personal identification” work= ing group.

 

The updated specification is available at:

--_000_DM6PR00MB068411044B829EAE93E3C267F5531DM6PR00MB0684namp_-- From nobody Sat Aug 29 19:58:03 2020 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 B4EE73A1396; Sat, 29 Aug 2020 19:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 wvolrI6QQGXG; Sat, 29 Aug 2020 19:58:00 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319FF3A1392; Sat, 29 Aug 2020 19:57:57 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 29 Aug 2020 19:57:50 -0700 From: Jim Schaad To: CC: Date: Sat, 29 Aug 2020 19:57:48 -0700 Message-ID: <01b601d67e79$594d2960$0be77c20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdZ+csWpRL6grQLsRCaGzhpYGtJ9gQ== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Review of draft-bormann-cbor-cddl-control-01 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 02:58:02 -0000 A couple of comments on this document. It is very possible that I have already made this comments and they are on your to do list. 1. Abstract needs to be expanded to identify what operators are in this document. 2. Bikeshed topic - I don't really like the name of the .feature control. The problem is that the definition of a feature is not at all clear from the name of the control. Among other things it does not say which extension points are targeted. I don't know that I have a good suggestion at this point but something long the lines of .map-extensions is a much tighter description of what is here. 3. Section 2.1 - I just ran into a potential issue with RFC 8610 that is highlighted here. On my system I would expect the result to be b = "foo\r\n bar\r\n baz\r\n". Both "\n" and "\r\n" are considered as legal inside of a byte string value and I did not find text to resolve it for the non-hex/base64 case (where it is not relevant). 4. Section 4 - Define behavior .feature is referenced outside of a map key. Or are there other places where it can be used and thus these need to be enumerated. 5. Acknowledgements - I think this does not read correctly as it says that I suggested improvements on .feature rather than the document as a whole which is what I think you meant to say. 6. Section 3 - The description says that following is legal, but does not give a clue on what the correct behavior would be: Value = text . abnf "full-date\n" The text says that it is followed by zero or more rules, I would assume that at least one rule would be required and the given target name must exist as a rulename for a rule. I think you might want to switch from element to rulename in this text as well. Element would allow for Value = text .abnf "(WSP / CRLF WSP") Jim From nobody Sat Aug 29 20:05:34 2020 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 EA0383A13C6 for ; Sat, 29 Aug 2020 20:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 TWtWOBtFy076 for ; Sat, 29 Aug 2020 20:05:30 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE3F3A0F52 for ; Sat, 29 Aug 2020 20:05:30 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 29 Aug 2020 20:05:21 -0700 From: Jim Schaad To: Date: Sat, 29 Aug 2020 20:05:19 -0700 Message-ID: <01b701d67e7a$6602fcb0$3208f610$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B8_01D67E3F.B9A4C0F0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdZ+eeo4mZXM/SbFQOu4wsLdIXvoCg== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Charter update X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 03:05:32 -0000 ------=_NextPart_000_01B8_01D67E3F.B9A4C0F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We need to get a charter update to deal with the new CDDL control document. We are looking at changing paragraph 4 as follows: CDDL has been published as RFC 8610. While this specification has been completed, several new features were raised during the update process that were not included, in order not to delay publication, and to allow publication in the Standards Track. One example of such a feature is the ability to combine multiple CDDL files together using a mechanism other than manually concatenating them together for processing. The working group will collect these features as well as other features that are raised by users of CDDL, evaluate their utility and add to a second edition of the specification where warranted., where warranted, progress them either in a standalone document or as part of a second edition of the specification. The object is to allow us to do a standalone CDDL document which is current not permitted. Please comment on the mailing list. This is expected to be part of the agenda on Wed. Jim ------=_NextPart_000_01B8_01D67E3F.B9A4C0F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We need to get a charter update to deal with the = new CDDL control document.    We are looking at changing = paragraph 4 as follows:

 

CDDL = has been published as RFC 8610. While this specification has = been

completed, several new = features were raised during the update process that

were not included, in order not to delay = publication, and to allow

publication in the Standards Track. One example of = such a feature is the

ability to = combine multiple CDDL files together using a mechanism other = than

manually concatenating them = together for processing. The working group will

collect these features as well as other features = that are raised by users of

CDDL, = evaluate their utility and add to a second edition of = the

specification where = warranted., where warranted, progress them either in = a

standalone document or as = part of a second edition of the specification.

 

The object is to allow us to do a standalone CDDL = document which is current not permitted.

 

 

Please = comment on the mailing list.  This is expected to be part of the = agenda on Wed.

 

Jim

 

------=_NextPart_000_01B8_01D67E3F.B9A4C0F0-- From nobody Sun Aug 30 15:26:21 2020 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 918A93A07C0 for ; Sun, 30 Aug 2020 15:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 NbxhaiKoRvI3 for ; Sun, 30 Aug 2020 15:26:16 -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 D1E0A3A07B3 for ; Sun, 30 Aug 2020 15:26:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 97548389AF; Sun, 30 Aug 2020 18:05:12 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sNgJsD8cjxdM; Sun, 30 Aug 2020 18:05:10 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 347B5389A6; Sun, 30 Aug 2020 18:05:10 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 14CF818B; Sun, 30 Aug 2020 18:26:12 -0400 (EDT) From: Michael Richardson To: Jim Schaad cc: cbor@ietf.org In-Reply-To: <01b701d67e7a$6602fcb0$3208f610$@augustcellars.com> References: <01b701d67e7a$6602fcb0$3208f610$@augustcellars.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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 Content-Transfer-Encoding: quoted-printable Date: Sun, 30 Aug 2020 18:26:12 -0400 Message-ID: <31675.1598826372@localhost> Archived-At: Subject: Re: [Cbor] Charter update X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 22:26:19 -0000 Jim Schaad wrote: > We need to get a charter update to deal with the new CDDL control do= cument. > We are looking at changing paragraph 4 as follows: seems fine to me. From nobody Sun Aug 30 22:31:32 2020 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 A0AF23A0EF1 for ; Sun, 30 Aug 2020 22:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 qC82yliKRKwo for ; Sun, 30 Aug 2020 22:31:28 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA4013A0EF0 for ; Sun, 30 Aug 2020 22:31:26 -0700 (PDT) Received: from [192.168.217.102] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BfzMX6G2MzyTZ; Mon, 31 Aug 2020 07:31:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <01b701d67e7a$6602fcb0$3208f610$@augustcellars.com> Date: Mon, 31 Aug 2020 07:31:20 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 620544680.339913-59a2b8ad5c4ad277091ce0188249d166 Content-Transfer-Encoding: quoted-printable Message-Id: <7DB5ABB8-EE71-4DD4-B332-765E12F5F548@tzi.org> References: <01b701d67e7a$6602fcb0$3208f610$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cbor] Charter update X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 05:31:31 -0000 On 2020-08-30, at 05:05, Jim Schaad wrote: >=20 > The object is to allow us to do a standalone CDDL document which is = current not permitted. Looks good to me. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 31 14:07:39 2020 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 1FE393A1960; Mon, 31 Aug 2020 14:07:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Samita Chakrabarti via Datatracker To: Cc: cbor@ietf.org, draft-ietf-cbor-date-tag.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159890805808.11581.2811166792074832134@ietfa.amsl.com> Reply-To: Samita Chakrabarti Date: Mon, 31 Aug 2020 14:07:38 -0700 Archived-At: Subject: [Cbor] Iotdir telechat review of draft-ietf-cbor-date-tag-06 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 21:07:38 -0000 Reviewer: Samita Chakrabarti Review result: Ready I have reviewed this document from IOT-DIR perspective. No issues.