From nobody Wed Dec 4 15:21:56 2019 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 DCB4512003F for ; Wed, 4 Dec 2019 15:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKYpZ4rvDuge for ; Wed, 4 Dec 2019 15:21:53 -0800 (PST) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E9D12002F for ; Wed, 4 Dec 2019 15:21:52 -0800 (PST) Received: by mail-oi1-x22f.google.com with SMTP id 6so940624oix.7 for ; Wed, 04 Dec 2019 15:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=pQ03mW1WtA2wHyBkzrLmc28//ye+rHilVtCwzxMoM3Y=; b=NUIupglNWXVIcf6xBrF0M5Fj03SgJnQ0p0CDbV5bTZEsePTC/PQNaoseciCAWk1C8V FNE8M8CgCAths3RhRNX8pegfZ+vPr/Ozk3k2YOEFTmFBJiS1P6Wkkn3HZecg87s0TZK2 fGPqlj+jCY1eyGJSZ2MHjSboYENq7OHJHJbKU6RUqtfUBrSVX0nf6zaK5/LyKCMnFzL+ i4P9kHIm1L6TAcBW9pHgl7Rc2Lk8Px08XHG039gsaWwnOBZk/8N7xq6oiXOsOM8NHffY dG1C4UYp0NVbywDmepck/C0gT2m5uHHDhZBeh/aKlt61JWQba8CqKe4lIGjYe8jQL+Tl e/Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pQ03mW1WtA2wHyBkzrLmc28//ye+rHilVtCwzxMoM3Y=; b=BQe+zaJBtXOSQqln4i8L4FNj+hcG2Itg0RV4xTU3qDYTBD7FTDwSxGIOGcqFHUkWVQ hr1LbIiOhGlTJMWEHoUAqoUdabQ/WvKnPvejehaFDk7bNRvF9h2M8QAlSplE+lWnXoWB JkCcISeL76qtFUEDEfhjjKxsOisG2TgD4IIeN9xHSY9d186bj9GVm+7hps66QGkzP0QM 5YLw5Iz4HXpIft85Du9S+7e5TW2N2K5bS/16EP/85wkeXf4CoP1/YQaU2lwO4r//lrFO 13vhvVsCLvO7fqwZ0XHFq59hTLFZBpnuBRBzybXdl7qcfmE5+LYtf4Y1vTQ7pa23xJpo XsTQ== X-Gm-Message-State: APjAAAUEy1CxgXW521ozPEuAJL9GKsvPLieSKbVwcjLqYARd0OX8zUnp OL9tHJAnIIrYV4f7Vup8QfWstAFVBanZhlRHtzhoIubd X-Google-Smtp-Source: APXvYqzOwl5H7yeApo3fzpNh2xG+yxci8PZTP4gDVy3vCe69q6vbRZYnL7SJPGOQb2Stl4u0rTXeErBBkkP1SlkJUVc= X-Received: by 2002:aca:36c5:: with SMTP id d188mr5048993oia.54.1575501712077; Wed, 04 Dec 2019 15:21:52 -0800 (PST) MIME-Version: 1.0 From: David Kemp Date: Wed, 4 Dec 2019 18:19:15 -0500 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="000000000000e437940598e913b0" Archived-At: Subject: Re: [Cbor] Handling duplicate map keys 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, 04 Dec 2019 23:21:55 -0000 --000000000000e437940598e913b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Laurence Lundblade wrote: >> Michael Richardson wrote: >> I am less afraid to declare an answer and make some decoders non-compliant. >> I think that they will get fixed. > > I would hope fix them means that they will error out when a duplicate is detected. > > It probably doesn=E2=80=99t cost any more than take first and is the more= clear, clean and > secure thing to do IMO. > > Seems like it will be easier to get agreement on that behavior than take first. > Also, there will always be some implementations that error out. We can=E2= =80=99t get them all > to do take first. > > LL +1. Section 3.7: "The resulting rule in the protocol should respect the CBOR data model: it cannot prescribe a specific handling of the entries with the identical keys, except ... error." This "should" is, logically speaking, a must, because the alternative is to declare that CBOR implementations that do not respect the CBOR data model (by silently accepting invalid input) are conforming. --000000000000e437940598e913b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Laurence Lundblade <lgl@island-resort.com> wrote:
>&g= t;=C2=A0 Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>> I am less afraid = to declare an answer and make some decoders non-compliant.
>> I th= ink that they will get fixed.=C2=A0
>
> I would hope fix them means that they will error out when a duplicate is de= tected.
>
> It probably doesn=E2=80=99t cost any more than take= first and is the more clear, clean and
> secure thing to do IMO.>
> Seems like it will be easier to get agreement on that behavio= r than take first.
> Also, there will always be some implement= ations that error out. We can=E2=80=99t get them all
> to do t= ake first.
>
> LL

+1.

Section 3.7: "The resu= lting rule in the protocol should respect the CBOR data model:
it= cannot prescribe a specific handling of the entries=C2=A0with the identica= l keys, except ... error."

This "should" is, logicall= y speaking, a must, because the alternative is to declare that CBOR
implementations that do not respect the CBOR data model (by silently acc= epting invalid input)
are conforming.=C2=A0=C2=A0
--000000000000e437940598e913b0-- From faye.github@gmail.com Wed Dec 4 18:40:21 2019 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 5F0FA120043 for ; Wed, 4 Dec 2019 18:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 booPelGZsfFN for ; Wed, 4 Dec 2019 18:40:18 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 578A312018B for ; Wed, 4 Dec 2019 18:40:18 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id m188so2056475qkc.4 for ; Wed, 04 Dec 2019 18:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=O2xP58CNaioKCs2tOqX1PVhiMVmKaaSTQMfjkWB7iIw=; b=o3grKHopoKZmYWyHO5RbUXO5g+kRyhgnZLoaWsj9SoEhtr6pjsowXbuPFg+pfs1pdH ls9061vIQrYkDFw3IrnF0TILunX0eHM7/qa+2Vrl4ro2qpI6xva3/R+yHWyuV1Oyff8u H7zKpSRUMzc4ytko/9DLpf8YoX+ARSE5j/XQxE3jmfQptW/ixPoR9wH4bnSCGX1unPzx 8ERTzhIoJEbTiC7YSDn7RAuNXUxxVzenvtqH1QUtLU/VTy0lsEQ6V6k5CXl0vUy0eyHd xM6xioqQ6fm42Kmcuw60xvP/YlTaaXlF7r8101mUiUhwU6Mjz7CBahvs+bH1fHXd1Qeh 9+RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=O2xP58CNaioKCs2tOqX1PVhiMVmKaaSTQMfjkWB7iIw=; b=pYb1VKFpuhEQnE/G1YoWQ2oMSX+1tVpOWSLfv5cJNfG91aW5HhdEgPt0bSgUXDe4WL cqixewNtF2rwugrYHJjd3QOyQ/zCEolG/RBLt2RifkTxmTcusY3U2vUCZBSZORHX3ccd IGoHbvh1k+NVweCSvKpxMbi7GmPjt3mqkNnYcCu5jVuvIrxvGbSnDIUAoCc/R9oDJ4Qg LWSG+d1EZzbPSiA5PsEUNJCS67TaF2MxCcucIRWG2YkMbwnlmQh7r4qT0ul7JFG1AJ9c ArMWYhBe3KbVvOBlZ/TE+8sJDHGmkQxH+7lV19Bj/mXOoTpu9izCZS5C6dHJ77uaLpT9 wj6A== X-Gm-Message-State: APjAAAWZtku0TSautrepv0vYxLbMC3yROVKgFLr8ei8H72zhW/WdSuB1 05xYv2L6Kj37WzrL8hc6tgqt9Z+1jY3XkmxAxPVeu0UB X-Google-Smtp-Source: APXvYqzFdDbzLa9NgpF8bSsyUhbnDYKzLRVqJeKvj2BiisPnDQs8eshbiNXwMtDcQzqVAfnTCbM1whHJaDyHD8+TTpc= X-Received: by 2002:a05:620a:1358:: with SMTP id c24mr6392447qkl.285.1575513617264; Wed, 04 Dec 2019 18:40:17 -0800 (PST) MIME-Version: 1.0 From: Faye Amacker Date: Wed, 4 Dec 2019 20:40:05 -0600 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="0000000000007ef5330598ebd9cc" Archived-At: Subject: [Cbor] Malformed tag example for RFC 7049bis Appendix G.1. 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, 05 Dec 2019 04:34:15 -0000 --0000000000007ef5330598ebd9cc Content-Type: text/plain; charset="UTF-8" Tag numbers must be followed by tag content. I think an example of this could make it more obvious to CBOR library authors. Please add an example of malformed tag to RFC 7049bis Appendix G.1: * Definite length maps ... + * Tag number not followed by tag content: C0 * Indefinite length strings ... My pull request for this one-line addition is at: https://github.com/cbor-wg/CBORbis/pull/146 BTW, I finished reading 7049bis and really appreciate the improvements. I added many new unit tests to my CBOR library based on Appendix G. And I'm also finding 7049bis more helpful while implementing support for tags. --0000000000007ef5330598ebd9cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tag numbers must be followed by tag content.=C2=A0 I = think an example of this could make it more obvious to CBOR library authors= .

Please add an example of malformed tag to RF= C 7049bis Appendix G.1:

=C2=A0=C2=A0 * Definite length = maps ...
+ * Tag number not followed by tag content: C0
=C2=A0=C2=A0 = * Indefinite length strings ...

My pull request for = this one-line addition is at:
https://github.com/cbor-wg/CBORbis/pull/146

BTW, I finished reading 7049bis and real= ly appreciate the improvements. I added many new unit tests to my CBOR libr= ary based on Appendix G.=C2=A0 And I'm also finding 7049bis more helpfu= l while implementing support for tags.
--0000000000007ef5330598ebd9cc-- From nobody Thu Dec 5 07:27:34 2019 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 9C951120013 for ; Thu, 5 Dec 2019 07:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 QklY5NIJsTjI for ; Thu, 5 Dec 2019 07:27:30 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 F145712002E for ; Thu, 5 Dec 2019 07:27:29 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id i18so3610038qkl.11 for ; Thu, 05 Dec 2019 07:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hVKlL6ywfAJ7cbpg3UtoJLpW6+J5IPztP5xN5L7xNMo=; b=axTKOgMbIDkxNuEbIIUT9nR9dbBk7BC59mSt1MLBZwLC9Img3X3kVRVsmpXWpzmzrI ytmWeEgqV6WXMCFJg4BBa8FG6lhMjcMXia2tg5OwRGodOnSnKX+dMBnyLW6V9fecRoju M8fUKPm1GNgd6/ajPlBtQlQXz2xHhvQnRsAHKDvhEp7ZRDxLNW9a61GoaSzBC+MW73Ol YNg1z/XFXqgrbRnLMzAmpDBLF6idRm1fPTF8EKYRv1zRBI2GEJAPmG0jMhxuqFjMj1nR YEM4Ts0vZyvuHMJxiYN8+eXQioAYihuefpoBZ6ZWe09tC1nlv9shFnq4dyXZ+IvN6qMO ceHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hVKlL6ywfAJ7cbpg3UtoJLpW6+J5IPztP5xN5L7xNMo=; b=c7PO1DMLywRALEpi3wB1gNfz/hYjyi727XlEEFRClzFEENB3+UL2kY/Uy2eXYxxzuQ fMDyjX+uAAt0tyJqt2US40rzGWhcH+N/naNtIuOLZ8tvA3a5Iom+S7bP9JGG7omDosdV VerXgWXClLpNAg743KNICSNukW2+wdV/DR2JKCeBeaExe+h871j6Fmepmb2M+0akuYgz Vgt+M9AOWmLE6PG9JgSW423Zid1P9cfJO4DTobIU+S38CcC22LgW0mdnJp12Xpb69Aov ydbCI9P3WuXmzcDeOSg0IBgYqvEbA9Xe/5l5JHDp+rMbxKb16oWq9yg1aJBPT0asD589 nOkg== X-Gm-Message-State: APjAAAXvFhqI2pTO1raUxpI4KTYyoAcD5uXnRU7mBGtzPyt6E84GJxF4 5yqLZK6//pvcGa3EN1eUgkIOHeSKa+36x2O16I5VCtv/ X-Google-Smtp-Source: APXvYqwFHie+4VVW++Tl0A5HsIRBV9MhC3182pCkeoV1mF5qVI6powgNUoulRw8HcSkpnPziawPU+HCnUz5AlLdB8zA= X-Received: by 2002:a37:9b97:: with SMTP id d145mr8966499qke.108.1575559648907; Thu, 05 Dec 2019 07:27:28 -0800 (PST) MIME-Version: 1.0 From: Faye Amacker Date: Thu, 5 Dec 2019 09:27:17 -0600 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="0000000000003216c40598f69149" Archived-At: Subject: [Cbor] Chunks with tags inside indefinite-length string (major type 2 and 3) 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, 05 Dec 2019 15:27:33 -0000 --0000000000003216c40598f69149 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While implementing support for tags, I ran into a scenario that might be errata or could use some clarification in 7049bis. Section 3.2.3 states: > Indefinite-length strings are represented by a byte containing the major type and additional information value of 31, followed by a series of zero or more byte or text strings (=E2=80=9Cchunks=E2=80=9D) that have definite = lengths, followed by the =E2=80=9Cbreak=E2=80=9D stop code (Section 3.2.1). The data= item represented by the indefinite-length string is the concatenation of the chunks (i.e., the empty byte or text string, respectively, if no chunk is present). And the pseudocode in Appendix C allows tags for chunks inside indefinite-length strings. Chunks are simply fragments to be concatenated, so tags applied to chunks doesn't seem intuitive. Chunks are not intended for independent access like array elements. Some tags (like #2 and #3) transform byte string into bignum which makes sense for arrays, not chunks. If tags must be applied to each chunk, there should be some text mentioning that because library authors might think it should be rejected or applied to the concatenated string rather than chunk. However, if the tag for a chunk applies to the entire concatenated string, then what happens when there are multiple chunks with different tags? Which tag wins? A simpler way forward is to treat tags on chunks as malformed. If this is the way to go, then the pseudocode in Appendix C needs to be updated and an example could be added to Appendix G. GitHub issue for RFC 7049bis: https://github.com/cbor-wg/CBORbis/issues/148 GitHub issue for my CBOR library: https://github.com/fxamacker/cbor/issues/44 --0000000000003216c40598f69149 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While implementing support for tags, I ran into a scenario= that might be errata or could use some clarification in 7049bis.

Se= ction 3.2.3 states:

> Indefinite-length strings are represented b= y a byte containing the major type and additional information value of 31, = followed by a series of zero or more byte or text strings (=E2=80=9Cchunks= =E2=80=9D) that have definite lengths, followed by the =E2=80=9Cbreak=E2=80= =9D stop code (Section 3.2.1). The data item represented by the indefinite-= length string is the concatenation of the chunks (i.e., the empty byte or t= ext string, respectively, if no chunk is present).

And the pseudocod= e in Appendix C allows tags for chunks inside indefinite-length strings.
Chunks are simply fragments to be concatenated, so tags applied to chu= nks doesn't seem intuitive.=C2=A0 Chunks are not intended for independe= nt access like array elements.=C2=A0 Some tags (like #2 and #3) transform b= yte string into bignum which makes sense for arrays, not chunks.
If tags must be applied to each chunk, there should be some te= xt mentioning that because library authors might think it should be rejecte= d or applied to the concatenated string rather than chunk.
However, if the tag for a chunk applies to the entire concatenated = string, then what happens when there are multiple chunks with different tag= s? Which tag wins?

A simpler way forward is to treat tags on ch= unks as malformed.=C2=A0 If this is the way to go, then the pseudocode in A= ppendix C needs to be updated and an example could be added to Appendix G.<= /div>

GitHub issue for my CBOR library: https://github.com/fxamacker/cbor/iss= ues/44
--0000000000003216c40598f69149-- From nobody Thu Dec 5 11:18:35 2019 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 132D2120090 for ; Thu, 5 Dec 2019 11:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 WCaDg5Bi-5Eu for ; Thu, 5 Dec 2019 11:18:30 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 87C7E12006B for ; Thu, 5 Dec 2019 11:18:30 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id d202so4354738qkb.1 for ; Thu, 05 Dec 2019 11:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1RoRorZZcjb+NbXjiQk+pyRUxs4o3h3lxUrZf+ooTo8=; b=cC5rF/qLkPUzRMT/ldTOfP/MscJSPgTWH5kK9d7b98LdTYqhNLD5MuFN4DU8uIgQXJ 2W8digUbQ5y1/q4c6J0kqkSMmDIFqZ24VajiqxgjcqGb97Aj//xCwyV+AXWIfC8gozUq 1ZGjgs0cI1FHuG/k9A+AuvCSAR8zEebP9y5ZA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1RoRorZZcjb+NbXjiQk+pyRUxs4o3h3lxUrZf+ooTo8=; b=YXVhTbNxSf4KIHt1g2wzzY7rOhLukwTKHACD9jqoxeMY1S+MBoOlHhCpz9cI2TNiKV bPACY4PPyKvpnbvLhN3KNDMV0UFBZGQ0SEj0QYmHRU5hT9+JrJJrvb3HHItSOlvUhfHM 01ncNZBEgPI2T2G7FcsGG1/0DNL97qFs1NLA716YaeA+gloKmEhljpO8qOVYr6GPWoxj HL6zQ0qrO+R7YtYNTvGQZHQVnEwO1LNzG+tcrnuxXGjI9R8n8DPomf1P0CW/b965VefF npKcGQBMGhqhmhegmrHj660UQT2h/O+5fGdNNJjvOi5PliLJdYPby2I9uMhbwKQUJ8QX KR2Q== X-Gm-Message-State: APjAAAWM24EMvGujf8j3RlS+05hHIyQLIkcr7BDtUYO25/JDC78Kgaam aWZLu+vwLwgebali3wZ9IXYZqTtuVzVa6RUNuVup9Q== X-Google-Smtp-Source: APXvYqy/PYYyC8DdDto73RpXdC4SPgpA4j2RYebww2M3GSIc8krpAJn90ItQYg+5rNgqp/KLQz9aawN0xjOkOtMTWic= X-Received: by 2002:ae9:c318:: with SMTP id n24mr10368032qkg.38.1575573508938; Thu, 05 Dec 2019 11:18:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Thu, 5 Dec 2019 11:18:17 -0800 Message-ID: To: Faye Amacker Cc: cbor@ietf.org Content-Type: multipart/alternative; boundary="00000000000051da2b0598f9cbc0" Archived-At: Subject: Re: [Cbor] Chunks with tags inside indefinite-length string (major type 2 and 3) 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, 05 Dec 2019 19:18:32 -0000 --00000000000051da2b0598f9cbc0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I *think* https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#indefinite-l= ength-byte-strings-and-text-strings is pretty clear that the contained things have to have the same major type as the indefinite-length string, and tags have a different major type. e.g. "a series of zero or more byte or text strings" doesn't include the possibility of tags, and "If any item between the indefinite-length string indicator (0b010_11111 or 0b011_11111) and the =E2=80=9Cbreak=E2=80=9D stop= code is not a definite-length string item of the same major type, the string is not well-formed." says any other content is not well-formed. The pseudocode includes if (it !=3D mt) // need finite-length chunk fail(); // of same type which I think also rejects tags inside indefinite strings. What am I missing? Jeffrey On Thu, Dec 5, 2019 at 7:27 AM Faye Amacker wrote: > While implementing support for tags, I ran into a scenario that might be > errata or could use some clarification in 7049bis. > > Section 3.2.3 states: > > > Indefinite-length strings are represented by a byte containing the majo= r > type and additional information value of 31, followed by a series of zero > or more byte or text strings (=E2=80=9Cchunks=E2=80=9D) that have definit= e lengths, > followed by the =E2=80=9Cbreak=E2=80=9D stop code (Section 3.2.1). The da= ta item > represented by the indefinite-length string is the concatenation of the > chunks (i.e., the empty byte or text string, respectively, if no chunk is > present). > > And the pseudocode in Appendix C allows tags for chunks inside > indefinite-length strings. > > Chunks are simply fragments to be concatenated, so tags applied to chunks > doesn't seem intuitive. Chunks are not intended for independent access > like array elements. Some tags (like #2 and #3) transform byte string in= to > bignum which makes sense for arrays, not chunks. > > If tags must be applied to each chunk, there should be some text > mentioning that because library authors might think it should be rejected > or applied to the concatenated string rather than chunk. > > However, if the tag for a chunk applies to the entire concatenated string= , > then what happens when there are multiple chunks with different tags? Whi= ch > tag wins? > > A simpler way forward is to treat tags on chunks as malformed. If this i= s > the way to go, then the pseudocode in Appendix C needs to be updated and = an > example could be added to Appendix G. > > GitHub issue for RFC 7049bis: > https://github.com/cbor-wg/CBORbis/issues/148 > GitHub issue for my CBOR library: > https://github.com/fxamacker/cbor/issues/44 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > --00000000000051da2b0598f9cbc0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I *think*=C2=A0https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#indefin= ite-length-byte-strings-and-text-strings=C2=A0is pretty clear that the = contained things have to have the same major type as the indefinite-length = string, and tags have a different major type. e.g. "a series of zero o= r more byte or text strings" doesn't include the possibility of ta= gs, and "If any item between the indefinite-length string indicator (0= b010_11111 or 0b011_11111) and the =E2=80=9Cbreak=E2=80=9D stop code is not= a definite-length string item of the same major type, the string is not we= ll-formed." says any other content is not well-formed.

<= div>The pseudocode includes

if (it !=3D mt) =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 // need finite-length chunk
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 fail(); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 // =C2=A0 =C2=A0of same type

which I think= also rejects tags inside indefinite strings. What am I missing?
=
Jeffrey

On Thu, Dec 5, 2019 at 7:27 AM Faye Amacker &= lt;faye.github@gmail.com> w= rote:
While implementing support for tags, I ran into a scenario that mi= ght be errata or could use some clarification in 7049bis.

Section 3.= 2.3 states:

> Indefinite-length strings are represented by a byte= containing the major type and additional information value of 31, followed= by a series of zero or more byte or text strings (=E2=80=9Cchunks=E2=80=9D= ) that have definite lengths, followed by the =E2=80=9Cbreak=E2=80=9D stop = code (Section 3.2.1). The data item represented by the indefinite-length st= ring is the concatenation of the chunks (i.e., the empty byte or text strin= g, respectively, if no chunk is present).

And the pseudocode in Appe= ndix C allows tags for chunks inside indefinite-length strings.

Chun= ks are simply fragments to be concatenated, so tags applied to chunks doesn= 't seem intuitive.=C2=A0 Chunks are not intended for independent access= like array elements.=C2=A0 Some tags (like #2 and #3) transform byte strin= g into bignum which makes sense for arrays, not chunks.

<= div>If tags must be applied to each chunk, there should be some text mentio= ning that because library authors might think it should be rejected or appl= ied to the concatenated string rather than chunk.

H= owever, if the tag for a chunk applies to the entire concatenated string, t= hen what happens when there are multiple chunks with different tags? Which = tag wins?

A simpler way forward is to treat tags on chunks as m= alformed.=C2=A0 If this is the way to go, then the pseudocode in Appendix C= needs to be updated and an example could be added to Appendix G.

GitHub issue for my CBOR library: https://= github.com/fxamacker/cbor/issues/44
_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
--00000000000051da2b0598f9cbc0-- From nobody Thu Dec 5 13:57:04 2019 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 636471200EF for ; Thu, 5 Dec 2019 13:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 3HB87THvR3tZ for ; Thu, 5 Dec 2019 13:57:01 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 58B4A120073 for ; Thu, 5 Dec 2019 13:57:01 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id 14so5070452qtf.5 for ; Thu, 05 Dec 2019 13:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q7pLZygOy3QmL569/KN8Swdw7li+S6cDOCFjiW30Gc4=; b=O6Yke5XTAQLPhAA1eLt5clmNuSIOapzpeKHWzJ7XxNjqOhRzg/6PXwQ0/dUqJ/9b1b Ulld4TdhyiQoEa7BJ7c5qy9WGxB7exHgxj1g6gGbBn/IPAvgHdBgqdVDKOBHxOeRxjlO 1cmFWkJwUxgsz/dWah6aSswOLtpSm5y+Irelw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q7pLZygOy3QmL569/KN8Swdw7li+S6cDOCFjiW30Gc4=; b=TS8+NKP6zypP0FbJmOG2+OloNX3+i3xXW8xqs0Bb8FPd090vbkK8VpJALTS47QHNeF 6CjvUcTJSRyfuHsYabFRg9mljhnoYdABA8REHBJT+h8aPJA0FiKwZ4nijxvp06nlETce sLySiueEARYzC/9nKiLp4tJSZeOm8dp2mBpx4jHe+2MjeL8ur3VVg6t1WvVs3dBdvLTf 0LnzNoXvHrlZ8KA7myhRn7WiHIaPMD7XPQmXhzr83K8ckeoVe25D1g+lHUE4yVK36BNW dPMJ6UK1EJXUZEBqZH8/rhJcJsg3AV2blaaJyYi1dia1no/w3LuXtHhbAWhIEkDxLmSE auQg== X-Gm-Message-State: APjAAAU7AbeAX1LEvCFT2E2+BUWKotViTyJE7xr1OX/EuCjWEErQob7R VyH4txIdzQpcf5psVD0t7W37LYkOIPsOYoIFhe2e8Q== X-Google-Smtp-Source: APXvYqyNrXOISjryuaei3gc/zpWuRAC3E/6ueFGjiAPrgojS3s6YGVFuPx74i56sPWVUky66j6LpvfjYpmtX05d7xRQ= X-Received: by 2002:ac8:488f:: with SMTP id i15mr8529130qtq.382.1575583019637; Thu, 05 Dec 2019 13:56:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Thu, 5 Dec 2019 13:56:47 -0800 Message-ID: To: Faye Amacker , cbor@ietf.org Cc: Jeffrey Yasskin Content-Type: multipart/alternative; boundary="000000000000339eb90598fc0228" Archived-At: Subject: Re: [Cbor] Chunks with tags inside indefinite-length string (major type 2 and 3) 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, 05 Dec 2019 21:57:03 -0000 --000000000000339eb90598fc0228 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe that's correct, with the caveat that protocols should be able to specify that they accept a "number", which would accept primitive integers, primitive floats, and tagged bigints, bigfloats, bigdecimals, and any new tags defined to represent numbers. https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#epochdatetim= esect has some wording to restrict to just primitive integers. Jeffrey On Thu, Dec 5, 2019 at 1:47 PM Faye Amacker wrote: > Jeffrey, I think you are correct. It seems I misread a line in the > pseudocode which made me doubt my interpretation of the text. > > Can you confirm that decoders (both generic and non-generic) should: > * reject a tagged positive number if a protocol specifies a positive > number. > * reject a positive number if a protocol specifies a tagged positive > number. > * accept both positive number and tagged positive number only if the > protocol specifies the specific tag is optional. > > Thanks again for your help. I'm relieved tags on chunks are malformed. > > On Thu, Dec 5, 2019 at 1:18 PM Jeffrey Yasskin > wrote: > >> I *think* >> https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#indefinit= e-length-byte-strings-and-text-strings is >> pretty clear that the contained things have to have the same major type = as >> the indefinite-length string, and tags have a different major type. e.g.= "a >> series of zero or more byte or text strings" doesn't include the >> possibility of tags, and "If any item between the indefinite-length stri= ng >> indicator (0b010_11111 or 0b011_11111) and the =E2=80=9Cbreak=E2=80=9D s= top code is not a >> definite-length string item of the same major type, the string is not >> well-formed." says any other content is not well-formed. >> >> The pseudocode includes >> >> if (it !=3D mt) // need finite-length chunk >> fail(); // of same type >> >> which I think also rejects tags inside indefinite strings. What am I >> missing? >> >> Jeffrey >> >> On Thu, Dec 5, 2019 at 7:27 AM Faye Amacker >> wrote: >> >>> While implementing support for tags, I ran into a scenario that might b= e >>> errata or could use some clarification in 7049bis. >>> >>> Section 3.2.3 states: >>> >>> > Indefinite-length strings are represented by a byte containing the >>> major type and additional information value of 31, followed by a series= of >>> zero or more byte or text strings (=E2=80=9Cchunks=E2=80=9D) that have = definite lengths, >>> followed by the =E2=80=9Cbreak=E2=80=9D stop code (Section 3.2.1). The = data item >>> represented by the indefinite-length string is the concatenation of the >>> chunks (i.e., the empty byte or text string, respectively, if no chunk = is >>> present). >>> >>> And the pseudocode in Appendix C allows tags for chunks inside >>> indefinite-length strings. >>> >>> Chunks are simply fragments to be concatenated, so tags applied to >>> chunks doesn't seem intuitive. Chunks are not intended for independent >>> access like array elements. Some tags (like #2 and #3) transform byte >>> string into bignum which makes sense for arrays, not chunks. >>> >>> If tags must be applied to each chunk, there should be some text >>> mentioning that because library authors might think it should be reject= ed >>> or applied to the concatenated string rather than chunk. >>> >>> However, if the tag for a chunk applies to the entire concatenated >>> string, then what happens when there are multiple chunks with different >>> tags? Which tag wins? >>> >>> A simpler way forward is to treat tags on chunks as malformed. If this >>> is the way to go, then the pseudocode in Appendix C needs to be updated= and >>> an example could be added to Appendix G. >>> >>> GitHub issue for RFC 7049bis: >>> https://github.com/cbor-wg/CBORbis/issues/148 >>> GitHub issue for my CBOR library: >>> https://github.com/fxamacker/cbor/issues/44 >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>> >> --000000000000339eb90598fc0228 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe that's correct, with the caveat that protoco= ls should be able to specify that they accept a "number", which w= ould accept primitive integers, primitive floats, and tagged bigints, bigfl= oats, bigdecimals, and any new tags defined to represent numbers.=C2=A0https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.htm= l#epochdatetimesect=C2=A0has some wording to restrict to just primitive= integers.

Jeffrey

On Thu, Dec 5, 2019 at 1:47 PM F= aye Amacker <faye.github@gmail.= com> wrote:
Jeffrey, I think you are correct.= =C2=A0 It seems I misread a line in the pseudocode which made me doubt my i= nterpretation of the text.

Can you confirm that de= coders (both generic and non-generic) should:
* reject a tagg= ed positive number if a protocol specifies a positive number.
* reject a positive number if a protocol specifies a tagged positive numbe= r.
* accept both positive number and tagged positive number o= nly if the protocol specifies the specific tag is optional.

<= /div>
Thanks again for your help.=C2=A0 I'm relieved tag= s on chunks are malformed.

On Thu, Dec 5, 2019 at 1:18 = PM Jeffrey Yasskin <jyasskin@chromium.org> wrote:
I *think*=C2=A0https://cbor-wg.github.i= o/CBORbis/draft-ietf-cbor-7049bis.html#indefinite-length-byte-strings-and-t= ext-strings=C2=A0is pretty clear that the contained things have to have= the same major type as the indefinite-length string, and tags have a diffe= rent major type. e.g. "a series of zero or more byte or text strings&q= uot; doesn't include the possibility of tags, and "If any item bet= ween the indefinite-length string indicator (0b010_11111 or 0b011_11111) an= d the =E2=80=9Cbreak=E2=80=9D stop code is not a definite-length string ite= m of the same major type, the string is not well-formed." says any oth= er content is not well-formed.

The pseudocode includes

if (it !=3D mt) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = // need finite-length chunk
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fail(); = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // =C2=A0 =C2=A0of same ty= pe

which I think also rejects tags inside inde= finite strings. What am I missing?

Jeffrey

On= Thu, Dec 5, 2019 at 7:27 AM Faye Amacker <faye.github@gmail.com> wrote:
While i= mplementing support for tags, I ran into a scenario that might be errata or= could use some clarification in 7049bis.

Section 3.2.3 states:
<= br>> Indefinite-length strings are represented by a byte containing the = major type and additional information value of 31, followed by a series of = zero or more byte or text strings (=E2=80=9Cchunks=E2=80=9D) that have defi= nite lengths, followed by the =E2=80=9Cbreak=E2=80=9D stop code (Section 3.= 2.1). The data item represented by the indefinite-length string is the conc= atenation of the chunks (i.e., the empty byte or text string, respectively,= if no chunk is present).

And the pseudocode in Appendix C allows ta= gs for chunks inside indefinite-length strings.

Chunks are simply fr= agments to be concatenated, so tags applied to chunks doesn't seem intu= itive.=C2=A0 Chunks are not intended for independent access like array elem= ents.=C2=A0 Some tags (like #2 and #3) transform byte string into bignum wh= ich makes sense for arrays, not chunks.

If tags must= be applied to each chunk, there should be some text mentioning that becaus= e library authors might think it should be rejected or applied to the conca= tenated string rather than chunk.

However, if the t= ag for a chunk applies to the entire concatenated string, then what happens= when there are multiple chunks with different tags? Which tag wins?
A simpler way forward is to treat tags on chunks as malformed.=C2=A0 = If this is the way to go, then the pseudocode in Appendix C needs to be upd= ated and an example could be added to Appendix G.

= GitHub issue for RFC 7049bis: https://github.com/cbor-wg/CBORbis/issues/14= 8
GitHub issue for my CBOR library: https://github.com/fxamack= er/cbor/issues/44
_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
--000000000000339eb90598fc0228-- From nobody Thu Dec 5 20:03:05 2019 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 2BD81120077 for ; Thu, 5 Dec 2019 20:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, 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 KjGkGQLRpRMJ for ; Thu, 5 Dec 2019 20:03:01 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 9DFAA12000F for ; Thu, 5 Dec 2019 20:03:01 -0800 (PST) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id d404iIVWRnEC3d4pYiEMJ1; Fri, 06 Dec 2019 04:03:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1575604980; bh=Dvq3f7LIYgY1aYNPCssYLqv9CwaMuqVgsaRhcQpKUMY=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=W207yW/m1dLZhfBRZnFRhO3xe3vMySeqP0xr6rit+s0kTSJhkZx2UK/U5mqNwSpv6 tUtstM4HKfuzxtyZmTjmNNmNuwsg4eptOnRGxZ4PnitLM+PuIXFB4YGZxiBnR2GonC Z9gY0p40/jhbVvrMea0RE3jJ3T1W+/hzsGvhDlE7zrs7F4O/TEcUe3rliEK2+3gcW0 ULzms32lLqmVTDNRluzuwuJsvJ0o0hW4v2zCqd288tfgOayuIOgpb7KoIKZD8bWT9Y oUZmJqR3xYMn9knJOlfDFaPAap9fGIFersJuSYRMlRGBhxrP0sIfB6yMfRZpuJncqN ztQ8txcEBf2Ew== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4600:1e00:222:fbff:fe91:d396]) by resomta-ch2-06v.sys.comcast.net with ESMTPA id d4pVi0zlmXFOod4pWikF5T; Fri, 06 Dec 2019 04:02:59 +0000 X-Xfinity-VMeta: sc=-100.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 xB642uYS025341; Thu, 5 Dec 2019 23:02:56 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id xB642txl025327; Thu, 5 Dec 2019 23:02:55 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Carsten Bormann Cc: cbor@ietf.org In-Reply-To: <953945BD-E435-4DDA-BC0A-EE7A8C4C36C6@tzi.org> (cabo@tzi.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 05 Dec 2019 23:02:54 -0500 Message-ID: <8736dy2j9t.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [Cbor] Magic number 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, 06 Dec 2019 04:03:03 -0000 Carsten Bormann writes: > However, not all CBOR carries this magic number. > I don't know if there is a way to say that "there is an optional magic > number defined that can be used by applications that want to use it" > in a media type registration. Functionally, I don't see this as a problem, as I've never known of an application that definitively rejected a file as not having a particular content type unless the application had specific knowledge of the details of the content type. OTOH, the "file" utility and others will differentiate a great number of content types based on the presence of magic numbers. That is, people generally assume that "file" can produce false negatives. Dale From nobody Fri Dec 6 10:06:32 2019 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 B72BD120105 for ; Fri, 6 Dec 2019 10:06:28 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 hkPsBCKk8vTy for ; Fri, 6 Dec 2019 10:06:24 -0800 (PST) Received: from p3plsmtpa09-04.prod.phx3.secureserver.net (p3plsmtpa09-04.prod.phx3.secureserver.net [173.201.193.233]) (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 5C7F71200A3 for ; Fri, 6 Dec 2019 10:06:24 -0800 (PST) Received: from [192.168.1.76] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id dHzjioMBGiuF7dHzji8dct; Fri, 06 Dec 2019 11:06:23 -0700 From: Laurence Lundblade Message-Id: <0F29E07D-1AB4-4229-B2C2-0C94FED3DA7E@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_547A11E4-8C4A-45BB-95EB-06673273505D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 6 Dec 2019 10:06:22 -0800 In-Reply-To: Cc: Faye Amacker , cbor@ietf.org To: Jeffrey Yasskin References: X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfLSjSblBr8BxkXS1p19Vl1snh1tHaoFhSI7R5HrAwsd+QjXAtMr7mVtJI//qOHsMyrRnD/+thn8HhCkROcFQcm75Uyqd3b7CLfSEMF7aVZmR+a2q4hnB 8AlkoaqyAu/5imFwbxtG2zwxIt9JACOImc4xp0bwcb056tNgbZ5pMA4pFoNvhjL/7HAfBpKfQmjyBkQIUsEpooJfV6PBqR5kiCx5Hzjh47YYtRJ+7ggL2qKW Archived-At: Subject: Re: [Cbor] Chunks with tags inside indefinite-length string (major type 2 and 3) 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, 06 Dec 2019 18:06:29 -0000 --Apple-Mail=_547A11E4-8C4A-45BB-95EB-06673273505D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree that chunks in indefinite length strings should not be tagged. I = think a decoder can aggregate the parts of an indefinite length string = into what looks like a definite length string to the next layer up = before processing tags. It would be good to have some of these in the not-well-formed CBOR = appendix. Here=E2=80=99s three: // Indefinite length byte string with tagged 2nd chunk {(uint8_t[]){0x5f, 0x41, 0x00, 0xc3, 0x42, 0x00, 0x00, 0xff}, 8} // Indefinite length byte string with tagged chunk {(uint8_t[]){0x5f, 0xc2, 0x41, 0x00, 0xff}, 5} // Indefinite length text string with tagged chunk {(uint8_t[]){0x7f, 0xc1, 0x61, 0x00, 0xff}, 5} I think your three rules about tagging are about right (applied to any = tagged item, not just to positive (big) numbers). CDDL allows you to = specify any of the three. It even gives an example of the third one. See = my_uri =3D #6.32(tstr) / tstr in section 3.6, though I hear we want to = discourage that third rule. One reason for restricting epoch date to a few types is to make it more = interoperable. Smaller decoders will not support big nums, decimal = fractions and such. Also, these larger types are not particularly needed = for dates (unless you wish to date dinosaur bones to the microsecond). LL > On Dec 5, 2019, at 1:56 PM, Jeffrey Yasskin = wrote: >=20 > I believe that's correct, with the caveat that protocols should be = able to specify that they accept a "number", which would accept = primitive integers, primitive floats, and tagged bigints, bigfloats, = bigdecimals, and any new tags defined to represent numbers. = https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#epochdateti= mesect = has some wording to restrict to just primitive integers. >=20 > Jeffrey >=20 > On Thu, Dec 5, 2019 at 1:47 PM Faye Amacker > wrote: > Jeffrey, I think you are correct. It seems I misread a line in the = pseudocode which made me doubt my interpretation of the text. >=20 > Can you confirm that decoders (both generic and non-generic) should: > * reject a tagged positive number if a protocol specifies a positive = number. > * reject a positive number if a protocol specifies a tagged positive = number. > * accept both positive number and tagged positive number only if the = protocol specifies the specific tag is optional. >=20 > Thanks again for your help. I'm relieved tags on chunks are = malformed. >=20 > On Thu, Dec 5, 2019 at 1:18 PM Jeffrey Yasskin > wrote: > I *think* = https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#indefinite-= length-byte-strings-and-text-strings = is pretty clear that the = contained things have to have the same major type as the = indefinite-length string, and tags have a different major type. e.g. "a = series of zero or more byte or text strings" doesn't include the = possibility of tags, and "If any item between the indefinite-length = string indicator (0b010_11111 or 0b011_11111) and the =E2=80=9Cbreak=E2=80= =9D stop code is not a definite-length string item of the same major = type, the string is not well-formed." says any other content is not = well-formed. >=20 > The pseudocode includes >=20 > if (it !=3D mt) // need finite-length chunk > fail(); // of same type >=20 > which I think also rejects tags inside indefinite strings. What am I = missing? >=20 > Jeffrey >=20 > On Thu, Dec 5, 2019 at 7:27 AM Faye Amacker > wrote: > While implementing support for tags, I ran into a scenario that might = be errata or could use some clarification in 7049bis. >=20 > Section 3.2.3 states: >=20 > > Indefinite-length strings are represented by a byte containing the = major type and additional information value of 31, followed by a series = of zero or more byte or text strings (=E2=80=9Cchunks=E2=80=9D) that = have definite lengths, followed by the =E2=80=9Cbreak=E2=80=9D stop code = (Section 3.2.1). The data item represented by the indefinite-length = string is the concatenation of the chunks (i.e., the empty byte or text = string, respectively, if no chunk is present). >=20 > And the pseudocode in Appendix C allows tags for chunks inside = indefinite-length strings. >=20 > Chunks are simply fragments to be concatenated, so tags applied to = chunks doesn't seem intuitive. Chunks are not intended for independent = access like array elements. Some tags (like #2 and #3) transform byte = string into bignum which makes sense for arrays, not chunks. >=20 > If tags must be applied to each chunk, there should be some text = mentioning that because library authors might think it should be = rejected or applied to the concatenated string rather than chunk. >=20 > However, if the tag for a chunk applies to the entire concatenated = string, then what happens when there are multiple chunks with different = tags? Which tag wins? >=20 > A simpler way forward is to treat tags on chunks as malformed. If = this is the way to go, then the pseudocode in Appendix C needs to be = updated and an example could be added to Appendix G. >=20 > GitHub issue for RFC 7049bis: = https://github.com/cbor-wg/CBORbis/issues/148 = > GitHub issue for my CBOR library: = https://github.com/fxamacker/cbor/issues/44 = ____________________________= ___________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor = > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_547A11E4-8C4A-45BB-95EB-06673273505D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree that chunks in indefinite length strings should not be tagged. I = think a decoder can aggregate the parts of an indefinite length string = into what looks like a definite length string to the next layer up = before processing tags.

It would be good to have some of these in the not-well-formed = CBOR appendix. Here=E2=80=99s three:
    // Indefinite length byte = string with tagged 2nd chunk
    = {(uint8_t[]){0x5f, 0x41, 0x00, = 0xc3, 0x42, 0x00, 0x00, 0xff}, = 8}
    // Indefinite length byte = string with tagged chunk
    {(uint8_t[]){0x5f, 0xc2, 0x41, 0x00, 0xff}, 5}
    // Indefinite = length text string with tagged chunk
    = {(uint8_t[]){0x7f, 0xc1, 0x61, 0x00, 0xff}, 5}

I think your three rules about tagging are about right = (applied to any tagged item, not just to positive (big) numbers). CDDL = allows you to specify any of the three. It even gives an example of the = third one. See my_uri =3D #6.32(tstr) / = tstr in section 3.6, though I hear we want to discourage that = third rule.

One= reason for restricting epoch date to a few types is to make it more = interoperable. Smaller decoders will not support big nums, decimal = fractions and such. Also, these larger types are not particularly needed = for dates (unless you wish to date dinosaur bones to the = microsecond).

LL


On Dec = 5, 2019, at 1:56 PM, Jeffrey Yasskin <jyasskin@chromium.org> wrote:

I believe that's correct, with the caveat that protocols = should be able to specify that they accept a "number", which would = accept primitive integers, primitive floats, and tagged bigints, = bigfloats, bigdecimals, and any new tags defined to represent = numbers. https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#= epochdatetimesect has some wording to restrict to just = primitive integers.

Jeffrey

On Thu, Dec = 5, 2019 at 1:47 PM Faye Amacker <faye.github@gmail.com> wrote:
Jeffrey, I think you are = correct.  It seems I misread a line in the pseudocode which made me = doubt my interpretation of the text.

Can you confirm that decoders (both = generic and non-generic) should:
* = reject a tagged positive number if a protocol specifies a positive = number.
* reject a positive number = if a protocol specifies a tagged positive number.
* accept both positive number and tagged positive number = only if the protocol specifies the specific tag is optional.

Thanks again for your help.  I'm relieved tags on chunks = are malformed.

On Thu, Dec 5, 2019 at 1:18 PM Jeffrey Yasskin = <jyasskin@chromium.org> wrote:
I = *think* https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#= indefinite-length-byte-strings-and-text-strings is pretty clear = that the contained things have to have the same major type as the = indefinite-length string, and tags have a different major type. e.g. "a = series of zero or more byte or text strings" doesn't include the = possibility of tags, and "If any item between the indefinite-length = string indicator (0b010_11111 or 0b011_11111) and the =E2=80=9Cbreak=E2=80= =9D stop code is not a definite-length string item of the same major = type, the string is not well-formed." says any other content is not = well-formed.

The = pseudocode includes

if (it !=3D mt)           // need = finite-length chunk
          = fail();               //   =  of same type

which I think also rejects tags inside = indefinite strings. What am I missing?

Jeffrey

On Thu, Dec = 5, 2019 at 7:27 AM Faye Amacker <faye.github@gmail.com> wrote:
While = implementing support for tags, I ran into a scenario that might be = errata or could use some clarification in 7049bis.

Section 3.2.3 states:

> = Indefinite-length strings are represented by a byte containing the major = type and additional information value of 31, followed by a series of = zero or more byte or text strings (=E2=80=9Cchunks=E2=80=9D) that have = definite lengths, followed by the =E2=80=9Cbreak=E2=80=9D stop code = (Section 3.2.1). The data item represented by the indefinite-length = string is the concatenation of the chunks (i.e., the empty byte or text = string, respectively, if no chunk is present).

And the pseudocode in Appendix C allows tags for chunks = inside indefinite-length strings.

Chunks = are simply fragments to be concatenated, so tags applied to chunks = doesn't seem intuitive.  Chunks are not intended for independent = access like array elements.  Some tags (like #2 and #3) transform = byte string into bignum which makes sense for arrays, not chunks.

If tags = must be applied to each chunk, there should be some text mentioning that = because library authors might think it should be rejected or applied to = the concatenated string rather than chunk.

However, if the tag for a chunk applies = to the entire concatenated string, then what happens when there are = multiple chunks with different tags? Which tag wins?

A simpler way forward is to treat tags on = chunks as malformed.  If this is the way to go, then the pseudocode = in Appendix C needs to be updated and an example could be added to = Appendix G.

GitHub issue for RFC 7049bis: https://github.com/cbor-wg/CBORbis/issues/148
GitHub issue for my CBOR library: https://github.com/fxamacker/cbor/issues/44
_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
_______________________________________________
CBOR = mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor

= --Apple-Mail=_547A11E4-8C4A-45BB-95EB-06673273505D-- From nobody Fri Dec 6 16:49:12 2019 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 434B3120044; Fri, 6 Dec 2019 16:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 jgRvBn7toTs3; Fri, 6 Dec 2019 16:49:10 -0800 (PST) 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 8F22B12006D; Fri, 6 Dec 2019 16:49:09 -0800 (PST) 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, 6 Dec 2019 16:49:03 -0800 From: Jim Schaad To: CC: Date: Fri, 6 Dec 2019 16:49:02 -0800 Message-ID: <036501d5ac98$201dd490$60597db0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdWrzuIQWugvBxHJT5iTlKC/vhBbgg== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] WGLC review of draft-ietf-cbor-7049bis-09 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, 07 Dec 2019 00:49:11 -0000 Here is my WGLC review of the document. * In paragraph 2 of section 1, I don't understand how the first sentence leads into the second sentence. The first talks about specific design goals, so I expected a discussion of some of those goals. Instead I get a discussion of the data model. Paragraph 3 seems to follow better from the first sentence of paragraph 2. * In section 1 - paragraph 3. I think this would fit better in section 1.1 rather than doing the forward reference. * Section 1.2 - The terminology of Encoder and Decoder do not seem to match each other. The decoder decodes a well-formed CBOR data item. The Encoder generates the representation of a CBOR data item. I assume that the decoder should decode the representation of a well-formed CBOR data item. The other way around would be that the Encoder creates a well-formed CBOR data item. * Section 2.2 last paragraph. /be considered duplicates/be considered duplicates, even if encoded as different major types,/ This is a belts and suspenders suggestion but not something I would die for. * Section 3 - para 1 - I do not believe that the encoding is summarized in table 6. This table just summarized the first byte of the encoding. Is this pointing to the right table or is the text just slightly messed up? * Section 3.2.3 - The text is silent on a chuck being of length zero. Should this be stated as discouraged but legal? * Section 3.4.2 - Is this section and 3.4.3 supposed to be at the same level s 3.4.1 or are they meant to be children? * Section 4.1 - I don't know what 1_000_000_000 is supposed to represent. My first assumption is that this is decimal, but it is not completely clear that is correct. * Section 4.2.2 - Do we want to include a point in this section about saying that applications may also need to set rules about how the content of a tag is going to be expressed. One example would be tag 6.1 where an application could state that all times are in UTC or that times are only expressed to the whole second. * Section 5.2 - I think that /containing a byte string or a text string/containing a byte string or containing a text string/ The byte string is an error in itself, the text string is only an issue if the embedded text is incorrect. * Section 9.2 - Are you intending to update the template to point to this document rather than saying with RFC 7049? This is not stated here. * Appendix B - Is there a reason why the first entry is Integer rather than Unsigned Integer? * Pseudo code - Should there be a break after case 7 (switch (mt))? Having it would be cleaner * Appendix F - This is missing some things which seem to be rather important. - New method to sort maps - Lots of work on describing the CBOR Data Models - Serialization considerations + Preferred - Canonical - Change in how validation/validity is described - Appendix G * Appendix G - /exexactly/exactly/ Jim From nobody Fri Dec 6 21:32:07 2019 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 35AED120116 for ; Fri, 6 Dec 2019 21:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.073, 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 pgOwcvEzdmsE for ; Fri, 6 Dec 2019 21:32:04 -0800 (PST) Received: from p3plsmtpa09-07.prod.phx3.secureserver.net (p3plsmtpa09-07.prod.phx3.secureserver.net [173.201.193.236]) (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 AF559120072 for ; Fri, 6 Dec 2019 21:32:04 -0800 (PST) Received: from [192.168.1.76] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id dShHifniPyTItdShIiNrus; Fri, 06 Dec 2019 22:32:04 -0700 From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5D8AF43E-1DAF-4797-8497-5984CCA6ADF0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 6 Dec 2019 21:32:03 -0800 In-Reply-To: <036501d5ac98$201dd490$60597db0$@augustcellars.com> Cc: draft-ietf-cbor-7049bis@ietf.org, cbor@ietf.org To: Jim Schaad References: <036501d5ac98$201dd490$60597db0$@augustcellars.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfNifeVf+zO3PTdiDFSJ2sjVvGGHCJp48Qq/eN7+hOuBC9oiFChNS4IfQo6Z7BJw0Ho+xO6bIlnc/BTBmpdjWAzh762VIB5SIphyDfPSvg8Ay7k3ub2Ll 0sjCd/l2fO6U7dyzPwZPU9l8o3d5E8c3ONFcnPHBYYvx2ANqV4Flh4rOC/OE2dCOGIY5meOtFGs9cH0il2uo/MzL85+fCc+MVGyjb8vtGegMgxZRE/kOZr9Q uPHd8RVatErZfRnaBJIs4w== Archived-At: Subject: Re: [Cbor] WGLC review of draft-ietf-cbor-7049bis-09 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, 07 Dec 2019 05:32:06 -0000 --Apple-Mail=_5D8AF43E-1DAF-4797-8497-5984CCA6ADF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 6, 2019, at 4:49 PM, Jim Schaad wrote: >=20 > * Section 3.4.2 - Is this section and 3.4.3 supposed to be at the same = level > s 3.4.1 or are they meant to be children? Children LL --Apple-Mail=_5D8AF43E-1DAF-4797-8497-5984CCA6ADF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Dec 6, 2019, at 4:49 PM, Jim Schaad <ietf@augustcellars.com> wrote:

* Section 3.4.2 - Is this = section and 3.4.3 supposed to be at the same level
s 3.4.1 or are they meant to be = children?

Children

LL

= --Apple-Mail=_5D8AF43E-1DAF-4797-8497-5984CCA6ADF0-- From nobody Sat Dec 7 09:36:40 2019 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 381F3120019; Sat, 7 Dec 2019 09:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_MED=-2.3, 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 fnFk1vHzb89f; Sat, 7 Dec 2019 09:36:34 -0800 (PST) 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 6AF10120802; Sat, 7 Dec 2019 09:36:34 -0800 (PST) Received: from [192.168.217.116] (p548DC893.dip0.t-ipconnect.de [84.141.200.147]) (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 47Vc801jYLz16VY; Sat, 7 Dec 2019 18:36:32 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <036501d5ac98$201dd490$60597db0$@augustcellars.com> Date: Sat, 7 Dec 2019 18:36:31 +0100 Cc: draft-ietf-cbor-7049bis@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 597432986.880481-072677ea83423ee4b7ecd54b241e3d40 Content-Transfer-Encoding: quoted-printable Message-Id: References: <036501d5ac98$201dd490$60597db0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] WGLC review of draft-ietf-cbor-7049bis-09 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, 07 Dec 2019 17:36:39 -0000 Hi Jim, Thank you for this review. > On Dec 7, 2019, at 01:49, Jim Schaad wrote: >=20 > Here is my WGLC review of the document. >=20 > * In paragraph 2 of section 1, I don't understand how the first = sentence > leads into the second sentence. The first talks about specific design > goals, so I expected a discussion of some of those goals. Instead I = get a > discussion of the data model. Paragraph 3 seems to follow better from = the > first sentence of paragraph 2. I don=E2=80=99t think the first sentence is meant to lead into the = second sentence. This brief introduction provides a set of facts that = distinguish CBOR from previous efforts but are not necessarily = interrelated. Paragraph 3 could be moved as a second sentence of paragraph 2, but that = would distract a bit from the brief explanation of what CBOR is. > * In section 1 - paragraph 3. I think this would fit better in = section 1.1 > rather than doing the forward reference. Section 1.1 is about the objectives behind CBOR. Section 1 paragraph 3 = is about previous formats. If we do want to restructure this, maybe it would be worth to do a = subsection =E2=80=9Chistory=E2=80=9D (or =E2=80=9Crelated work=E2=80=9D?) = with the JSON material and the pointer to appendix E. > * Section 1.2 - The terminology of Encoder and Decoder do not seem to = match > each other. The decoder decodes a well-formed CBOR data item. The = Encoder > generates the representation of a CBOR data item. I assume that the = decoder > should decode the representation of a well-formed CBOR data item. The = other > way around would be that the Encoder creates a well-formed CBOR data = item. Right. This is one instance where we don=E2=80=99t properly handle the = distinction between the abstract data item and its representation = format/encoded data item. This is an issue that would need to go through the whole definition = section and probably much more; e.g., well-formed is a property of an = instance of the representation format. Should we go for that? Symmetry between encoder and decoder should be easy to achieve even = without such massive surgery, e.g., s/well-formed CBOR data = item/well-formed encoded CBOR data item/ (maybe even without the = =E2=80=9CCBOR=E2=80=9D). > * Section 2.2 last paragraph. /be considered duplicates/be considered > duplicates, even if encoded as different major types,/ This is a = belts and > suspenders suggestion but not something I would die for. I=E2=80=99m not sure I like the =E2=80=9Cif=E2=80=9D (integer 0 and = float 0.0 are always encoded as different major types). How about = =E2=80=9Cwhile=E2=80=9D? > * Section 3 - para 1 - I do not believe that the encoding is = summarized in > table 6. This table just summarized the first byte of the encoding. = Is > this pointing to the right table or is the text just slightly messed = up? It is pointing to the right table. That table is indeed indexed by the = first byte, but does have more information in its right column. (It = *is* a summary.) How about: "The encoding is summarized in {{jumptable}}, indexed by the initial byte.=E2=80=9D (in PR below). > * Section 3.2.3 - The text is silent on a chuck being of length zero. > Should this be stated as discouraged but legal? I don=E2=80=99t know why this needs to be discouraged but it certainly = is not ruled out. To this reader, chunks of length 0 need to be discussed as much as = chunks of length 4711, which are also not ruled out. > * Section 3.4.2 - Is this section and 3.4.3 supposed to be at the same = level > s 3.4.1 or are they meant to be children? Fixed in PR below. I=E2=80=99m not a big fan of subsubsubsections, so I = just got rid of the section head for 3.4.1 entirely, adding the last = paragraph to the introduction of Section 3.4: Protocols using tag numbers 0 and 1 extend the generic data model ({{cbor-data-models}}) with data items representing points in time; tag numbers 2 and 3, with arbitrarily sized integers; and tag numbers 4 and 5, with floating point values of arbitrary size and precision. > * Section 4.1 - I don't know what 1_000_000_000 is supposed to = represent. > My first assumption is that this is decimal, but it is not completely = clear > that is correct. =20 Good languages have had these for a while, but even Java 7, C#, and = Python allow these underscores now=E2=80=A6 Changed text explaining this in 1.2 slightly in the PR below: Underscores can be added to a number solely for readability. > * Section 4.2.2 - Do we want to include a point in this section about = saying > that applications may also need to set rules about how the content of = a tag > is going to be expressed. One example would be tag 6.1 where an = application > could state that all times are in UTC or that times are only expressed = to > the whole second. I would add (in PR below): Deterministic encoding considerations also = apply to the content of tags. Would that address your point? > * Section 5.2 - I think that /containing a byte string or a text > string/containing a byte string or containing a text string/ The byte > string is an error in itself, the text string is only an issue if the > embedded text is incorrect. Added a comma to that (in PR below). > * Section 9.2 - Are you intending to update the template to point to = this > document rather than saying with RFC 7049? This is not stated here. Not sure about updating the template, but the registries should indeed = be updated to this specification. Added at the end of Section 9 in PR below: \[To be removed by RFC editor:] IANA is requested to update these registries to point to the present document instead of RFC 7049. > * Appendix B - Is there a reason why the first entry is Integer rather = than > Unsigned Integer? Not really (well, 0 to 23 are unsigned even if we don=E2=80=99t say so = :-). Fixed in PR below. > * Pseudo code - Should there be a break after case 7 (switch (mt))? = Having > it would be cleaner It is cleaner if we plan to update this code later. I don=E2=80=99t think we do=E2=80=A6 (And I don=E2=80=99t think we need another line in that code.) > * Appendix F - This is missing some things which seem to be rather > important. > - New method to sort maps > - Lots of work on describing the CBOR Data Models > - Serialization considerations + Preferred - Canonical > - Change in how validation/validity is described > - Appendix G Indeed. I think we need to do a separate PR for the list of changes. > * Appendix G - /exexactly/exactly/ Fixed in PR #144 (already merged). I have prepare a pull request with the changes that I already know what = I would propose to make from these comments: https://github.com/cbor-wg/CBORbis/pull/149 Of course, the questions raised above could lead to more changes. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Dec 7 11:24:54 2019 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 1990C120834; Sat, 7 Dec 2019 11:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 MqPCLn7n63lg; Sat, 7 Dec 2019 11:24:51 -0800 (PST) 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 0C7BB120831; Sat, 7 Dec 2019 11:24:50 -0800 (PST) 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, 7 Dec 2019 11:24:38 -0800 From: Jim Schaad To: 'Carsten Bormann' CC: , References: <036501d5ac98$201dd490$60597db0$@augustcellars.com> In-Reply-To: Date: Sat, 7 Dec 2019 11:24:36 -0800 Message-ID: <037901d5ad33$f86f9fe0$e94edfa0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHQ2zLAodfcg8UghEvdulp8QNZcLgG3QVSZp6ryloA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] WGLC review of draft-ietf-cbor-7049bis-09 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, 07 Dec 2019 19:24:53 -0000 -----Original Message----- From: Carsten Bormann =20 Sent: Saturday, December 7, 2019 9:37 AM To: Jim Schaad Cc: draft-ietf-cbor-7049bis@ietf.org; cbor@ietf.org Subject: Re: [Cbor] WGLC review of draft-ietf-cbor-7049bis-09 Hi Jim, Thank you for this review. > On Dec 7, 2019, at 01:49, Jim Schaad wrote: >=20 > Here is my WGLC review of the document. >=20 > * In paragraph 2 of section 1, I don't understand how the first=20 > sentence leads into the second sentence. The first talks about=20 > specific design goals, so I expected a discussion of some of those=20 > goals. Instead I get a discussion of the data model. Paragraph 3=20 > seems to follow better from the first sentence of paragraph 2. I don=E2=80=99t think the first sentence is meant to lead into the = second sentence. This brief introduction provides a set of facts that = distinguish CBOR from previous efforts but are not necessarily = interrelated. Paragraph 3 could be moved as a second sentence of paragraph 2, but that = would distract a bit from the brief explanation of what CBOR is. [JLS] Let's have Paul look at it. It just reads really badly to me. = Forward references would be one way to say that they are not related = items. > * In section 1 - paragraph 3. I think this would fit better in=20 > section 1.1 rather than doing the forward reference. Section 1.1 is about the objectives behind CBOR. Section 1 paragraph 3 = is about previous formats. If we do want to restructure this, maybe it would be worth to do a = subsection =E2=80=9Chistory=E2=80=9D (or =E2=80=9Crelated = work=E2=80=9D?) with the JSON material and the pointer to appendix E. [JLS] That would be part of the "are not well met" in the first = sentence. I don=E2=80=99t know that a history section would help here. > * Section 1.2 - The terminology of Encoder and Decoder do not seem to=20 > match each other. The decoder decodes a well-formed CBOR data item. =20 > The Encoder generates the representation of a CBOR data item. I=20 > assume that the decoder should decode the representation of a=20 > well-formed CBOR data item. The other way around would be that the = Encoder creates a well-formed CBOR data item. Right. This is one instance where we don=E2=80=99t properly handle the = distinction between the abstract data item and its representation = format/encoded data item. This is an issue that would need to go through the whole definition = section and probably much more; e.g., well-formed is a property of an = instance of the representation format. Should we go for that? [JLS] I hope that is not needed. Symmetry between encoder and decoder should be easy to achieve even = without such massive surgery, e.g., s/well-formed CBOR data = item/well-formed encoded CBOR data item/ (maybe even without the = =E2=80=9CCBOR=E2=80=9D). [JLS] I think you need some changes on the Encoder side as well. > * Section 2.2 last paragraph. /be considered duplicates/be considered > duplicates, even if encoded as different major types,/ This is a = belts and > suspenders suggestion but not something I would die for. I=E2=80=99m not sure I like the =E2=80=9Cif=E2=80=9D (integer 0 and = float 0.0 are always encoded as different major types). How about = =E2=80=9Cwhile=E2=80=9D? [JLS] That is just fine. Other approach would be /even if/when/ > * Section 3 - para 1 - I do not believe that the encoding is=20 > summarized in table 6. This table just summarized the first byte of=20 > the encoding. Is this pointing to the right table or is the text just = slightly messed up? It is pointing to the right table. That table is indeed indexed by the = first byte, but does have more information in its right column. (It = *is* a summary.) How about: "The encoding is summarized in {{jumptable}}, indexed by the initial byte.=E2=80=9D (in PR below). [JLS] fine. > * Section 3.2.3 - The text is silent on a chuck being of length zero. > Should this be stated as discouraged but legal? I don=E2=80=99t know why this needs to be discouraged but it certainly = is not ruled out. To this reader, chunks of length 0 need to be discussed as much as = chunks of length 4711, which are also not ruled out. [JLS] Yes, but checks of length 4711 are, if not expected, useful. A = chuck of length 0 is not useful. > * Section 3.4.2 - Is this section and 3.4.3 supposed to be at the same = > level s 3.4.1 or are they meant to be children? Fixed in PR below. I=E2=80=99m not a big fan of subsubsubsections, so I = just got rid of the section head for 3.4.1 entirely, adding the last = paragraph to the introduction of Section 3.4: Protocols using tag numbers 0 and 1 extend the generic data model ({{cbor-data-models}}) with data items representing points in time; tag = numbers 2 and 3, with arbitrarily sized integers; and tag numbers 4 and 5, with floating point values of arbitrary size and precision. [JLS] works for me > * Section 4.1 - I don't know what 1_000_000_000 is supposed to = represent. > My first assumption is that this is decimal, but it is not completely=20 > clear that is correct. Good languages have had these for a while, but even Java 7, C#, and = Python allow these underscores now=E2=80=A6 Changed text explaining this = in 1.2 slightly in the PR below: Underscores can be added to a number solely for readability. [JLS] I have never seen this. I don't know that I would agree that = this represents a good practice, but ok > * Section 4.2.2 - Do we want to include a point in this section about=20 > saying that applications may also need to set rules about how the=20 > content of a tag is going to be expressed. One example would be tag=20 > 6.1 where an application could state that all times are in UTC or that = > times are only expressed to the whole second. I would add (in PR below): Deterministic encoding considerations also = apply to the content of tags. Would that address your point? [JLS] Works for me > * Section 5.2 - I think that /containing a byte string or a text=20 > string/containing a byte string or containing a text string/ The byte = > string is an error in itself, the text string is only an issue if the=20 > embedded text is incorrect. Added a comma to that (in PR below). [JLS] WFM > * Section 9.2 - Are you intending to update the template to point to=20 > this document rather than saying with RFC 7049? This is not stated = here. Not sure about updating the template, but the registries should indeed = be updated to this specification. Added at the end of Section 9 in PR below: \[To be removed by RFC editor:] IANA is requested to update these registries to point to the present = document instead of RFC 7049. [JLS] As noted in the PR, I think IANA is going to want this instruction = to remain in the document. > * Appendix B - Is there a reason why the first entry is Integer rather = > than Unsigned Integer? Not really (well, 0 to 23 are unsigned even if we don=E2=80=99t say so = :-). Fixed in PR below. [JLS] WFM > * Pseudo code - Should there be a break after case 7 (switch (mt))? =20 > Having it would be cleaner It is cleaner if we plan to update this code later. I don=E2=80=99t think we do=E2=80=A6 (And I don=E2=80=99t think we need another line in that code.) [JLS] I prefer it, but that is just fine. ** Jim > * Appendix F - This is missing some things which seem to be rather=20 > important. > - New method to sort maps > - Lots of work on describing the CBOR Data Models > - Serialization considerations + Preferred - Canonical > - Change in how validation/validity is described > - Appendix G Indeed. I think we need to do a separate PR for the list of changes. > * Appendix G - /exexactly/exactly/ Fixed in PR #144 (already merged). I have prepare a pull request with the changes that I already know what = I would propose to make from these comments: https://github.com/cbor-wg/CBORbis/pull/149 Of course, the questions raised above could lead to more changes. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Dec 8 09:07:47 2019 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 E57A812004F; Sun, 8 Dec 2019 09:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 QtMoWZx2nBPB; Sun, 8 Dec 2019 09:07:43 -0800 (PST) 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 C4421120025; Sun, 8 Dec 2019 09:07:42 -0800 (PST) Received: from [192.168.217.116] (p548DC893.dip0.t-ipconnect.de [84.141.200.147]) (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 47WCSD0q5NzyT8; Sun, 8 Dec 2019 18:07:40 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <037901d5ad33$f86f9fe0$e94edfa0$@augustcellars.com> Date: Sun, 8 Dec 2019 18:07:39 +0100 Cc: draft-ietf-cbor-7049bis@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 597517656.776078-21d6600a0ba9fc4329c467c8b9ce4570 Content-Transfer-Encoding: quoted-printable Message-Id: <66CE9655-1721-4159-BC26-3791ACD46D45@tzi.org> References: <036501d5ac98$201dd490$60597db0$@augustcellars.com> <037901d5ad33$f86f9fe0$e94edfa0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] WGLC review of draft-ietf-cbor-7049bis-09 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, 08 Dec 2019 17:07:46 -0000 Hi Jim, now looking at the items not yet covered by the PR so far: >> * In paragraph 2 of section 1, I don't understand how the first=20 >> sentence leads into the second sentence. The first talks about=20 >> specific design goals, so I expected a discussion of some of those=20 >> goals. Instead I get a discussion of the data model. Paragraph 3=20 >> seems to follow better from the first sentence of paragraph 2. >=20 > I don=E2=80=99t think the first sentence is meant to lead into the = second sentence. This brief introduction provides a set of facts that = distinguish CBOR from previous efforts but are not necessarily = interrelated. > Paragraph 3 could be moved as a second sentence of paragraph 2, but = that would distract a bit from the brief explanation of what CBOR is. >=20 > [JLS] Let's have Paul look at it. It just reads really badly to me. = Forward references would be one way to say that they are not related = items. OK, I=E2=80=99ll let the native speakers sort that one out=E2=80=A6 >> * In section 1 - paragraph 3. I think this would fit better in=20 >> section 1.1 rather than doing the forward reference. >=20 > Section 1.1 is about the objectives behind CBOR. Section 1 paragraph = 3 is about previous formats. >=20 > If we do want to restructure this, maybe it would be worth to do a = subsection =E2=80=9Chistory=E2=80=9D (or =E2=80=9Crelated work=E2=80=9D?) = with the JSON material and the pointer to appendix E. >=20 > [JLS] That would be part of the "are not well met" in the first = sentence. I don=E2=80=99t know that a history section would help here. See above. >> * Section 1.2 - The terminology of Encoder and Decoder do not seem to=20= >> match each other. The decoder decodes a well-formed CBOR data item. =20= >> The Encoder generates the representation of a CBOR data item. I=20 >> assume that the decoder should decode the representation of a=20 >> well-formed CBOR data item. The other way around would be that the = Encoder creates a well-formed CBOR data item. >=20 > Right. This is one instance where we don=E2=80=99t properly handle = the distinction between the abstract data item and its representation = format/encoded data item. >=20 > This is an issue that would need to go through the whole definition = section and probably much more; e.g., well-formed is a property of an = instance of the representation format. Should we go for that? >=20 > [JLS] I hope that is not needed. >=20 > Symmetry between encoder and decoder should be easy to achieve even = without such massive surgery, e.g., s/well-formed CBOR data = item/well-formed encoded CBOR data item/ (maybe even without the = =E2=80=9CCBOR=E2=80=9D). >=20 > [JLS] I think you need some changes on the Encoder side as well. So here is my proposal of a limited change: =20 Decoder: -: A process that decodes a well-formed CBOR data item and makes it = available to an +: A process that decodes a well-formed encoded CBOR data item and makes = it available to an application. [=E2=80=A6] =20 Encoder: -: A process that generates the representation format of a CBOR data +: A process that generates the (well-formed) representation format of a = CBOR data item from application information. Added to PR below. >> * Section 2.2 last paragraph. /be considered duplicates/be = considered >> duplicates, even if encoded as different major types,/ This is a = belts and >> suspenders suggestion but not something I would die for. >=20 > I=E2=80=99m not sure I like the =E2=80=9Cif=E2=80=9D (integer 0 and = float 0.0 are always encoded as different major types). How about = =E2=80=9Cwhile=E2=80=9D? >=20 > [JLS] That is just fine. Other approach would be /even if/when/ I stuck with =E2=80=9Cwhile=E2=80=9D. Added to PR below. >> * Section 3.2.3 - The text is silent on a chuck being of length zero. >> Should this be stated as discouraged but legal? >=20 > I don=E2=80=99t know why this needs to be discouraged but it certainly = is not ruled out. > To this reader, chunks of length 0 need to be discussed as much as = chunks of length 4711, which are also not ruled out. >=20 > [JLS] Yes, but checks of length 4711 are, if not expected, useful. A = chuck of length 0 is not useful. Added: (Note that zero-length chunks, while not particularly useful, are = permitted.) Added to PR below. >> * Section 9.2 - Are you intending to update the template to point to=20= >> this document rather than saying with RFC 7049? This is not stated = here. >=20 > Not sure about updating the template, but the registries should indeed = be updated to this specification. >=20 > Added at the end of Section 9 in PR below: >=20 > \[To be removed by RFC editor:] > IANA is requested to update these registries to point to the present = document instead of RFC 7049. >=20 > [JLS] As noted in the PR, I think IANA is going to want this = instruction to remain in the document. I think I=E2=80=99d prefer to let them speak for themselves=E2=80=A6 (That sentence is not really useful for any future user of the RFC, so = I=E2=80=99d prefer to leave it out.) I updated https://github.com/cbor-wg/CBORbis/pull/149 with the changes = identified above. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 9 17:46:50 2019 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 6894712002F for ; Mon, 9 Dec 2019 17:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] 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 mJAReKVbMXgo for ; Mon, 9 Dec 2019 17:46:47 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 F016312001A for ; Mon, 9 Dec 2019 17:46:46 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-08v.sys.comcast.net with ESMTP id eTWcika9y7jwaeUbtir3Dj; Tue, 10 Dec 2019 01:46:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1575942405; bh=MNKgLUeDXFisf3vGwVVS1NGb3ymn3d/9SQowqdtLgvQ=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=dhSgFQb81tUqXb+4rWxfVJZjWVNmr7kLja4F3HiU5Rw8m03B7WL6LKsQJM0grxp1j NuUHXFceuZmQF9k+klpqHwflVb0xPNUp0VXmajh2CY10mheoAAKrhvRmgBPX7osQ+e j/OFcRKj8NvAIcSqSmYSj2eFnUE7ayZzTW+P9p26kNbXr3emULl0DI78wMy98uhPKU juaGARqUQdoAXRDnbZqz7N3uT36BxpTdYJzIan2gWOlGshjGHhaZ3hOf441HYsMPhG zXT8Sd5RCj5W90nE7svoKULLY1rH0TtNx+TBrnidcOIE2P5VBSurRb2ys339Pb565t KdyAKoTtM+gww== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4600:1e00:222:fbff:fe91:d396]) by resomta-ch2-17v.sys.comcast.net with ESMTPA id eUbsiASzeoG7SeUbtia8BR; Tue, 10 Dec 2019 01:46:45 +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 xBA1khIt017827; Mon, 9 Dec 2019 20:46:43 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id xBA1kgxb017824; Mon, 9 Dec 2019 20:46:42 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Faye Amacker Cc: cbor@ietf.org In-Reply-To: (faye.github@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 09 Dec 2019 20:46:42 -0500 Message-ID: <87a78154vx.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [Cbor] Chunks with tags inside indefinite-length string (major type 2 and 3) 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, 10 Dec 2019 01:46:49 -0000 Faye Amacker writes: > And the pseudocode in Appendix C allows tags for chunks inside > indefinite-length strings. It seems to me that the safe option, the one that will cause the least trouble in the future, is to define tags on items inside indefinite-length structure as syntactically well-structured but semantically having no defined meaning. Actually, that's the same as we treat use of tags whose values haven't been defined. Functionally, that means that no current application should generate them (and thus an application for the same universe of values should expect to never see them), but "generic" decoders should be prepared to see such tags. Dale From nobody Mon Dec 9 21:03:50 2019 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 0E2F412021C for ; Mon, 9 Dec 2019 21:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 fI5mi00FqYQO for ; Mon, 9 Dec 2019 21:03:46 -0800 (PST) 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 9F855120154 for ; Mon, 9 Dec 2019 21:03:46 -0800 (PST) Received: from client-0173.vpn.uni-bremen.de (client-0173.vpn.uni-bremen.de [134.102.107.173]) (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 47X7J04GTRz16CK; Tue, 10 Dec 2019 06:03:44 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <87a78154vx.fsf@hobgoblin.ariadne.com> Date: Tue, 10 Dec 2019 06:03:44 +0100 Cc: Faye Amacker , cbor@ietf.org X-Mao-Original-Outgoing-Id: 597647022.183664-b4d48bb92a0b0f15af4337cd7cca8acf Content-Transfer-Encoding: quoted-printable Message-Id: References: <87a78154vx.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Chunks with tags inside indefinite-length string (major type 2 and 3) 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, 10 Dec 2019 05:03:49 -0000 On Dec 10, 2019, at 02:46, Dale R. Worley wrote: >=20 > Faye Amacker writes: >> And the pseudocode in Appendix C allows tags for chunks inside >> indefinite-length strings. As Jeffrey noted, the pseudocode actually catches chunks that are of a = different major type than the indefinite string they are contained in. > It seems to me that the safe option, the one that will cause the least > trouble in the future, is to define tags on items inside > indefinite-length structure as syntactically well-structured but > semantically having no defined meaning. =20 Why would we allow tags here? Indefinite strings are a very limited = syntactical structure; there is no need to allow flexibility here (in = particular if there is no semantic gain from that). > Actually, that's the same as we > treat use of tags whose values haven=E2=80=99t been defined. I don=E2=80=99t follow. > Functionally, that means that no current application should generate > them (and thus an application for the same universe of values should > expect to never see them), but "generic" decoders should be prepared = to > see such tags. I don=E2=80=99t think so. Both the text and the pseudocode disallow = tags on chunks. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Dec 17 19:34:04 2019 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 6A4A212013A for ; Tue, 17 Dec 2019 19:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] 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 K-utk8RW15E5 for ; Tue, 17 Dec 2019 19:34:00 -0800 (PST) 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 4040C120073 for ; Tue, 17 Dec 2019 19:33:59 -0800 (PST) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id hPYjip8tpZB3ohQ63i1qzi; Wed, 18 Dec 2019 03:33:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1576640039; bh=pu+6CuFBh2f3nG3xuXXzbVgfkTR0RaL7HEL7zVk6apo=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=QyJuz+86v9Y7v3CvunOFIOqMVvPGbq+7O21IptSCNIR7TB0FE90/d1gVKdmd/AUHE YN1biWnO16jNb4iQVNiqGpQ0/4e8LYFnAkzrtlRWkwEK3qQUzC8WTgOveD7Y6q82JI z0BTx5L2voqz4jWQtSNKcmNOILn+Ml7YNEhjNB4auQ+z2zHr/wtFNV+8sPCFdWJcT2 daBDeLyiQo79JSrq0TBFZN+TdpqaI2xkiHm5VXobmzmDPxgbb3MYTMrf/gIGCgLGCP XqMwad7jFge11OxwVhumJYDobi8OkIJZiLH5Ktw1ZJyO7KSlZBNqpi3kOkw5Mhyy// 0x1bii1ZJhmqQ== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4600:1e00:222:fbff:fe91:d396]) by resomta-ch2-12v.sys.comcast.net with ESMTPA id hQ60inQusEu3BhQ61iyR7n; Wed, 18 Dec 2019 03:33:58 +0000 X-Xfinity-VMeta: sc=-100.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 xBI3XuBB021299; Tue, 17 Dec 2019 22:33:56 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id xBI3XsOZ021288; Tue, 17 Dec 2019 22:33:54 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Carsten Bormann Cc: faye.github@gmail.com, cbor@ietf.org In-Reply-To: (cabo@tzi.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 17 Dec 2019 22:33:53 -0500 Message-ID: <8736di2tpa.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [Cbor] Chunks with tags inside indefinite-length string (major type 2 and 3) 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, 18 Dec 2019 03:34:03 -0000 Carsten Bormann writes: > Why would we allow tags here? Indefinite strings are a very limited > syntactical structure; there is no need to allow flexibility here (in > particular if there is no semantic gain from that). The reason I argue is that having worked with SIP, I've become very respectful of extensibility. SIP has taken over the internals of every major telecom company, it seems. And that doesn't seem to be because SIP is wonderfully designed; it's sort of a running joke to list the things one would change in the next version of SIP if it didn't have to be upward-compatible. But SIP has a number of very general extensibility mechanisms that make it possible to implement almost any telecomm feature in an upward-compatible way. And there are dozens if not hundreds of SIP extensions. And while I cannot guess what use might be made of tagging chunks of indefinite-length strings, it seems to me that as long as the fundamental structure of CBOR allows such a thing to be constructed unambiguously, the wisest course of action is to make it clear that such constructs can sensibly be made, but the current standard assigns no meaning to them. Dale From nobody Tue Dec 17 21:45:01 2019 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 D78A612011B for ; Tue, 17 Dec 2019 21:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 UeEIwZ8NEQO0 for ; Tue, 17 Dec 2019 21:44:56 -0800 (PST) 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 12C1C120098 for ; Tue, 17 Dec 2019 21:44:56 -0800 (PST) Received: from client-0017.vpn.uni-bremen.de (client-0017.vpn.uni-bremen.de [134.102.107.17]) (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 47d3qp1ph8zyjh; Wed, 18 Dec 2019 06:44:54 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <8736di2tpa.fsf@hobgoblin.ariadne.com> Date: Wed, 18 Dec 2019 06:44:52 +0100 Cc: cbor@ietf.org, faye.github@gmail.com X-Mao-Original-Outgoing-Id: 598340689.4383301-f07721f644ae3b28ca95c06a1be43f77 Content-Transfer-Encoding: quoted-printable Message-Id: <85C20E2D-1FF5-4B2B-9D5D-0916B4D02EFF@tzi.org> References: <8736di2tpa.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Chunks with tags inside indefinite-length string (major type 2 and 3) 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, 18 Dec 2019 05:45:00 -0000 Hi Dale, I completely agree that extensibility (and, more generally, = evolvability) is what can make or break a protocol. One of the big = differences between JSON and CBOR is that JSON was designed to be = =E2=80=9Cstable=E2=80=9D (fixed, non-extensible), while CBOR has = well-defined extension points. Indefinite length strings are a syntactic feature of CBOR that was not = designed to be extensible. I have a hard time imagining why one would = want to extend it. I don=E2=80=99t think this is proof by lack of = imagination, either; this mechanism already has more complexity than one = would reasonably like; it just happens to be needed. There are no data = model extensions that would need to extend this mechanism. If there = ever is a need to extend it, this would be much like using additional = information values 28..30: A revision of the standard, a new version of = the format. For the present format, indefinite length strings of major = type N (2 or 3) are composed of definite length strings of the same = major type, only. Gr=C3=BC=C3=9Fe, Carsten > On Dec 18, 2019, at 04:33, Dale R. Worley wrote: >=20 > Carsten Bormann writes: >> Why would we allow tags here? Indefinite strings are a very limited >> syntactical structure; there is no need to allow flexibility here (in >> particular if there is no semantic gain from that). >=20 > The reason I argue is that having worked with SIP, I've become very > respectful of extensibility. SIP has taken over the internals of = every > major telecom company, it seems. And that doesn't seem to be because > SIP is wonderfully designed; it's sort of a running joke to list the > things one would change in the next version of SIP if it didn't have = to > be upward-compatible. But SIP has a number of very general > extensibility mechanisms that make it possible to implement almost any > telecomm feature in an upward-compatible way. And there are dozens if > not hundreds of SIP extensions. >=20 > And while I cannot guess what use might be made of tagging chunks of > indefinite-length strings, it seems to me that as long as the > fundamental structure of CBOR allows such a thing to be constructed > unambiguously, the wisest course of action is to make it clear that = such > constructs can sensibly be made, but the current standard assigns no > meaning to them. >=20 > Dale >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Dec 18 06:41:22 2019 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 B644F12020A; Wed, 18 Dec 2019 06:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 1pazRCjLDqsm; Wed, 18 Dec 2019 06:41:19 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80059.outbound.protection.outlook.com [40.107.8.59]) (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 9C36A120112; Wed, 18 Dec 2019 06:41:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lr3SCETnLoGrWwJbmjGjAF/2m5Qibl3mGqwlQGQk+0Wq8HouENR4FDkpobQsWRyd1fHc/6+2E2zyCaZx7WD6HYkK/id74NlP73RePgGItULZT3uRBC4NufTSKsI7GRIuWA2pwEchCTF3vaHHuNeZu7OJdZdCjDgl+YvyzAVXKSzVS3ZPQ4I6iknxDIHqz5M3AxpjVEFP1mOICLnBFF/Z6/6t3XjvVouFIYy1iCmKNkgNup5MfBHWYqioAzgQho8E5GZO3Lw/MWplAjg9ID5QJT9jLV3o+VBlBcWICxW04u+UrmDJti4nkcH8ZTulCW/FWkJqWBQwYRdcqn19BMKAAA== 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=2VMWU5tbaKn3Tx/IOnPl2UOVzfJL8LBnb/utWbyR1po=; b=LXVJfrX4dnoGo/eklCJ9XcNitoo9nA2+9n0f5KjcuuK6FPnaB/zVuHTP1NK4vCoMCizFFuSHagXyWxa3EkFhiyPTkSHJ6L3xKXIcTHUZ+am8NIOeqPwt4wW/AxC9c3lUYnlFeRI91AARsUJirTGGL/fhft7mq43UwlY07fjG71oyj0il4WeG2lXDKUCVLtXaEc22DHB3ZA8yR26AdiGdLOooGz0OlT8Yl0K9CwRUkKpWsjiuhcxm15cveSEDVwBxrqxl8c13y0w5YJx//u3+PGKl+Xd3CrqLizDkoZrjIiQdo356bb5GbJrqFXvQzX3MuAyYx46cRdk5qhBvBa2bpg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ietf.org; dkim=pass header.d=ietf.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2VMWU5tbaKn3Tx/IOnPl2UOVzfJL8LBnb/utWbyR1po=; b=XCSKsj+ExMrjcuIraMzgasGgVy70wnqr2R7EH6dMBQ5rXOwMDrYjVSmQ7eShF2lvveHLujlr9Wm8MXDDad50GFZMhMNuUygiEJUoEwOBFmQ1TEIDHrYx9jQeXmD4jXcV0OaTBkea6bkzCz6LizPzkKs0eujArOXiLBBecmU8V14= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB4678.eurprd07.prod.outlook.com (20.177.39.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.9; Wed, 18 Dec 2019 14:41:14 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::8514:c0f:390b:277]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::8514:c0f:390b:277%6]) with mapi id 15.20.2559.012; Wed, 18 Dec 2019 14:41:14 +0000 From: CBOR Working Group To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: CBOR virtual interim meeting 12-18-2019 Thread-Index: AQHVtbExVZbwWHLPkkGGOdMhFLioOA== Sender: Francesca Palombini Date: Wed, 18 Dec 2019 14:41:14 +0000 Message-ID: References: <910238769.2357261574776477925.JavaMail.nobody@rva2rmd101.webex.com> In-Reply-To: <910238769.2357261574776477925.JavaMail.nobody@rva2rmd101.webex.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-publictraffictype: Email authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 2 x-ms-exchange-meetingforward-message: Forward x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAAAAAAAAAAAAAAAAAAAAAAAAAAAMQAAAHZDYWwtVWlkAQAAADFhYzMyZTg0LWEyNWEtNGY3Yi1hY2RjLTJmMGVkZjA0NmRjNgA= x-originating-ip: [109.52.248.44] x-ms-office365-filtering-correlation-id: cb5cf1d6-c58e-4b90-a26d-08d783c85562 x-ms-traffictypediagnostic: AM6PR07MB4678:MeetingMessage x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(346002)(376002)(39860400002)(136003)(189003)(199004)(53754006)(8676002)(81166006)(8936002)(2906002)(4326008)(450100002)(16799955002)(478600001)(6506007)(81156014)(33656002)(966005)(7696005)(6916009)(6636002)(9686003)(76116006)(91956017)(42882007)(5660300002)(55016002)(316002)(7846003)(186003)(26005)(66446008)(64756008)(66556008)(66476007)(66616009)(71200400001)(19627405001)(52536014)(4744005)(66946007)(574754004)(24704002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4678; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 2 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XNcALGNSpRyT/4wjtGO5hEvaoufcw6G3+CY+IyYjuZYp8Fc7YRRAwNXsCq0QnLWWcyg3stbImGBschZFbNCmOpSjbVWGVs9mDoFOzGxLGnftZ4dhDd0THse1MlIdQ4rhmMpdH6BxU3BxnW1h0hktvUAL8rSr+yp2GA8x20ZUkHQO2bzpdZfGtGfAqjMDU3vKPNIJyqi0mce2nzCpH1WeaXtoJSsx3ZjakEMw8wlNzRwUhsDtCRnlwi+ozS0ahAueqqZx89uEAL4FrYL194e+bolCffWOXvV22i7SaXItXnrT7WT/NDXPYl4ACgvwQKtYtQatUsAkHD8kYekardtNdt7iU5Zu8UlwpcKThUHschBx2baGf3YhF5kUnylguZ/ppKUZ3/MrV/2LU5cOOfXec9exTpzk4BfEPEDpevJ+W7lrpXfK6GsNOjmzHq7kb1NHa8XbwvKOEAUr69ueHpTp6epBF1kCTfFjuYwt9vJQmF2wAXMcKUzpe6UKHRGAxvzgO6lBoLd7XhU8ZfR85V2W1HLZJ1MDblq8lSJS4MPIRDjheaXQqiG+nMdzyFoJyhu2S959fzuTZaUtHawF0MQEag== x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_005_AM6PR07MB40530D284C500931425A9D5898530AM6PR07MB4053eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: cb5cf1d6-c58e-4b90-a26d-08d783c85562 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2019 14:41:14.2151 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FKAy2K+fjYbWcZfAgQ+66d+JNIj2yoO6Fe1zLTSrqMVVOFRwwo5Lx0IsXvtNskjQVzrEcExexqkDFCptgEcAAOldB0LINm4kkM98PG3h6omN2QAXwFxBFZzTsvNRdGTz X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4678 Archived-At: Subject: [Cbor] CBOR virtual interim meeting 12-18-2019 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, 18 Dec 2019 14:41:21 -0000 --_005_AM6PR07MB40530D284C500931425A9D5898530AM6PR07MB4053eurp_ Content-Type: multipart/alternative; boundary="_000_AM6PR07MB40530D284C500931425A9D5898530AM6PR07MB4053eurp_" --_000_AM6PR07MB40530D284C500931425A9D5898530AM6PR07MB4053eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, A reminder that we have an interim today (in around 80 minutes), call detai= ls below. On the agenda for today is to discuss status update and open issues on CBOR= bis specification, following WGLC. Francesca From: CBOR Working Group Reply to: Date: Tuesday, 26 November 2019 at 14:54 To: Subject: Webex meeting invitation: CBOR virtual interim meeting Resent from: Resent to: Jim Schaad , Francesca Palombini Resent date: Tue, 26 Nov 2019 05:54:41 -0800 (PST) CBOR Working Group invites you to join this Webex meeting. Meeting number (access code): 644 419 682 Meeting password: spPVbbv4 Wednesday, December 18, 2019 4:00 pm | (UTC+00:00) Monrovia, Reykjavik | 1 hr Join meeting Join by phone Tap to call in from a mobile device (attendees only) 1-650-479-3208 Call-in toll= number (US/Canada) Need help? Go to http://help.webex.com --_000_AM6PR07MB40530D284C500931425A9D5898530AM6PR07MB4053eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

&nbs= p;

A reminde= r that we have an interim today (in around 80 minutes), call details below.=

&nbs= p;

On the ag= enda for today is to discuss status update and open issues on CBOR bis spec= ification, following WGLC.

&nbs= p;

Francesca=

&nbs= p;

From= : CBOR Working Grou= p <messenger@webex.com>
Reply to: <cbor-chairs@ietf.org>
Date: Tuesday, 26 November 2019 at 14:54
To: <cbor-chairs@ietf.org>
Subject: Webex meeting invitation: CBOR virtual interim meeting
Resent from: <alias-bounces@ietf.org>
Resent to: Jim Schaad <ietf@augustcellars.com>, Francesca Palo= mbini <francesca.palombini@ericsson.com>
Resent date: Tue, 26 Nov 2019 05:54:41 -0800 (PST)=

 

 

CBOR Working Group invites you to join this Webex meeting.

 

 

 

Meeting number (access code): 644 419 682

 

Meeting password: spPVbbv4

 

 

 

Wednesday, December 18, 2019

4:00 pm  |  (UTC+00:00) Monrovia, Reyk= javik  |  1 hr

 

 

 

Join meeting

 

 

 

Join by phone

Tap to call in from a mobile device (attendees only)=

1-650-479-3208&n= bsp;Call-in toll number (US/Canada)

 

 

 

Need help? Go to http://help.webex.com

 

 

--_000_AM6PR07MB40530D284C500931425A9D5898530AM6PR07MB4053eurp_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpBdGxhbnRp Yy9SZXlramF2aWsNCkJFR0lOOlNUQU5EQVJEDQpEVFNUQVJUOjE2MDEwMTAxVDAwMDAwMA0KVFpP RkZTRVRGUk9NOiswMDAwDQpUWk9GRlNFVFRPOiswMDAwDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRB WUxJR0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAwMDAwMA0KVFpPRkZTRVRGUk9NOiswMDAwDQpUWk9G RlNFVFRPOiswMDAwDQpFTkQ6REFZTElHSFQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0K T1JHQU5JWkVSO0NOPUNCT1IgV29ya2luZyBHcm91cDtTRU5ULUJZPSJNQUlMVE86ZnJhbmNlc2Nh LnBhbG9tYmluaUBlcmljc3Nvbg0KIC5jb20iOk1BSUxUTzpjYm9yLWNoYWlyc0BpZXRmLm9yZw0K QVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9 RkFMU0U7Q049Y2JvckBpZXRmDQogLm9yZzpNQUlMVE86Y2JvckBpZXRmLm9yZw0KQVRURU5ERUU7 Uk9MRT1PUFQtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9RkFMU0U7Q049 Y2Jvci1jaGFpDQogcnNAaWV0Zi5vcmc6TUFJTFRPOmNib3ItY2hhaXJzQGlldGYub3JnDQpBVFRB Q0g6Q0lEOjUxMTUzQjI3Nzg1ODkwNENCRTA5REE2NUMzM0E1MjQ5QGV1cnByZDA3LnByb2Qub3V0 bG9vay5jb20NCkRFU0NSSVBUSU9OO0xBTkdVQUdFPWVuLUdCOkhpIGFsbFwsXG5cbkEgcmVtaW5k ZXIgdGhhdCB3ZSBoYXZlIGFuIGludGVyaW0gdA0KIG9kYXkgKGluIGFyb3VuZCA4MCBtaW51dGVz KVwsIGNhbGwgZGV0YWlscyBiZWxvdy5cblxuT24gdGhlIGFnZW5kYSBmb3IgdG9kDQogYXkgaXMg dG8gZGlzY3VzcyBzdGF0dXMgdXBkYXRlIGFuZCBvcGVuIGlzc3VlcyBvbiBDQk9SIGJpcyBzcGVj aWZpY2F0aW9uXCwNCiAgZm9sbG93aW5nIFdHTEMuXG5cbkZyYW5jZXNjYVxuXG5Gcm9tOiBDQk9S IFdvcmtpbmcgR3JvdXAgPG1lc3NlbmdlckB3ZWJleA0KIC5jb20+XG5SZXBseSB0bzogPGNib3It Y2hhaXJzQGlldGYub3JnPlxuRGF0ZTogVHVlc2RheVwsIDI2IE5vdmVtYmVyIDIwMTkgDQogYXQg MTQ6NTRcblRvOiA8Y2Jvci1jaGFpcnNAaWV0Zi5vcmc+XG5TdWJqZWN0OiBXZWJleCBtZWV0aW5n IGludml0YXRpb246IEMNCiBCT1IgdmlydHVhbCBpbnRlcmltIG1lZXRpbmdcblJlc2VudCBmcm9t OiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz5cblJlc2VudA0KICB0bzogSmltIFNjaGFhZCA8aWV0 ZkBhdWd1c3RjZWxsYXJzLmNvbT5cLCBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EuDQog cGFsb21iaW5pQGVyaWNzc29uLmNvbT5cblJlc2VudCBkYXRlOiBUdWVcLCAyNiBOb3YgMjAxOSAw NTo1NDo0MSAtMDgwMCAoUFMNCiBUKVxuXG5cbkNCT1IgV29ya2luZyBHcm91cCBpbnZpdGVzIHlv dSB0byBqb2luIHRoaXMgV2ViZXggbWVldGluZy5cblxuXG5cbg0KIE1lZXRpbmcgbnVtYmVyIChh Y2Nlc3MgY29kZSk6IDY0NCA0MTkgNjgyXG5cbk1lZXRpbmcgcGFzc3dvcmQ6IHNwUFZiYnY0XG5c DQogblxuXG5XZWRuZXNkYXlcLCBEZWNlbWJlciAxOFwsIDIwMTlcbjQ6MDAgcG0gIHwgIChVVEMr MDA6MDApIE1vbnJvdmlhXCwgUmUNCiB5a2phdmlrICB8ICAxIGhyXG5cblxuXG5Kb2luIG1lZXRp bmc8aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USQ0KIEQ9bTA1MzVjMzYyZDBh OWEyMjYwMjJkZmY5YzY2MWNmM2YxPlxuXG5cblxuSm9pbiBieSBwaG9uZVxuVGFwIHRvIGNhbGwg aW4gDQogZnJvbSBhIG1vYmlsZSBkZXZpY2UgKGF0dGVuZGVlcyBvbmx5KVxuMS02NTAtNDc5LTMy MDg8dGVsOiUyQjEtNjUwLTQ3OS0zMjANCiA4XCxcLCowMSo2NDQ0MTk2ODIlMjMlMjMqMDEqPiBD YWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5cblxuXG5OZWVkIA0KIGhlbHA/IEdvIHRv IGh0dHA6Ly9oZWxwLndlYmV4LmNvbVxuXG5cbg0KVUlEOjFhYzMyZTg0LWEyNWEtNGY3Yi1hY2Rj LTJmMGVkZjA0NmRjNg0KU1VNTUFSWTtMQU5HVUFHRT1lbi1HQjpDQk9SIHZpcnR1YWwgaW50ZXJp bSBtZWV0aW5nIDEyLTE4LTIwMTkNCkRUU1RBUlQ7VFpJRD1BdGxhbnRpYy9SZXlramF2aWs6MjAx OTEyMThUMTYwMDAwDQpEVEVORDtUWklEPUF0bGFudGljL1JleWtqYXZpazoyMDE5MTIxOFQxNzAw MDANCkNMQVNTOlBVQkxJQw0KUFJJT1JJVFk6NQ0KRFRTVEFNUDoyMDE5MTEyNlQxMzU0MzdaDQpU UkFOU1A6T1BBUVVFDQpTVEFUVVM6Q09ORklSTUVEDQpTRVFVRU5DRToxNTc0Nzc2NDc3DQpMT0NB VElPTjtMQU5HVUFHRT1lbi1HQjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYNClgtTUlDUk9T T0ZULUNETy1BUFBULVNFUVVFTkNFOjE1NzQ3NzY0NzcNClgtTUlDUk9TT0ZULUNETy1CVVNZU1RB VFVTOlRFTlRBVElWRQ0KWC1NSUNST1NPRlQtQ0RPLUlOVEVOREVEU1RBVFVTOkJVU1kNClgtTUlD Uk9TT0ZULUNETy1BTExEQVlFVkVOVDpGQUxTRQ0KWC1NSUNST1NPRlQtQ0RPLUlNUE9SVEFOQ0U6 MQ0KWC1NSUNST1NPRlQtQ0RPLUlOU1RUWVBFOjANClgtTUlDUk9TT0ZULURPTk9URk9SV0FSRE1F RVRJTkc6RkFMU0UNClgtTUlDUk9TT0ZULURJU0FMTE9XLUNPVU5URVI6RkFMU0UNClgtTUlDUk9T T0ZULUxPQ0FUSU9OUzpbeyJEaXNwbGF5TmFtZSI6Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 ZiJcLCJMb2NhdA0KIGlvbkFubm90YXRpb24iOiIiXCwiTG9jYXRpb25VcmkiOiIiXCwiTG9jYXRp b25TdHJlZXQiOiIiXCwiTG9jYXRpb25DaXR5IjoiDQogIlwsIkxvY2F0aW9uU3RhdGUiOiIiXCwi TG9jYXRpb25Db3VudHJ5IjoiIlwsIkxvY2F0aW9uUG9zdGFsQ29kZSI6IiJcLCJMb2MNCiBhdGlv bkZ1bGxBZGRyZXNzIjoiIn1dDQpCRUdJTjpWQUxBUk0NCkRFU0NSSVBUSU9OOlJFTUlOREVSDQpU UklHR0VSO1JFTEFURUQ9U1RBUlQ6LVBUNU0NCkFDVElPTjpESVNQTEFZDQpFTkQ6VkFMQVJNDQpF TkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= --_000_AM6PR07MB40530D284C500931425A9D5898530AM6PR07MB4053eurp_-- --_005_AM6PR07MB40530D284C500931425A9D5898530AM6PR07MB4053eurp_ Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Description: Webex_Meeting.ics Content-Disposition: attachment; filename="Webex_Meeting.ics"; size=5348; creation-date="Tue, 26 Nov 2019 13:54:58 GMT"; modification-date="Tue, 26 Nov 2019 13:54:58 GMT" Content-ID: <51153B277858904CBE09DA65C33A5249@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL1JleWtqYXZpaw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96 b25laW5mby1vdXRsb29rL0F0bGFudGljL1JleWtqYXZpaw0KWC1MSUMtTE9DQVRJT046QXRsYW50 aWMvUmV5a2phdmlrDQpCRUdJTjpTVEFOREFSRA0KVFpPRkZTRVRGUk9NOiswMDAwDQpUWk9GRlNF VFRPOiswMDAwDQpUWk5BTUU6R01UDQpEVFNUQVJUOjE5NzAwMTAxVDAwMDAwMA0KRU5EOlNUQU5E QVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAxOTExMjZUMTM1NDM3 Wg0KQVRURU5ERUU7Q049IkNCT1IgV29ya2luZyBHcm91cCI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7 UlNWUD1UUlVFOk1BSUxUTzpjYm9yLWNoYWlyc0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJDQk9S IFdvcmtpbmcgR3JvdXAiOk1BSUxUTzpjYm9yLWNoYWlyc0BpZXRmLm9yZw0KRFRTVEFSVDtUWklE PUF0bGFudGljL1JleWtqYXZpazoyMDE5MTIxOFQxNjAwMDANCkRURU5EO1RaSUQ9QXRsYW50aWMv UmV5a2phdmlrOjIwMTkxMjE4VDE3MDAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmDQpUUkFOU1A6T1BBUVVFDQpTRVFVRU5DRToxNTc0Nzc2NDc3DQpVSUQ6MWFjMzJlODQt YTI1YS00ZjdiLWFjZGMtMmYwZWRmMDQ2ZGM2DQpERVNDUklQVElPTjpcblxuXG5cbkpPSU4gV0VC RVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTA1MzVj MzYyZDBhOWEyMjYwMjJkZmY5YzY2MWNmM2YxXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUp OiA2NDQgNDE5IDY4MlxuXG5cbk1lZXRpbmcgcGFzc3dvcmQ6IHNwUFZiYnY0XG5cblxuXG5KT0lO IEJZIFBIT05FXG4xLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEp XG5UYXAgaGVyZSB0byBjYWxsIChtb2JpbGUgcGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0 ZWQpOiB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDQ0MTk2ODIlMjMlMjMqMDEqXG5cblxu XG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNp c2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFz ZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5m b3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1h eSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNz aW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91 IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMg d2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQtREVTQztG TVRUWVBFPXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxuKiB7XG4gICAgcGFkZGlu ZzogMDsgICAgbWFyZ2luOiAwO31cbnRhYmxlIHtcbglib3JkZXItY29sbGFwc2U6IHNlcGFyYXRl OyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2luZzogMDt9XG5cbnRyIHtcbgls aW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRkIHtcbglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFt aWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1icmVh azogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxuLnRpdGxlIHtcbglmb250LXNpemU6IDI4cHg7fVxu XG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwltYXgtd2lkdGg6IGF1dG87fVxuXG4uZm9vdGVyIHtc bgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7XG5cbn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRl dmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0bGUge1xuCQlmb250LXNpemU6IDIycHggIWltcG9y dGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRoOiBhdXRvICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6 IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290ZXIge1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50 OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxuCS5tYWluIHtcbgkJd2lkdGg6IDEw MCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbn1cbjwvc3R5 bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFyZ2lu OiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiPlxuCTx0ciBzdHlsZT0i aGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCTx0cj5cbgkJPHRkIGFsaWduPSJs ZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAiPlxuCQkJPCEtLTx0YWJsZSBi Z2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7IHdpZHRoOiAxMDAlOyBwYWRkaW5n LWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1h aW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5i c3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPi0tPlxuXG5cblxuXG5cbgkJCTx0 YWJsZT5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjQiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+V2hlbiBpdCdzIHRpbWUsIGpvaW4gdGhlIFdlYmV4IG1lZXRp bmcgaGVyZS48L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCQk8dHIgc3R5bGU9Imxp bmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3Ry PlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDQgNDE5IDY4 MjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT5cbgkJCVxuCQkJPHRh YmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5N ZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5zcFBWYmJ2NDwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT5cblxu ICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+ PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPHRyPlxuCQkJCTx0 ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4JCQkJCTx0YWJsZSBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5bGU9IndpZHRoOmF1dG87d2lkdGg6 YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNBOTQyOyBib3JkZXI6MHB4IHNvbGlk ICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdpZHRoOjE2MHB4IWltcG9ydGFudDsi PlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiBzdHlsZT0icGFkZGluZzox MHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tMDUzNWMzNjJkMGE5YTIyNjAyMmRmZjljNjYxY2YzZjEiIHN0eWxlPSJjb2xvcjojRkZGRkZG OyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5Kb2luIG1lZXRpbmc8L2E+ PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4JCQkJPC90ZD5cbgkJCTwvdHI+XG4J CTwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9ImZvbnQt ZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJz cDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSI0IiBGQUNF PSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2lu IGJ5IHBob25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+PGI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQ0 NDE5NjgyJTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29yYXRpb246 bm9uZTsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjRw eDsnPjEtNjUwLTQ3OS0zMjA4PC9hPjwvYj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRh KTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48QlI+XG5cbjx0YWJsZT48dHIgc3R5bGU9Imxp bmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3Ry PjwvdGFibGU+XG5cblxuXG5cblxuCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDogMTAwJTsiIGFsaWdu PSJsZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6 IDcycHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgc3R5bGU9Imhl aWdodDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OkFyaWFsOyBmb250LXNpemU6 IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBHbyB0byA8YSBocmVmPSJodHRw Oi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5OyB0ZXh0LWRlY29yYXRpb246 bm9uZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxu ICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48dGQ+Jm5ic3A7PC90ZD48 L3RyPlxuCQkJPC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90YWJsZT5cbg0KU1VNTUFSWTpD Qk9SIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nDQpQUklPUklUWTo1DQpDTEFTUzpQVUJMSUMNCkJF R0lOOlZBTEFSTQ0KVFJJR0dFUjotUFQ1TQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9OOlJl bWluZGVyDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= --_005_AM6PR07MB40530D284C500931425A9D5898530AM6PR07MB4053eurp_-- From nobody Wed Dec 18 07:26:44 2019 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 8DDB61207FE; Wed, 18 Dec 2019 07:26:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <157668280253.29987.10569390987199865996@ietfa.amsl.com> Date: Wed, 18 Dec 2019 07:26:42 -0800 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-7049bis-10.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, 18 Dec 2019 15:26:42 -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) Authors : Carsten Bormann Paul Hoffman Filename : draft-ietf-cbor-7049bis-10.txt Pages : 70 Date : 2019-12-18 Abstract: The Concise Binary Object Representation (CBOR) 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. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document is a revised edition of RFC 7049, with editorial improvements, added detail, and fixed errata. This revision formally obsoletes RFC 7049, while keeping full compatibility of the interchange format from RFC 7049. It does not create a new version of the format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-7049bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-7049bis-10 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-7049bis-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-7049bis-10 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 Dec 18 07:31:14 2019 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 965F2120807; Wed, 18 Dec 2019 07:31:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <157668307252.30016.293571515528793401@ietfa.amsl.com> Date: Wed, 18 Dec 2019 07:31:12 -0800 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-7049bis-11.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, 18 Dec 2019 15:31:13 -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) Authors : Carsten Bormann Paul Hoffman Filename : draft-ietf-cbor-7049bis-11.txt Pages : 70 Date : 2019-12-18 Abstract: The Concise Binary Object Representation (CBOR) 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. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document is a revised edition of RFC 7049, with editorial improvements, added detail, and fixed errata. This revision formally obsoletes RFC 7049, while keeping full compatibility of the interchange format from RFC 7049. It does not create a new version of the format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-7049bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-7049bis-11 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-7049bis-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-7049bis-11 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 Dec 18 07:37:59 2019 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 0754C120858; Wed, 18 Dec 2019 07:37:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <157668347794.30012.5669023249801426871@ietfa.amsl.com> Date: Wed, 18 Dec 2019 07:37:58 -0800 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-7049bis-12.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, 18 Dec 2019 15:37:58 -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) Authors : Carsten Bormann Paul Hoffman Filename : draft-ietf-cbor-7049bis-12.txt Pages : 69 Date : 2019-12-18 Abstract: The Concise Binary Object Representation (CBOR) 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. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document is a revised edition of RFC 7049, with editorial improvements, added detail, and fixed errata. This revision formally obsoletes RFC 7049, while keeping full compatibility of the interchange format from RFC 7049. It does not create a new version of the format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-7049bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-7049bis-12 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-7049bis-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-7049bis-12 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 Dec 18 07:49:53 2019 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 43F9C120834 for ; Wed, 18 Dec 2019 07:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 d0l1yidRgdT6 for ; Wed, 18 Dec 2019 07:49:50 -0800 (PST) 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 5C2DB12025D for ; Wed, 18 Dec 2019 07:49:50 -0800 (PST) Received: from [172.16.42.104] (p548DC893.dip0.t-ipconnect.de [84.141.200.147]) (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 47dKFn0Hp2zyf6; Wed, 18 Dec 2019 16:49:49 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 598376986.583028-51cb6bd2cfb8b114da6f725f736f2caf Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 18 Dec 2019 16:49:48 +0100 Message-Id: <920D0B30-16F7-4022-B21E-37CE55289785@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] Rapid version progression 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, 18 Dec 2019 15:49:52 -0000 I just submitted three versions of CBORbis: -10, -11, and -12. -10 is the roll-up of all the changes we have made so far based on the = WGLC comments (this is not saying we addressed them all, but see below). We have one pull request that implements switching from RFCXMLv2 to = RFCXMLv3. We need to do this at some point, because the RFC will be based on v3, = so I thought it would be best to do this now. Unfortunately, v3 = formatting has some gratuitous changes the bulk of which would obscure = changes to content. So -10 is the snapshot from before this switch. The biggest set of gratuitous changes are in the list symbols. So -11 = is a v2-formatted version that adopts (most of) those changes. There are some more changes in v3, which you can find in -12. All = three, -10, -11, -12 should be identical in content and just differ in = (non consequential, I hope) formatting. With -12, we should now be safely in v3 land, and we can return to = discussing content. Enjoy the new splendor of = https://www.ietf.org/id/draft-ietf-cbor-7049bis-12.html =E2=80=94 but = you still can get the htmlized text at = https://tools.ietf.org/html/draft-ietf-cbor-7049bis-12 if that helps. So: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-7049bis-10.txt has the rolled-up content changes. https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-7049bis-11.txt has the v3 list-symbol changes, only, which should definitely have no = effect on content. https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-7049bis-12.txt has the rest of the v3 formatting changes, also hopefully with no effect = on content, but that needs to be more carefully checked. I=E2=80=99m now merging these changes (#150), which should cover #140. https://github.com/cbor-wg/CBORbis/pull/150 https://github.com/cbor-wg/CBORbis/pull/140 Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Dec 18 07:54:01 2019 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 E3D97120813; Wed, 18 Dec 2019 07:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Z4UhrEB9xiX3; Wed, 18 Dec 2019 07:53:57 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150055.outbound.protection.outlook.com [40.107.15.55]) (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 B2AAE12025D; Wed, 18 Dec 2019 07:53:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S8bzA7Tmogoxkvpn8IF7DZtNM3WHQsSRrt7RbcveaEHY9ZuYwypN0nJIXpOOTaHw8H586zQ9PBxVWW6v0x/jEI4kOWjUFXYFRf3q86vYCtQ1b8LETJo+jFa9JEK6JpHfWZ+Q3gzuMERe77EXUTlGBGoCFlXnHzl7P33aEC5+g1nrbBm2Xfi7zZ/gUAN6tnghPF6ZraANJsHVHMZumDjodZqM6MABYYkd1JKy2cd7dyLmMmZFWXKOk2eJEWgjg3iDAPlBbgo1SIEwxbShVIsc/tBU7tatH5bN2HaqnRfr38jU5MnBfk389KOb813AwDIGD0DMuNSOFL9SwI3BEGQlIw== 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=zbkDu08bO8yiBCaRF3C0LbDYbxMB599UXg0FCZ2pYCM=; b=FAnRTWiHa2Hcg1cb0/3nDQ88X82qiWxTR1G9Sj7t6HU+bKF/Jsq0E3Sxctfb2o0VgZSIXKjKyIkzMlECatYD8itgX8BRlakE24V+XnWvTIWen/UlKS8JkOZVC16rW377IrTZK2R+Sk/+3OxrZITZicD9WxtjA8pd2BF7kJ7dyE4p01x/Ep2rVd7JNEWy1a9/L9MJRV3Y8JUYjhskCzSnj97z8cRUVIZyiSieUX+oJJBf+wzYwZ6OkAtCZQu6+j6Xq0g7fbCuNzbzOKMIKZ3cgHu22KNCiW5xcnsX5mE4HvLtYoVE9gU2YukzyOdaMhHJ6R2oAKWigzytVfAhpYOgSQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zbkDu08bO8yiBCaRF3C0LbDYbxMB599UXg0FCZ2pYCM=; b=mFwBM10LhuSE7QrUsHKLupaHNHgTTEIR4FtHqphiLs2uzQpta6Pp16IIjfskFIbhqxoSgP5ek2cyZQWt7eLV0eu9oBuUdDD51Xj6hgzQeOOqt00ZRnhrQ4rmrg3B2pKxMyKXfwAidv/twgRtknlVBIkhwkaYg/MOyFg5eoyePs0= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB4472.eurprd07.prod.outlook.com (20.176.242.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.13; Wed, 18 Dec 2019 15:53:54 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::8514:c0f:390b:277]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::8514:c0f:390b:277%6]) with mapi id 15.20.2559.012; Wed, 18 Dec 2019 15:53:54 +0000 From: Francesca Palombini To: "cbor@ietf.org" , "draft-ietf-cbor-7049bis@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: =?utf-8?B?8J+UlCBXR0xDIG9uIGRyYWZ0LWlldGYtY2Jvci03MDQ5YmlzLTA5?= Thread-Index: AQHVmtgHlP3xTHM9I0+UjjjMBCp1aqfAUb8A Date: Wed, 18 Dec 2019 15:53:53 +0000 Message-ID: References: <293AFF31-D0EF-45D6-9B9D-E8136481C404@ericsson.com> In-Reply-To: <293AFF31-D0EF-45D6-9B9D-E8136481C404@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [95.192.140.18] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 287e3a83-5173-4f88-50cd-08d783d27be1 x-ms-traffictypediagnostic: AM6PR07MB4472: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(39860400002)(136003)(376002)(396003)(199004)(189003)(76116006)(5660300002)(91956017)(71200400001)(6506007)(186003)(478600001)(26005)(2616005)(33656002)(6486002)(36756003)(81156014)(9326002)(8936002)(81166006)(66446008)(44832011)(86362001)(66476007)(450100002)(4326008)(110136005)(6512007)(2906002)(66946007)(66556008)(316002)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4472; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dDZC3rf4nSXaz24IdNxTTqOjqu2+97+6DVhKqIqkeKmFCWx2LtG/lsWV+GSYJVahDp1Bcx1JqfmLH8RO6QqDifSS/XygXQUHv/s1WQyyl7IFBhyAT7/y72UIfbBYGkkRLyRsIz9FusKZJZe//6S1Kyl3W7YUNN2xBYWC8DqiVOHew8uWTsOyy3hIcN6xJhkm48MWg+b+3cG34QLMIrPfHn1U1S1PdqP2ANjrZ5i1mQw7Ts6UVWMj8o6IIuYqCnWOBZkxrcsYvdfdQxjz1pio2knHNrLZzEeAw6qhO5WMjS3RyCk7w+TCwn5inlCp1OlRnLiICfzvC1KKIB3MdVaMRvKbVhD8jviSVRKFLi50aBIKr4y71eTHQsxk4iZWo6y7STYQWuV1Wmyu3fUktaeaiGaXP7htl3XK8xcIWuWPa/zNVV1kLz2EhiYL/Sm1MDRQ x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_A808010AAD614FEAA79F9AB669E38B6Aericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 287e3a83-5173-4f88-50cd-08d783d27be1 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2019 15:53:54.0329 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bsJ6uTG37xwwcEHYw9WAceleJjMiItnOOhIonDwHSJ2njgdtHKt3LBUWmtB188MR3Bc9Z9SBkib3bZmYg6da9m5PMPrTMI99czTHS4vjbaDPHvN9IukfuGeIbH5lJvfd X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4472 Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-7049bis-09?= 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, 18 Dec 2019 15:54:00 -0000 --_000_A808010AAD614FEAA79F9AB669E38B6Aericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldpdGggYSBzbWFsbCBkZWxheSwgSSBqdXN0IGZpbmlzaGVkIHJldmlld2luZyB0aGUg Q0JPUiBzcGVjaWZpY2F0aW9uIHYtMDksIHJlYWRpbmcgdG9wIHRvIGJvdHRvbS4gSW4gZ2VuZXJh bCwgSSBhbSBoYXBweSB3aXRoIHRoZSBkb2N1bWVudCwgYW5kIG9ubHkgaGF2ZSBtaW5vci9lZGl0 b3JpYWwgc3VnZ2VzdGlvbnMsIHBsdXMgc29tZSBxdWVzdGlvbnMgb24gZm9ybXVsYXRpb24uDQoN CkNhcnN0ZW4gYW5kIFBhdWwsIGZlZWwgZnJlZSB0byBsZXQgbWUga25vdyBpZiBhbnl0aGluZyB3 YXMgYWRkcmVzc2VkIGJ5IHJlY2VudCB1cGRhdGVzLg0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg0K LS0NClF1ZXN0aW9uczoNCg0KKiBTZWN0aW9uIDMuNC43DQoNCldoaWxlIHJlYWRpbmcgdGhpcyBh Z2FpbiwgSSByZWFsaXplZCB0aGF0IENCT1Igc2VxdWVuY2VzIGNhbm5vdCBiZSB0YWdnZWQsIGFz IGJ5IGRlZmluaXRpb24gdGhleSBhcmUgbm90IG9uZSBkYXRhIGl0ZW0uIEkgdGhpbmsgYmVpbmcg YWJsZSB0byB0YWcgQ0JPUiBzZXF1ZW5jZSB3aXRoIHRoZSBzZWxmLWRlc2NyaWJpbmcgdGFnIGlu IHRoZSBzY2VuYXJpbyBkZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uIHdvdWxkIGJlIGdvb2QuDQoN CiogU2VjdGlvbiA0LjIuMg0KDQpTZWNvbmQgdG8gbGFzdCBzdWItYnVsbGV0OiAiSWYgYSBwcm90 b2NvbCBpbmNsdWRlcyBhIGZpZWxkIHRoYXQgY2FuIGV4cHJlc3MgaW50ZWdlcnMuLi4iDQoNCkkg bm90ZWQgYW4gaW5jb25jaXN0ZW5jeSBoZXJlIHdpdGggdGhlIHRleHQgb24gcHJlZmVycmVkIGVu Y29kaW5nIHByZWZlcnJpbmcgdXNpbmcgbWFqIHR5cGVzIDAgYW5kIDEgKHNlZSB0ZXh0IGluIHNl Y3Rpb24gMy40LjQuICJUaGUgcHJlZmVycmVkIGVuY29kaW5nIG9mIGFuIGludGVnZXIuLi4iKQ0K DQoqIFNlY3Rpb24gOS41DQoNCkNvbnNpZGVyaW5nIHRoZSBBcHBzIEFyZWEgV29ya2luZyBHcm91 cCBkb2VzIG5vdCBleGlzdCBhbnltb3JlLCBzaG91bGQgdGhlIGNvbnRhY3QgaGVyZSBiZWluZyB1 cGRhdGVkPw0KDQoNCg0KTWlub3IvRWRpdG9yaWFscw0KDQoqIENvbnRyaWJ1dGluZw0KDQpJdCBt aWdodCBiZSBnb29kIHRvIHB1dCBpbiBhIG5vdGUgZm9yIHRoZSBSRkMgRWRpdG9yIHRvIHJlbW92 ZSB0aGlzIHNlY3Rpb24uDQoNCiogU2VjdGlvbiAxLjEsIFBvaW50IDIsIHN1Yi1idWxsZXQgMQ0K DQpGb3IgcmVhZGFiaWxpdHksIEkgd291bGQgcHV0IGFuIGV4YW1wbGUgb2YgInZlcnkgc21hbGwg YW1vdW50IG9mIGNvZGUiIG51bWJlciBkaXJlY3RseSBpbiB0aGUgdGV4dCwgaW4gdGhlIHBhcmVu dGhlc2lzIHdoZW4gbWVudGlvbmluZyBjbGFzcyAxIGNvbnN0cmFpbmVkIG5vZGVzLg0KDQoqIFNl Y3Rpb24gMS4xLCBQb2ludCA0LCBzdWItYnVsbGV0IDENCg0KImFuZCBieSBpbXBsZW1lbnRhdGlv biBjb21wbGV4aXR5IG1haW50aW5pbmcgYSBsb3dlciBib3VuZCIgZG9lcyBub3QgcmVhZCBjb3Jy ZWN0bHkgdG8gbWUuIEFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQoNCiogU2VjdGlvbiAxLjEsIFBv aW50IDUsIHN1Yi1idWxsZXQgMQ0KDQpJIHdvdWxkIHN1Z2dlc3QgdG8gYWRkICJmb3IgZXhhbXBs ZSBmb3IgZGV2aWNlcyBvZiBjbGFzcyAxIiBhcyBhbiBleGFtcGxlIG9mIHdoYXQgInJlYXNvbmFi bHkgZnJ1Z2FsIGluIENQVSIgbWVhbnMuDQoNCiogU2VjdGlvbiAxLjINCg0KVGhlIHRlcm0gInJl cHJlc2VudGF0aW9uIGZvcm1hdCIgaXMgb25seSB1c2VkIGluIHRoaXMgc2VjdGlvbiB0d2ljZSwg ZXZlcnl3aGVyZSBlbHNlICJlbmNvZGVkIGRhdGEgaXRlbSIgaXMgdXNlZC4gSSB3b3VsZCBnbyBh aGVhZCBhbmQgcmVtb3ZlIHRoaXMgZm9ybXVsYXRpb24sIGFuZCBvbmx5IHVzZSBlbmNvZGVkIGRh dGEgaXRlbS4gVGhpcyB3b3VsZCBhbHNvIG1ha2UgdGhlIHBhcnQgb24gZGVjb2RlciBhbmQgZW5j b2RlciBtb3JlIHN5bW1ldHJpYyAocmlnaHQgbm93IERlY29kZXIgdGFsa3MgYWJvdXQgImVuY29k ZWQgZGF0YSBpdGVtIiBhbmQgRW5jb2RlciB0YWxrcyBhYm91dCAicmVwcmVzZXRuYXRpb24gZm9y bWF0IikuDQoNCiogU2VjdGlvbiAxLjIsICJWYWxpZDogIg0KDQpUaGlzIHBhcmFncmFwaCB0YWxr cyBhYm91dCAic2VtYW50aWMgcmVzdHJpY3Rpb25zIHRoYXQgYXBwbHkgdG8gQ0JPUiBkYXRhIGl0 ZW1zIjsgaXQgd291bGQgYmUgZ29vZCB0byBhZGQgYSBoaW50IG9uIHdoZXJlIHRoZXNlIGFyZSBk ZWZpbmVkIGluIHRoZSBzcGVjaWZpY2F0aW9uLg0KDQoqIFNlY3Rpb24gMg0KDQoiQSBzaW1wbGUg dmFsdWUsIGlkZW50aWZpZWQgYnkgYSBudW1iZXIgYmV0d2VlbiAwIGFuZCAyNTUsIGJ1dCBkaXN0 aW5jdCBmcm9tIHRoYXQgbnVtYmVyIg0KDQpJIGhhZCB0byByZWFkIHRoaXMgc2VudGVuY2Ugc2V2 ZXJhbCB0aW1lcyB0byB1bmRlcnN0YW5kIHRoYXQgdGhlIHBhcnQgImJ1dCBkaXN0aW5jdCBmcm9t IHRoYXQgbnVtYmVyIiBpcyBtZWFudCB0byBub3RlIHRvIHRoZSByZWFkZXIgdGhhdCB0aGUgdmFs dWUgb2YgdGhlIGl0ZW0gaXMgbm90IHRoZSBudW1iZXIgaXQncyBpZGVudGlmaWVkIGJ5LiBJIHdv dWxkIGZvcm11bGF0ZSBhcyB3cml0dGVuIGhlcmUsIHJhdGhlciB0aGFuIGFzIGl0IGlzIG5vdy4g KCJOb3RlIHRoYXQgdGhlIHZhbHVlIG9mIHRoZSBpdGVtIGlzIG5vdCB0aGUgbnVtYmVyIGl0J3Mg aWRlbnRpZmllZCBieSIpDQoNCiogU2VjdGlvbiAzLjEsIE1ham9yIHR5cGUgNA0KDQpUaGUgdGV4 dCBzdGF0ZXMgdGhhdCBhcnJheXMgY2FuIGFsc28gYmUgY2FsbGVkIHNlcXVlbmNlcy4gV2l0aCB0 aGUgcHVibGljYXRpb24gb2YgQ0JPUiBTZXF1ZW5jZXMsIGNhbiB3ZSByZW1vdmUgdGhpcyBzdGF0 ZW1lbnQsIGFzIHNlcXVlbmNlcyBhcmUgKGFsdGhvdWdoIHJlbGF0ZWQpIGRpZmZlcmVudCB0aGlu Z3M/DQoNCiogU2VjdGlvbiAzLjEsIE1ham9yIHR5cGUgNQ0KDQpVc2luZyB1bmRlcnNjb3Jpbmcg dG8gaGlnaGxpZ2h0IGEgdGVybSAoaW4gdGhpcyBjYXNlICJwYWlycyIpIHNob3VsZCBiZSBleHBs YWluZWQgaW4gdGVybWlub2xvZ3kuDQoNCiogU2VjdGlvbiAzLjEsIE1ham9yIHR5cGUgNg0KDQpU byBiZSBjb25zaXN0ZW50IHdpdGggb3RoZXIgbWFqb3IgdHlwZXMsIGl0IG1pZ2h0IGJlIGdvb2Qg dG8gc2hvcnRseSBtZW50aW9uIHJhbmdlcyBmb3IgdGFncyBoZXJlLg0KDQoqIFNlY3Rpb24gMy4y DQoNCldoaWxlIHRoZSBtb3RpdmF0aW9uIGZvciBhcnJheXMgYW5kIG1hcHMgaXMgb2J2aW91cywg SSB3b3VsZCBoYXZlIGFwcHJlY2lhdGVkIHNvbWUgbW9yZSB0ZXh0IG9uIG1vdGl2YXRpb24gKG9y IGFuIGV4YW1wbGUgb2YgdXNlIGNhc2UpIHdoZXJlIGluZGVmaW5pdGUtbGVuZ3RoIHN0cmluZ3Mg YXJlIHVzZWZ1bC4NCg0KKiBTZWN0aW9uIDMuMi4zDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUg bGluayBiZXR3ZWVuIHRoZSBwcmV2aW91cyBzZW50ZW5jZSBhbmQgdGhpcyBvbmU6DQoNCiIgICBO b3RlIHRoYXQgdGhpcyBpbXBsaWVzIHRoYXQgdGhlIGJ5dGVzIG9mIGEgc2luZ2xlIFVURi04IGNo YXJhY3Rlcg0KICAgY2Fubm90IGJlIHNwcmVhZCBiZXR3ZWVuIGNodW5rczogYSBuZXcgY2h1bmsg Y2FuIG9ubHkgYmUgc3RhcnRlZCBhdCBhDQogICBjaGFyYWN0ZXIgYm91bmRhcnkuIg0KDQpOb3Ig YW0gSSBzdXJlIG9mIHRoZSBtZWFuaW5nIG9mIHRoZSB0ZXJtICJzcHJlYWQiIGhlcmUuDQoNCiog U2VjdGlvbiAzLjMNCg0KUmUtYXBwZWFyYW5jZSBvZiB0aGUgdGVybSAic2VxdWVuY2UiLCB3aGlj aCBJIHdvdWxkIHN0aWxsIGF2b2lkLg0KDQoqIFRhYmxlIDQNCg0KSSB3b3VsZCBoYXZlIGV4cGxp Y2l0ZWx5IHN0YXRlZCB3aGF0IGRhdGEgaXRlbXMgd2hlcmUgYWxsb3dlZCBmb3IgZWFjaCB0YWcg bnVtYmVyLCByYXRoZXIgdGhhbiB3cml0aW5nIG11bHRpcGxlLg0KDQoqIFNlY3Rpb24gMy40LjQN Cg0KVGhlIHRlcm0gInByZWZlcnJlZCBlbmNvZGluZyIgYXBwZWFycyBoZXJlIGZvciB0aGUgZmly c3QgdGltZSB3aXRob3V0IGFueSByZWZlcmVuY2Ugb3IgaW50cm9kdWN0aW9uLg0KDQoqIFNlY3Rp b24gMy40LjUNCg0KIndoaWxlIHRoZSBtYW50aXNzYSBhbHNvIGNhbiBiZSIgLT4gIndoaWxlIHRo ZSBtYW50aXNzYSBjYW4gYWxzbyBiZSINCg0KKiBTZWN0aW9uIDMuNC41DQoNCkV4cGFuZCBOYU4g b24gZmlyc3QgYXBwZWFyYW5jZSBoZXJlIChpbnN0ZWFkIG9mIDUuNi4xKQ0KDQoqIFNlY3Rpb24g NC4yLjINCg0KIm1heSB3YW50IHRvIGV4Y2x1ZGUgdGhlbSBmcm9tIGludGVyY2hhbmdlLCBpbnRl cmNoYW5naW5nIg0KDQpJIHdvdWxkIHJlZm9ybXVsYXRlIHRoaXMuDQoNCiogU2VjdGlvbiA0LjIu Mw0KDQpDYXBpdGFsaXplIHNlY3Rpb24gdGl0bGUNCg0KKiBTZWN0aW9uIDQuMi4zDQoNCkZpcnN0 IHBhcmFncmFwaDogcGxlYXNlIGFkZCBhIHJlZmVyZW5jZSB0byA0LjIuMSB3aGVuIHRhbGtpbmcg YWJvdXQgY29yZSBkZXRlcm1pbmlzdGljIGVuY29kaW5nIHJlcXVpcmVtZW50cy4NCg0KKiBTZWN0 aW9uIDUuNA0KDQoiQSBnZW5lcmljIGVuY29kZXIgYWxzbyBtYXkgd2FudCIgLT4gIkEgZ2VuZXJp YyBlbmNvZGVyIG1heSBhbHNvIHdhbnQiDQoNCiogU2VjdGlvbiA1LjYNCg0KIkR1cGxpY2F0ZSBr ZXlzIGFyZSBhbHNvIHByb2hpYml0ZWQgYnkgQ0JPUiBkZWNvZGVycyB0aGF0DQogICBlbmZvcmNl IHZhbGlkaXR5IChTZWN0aW9uIDUuNCkuIg0KDQpJIGhhdmUgYSBzbGlnaHQgcHJvYmxlbSB3aXRo IHRoZSB0ZXJtICJwcm9oaWJpdGVkIGJ5IiBkZWNvZGVycy4uLiBEZWNvZGVycyBkbyBub3QgcHJv aGliaXQsIGF0IG1vc3QgdGhleSBkbyBub3QgYWNjZXB0Lg0KDQoqIFNlY3Rpb24gNS42DQoNCiJl eGNlcHQgdG8gc3BlY2lmeSB0aGF0IHNvbWUsIG9yZGVycyBhcmUgZGlzYWxsb3dlZCIgLT4gcmVt b3ZlIGNvbW1hDQoNCiogU2VjdGlvbiA3LjEsIGxhc3Qgc3ViLWJ1bGxldA0KDQpQbGVhc2UgcmVm ZXJlbmNlIHNlY3Rpb24gNy4yLg0KDQoqIFNlY3Rpb24gOC4xDQoNCkkgbGlrZSBleGFtcGxlcy4g SSB3b3VsZCBoYXZlIGxpa2VkIGFuIGV4YW1wbGUgZm9yIHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9m IHRoaXMgc2VjdGlvbi4NCg0KKiBBcHBlbmRpeCBHDQoNCiJ0aGlzIG1heSBub3QgYmUgYWN0dWFs bHkgYmUgYW4gZXJyb3IiIC0+ICJ0aGlzIG1heSBub3QgYWN0dWFsbHkgYmUgYW4gZXJyb3IiDQoN Cg== --_000_A808010AAD614FEAA79F9AB669E38B6Aericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1 NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIGEgc21hbGwg ZGVsYXksIEkganVzdCBmaW5pc2hlZCByZXZpZXdpbmcgdGhlIENCT1Igc3BlY2lmaWNhdGlvbiB2 LTA5LCByZWFkaW5nIHRvcCB0byBib3R0b20uIEluIGdlbmVyYWwsIEkgYW0gaGFwcHkgd2l0aCB0 aGUgZG9jdW1lbnQsIGFuZCBvbmx5IGhhdmUgbWlub3IvZWRpdG9yaWFsIHN1Z2dlc3Rpb25zLCBw bHVzIHNvbWUgcXVlc3Rpb25zIG9uIGZvcm11bGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5DYXJzdGVuIGFuZCBQYXVsLCBmZWVsIGZyZWUgdG8gbGV0IG1lIGtub3cgaWYgYW55dGhpbmcg d2FzIGFkZHJlc3NlZCBieSByZWNlbnQgdXBkYXRlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzLDxicj4NCkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UXVlc3Rpb25zOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4qIFNlY3Rpb24gMy40Ljc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgcmVh ZGluZyB0aGlzIGFnYWluLCBJIHJlYWxpemVkIHRoYXQgQ0JPUiBzZXF1ZW5jZXMgY2Fubm90IGJl IHRhZ2dlZCwgYXMgYnkgZGVmaW5pdGlvbiB0aGV5IGFyZSBub3Qgb25lIGRhdGEgaXRlbS4gSSB0 aGluayBiZWluZyBhYmxlIHRvIHRhZyBDQk9SIHNlcXVlbmNlIHdpdGggdGhlIHNlbGYtZGVzY3Jp YmluZyB0YWcgaW4gdGhlIHNjZW5hcmlvIGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rpb24gd291bGQN CiBiZSBnb29kLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFNlY3Rpb24gNC4yLjI8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U2Vjb25kIHRvIGxhc3Qgc3ViLWJ1bGxldDogJnF1b3Q7SWYgYSBw cm90b2NvbCBpbmNsdWRlcyBhIGZpZWxkIHRoYXQgY2FuIGV4cHJlc3MgaW50ZWdlcnMuLi4mcXVv dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBub3RlZCBhbiBpbmNvbmNpc3RlbmN5IGhlcmUg d2l0aCB0aGUgdGV4dCBvbiBwcmVmZXJyZWQgZW5jb2RpbmcgcHJlZmVycmluZyB1c2luZyBtYWog dHlwZXMgMCBhbmQgMSAoc2VlIHRleHQgaW4gc2VjdGlvbiAzLjQuNC4gJnF1b3Q7VGhlIHByZWZl cnJlZCBlbmNvZGluZyBvZiBhbiBpbnRlZ2VyLi4uJnF1b3Q7KTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4qIFNlY3Rpb24gOS41PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbnNpZGVyaW5nIHRo ZSBBcHBzIEFyZWEgV29ya2luZyBHcm91cCBkb2VzIG5vdCBleGlzdCBhbnltb3JlLCBzaG91bGQg dGhlIGNvbnRhY3QgaGVyZSBiZWluZyB1cGRhdGVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlub3IvRWRpdG9yaWFsczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4qIENvbnRyaWJ1dGluZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBt aWdodCBiZSBnb29kIHRvIHB1dCBpbiBhIG5vdGUgZm9yIHRoZSBSRkMgRWRpdG9yIHRvIHJlbW92 ZSB0aGlzIHNlY3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogU2VjdGlvbiAxLjEsIFBv aW50IDIsIHN1Yi1idWxsZXQgMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgcmVhZGFiaWxp dHksIEkgd291bGQgcHV0IGFuIGV4YW1wbGUgb2YgJnF1b3Q7dmVyeSBzbWFsbCBhbW91bnQgb2Yg Y29kZSZxdW90OyBudW1iZXIgZGlyZWN0bHkgaW4gdGhlIHRleHQsIGluIHRoZSBwYXJlbnRoZXNp cyB3aGVuIG1lbnRpb25pbmcgY2xhc3MgMSBjb25zdHJhaW5lZCBub2Rlcy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+KiBTZWN0aW9uIDEuMSwgUG9pbnQgNCwgc3ViLWJ1bGxldCAxPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZxdW90O2FuZCBieSBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5IG1h aW50aW5pbmcgYSBsb3dlciBib3VuZCZxdW90OyBkb2VzIG5vdCByZWFkIGNvcnJlY3RseSB0byBt ZS4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBTZWN0 aW9uIDEuMSwgUG9pbnQgNSwgc3ViLWJ1bGxldCAxPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg d291bGQgc3VnZ2VzdCB0byBhZGQgJnF1b3Q7Zm9yIGV4YW1wbGUgZm9yIGRldmljZXMgb2YgY2xh c3MgMSZxdW90OyBhcyBhbiBleGFtcGxlIG9mIHdoYXQgJnF1b3Q7cmVhc29uYWJseSBmcnVnYWwg aW4gQ1BVJnF1b3Q7IG1lYW5zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFNlY3Rpb24gMS4y PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0ZXJtICZxdW90O3JlcHJlc2VudGF0aW9uIGZv cm1hdCZxdW90OyBpcyBvbmx5IHVzZWQgaW4gdGhpcyBzZWN0aW9uIHR3aWNlLCBldmVyeXdoZXJl IGVsc2UgJnF1b3Q7ZW5jb2RlZCBkYXRhIGl0ZW0mcXVvdDsgaXMgdXNlZC4gSSB3b3VsZCBnbyBh aGVhZCBhbmQgcmVtb3ZlIHRoaXMgZm9ybXVsYXRpb24sIGFuZCBvbmx5IHVzZSBlbmNvZGVkIGRh dGEgaXRlbS4gVGhpcyB3b3VsZCBhbHNvIG1ha2UgdGhlIHBhcnQgb24gZGVjb2RlciBhbmQNCiBl bmNvZGVyIG1vcmUgc3ltbWV0cmljIChyaWdodCBub3cgRGVjb2RlciB0YWxrcyBhYm91dCAmcXVv dDtlbmNvZGVkIGRhdGEgaXRlbSZxdW90OyBhbmQgRW5jb2RlciB0YWxrcyBhYm91dCAmcXVvdDty ZXByZXNldG5hdGlvbiBmb3JtYXQmcXVvdDspLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFNl Y3Rpb24gMS4yLCAmcXVvdDtWYWxpZDogJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo aXMgcGFyYWdyYXBoIHRhbGtzIGFib3V0ICZxdW90O3NlbWFudGljIHJlc3RyaWN0aW9ucyB0aGF0 IGFwcGx5IHRvIENCT1IgZGF0YSBpdGVtcyZxdW90OzsgaXQgd291bGQgYmUgZ29vZCB0byBhZGQg YSBoaW50IG9uIHdoZXJlIHRoZXNlIGFyZSBkZWZpbmVkIGluIHRoZSBzcGVjaWZpY2F0aW9uLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFNlY3Rpb24gMjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mcXVvdDtBIHNpbXBsZSB2YWx1ZSwgaWRlbnRpZmllZCBieSBhIG51bWJlciBiZXR3ZWVuIDAg YW5kIDI1NSwgYnV0IGRpc3RpbmN0IGZyb20gdGhhdCBudW1iZXImcXVvdDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBoYWQgdG8gcmVhZCB0aGlzIHNlbnRlbmNlIHNldmVyYWwgdGltZXMgdG8g dW5kZXJzdGFuZCB0aGF0IHRoZSBwYXJ0ICZxdW90O2J1dCBkaXN0aW5jdCBmcm9tIHRoYXQgbnVt YmVyJnF1b3Q7IGlzIG1lYW50IHRvIG5vdGUgdG8gdGhlIHJlYWRlciB0aGF0IHRoZSB2YWx1ZSBv ZiB0aGUgaXRlbSBpcyBub3QgdGhlIG51bWJlciBpdCdzIGlkZW50aWZpZWQgYnkuIEkgd291bGQg Zm9ybXVsYXRlIGFzIHdyaXR0ZW4gaGVyZSwgcmF0aGVyDQogdGhhbiBhcyBpdCBpcyBub3cuICgm cXVvdDtOb3RlIHRoYXQgdGhlIHZhbHVlIG9mIHRoZSBpdGVtIGlzIG5vdCB0aGUgbnVtYmVyIGl0 J3MgaWRlbnRpZmllZCBieSZxdW90Oyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBTZWN0aW9u IDMuMSwgTWFqb3IgdHlwZSA0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0ZXh0IHN0YXRl cyB0aGF0IGFycmF5cyBjYW4gYWxzbyBiZSBjYWxsZWQgc2VxdWVuY2VzLiBXaXRoIHRoZSBwdWJs aWNhdGlvbiBvZiBDQk9SIFNlcXVlbmNlcywgY2FuIHdlIHJlbW92ZSB0aGlzIHN0YXRlbWVudCwg YXMgc2VxdWVuY2VzIGFyZSAoYWx0aG91Z2ggcmVsYXRlZCkgZGlmZmVyZW50IHRoaW5ncz88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBTZWN0aW9uIDMuMSwgTWFqb3IgdHlwZSA1PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlVzaW5nIHVuZGVyc2NvcmluZyB0byBoaWdobGlnaHQgYSB0ZXJtIChp biB0aGlzIGNhc2UgJnF1b3Q7cGFpcnMmcXVvdDspIHNob3VsZCBiZSBleHBsYWluZWQgaW4gdGVy bWlub2xvZ3kuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogU2VjdGlvbiAzLjEsIE1ham9yIHR5 cGUgNjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBiZSBjb25zaXN0ZW50IHdpdGggb3RoZXIg bWFqb3IgdHlwZXMsIGl0IG1pZ2h0IGJlIGdvb2QgdG8gc2hvcnRseSBtZW50aW9uIHJhbmdlcyBm b3IgdGFncyBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFNlY3Rpb24gMy4yPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIHRoZSBtb3RpdmF0aW9uIGZvciBhcnJheXMgYW5kIG1h cHMgaXMgb2J2aW91cywgSSB3b3VsZCBoYXZlIGFwcHJlY2lhdGVkIHNvbWUgbW9yZSB0ZXh0IG9u IG1vdGl2YXRpb24gKG9yIGFuIGV4YW1wbGUgb2YgdXNlIGNhc2UpIHdoZXJlIGluZGVmaW5pdGUt bGVuZ3RoIHN0cmluZ3MgYXJlIHVzZWZ1bC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBTZWN0 aW9uIDMuMi4zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUg bGluayBiZXR3ZWVuIHRoZSBwcmV2aW91cyBzZW50ZW5jZSBhbmQgdGhpcyBvbmU6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZxdW90OyZuYnNwOyZuYnNwOyBOb3RlIHRoYXQgdGhpcyBpbXBsaWVz IHRoYXQgdGhlIGJ5dGVzIG9mIGEgc2luZ2xlIFVURi04IGNoYXJhY3RlcjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGNhbm5vdCBiZSBzcHJlYWQgYmV0 d2VlbiBjaHVua3M6IGEgbmV3IGNodW5rIGNhbiBvbmx5IGJlIHN0YXJ0ZWQgYXQgYTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGNoYXJhY3RlciBib3Vu ZGFyeS4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm9yIGFtIEkgc3VyZSBvZiB0aGUg bWVhbmluZyBvZiB0aGUgdGVybSAmcXVvdDtzcHJlYWQmcXVvdDsgaGVyZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+KiBTZWN0aW9uIDMuMzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZS1hcHBl YXJhbmNlIG9mIHRoZSB0ZXJtICZxdW90O3NlcXVlbmNlJnF1b3Q7LCB3aGljaCBJIHdvdWxkIHN0 aWxsIGF2b2lkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFRhYmxlIDQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSB3b3VsZCBoYXZlIGV4cGxpY2l0ZWx5IHN0YXRlZCB3aGF0IGRhdGEgaXRl bXMgd2hlcmUgYWxsb3dlZCBmb3IgZWFjaCB0YWcgbnVtYmVyLCByYXRoZXIgdGhhbiB3cml0aW5n IG11bHRpcGxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFNlY3Rpb24gMy40LjQ8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIHRlcm0gJnF1b3Q7cHJlZmVycmVkIGVuY29kaW5nJnF1b3Q7 IGFwcGVhcnMgaGVyZSBmb3IgdGhlIGZpcnN0IHRpbWUgd2l0aG91dCBhbnkgcmVmZXJlbmNlIG9y IGludHJvZHVjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBTZWN0aW9uIDMuNC41PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O3doaWxlIHRoZSBtYW50aXNzYSBhbHNvIGNhbiBi ZSZxdW90OyAtJmd0OyAmcXVvdDt3aGlsZSB0aGUgbWFudGlzc2EgY2FuIGFsc28gYmUmcXVvdDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBTZWN0aW9uIDMuNC41PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkV4cGFuZCBOYU4gb24gZmlyc3QgYXBwZWFyYW5jZSBoZXJlIChpbnN0ZWFkIG9mIDUu Ni4xKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFNlY3Rpb24gNC4yLjI8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+JnF1b3Q7bWF5IHdhbnQgdG8gZXhjbHVkZSB0aGVtIGZyb20gaW50ZXJjaGFu Z2UsIGludGVyY2hhbmdpbmcmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBy ZWZvcm11bGF0ZSB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFNlY3Rpb24gNC4yLjM8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FwaXRhbGl6ZSBzZWN0aW9uIHRpdGxlPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiogU2VjdGlvbiA0LjIuMzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5G aXJzdCBwYXJhZ3JhcGg6IHBsZWFzZSBhZGQgYSByZWZlcmVuY2UgdG8gNC4yLjEgd2hlbiB0YWxr aW5nIGFib3V0IGNvcmUgZGV0ZXJtaW5pc3RpYyBlbmNvZGluZyByZXF1aXJlbWVudHMuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiogU2VjdGlvbiA1LjQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ JnF1b3Q7QSBnZW5lcmljIGVuY29kZXIgYWxzbyBtYXkgd2FudCZxdW90OyAtJmd0OyAmcXVvdDtB IGdlbmVyaWMgZW5jb2RlciBtYXkgYWxzbyB3YW50JnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiogU2VjdGlvbiA1LjY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7RHVwbGljYXRl IGtleXMgYXJlIGFsc28gcHJvaGliaXRlZCBieSBDQk9SIGRlY29kZXJzIHRoYXQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBlbmZvcmNlIHZhbGlkaXR5 IChTZWN0aW9uIDUuNCkuJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBhIHNs aWdodCBwcm9ibGVtIHdpdGggdGhlIHRlcm0gJnF1b3Q7cHJvaGliaXRlZCBieSZxdW90OyBkZWNv ZGVycy4uLiBEZWNvZGVycyBkbyBub3QgcHJvaGliaXQsIGF0IG1vc3QgdGhleSBkbyBub3QgYWNj ZXB0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFNlY3Rpb24gNS42PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZxdW90O2V4Y2VwdCB0byBzcGVjaWZ5IHRoYXQgc29tZSwgb3JkZXJzIGFyZSBk aXNhbGxvd2VkJnF1b3Q7IC0mZ3Q7IHJlbW92ZSBjb21tYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4qIFNlY3Rpb24gNy4xLCBsYXN0IHN1Yi1idWxsZXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UGxlYXNlIHJlZmVyZW5jZSBzZWN0aW9uIDcuMi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBT ZWN0aW9uIDguMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGxpa2UgZXhhbXBsZXMuIEkgd291 bGQgaGF2ZSBsaWtlZCBhbiBleGFtcGxlIGZvciB0aGUgc2Vjb25kIHBhcmFncmFwaCBvZiB0aGlz IHNlY3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogQXBwZW5kaXggRzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mcXVvdDt0aGlzIG1heSBub3QgYmUgYWN0dWFsbHkgYmUgYW4gZXJyb3Im cXVvdDsgLSZndDsgJnF1b3Q7dGhpcyBtYXkgbm90IGFjdHVhbGx5IGJlIGFuIGVycm9yJnF1b3Q7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A808010AAD614FEAA79F9AB669E38B6Aericssoncom_-- From nobody Sat Dec 21 09:21:06 2019 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 0C43412002F for ; Sat, 21 Dec 2019 09:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 S_9sCTcfPBPf for ; Sat, 21 Dec 2019 09:21:03 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00073.outbound.protection.outlook.com [40.107.0.73]) (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 7BB95120019 for ; Sat, 21 Dec 2019 09:21:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dY/dRzAg5Pg0VP2brmiyCg5dDESGFtEPDH6LBbeaq90MxDtbu9IKPSaeHyzx+Ha/TYs1DLmMaYnqb0bgq+mVhmCZ+db3CN+PLPeHuAHu6Jkxs6/0qwZntS+cklie2G0t8bgRcSWRUZg1VepjEiBfwPJ/ymwJRA/3/Kk9+V7gxKEM5lZQEFMoftx+DaMyxWBXZMLBWWmNrliEtwLX+eYPPGmoWUlxcYZbzx15lSk/cGdwyqbVZ2FQc/5hE2divTRXHUqqEnqpnxDXOIAM5jM6/7HShLfxLIEBGv0uYsd6grSR7kI69UYgGvGeigmBWogGkYgsjoykGdz7zu9a/1QbVA== 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=xvH6ID1m8i+rkKc7aZukQ4FZPiRRsr8wWAbLFUe5Pck=; b=Z9PzpIfttjVnx8UQEKSPFngWY2gvbgeYOS8owVQSCpBQJlPBRS2NRhV0b+Iko9Fq4Yw+14E1ejyWO4z4TeveoUdNo/mRuwJTOknnNfKi9HCnGQ6X48vS8oZEwLiBithnS/Vjrr0VrOpvriEapGSz0GLvdv2oRFy53/vu6P5twD4cVW7VBW93yCFfQGU0rG2S1vgFzZKGNPzrGO66tF+d2E7J95qdYCM2Oaq8jfdSDoDbJ9WZHYVxr9Qzt50v7W3dwyc2bI90YIJ//qLxZbCPRVUCu7lgHqtc1PXxt17Ln2Cu8MIjGaxaaKqZu2cLtR8pPsuCGYqKQ3WL1olkNw988A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xvH6ID1m8i+rkKc7aZukQ4FZPiRRsr8wWAbLFUe5Pck=; b=sVW7lEO/6F0qReyB2k//9eb9JXGcM3avSI/LQnjCS3aqlMqVPkfUZb6n+/xRtmBI9sQJqPoLp7Zkh4rh7mbZ/63COTs98m1eGHCrkxK/l70sLZHqIlY+28ctrHg58fxjVeozGX+3ciLazPtqj79TfngDgrsZPqNyqXzrX/EGtDs= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB5174.eurprd07.prod.outlook.com (20.177.198.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.12; Sat, 21 Dec 2019 17:21:01 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::8514:c0f:390b:277]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::8514:c0f:390b:277%6]) with mapi id 15.20.2581.007; Sat, 21 Dec 2019 17:21:01 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: Minutes interim 2019-12-18 Thread-Index: AQHVuCMEGwTj8Dg99kiuLA0Tb9LpIg== Date: Sat, 21 Dec 2019 17:21:00 +0000 Message-ID: <43369E25-650B-4E00-8097-B56A3D7125C6@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [2.34.150.16] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eab8db3b-1e00-4158-bd21-08d7863a26c0 x-ms-traffictypediagnostic: AM6PR07MB5174: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(396003)(136003)(39860400002)(366004)(199004)(189003)(53754006)(81156014)(8676002)(44832011)(36756003)(2906002)(81166006)(6916009)(86362001)(71200400001)(966005)(8936002)(6486002)(316002)(2616005)(186003)(6512007)(33656002)(91956017)(26005)(66946007)(66446008)(76116006)(66556008)(4744005)(6506007)(5660300002)(66476007)(478600001)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5174; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nqA0hf5T81ddtNgLkDvZzEvioB+4mWVtqGXZnTtSX2/7uMVNyAaUUDpRU+iHvsnT05L9iqp/CDoPVzpT3SU/AzExryIZcuu1uRX+18wUU1TtNUK8nfCgyo8lFMP5eWu82WwBSD6CPuHC/xo3eDZJcQCydXrNIqsi/YQXmfK2FX13IqPSe1AzK5uBfY6oiscYdTyzstLjRwf+tuLRXZZ88Z3Oa4fdpl0JN//o8PRnXEHJLi9PuYp3FXziKsoVScWltzJ7v/kEZgogrnI3pQ1bu8dwhy0S814SwIrmXTGp1UZnezQlbDeAY+U74yT8gcdzmLoF9lCA01UzIQIsqIjx9lWZT/ldtwdZpm4QTB2dStMuQVrDX3/tg1WB0Mc4IFCPDdE5W46ErHVUcEx6m3ep4/FwdXNEJevtNyLNMHbTTspeUF4bQXLl/kuOexppBwYvUIvu9WaSJc6HebC6lGX/G8jYwLvz7Ag8b370NFodI0J7SDopHTQAuIKx/kTuDjM9yOXYNobYMXEO6AkIPNtVEcZOx5gl1XhYsZ6K6j6nFjc= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_43369E25650B4E008097B56A3D7125C6ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: eab8db3b-1e00-4158-bd21-08d7863a26c0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2019 17:21:01.1305 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0n/hWLhimGU/SHEu0CXmRZVHGyAzub1Mb/2/ZqwQ3IyE85czYONDTXk2m4qUBXmInUkdEbfcWmmLWx3ad3JNSUQ3OKfGbdS2KeeHNYldBSSTXhIFkqhP/5aNpH5+XAfR X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5174 Archived-At: Subject: [Cbor] Minutes interim 2019-12-18 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, 21 Dec 2019 17:21:06 -0000 --_000_43369E25650B4E008097B56A3D7125C6ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpNaW51dGVzIGZyb20gbGFzdCBtZWV0aW5nIGhhdmUgYmVlbiBwb3N0ZWQgaGVy ZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAxOS1jYm9y LTIwL21hdGVyaWFscy9taW51dGVzLWludGVyaW0tMjAxOS1jYm9yLTIwLTIwMTkxMjE4MTYwMC50 eHQNCg0KUmVjb3JkaW5ncyB3aWxsIGJlIHVwbG9hZGVkIHRvIHlvdXR1YmUgYW5kIHRoZSBtaW51 dGVzIHVwZGF0ZWQgYWNjb3JkaW5nbHksIGJ1dCBmb3Igbm93IHlvdSBjYW4gbGlzdGVuIHRvOiAg aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9yZWNvcmRpbmdzZXJ2aWNlL3NpdGVzL2lldGYvcmVjb3Jk aW5nL3BsYXliYWNrLzE4YWY1MjEwNDVkNTQzZmM4NmQ0MGRjM2I0MjZiOTRkDQoNClRoYW5rcyBh bmQgaGFwcHkgaG9saWRheXMhDQpGcmFuY2VzY2ENCg== --_000_43369E25650B4E008097B56A3D7125C6ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+TWludXRlcyBmcm9tIGxhc3QgbWVldGluZyBoYXZlIGJlZW4gcG9z dGVkIGhlcmU6DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9t ZWV0aW5nL2ludGVyaW0tMjAxOS1jYm9yLTIwL21hdGVyaWFscy9taW51dGVzLWludGVyaW0tMjAx OS1jYm9yLTIwLTIwMTkxMjE4MTYwMC50eHQiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv bWVldGluZy9pbnRlcmltLTIwMTktY2Jvci0yMC9tYXRlcmlhbHMvbWludXRlcy1pbnRlcmltLTIw MTktY2Jvci0yMC0yMDE5MTIxODE2MDAudHh0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5SZWNvcmRpbmdzIHdpbGwgYmUgdXBsb2FkZWQgdG8geW91dHViZSBhbmQgdGhl IG1pbnV0ZXMgdXBkYXRlZCBhY2NvcmRpbmdseSwgYnV0IGZvciBub3cgeW91IGNhbiBsaXN0ZW4g dG86Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL3JlY29yZGluZ3NlcnZp Y2Uvc2l0ZXMvaWV0Zi9yZWNvcmRpbmcvcGxheWJhY2svMThhZjUyMTA0NWQ1NDNmYzg2ZDQwZGMz YjQyNmI5NGQiPg0KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9yZWNvcmRpbmdzZXJ2aWNlL3NpdGVz L2lldGYvcmVjb3JkaW5nL3BsYXliYWNrLzE4YWY1MjEwNDVkNTQzZmM4NmQ0MGRjM2I0MjZiOTRk PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzIGFu ZCBoYXBweSBob2xpZGF5cyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJhbmNlc2NhPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_43369E25650B4E008097B56A3D7125C6ericssoncom_--