From nobody Sun Nov 3 08:45:41 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 A3D79120047 for ; Sun, 3 Nov 2019 08:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgODpRpJmM5t for ; Sun, 3 Nov 2019 08:45:35 -0800 (PST) Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9977120044 for ; Sun, 3 Nov 2019 08:45:35 -0800 (PST) Received: from [10.122.0.58] ([45.56.150.85]) by :SMTPAUTH: with ESMTPA id RJ0PiHLU3r3FgRJ0Qid1OJ; Sun, 03 Nov 2019 09:45:34 -0700 From: Laurence Lundblade Message-Id: <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AB45DAC2-3C57-4534-8595-68F9EF3AFDFE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 3 Nov 2019 08:45:33 -0800 In-Reply-To: Cc: cbor@ietf.org To: Christophe Lohr References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfN0zjrWB0HLsoiSX9glYyxtha7aBlSgwZ1EXFOj0AmrKR7p0X2grl0UkVXvLNn6kgd+OdBoYEDPfXDMx7cXGfMXynJQZmcVU238UQ7cs2iAtCTarL7FY ktaGQX2nwAXcvs/8PfMZ5i2diwxBlp2dTV31S1rdJTd7QP9rm/Tk/mu2x03bCK2K+FIGSo+aKEZ2aQXAxq/EueLpx0Kgck2KDRU= Archived-At: Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126 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, 03 Nov 2019 16:45:39 -0000 --Apple-Mail=_AB45DAC2-3C57-4534-8595-68F9EF3AFDFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m not really a data structure scientist or such, but I think I = can see Christophe=E2=80=99s point.=20 Maybe CBOR-based (and JSON-based) protocols don=E2=80=99t have a formal = schema language, but these protocols rely on ordering and such. For = example in a COSE_Sign1 it is expected that the first data item is the = protected headers, the second the unprotected headers, the third the = payload and the fourth the signature. I don=E2=80=99t think you can call = them self-describing. It seems like CBOR and JSON say =E2=80=9Cno schema=E2=80=99=E2=80=9D to = distance from the horror of XML schemas, but in reality CDDL and prose = protocol specs are schemas in spirit. Maybe a key question here is whether you can say in CDDL =E2=80=9Cthis = next item must always be interpreted as a date even though it will never = have a date tag=E2=80=9D. If CDDL doesn=E2=80=99t have than, then you = can=E2=80=99t describe some CBOR-protocols with it. CWT would be one of = those protocols as it forbids adding the tag to dates. To summarize what I understand about tagging: The designer of a new CBOR data item type like a date format will = generally register a tag for it. These new data types can be really = simple, like epoch dates or really complex like COSE_Sign1. The designer of a protocol using a new data type will indicate in their = protocol for each occurrence of it whether the tag must be present or = not (never saying the tag may or may not be present). The designer will = typically require the tag only when necessary to disambiguate the type = of the data item. The implementor of a general purpose library to generate one of these = new data item types must give the caller the option to include or not = include the tag. Maybe this is just by never automatically outputting = the tag and having a distinct output tag function. The implementor of a general purpose library to decode one of these new = data types must allow the caller to say that the next data item should = be decoded as this new data type whether or not it is tagged. Maybe it = even errors out if it is tagged for the cases where the protocol = document says no tag should be used. What I don=E2=80=99t know is whether CDDL can describe all this desired = behavior. LL > On Oct 24, 2019, at 1:50 AM, Christophe Lohr = wrote: >=20 > On 23/10/2019 13:38, Carsten Bormann wrote: >> Section 3.4 talks about "optional tagging" as a secondary purpose of = tags. But in today's CBOR protocols, tags are rarely "optional" in the = sense that they can simply be left out without a change in semantics, as = 3.4 para 3 implies. >>=20 >> This concept comes up again in 4.2.2, where "optional tagging" is = outlawed in deterministic encoding (but then the text goes on to explain = that protocols might choose to retain tags, but doesn't say why). >=20 > To be honest, I don't really understand how much optional are tags. >=20 > A CDD rule with tags matchs cbor items with tags and reject cbor items > without tags. Tags are not optional from the data-model point of view. >=20 >=20 > Moreover, please consider this CDDL objective: > (https://tools.ietf.org/html/rfc7049#section-1.1) >=20 > 3. Data must be able to be decoded without a schema description. > * Similar to JSON, encoded data should be self-describing so > that a generic decoder can be written. >=20 >=20 > Well, how to do this without putting tags everywhere for everything? > (Or I need more explanation about what is "self-describing" and what = is > a "schema description") >=20 > Let say I receive data. How may I know that this number is a = temperature > and not a distance, and that this byte-string is an uuid and not a = small > picture? >=20 > The first way is to have a schema (written or not): That is to say a > certain preliminary knowledge of expected data which tell me that this > number at this place or associated to this map-key is a temperature. > The second way is to decorate data with tags, all data. > A third way is a compromise between the two first ones: I have a = certain > level of preliminary knoledge of what data are (a kind of schema > description), with possibly some missing parts that are filled by = tags. >=20 > But the only way to decode data _without_ a schema description is to > have tags everywhere for everything. > Surprisingly, json has no tags and is claimed to be self-describing. = Is > it really? I'm lost. >=20 > My feeling is that this objective CBOR should be not so demanding. >=20 > Best regards, > Christophe >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_AB45DAC2-3C57-4534-8595-68F9EF3AFDFE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m not really a data structure scientist or such, but I think I can = see Christophe=E2=80=99s point. 

Maybe CBOR-based (and JSON-based) = protocols don=E2=80=99t have a formal schema language, but these = protocols rely on ordering and such. For example in a COSE_Sign1 it is = expected that the first data item is the protected headers, the second = the unprotected headers, the third the payload and the fourth the = signature. I don=E2=80=99t think you can call them = self-describing.

It seems like CBOR and JSON say =E2=80=9Cno schema=E2=80=99=E2=80= =9D to distance from the horror of XML schemas, but in reality CDDL and = prose protocol specs are schemas in spirit.

Maybe a key question here is whether = you can say in CDDL =E2=80=9Cthis next item must always be interpreted = as a date even though it will never have a date tag=E2=80=9D. If CDDL = doesn=E2=80=99t have than, then you can=E2=80=99t describe some = CBOR-protocols with it. CWT would be one of those protocols as it = forbids adding the tag to dates.

To summarize what I understand about = tagging:

The designer of a new CBOR data item type like a date format = will generally register a tag for it. These new data types can be really = simple, like epoch dates or really complex like COSE_Sign1.

The designer of a = protocol using a new data type will indicate in their protocol for each = occurrence of it whether the tag must be present or not (never saying = the tag may or may not be present). The designer will typically require = the tag only when necessary to disambiguate the type of the data = item.

The = implementor of a general purpose library to generate one of these new = data item types must give the caller the option to include or not = include the tag. Maybe this is just by never automatically outputting = the tag and having a distinct output tag function.

The implementor of a = general purpose library to decode one of these new data types must allow = the caller to say that the next data item should be decoded as this new = data type whether or not it is tagged. Maybe it even errors out if it is = tagged for the cases where the protocol document says no tag should be = used.

What I = don=E2=80=99t know is whether CDDL can describe all this desired = behavior.

LL




On Oct 24, 2019, at 1:50 AM, Christophe Lohr <christophe.lohr@imt-atlantique.fr> wrote:

On = 23/10/2019 13:38, Carsten Bormann wrote:
Section 3.4 talks about "optional tagging" as a = secondary purpose of tags. But in today's CBOR protocols, tags are = rarely "optional" in the sense that they can simply be left out without = a change in semantics, as 3.4 para 3 implies.

This concept comes up again in 4.2.2, where "optional = tagging" is outlawed in deterministic encoding (but then the text goes = on to explain that protocols might choose to retain tags, but doesn't = say why).

To be honest, I = don't really understand how much optional are tags.

A CDD rule with tags matchs cbor items with tags and reject = cbor items
without tags. Tags are not optional from the = data-model point of view.


Moreover, please consider this CDDL objective:
(https://tools.ietf.org/html/rfc7049#section-1.1)

   3.  Data must be able to be = decoded without a schema description.
       *  Similar to JSON, = encoded data should be self-describing so
          that a = generic decoder can be written.


Well, how to do this without putting tags everywhere for = everything?
(Or I need more explanation about what is = "self-describing" and what is
a "schema description")

Let say I receive data. How may I know that = this number is a temperature
and not a distance, and that = this byte-string is an uuid and not a small
picture?

The first way is to have a schema (written or = not): That is to say a
certain preliminary knowledge of = expected data which tell me that this
number at this place = or associated to this map-key is a temperature.
The second = way is to decorate data with tags, all data.
A third way = is a compromise between the two first ones: I have a certain
level of preliminary knoledge of what data are (a kind of = schema
description), with possibly some missing parts that = are filled by tags.

But the only way to = decode data _without_ a schema description is to
have tags = everywhere for everything.
Surprisingly, json has no tags = and is claimed to be self-describing. Is
it really? I'm = lost.

My feeling is that this objective = CBOR should be not so demanding.

Best = regards,
Christophe

_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor

= --Apple-Mail=_AB45DAC2-3C57-4534-8595-68F9EF3AFDFE-- From nobody Sun Nov 3 08:57:27 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 202F712008F for ; Sun, 3 Nov 2019 08:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 b8yRade2r4W4 for ; Sun, 3 Nov 2019 08:57:23 -0800 (PST) Received: from p3plsmtpa06-02.prod.phx3.secureserver.net (p3plsmtpa06-02.prod.phx3.secureserver.net [173.201.192.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CE0412004A for ; Sun, 3 Nov 2019 08:57:23 -0800 (PST) Received: from [10.122.0.58] ([45.56.150.85]) by :SMTPAUTH: with ESMTPA id RJBpiZe3M4y4cRJBqipfSr; Sun, 03 Nov 2019 09:57:22 -0700 From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_305F2178-37CD-4839-8EB2-C86BCED237DF" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <1F1C4AE2-25DB-455F-846C-A262A82A4A33@island-resort.com> Date: Sun, 3 Nov 2019 08:57:21 -0800 To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfIuHZdPxiSpcAYtxyK8lbyDmUHj57ehvAx3D9PcxQAhlqhoHGVmSoiRbQUSovulz1ODOGYFFzEDEPLNJh9lHDGrq6F90Jdd66/8vDZFa4AL9XuBeZgR9 TkgFLvljbsadkHkCElVFfo/w1y/iQIF/1Txadyo6rpz7/282f9U8ju7G Archived-At: Subject: [Cbor] Validity checking and tags X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 16:57:25 -0000 --Apple-Mail=_305F2178-37CD-4839-8EB2-C86BCED237DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Some CBOR protocols will require use of a tag to indicate a particular = data type (on a per instance basis) and others will explicitly prohibit = use of a tag (on a per instance basis). That implies that generic validity processing can only be performed on = data items that are explicitly tagged. For example generic processing = can=E2=80=99t check the internal structure of a decimal fraction for = validity unless it is tagged. It just won=E2=80=99t know that it is a = decimal fraction. I think we expect protocols using using these new / custom / registered = / bespoke data types to not require instances to be tagged, so validity = checking will be limited.=20 I think this is mostly OK, but wanted to point it out. (We refer to these new / custom / registered / bespoke data types = primarily as tagged, but then say the tag is not necessary; I think this = is confusing).=20 LL --Apple-Mail=_305F2178-37CD-4839-8EB2-C86BCED237DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Some CBOR protocols = will require use of a tag to indicate a particular data type (on a per = instance basis) and others will explicitly prohibit use of a tag (on a = per instance basis).

That implies that generic validity = processing can only be performed on data items that are explicitly = tagged. For example generic processing can=E2=80=99t check the internal = structure of a decimal fraction for validity unless it is tagged. It = just won=E2=80=99t know that it is a decimal fraction.

I think we expect = protocols using using these new / custom / registered / bespoke data = types to not require instances to be tagged, so validity checking will = be limited. 

I think this is mostly OK, but wanted to = point it out.

(We refer to these new / custom / registered / bespoke data = types primarily as tagged, but then say the tag is not necessary; I = think this is confusing). 

LL


= --Apple-Mail=_305F2178-37CD-4839-8EB2-C86BCED237DF-- From nobody Sun Nov 3 08:59: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 F33561200CC for ; Sun, 3 Nov 2019 08:59:46 -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 tKKuVmWSi00K for ; Sun, 3 Nov 2019 08:59:44 -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 462F712008F for ; Sun, 3 Nov 2019 08:59:44 -0800 (PST) Received: from [192.168.217.102] (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 475hxB1wNgzyfw; Sun, 3 Nov 2019 17:59:42 +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: <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> Date: Sun, 3 Nov 2019 17:59:41 +0100 Cc: Christophe Lohr , cbor@ietf.org X-Mao-Original-Outgoing-Id: 594493179.809954-6fcbf509bcbe4a2f3a262a3fa1536a55 Content-Transfer-Encoding: quoted-printable Message-Id: References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126 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, 03 Nov 2019 16:59:47 -0000 Hi Laurence, CDDL does not describe behavior, but the shape of data. > Maybe a key question here is whether you can say in CDDL =E2=80=9Cthis = next item must always be interpreted as a date even though it will never = have a date tag=E2=80=9D. CDDL can say =E2=80=9Cthis item is a number=E2=80=9D. It does not tell = you how to =E2=80=9Cinterpret=E2=80=9D things, that would be the job of = a language that transforms the data just received into data that is used = by an application. > If CDDL doesn=E2=80=99t have than, then you can=E2=80=99t describe = some CBOR-protocols with it. You sure can =E2=80=9Cdescribe=E2=80=9D the shape of data in CBOR = protocols, but you will also need some information about how you plan to = interpret the data. > CWT would be one of those protocols as it forbids adding the tag to = dates. (For the exp, nbf, and iat claims, or claim numbers 4 to 6:) Yes, the = CWT RFC (RFC 8392) tells you that the value here is a number, not a = tagged date. > The designer of a protocol using a new data type will indicate in = their protocol for each occurrence of it whether the tag must be present = or not (never saying the tag may or may not be present). The designer = will typically require the tag only when necessary to disambiguate the = type of the data item. Right. If you need to register for CWT a new claim that could either = take a number (such as the longitude of the satellite that this claim is = about) or a date/time (such as the time the satellite was launched), = then a tag could be useful to make that distinction. =20 That example is a bit contrived, because it=E2=80=99s just not as usual = to have a choice between a number and a date. More likely might be a = choice between a date/time represented as a Tag 1 and a Tag 1001. The = encoding could choose to leave off the tag from the number that is the = enclosed item of Tag 1, so you would have a choice between a number and = a Tag 1001. > The implementor of a general purpose library to generate one of these = new data item types must give the caller the option to include or not = include the tag. Maybe this is just by never automatically outputting = the tag and having a distinct output tag function. >=20 > The implementor of a general purpose library to decode one of these = new data types must allow the caller to say that the next data item = should be decoded as this new data type whether or not it is tagged. = Maybe it even errors out if it is tagged for the cases where the = protocol document says no tag should be used. Right. > What I don=E2=80=99t know is whether CDDL can describe all this = desired behavior. CDDL can describe the shape of the data interchanged, but it can=E2=80=99t= describe the mapping to application semantics. It can provide hints, = and that=E2=80=99s one of the things that the unwrap operator is good = for: When you apply it to a tag, this is a hint that you do not just = want the data shape of that tag=E2=80=99d enclosed item, but also its = semantics. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Nov 3 09:05: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 9B5A7120048 for ; Sun, 3 Nov 2019 09:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 lLFmoPqFh7GC for ; Sun, 3 Nov 2019 09:04:57 -0800 (PST) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 957DB120044 for ; Sun, 3 Nov 2019 09:04:55 -0800 (PST) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id xA3H4rsM015453 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Sun, 3 Nov 2019 18:04:54 +0100 Received: from [192.168.16.50] (79.234.112.245) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Sun, 3 Nov 2019 18:04:48 +0100 To: Laurence Lundblade , Christophe Lohr CC: References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> From: Henk Birkholz Message-ID: <88ea442d-8fc0-31fa-d00b-7e9c0c047323@sit.fraunhofer.de> Date: Sun, 3 Nov 2019 18:04:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.234.112.245] Archived-At: Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126 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, 03 Nov 2019 17:05:01 -0000 Hi Laurence, please see below. On 03.11.19 17:45, Laurence Lundblade wrote: > I’m not really a data structure scientist or such, but I think I can see > Christophe’s point > > Maybe CBOR-based (and JSON-based) protocols don’t have a formal schema > language, but these protocols rely on ordering and such. For example in > a COSE_Sign1 it is expected that the first data item is the protected > headers, the second the unprotected headers, the third the payload and > the fourth the signature. I don’t think you can call them self-describing. > > It seems like CBOR and JSON say “no schema’” to distance from the horror > of XML schemas, but in reality CDDL and prose protocol specs are schemas > in spirit. > > Maybe a key question here is whether you can say in CDDL “this next item > must always be interpreted as a date even though it will never have a > date tag”. I would not use the term "interpretation" here. CDDL is a language, it in unambiguous in that regard. But I think it can do exactly what you mean :-) It describes the structure of CBOR/JSON messages/documents - if it precise enough, CBOR tags are not needed, but to ensure that precision you need a dedicated authority, I think. If CDDL doesn’t have than, then you can’t describe some > CBOR-protocols with it. CWT would be one of those protocols as it > forbids adding the tag to dates. > > To summarize what I understand about tagging: > > The designer of a new CBOR data item type like a date format will > generally register a tag for it. These new data types can be really > simple, like epoch dates or really complex like COSE_Sign1. > > The designer of a protocol using a new data type will indicate in > their protocol for each occurrence of it whether the tag must be > present or not (never saying the tag may or may not be present). The > designer will typically require the tag only when necessary to > disambiguate the type of the data item. > > The implementor of a general purpose library to generate one of > these new data item types must give the caller the option to include > or not include the tag. Maybe this is just by never automatically > outputting the tag and having a distinct output tag function. > > The implementor of a general purpose library to decode one of these > new data types must allow the caller to say that the next data item > should be decoded as this new data type whether or not it is tagged. > Maybe it even errors out if it is tagged for the cases where the > protocol document says no tag should be used. > > What I don’t know is whether CDDL can describe all this desired behavior. > > LL > > > > >> On Oct 24, 2019, at 1:50 AM, Christophe Lohr >> > > wrote: >> >> On 23/10/2019 13:38, Carsten Bormann wrote: >>> Section 3.4 talks about "optional tagging" as a secondary purpose of >>> tags. But in today's CBOR protocols, tags are rarely "optional" in >>> the sense that they can simply be left out without a change in >>> semantics, as 3.4 para 3 implies. >>> >>> This concept comes up again in 4.2.2, where "optional tagging" is >>> outlawed in deterministic encoding (but then the text goes on to >>> explain that protocols might choose to retain tags, but doesn't say why). >> >> To be honest, I don't really understand how much optional are tags. >> >> A CDD rule with tags matchs cbor items with tags and reject cbor items >> without tags. Tags are not optional from the data-model point of view. >> >> >> Moreover, please consider this CDDL objective: >> (https://tools.ietf.org/html/rfc7049#section-1.1) >> >>    3.  Data must be able to be decoded without a schema description. >>        *  Similar to JSON, encoded data should be self-describing so >>           that a generic decoder can be written. >> >> >> Well, how to do this without putting tags everywhere for everything? >> (Or I need more explanation about what is "self-describing" and what is >> a "schema description") >> >> Let say I receive data. How may I know that this number is a temperature >> and not a distance, and that this byte-string is an uuid and not a small >> picture? >> >> The first way is to have a schema (written or not): That is to say a >> certain preliminary knowledge of expected data which tell me that this >> number at this place or associated to this map-key is a temperature. >> The second way is to decorate data with tags, all data. >> A third way is a compromise between the two first ones: I have a certain >> level of preliminary knoledge of what data are (a kind of schema >> description), with possibly some missing parts that are filled by tags. >> >> But the only way to decode data _without_ a schema description is to >> have tags everywhere for everything. >> Surprisingly, json has no tags and is claimed to be self-describing. Is >> it really? I'm lost. >> >> My feeling is that this objective CBOR should be not so demanding. >> >> Best regards, >> Christophe >> >> _______________________________________________ >> 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 > From nobody Sun Nov 3 09:18:17 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 59ACF12004A for ; Sun, 3 Nov 2019 09:18:15 -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 jeBFTuf0wvsn for ; Sun, 3 Nov 2019 09:18:12 -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 7F5F1120018 for ; Sun, 3 Nov 2019 09:18:12 -0800 (PST) Received: from [192.168.217.102] (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 475jLV66kmzyfs; Sun, 3 Nov 2019 18:18:10 +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: <1F1C4AE2-25DB-455F-846C-A262A82A4A33@island-resort.com> Date: Sun, 3 Nov 2019 18:18:10 +0100 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 594494288.505784-825dd31063ae7234f28bad8484d01b82 Content-Transfer-Encoding: quoted-printable Message-Id: <89CDD13F-26C9-41B4-97B9-6182ECBC4465@tzi.org> References: <1F1C4AE2-25DB-455F-846C-A262A82A4A33@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Validity checking and tags X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 17:18:15 -0000 > Some CBOR protocols will require use of a tag to indicate a particular = data type (on a per instance basis) and others will explicitly prohibit = use of a tag (on a per instance basis). Normally, you don=E2=80=99t =E2=80=9Cprohibit a tag=E2=80=9D, you say = what you want. =E2=80=9CThis is a number.=E2=80=9D As in (RFC 8392 in one slide): cwt =3D { ? iss =3D> text ? sub =3D> text ? aud =3D> text ? exp =3D> ~time ? nbf =3D> ~time ? iat =3D> ~time ? cti =3D> bytes * int =3D> any } iss =3D 1 sub =3D 2 aud =3D 3 exp =3D 4 nbf =3D 5 iat =3D 6 cti =3D 7 ~time is a number (with a strong hint that this number is meant to be = interpreted as similar to how the enclosed data item of a tag with = number 1 would be, i.e. as an epoch-based time). Note that the prelude says: time =3D #6.1(number) number =3D int / float So the three lines ? exp =3D> number ? nbf =3D> number ? iat =3D> number in the above would have meant exactly the same, but without the little = hint about interpretation. > That implies that generic validity processing can only be performed on = data items that are explicitly tagged. For example generic processing = can=E2=80=99t check the internal structure of a decimal fraction for = validity unless it is tagged. It just won=E2=80=99t know that it is a = decimal fraction. Generic validity processing sees an array and sees that this is valid = (from a generic validity processing point of view). Indeed, it won=E2=80=99= t know that the application intends to process this as a decimal = fraction. > I think we expect protocols using using these new / custom / = registered / bespoke data types to not require instances to be tagged, = so validity checking will be limited.=20 The checking cannot be done as =E2=80=9Ctag validity=E2=80=9D, but it = needs to be done in the application. > I think this is mostly OK, but wanted to point it out. I think so, too. > (We refer to these new / custom / registered / bespoke data types = primarily as tagged, but then say the tag is not necessary; I think this = is confusing).=20 The short form is: A CBOR-based protocol can make use of a tag = definition in an interesting way: not by shaping the data as the tag = that has been defined, but by shaping the data as what would have been = the enclosed data item of the tag, and then saying with that (in prose, = at this point) that the data item is to be processed as if it where that = enclosed data item of the tag. That is a useful device to reduce the = amount of variation between different protocols. Providing direct = support for this from a CBOR decoder implementation would be an = interesting addition (it would become a schema-informed CBOR decoder = then, of course). All this discussion may be somewhat clouded by the fact that RFC 7049 = speaks about =E2=80=9Coptional tags=E2=80=9D; these have never turned = out to be particularly useful, so we should no longer talk about those = when writing up 7049bis. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Nov 3 12:41: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 6BCA0120073 for ; Sun, 3 Nov 2019 12:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=imt-atlantique.fr 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 dFVwc6EBpg55 for ; Sun, 3 Nov 2019 12:41:42 -0800 (PST) Received: from zproxy110.enst.fr (zproxy110.enst.fr [IPv6:2001:660:330f:2::c0]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668E712002E for ; Sun, 3 Nov 2019 12:41:42 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id B032E81360 for ; Sun, 3 Nov 2019 21:41:40 +0100 (CET) Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id exssrNXDt_FO for ; Sun, 3 Nov 2019 21:41:40 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 44A9B8137C for ; Sun, 3 Nov 2019 21:41:40 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr 44A9B8137C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1572813700; bh=X68noN6GxAo7Zbt+MvNamy6oS0EkN+vxCwxT3iCdjio=; h=To:From:Message-ID:Date:MIME-Version; b=QvBomA9HNYasGtxE2KkhS600lvbdW/wEz0Ki1/v7caOoaztbBh9seeYX+vzWYPUac GPiZORRVWDEKgAjZBBLk1CpH8YA5xTw0rrmRETQ1bo5+pCm1uieCdwrLok4id5TiCm m/KrbaCt06qXNxYAbQpLva8si+4GQ5KIeY0ga4vg= X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id HRwztPTVZlbI for ; Sun, 3 Nov 2019 21:41:40 +0100 (CET) Received: from [192.168.1.4] (157.68.93.79.rev.sfr.net [79.93.68.157]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 0D58181360 for ; Sun, 3 Nov 2019 21:41:39 +0100 (CET) References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> To: cbor@ietf.org From: Christophe Lohr Openpgp: preference=signencrypt Autocrypt: addr=christophe.lohr@imt-atlantique.fr; prefer-encrypt=mutual; keydata= mQINBFidiI4BEAC/zpewWjK9zQSDxb5ue3RvpVE3GJJZHZtCTnUpUnlMs2cKE5ZFwgYnMGr6 hFZFubcZcg2iTWCAcGcaqGHufFlv1+T/zw6tN0XUEnJRDAdqPeefjrRzf264efp/2kfftJkU rWS7cPPOYjSbsB+TMjDL13+lGAh3wceo8kXrCRSEKnzCGKcwrgNNIWwISqD/+1/2rppCEE55 Mx7Gh/NtLDhrhrlSJe5UhRa5PHG17FyFwnpP+Mplqy5AGjt2cEdooQBqOJR8k0UksYmSw2uU 2zP779xr9Jh9zjwZxXFia6Q7ZmOMnMjMWG225iVPphye5TS1s/1LTOXZYUWFY8RCuVxR2YHg C0qsd5lC0Hei/WODt0Lx0T4DgHXEe6zqg1X4PKCqWW7DaPUMy1v1yfu8K1T7ySUSxNan8XuA om15iYqJHjHLBuMxq3TKAOoHaWecdP7tAK58WVncsWb4vQZGweSQRsr/CBgRmsZM4UcT0Kkr t0rOAfpW9t4vz3dqn80MwRu9UGVnc2fLgC0Ml+ymsBFnDZjYTg/4vAas7E9V2E7uVfOXB9Mr PwB4u3+VdKgI2qRYEUUbvmrw9sYX/we4eh3qUtXcSXuvhu4ukDrjFKMGgZXccgXbsevzi24o j3IopUdrY0OrsMXhqHlMwrw4iq5aZujxP0T1CzVW6qAIZD9HewARAQABtEJDaHJpc3RvcGhl IExvaHIgKFdvcmsgYWRkcmVzcykgPGNocmlzdG9waGUubG9ockBpbXQtYXRsYW50aXF1ZS5m cj6JAk4EEwEIADgWIQRBlpOqI8ZwLZqLQzc/4GWuK29VCgUCWJ2IjgIbAwULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRA/4GWuK29VCnAaD/wIwRul4rfN5g9PPX5o89JtXKJHbdl/Ql8W +td240unsleBaJkqZTcnARmk+enYB5d54taM6e+Sodsjskt1P4mwX1AVR2/F/woeqEZxMMKQ xAQHFP+IInYsJHFw8qYO33Dc+Xlf6FGXMHGsPDoPbpWIZLMJbh20K9VeeEMuOBuTGnZHJhDy SyBnkgF3z4m37VVZKIC4CMbpswEqSPrI+U7Bmcr4LseqRN/6P3ivAHvF3hTy2cpAvLfbBQSm E91CdRzzZ5rvYnk3SsiBZ75IelYmaCqpDSPuzJSMAePiI3SvdoVWl4Hl81y0lGfFeMkx+xxk 01YJUFAjIllOW0xVueODuXT70XI+xkds1QIuSG8IO/AaDk7zrB+5LpPTF+vrdd07yTyk6gUD ZJqWI56Nhvkq+ORskWnPDOHy6Zd1Ov4ke3bVxuGn0Y/Vzkdp7U2SqJEb82OkGAWw4IS9NbWm IlKKxsGJSsnlq7HxX0m/5+DTHnlCjdI/iyXxUOwp15Wc7M7xOwg+34ME1uUJ9lOsqxVUopYG e2rbJK+LNzRUHx+aDSE3LYSEd481h6lelqJ9bE1Dri2Um/YHZK8DoVvrMV7+FdfjX75ooaV+ XDa4rc6M0lIz20yPBB2kWC2qAObelRNK28pUWMfc4fS238pIjYqlhassImksSEVWq52ypryi l7kCDQRYnYiOARAAwdGm1tsrDtx8nn5ykcld8fYM4LRPRrwekDi7GYuJZq2rQvVccMpmb9v8 nlloYEDAf7nnqlH7nHEmZP+j6w0oxkUp/leKGeGddEiLsKY+BcmgricktNxdsoIryDLpmI+j qjGw5UtEBDO8+iBDi+Nu78SSa9UKEfxw+KUhPWWUiHSKEO4+wov0B5dswTtVGACtbjwTFVVr LHCXP0O4nmlRgh89y7rEFIReOMLQUxzHttMsEe7qlZuX49jYtAabAaFmmh96BoepQY1Gq1+M ShD9PTUb2dKpNBwWbM94gHIkYYHcChPsAbj1D3Xgxx2U+55+49zUClJ6AXxNZQGtPvhYsYm+ Fde2REQh7zcefjTq2FvXIXyUiRyYL2nR3oQTzdsuoY81zBokETt7hVeRa/vHblLIx25mFrqF ccjKvE4NmMzYTh7oUJWPWGB/o6WxGlDG01hz6Kv+fCxRReW1nbMOxe7FjCTTuzxF9Y9pueE8 MOKMTXR1Z1dnznOyTfqkKEYKejPpD3nZPhNUrnxkiccjKI1RRyWqz9mXCZWw/NdWOscGorNL +KAyFpNRFXelgIsPcmSBrZq3Z6+QBYEgm92qo5/dnvf/vwZBXdeiNuhkz0iyDiFsMWIyiJ/b bZBmbnNTbSHmbS0ObbuO3duWCs/m3wKiDjACAdG7HXNsFFL2L1sAEQEAAYkCNgQYAQgAIBYh BEGWk6ojxnAtmotDNz/gZa4rb1UKBQJYnYiOAhsMAAoJED/gZa4rb1UKpO4P/RqIjeePf4o9 rcT93UfSPgg+dlJjv1OgCYkURrXHB80h3PKEO9YDCcW6b0Zmzr048eNNGk54d5pflqZClIte IjgV6OcsGrSydickN9rRmXhRbwqcEhLasjJaSyIFwxmadc7aBuiFSJyuvHU4OPBZIx3eArb5 e+vNeNkP14p0yrWUeQ608xn8WgReDyIxwmnMkxoZkwlj9O2+zCyyLo6jKtVCfn4LZpwcwUP9 awQeQqU7WYckzm4fO+2JxmZ0zhIjia3ROdrw00H3V8KbDWcKTL7IWDqoLF/afDRQTMkrDmmY LF6Pgk5Lg/uUo3CBv8EzJXscZ2w6Ttzv0o5lECHMpQvmeitW56/rfQMIZTXhOxrhzi5jXWRz t0M54F9PVmyOX9a5qrlyU28mi1Mgs+uvmjXMFEwg+h8lCrayeOR1nwPMr4FgoHsHU6JyUVxv pIgBF5Q8HpPZuQUEaEz5Bl3uEI3ofI616dCmh42GCHOFvc8bIORwLYaNTs0zGEc4bLVe9cGf i7uJTfshDnL4aKGLbNebV7mUJ1TNEQ8Syx5fWpt/92XECtE9ovSQHCXabTNzGb63Z5HtqOUA TTNmm76rXBSrlvtPv548cMXw4dejA09u1tCFNEyuHzOgT2ZJzEkUY96iNf5ZC+qyOcttgQWV ejdE1EpSVxnHMn0oG8z+dXZZ Message-ID: <06592ab7-f3cb-1a59-1b32-ffba3194162c@imt-atlantique.fr> Date: Sun, 3 Nov 2019 21:40:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: fr Archived-At: Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126 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, 03 Nov 2019 20:41:46 -0000 >> =C2=A0=C2=A0 3.=C2=A0 Data must be able to be decoded without a schema= description. >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 Similar to JSON, encoded = data should be self-describing so >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that a generic = decoder can be written. My confusion comes probably from vocabulary issues. The sentence here probably talks about "a schema description" from the /coding-decoding/ point of view, and nothing else. Such as, let's say, the IP header: without the RFC in hands (its description), there is no way to decode a set of 20 bytes and to guess that the first 4 bits are an unsigned int, followed by another 4 bits unsigned int, followed by an array of 8 booleans, etc.=C2=A0 A CBOR (or a JSON) coding format can tell this, without the need of another writing document to specify this. However, I read "schema description" from the /semantic/ point of view: a description which explains the meaning of data items.=C2=A0 The IP RFC = not only tells that the first 4bits are an unsigned int, it also tells that this number is the protocol version.=C2=A0 CBOR (neither JSON) can't tells this by itself, except if one defines a TAG for this. So, the next question is: "is there some guidelines for using TAGs?" Well, it's probably too early. One may have to wait that CBOR usages grow in maturity. But what's your opinion? Let's say I'm designing a system.=C2=A0 CBOR is used (for messages, recor= ding data files, or whatever). What should I decide for my system design regarding CBOR TAGs? Shall I: - prohibit TAGs since this is redundant with other parts of my design specifications (which already explicit the meaning of each field); or - put TAGs everywhere for everything because TAGs bring semantic to data;= or - add TAGs to some fields and not to others (which ones and why?) The right answer is probably: "this depends". ;-) but of what? Best regards Christophe From nobody Sun Nov 3 13:02: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 E876E1200CE for ; Sun, 3 Nov 2019 13:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHltrcGk0w3c for ; Sun, 3 Nov 2019 13:02:17 -0800 (PST) Received: from p3plsmtpa08-06.prod.phx3.secureserver.net (p3plsmtpa08-06.prod.phx3.secureserver.net [173.201.193.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6D31200C1 for ; Sun, 3 Nov 2019 13:02:17 -0800 (PST) Received: from [10.122.0.22] ([45.56.150.85]) by :SMTPAUTH: with ESMTPA id RN0qiNlpIksi3RN0qi1Hpi; Sun, 03 Nov 2019 14:02:17 -0700 From: Laurence Lundblade Message-Id: <8B119642-7D8D-4BEF-AD75-0AC9935BCD7C@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4772C1B3-3AC1-43A3-AE80-A83692423BB4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 3 Nov 2019 13:02:16 -0800 In-Reply-To: Cc: Christophe Lohr , cbor@ietf.org To: Carsten Bormann References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfBGFX0Nw9F0SAlY0QQlz97h469bxm2/93oHJn4mMUl5lBUsqByuuIdB2mqsKEPcpLA9eNzet1HpolKuM1FSkWmKTZQIZINDIi4qSyDrYL6g/j2KSX9V1 B2PnCH4/gJfSWp80qca5swhhT7U//8XgkikoDorfe7d72bVoee2d+8/iM/JmqbgnBBhHh0nSuj2E8unKDL5XTIhU8PKi0wbpZJ8xMendHww5nrYmQrQA6WEj Archived-At: Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126 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, 03 Nov 2019 21:02:20 -0000 --Apple-Mail=_4772C1B3-3AC1-43A3-AE80-A83692423BB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK. I understand. To use it one of these new types in CDDL, = particularly those with a internal structure, you make a pair of CDDL = headers, one for tagged and one for untagged that describe it like COSE = did (from 8152): COSE_Messages =3D COSE_Untagged_Message / COSE_Tagged_Message COSE_Untagged_Message =3D COSE_Sign / COSE_Sign1 / COSE_Encrypt / COSE_Encrypt0 / COSE_Mac / COSE_Mac0 COSE_Tagged_Message =3D COSE_Sign_Tagged / COSE_Sign1_Tagged / COSE_Encrypt_Tagged / COSE_Encrypt0_Tagged / COSE_Mac_Tagged / COSE_Mac0_Tagged ... COSE_Sign1_Tagged =3D #6.18(COSE_Sign1) COSE_Sign1 =3D [ Headers, payload : bstr / nil, signature : bstr ] Would be cool if there were standard CDDL definitions ready for = normative reference for all the =E2=80=9Ctagged=E2=80=9D data types = defined in 7049 / 7049bis. LL > On Nov 3, 2019, at 8:59 AM, Carsten Bormann wrote: >=20 > Hi Laurence, >=20 > CDDL does not describe behavior, but the shape of data. >=20 >> Maybe a key question here is whether you can say in CDDL =E2=80=9Cthis = next item must always be interpreted as a date even though it will never = have a date tag=E2=80=9D. >=20 > CDDL can say =E2=80=9Cthis item is a number=E2=80=9D. It does not = tell you how to =E2=80=9Cinterpret=E2=80=9D things, that would be the = job of a language that transforms the data just received into data that = is used by an application. >=20 >> If CDDL doesn=E2=80=99t have than, then you can=E2=80=99t describe = some CBOR-protocols with it. >=20 > You sure can =E2=80=9Cdescribe=E2=80=9D the shape of data in CBOR = protocols, but you will also need some information about how you plan to = interpret the data. >=20 >> CWT would be one of those protocols as it forbids adding the tag to = dates. >=20 > (For the exp, nbf, and iat claims, or claim numbers 4 to 6:) Yes, the = CWT RFC (RFC 8392) tells you that the value here is a number, not a = tagged date. >=20 >> The designer of a protocol using a new data type will indicate in = their protocol for each occurrence of it whether the tag must be present = or not (never saying the tag may or may not be present). The designer = will typically require the tag only when necessary to disambiguate the = type of the data item. >=20 > Right. If you need to register for CWT a new claim that could either = take a number (such as the longitude of the satellite that this claim is = about) or a date/time (such as the time the satellite was launched), = then a tag could be useful to make that distinction. =20 >=20 > That example is a bit contrived, because it=E2=80=99s just not as = usual to have a choice between a number and a date. More likely might = be a choice between a date/time represented as a Tag 1 and a Tag 1001. = The encoding could choose to leave off the tag from the number that is = the enclosed item of Tag 1, so you would have a choice between a number = and a Tag 1001. >=20 >> The implementor of a general purpose library to generate one of these = new data item types must give the caller the option to include or not = include the tag. Maybe this is just by never automatically outputting = the tag and having a distinct output tag function. >>=20 >> The implementor of a general purpose library to decode one of these = new data types must allow the caller to say that the next data item = should be decoded as this new data type whether or not it is tagged. = Maybe it even errors out if it is tagged for the cases where the = protocol document says no tag should be used. >=20 > Right. >=20 >> What I don=E2=80=99t know is whether CDDL can describe all this = desired behavior. >=20 > CDDL can describe the shape of the data interchanged, but it can=E2=80=99= t describe the mapping to application semantics. It can provide hints, = and that=E2=80=99s one of the things that the unwrap operator is good = for: When you apply it to a tag, this is a hint that you do not just = want the data shape of that tag=E2=80=99d enclosed item, but also its = semantics. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 --Apple-Mail=_4772C1B3-3AC1-43A3-AE80-A83692423BB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OK. = I understand.  To use it one of these new types in CDDL, = particularly those with a internal structure, you make a pair of CDDL = headers, one for tagged and one for untagged that describe it like COSE = did (from 8152):

   COSE_Messages =3D =
COSE_Untagged_Message / COSE_Tagged_Message

   COSE_Untagged_Message =3D COSE_Sign / COSE_Sign1 /
       COSE_Encrypt / COSE_Encrypt0 /
       COSE_Mac / COSE_Mac0

   COSE_Tagged_Message =3D COSE_Sign_Tagged / COSE_Sign1_Tagged /
       COSE_Encrypt_Tagged / COSE_Encrypt0_Tagged /
       COSE_Mac_Tagged / COSE_Mac0_Tagged

   =
...

   =
COSE_Sign1_Tagged =3D #6.18(COSE_Sign1)

   =
COSE_Sign1 =3D [
       Headers,
       payload : bstr / nil,
       signature : bstr
   ]

Would be cool if there were standard CDDL definitions ready = for normative reference for all the =E2=80=9Ctagged=E2=80=9D data types = defined in 7049 / 7049bis.

LL


On Nov = 3, 2019, at 8:59 AM, Carsten Bormann <cabo@tzi.org> wrote:

Hi = Laurence,

CDDL does not describe behavior, = but the shape of data.

Maybe a key question here is whether you can = say in CDDL =E2=80=9Cthis next item must always be interpreted as a date = even though it will never have a date tag=E2=80=9D.

CDDL can say =E2=80=9Cthis item = is a number=E2=80=9D.  It does not tell you how to =E2=80=9Cinterpret= =E2=80=9D things, that would be the job of a language that transforms = the data just received into data that is used by an application.

If CDDL = doesn=E2=80=99t have than, then you can=E2=80=99t describe some = CBOR-protocols with it.

You = sure can =E2=80=9Cdescribe=E2=80=9D the shape of data in CBOR protocols, = but you will also need some information about how you plan to interpret = the data.

CWT would be one of those protocols as it forbids adding the = tag to dates.

(For the exp, = nbf, and iat claims, or claim numbers 4 to 6:) Yes, the CWT RFC (RFC = 8392) tells you that the value here is a number, not a tagged date.

The = designer of a protocol using a new data type will indicate in their = protocol for each occurrence of it whether the tag must be present or = not (never saying the tag may or may not be present). The designer will = typically require the tag only when necessary to disambiguate the type = of the data item.

Right. =  If you need to register for CWT a new claim that could either take = a number (such as the longitude of the satellite that this claim is = about) or a date/time (such as the time the satellite was launched), = then a tag could be useful to make that distinction.  

That example is a bit contrived, because = it=E2=80=99s just not as usual to have a choice between a number and a = date.  More likely might be a choice between a date/time = represented as a Tag 1 and a Tag 1001.  The encoding could choose = to leave off the tag from the number that is the enclosed item of Tag 1, = so you would have a choice between a number and a Tag 1001.

The = implementor of a general purpose library to generate one of these new = data item types must give the caller the option to include or not = include the tag. Maybe this is just by never automatically outputting = the tag and having a distinct output tag function.

The implementor of a general purpose library to decode one of = these new data types must allow the caller to say that the next data = item should be decoded as this new data type whether or not it is = tagged. Maybe it even errors out if it is tagged for the cases where the = protocol document says no tag should be used.

Right.

What I don=E2=80=99t = know is whether CDDL can describe all this desired behavior.

CDDL can describe the shape of = the data interchanged, but it can=E2=80=99t describe the mapping to = application semantics.  It can provide hints, and that=E2=80=99s = one of the things that the unwrap operator is good for: When you apply = it to a tag, this is a hint that you do not just want the data shape of = that tag=E2=80=99d enclosed item, but also its semantics.

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



= --Apple-Mail=_4772C1B3-3AC1-43A3-AE80-A83692423BB4-- From nobody Sun Nov 3 13:04: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 1FCA61200CE for ; Sun, 3 Nov 2019 13:04:05 -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 kaesINT_yrjz for ; Sun, 3 Nov 2019 13:04:02 -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 ECA051200C4 for ; Sun, 3 Nov 2019 13:04:01 -0800 (PST) Received: from [192.168.217.102] (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 475pM43PhjzyWd; Sun, 3 Nov 2019 22:04:00 +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: <06592ab7-f3cb-1a59-1b32-ffba3194162c@imt-atlantique.fr> Date: Sun, 3 Nov 2019 22:03:59 +0100 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 594507838.0811599-f7a75664086a1285a6bde5f772ba8956 Content-Transfer-Encoding: quoted-printable Message-Id: References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> <06592ab7-f3cb-1a59-1b32-ffba3194162c@imt-atlantique.fr> To: Christophe Lohr X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126 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, 03 Nov 2019 21:04:05 -0000 >=20 > However, I read "schema description" from the /semantic/ point of = view: > a description which explains the meaning of data items. =20 Right. =E2=80=9CSchema=E2=80=9D probably is one of the most misused = terms in this space. (That=E2=80=99s why CDDL is called a =E2=80=9Cdata definition = language=E2=80=9D.) > The IP RFC not > only tells that the first 4bits are an unsigned int, it also tells = that > this number is the protocol version.=20 > CBOR (neither JSON) can't tells this by itself, except if one defines = a > TAG for this. Tags (we prefer to write simple English words in lower case) tell you = how to interpret an enclosed item with different (additional) data = semantics. So a tag with number 1 tells you the enclosed number really = is to be interpreted as a POSIX epoch-based date. > So, the next question is: =E2=80=9Cis there some guidelines for using = TAGs?" >=20 > Well, it's probably too early. One may have to wait that CBOR usages > grow in maturity. CBOR has been around for half a decade now, so I think we have a pretty = good comprehension now of when to use tags. > What should I decide for my system design regarding CBOR TAGs? =E2=9E=94 Use tags when they are useful. There are no general guidelines like the ones you propose below, because = the usefulness depends on the specific context. > Shall I: > - prohibit TAGs since this is redundant with other parts of my design > specifications (which already explicit the meaning of each field); or If you have a relatively rigid data shape (=E2=80=9Cschema=E2=80=9D in = the usual structural sense), you may indeed not need tags, because you = can infer an alternative interpretation from structure (e.g., field = names in a map used as a struct, position in a record, etc.). They may = still be useful when you want to express a choice, e.g., if you want to = support both epoch-based and text-based dates, use Tag 0 or Tag 1. = Another example is integers: If you expect to interchange integers that = might not fit into 64 bits, use a choice between a built-in integer = (major types 0 and 1) and a tag 2/3: uint =3D #0 nint =3D #1 int =3D uint / nint biguint =3D #6.2(bstr) bignint =3D #6.3(bstr) bigint =3D biguint / bignint integer =3D int / bigint > - put TAGs everywhere for everything because TAGs bring semantic to = data; or "Everywhere=E2=80=9D I don=E2=80=99t know. But if you expect your = implementations to rely on generic decoders/encoders doing the work, = using tags may be a labor-saving device. This is particularly useful = when CBOR is used for general serialization in a programming environment = (where you may not have a hard and fast data definition with your data). > - add TAGs to some fields and not to others (which ones and why?) Yes. Only add them when they are useful. To express a choice, and/or = to have the generic codec do the work. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Nov 3 13:05: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 C03781200C4 for ; Sun, 3 Nov 2019 13:05:20 -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 HvidhGbHDCWx for ; Sun, 3 Nov 2019 13:05:18 -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 1E85D1200C1 for ; Sun, 3 Nov 2019 13:05:18 -0800 (PST) Received: from [192.168.217.102] (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 475pNX4nmlzyNM; Sun, 3 Nov 2019 22:05:16 +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: <8B119642-7D8D-4BEF-AD75-0AC9935BCD7C@island-resort.com> Date: Sun, 3 Nov 2019 22:05:16 +0100 Cc: Christophe Lohr , cbor@ietf.org X-Mao-Original-Outgoing-Id: 594507914.173039-54981c0de7b2fe7236bf6b79489d6304 Content-Transfer-Encoding: quoted-printable Message-Id: References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> <8B119642-7D8D-4BEF-AD75-0AC9935BCD7C@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126 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, 03 Nov 2019 21:05:21 -0000 On Nov 3, 2019, at 22:02, Laurence Lundblade = wrote: >=20 > Would be cool if there were standard CDDL definitions ready for = normative reference for all the =E2=80=9Ctagged=E2=80=9D data types = defined in 7049 / 7049bis. Do you mean anything beyond Appendix D of RFC 8610? https://tools.ietf.org/html/rfc8610#appendix-D Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Nov 3 13:07: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 4E25B1200CE for ; Sun, 3 Nov 2019 13:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 5wAOQmuySeRJ for ; Sun, 3 Nov 2019 13:07:00 -0800 (PST) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 1970F1200C1 for ; Sun, 3 Nov 2019 13:06:59 -0800 (PST) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id xA3L6v1F031813 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Sun, 3 Nov 2019 22:06:58 +0100 Received: from [192.168.16.50] (79.234.112.245) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Sun, 3 Nov 2019 22:06:52 +0100 To: Laurence Lundblade , Carsten Bormann CC: , Christophe Lohr References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> <8B119642-7D8D-4BEF-AD75-0AC9935BCD7C@island-resort.com> From: Henk Birkholz Message-ID: <3a7e36aa-a93b-feb7-0bf2-8745e8997699@sit.fraunhofer.de> Date: Sun, 3 Nov 2019 22:06:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <8B119642-7D8D-4BEF-AD75-0AC9935BCD7C@island-resort.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.234.112.245] Archived-At: Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126 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, 03 Nov 2019 21:07:03 -0000 Well there is this for starters > https://tools.ietf.org/html/rfc8610#appendix-D On 03.11.19 22:02, Laurence Lundblade wrote: > OK. I understand.  To use it one of these new types in CDDL, > particularly those with a internal structure, you make a pair of CDDL > headers, one for tagged and one for untagged that describe it like COSE > did (from 8152): > > COSE_Messages = COSE_Untagged_Message / COSE_Tagged_Message > > COSE_Untagged_Message = COSE_Sign / COSE_Sign1 / > COSE_Encrypt / COSE_Encrypt0 / > COSE_Mac / COSE_Mac0 > > COSE_Tagged_Message = COSE_Sign_Tagged / COSE_Sign1_Tagged / > COSE_Encrypt_Tagged / COSE_Encrypt0_Tagged / > COSE_Mac_Tagged / COSE_Mac0_Tagged > > > .... > > > COSE_Sign1_Tagged = #6.18(COSE_Sign1) > > > COSE_Sign1 = [ > Headers, > payload : bstr / nil, > signature : bstr > ] > > > Would be cool if there were standard CDDL definitions ready for > normative reference for all the “tagged” data types defined in 7049 / > 7049bis. > > LL > > >> On Nov 3, 2019, at 8:59 AM, Carsten Bormann > > wrote: >> >> Hi Laurence, >> >> CDDL does not describe behavior, but the shape of data. >> >>> Maybe a key question here is whether you can say in CDDL “this next >>> item must always be interpreted as a date even though it will never >>> have a date tag”. >> >> CDDL can say “this item is a number”.  It does not tell you how to >> “interpret” things, that would be the job of a language that >> transforms the data just received into data that is used by an >> application. >> >>> If CDDL doesn’t have than, then you can’t describe some >>> CBOR-protocols with it. >> >> You sure can “describe” the shape of data in CBOR protocols, but you >> will also need some information about how you plan to interpret the data. >> >>> CWT would be one of those protocols as it forbids adding the tag to >>> dates. >> >> (For the exp, nbf, and iat claims, or claim numbers 4 to 6:) Yes, the >> CWT RFC (RFC 8392) tells you that the value here is a number, not a >> tagged date. >> >>> The designer of a protocol using a new data type will indicate in >>> their protocol for each occurrence of it whether the tag must be >>> present or not (never saying the tag may or may not be present). The >>> designer will typically require the tag only when necessary to >>> disambiguate the type of the data item. >> >> Right.  If you need to register for CWT a new claim that could either >> take a number (such as the longitude of the satellite that this claim >> is about) or a date/time (such as the time the satellite was >> launched), then a tag could be useful to make that distinction. >> >> That example is a bit contrived, because it’s just not as usual to >> have a choice between a number and a date.  More likely might be a >> choice between a date/time represented as a Tag 1 and a Tag 1001.  The >> encoding could choose to leave off the tag from the number that is the >> enclosed item of Tag 1, so you would have a choice between a number >> and a Tag 1001. >> >>> The implementor of a general purpose library to generate one of these >>> new data item types must give the caller the option to include or not >>> include the tag. Maybe this is just by never automatically outputting >>> the tag and having a distinct output tag function. >>> >>> The implementor of a general purpose library to decode one of these >>> new data types must allow the caller to say that the next data item >>> should be decoded as this new data type whether or not it is tagged. >>> Maybe it even errors out if it is tagged for the cases where the >>> protocol document says no tag should be used. >> >> Right. >> >>> What I don’t know is whether CDDL can describe all this desired behavior. >> >> CDDL can describe the shape of the data interchanged, but it can’t >> describe the mapping to application semantics.  It can provide hints, >> and that’s one of the things that the unwrap operator is good for: >> When you apply it to a tag, this is a hint that you do not just want >> the data shape of that tag’d enclosed item, but also its semantics. >> >> Grüße, Carsten >> >> > > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > From nobody Sun Nov 3 13:08:13 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 8F27F12082F for ; Sun, 3 Nov 2019 13:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 USBHJ2RJY02z for ; Sun, 3 Nov 2019 13:08:06 -0800 (PST) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 24CAF120110 for ; Sun, 3 Nov 2019 13:08:05 -0800 (PST) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id xA3L83EH031976 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Sun, 3 Nov 2019 22:08:04 +0100 Received: from [192.168.16.50] (79.234.112.245) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Sun, 3 Nov 2019 22:07:58 +0100 To: Carsten Bormann , Laurence Lundblade CC: , Christophe Lohr References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> <8B119642-7D8D-4BEF-AD75-0AC9935BCD7C@island-resort.com> From: Henk Birkholz Message-ID: <0b6b6814-2c58-5f3f-6932-796f0978ae37@sit.fraunhofer.de> Date: Sun, 3 Nov 2019 22:07:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.234.112.245] Archived-At: Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126 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, 03 Nov 2019 21:08:13 -0000 Okay, as I am only seem to add redundancy, I'll just add an offset of 30 min before I reply here :o) On 03.11.19 22:05, Carsten Bormann wrote: > On Nov 3, 2019, at 22:02, Laurence Lundblade wrote: >> >> Would be cool if there were standard CDDL definitions ready for normative reference for all the “tagged” data types defined in 7049 / 7049bis. > > Do you mean anything beyond Appendix D of RFC 8610? > > https://tools.ietf.org/html/rfc8610#appendix-D > > Grüße, Carsten > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > From nobody Sun Nov 3 13:48:16 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 CB325120024 for ; Sun, 3 Nov 2019 13:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 G8XwaX-DYlaO for ; Sun, 3 Nov 2019 13:48:11 -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 1DCE412001E for ; Sun, 3 Nov 2019 13:48:11 -0800 (PST) Received: from Jude (192.168.1.159) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 3 Nov 2019 13:48:04 -0800 From: Jim Schaad To: 'Laurence Lundblade' , 'Christophe Lohr' CC: References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> In-Reply-To: <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> Date: Sun, 3 Nov 2019 13:48:01 -0800 Message-ID: <00e701d59290$5f1e8800$1d5b9800$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E8_01D5924D.50FDB900" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGnHXGXCgNhMDA3lcYHl4TPKUnPNwIaBkgZAi7v+2yntJceIA== X-Originating-IP: [192.168.1.159] Archived-At: Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126 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, 03 Nov 2019 21:48:15 -0000 ------=_NextPart_000_00E8_01D5924D.50FDB900 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: CBOR On Behalf Of Laurence Lundblade Sent: Sunday, November 3, 2019 8:46 AM To: Christophe Lohr Cc: cbor@ietf.org Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not = really used in practice #126 =20 I=E2=80=99m not really a data structure scientist or such, but I think I = can see Christophe=E2=80=99s point.=20 =20 Maybe CBOR-based (and JSON-based) protocols don=E2=80=99t have a formal = schema language, but these protocols rely on ordering and such. For = example in a COSE_Sign1 it is expected that the first data item is the = protected headers, the second the unprotected headers, the third the = payload and the fourth the signature. I don=E2=80=99t think you can call = them self-describing. =20 [JLS] I consider the term self-describing to be a completely different = beast. The data can be parsed without the knowledge of the schema. = This is not a true statement with ASN.1 where a data description label, = such as this is a SEQUENCE can be replace with a tag and the parser = without the schema has no idea what the data type and structure of the = data type is supposed to be. This is not an issue for XML either as far = as I know. =20 Jim =20 =20 It seems like CBOR and JSON say =E2=80=9Cno schema=E2=80=99=E2=80=9D to = distance from the horror of XML schemas, but in reality CDDL and prose = protocol specs are schemas in spirit. =20 Maybe a key question here is whether you can say in CDDL =E2=80=9Cthis = next item must always be interpreted as a date even though it will never = have a date tag=E2=80=9D. If CDDL doesn=E2=80=99t have than, then you = can=E2=80=99t describe some CBOR-protocols with it. CWT would be one of = those protocols as it forbids adding the tag to dates. =20 To summarize what I understand about tagging: =20 The designer of a new CBOR data item type like a date format will = generally register a tag for it. These new data types can be really = simple, like epoch dates or really complex like COSE_Sign1. =20 The designer of a protocol using a new data type will indicate in their = protocol for each occurrence of it whether the tag must be present or = not (never saying the tag may or may not be present). The designer will = typically require the tag only when necessary to disambiguate the type = of the data item. =20 The implementor of a general purpose library to generate one of these = new data item types must give the caller the option to include or not = include the tag. Maybe this is just by never automatically outputting = the tag and having a distinct output tag function. =20 The implementor of a general purpose library to decode one of these new = data types must allow the caller to say that the next data item should = be decoded as this new data type whether or not it is tagged. Maybe it = even errors out if it is tagged for the cases where the protocol = document says no tag should be used. =20 What I don=E2=80=99t know is whether CDDL can describe all this desired = behavior. =20 LL =20 =20 =20 On Oct 24, 2019, at 1:50 AM, Christophe Lohr = > wrote: =20 On 23/10/2019 13:38, Carsten Bormann wrote: Section 3.4 talks about "optional tagging" as a secondary purpose of = tags. But in today's CBOR protocols, tags are rarely "optional" in the = sense that they can simply be left out without a change in semantics, as = 3.4 para 3 implies. This concept comes up again in 4.2.2, where "optional tagging" is = outlawed in deterministic encoding (but then the text goes on to explain = that protocols might choose to retain tags, but doesn't say why). To be honest, I don't really understand how much optional are tags. A CDD rule with tags matchs cbor items with tags and reject cbor items without tags. Tags are not optional from the data-model point of view. Moreover, please consider this CDDL objective: (https://tools.ietf.org/html/rfc7049#section-1.1) 3. Data must be able to be decoded without a schema description. * Similar to JSON, encoded data should be self-describing so that a generic decoder can be written. Well, how to do this without putting tags everywhere for everything? (Or I need more explanation about what is "self-describing" and what is a "schema description") Let say I receive data. How may I know that this number is a temperature and not a distance, and that this byte-string is an uuid and not a small picture? The first way is to have a schema (written or not): That is to say a certain preliminary knowledge of expected data which tell me that this number at this place or associated to this map-key is a temperature. The second way is to decorate data with tags, all data. A third way is a compromise between the two first ones: I have a certain level of preliminary knoledge of what data are (a kind of schema description), with possibly some missing parts that are filled by tags. But the only way to decode data _without_ a schema description is to have tags everywhere for everything. Surprisingly, json has no tags and is claimed to be self-describing. Is it really? I'm lost. My feeling is that this objective CBOR should be not so demanding. Best regards, Christophe _______________________________________________ CBOR mailing list CBOR@ietf.org =20 https://www.ietf.org/mailman/listinfo/cbor =20 ------=_NextPart_000_00E8_01D5924D.50FDB900 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: CBOR = <cbor-bounces@ietf.org> On Behalf Of Laurence = Lundblade
Sent: Sunday, November 3, 2019 8:46 AM
To: = Christophe Lohr <christophe.lohr@imt-atlantique.fr>
Cc: = cbor@ietf.org
Subject: Re: [Cbor] 7049bis: The concept of = "optional tagging" is not really used in practice = #126

 

I=E2=80=99m = not really a data structure scientist or such, but I think I can see = Christophe=E2=80=99s point. 

 

Maybe CBOR-based (and JSON-based) protocols = don=E2=80=99t have a formal schema language, but these protocols rely on = ordering and such. For example in a COSE_Sign1 it is expected that the = first data item is the protected headers, the second the unprotected = headers, the third the payload and the fourth the signature. I = don=E2=80=99t think you can call them self-describing.

 

[JLS] I = consider the term self-describing to be a completely different beast. = =C2=A0The data can be parsed without the knowledge of the schema.=C2=A0 = This is not a true statement with ASN.1 where a data description label, = such as this is a SEQUENCE can be replace with a tag and the parser = without the schema has no idea what the data type and structure of the = data type is supposed to be.=C2=A0 This is not an issue for XML either = as far as I know.

 

Jim

 

 

It seems like CBOR and JSON say =E2=80=9Cno = schema=E2=80=99=E2=80=9D to distance from the horror of XML schemas, but = in reality CDDL and prose protocol specs are schemas in = spirit.

 

Maybe a key question here is whether you can say in = CDDL =E2=80=9Cthis next item must always be interpreted as a date even = though it will never have a date tag=E2=80=9D. If CDDL doesn=E2=80=99t = have than, then you can=E2=80=99t describe some CBOR-protocols with it. = CWT would be one of those protocols as it forbids adding the tag to = dates.

 

To summarize what I understand about = tagging:

 

The designer of a new CBOR data item type like a date = format will generally register a tag for it. These new data types can be = really simple, like epoch dates or really complex like = COSE_Sign1.

 

The designer of a protocol using a new data type will = indicate in their protocol for each occurrence of it whether the tag = must be present or not (never saying the tag may or may not be present). = The designer will typically require the tag only when necessary to = disambiguate the type of the data item.

 

The implementor of a general purpose library to = generate one of these new data item types must give the caller the = option to include or not include the tag. Maybe this is just by never = automatically outputting the tag and having a distinct output tag = function.

 

The implementor of a general purpose library to decode = one of these new data types must allow the caller to say that the next = data item should be decoded as this new data type whether or not it is = tagged. Maybe it even errors out if it is tagged for the cases where the = protocol document says no tag should be = used.

 

What I don=E2=80=99t know is whether CDDL can describe = all this desired behavior.

 

LL

 

 

 



On Oct 24, 2019, at 1:50 AM, Christophe Lohr <christophe.lohr@imt-atl= antique.fr> wrote:

 

On = 23/10/2019 13:38, Carsten Bormann = wrote:

Section 3.4 talks about "optional tagging" = as a secondary purpose of tags. But in today's CBOR protocols, tags are = rarely "optional" in the sense that they can simply be left = out without a change in semantics, as 3.4 para 3 implies.

This = concept comes up again in 4.2.2, where "optional tagging" is = outlawed in deterministic encoding (but then the text goes on to explain = that protocols might choose to retain tags, but doesn't say = why).


To be honest, = I don't really understand how much optional are tags.

A CDD rule = with tags matchs cbor items with tags and reject cbor items
without = tags. Tags are not optional from the data-model point of = view.


Moreover, please consider this CDDL objective:
(https://tools.ie= tf.org/html/rfc7049#section-1.1)

   3.  Data = must be able to be decoded without a schema = description.
       *  Similar to = JSON, encoded data should be self-describing = so
          that a = generic decoder can be written.


Well, how to do this without = putting tags everywhere for everything?
(Or I need more explanation = about what is "self-describing" and what is
a "schema = description")

Let say I receive data. How may I know that = this number is a temperature
and not a distance, and that this = byte-string is an uuid and not a small
picture?

The first way = is to have a schema (written or not): That is to say a
certain = preliminary knowledge of expected data which tell me that this
number = at this place or associated to this map-key is a temperature.
The = second way is to decorate data with tags, all data.
A third way is a = compromise between the two first ones: I have a certain
level of = preliminary knoledge of what data are (a kind of schema
description), = with possibly some missing parts that are filled by tags.

But the = only way to decode data _without_ a schema description is to
have = tags everywhere for everything.
Surprisingly, json has no tags and is = claimed to be self-describing. Is
it really? I'm lost.

My = feeling is that this objective CBOR should be not so = demanding.

Best = regards,
Christophe

___________________________________________= ____
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/= mailman/listinfo/cbor

 

------=_NextPart_000_00E8_01D5924D.50FDB900-- From nobody Sun Nov 3 16:03:18 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 4E9FA12004F for ; Sun, 3 Nov 2019 16:03:15 -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 AyDxVNaaB1kv for ; Sun, 3 Nov 2019 16:03:13 -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 CDD0A12003E for ; Sun, 3 Nov 2019 16:03:12 -0800 (PST) Received: from [192.168.217.102] (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 475tKm60dXzySF; Mon, 4 Nov 2019 01:03:08 +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: <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> Date: Mon, 4 Nov 2019 01:03:10 +0100 Cc: Christophe Lohr , cbor@ietf.org X-Mao-Original-Outgoing-Id: 594518588.141502-c7ea9df27385886642688ba33870ba98 Content-Transfer-Encoding: quoted-printable Message-Id: References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 00:03:16 -0000 On Nov 3, 2019, at 17:45, Laurence Lundblade = wrote: >=20 > It seems like CBOR and JSON say =E2=80=9Cno schema=E2=80=99=E2=80=9D = to distance from the horror of XML schemas, but in reality CDDL and = prose protocol specs are schemas in spirit. One of the innovations of XML with respect to SGML was that it allowed = schemaless parsing (parsing without a DTD). In practice, this was = marred by having default values in the DTD, so you couldn=E2=80=99t = quite use schemaless parsing with a lot of real-world data. But it = still was a major item of progress, and people who got the point started = to shun adding defaults to DTDs. Schemaless parsing means that you can develop a parser independent of = the application. This is a major boon when you consider the fact that it is quite easy to = introduce bugs in parsers, and bugs in input parsers are a significant = attack vector. Application considerations don=E2=80=99t enter a schemaless parser, so = you can use a hardened, debugged implementation for parsing. Default value processing is an example of data transformation, from the = parsed input to something that an application can use (and back!). = Adding information about more general forms of such a transformation to = a data definition language is a major item of interest. First of all, = it needs a data model for what the application can use. Doing only = defaults processing as in a DTD-based XML parser is easy, because the = application data model is a simplified version of the interchange data = model. Now if you add something like tag processing (or, more = generally, conversions between platform data types and the conventions = used for representing them in interchange), the abstractions can get = more leaky. Fortunately, none of this is needed for completing 7049bis. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Nov 4 08:28:08 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 8B2C0120B5E for ; Mon, 4 Nov 2019 08:28:05 -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 qTiQqO6HH6cJ for ; Mon, 4 Nov 2019 08:28:02 -0800 (PST) Received: from p3plsmtpa11-07.prod.phx3.secureserver.net (p3plsmtpa11-07.prod.phx3.secureserver.net [68.178.252.108]) (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 B6CFB120B3D for ; Mon, 4 Nov 2019 08:28:02 -0800 (PST) Received: from [10.122.0.118] ([45.56.150.85]) by :SMTPAUTH: with ESMTPA id RfCziW5aVOBX8RfD0inrbo; Mon, 04 Nov 2019 09:28:02 -0700 From: Laurence Lundblade Message-Id: <3F9E4E02-7A86-4954-8E31-0E28D2B2FCDA@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BA7E3C5F-A86D-49E0-8675-BF7AA19652FA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 4 Nov 2019 08:28:01 -0800 In-Reply-To: Cc: cbor@ietf.org, Christophe Lohr To: Carsten Bormann References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> <8B119642-7D8D-4BEF-AD75-0AC9935BCD7C@island-resort.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfLd8vkg0Hnfn6kfwvl7Pu5hAncy1VbSoinPguW9IB5t4YFHsUjcvh9aZ4iqqfKV0TUG7u+pRfeX2cLoBFwMUa8R7vY3oyaKBingFabr2XMZGfkdqcEso glc4+FFvoqtTbanVKc0tGVjKV6PH+6KaduDV7rjgheeaLw6j88K30m0rgUlIyJVjxtaGVlWhjgplumdKmxxwqQbRZ/GCSDBwNQursvXMIJ0mec2KnRa9Tdb+ Archived-At: Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 16:28:06 -0000 --Apple-Mail=_BA7E3C5F-A86D-49E0-8675-BF7AA19652FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 3, 2019, at 1:05 PM, Carsten Bormann wrote: >=20 > On Nov 3, 2019, at 22:02, Laurence Lundblade = wrote: >>=20 >> Would be cool if there were standard CDDL definitions ready for = normative reference for all the =E2=80=9Ctagged=E2=80=9D data types = defined in 7049 / 7049bis. >=20 > Do you mean anything beyond Appendix D of RFC 8610? >=20 > https://tools.ietf.org/html/rfc8610#appendix-D Was thinking more like COSE: decfrac =3D [ e10: int, m: integer ] decfrac_tagged =3D #6.4(decfrac) That way you can say exactly which you want in CDDL without constructing = the CDDL for the non-tagged form. Will also help make it clear that = protocol designers need to be clear and pick one. Maybe even ask that every new registered data type have CDDL like this = published suitable for normative reference as a requirement for getting = into the IANA registry? LL --Apple-Mail=_BA7E3C5F-A86D-49E0-8675-BF7AA19652FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Nov 3, 2019, at 1:05 PM, Carsten Bormann <cabo@tzi.org> = wrote:

On Nov 3, 2019, at 22:02, Laurence Lundblade <lgl@island-resort.com> wrote:

Would be cool if there were = standard CDDL definitions ready for normative reference for all the = =E2=80=9Ctagged=E2=80=9D data types defined in 7049 / 7049bis.

Do you mean anything beyond = Appendix D of RFC 8610?

https://tools.ietf.org/html/rfc8610#appendix-D

Was = thinking more like COSE:

decfrac =3D = [
    =           e10: int,
            =   m: integer
          =  ]

decfrac_tagged =3D = #6.4(decfrac)


That way you can = say exactly which you want in CDDL without constructing the CDDL for the = non-tagged form. Will also help make it clear that  protocol = designers need to be clear and pick one.

Maybe even ask that every new registered data type = have CDDL like this published suitable for normative reference as a = requirement for getting into the IANA registry?

LL

= --Apple-Mail=_BA7E3C5F-A86D-49E0-8675-BF7AA19652FA-- From nobody Mon Nov 4 08:34:23 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 2624B120232 for ; Mon, 4 Nov 2019 08:34:22 -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 NRFvP4_iEUav for ; Mon, 4 Nov 2019 08:34:20 -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 1588E12011F for ; Mon, 4 Nov 2019 08:34:20 -0800 (PST) Received: from [192.168.217.102] (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 476JKQ1vRRzyjS; Mon, 4 Nov 2019 17:34:18 +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: <3F9E4E02-7A86-4954-8E31-0E28D2B2FCDA@island-resort.com> Date: Mon, 4 Nov 2019 17:34:17 +0100 Cc: cbor@ietf.org, Christophe Lohr X-Mao-Original-Outgoing-Id: 594578055.681186-09573d8762d033e2facc76f92b42e5fb Content-Transfer-Encoding: quoted-printable Message-Id: References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> <8B119642-7D8D-4BEF-AD75-0AC9935BCD7C@island-resort.com> <3F9E4E02-7A86-4954-8E31-0E28D2B2FCDA@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 16:34:22 -0000 On Nov 4, 2019, at 17:28, Laurence Lundblade = wrote: >=20 > Was thinking more like COSE: >=20 > decfrac =3D [ > e10: int, > m: integer > ] >=20 > decfrac_tagged =3D #6.4(decfrac) That kind of style was written when we didn=E2=80=99t have the unwrap = operator. RFC 8610 says: decfrac =3D #6.4([e10: int, m: integer]) Which is exactly what is called =E2=80=9Cdecfrac_tagged=E2=80=9D in the = above. If you don=E2=80=99t want the tag, just write ~decfrac, and you have = what you called decfrac in your example. (And the fact that the unwrap convention works universally obviates the = need to come up with noisy conventions such as _tagged.) > That way you can say exactly which you want in CDDL without = constructing the CDDL for the non-tagged form. Will also help make it = clear that protocol designers need to be clear and pick one. >=20 > Maybe even ask that every new registered data type have CDDL like this = published suitable for normative reference as a requirement for getting = into the IANA registry? Requiring this would create too much coupling. Suggesting this is a good job for the DE :-) (=E2=80=9Csuitable for normative reference=E2=80=9D is a different = issue, though.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Nov 4 15:22:04 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 7AEFA1207FB; Mon, 4 Nov 2019 15:21:56 -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.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <157290971643.13964.10442200211561663375@ietfa.amsl.com> Date: Mon, 04 Nov 2019 15:21:56 -0800 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-7049bis-08.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: Mon, 04 Nov 2019 23:21:56 -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-08.txt Pages : 70 Date : 2019-11-04 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-7049bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-7049bis-08 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 Mon Nov 4 15:26:56 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 BC4E9120B30; Mon, 4 Nov 2019 15:26:51 -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.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <157291001172.13984.17072316613413501610@ietfa.amsl.com> Date: Mon, 04 Nov 2019 15:26:51 -0800 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-7049bis-09.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: Mon, 04 Nov 2019 23:26:55 -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-09.txt Pages : 70 Date : 2019-11-04 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-7049bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-7049bis-09 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 Mon Nov 4 15:35:39 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 3A5741209D1 for ; Mon, 4 Nov 2019 15:35:34 -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 AIxP-fcwll0y for ; Mon, 4 Nov 2019 15:35:31 -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 D4E5D120910 for ; Mon, 4 Nov 2019 15:35:30 -0800 (PST) Received: from client-0152.vpn.uni-bremen.de (client-0152.vpn.uni-bremen.de [134.102.107.152]) (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 476TgP1cqKzydC; Tue, 5 Nov 2019 00:35:29 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 594603327.047892-f6ffdf1e6c111621f1a9d58fc31787a0 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 5 Nov 2019 00:35:28 +0100 Message-Id: To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] 7049bis -08 and -09 submitted X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 23:35:38 -0000 Right before the I-D deadline, I have submitted two new versions of = 7049bis Version -08: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-7049bis-08 Contains all the changes that we had done about a week ago, so should be = relatively stable. Version -09: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-7049bis-09 has all the bleeding edge stuff that has not had as much review. These were submitted separately so you can look at the changes = separately. Of course, if you want the firehose: = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-cbor-7049bis-07&url2=3Ddraf= t-ietf-cbor-7049bis-09 It would be great to get some review so we can decide whether -09 is the = WGLC version. (I have done some issue processing, but not yet a grand re-read. Expect some WGLC comments from me as well ;-) There are a few remnant issues at: https://github.com/cbor-wg/CBORbis/issues which I believe can be closed, but before that I'd like to hear some = support for closing them. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Nov 6 01:35:13 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 7F6E6120103 for ; Wed, 6 Nov 2019 01:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_FONT_LOW_CONTRAST=0.001, 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 meJXtGqZefZG for ; Wed, 6 Nov 2019 01:35:08 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150050.outbound.protection.outlook.com [40.107.15.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C14120073 for ; Wed, 6 Nov 2019 01:35:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jiavPohfutltVteVV8k4sGs7zNsIlJkGBZ+PKLJPbTTTsrj/jd9MCbd3XTtoxWIu9cXv5EijYUd9ZqrrMJQxEhpSU4NbSqXBpL2l571rNTAn9m3hPtbyxi/rAwHhH75IGgdDkOalfVftdxirbq20HuS2R+oLbGUUwsY93otu2hCZDPPVDMpre8q2uV13PkGQEJNXhje8u/TBUgln+04ONp93PJtZ0/QoTDjQGL/Dyh+VPGQ61sntUYQF4vyuo285GP6OpCY6rk23pdftJS0kkbGMmZOwDPKzbduyVAOQ3wY4HOpfd1tV0F0x+V3642SmX0k7KkspFFO7FwcpBEnoZQ== 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=v0F2vyO/uoCxBfEN+c3H8MVt60T0okvI47NwLHqPtHk=; b=ROxh8Kh/kFqD7WTpRdroQLB8Abrf59s9wjuJYHNXfW3idQTVt9gFEaC9Ycv1WkLjAMzjB0/5aRQ8ltPo18yIdWdwBVaULVQgoW2DdRnEgoXxa8LtESNO147nPCRu9gR+E/PtVhSKBhMo8KmjUdOtPSZP3mDmAtDs0W2ccJJ94rg/w5bHKkSY5NxArU9FwBlvI1fQkpyL8nBnasy10omtGTAf73NDrRQ4t1etMVD4kSgkcR0u9sHGtVIuKK9kaeaOtwwRHr8XLEHTchYNa8uTLLR6XBac7HSCgPC0vyf3f/TpVuiMRdZ4AnoYeSvbKRRgCEBzsY9Kt+8NuJ3dmIjdBw== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v0F2vyO/uoCxBfEN+c3H8MVt60T0okvI47NwLHqPtHk=; b=OgfNYsz7MPqKZhqpie23uryORkf5bUoYZE4CQzzjUjxK7uiiSL0IB0MerZnItbTf0OYZjO/nI/JNzDFjb8CYG3yKgbFD8rW6NI9PoGjZ7N59N27NjJ1YabXa+GDqL8umxinXuEhy+NDSFuYj479JaXy2ZheWiQLUupyLcf3IVvo= Received: from VI1PR07MB5469.eurprd07.prod.outlook.com (20.178.14.214) by VI1PR07MB5056.eurprd07.prod.outlook.com (20.177.203.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.13; Wed, 6 Nov 2019 09:35:05 +0000 Received: from VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76]) by VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76%6]) with mapi id 15.20.2430.017; Wed, 6 Nov 2019 09:35:05 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: Carsten Bormann , Jim Schaad Thread-Topic: CBOR Interim: 2019-11-06 Thread-Index: AQHVlIV4q/wMge1kUUufGCBYuNuLwQ== Date: Wed, 6 Nov 2019 09:35:05 +0000 Message-ID: <4ED88D25-846D-4307-97E4-BEEDC4451ABF@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: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5f563bd2-7e6c-44fa-ae76-08d7629c9b62 x-ms-traffictypediagnostic: VI1PR07MB5056: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(136003)(39860400002)(366004)(376002)(199004)(189003)(53754006)(497574002)(6116002)(25786009)(478600001)(6436002)(6916009)(4326008)(54906003)(8936002)(2351001)(186003)(14444005)(256004)(16799955002)(476003)(6506007)(1730700003)(66446008)(81166006)(3846002)(81156014)(606006)(14454004)(966005)(36756003)(66476007)(66556008)(2501003)(486006)(64756008)(7736002)(71200400001)(71190400001)(102836004)(86362001)(91956017)(76116006)(44832011)(66946007)(5640700003)(2616005)(8676002)(26005)(316002)(6306002)(54896002)(236005)(6512007)(2906002)(99286004)(6486002)(66066001)(33656002)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5056; H:VI1PR07MB5469.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: 0jZpofpsNzdnA0ObKyql2d7E7HRTA4Epble5vuYIO/LAboCupTmynbV7ndGEOaan47cppcoK92JkvP+XhHA6EbdFwg6Csx6IH/gUM7hR1rCyFfvDsecJxaD6fdfaBTwY1XKlW8kT7Wcna9y1PqqHU0Ypmazp60FXhJ3/jl3c99k96OrXPln8gCDow+rpUvrETAa6bNYDTsO0NHEeX3HWfFYa11JIX5nCvFXV0ukbO12vT2+Uj0HMKOlUE2nmRagLrQZElFAEt8yQn4nPoDoXAbU6LdG6ICj5DCxFpKKj8jt7TIKXcGfAX2M2FXWsw1SDaA9F1q4UvftbnICp7vfEBsv/u4TZ1qwgxcqFLcgXYOW+pwnqgPU10MJuzf98bwEhrmLGnWQ4hopyCFfw7jTBB4xTuCeu3anNBdJXHL1i+l7kMl8MQwKXelUnDDIx50TexO3ml+yvPZjNtCSDFFjYkq5hslGYRQatGVASZXYsbrw= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_4ED88D25846D430797E4BEEDC4451ABFericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5f563bd2-7e6c-44fa-ae76-08d7629c9b62 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 09:35:05.6431 (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: ru4cq4/EEhakWEuM5R7Ov5JzQ17Oo4+v/ZhjMg90J4hi5Kfao/bl+8q3naB1AWqScrSux4tt6yi5E9tkVE3F0xfiouJ3XMZrCpmHlIighPHhBkG6RVc33wOZP9tkUSYl X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5056 Archived-At: Subject: [Cbor] CBOR Interim: 2019-11-06 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, 06 Nov 2019 09:35:12 -0000 --_000_4ED88D25846D430797E4BEEDC4451ABFericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUb2RheeKAmXMgaW50ZXJpbSB3aWxsIHByb2JhYmx5IGJlIGEgc2hvcnQgb25l LCBidXQgSSB3YW50IHRvIGhhdmUgYSBjaGF0IGFuZCBzZWUgaWYgYW55Ym9keSB3YXMgYWJsZSB0 byByZWFkIHRoZSB1cGRhdGUgb24gQ0JPUiBDYXJzdGVuIHBvc3RlZCAodGhhbmtzIENhcnN0ZW4h KS4gSWYgc28sIHdlIGNhbiBkaXNjdXNzIGl0LCBvdGhlcndpc2UgSSBvbmx5IGhhdmUgYSBjb3Vw bGUgb2YgcXVpY2sgaXRlbXMgb24gdGhlIGFnZW5kYSAoYWdlbmRhIHNsb3RzIGluIFNpbmdhcG9y ZSwgYW5kIENEREwgY29udGludWVkKS4gSSBkb27igJl0IHRoaW5rIHdl4oCZbGwgdGFrZSB0aGUg ZnVsbCBob3VyLg0KDQoNCldlYmV4OiBodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/ TVRJRD1tMTIzN2E5ODEyNDExMWRlM2E0YzRlNjFkZmFjYTA1ZDUNCkFnZW5kYTogaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAxOS1jYm9yLTE5L21hdGVyaWFs cy9hZ2VuZGEtaW50ZXJpbS0yMDE5LWNib3ItMTktc2Vzc2ENClRpbWU6IGh0dHBzOi8vd3d3Lndv cmxkdGltZWJ1ZGR5LmNvbS8/cW09MSZsaWQ9MTIsMTAwLDUsOCZoPTEwMCZkYXRlPTIwMTktMTEt MDYmc2xuPTE2LTE3DQoNCg0KVGFsayB0byB5b3UgbGF0ZXIsDQpGcmFuY2VzY2ENCg0KDQoNCkhl bGxvLA0KQ0JPUiBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJleCBt ZWV0aW5nLg0KDQoNCg0KQ0JPUiBXRyBDb25mZXJlbmNlIENhbGwNCk9jY3VycyBldmVyeSAyIHdl ZWsocykgb24gV2VkbmVzZGF5IGVmZmVjdGl2ZSBXZWRuZXNkYXksIE1heSAyMiwgMjAxOSB1bnRp bCBXZWRuZXNkYXksIE5vdmVtYmVyIDYsIDIwMTkgZnJvbSA1OjAwIFBNIHRvIDY6MDAgUE0sIChV VEMrMDE6MDApIEFtc3RlcmRhbSwgQmVybGluLCBCZXJuLCBSb21lLCBTdG9ja2hvbG0sIFZpZW5u YQ0KNTowMCBwbSAgfCAgRXVyb3BlIFN1bW1lciBUaW1lIChBbXN0ZXJkYW0sIEdNVCswMjowMCkg IHwgIDEgaHINCg0KTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQxIDc2MCAxNTcNCg0K TWVldGluZyBwYXNzd29yZDogVVBBdDlyQm4NCg0KDQoNCkFkZCB0byBDYWxlbmRhcjxodHRwczov L2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMWQwNjM2MDY5YTI4YmQ3YzhjYzA5MGU3 NDE1NjVjOGM+DQpXaGVuIGl0J3MgdGltZSwgam9pbiB0aGUgbWVldGluZzxodHRwczovL2lldGYu d2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMTIzN2E5ODEyNDExMWRlM2E0YzRlNjFkZmFjYTA1 ZDU+Lg0KDQoNCg0KSm9pbiBieSBwaG9uZQ0KMS02NTAtNDc5LTMyMDg8dGVsOiUyQjEtNjUwLTQ3 OS0zMjA4LCwqMDEqNjQxNzYwMTU3JTIzJTIzKjAxKj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMv Q2FuYWRhKQ0KDQoNCg0KQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz88aHR0cHM6Ly9jb2xsYWJvcmF0 aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTU+DQoNCg0KDQpJTVBPUlRBTlQg Tk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8g YW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29y ZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2lu aW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29y ZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5 b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uDQoN Cg== --_000_4ED88D25846D430797E4BEEDC4451ABFericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <5CA3BCBEA4C3E648BB688330F3505B6D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQt c3RhbmRhcmQ7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uYXBw bGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFj ZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IlNWIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRvZGF54oCZcyBpbnRlcmltIHdpbGwg cHJvYmFibHkgYmUgYSBzaG9ydCBvbmUsIGJ1dCBJIHdhbnQgdG8gaGF2ZSBhIGNoYXQgYW5kIHNl ZSBpZiBhbnlib2R5IHdhcyBhYmxlIHRvIHJlYWQgdGhlIHVwZGF0ZSBvbiBDQk9SIENhcnN0ZW4g cG9zdGVkICh0aGFua3MgQ2Fyc3RlbiEpLiBJZiBzbywgd2UgY2FuIGRpc2N1c3MgaXQsIG90aGVy d2lzZSBJIG9ubHkgaGF2ZQ0KIGEgY291cGxlIG9mIHF1aWNrIGl0ZW1zIG9uIHRoZSBhZ2VuZGEg KGFnZW5kYSBzbG90cyBpbiBTaW5nYXBvcmUsIGFuZCBDRERMIGNvbnRpbnVlZCkuIEkgZG9u4oCZ dCB0aGluayB3ZeKAmWxsIHRha2UgdGhlIGZ1bGwgaG91ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XZWJleDogPGEg aHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTEyMzdhOTgxMjQx MTFkZTNhNGM0ZTYxZGZhY2EwNWQ1Ij4NCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW0xMjM3YTk4MTI0MTExZGUzYTRjNGU2MWRmYWNhMDVkNTwvYT4gPG86cD4NCjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPkFnZW5kYTogPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMTktY2Jvci0xOS9tYXRlcmlhbHMvYWdl bmRhLWludGVyaW0tMjAxOS1jYm9yLTE5LXNlc3NhIj48c3BhbiBsYW5nPSJTViI+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAxOS1jYm9yLTE5L21hdGVyaWFs cy9hZ2VuZGEtaW50ZXJpbS0yMDE5LWNib3ItMTktc2Vzc2E8L3NwYW4+PC9hPjxzcGFuIGxhbmc9 IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGltZTogPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LndvcmxkdGltZWJ1ZGR5LmNvbS8/cW09MSZhbXA7bGlkPTEyLDEwMCw1LDgmYW1wO2g9MTAwJmFt cDtkYXRlPTIwMTktMTEtMDYmYW1wO3Nsbj0xNi0xNyI+aHR0cHM6Ly93d3cud29ybGR0aW1lYnVk ZHkuY29tLz9xbT0xJmFtcDtsaWQ9MTIsMTAwLDUsOCZhbXA7aD0xMDAmYW1wO2RhdGU9MjAxOS0x MS0wNiZhbXA7c2xuPTE2LTE3PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGFsayB0byB5b3UgbGF0ZXIsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxU YWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgYWxpZ249ImxlZnQiIHdpZHRoPSI1MjUi IHN0eWxlPSJ3aWR0aDozOTMuNzVwdDttYXJnaW4tbGVmdDozLjc1cHQiPg0KPHRib2R5Pg0KPHRy Pg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpm cmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91 bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNo b3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUg Y2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0i NTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJw YWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGlj YWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0RDRENEQiPkhlbGxvLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRk aW5nOjcuNXB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNl OjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNh bDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWln aHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzRENEQ0RCI+Q0JPUiBXb3Jr aW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJleCBtZWV0aW5nLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1l O21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDtt c28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1o b3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM2NjY2NjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFz cz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUi IHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4w cHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1l bnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90 ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12 ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21z by1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIg Ym9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAu MCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVt ZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFw OmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50 LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNEQ0RDREIj5DQk9SIFdHIENvbmZlcmVuY2UgQ2FsbDwvc3Bhbj48L2I+PG86cD48L286cD48 L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQt d3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxl bWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5PY2N1cnMgZXZlcnkgMiB3ZWVrKHMpIG9uIFdl ZG5lc2RheSBlZmZlY3RpdmUgV2VkbmVzZGF5LCBNYXkgMjIsIDIwMTkgdW50aWwgV2VkbmVzZGF5 LCBOb3ZlbWJlciA2LCAyMDE5IGZyb20gNTowMCBQTSB0byA2OjAwIFBNLCAoVVRDJiM0MzswMTow MCkgQW1zdGVyZGFtLCBCZXJsaW4sIEJlcm4sIFJvbWUsIFN0b2NraG9sbSwNCiBWaWVubmE8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4w cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1l bGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7 bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFj dGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+NTowMCBwbSZuYnNwOyZuYnNwO3wm bmJzcDsmbmJzcDtFdXJvcGUgU3VtbWVyIFRpbWUgKEFtc3RlcmRhbSwgR01UJiM0MzswMjowMCkm bmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7MSBocjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhz cGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJv cmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MGNtIj4NCjx0 Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFt ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7 bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3It aG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojNjY2NjY2Ij5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDEgNzYwIDE1 Nzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVt ZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFw OmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50 LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdp ZHRoPSIwIiBzdHlsZT0id2lkdGg6MGNtIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFk ZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6 Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5NZWV0aW5nIHBh c3N3b3JkOiBVUEF0OXJCbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50 LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1h bmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNv bHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2 NjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFs VGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0 aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1l bGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6 b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0 O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs ZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBj ZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY207bWluLXdpZHRoOiAxODZw eCAhaW1wb3J0YW50O2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91 bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBh ZGRpbmc6MGNtIDBjbSAwY20gMGNtO21pbi13aWR0aDogMTg2cHggIWltcG9ydGFudCI+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjEiIGNlbGxzcGFjaW5nPSIwIiBjZWxs cGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY207YmFja2dyb3VuZDojMDQ4Q0JG O2JvcmRlcjpzb2xpZCAjMDQ4Q0JGIDEuNXB0O21pbi13aWR0aDogMTg2cHggIWltcG9ydGFudCI+ DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6MTAuNXB0IDE1 LjBwdCAxMC41cHQgMTUuMHB0O21pbi13aWR0aDogMTg2cHggIWltcG9ydGFudDtiYWNrZ3JvdW5k LXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRp YWwiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxp Z246Y2VudGVyO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVu dC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQt YW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpj b2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2 NjY2Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMWQw NjM2MDY5YTI4YmQ3YzhjYzA5MGU3NDE1NjVjOGMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUu MHB0O2NvbG9yOndoaXRlIj5BZGQgdG8gQ2FsZW5kYXI8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTttaW4td2lkdGg6IDE4NnB4ICFpbXBvcnRhbnQi Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0i MCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MGNtO21pbi13aWR0aDog MTg2cHggIWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNt IDBjbSAwY20gMTIuMHB0O21pbi13aWR0aDogMTg2cHggIWltcG9ydGFudCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21z by1lbGVtZW50LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM2NjY2NjYiPldoZW4gaXQncyB0aW1lLDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYv ai5waHA/TVRJRD1tMTIzN2E5ODEyNDExMWRlM2E0YzRlNjFkZmFjYTA1ZDUiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDBBRkY5Ij5qb2luIHRoZSBtZWV0aW5nPC9zcGFuPjwvYT4uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3Ry Pg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2 LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNv Tm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxl PSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0K PHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwv dHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNl OjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNh bDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWln aHQtcnVsZTpleGFjdGx5Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJN c29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5 bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzow Y20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Sm9pbiBieSBwaG9uZTwvc3Bhbj48L2I+PG86cD48 L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVs ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0 bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48YSBocmVmPSJ0ZWw6JTJCMS02 NTAtNDc5LTMyMDgsLCowMSo2NDE3NjAxNTclMjMlMjMqMDEqIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwQUZGOSI+MS02NTAtNDc5LTMyMDg8L3NwYW4+PC9hPjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJz cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Q2FsbC1pbg0KIHRv bGwgbnVtYmVyIChVUy9DYW5hZGEpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+ DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPC90cj4N CjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4w cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBh cmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1y dWxlOmV4YWN0bHkiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05v cm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNTI1IiBzdHlsZT0i d2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0 ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1l O21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDtt c28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1o b3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM2NjY2NjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3Ry Pg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2 LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNv Tm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxl PSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNt IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox NS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21z by1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3Jh cGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpl eGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+PGEgaHJlZj0iaHR0cHM6Ly9j b2xsYWJvcmF0aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTUiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDBBRkY5Ij5DYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvc3Bhbj48L2E+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6 ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJv dW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5j aG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBj ZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9k eT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjcuNXB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNt IDBjbSAwY207aGVpZ2h0OjcuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQt d3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxl bWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1m cmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5j aG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1 bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhz cGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6I0EwQTBBMCI+SU1QT1JU QU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1 ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSBy ZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkg am9pbmluZw0KIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNo IHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlz Y3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Np b24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJs ZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4ED88D25846D430797E4BEEDC4451ABFericssoncom_-- From nobody Wed Nov 6 04:24:15 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 A77CC120860 for ; Wed, 6 Nov 2019 04:24:12 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VG2EkpjHxWMb for ; Wed, 6 Nov 2019 04:24:08 -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 B7DD612006D for ; Wed, 6 Nov 2019 04:24:08 -0800 (PST) Received: from [192.168.217.102] (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 477Qgp5Y6lzyXN; Wed, 6 Nov 2019 13:24:06 +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: <4ED88D25-846D-4307-97E4-BEEDC4451ABF@ericsson.com> Date: Wed, 6 Nov 2019 13:24:12 +0100 Cc: "cbor@ietf.org" , Jim Schaad X-Mao-Original-Outgoing-Id: 594735848.6385289-92dae32a8e14b3fa17f1c2e032532617 Content-Transfer-Encoding: quoted-printable Message-Id: <48A20127-CC94-406B-8CC4-788035534E47@tzi.org> References: <4ED88D25-846D-4307-97E4-BEEDC4451ABF@ericsson.com> To: Francesca Palombini X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] CBOR Interim: 2019-11-06 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, 06 Nov 2019 12:24:13 -0000 We probably should also discuss the one open issue that didn=E2=80=99t = lead to text changes: https://github.com/cbor-wg/CBORbis/issues/63 I personally think we are as good on this as we can be, but I would love = to hear other views. Gr=C3=BC=C3=9Fe, Carsten > On Nov 6, 2019, at 10:35, Francesca Palombini = wrote: >=20 > Hi all, > =20 > Today=E2=80=99s interim will probably be a short one, but I want to = have a chat and see if anybody was able to read the update on CBOR = Carsten posted (thanks Carsten!). If so, we can discuss it, otherwise I = only have a couple of quick items on the agenda (agenda slots in = Singapore, and CDDL continued). I don=E2=80=99t think we=E2=80=99ll take = the full hour. > =20 > =20 > Webex: = https://ietf.webex.com/ietf/j.php?MTID=3Dm1237a98124111de3a4c4e61dfaca05d5= > Agenda: = https://datatracker.ietf.org/meeting/interim-2019-cbor-19/materials/agenda= -interim-2019-cbor-19-sessa > Time: = https://www.worldtimebuddy.com/?qm=3D1&lid=3D12,100,5,8&h=3D100&date=3D201= 9-11-06&sln=3D16-17 > =20 > =20 > Talk to you later, > Francesca > =20 > =20 > =20 > Hello, > CBOR Working Group invites you to join this Webex meeting. > =20 > =20 > =20 > CBOR WG Conference Call > Occurs every 2 week(s) on Wednesday effective Wednesday, May 22, 2019 = until Wednesday, November 6, 2019 from 5:00 PM to 6:00 PM, (UTC+01:00) = Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna=20 > 5:00 pm | Europe Summer Time (Amsterdam, GMT+02:00) | 1 hr > =20 > Meeting number (access code): 641 760 157 > =20 > Meeting password: UPAt9rBn > =20 >=20 > =20 > =20 > Add to Calendar > When it's time, join the meeting. > =20 > =20 > =20 > Join by phone > 1-650-479-3208 Call-in toll number (US/Canada) > =20 > =20 > =20 > Can't join the meeting? > =20 > =20 > =20 > IMPORTANT NOTICE: Please note that this Webex service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. > =20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Nov 6 08:08:39 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 9D28512011F for ; Wed, 6 Nov 2019 08:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_FONT_LOW_CONTRAST=0.001, 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 c0P3y_U78M2J for ; Wed, 6 Nov 2019 08:08:34 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50067.outbound.protection.outlook.com [40.107.5.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D47F120885 for ; Wed, 6 Nov 2019 08:08:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dr9mVUIwn54Pb7zAoY36UUGrmkCITIw9Gleij9pa0tTphVO2NN/p47rYqlt+SmhPZXEr04nwW+GTAILHCNFMZrEVaQ8Mu8nCg/IxqgcoJgtTc8X/hwl7lOH41h841jyx3CTv55+3AfCSjK8qCBg57dJRTYpz2eNCGSDt2lqpyFWW3Ba38FYrKFm70GMqEmonbXaWdgsxw8NmThAsIfDTH2ouYukBx30pp215rESfu9moFZ9jScL9OASIktwddm+kHdww0vGws7Vqf45M3gty855zqSG+l63r04pBNZIPvwHr/210W/GjNpKOAF/DeomtuogRNLthSpFbsdVvyDp/9Q== 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=/cjNctDORJgL2MO+dgzLYV4TTB7YsVomJNHFT5RidoE=; b=GK7wgAdvkCoXroAOTSCpSlsOrkMVu8f9SXR9+SNu8MUuv+6R/oQc6LEgPYXm/tkv27NN9K8O28ZlXY1bOOaZSwHOlhPsNENmbWdgA6pkYYqccpvLtzBFrPa2LmtQFgS4p8G/wGK5YvaNgfrMizGEPmnmVTiYkDeduT4i/K6CAyiPCosoxayHA3eUWo2FAr105zjUsGxs2wHYbpbLdkkKL/A9EvH37l+HL8XkHNj0n/AZn92Vpq3XtiYQW6IG1ei+kzZf56zvhVEiqHCXzBQCoTf7sJm2sOgjDdgf/savwdwGMg4t2gwWLonVTofJ4I8g4naJ0xXljmhxc7AoFOhu0A== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/cjNctDORJgL2MO+dgzLYV4TTB7YsVomJNHFT5RidoE=; b=RlNSFHmMI7/fRRIhK0CCdod5wXN2Lhmj/tAd3NXMW5Xo5hVljaMTHrmtkECJkvviNjigS/9X3a7Lah7fihk//7V6UolOrLkS71ExpmsqieCJ4jCRasVRPq2e283yuBirFL/ehdm7cy3m90RX2sUbhFPTaX0ZuyeylgDn99086qg= Received: from VI1PR07MB5469.eurprd07.prod.outlook.com (20.178.14.214) by VI1PR07MB3853.eurprd07.prod.outlook.com (52.134.26.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Wed, 6 Nov 2019 16:08:21 +0000 Received: from VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76]) by VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76%6]) with mapi id 15.20.2430.017; Wed, 6 Nov 2019 16:08:21 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: Jim Schaad Thread-Topic: [Cbor] CBOR Interim: 2019-11-06 Thread-Index: AQHVlLxpEUOhFcEsV0mym/jgiJqeKA== Date: Wed, 6 Nov 2019 16:08:21 +0000 Message-ID: <07363E43-7C09-4333-A5D5-C3864263F7A0@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: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cb6cfc08-edd6-42ca-2312-08d762d38bb8 x-ms-traffictypediagnostic: VI1PR07MB3853: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(376002)(346002)(366004)(53754006)(189003)(199004)(497574002)(256004)(66946007)(6486002)(8676002)(5660300002)(2906002)(44832011)(81166006)(2501003)(2351001)(26005)(5640700003)(6916009)(102836004)(316002)(229853002)(53546011)(6306002)(6246003)(66066001)(71200400001)(14454004)(16799955002)(71190400001)(6436002)(66556008)(6116002)(6512007)(966005)(81156014)(1730700003)(54896002)(486006)(3846002)(478600001)(7736002)(6506007)(236005)(25786009)(86362001)(91956017)(2616005)(606006)(36756003)(476003)(64756008)(76116006)(8936002)(33656002)(66476007)(66446008)(186003)(4326008)(14444005)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3853; H:VI1PR07MB5469.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: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LiuM/+eN+2jmW6Y/YUiHLJ/aWpn6B/iOPn3+roLDP7NWDNIgevAC66ndamklJC3O4oNrD1kW07lHwwvqUedIfvessk0jZXhNBKFh3Gx+FH1N4CsUiXrLAOK8R9gLnIzbPuypyHPxg/iwsR8Mu/jQ6NQmsiXqjY7zD6P4BzkW7WEuUWhM6KRKLTtrDjBeFnaz6qMbYMPfvzP3roT9XJ2JreXCnOyXpaIpYO9sn9KOFs9t4O7BJfXsHoqr3d6r97GB9fxj/Yt+eZmLEZarrAuje/tvGqq4H94tYSFTTTl6rwVxHTpVOdHOFMf06mk5E3p7ECmOFRf9suHJz2JPp0sd1fht1Ba3fG/NpPQdW4nI8CBr/9BpvELs/D/5nwSjpATm1rtLb7Y3CGtCj44IqHk/mybxEzcAIUrxoDxR1Ba1NkQrpP1lsNYiCIbKtiHKXcgDAlezxUApetlNSeyaLKmMcGbvYufv0A2QyAZksuckWuc= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_07363E437C094333A5D5C3864263F7A0ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: cb6cfc08-edd6-42ca-2312-08d762d38bb8 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 16:08:21.6717 (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: sbNQwQj73YM3LYYzr6G9aYyp17KtzeOWQ3SNGZ5IeMD9RwzSf9FJo/atl91rb1IDQ9+070SkveMCfVwvoqlI4wyMCqcrYaAT3HZKL9U9dpOcajvkQ3q9MUjpeNNNiiRL X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3853 Archived-At: Subject: Re: [Cbor] CBOR Interim: 2019-11-06 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, 06 Nov 2019 16:08:37 -0000 --_000_07363E437C094333A5D5C3864263F7A0ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28sIEkgcG9zdGVkIHRoZSB3cm9uZyB0aW1lIGluIHRoZSBhZ2VuZGEsIGJ1dCB0aGUgd29ybGR0 aW1lYnVkZHkgbGluayBiZWxvdyBpcyBjb3JyZWN0LCB0aGUgbWVldGluZyBpcyBub3cuDQoNCkZy YW5jZXNjYQ0KDQoNCkZyb206IENCT1IgPGNib3ItYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxm IG9mIEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJpbmk9NDBlcmljc3Nvbi5j b21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBXZWRuZXNkYXksIDYgTm92ZW1iZXIgMjAxOSBhdCAx MDozNQ0KVG86ICJjYm9yQGlldGYub3JnIiA8Y2JvckBpZXRmLm9yZz4NCkNjOiBDYXJzdGVuIEJv cm1hbm4gPGNhYm9jYWJvQGdtYWlsLmNvbT4sIEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFy cy5jb20+DQpTdWJqZWN0OiBbQ2Jvcl0gQ0JPUiBJbnRlcmltOiAyMDE5LTExLTA2DQoNCkhpIGFs bCwNCg0KVG9kYXnigJlzIGludGVyaW0gd2lsbCBwcm9iYWJseSBiZSBhIHNob3J0IG9uZSwgYnV0 IEkgd2FudCB0byBoYXZlIGEgY2hhdCBhbmQgc2VlIGlmIGFueWJvZHkgd2FzIGFibGUgdG8gcmVh ZCB0aGUgdXBkYXRlIG9uIENCT1IgQ2Fyc3RlbiBwb3N0ZWQgKHRoYW5rcyBDYXJzdGVuISkuIElm IHNvLCB3ZSBjYW4gZGlzY3VzcyBpdCwgb3RoZXJ3aXNlIEkgb25seSBoYXZlIGEgY291cGxlIG9m IHF1aWNrIGl0ZW1zIG9uIHRoZSBhZ2VuZGEgKGFnZW5kYSBzbG90cyBpbiBTaW5nYXBvcmUsIGFu ZCBDRERMIGNvbnRpbnVlZCkuIEkgZG9u4oCZdCB0aGluayB3ZeKAmWxsIHRha2UgdGhlIGZ1bGwg aG91ci4NCg0KDQpXZWJleDogaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9 bTEyMzdhOTgxMjQxMTFkZTNhNGM0ZTYxZGZhY2EwNWQ1DQpBZ2VuZGE6IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMTktY2Jvci0xOS9tYXRlcmlhbHMvYWdl bmRhLWludGVyaW0tMjAxOS1jYm9yLTE5LXNlc3NhDQpUaW1lOiBodHRwczovL3d3dy53b3JsZHRp bWVidWRkeS5jb20vP3FtPTEmbGlkPTEyLDEwMCw1LDgmaD0xMDAmZGF0ZT0yMDE5LTExLTA2JnNs bj0xNi0xNw0KDQoNClRhbGsgdG8geW91IGxhdGVyLA0KRnJhbmNlc2NhDQoNCg0KDQpIZWxsbywN CkNCT1IgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViZXggbWVldGlu Zy4NCg0KDQoNCkNCT1IgV0cgQ29uZmVyZW5jZSBDYWxsDQpPY2N1cnMgZXZlcnkgMiB3ZWVrKHMp IG9uIFdlZG5lc2RheSBlZmZlY3RpdmUgV2VkbmVzZGF5LCBNYXkgMjIsIDIwMTkgdW50aWwgV2Vk bmVzZGF5LCBOb3ZlbWJlciA2LCAyMDE5IGZyb20gNTowMCBQTSB0byA2OjAwIFBNLCAoVVRDKzAx OjAwKSBBbXN0ZXJkYW0sIEJlcmxpbiwgQmVybiwgUm9tZSwgU3RvY2tob2xtLCBWaWVubmENCjU6 MDAgcG0gIHwgIEV1cm9wZSBTdW1tZXIgVGltZSAoQW1zdGVyZGFtLCBHTVQrMDI6MDApICB8ICAx IGhyDQoNCk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0MSA3NjAgMTU3DQoNCk1lZXRp bmcgcGFzc3dvcmQ6IFVQQXQ5ckJuDQoNCg0KDQpBZGQgdG8gQ2FsZW5kYXI8aHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTFkMDYzNjA2OWEyOGJkN2M4Y2MwOTBlNzQxNTY1 YzhjPg0KV2hlbiBpdCdzIHRpbWUsIGpvaW4gdGhlIG1lZXRpbmc8aHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmL2oucGhwP01USUQ9bTEyMzdhOTgxMjQxMTFkZTNhNGM0ZTYxZGZhY2EwNWQ1Pi4N Cg0KDQoNCkpvaW4gYnkgcGhvbmUNCjEtNjUwLTQ3OS0zMjA4PHRlbDolMkIxLTY1MC00NzktMzIw OCwsKjAxKjY0MTc2MDE1NyUyMyUyMyowMSo+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFk YSkNCg0KDQoNCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PGh0dHBzOi8vY29sbGFib3JhdGlvbmhl bHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1Pg0KDQoNCg0KSU1QT1JUQU5UIE5PVElD RTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBv dGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwg d2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0 aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdz LiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBj b25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLg0KDQo= --_000_07363E437C094333A5D5C3864263F7A0ericssoncom_ 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 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxl LW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLUdCIj5TbywgSSBwb3N0ZWQgdGhlIHdyb25nIHRpbWUgaW4gdGhlIGFnZW5kYSwg YnV0IHRoZSB3b3JsZHRpbWVidWRkeSBsaW5rIGJlbG93IGlzIGNvcnJlY3QsIHRoZSBtZWV0aW5n IGlzIG5vdy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1HQiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2s7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPkZyYW5jZXNjYTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Q0JPUiAmbHQ7Y2Jvci1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgRnJhbmNlc2Nh IFBhbG9tYmluaSAmbHQ7ZnJhbmNlc2NhLnBhbG9tYmluaT00MGVyaWNzc29uLmNvbUBkbWFyYy5p ZXRmLm9yZyZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCA2IE5vdmVtYmVyIDIwMTkg YXQgMTA6MzU8YnI+DQo8Yj5UbzogPC9iPiZxdW90O2Nib3JAaWV0Zi5vcmcmcXVvdDsgJmx0O2Ni b3JAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5DYXJzdGVuIEJvcm1hbm4gJmx0O2NhYm9j YWJvQGdtYWlsLmNvbSZndDssIEppbSBTY2hhYWQgJmx0O2lldGZAYXVndXN0Y2VsbGFycy5jb20m Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltDYm9yXSBDQk9SIEludGVyaW06IDIwMTktMTEtMDY8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpIGFsbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Ub2RheeKAmXMgaW50ZXJpbSB3aWxsIHByb2JhYmx5 IGJlIGEgc2hvcnQgb25lLCBidXQgSSB3YW50IHRvIGhhdmUgYSBjaGF0IGFuZCBzZWUgaWYgYW55 Ym9keSB3YXMgYWJsZSB0byByZWFkIHRoZSB1cGRhdGUgb24gQ0JPUiBDYXJzdGVuIHBvc3RlZCAo dGhhbmtzIENhcnN0ZW4hKS4gSWYgc28sIHdlIGNhbiBkaXNjdXNzIGl0LCBvdGhlcndpc2UgSSBv bmx5IGhhdmUNCiBhIGNvdXBsZSBvZiBxdWljayBpdGVtcyBvbiB0aGUgYWdlbmRhIChhZ2VuZGEg c2xvdHMgaW4gU2luZ2Fwb3JlLCBhbmQgQ0RETCBjb250aW51ZWQpLiBJIGRvbuKAmXQgdGhpbmsg d2XigJlsbCB0YWtlIHRoZSBmdWxsIGhvdXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+V2ViZXg6IDxhIGhyZWY9Imh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xMjM3YTk4MTI0MTExZGUzYTRj NGU2MWRmYWNhMDVkNSI+DQpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1t MTIzN2E5ODEyNDExMWRlM2E0YzRlNjFkZmFjYTA1ZDU8L2E+IDwvc3Bhbj4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5BZ2VuZGE6IDwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL21lZXRpbmcvaW50ZXJpbS0yMDE5LWNib3ItMTkvbWF0ZXJpYWxzL2FnZW5kYS1pbnRl cmltLTIwMTktY2Jvci0xOS1zZXNzYSI+PHNwYW4gbGFuZz0iU1YiPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMTktY2Jvci0xOS9tYXRlcmlhbHMvYWdlbmRh LWludGVyaW0tMjAxOS1jYm9yLTE5LXNlc3NhPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaW1lOiA8 L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cud29ybGR0aW1lYnVkZHkuY29tLz9xbT0xJmFtcDts aWQ9MTIsMTAwLDUsOCZhbXA7aD0xMDAmYW1wO2RhdGU9MjAxOS0xMS0wNiZhbXA7c2xuPTE2LTE3 Ij5odHRwczovL3d3dy53b3JsZHRpbWVidWRkeS5jb20vP3FtPTEmYW1wO2xpZD0xMiwxMDAsNSw4 JmFtcDtoPTEwMCZhbXA7ZGF0ZT0yMDE5LTExLTA2JmFtcDtzbG49MTYtMTc8L2E+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UYWxr IHRvIHlvdSBsYXRlciw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJhbmNlc2NhPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIw IiBhbGlnbj0ibGVmdCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0O21hcmdpbi1s ZWZ0OjMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRk aW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2 LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0i MCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8 dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzRENEQ0RCI+SGVsbG8sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwv dHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ny41cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFt ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7 bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3It aG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojNEQ0RDREIj5DQk9SIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0 aGlzIFdlYmV4IG1lZXRpbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0 O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs ZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBj ZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9k eT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBj bSAwY20gMGNtO2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3Bh Y2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRp Y2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhl aWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVu dDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDph cm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1h bmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0 aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1o ZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0RDRENEQiPkNCT1IgV0cgQ29uZmVyZW5jZSBD YWxsPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1l LWhzcGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPk9j Y3VycyBldmVyeSAyIHdlZWsocykgb24gV2VkbmVzZGF5IGVmZmVjdGl2ZSBXZWRuZXNkYXksIE1h eSAyMiwgMjAxOSB1bnRpbCBXZWRuZXNkYXksIE5vdmVtYmVyIDYsIDIwMTkgZnJvbSA1OjAwIFBN IHRvIDY6MDAgUE0sIChVVEMmIzQzOzAxOjAwKSBBbXN0ZXJkYW0sIEJlcmxpbiwgQmVybiwgUm9t ZSwgU3RvY2tob2xtLA0KIFZpZW5uYTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4N Cjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVu dC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQt YW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpj b2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2 NjY2Ij41OjAwIHBtJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwO0V1cm9wZSBTdW1tZXIgVGltZSAo QW1zdGVyZGFtLCBHTVQmIzQzOzAyOjAwKSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsxIGhyPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6 ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJv dW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5j aG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxl IGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9 IjAiIHN0eWxlPSJ3aWR0aDowY20iPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2LjBw dDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFy YWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1 bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPk1lZXRpbmcgbnVtYmVy IChhY2Nlc3MgY29kZSk6IDY0MSA3NjAgMTU3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N CjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0 aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1o ZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9y ZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY20iPg0KPHRi b2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1l O21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDtt c28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1o b3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM2NjY2NjYiPk1lZXRpbmcgcGFzc3dvcmQ6IFVQQXQ5ckJuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtsaW5lLWhlaWdodDoxNS4wcHQ7bXNv LWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50 LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVs ZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0i MCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHls ZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hl aWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1 LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNv LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4 YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28t ZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVs ZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpv bnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNjY2NjY2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1z b05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9 IndpZHRoOjBjbTttaW4td2lkdGg6IDE4NnB4ICFpbXBvcnRhbnQ7YmFja2dyb3VuZC1wb3NpdGlv bjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCjx0 Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207bWluLXdpZHRo OiAxODZweCAhaW1wb3J0YW50Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRl cj0iMSIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9Indp ZHRoOjBjbTtiYWNrZ3JvdW5kOiMwNDhDQkY7Ym9yZGVyOnNvbGlkICMwNDhDQkYgMS41cHQ7bWlu LXdpZHRoOiAxODZweCAhaW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0iYm9y ZGVyOm5vbmU7cGFkZGluZzoxMC41cHQgMTUuMHB0IDEwLjVwdCAxNS4wcHQ7bWluLXdpZHRoOiAx ODZweCAhaW1wb3J0YW50Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzY2NjY2NiI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP01USUQ9bTFkMDYzNjA2OWEyOGJkN2M4Y2MwOTBlNzQxNTY1YzhjIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE1LjBwdDtjb2xvcjp3aGl0ZSI+QWRkIHRvIENhbGVuZGFyPC9zcGFuPjwvYT48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0K PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207bWluLXdpZHRoOiAxODZw eCAhaW1wb3J0YW50Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBj bTttaW4td2lkdGg6IDE4NnB4ICFpbXBvcnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDEyLjBwdDttaW4td2lkdGg6IDE4NnB4ICFpbXBvcnRhbnQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxl bWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3Jh cDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVu dC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5XaGVuIGl0J3MgdGltZSw8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndl YmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTEyMzdhOTgxMjQxMTFkZTNhNGM0ZTYxZGZhY2EwNWQ1 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOSI+am9pbiB0aGUgbWVldGluZzwvc3Bhbj48L2E+ Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+ DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1m cmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5j aG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1 bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWln aHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjE1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21z by1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVu dC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1l bGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50 LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1h bmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNv bHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdp ZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12 ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21z by1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPkpvaW4gYnkgcGhvbmU8L3Nw YW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBh ZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNl OjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNh bDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWln aHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+PGEgaHJl Zj0idGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQxNzYwMTU3JTIzJTIzKjAxKiI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMEFGRjkiPjEtNjUwLTQ3OS0zMjA4PC9zcGFuPjwvYT48L3NwYW4+PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYi PkNhbGwtaW4NCiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+ PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJh bWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hv ci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1u O21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHRhYmxl IGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9 IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0 OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxNS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQt d3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxl bWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1m cmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5j aG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1 bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhz cGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxhIGhy ZWY9Imh0dHBzOi8vY29sbGFib3JhdGlvbmhlbHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5 MDU1Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOSI+Q2FuJ3Qgam9pbiB0aGUgbWVldGluZz88 L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N CjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxl bWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21z by1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3Rs eSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUi IGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMu NzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDo3LjVwdCI+DQo8dGQgc3R5bGU9InBh ZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDo3LjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0 O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs ZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7 bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21z by1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhv cml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFk ZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0 cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1l bnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRh bDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiNB MEEwQTAiPklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2 aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNl c3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdh bCBtYXR0ZXIuIEJ5IGpvaW5pbmcNCiB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNv bnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcg cmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBq b2luIHRoZSBzZXNzaW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_07363E437C094333A5D5C3864263F7A0ericssoncom_-- From nobody Wed Nov 6 08:54:59 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 F25E0120BE8 for ; Wed, 6 Nov 2019 08:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_FONT_LOW_CONTRAST=0.001, 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 D3tUdOl-oyyu for ; Wed, 6 Nov 2019 08:54:43 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40071.outbound.protection.outlook.com [40.107.4.71]) (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 8BEAC120921 for ; Wed, 6 Nov 2019 08:54:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LW33Z/gMW0+85+S91Imq9V7jT+kI2GMGoBAbouSevdmbQ0oZb+v7TFdmdchpYV6h9oBXTgBuZs0qp3Ro+iQfYpygnMLrnP+T1SR5ObEjPuicFmVdr+a+wqaGzpfjiBiUejiYD8ugt3PaxtlwrtF0CyV65n48JkAOuFZXPRwDsJSfbhhFnWdx31OYuStnbjQDooAO+uncqz7b5xhOEhgYaA7Ju4wsVMQP7sEM3O68r0HVEcUMIw2CcBpcvqcNDm4rIk/aORnl8lhnn2FB7LVUIs2k+yyheQxTCaxAnQv6zm51BqmV5opfYMdc9NtZDbV0Lt0k4ByUVSXunnbQza/DRQ== 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=X2kbastXi3asUC+zjHCYoJKbOrJFrMA0W7iuaHRg38g=; b=gtsQbzWxiMe+wnJMgQXDid0Aq22Psxl2azMFjz4x8lr/r2B2uuUq4XtkRG4ebL3/AksRKccs3d1o7KbNhwK4xtwchvoL6X3Q4AZ5ygaDdVVqWcTxlMrXmMjYPo1RfDzvKGTrTTY6RSA8Tr8guY72ZTQLlvLkb3SWe5tr/9JLD3juw8SRElstZxCpgiFelFFB/zYIJzSjoXEvpOEWPrOmxcHUAn0awzjejYwTcwgj1CyNqo4D5tXbSRi6MJVu0+D4mq/4X1zwE1Wwc2FiDo8HlNIcIJmJD2tmmu+1kfhpM8igea0ALZU0r4MvWRAWLVCR/cK+2g6mWDoftgqvLKoiPA== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X2kbastXi3asUC+zjHCYoJKbOrJFrMA0W7iuaHRg38g=; b=W3WIOYbiMwKgX2XcC1gzMT6hgotSOlEyLYhIUU0ECmR+VsGv6viUFTv7IZDASU7Q75QoUU+1k6Mtt7uNU1n853xOoPo+GP+R9ODTzoPqbtUoE+sqj7Z2QTCXnJoJrurOu2dzeP4b29J3/Kr1O/LPfV6jcFQpacWYps7YWHqlAVE= Received: from VI1PR07MB5469.eurprd07.prod.outlook.com (20.178.14.214) by VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Wed, 6 Nov 2019 16:54:39 +0000 Received: from VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76]) by VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76%6]) with mapi id 15.20.2430.017; Wed, 6 Nov 2019 16:54:38 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: Minutes interim 2019-11-06 Thread-Index: AQHVlMLgs78Sn75mQUep5aB+y0uPGg== Date: Wed, 6 Nov 2019 16:54:38 +0000 Message-ID: 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.17.88] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 748e9c7b-21dc-479f-3fe4-08d762da0308 x-ms-traffictypediagnostic: VI1PR07MB3118: x-ms-exchange-purlcount: 9 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(366004)(376002)(136003)(39860400002)(53754006)(199004)(189003)(497574002)(256004)(8936002)(9326002)(6916009)(102836004)(53546011)(6506007)(14444005)(2501003)(5640700003)(25786009)(1730700003)(81156014)(476003)(2616005)(81166006)(3846002)(16799955002)(33656002)(99286004)(5660300002)(316002)(26005)(186003)(36756003)(6512007)(2906002)(91956017)(76116006)(71200400001)(6116002)(8676002)(486006)(86362001)(44832011)(66476007)(66556008)(64756008)(66446008)(6486002)(6436002)(7736002)(236005)(966005)(606006)(66066001)(6306002)(66946007)(54896002)(71190400001)(14454004)(2351001)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3118; H:VI1PR07MB5469.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: 7eML9KgdNAAq11WMzoZGG7RFtw6kiwrvZjBeGpMqZ3piDoKIN2KF/sgZoDIfhDISmnhK5wlgY9PX8mh/G6L53mlgTI3y6FN12Z+XhBMjSgrP2Hmu/ZncxBspyUe3M0r8vxk165HpjqS2OfLrpux6zjLMNHpE6xn9GGNTZONrsAfDfXL3SJSyHuJjNfTrJf8h5hRuLMFCe0UWHk7ZeMq0GAzWGp4nVIOwsBB1tksbaUOEcWFXip1njg0Vt2fo05ajcbaROssysip/J0R4uk7ltppBC7FLEeIb3q5Jpz/0nlWvjw21xSoIEyiNPbTbg4SMgS5+0xyCsYDFcgYxdrbYQWOzhwVf34O23ofL/OnHz+PchYWsx4Y3Yq5LWIYxLj2FlbdsuECwZZgQcY6yaFubI4+t6iu6Z7jB20DoMJBqsLJME2Eb3laVkdBEo+2oTkD1EOJZ6IpiSDJu4E2J9FPFMfbW0V3BhU5ns8WlOJBQPq4= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_B99B66EBA62C4CD08CA036462F71973Bericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 748e9c7b-21dc-479f-3fe4-08d762da0308 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 16:54:38.5301 (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: 7IEGU0DuZvy0fQoe8DBXWSSTH1qLwjKSa/wevc/onpipeJ1xz2jo6+S1bKfLwWQj8ffD/rZSNxfceTTesAcnmywhXNnaBZeyaKYjhGDeYtWjyPZlQtK8nDRVaXd3tqyO X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3118 Archived-At: Subject: [Cbor] Minutes interim 2019-11-06 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, 06 Nov 2019 16:54:49 -0000 --_000_B99B66EBA62C4CD08CA036462F71973Bericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkhlcmUgYXJlIHRoZSBtaW51dGVzIGZyb20gdG9kYXnigJlzIGludGVyaW06IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMTktY2Jvci0xOS9tYXRl cmlhbHMvbWludXRlcy1pbnRlcmltLTIwMTktY2Jvci0xOS0yMDE5MTEwNjE2MDANCg0KUmV2aWV3 ZXJzIG9mIENCT1IsIHBsZWFzZSB0YWtlIGEgbW9tZW50IHRvIHJldmlldyB0aGUgdXBkYXRlIENh cnN0ZW4gbWFkZSwgYW5kIGxldCB1cyBrbm93IG9mIGFueSBjb25jZXJucy9jb21tZW50cy4gRmVl ZGJhY2sgc3RhdGluZyBubyBjb25jZXJucyBpcyBhbHNvIGFwcHJlY2lhdGVkLiBDdXQgYW5kIHBh c3RlZCBmcm9tIENhcnN0ZW7igJlzIG1haWw6DQoNClZlcnNpb24gLTA4Og0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2Jvci03MDQ5YmlzLTA4DQpDb250YWlu cyBhbGwgdGhlIGNoYW5nZXMgdGhhdCB3ZSBoYWQgZG9uZSBhYm91dCBhIHdlZWsgYWdvLCBzbyBz aG91bGQgYmUgcmVsYXRpdmVseSBzdGFibGUuDQoNClZlcnNpb24gLTA5Og0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2Jvci03MDQ5YmlzLTA5DQpoYXMgYWxs IHRoZSBibGVlZGluZyBlZGdlIHN0dWZmIHRoYXQgaGFzIG5vdCBoYWQgYXMgbXVjaCByZXZpZXcu DQoNClRoZXNlIHdlcmUgc3VibWl0dGVkIHNlcGFyYXRlbHkgc28geW91IGNhbiBsb29rIGF0IHRo ZSBjaGFuZ2VzIHNlcGFyYXRlbHkuDQoNCk9mIGNvdXJzZSwgaWYgeW91IHdhbnQgdGhlIGZpcmVo b3NlOg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtY2Jvci03 MDQ5YmlzLTA3JnVybDI9ZHJhZnQtaWV0Zi1jYm9yLTcwNDliaXMtMDkNCg0KDQpTZWUgeW91IGlu IFNpbmdhcG9yZSwNCkZyYW5jZXNjYQ0KDQpGcm9tOiBDQk9SIDxjYm9yLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOmNib3ItYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBGcmFuY2VzY2Eg UGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYu b3JnPG1haWx0bzpmcmFuY2VzY2EucGFsb21iaW5pPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYu b3JnPj4NCkRhdGU6IFdlZG5lc2RheSwgNiBOb3ZlbWJlciAyMDE5IGF0IDEwOjM1DQpUbzogImNi b3JAaWV0Zi5vcmc8bWFpbHRvOmNib3JAaWV0Zi5vcmc+IiA8Y2JvckBpZXRmLm9yZzxtYWlsdG86 Y2JvckBpZXRmLm9yZz4+DQpDYzogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvY2Fib0BnbWFpbC5jb208 bWFpbHRvOmNhYm9jYWJvQGdtYWlsLmNvbT4+LCBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxh cnMuY29tPG1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPj4NClN1YmplY3Q6IFtDYm9yXSBD Qk9SIEludGVyaW06IDIwMTktMTEtMDYNCg0KSGkgYWxsLA0KDQpUb2RheeKAmXMgaW50ZXJpbSB3 aWxsIHByb2JhYmx5IGJlIGEgc2hvcnQgb25lLCBidXQgSSB3YW50IHRvIGhhdmUgYSBjaGF0IGFu ZCBzZWUgaWYgYW55Ym9keSB3YXMgYWJsZSB0byByZWFkIHRoZSB1cGRhdGUgb24gQ0JPUiBDYXJz dGVuIHBvc3RlZCAodGhhbmtzIENhcnN0ZW4hKS4gSWYgc28sIHdlIGNhbiBkaXNjdXNzIGl0LCBv dGhlcndpc2UgSSBvbmx5IGhhdmUgYSBjb3VwbGUgb2YgcXVpY2sgaXRlbXMgb24gdGhlIGFnZW5k YSAoYWdlbmRhIHNsb3RzIGluIFNpbmdhcG9yZSwgYW5kIENEREwgY29udGludWVkKS4gSSBkb27i gJl0IHRoaW5rIHdl4oCZbGwgdGFrZSB0aGUgZnVsbCBob3VyLg0KDQoNCldlYmV4OiBodHRwczov L2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMTIzN2E5ODEyNDExMWRlM2E0YzRlNjFk ZmFjYTA1ZDUNCkFnZW5kYTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2lu dGVyaW0tMjAxOS1jYm9yLTE5L21hdGVyaWFscy9hZ2VuZGEtaW50ZXJpbS0yMDE5LWNib3ItMTkt c2Vzc2ENClRpbWU6IGh0dHBzOi8vd3d3LndvcmxkdGltZWJ1ZGR5LmNvbS8/cW09MSZsaWQ9MTIs MTAwLDUsOCZoPTEwMCZkYXRlPTIwMTktMTEtMDYmc2xuPTE2LTE3DQoNCg0KVGFsayB0byB5b3Ug bGF0ZXIsDQpGcmFuY2VzY2ENCg0KDQoNCkhlbGxvLA0KQ0JPUiBXb3JraW5nIEdyb3VwIGludml0 ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJleCBtZWV0aW5nLg0KDQoNCg0KQ0JPUiBXRyBDb25mZXJl bmNlIENhbGwNCk9jY3VycyBldmVyeSAyIHdlZWsocykgb24gV2VkbmVzZGF5IGVmZmVjdGl2ZSBX ZWRuZXNkYXksIE1heSAyMiwgMjAxOSB1bnRpbCBXZWRuZXNkYXksIE5vdmVtYmVyIDYsIDIwMTkg ZnJvbSA1OjAwIFBNIHRvIDY6MDAgUE0sIChVVEMrMDE6MDApIEFtc3RlcmRhbSwgQmVybGluLCBC ZXJuLCBSb21lLCBTdG9ja2hvbG0sIFZpZW5uYQ0KNTowMCBwbSAgfCAgRXVyb3BlIFN1bW1lciBU aW1lIChBbXN0ZXJkYW0sIEdNVCswMjowMCkgIHwgIDEgaHINCg0KTWVldGluZyBudW1iZXIgKGFj Y2VzcyBjb2RlKTogNjQxIDc2MCAxNTcNCg0KTWVldGluZyBwYXNzd29yZDogVVBBdDlyQm4NCg0K DQoNCkFkZCB0byBDYWxlbmRhcjxodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tMWQwNjM2MDY5YTI4YmQ3YzhjYzA5MGU3NDE1NjVjOGM+DQpXaGVuIGl0J3MgdGltZSwgam9p biB0aGUgbWVldGluZzxodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMTIz N2E5ODEyNDExMWRlM2E0YzRlNjFkZmFjYTA1ZDU+Lg0KDQoNCg0KSm9pbiBieSBwaG9uZQ0KMS02 NTAtNDc5LTMyMDg8dGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQxNzYwMTU3JTIzJTIzKjAx Kj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKQ0KDQoNCg0KQ2FuJ3Qgam9pbiB0aGUg bWVldGluZz88aHR0cHM6Ly9jb2xsYWJvcmF0aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgw MDAwMjkwNTU+DQoNCg0KDQpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMg V2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVy aW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxl IGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRp Y2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0 byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3Ig ZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uDQoNCg0K --_000_B99B66EBA62C4CD08CA036462F71973Bericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <035E885C0DB15C41B8566320B9C5B12E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQt c3RhbmRhcmQ7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uYXBw bGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFj ZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGksPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRv O3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93 czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5IZXJlIGFyZSB0aGUgbWludXRlcyBmcm9tIHRvZGF54oCZcyBpbnRlcmltOjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvaW50ZXJpbS0yMDE5LWNib3ItMTkvbWF0ZXJpYWxz L21pbnV0ZXMtaW50ZXJpbS0yMDE5LWNib3ItMTktMjAxOTExMDYxNjAwIj48c3BhbiBzdHlsZT0i Y29sb3I6Izk1NEY3MiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVy aW0tMjAxOS1jYm9yLTE5L21hdGVyaWFscy9taW51dGVzLWludGVyaW0tMjAxOS1jYm9yLTE5LTIw MTkxMTA2MTYwMDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13 ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0 bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZXZpZXdlcnMgb2YgQ0JPUiwgcGxlYXNlIHRha2Ug YSBtb21lbnQgdG8gcmV2aWV3IHRoZSB1cGRhdGUgQ2Fyc3RlbiBtYWRlLCBhbmQgbGV0IHVzIGtu b3cgb2YgYW55IGNvbmNlcm5zL2NvbW1lbnRzLiBGZWVkYmFjayBzdGF0aW5nIG5vIGNvbmNlcm5z IGlzIGFsc28gYXBwcmVjaWF0ZWQuIEN1dCBhbmQgcGFzdGVkIGZyb20gQ2Fyc3RlbuKAmXMgbWFp bDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6 IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7 d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPlZlcnNpb24gLTA4OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Vi a2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jYm9yLTcwNDliaXMt MDgiIHRpdGxlPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1j Ym9yLTcwNDliaXMtMDgiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5odHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jYm9yLTcwNDliaXMtMDg8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJl dC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczog YXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1 c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgi Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Db250YWlucyBhbGwgdGhlIGNoYW5nZXMgdGhh dCB3ZSBoYWQgZG9uZSBhYm91dCBhIHdlZWsgYWdvLCBzbyBzaG91bGQgYmUgcmVsYXRpdmVseSBz dGFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBo YW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0 YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5WZXJzaW9uIC0wOTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87 LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2Jvci03MDQ5 YmlzLTA5IiB0aXRsZT0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtY2Jvci03MDQ5YmlzLTA5Ij48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2Jvci03MDQ5YmlzLTA5PC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhh bnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUt YWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+aGFzIGFsbCB0aGUgYmxlZWRpbmcgZWRn ZSBzdHVmZiB0aGF0IGhhcyBub3QgaGFkIGFzIG11Y2ggcmV2aWV3LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0 YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtp dC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3 b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlc2Ugd2VyZSBz dWJtaXR0ZWQgc2VwYXJhdGVseSBzbyB5b3UgY2FuIGxvb2sgYXQgdGhlIGNoYW5nZXMgc2VwYXJh dGVseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhh bnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUt YWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3Rh cnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPk9mIGNvdXJzZSwgaWYgeW91IHdhbnQgdGhlIGZpcmVob3NlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFs aWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDE9ZHJhZnQtaWV0Zi1jYm9yLTcwNDliaXMtMDcmYW1wO3VybDI9ZHJhZnQtaWV0Zi1jYm9yLTcw NDliaXMtMDkiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5odHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1jYm9yLTcwNDliaXMtMDcmYW1wO3VybDI9ZHJhZnQt aWV0Zi1jYm9yLTcwNDliaXMtMDk8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93 czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29y cGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNp emUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwg MCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246 c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPlNlZSB5b3UgaW4gU2luZ2Fwb3JlLDxicj4NCkZyYW5jZXNjYTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0 LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5DQk9SICZsdDs8YSBocmVmPSJtYWlsdG86Y2Jvci1ib3VuY2Vz QGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+Y2Jvci1ib3VuY2VzQGlldGYu b3JnPC9zcGFuPjwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBGcmFuY2VzY2ENCiBQYWxvbWJpbmkgJmx0 OzxhIGhyZWY9Im1haWx0bzpmcmFuY2VzY2EucGFsb21iaW5pPTQwZXJpY3Nzb24uY29tQGRtYXJj LmlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+ZnJhbmNlc2NhLnBhbG9tYmlu aT00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkRh dGU6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5X ZWRuZXNkYXksIDYgTm92ZW1iZXIgMjAxOSBhdCAxMDozNTxicj4NCjxiPlRvOjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmNib3JAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5jYm9yQGll dGYub3JnPC9zcGFuPjwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjYm9yQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+Y2JvckBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0 Ozxicj4NCjxiPkNjOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48L2I+Q2Fyc3RlbiBCb3JtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86Y2Fib2NhYm9AZ21h aWwuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+Y2Fib2NhYm9AZ21haWwuY29tPC9z cGFuPjwvYT4mZ3Q7LCBKaW0gU2NoYWFkICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBhdWd1c3Rj ZWxsYXJzLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmlldGZAYXVndXN0Y2VsbGFy cy5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+W0Nib3JdIENCT1IgSW50ZXJpbTogMjAx OS0xMS0wNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBh dXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkhp IGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhh bnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUt YWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3Rh cnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPlRvZGF54oCZcyBpbnRlcmltIHdpbGwgcHJvYmFibHkgYmUgYSBzaG9ydCBvbmUs IGJ1dCBJIHdhbnQgdG8gaGF2ZSBhIGNoYXQgYW5kIHNlZSBpZiBhbnlib2R5IHdhcyBhYmxlIHRv IHJlYWQgdGhlIHVwZGF0ZSBvbiBDQk9SIENhcnN0ZW4gcG9zdGVkICh0aGFua3MgQ2Fyc3RlbiEp LiBJZiBzbywgd2UgY2FuIGRpc2N1c3MgaXQsIG90aGVyd2lzZSBJIG9ubHkgaGF2ZSBhIGNvdXBs ZSBvZiBxdWljayBpdGVtcw0KIG9uIHRoZSBhZ2VuZGEgKGFnZW5kYSBzbG90cyBpbiBTaW5nYXBv cmUsIGFuZCBDRERMIGNvbnRpbnVlZCkuIEkgZG9u4oCZdCB0aGluayB3ZeKAmWxsIHRha2UgdGhl IGZ1bGwgaG91ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs O29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0 LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxp Z246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzst d2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5XZWJleDo8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTEyMzdhOTgxMjQxMTFkZTNh NGM0ZTYxZGZhY2EwNWQ1Ij48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTEyMzdhOTgxMjQxMTFkZTNhNGM0ZTYxZGZhY2Ew NWQ1PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10 ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3Jk LXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QWdlbmRhOjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvaW50ZXJpbS0yMDE5LWNib3ItMTkvbWF0ZXJp YWxzL2FnZW5kYS1pbnRlcmltLTIwMTktY2Jvci0xOS1zZXNzYSI+PHNwYW4gc3R5bGU9ImNvbG9y OiM5NTRGNzIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIw MTktY2Jvci0xOS9tYXRlcmlhbHMvYWdlbmRhLWludGVyaW0tMjAxOS1jYm9yLTE5LXNlc3NhPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29y cGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNp emUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGltZTo8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cud29y bGR0aW1lYnVkZHkuY29tLz9xbT0xJmFtcDtsaWQ9MTIsMTAwLDUsOCZhbXA7aD0xMDAmYW1wO2Rh dGU9MjAxOS0xMS0wNiZhbXA7c2xuPTE2LTE3Ij48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+ aHR0cHM6Ly93d3cud29ybGR0aW1lYnVkZHkuY29tLz9xbT0xJmFtcDtsaWQ9MTIsMTAwLDUsOCZh bXA7aD0xMDAmYW1wO2RhdGU9MjAxOS0xMS0wNiZhbXA7c2xuPTE2LTE3PC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87 dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBh dXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dz OiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3Jw aGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6 ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2lu ZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UYWxrIHRvIHlvdSBsYXRlciw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87 dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBh dXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJhbmNlc2NhPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lk b3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQt c2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxw YWRkaW5nPSIwIiBhbGlnbj0ibGVmdCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0 O21hcmdpbi1sZWZ0OjMuNzVwdDtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO29ycGhhbnM6IGF1 dG87d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8dGJvZHk+DQo8dHI+DQo8 dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1l O21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDtt c28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1o b3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM2NjY2NjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFz cz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUi IHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRp bmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYu MHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzRENEQ0RCI+SGVsbG8sPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6 Ny41cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4w cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBh cmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1y dWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNEQ0RDREIj5DQk9SIFdvcmtpbmcg R3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYmV4IG1lZXRpbmcuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1l bGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6 b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJN c29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5 bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+ DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxNS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpm cmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91 bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNo b3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K PC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3Bh Y2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRp Y2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhl aWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+ DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6 ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJv dW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5j aG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0 RDRENEQiPkNCT1IgV0cgQ29uZmVyZW5jZSBDYWxsPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVt ZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFw OmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50 LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPk9jY3VycyBldmVyeSAyIHdlZWsocykgb24gV2VkbmVz ZGF5IGVmZmVjdGl2ZSBXZWRuZXNkYXksIE1heSAyMiwgMjAxOSB1bnRpbCBXZWRuZXNkYXksIE5v dmVtYmVyIDYsIDIwMTkgZnJvbSA1OjAwIFBNIHRvIDY6MDAgUE0sIChVVEMmIzQzOzAxOjAwKSBB bXN0ZXJkYW0sIEJlcmxpbiwgQmVybiwgUm9tZSwgU3RvY2tob2xtLA0KIFZpZW5uYTxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDtt c28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1l bnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28t ZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHki Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij41OjAwIHBtJm5ic3A7Jm5ic3A7fCZuYnNw OyZuYnNwO0V1cm9wZSBTdW1tZXIgVGltZSAoQW1zdGVyZGFtLCBHTVQmIzQzOzAyOjAwKSZuYnNw OyZuYnNwO3wmbmJzcDsmbmJzcDsxIGhyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwv dHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNl OjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNh bDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWln aHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVy PSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY20iPg0KPHRib2R5 Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21z by1lbGVtZW50LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM2NjY2NjYiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0MSA3NjAgMTU3PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6 ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJv dW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5j aG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxl IGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9 IjAiIHN0eWxlPSJ3aWR0aDowY20iPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2LjBw dDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFy YWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1 bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPk1lZXRpbmcgcGFzc3dv cmQ6IFVQQXQ5ckJuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5 Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdDtsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJh bWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hv ci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1u O21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJs ZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5 My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1l bnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRh bDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj NjY2NjY2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJv ZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1 LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNv LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4 YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxw YWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbTttaW4td2lkdGg6IDE4NnB4ICFp bXBvcnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt IDBjbTttaW4td2lkdGg6IDE4NnB4ICFpbXBvcnRhbnQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt YWxUYWJsZSIgYm9yZGVyPSIxIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRo PSIwIiBzdHlsZT0id2lkdGg6MGNtO2JhY2tncm91bmQ6IzA0OENCRjtib3JkZXI6c29saWQgIzA0 OENCRiAxLjVwdDttaW4td2lkdGg6IDE4NnB4ICFpbXBvcnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0K PHRkIHN0eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5nOjEwLjVwdCAxNS4wcHQgMTAuNXB0IDE1LjBw dDttaW4td2lkdGg6IDE4NnB4ICFpbXBvcnRhbnQ7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFs IGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhl aWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYu MHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+PGEgaHJlZj0iaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTFkMDYzNjA2OWEyOGJkN2M4Y2Mw OTBlNzQxNTY1YzhjIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtjb2xvcjp3aGl0ZSI+ QWRkIHRvIENhbGVuZGFyPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K PC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20g MGNtIDBjbSAwY207bWluLXdpZHRoOiAxODZweCAhaW1wb3J0YW50Ij4NCjx0YWJsZSBjbGFzcz0i TXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIw IiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbTttaW4td2lkdGg6IDE4NnB4ICFpbXBvcnRhbnQi Pg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDEyLjBwdDtt aW4td2lkdGg6IDE4NnB4ICFpbXBvcnRhbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1o c3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZl cnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNv LWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5XaGVu IGl0J3MgdGltZSw8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTEyMzdh OTgxMjQxMTFkZTNhNGM0ZTYxZGZhY2EwNWQ1Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOSI+ am9pbiB0aGUgbWVldGluZzwvc3Bhbj48L2E+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3Rh YmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQt d3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxl bWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0K Jm5ic3A7PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQi Pg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGlu ZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZy YW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNo b3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVt bjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv dGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21z by1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVu dC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1l bGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+ DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJv cmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVw dCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1l bnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM2NjY2NjYiPkpvaW4gYnkgcGhvbmU8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N CjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzY2NjY2NiI+PGEgaHJlZj0idGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEq NjQxNzYwMTU3JTIzJTIzKjAxKiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFGRjkiPjEtNjUwLTQ3 OS0zMjA4PC9zcGFuPjwvYT48L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPkNhbGwtaW4NCiB0b2xsIG51bWJlciAoVVMvQ2Fu YWRhKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJs ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVs ZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdy YXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1l bnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVy PSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4N Cjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6 MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFt ZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9y LXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47 bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3Rh YmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVsZW1lbnQt d3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxl bWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0K Jm5ic3A7PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQi Pg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFy b3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFu Y2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxhIGhyZWY9Imh0dHBzOi8vY29sbGFib3JhdGlvbmhlbHAu Y2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZG OSI+Q2FuJ3Qgam9pbiB0aGUgbWVldGluZz88L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50 LWZyYW1lLWhzcGFjZTo2LjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1h bmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNv bHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdp ZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9Imhl aWdodDo3LjVwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDo3 LjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1l bGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6 b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjYuMHB0 O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs ZTpleGFjdGx5Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9Indp ZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Ni4wcHQ7bXNvLWVs ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0 bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiNBMEEwQTAiPklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFz ZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5m b3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1h eSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcNCiB0aGlzIHNl c3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5 b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJu cyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4N CjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRv O3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B99B66EBA62C4CD08CA036462F71973Bericssoncom_-- From nobody Wed Nov 6 09:11:24 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 2E9BC1209D7; Wed, 6 Nov 2019 09:11:20 -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 BYEJ9kRHrKiM; Wed, 6 Nov 2019 09:11:17 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60084.outbound.protection.outlook.com [40.107.6.84]) (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 8D27F1209B3; Wed, 6 Nov 2019 09:11:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NyarOn3WaoF25kT3YyxZYKomZ4ZVnt6kPqdMV/Rq0uI8EzcSRJEado3+H6D7Uh+jaaKLeoyqqTGJ5Q+J3n4SPZNtKGcrp7ph2C8cBbCizbmiclFGhlirUhuK9QCNBlHn9GRXlsZEzgaa5OHy23c+XWX7kuIwiEtseKs5aKFaFvDn4La3Mgz0KVUmJopjte7CSu7Mv0DDWvLotOtHtcC4DC5em7DLl8OezZcO+mYQQwTiNnVb1eVvlFwrwnmE887wCQ4VWmcbQ+WGUj9to9+0YRKfCYf6PUGMTl+TV2Kc+a8hkF4ZB80CwY/CMFWIuje7ZjCHc+Nzb5n2GiKoL6P22w== 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=w3bWssVq2ztmuvRnM8jUUByvnh2LfgvvovUOJEDFioA=; b=jQ6GFg05wybJoixQescgeLAET5j7DPcejzaCmW7hmRGEh4FkrIcDQdYLQmi6YpJwuT09oadMhB6zvdhM7J1CJHzomLcfHNiGxOwja6wvsK2VqLOp1bBIqW0moiycSmJ1aRhNQ0/mQlwmzsBIMWUgyLMNr0gDxmYEuxWWjEnzpRtxzs4ObBG9iGsMYJeO6Q1yY6LYxeMp6SElBxVkhh+OjUmdQvr+0mDP5JDD2OjejpzSvLIOypt7PCJyhr8l6Gg0Euwxmge81wVaUcy3cz92tHynvMlUgqx5QjDcoGr0vfuS8++bshCodRaHQzBmJ08spMxVT+GLr1h+piwiYevo6w== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w3bWssVq2ztmuvRnM8jUUByvnh2LfgvvovUOJEDFioA=; b=LLz/MhlORWgePAYW0+2p8ptAx2JYTd1OviFjFVhGkMvkaCCWL/O/+cKRpXfVx7JnXNcuYNpyATttlD0+NIevyMHQW33Fq6ZsHOT4Zs8oCnH1BW8czwbvWVpTLrXVNmRbfB6AXhNrpEJwDs4MnTJ4082R6s0M64ZHTHLTCHWEPZY= Received: from VI1PR07MB5469.eurprd07.prod.outlook.com (20.178.14.214) by VI1PR07MB4525.eurprd07.prod.outlook.com (20.177.57.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Wed, 6 Nov 2019 17:11:13 +0000 Received: from VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76]) by VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76%6]) with mapi id 15.20.2430.017; Wed, 6 Nov 2019 17:11:13 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: IETF106 agenda Thread-Index: AQHVlMUwbZvE2ljsIkeDMkQUTHKzCw== Date: Wed, 6 Nov 2019 17:11:12 +0000 Message-ID: <3C487045-FFA3-4DC2-82E3-FB885BA34D44@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.17.88] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ab79ac72-3c29-4b1f-5c92-08d762dc53b5 x-ms-traffictypediagnostic: VI1PR07MB4525: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(346002)(366004)(396003)(39860400002)(189003)(199004)(8676002)(6306002)(26005)(5660300002)(36756003)(66066001)(54896002)(66946007)(66556008)(9326002)(64756008)(66446008)(66476007)(4326008)(2616005)(476003)(186003)(236005)(6512007)(76116006)(91956017)(6506007)(44832011)(2906002)(450100002)(7116003)(33656002)(2351001)(966005)(3846002)(478600001)(558084003)(99286004)(316002)(14454004)(5640700003)(81156014)(1730700003)(606006)(7736002)(81166006)(86362001)(71200400001)(2501003)(486006)(8936002)(6436002)(102836004)(6486002)(6916009)(71190400001)(25786009)(6116002)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4525; H:VI1PR07MB5469.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: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: R3RQOx5KqVCh00naTIb18fQmDsPqPZwhL6lXiARyQm+rBeWqi9Yl8Tn7HfSwvI0ZsH96MbdGmAOB2Bf7RTIkY8lYViSKZ1HCOQFryPzV9oXsrRULayirbgikcly47/lekPDsPg3lfdTRFx02ODZF5UPPRXHWA1sR2U4PfprAckmI/Iam0dWqT8xLJYGMCMltmjbjh10l+HflfrvgYFCgnhjfSVux4GVifupKSyAxvRrVrDOULFUNptu2LMELHQvjVVYQSnWi3zqSlgHY5AlocJfPqwajseVP9/hjapvPDgKJulJJlLwZoDVO/+eGCM3kK9JUZri57IwOVApICL3p47AR6BKsyDyhPve/CDxtKNbKbAnuGpD8UgEflPi/dXquy1r4FR5GiUKRZUrPcpj/mxoWVpIpFW221Z/cEnuxFqJGsjRzU8HNdnoI3z72D7/xNRcpXgAQODEAf5r5hbvdGMcfMAYTJMPQGw7GxtA47xg= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3C487045FFA34DC282E3FB885BA34D44ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ab79ac72-3c29-4b1f-5c92-08d762dc53b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 17:11:13.1417 (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: Vi2g2A5g+u0BclbGfOzpZS6ilskzH+hhp4/MYkTaOdSWY+cxQWjDeBY2kIrYe4/Tm6u4SPuzA5kvNCT5NNVaYdWALV0obQ5Gxx6w7zrhaT9ggq4qS5nVDXw7hpUaHVdY X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4525 Archived-At: Subject: [Cbor] IETF106 agenda 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, 06 Nov 2019 17:11:23 -0000 --_000_3C487045FFA34DC282E3FB885BA34D44ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkEgZHJhZnQgYWdlbmRhIGZvciBJRVRGMTA2IGhhcyBiZWVuIHVwbG9hZGVkIHRvIHRo ZSBkYXRhdHJhY2tlcjoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDYv bWF0ZXJpYWxzL2FnZW5kYS0xMDYtY2Jvci0wMC50eHQNCg0KUGxlYXNlIGxldCB1cyBjaGFpcnMg a25vdyBpZiB5b3UgaGF2ZSBhbnkgZmVlZGJhY2sgYWJvdXQgdGltZXNsb3RzLCBhbmQgaWYgeW91 J2QgbGlrZSB0byBhZGQgKG9yIHJlbW92ZSkgaXRlbXMuDQoNClRoYW5rcywNCkZyYW5jZXNjYQ0K --_000_3C487045FFA34DC282E3FB885BA34D44ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <7988CDBB9EA986409A10C8F3451891CD@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkEgZHJhZnQgYWdlbmRhIGZvciBJRVRGMTA2 IGhhcyBiZWVuIHVwbG9hZGVkIHRvIHRoZSBkYXRhdHJhY2tlcjo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwNi9tYXRlcmlh bHMvYWdlbmRhLTEwNi1jYm9yLTAwLnR4dCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9t ZWV0aW5nLzEwNi9tYXRlcmlhbHMvYWdlbmRhLTEwNi1jYm9yLTAwLnR4dDwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBsZWFzZSBsZXQgdXMgY2hhaXJzIGtu b3cgaWYgeW91IGhhdmUgYW55IGZlZWRiYWNrIGFib3V0IHRpbWVzbG90cywgYW5kIGlmIHlvdSdk IGxpa2UgdG8gYWRkIChvciByZW1vdmUpIGl0ZW1zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5GcmFuY2VzY2E8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3C487045FFA34DC282E3FB885BA34D44ericssoncom_-- From nobody Wed Nov 6 09:12: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 9B46D120875; Wed, 6 Nov 2019 09:12:41 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tU9mzR50_O8x; Wed, 6 Nov 2019 09:12:39 -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 94E57120860; Wed, 6 Nov 2019 09:12:39 -0800 (PST) Received: from [192.168.217.102] (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 477Y4j4pvGzyWt; Wed, 6 Nov 2019 18:12:37 +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: Date: Wed, 6 Nov 2019 18:12:37 +0100 Cc: Deborah Brungard , Alvaro Retana , t2trg@irtf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 594753155.580314-500b73e88c3ba69976f774d2d4016f76 Content-Transfer-Encoding: quoted-printable Message-Id: <26630BB7-A8A6-4A35-BF22-22CEDFDBE3E3@tzi.org> References: <4BD0608C-A277-4130-B85C-D7A75FAEFD8F@smcquistin.uk> To: "hackathon@ietf.org" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] [hackathon] Formal Languages at the Hackathon 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, 06 Nov 2019 17:12:42 -0000 On Nov 6, 2019, at 17:52, Antoni Przygienda = wrote: >=20 > enhance GRPC or thrift There are several of these integrated modeling language + encoding = scheme ecosystems we could latch ourselves up to. Actually we did that = already with ASN.1 a long time ago, and it is interesting what people = who have used it for a few decades now think about it (*). Obviously there are some requirements for data modeling (mostly around = handling evolution) that are better served by using a mature FDT = approach than by graphical representation of various encoding stages = (the =E2=80=9Cbox notation=E2=80=9D we love from RFC79x etc.). =20 When the encoding dominates your thinking, they get in the way (e.g., = look at how HTTP/2 is encoded). So being able to describe an arbitrary = bespoke encoding with an FDT (like Quentin=E2=80=99s work or YOUPI do, = within the limits of their expressibility) may be useful in those = spaces. When the complexity of the data being modeled dominates your thinking, = you want a solid encoding scheme such as XML or JSON or CBOR (or you can = do the latch-up alluded to above). For standards that are expected to live for a while (=E2=80=9Cdesign for = decades=E2=80=9D), I prefer situations where the encoding scheme has a = life of its own, independent of the FDT, so you can swap your FDT if the = old one is broken (just as we moved from W3C XSD to Relax-NG for most = XML work). The integrated approaches may have their own advantages, = especially in the time-to-market department, while usually wedding you = to a specific toolchain (or tool ecosystem, as with ASN.1). Gr=C3=BC=C3=9Fe, Carsten (*) Especially after you compensate for the inevitable occurrence of = Stockholm syndrome. From nobody Wed Nov 6 09:16: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 304BA120072 for ; Wed, 6 Nov 2019 09:16:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEbL79jCJktm for ; Wed, 6 Nov 2019 09:16:24 -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 61776120071 for ; Wed, 6 Nov 2019 09:16:24 -0800 (PST) Received: from [192.168.217.102] (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 477Y9275DSzymQ; Wed, 6 Nov 2019 18:16:22 +0100 (CET) From: Carsten Bormann Content-Type: multipart/alternative; boundary="Apple-Mail=_EC89DECC-B784-4A4B-8D8C-C5626E9A46A3" X-Mao-Original-Outgoing-Id: 594753380.4711601-3d13068ba28b8658cd77faa116286851 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 6 Nov 2019 18:16:22 +0100 Message-Id: <8C96C2EF-31B5-4ACD-BDFE-11E671BEE06F@tzi.org> References: To: cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] Fwd: [hackathon] Formal Languages at the Hackathon 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, 06 Nov 2019 17:16:27 -0000 --Apple-Mail=_EC89DECC-B784-4A4B-8D8C-C5626E9A46A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Interesting discussion at the hackathon mailing list=E2=80=A6 BTW, we are thinking about getting together in a corner of the hackathon = room with all the people that work on a hackathon project that employs = CBOR, so we can have some chatting about cross-pollination and = coordination of that side as well. Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: Carsten Bormann > Subject: Re: [hackathon] Formal Languages at the Hackathon > Date: November 6, 2019 at 16:40:11 GMT+1 > To: hackathon@ietf.org > Cc: Carsten Bormann > Archived-At: = >=20 > I=E2=80=99m sharing the below with t2trg as it appears to be highly = related to some of our current work. >=20 > I=E2=80=99d also like to point out that formal description techniques = (FDT) have been used a lot at the IETF and the IRTF: >=20 > * we know very well how to use ABNF (RFC 5234) for our text-based = protocols. We don=E2=80=99t really have a good way to work with = multiple layers of ABNF, though; see the difference between RFC 5988 and = RFC 8288 for some recent improvements (but the link between the layers = is not formal). ABNF tools exist for both checking ABNF specs and for = automatically generating instances (examples). >=20 > * specific areas have had their FDTs, e.g. RFC 4997 for ROHC, YANG for = management, etc. Specifically YANG is increasingly used not only for = its original purpose, describing management information bases, but also = for data on the wire (yang-data). YOUPI [1] is an interesting YANG = extension for describing arbitrary binary data. >=20 > [1]: https://tools.ietf.org/html/draft-petrov-t2trg-youpi >=20 > * some RFCs were to a large extent machine-generated text (e.g., RFC = 7400) or machine-verified (e.g., RFC 8428), based on models in various = FDTs. Some of these are very domain-specific, but we could still be = better on sharing tools (and long-term preserving the sources that = generated those RFCs). >=20 > * there is a lively discussion about adding (structural) data modeling = (a.k.a. =E2=80=9Cschemas=E2=80=9D) to JSON over at the mailing list of = the closed JSON WG (e.g., [2]). While that discussion is ongoing, we = already have CDDL (RFC 8610) for structurally modeling CBOR and JSON = data. Maybe one size does not fit all here. Similar to ABNF, CDDL = tools can check specs, verify instances against a spec, extract/generate = code snippets from specs, and generate instances/examples from specs. = One next step here is adding links to application semantics. >=20 > [2]: https://tools.ietf.org/html/draft-ucarion-jddf >=20 > * the WISHI activity in T2TRG looks at modeling data shapes, = interaction modeling, and potentially adding protocol bindings towards = the wire and application semantics towards the application. Several = SDOs are providing interesting study subjects, e.g., W3C WoT with their = Thing Description (TD) [3] and the still somewhat stealthy OneDM group = with the Simple Definition Format (SDF) [4]. We=E2=80=99ll discuss this = on the Friday before the IETF [5] and work on tools for it at the = Hackathon (look for =E2=80=9CWISHI=E2=80=9D). >=20 > [3]: https://www.w3.org/TR/wot-thing-description/ > [4]: https://github.com/one-data-model/language/blob/master/sdf.md > [5]: https://github.com/t2trg/2019-11-singapore > (Yes, you can still register.) >=20 > I understand that the =E2=80=9CFormal Languages=E2=80=9D activity = mostly addresses their use in IETF specifications, and I like that angle = =E2=80=94 there are other uses of formal description techniques that = possible have a different set of requirements, which sometimes cause the = requirements of spec writers to be forgotten [6]. >=20 > [6]: = https://www.iab.org/wp-content/IAB-uploads/2016/03/Noise-in-specifications= -hurts.pdf >=20 > So I=E2=80=99m really looking forward to the discussions on Friday, = November 15th [5] and at the Hackathon. Getting something going on = cross-pollinating and coordinating the various FDT activities at IETF = and IRTF might be a good medium term goal. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 >> On Nov 6, 2019, at 11:09, Stephen McQuistin wrote: >>=20 >> Hi all, >>=20 >> Marc Petit-Huguenin and I are championing formal languages projects = at the hackathon in Singapore. Broadly, these >> projects seek to improve the quality of standards by using formal and = structured languages in specification documents. >> These documents can then be parsed by tooling that can, for example, = generate parser code or verify properties for the >> protocol being specified. >>=20 >> There will be two formal languages projects being worked on: = Augmented Packet Header Diagrams and Computerate >> Specifying. Details for both projects are available on the Wiki at = https://trac.ietf.org/trac/ietf/meeting/wiki/106hackathon/formal-languages= , >> but I'll give a brief outline of the Augmented Packet Header Diagrams = project here. I'll let Marc describe his >> Computerate Specifying project separately. >>=20 >> The Augmented Packet Header Diagram format = (draft-mcquistin-augmented-ascii-diagrams) is a consistent packet header >> diagram format and accompanying structured text constructs that allow = for the parsing process of protocol headers to be >> fully specified. This provides support for the automatic generation = of parser code, and for other benefits that follow >> from being able to use tooling to process packet header diagrams. >>=20 >> Our goal at the hackathon is to improve both the Augmented Packet = Header Diagram format itself, by attempting to rewrite >> existing I-Ds and RFCs using its syntax, and to improve the tooling, = and in particular, its Rust parser generator. >>=20 >> Please join us: we are particularly interested in examples of packet = header diagrams that might be challenging to write >> in the format our draft describes, and in how our tooling might fit = into existing workflows. >>=20 >> I-D: = https://datatracker.ietf.org/doc/draft-mcquistin-augmented-ascii-diagrams >> Getting started information: = https://trac.ietf.org/trac/ietf/meeting/wiki/106hackathon/formal-languages= >>=20 >> Thanks, >>=20 >> Stephen >>=20 >>=20 >>=20 >> _______________________________________________ >> hackathon mailing list >> hackathon@ietf.org >> https://www.ietf.org/mailman/listinfo/hackathon >=20 > _______________________________________________ > hackathon mailing list > hackathon@ietf.org > https://www.ietf.org/mailman/listinfo/hackathon --Apple-Mail=_EC89DECC-B784-4A4B-8D8C-C5626E9A46A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Interesting discussion at the hackathon mailing list=E2=80=A6
BTW, we are thinking = about getting together in a corner of the hackathon room with all the = people that work on a hackathon project that employs CBOR, so we can = have some chatting about cross-pollination and coordination of that side = as well.

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


Begin = forwarded message:

From: = Carsten Bormann <cabo@tzi.org>
Subject: = Re: [hackathon] = Formal Languages at the Hackathon
Date: = November 6, 2019 at 16:40:11 = GMT+1
To: = hackathon@ietf.org
Cc: = Carsten Bormann <cabo@tzi.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/hackathon/Bu-WHQtU-8gZeiX= 5O16IZ1bFkOw>

I=E2=80=99m sharing the below with t2trg as = it appears to be highly related to some of our current work.

I=E2=80=99d also like to point out that formal = description techniques (FDT) have been used a lot at the IETF and the = IRTF:

* we know very well how to use ABNF = (RFC 5234) for our text-based protocols.  We don=E2=80=99t really = have a good way to work with multiple layers of ABNF, though; see the = difference between RFC 5988 and RFC 8288 for some recent improvements = (but the link between the layers is not formal).  ABNF tools exist = for both checking ABNF specs and for automatically generating instances = (examples).

* specific areas have had their = FDTs, e.g. RFC 4997 for ROHC, YANG for management, etc. =  Specifically YANG is increasingly used not only for its original = purpose, describing management information bases, but also for data on = the wire (yang-data).  YOUPI [1] is an interesting YANG extension = for describing arbitrary binary data.

[1]: = https://tools.ietf.org/html/draft-petrov-t2trg-youpi

* some RFCs were to a large extent = machine-generated text (e.g., RFC 7400) or machine-verified (e.g., RFC = 8428), based on models in various FDTs.  Some of these are very = domain-specific, but we could still be better on sharing tools (and = long-term preserving the sources that generated those RFCs).

* there is a lively discussion about adding = (structural) data modeling (a.k.a. =E2=80=9Cschemas=E2=80=9D) to JSON = over at the mailing list of the closed JSON WG (e.g., [2]).  While = that discussion is ongoing, we already have CDDL (RFC 8610) for = structurally modeling CBOR and JSON data.  Maybe one size does not = fit all here.  Similar to ABNF, CDDL tools can check specs, verify = instances against a spec, extract/generate code snippets from specs, and = generate instances/examples from specs.  One next step here is = adding links to application semantics.

[2]: = https://tools.ietf.org/html/draft-ucarion-jddf

* the WISHI activity in T2TRG looks at = modeling data shapes, interaction modeling, and potentially adding = protocol bindings towards the wire and application semantics towards the = application.  Several SDOs are providing interesting study = subjects, e.g., W3C WoT with their Thing Description (TD) [3] and the = still somewhat stealthy OneDM group with the Simple Definition Format = (SDF) [4].  We=E2=80=99ll discuss this on the Friday before the = IETF [5] and work on tools for it at the Hackathon (look for = =E2=80=9CWISHI=E2=80=9D).

[3]: https://www.w3.org/TR/wot-thing-description/
[4]: https://github.com/one-data-model/language/blob/master/sdf.md
[5]: https://github.com/t2trg/2019-11-singapore
(Yes, you can still register.)

I = understand that the =E2=80=9CFormal Languages=E2=80=9D activity mostly = addresses their use in IETF specifications, and I like that angle =E2=80=94= there are other uses of formal description techniques that possible = have a different set of requirements, which sometimes cause the = requirements of spec writers to be forgotten [6].

[6]: https://www.iab.org/wp-content/IAB-uploads/2016/03/Noise-in-spe= cifications-hurts.pdf

So I=E2=80=99m = really looking forward to the discussions on Friday, November 15th [5] = and at the Hackathon.  Getting something going on cross-pollinating = and coordinating the various FDT activities at IETF and IRTF might be a = good medium term goal.

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



On Nov 6, 2019, at = 11:09, Stephen McQuistin <sm@smcquistin.uk> wrote:

Hi= all,

Marc Petit-Huguenin and I are = championing formal languages projects at the hackathon in Singapore. = Broadly, these
projects seek to improve the quality of = standards by using formal and structured languages in specification = documents.
These documents can then be parsed by tooling = that can, for example, generate parser code or verify properties for = the
protocol being specified.

There will be two formal languages projects being worked on: = Augmented Packet Header Diagrams and Computerate
Specifying.= Details for both projects are available on the Wiki at https://trac.ietf.org/trac/ietf/meeting/wiki/106hackathon/forma= l-languages,
but I'll give a brief outline of the = Augmented Packet Header Diagrams project here. I'll let Marc describe = his
Computerate Specifying project separately.

The Augmented Packet Header Diagram format = (draft-mcquistin-augmented-ascii-diagrams) is a consistent packet = header
diagram format and accompanying structured text = constructs that allow for the parsing process of protocol headers to = be
fully specified. This provides support for the = automatic generation of parser code, and for other benefits that = follow
from being able to use tooling to process packet = header diagrams.

Our goal at the hackathon = is to improve both the Augmented Packet Header Diagram format itself, by = attempting to rewrite
existing I-Ds and RFCs using its = syntax, and to improve the tooling, and in particular, its Rust parser = generator.

Please join us: we are = particularly interested in examples of packet header diagrams that might = be challenging to write
in the format our draft describes, = and in how our tooling might fit into existing workflows.

I-D: https://datatracker.ietf.org/doc/draft-mcquistin-augmented-asci= i-diagrams
Getting started information: https://trac.ietf.org/trac/ietf/meeting/wiki/106hackathon/forma= l-languages

Thanks,

Stephen



_______________________________________________
hackathon mailing list
hackathon@ietf.org
https://www.ietf.org/mailman/listinfo/hackathon

_______________________________________________
hackathon mailing list
hackathon@ietf.org
https://www.ietf.org/mailman/listinfo/hackathon

= --Apple-Mail=_EC89DECC-B784-4A4B-8D8C-C5626E9A46A3-- From nobody Wed Nov 6 09:21:30 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 0C0C7120090; Wed, 6 Nov 2019 09:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, 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=juniper.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 neiJLFNLOBNs; Wed, 6 Nov 2019 09:21:03 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 76878120089; Wed, 6 Nov 2019 09:21:03 -0800 (PST) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA6HHVVL000771; Wed, 6 Nov 2019 09:20:59 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=f5w85fNAfaHAR2105XxT7EYAW6ol9geVNNPRSWx1Rr8=; b=iA/6pS8OjjFbwYmBkf+p+QCv/k15mjbHwA1cC3wskyaaHSqxORriF4/tKtu1cSZdIegY Xzk+8fgnejF6n+XDMLqrQCQfUt9o8Rq9c9kJSatR243j03ffMD+JVwe/m39sSfdk+1Oa M07PJ6UhZm1XLJxTMXeKpnV41+UIVbsbsDxX1uoeHfu1O3cq1mcdCxeUojh9MgAHBPcQ 0dktk9HI+EPZUPXCmOdh0ijZLXqD8yTiXL1UiX+Kg/Li+m57SqLqPxMmRByiB8/phcRC 59YSpd1EXOiino84gmmUgwY+DIKpeA55fJjeN8MC8pRUkbNGurni5jnwiBch8VS83noR pQ== Received: from nam05-dm3-obe.outbound.protection.outlook.com (mail-dm3nam05lp2051.outbound.protection.outlook.com [104.47.49.51]) by mx0a-00273201.pphosted.com with ESMTP id 2w41vd82qe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Nov 2019 09:20:59 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dJK+z7pKmjZizbjubI6J51oNRFijSYVoRBtI7yl3vJ6cdA/J4Tf34F/q8f9QXlbQj+M+3Bh7Fg/nfO/5kKB6xBjcCPAuQOF1a74KEjX18NITJfSS9QdqSZ8+yeDng9PeJYx0XUzfznizKpcz/O1innyvec47JtdHX104UdALxvOpK2jxWbVe3t9zyKnW6EaWzlO6yRDmsDt/WxZiatnEjKl7kE/S5s/I0Bm7n8kdjxB7KgMposTWNFWBa73dk1KDpMBumxNAY8UUGJwVHFqg2odoWww7KZ9h06/1nz6CX5RXj6AjW0KafIdO+5qhsqTEu0+hDgPoYskAREmC8SZGmw== 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=f5w85fNAfaHAR2105XxT7EYAW6ol9geVNNPRSWx1Rr8=; b=jiBzIuFPPgemy+OEyVCcdUOk6kJk/uSgfWNJiigfcnYOX61gGi3irtr6FyEwYS5PenbfX8WG+E9PTECncYF0ZDjKsnr+7DthAmP0iaChMjKlXw3V5+C1B5O/f90H37W9L3CpjsdjhFT2wHXjTcGuvjyfw8woHZi8OOtF9qqrv3tf6UVKEPlbKjMSqrq2Of9iblfGuFPZS6H+RB33BIMbJ7BzFcj6vTY5/wmQogkYQl7jij1NOswcbPQRrIVkw6VnyImGb/2PKXpOQnHY3PM8nllH4d9NC0Az5mFJUWv6swQjJW+XwlUr4I/LDD/2TlIXUegrRHqkYQji2/PFofzL2Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none Received: from SN6PR05MB5613.namprd05.prod.outlook.com (52.135.109.221) by SN6PR05MB5391.namprd05.prod.outlook.com (52.135.111.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Wed, 6 Nov 2019 17:20:57 +0000 Received: from SN6PR05MB5613.namprd05.prod.outlook.com ([fe80::1cff:aada:b864:8c83]) by SN6PR05MB5613.namprd05.prod.outlook.com ([fe80::1cff:aada:b864:8c83%7]) with mapi id 15.20.2430.020; Wed, 6 Nov 2019 17:20:57 +0000 From: Antoni Przygienda To: Carsten Bormann , "hackathon@ietf.org" CC: "cbor@ietf.org" , "t2trg@irtf.org" , Deborah Brungard , Alvaro Retana Thread-Topic: [hackathon] Formal Languages at the Hackathon Thread-Index: AQHVlIpUHHz09UBtGESbEgrp8q5at6d+R96A//+ODYCAAIvGgP//fCCA Date: Wed, 6 Nov 2019 17:20:57 +0000 Message-ID: <19B88297-3EB0-4FDD-86A0-E6118729312F@juniper.net> References: <4BD0608C-A277-4130-B85C-D7A75FAEFD8F@smcquistin.uk> <26630BB7-A8A6-4A35-BF22-22CEDFDBE3E3@tzi.org> In-Reply-To: <26630BB7-A8A6-4A35-BF22-22CEDFDBE3E3@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Enabled=true; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Name=Juniper Business Use Only; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Enabled=true; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ContentBits=0; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Method=Standard; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ActionId=a4095b3b-40e5-4dd9-8620-0000a21454a9; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SetDate=2019-11-06T17:19:47Z; user-agent: Microsoft-MacOutlook/10.1f.0.191103 x-originating-ip: [66.129.239.12] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4c2e9983-ff8e-4e3a-2fe8-08d762ddb005 x-ms-traffictypediagnostic: SN6PR05MB5391: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3826; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(376002)(136003)(366004)(39860400002)(199004)(189003)(76116006)(316002)(66066001)(26005)(81156014)(6486002)(6506007)(6246003)(86362001)(486006)(11346002)(99286004)(2501003)(2616005)(7736002)(476003)(446003)(8676002)(81166006)(5660300002)(8936002)(76176011)(558084003)(14454004)(58126008)(25786009)(186003)(33656002)(102836004)(229853002)(54896002)(6306002)(36756003)(6512007)(3846002)(71200400001)(66476007)(6116002)(256004)(478600001)(71190400001)(66946007)(66556008)(64756008)(6436002)(4326008)(54906003)(66446008)(91956017)(2906002)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR05MB5391; H:SN6PR05MB5613.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zqJZeakn9qEUjyhGtyFg7KES6Sho9ZduGwISRexoUMfEF5WZj69sWzG4KY8/o42OU4IMfqQsfAHrj2ZNCn87Qnqp4+xIlcvNRBVT9QRXzATPQaGFRY1UMF0voJJaKOfvPwLVfkEKneUwgjLIAjB/l/IlB3qvAxaczlMTTCpSuIzx/WAlDA06N1gf9TQKWocD2WOEQrDCJ5O2ab7/rwTKZLOqybQ01TyA2WfNQoaT05LTKWG0Y5vKP/AS3x60m5041Z/V40y0Bnp2pw7jG4FAMuBjtOed0nBTT2KNNsAB9WcT5PoRFbvrSZUK9MviyihEs5DO579QiXcow8I87V7uzTD4pja8vK6G3Hrx7/Sb5qy3/Kre16y/Js1hiJ9wov1f0iXkx2EcEbSYzbxqVUdb3FdRjdwk/sIWN4BsAKqWae/oUL9l/E02YcBueYN2vtM8 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_19B882973EB04FDD86A0E6118729312Fjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 4c2e9983-ff8e-4e3a-2fe8-08d762ddb005 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 17:20:57.4849 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R5L4OdefDfXwwsO0cPp6AIYV1t4fUKZNNAHyjXoo5thpIO2xAlf1rlCv64P1vdIp X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB5391 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-06_06:2019-11-06,2019-11-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 phishscore=0 priorityscore=1501 mlxscore=0 suspectscore=0 spamscore=0 clxscore=1011 bulkscore=0 impostorscore=0 malwarescore=0 mlxlogscore=716 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911060166 Archived-At: Subject: Re: [Cbor] [hackathon] Formal Languages at the Hackathon 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, 06 Nov 2019 17:21:05 -0000 --_000_19B882973EB04FDD86A0E6118729312Fjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCj4gICAgV2hlbiB0aGUgY29tcGxleGl0eSBvZiB0aGUgZGF0YSBiZWluZyBtb2RlbGVkIGRv bWluYXRlcyB5b3VyIHRoaW5raW5nIOKApg0KDQoNCg0KVG9ueeKAmXMgZG9nbWE6IOKAnENvbXBs ZXhpdHkgb2YgYW55IHN1Y2Nlc3NmdWwgdGVjaG5vbG9neSBfYWx3YXlzXyBnb2VzIHVwIHdpdGgg dGltZeKAnSDwn5iJIPCfmIkNCg0KDQoNCi0tLSB0b255DQoNCg0K --_000_19B882973EB04FDD86A0E6118729312Fjunipernet_ 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 YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0 RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdoZW4gdGhlIGNvbXBsZXhpdHkgb2YgdGhlIGRh dGEgYmVpbmcgbW9kZWxlZCBkb21pbmF0ZXMgeW91ciB0aGlua2luZyDigKYNCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5Ub2554oCZcyBkb2dtYTog4oCcQ29tcGxleGl0eSBvZiBhbnkg c3VjY2Vzc2Z1bCB0ZWNobm9sb2d5IF88aT5hbHdheXM8L2k+XyBnb2VzIHVwIHdpdGggdGltZeKA nQ0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FwcGxlIENvbG9yIEVtb2ppJnF1b3Q7 Ij4mIzEyODUyMTs8L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcHBsZSBD b2xvciBFbW9qaSZxdW90OyI+DQomIzEyODUyMTs8L3NwYW4+IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4tLS0gdG9ueSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_19B882973EB04FDD86A0E6118729312Fjunipernet_-- From nobody Wed Nov 6 12:18: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 066941200A4 for ; Wed, 6 Nov 2019 12:18:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bYgAMyiVM70 for ; Wed, 6 Nov 2019 12:18:03 -0800 (PST) Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F037312004A for ; Wed, 6 Nov 2019 12:18:02 -0800 (PST) Received: from [10.122.0.182] ([45.56.150.85]) by :SMTPAUTH: with ESMTPA id SRkfiex5Er3FgSRkgija5p; Wed, 06 Nov 2019 13:18:02 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Laurence Lundblade In-Reply-To: Date: Wed, 6 Nov 2019 12:18:00 -0800 Cc: cbor@ietf.org, Christophe Lohr Content-Transfer-Encoding: quoted-printable Message-Id: References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com> <8B119642-7D8D-4BEF-AD75-0AC9935BCD7C@island-resort.com> <3F9E4E02-7A86-4954-8E31-0E28D2B2FCDA@island-resort.com> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfA6x4hdFjUPJCvkciC2AtcGLky0QjE14DdBp3F4+mA/S80GG5f4y6/1vpiEr8vfHP6bgdzetxoDhzDXhnHEJVm1vLmB4RoQaOVR6aGphB8bT7W7KY88U usMhglUo6gywKfDWMbBs2Fzl/kypJqpnfvZ3y93p8Ri/BX00+z1fY3hMMjODZoVkOKlNkV+T4p/g1eRI7nGR1A5dX6I20UqPd1j35J+3PGcXd02IBUGdKcQC Archived-At: Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126 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, 06 Nov 2019 20:18:05 -0000 Thanks for all the explanations and comments and pointing out things I = missed when I read CDDL. One more observation. Seems like this is all about defining new registered data types, very = similar to a typedef in C. For example, this is about a data type for temperature, but not = indication whether the temperature is of the turkey in the oven or of = the Chernobyl reactor core. To distinguish reactor core from turkey it = is by the ordering in an array or the key/label in a map, never the tag. = In C it is the variable name. LL > On Nov 4, 2019, at 8:34 AM, Carsten Bormann wrote: >=20 > On Nov 4, 2019, at 17:28, Laurence Lundblade = wrote: >>=20 >> Was thinking more like COSE: >>=20 >> decfrac =3D [ >> e10: int, >> m: integer >> ] >>=20 >> decfrac_tagged =3D #6.4(decfrac) >=20 > That kind of style was written when we didn=E2=80=99t have the unwrap = operator. >=20 > RFC 8610 says: >=20 > decfrac =3D #6.4([e10: int, m: integer]) >=20 > Which is exactly what is called =E2=80=9Cdecfrac_tagged=E2=80=9D in = the above. > If you don=E2=80=99t want the tag, just write ~decfrac, and you have = what you called decfrac in your example. >=20 > (And the fact that the unwrap convention works universally obviates = the need to come up with noisy conventions such as _tagged.) >=20 >> That way you can say exactly which you want in CDDL without = constructing the CDDL for the non-tagged form. Will also help make it = clear that protocol designers need to be clear and pick one. >>=20 >> Maybe even ask that every new registered data type have CDDL like = this published suitable for normative reference as a requirement for = getting into the IANA registry? >=20 > Requiring this would create too much coupling. > Suggesting this is a good job for the DE :-) >=20 > (=E2=80=9Csuitable for normative reference=E2=80=9D is a different = issue, though.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Nov 6 13:02:36 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 2434612011E; Wed, 6 Nov 2019 13:02:28 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcLPDC4x0Qqk; Wed, 6 Nov 2019 13:02:25 -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 53F01120110; Wed, 6 Nov 2019 13:02:25 -0800 (PST) Received: from [192.168.217.102] (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 477f9q3ZmHzyT7; Wed, 6 Nov 2019 22:02:23 +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: <19B88297-3EB0-4FDD-86A0-E6118729312F@juniper.net> Date: Wed, 6 Nov 2019 22:02:23 +0100 Cc: "hackathon@ietf.org" , "cbor@ietf.org" , "t2trg@irtf.org" , Deborah Brungard , Alvaro Retana X-Mao-Original-Outgoing-Id: 594766941.191627-8c16912029267332d129620913db40a9 Content-Transfer-Encoding: quoted-printable Message-Id: <867BC0C8-651A-4EDA-8C24-2E7C877BF624@tzi.org> References: <4BD0608C-A277-4130-B85C-D7A75FAEFD8F@smcquistin.uk> <26630BB7-A8A6-4A35-BF22-22CEDFDBE3E3@tzi.org> <19B88297-3EB0-4FDD-86A0-E6118729312F@juniper.net> To: Antoni Przygienda X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] [hackathon] Formal Languages at the Hackathon 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, 06 Nov 2019 21:02:28 -0000 On Nov 6, 2019, at 18:20, Antoni Przygienda wrote: >=20 > > When the complexity of the data being modeled dominates your = thinking =E2=80=A6 > =20 > Tony=E2=80=99s dogma: =E2=80=9CComplexity of any successful technology = _always_ goes up with time=E2=80=9D =F0=9F=98=89 =F0=9F=98=89 Indeed, that=E2=80=99s why I talked about =E2=80=9Cdominates your = thinking=E2=80=9D (as opposed to =E2=80=9Cshould dominate your = thinking=E2=80=9D). An interesting effect of having a great FDT technique is that it becomes = much easier to handle complexity. A follow-on effect is that, as it is so much easier to put in = complexity, you do put in more of that. Which will hurt you sooner than you think (*)=E2=80=A6 So I strongly believe that a prerequisite of using FDT successfully is = that the formal model of your shiny new RFC should now fit on one slide. = (Which actually works out for RFC 7071 (+)!) Gr=C3=BC=C3=9Fe, Carsten (*) I still remember when I first read the ASN.1 for GSM MAP. All 950 = pages [IIRC] of it=E2=80=A6 (+) https://tools.ietf.org/html/rfc8610#page-61 From nobody Wed Nov 6 13:11: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 78116120145 for ; Wed, 6 Nov 2019 13:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 DJXtWFAnBQNi for ; Wed, 6 Nov 2019 13:11:46 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 A824A12018D for ; Wed, 6 Nov 2019 13:11:45 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id f2so162976wrs.11 for ; Wed, 06 Nov 2019 13:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WkpmjJje8UABWhuWQtjq1njaYVfduXpGFAS27YzGEZ4=; b=VxghO5d45bPzGKcexkYUKH5gUJGg9d9KNu60yI96ZJzaJApW8uyXtZQ8rHS/U9FQ5w dczHzaai1JmAjTWhaUhAAU9yB+25CwxZFpAlycZlyUFDglQcmjUHaSeF1mEzYVHf4eFK PZe/pXqUgo/YhHzJIEFV2pzLLkI2Pt68mysKxpZPEg+ApVI177Jj5XYsVdJ4DGW2OCEh zCWJ8MxmCNhL3d7hCApo3M8O2s8NOzGoj6OdkkVK/WNwGUJ6kdGONxLSjT/wIRuN7cS/ /zsNN9zeUwaSQYRFcd5vg+fxssGXZpSnakO6piMuVeVVQ/fYEKHz21xVc6HMCruWq2T1 8nJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WkpmjJje8UABWhuWQtjq1njaYVfduXpGFAS27YzGEZ4=; b=AMahytbIj4QxgI26zHLwZjg4WNlGqm8qO9xfP5H/P1pIcDmnb+oiQOQE6CK9Oirvw2 uBmSW09BxE/PD10tuNxGOPFzC8QtmgAYmgdJrg8a+yqje5yFXkivsCCKMys050qlTxWP l8/p7ecwWwVApjmCpVnh7i4WDf27Np9G5WMtjcjMP00/cyb2xYEtxuQ5LoYZZ2a6Fij/ 4m/xQyv2duGpkJQyYYiMVTNTlJfWm+CFZXPoi2YgYdC5tUrWK8JE38OwvmrBNMho/zB3 rSA15VdLf61kpsXkoh6ciBprH+8ZkbSxYGou+g8I3ld1tw/r4HpBQxVl6WPG09NPakyQ X16Q== X-Gm-Message-State: APjAAAVmEoQbEjT7yADHN7RWfdzaaSn3KAdLAgk5F5jY0Tjqlf1p5W75 moR+rzKXFVeXIpzG6Zc13KGomw== X-Google-Smtp-Source: APXvYqyvEsKiWxwTfCAV1cwSJ076tzMpdsK9DAvysW1yazK7G5nLt80dE+JR8SSshuaP88JK4sKq0w== X-Received: by 2002:a5d:6706:: with SMTP id o6mr4713451wru.54.1573074704100; Wed, 06 Nov 2019 13:11:44 -0800 (PST) Received: from [10.10.172.74] (207.239.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch. [178.197.239.207]) by smtp.gmail.com with ESMTPSA id g69sm3950088wme.31.2019.11.06.13.11.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Nov 2019 13:11:43 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) From: Ted Lemon In-Reply-To: <867BC0C8-651A-4EDA-8C24-2E7C877BF624@tzi.org> Date: Wed, 6 Nov 2019 22:11:38 +0100 Cc: Antoni Przygienda , "cbor@ietf.org" , Alvaro Retana , "t2trg@irtf.org" , Deborah Brungard , "hackathon@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <76A4AEEE-7773-4031-988E-00466B23C15E@fugue.com> References: <4BD0608C-A277-4130-B85C-D7A75FAEFD8F@smcquistin.uk> <26630BB7-A8A6-4A35-BF22-22CEDFDBE3E3@tzi.org> <19B88297-3EB0-4FDD-86A0-E6118729312F@juniper.net> <867BC0C8-651A-4EDA-8C24-2E7C877BF624@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3600) Archived-At: Subject: Re: [Cbor] [hackathon] Formal Languages at the Hackathon 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, 06 Nov 2019 21:11:48 -0000 This is getting kind of long for the hackathon mailing list (not that I = object to formal languages!). > On Nov 6, 2019, at 10:02 PM, Carsten Bormann wrote: >=20 > On Nov 6, 2019, at 18:20, Antoni Przygienda wrote: >>=20 >>> When the complexity of the data being modeled dominates your = thinking =E2=80=A6 >>=20 >> Tony=E2=80=99s dogma: =E2=80=9CComplexity of any successful = technology _always_ goes up with time=E2=80=9D =F0=9F=98=89 =F0=9F=98=89 >=20 > Indeed, that=E2=80=99s why I talked about =E2=80=9Cdominates your = thinking=E2=80=9D (as opposed to =E2=80=9Cshould dominate your = thinking=E2=80=9D). >=20 > An interesting effect of having a great FDT technique is that it = becomes much easier to handle complexity. > A follow-on effect is that, as it is so much easier to put in = complexity, you do put in more of that. > Which will hurt you sooner than you think (*)=E2=80=A6 >=20 > So I strongly believe that a prerequisite of using FDT successfully is = that the formal model of your shiny new RFC should now fit on one slide. = (Which actually works out for RFC 7071 (+)!) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > (*) I still remember when I first read the ASN.1 for GSM MAP. All 950 = pages [IIRC] of it=E2=80=A6 > (+) https://tools.ietf.org/html/rfc8610#page-61 >=20 > _______________________________________________ > hackathon mailing list > hackathon@ietf.org > https://www.ietf.org/mailman/listinfo/hackathon From nobody Wed Nov 6 13:14:16 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 40D111201A3; Wed, 6 Nov 2019 13:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 SPGwBpyLJAS4; Wed, 6 Nov 2019 13:14:12 -0800 (PST) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A15120120; Wed, 6 Nov 2019 13:14:12 -0800 (PST) Received: from [IPv6:2001:0:53aa:64c:1047:f4a0:3156:5791] (unknown [IPv6:2001:0:53aa:64c:1047:f4a0:3156:5791]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id DC177AE4A2; Wed, 6 Nov 2019 22:13:58 +0100 (CET) To: Ted Lemon , Carsten Bormann Cc: Deborah Brungard , "t2trg@irtf.org" , "hackathon@ietf.org" , "cbor@ietf.org" , Alvaro Retana , Antoni Przygienda References: <4BD0608C-A277-4130-B85C-D7A75FAEFD8F@smcquistin.uk> <26630BB7-A8A6-4A35-BF22-22CEDFDBE3E3@tzi.org> <19B88297-3EB0-4FDD-86A0-E6118729312F@juniper.net> <867BC0C8-651A-4EDA-8C24-2E7C877BF624@tzi.org> <76A4AEEE-7773-4031-988E-00466B23C15E@fugue.com> From: Marc Petit-Huguenin Openpgp: preference=signencrypt Autocrypt: addr=marc@petit-huguenin.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtC1NYXJjIFBldGl0 LUh1Z3VlbmluIDxtYXJjQHBldGl0LWh1Z3VlbmluLm9yZz6JAjsEEwEIACUCGyMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAAhkBBQJX8tdbAAoJECnERZXWan7EiNkQAIbS72cyalFjxQ1l vEW9S8NjjwIMbb5+NC2XqDakAmZq+Aav/Yfk8aEc+eAWBboVC3NBBjYojMRXK1XEnD7xPQ1X rWd23TDibKajy/2fo/MS9/s6uPFOAINi1ykOMq8ShxMHcIPC/dvVt59a7DV1KPGlnUheNR7N 4rIbkL5KndatD38yTGkyKsFvVKTHJn3y5zqHTGP0BjE1rxsGEBn4h+EzxVCIMVFQUeMVPKPV dlQY9fxdicSGPK2WKo1KL3CVpnYTuNCAVIGA9DPTXPPKvEte+/+xv10I03pj4w87iMUZt7Ca FTO55Gsf8hZvmpuB224yzrAbquA450EUVcQ7KAPcHrph5KAu0d3nwrjrUDn/RWWbyRiVrPtf hmnAAhkSv7oOxzyMdLvqt7XKGKbABhrl1ZRF8QbquOkyu8n3Bz2Osgw7JyFn9N6svlFPmpML UTEi64NewvN6zszKs/zBS6bn7na75gxHNvjSZpSF6uSLYgmKbyG8vkY/i0s0e0njjOHcpNx1 0mNZ+wOoCgHtSCZFyv14ncioJTiSjtZCs+srW9PFlbOg73C1Op42xV5Y+dh/mCC+rweKtB3t yTAy52v8vPG0VjsLS52x6yUsoDjYV33AmTEaWmGzN5t8BX/qh7pgNIEd9TEwrR3B4LjqMmUk XXWSJG5IM8Zr2OE/t2vyuQINBE6Mh9wBEAC/i4Lh4XEgwi/yHr3XLx/+f38ztn5rrk8XRsK2 WUpu5evxw9iK2oelqWtS71XkW57EavJOjvP4t8FWqRKED5jWN741n12iW/EeLx3KoHMcPTfY 4WWvprxiZPfnCIpQ8j8x0QQSA+Hf96BSkAkOGNkiJDuus5z4XwTktn9gFOwLVx4VRMo+lrCy um6BDHI+4/sOWnrNp2WptI4YKM/uA0HpuLpPKLra0ZW6Bp2TewNpAjbst/VHjqewab0PeSCn CQiHkqIibdgOATT0K6KoVtMxp/WPRSfVImfWCHjT2G7HFMcb6w/jlPSb+u4VtL9yn76CCg8F SqTtzFuqPtbXkhrdSgks/grxiQryMXwpO0uSuUgZ3u2TSs+65Bl2CM5cq+2aBIER5qhpnCv7 B00uHuoNqUEK0VEpLKcqi2ZeVM5oO8iOaBgS9Gh082HQ5JDijEV2J5e4rwXjbRnJ4hqpTjSy caW8HnPI+4S0aqVxbnqW7T6l/xnn7ivK3aPqaRKqUSedHCU3oHIU31n0o5+f5htQeDs/Tpzn ARHkyzu9vZ9CvQXk8daZorA+j/38q6mWU6Mw8FRIu1qPQDmqljobk3vC9BZRSJOn3P8jNMM7 w1j+7Da3rxGBylfa3fmHPyY7dvdyeLmsq7egzTJkpAMN55Qat7iuXeeCdBQLAFHLBP1tvwAR AQABiQIfBBgBCAAJAhsMBQJX8tdcAAoJECnERZXWan7EkMgP/isd3lrSsm/8t+U44LY0/x67 cPmiKa9biveywJZ9Y+Zu/pUP44dP670mY7PmEDGC6lRiPKGmhf7vqq6JJFOqX64VWePQ9QZp kkzAUmIJwQ2Kmcmfrs0J5w2Lf5qaNji25fQYbon0eUFy6eN3BNRSIcg0+OsH7HubTWfpZeJu B7V7k8OFt2+HDx7aNdNutDJIu4V25AzGfonARQzJK62cmB0pwYXpcyDO152OwP12XbpXxXA1 xHGYQBRL98pSbMU5xsMw8j9VQHQRS94aT9Qqnz9SrYuISnMV2WGyIE0rAY3GGz3IcN5LVE1N vSP51ih+YJg/qsBYs8obbfEIZelOuznWf120RgV7P+7ZWCSBohmchuyELQzl9D7FXfulkXA3 RapKQcGJMVPIHYgnlvmE0OXfJl1z09nYRQHitoQhWtviHWl7x/KL42aUzHirLR61iVA2kqkO BhU+u+g2w8qrZj+lJfXIxlbVyLOuBVqkfcK28AR9RriB4Q5hvbDeQJMgfZsV2hBt7huBOqkH nnbSCguqfnmwLGkxoM7RVjCQwvC1M57uwdKMlsTVaBP0RreZnrDngLamK+ibXYe7p8pPAWD9 cuHvkkjML7cIfuvbScDYRmGzia3V9+LVzQCm+q/6xUY1SZvrDz7OaJOy3Xb1d+aPhYaNC0TQ 7IqA1dx8rZYQ Message-ID: Date: Wed, 6 Nov 2019 13:13:49 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <76A4AEEE-7773-4031-988E-00466B23C15E@fugue.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KBvphtwT6ImGcIumDptbTHrLF4FefcSm7" Archived-At: Subject: Re: [Cbor] [hackathon] Formal Languages at the Hackathon 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, 06 Nov 2019 21:14:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KBvphtwT6ImGcIumDptbTHrLF4FefcSm7 Content-Type: multipart/mixed; boundary="wB8ugpyDRCRmIsZb3fpgHI2uCEJkUg7Zm"; protected-headers="v1" From: Marc Petit-Huguenin To: Ted Lemon , Carsten Bormann Cc: Deborah Brungard , "t2trg@irtf.org" , "hackathon@ietf.org" , "cbor@ietf.org" , Alvaro Retana , Antoni Przygienda Message-ID: Subject: Re: [hackathon] Formal Languages at the Hackathon References: <4BD0608C-A277-4130-B85C-D7A75FAEFD8F@smcquistin.uk> <26630BB7-A8A6-4A35-BF22-22CEDFDBE3E3@tzi.org> <19B88297-3EB0-4FDD-86A0-E6118729312F@juniper.net> <867BC0C8-651A-4EDA-8C24-2E7C877BF624@tzi.org> <76A4AEEE-7773-4031-988E-00466B23C15E@fugue.com> In-Reply-To: <76A4AEEE-7773-4031-988E-00466B23C15E@fugue.com> --wB8ugpyDRCRmIsZb3fpgHI2uCEJkUg7Zm Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Maybe we need a new mailing-list to discuss formal languages... On 11/6/19 1:11 PM, Ted Lemon wrote: > This is getting kind of long for the hackathon mailing list (not that I= object to formal languages!). >=20 >> On Nov 6, 2019, at 10:02 PM, Carsten Bormann wrote: >> >> On Nov 6, 2019, at 18:20, Antoni Przygienda wrote: >>> >>>> When the complexity of the data being modeled dominates your think= ing =E2=80=A6 >>> >>> Tony=E2=80=99s dogma: =E2=80=9CComplexity of any successful technolog= y _always_ goes up with time=E2=80=9D =F0=9F=98=89 =F0=9F=98=89 >> >> Indeed, that=E2=80=99s why I talked about =E2=80=9Cdominates your thin= king=E2=80=9D (as opposed to =E2=80=9Cshould dominate your thinking=E2=80= =9D). >> >> An interesting effect of having a great FDT technique is that it becom= es much easier to handle complexity. >> A follow-on effect is that, as it is so much easier to put in complexi= ty, you do put in more of that. >> Which will hurt you sooner than you think (*)=E2=80=A6 >> >> So I strongly believe that a prerequisite of using FDT successfully is= that the formal model of your shiny new RFC should now fit on one slide.= (Which actually works out for RFC 7071 (+)!) >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> (*) I still remember when I first read the ASN.1 for GSM MAP. All 950= pages [IIRC] of it=E2=80=A6 >> (+) https://tools.ietf.org/html/rfc8610#page-61 >> >> _______________________________________________ >> hackathon mailing list >> hackathon@ietf.org >> https://www.ietf.org/mailman/listinfo/hackathon >=20 > _______________________________________________ > hackathon mailing list > hackathon@ietf.org > https://www.ietf.org/mailman/listinfo/hackathon >=20 --wB8ugpyDRCRmIsZb3fpgHI2uCEJkUg7Zm-- --KBvphtwT6ImGcIumDptbTHrLF4FefcSm7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAl3DN44ACgkQKcRFldZq fsQ5pBAAt51yGKxxQzlFT0sCzhmwdmbia9idTvqqTTvCY7X0rbzNN61+xevuZpu6 L90zwwRKRwZzYh4REc4KW6D+A8QDg/QowHt+SNkR2Ss7GMs8dZNCrX7d88IiB21r lcGSes3zyJJXmtr/6tn5cgAMrNC7QYHXc9yjSsVpNUzqLWjx2iwfzjGa0S/1t/NT O/w1RPVNwIO0JseAVe1A7A1yTt/rM/tQv/NWOQqnqDG1CCD/bDd/FFZfkuaxSU80 Ldv7ChQgTANWyF739O1pwrHaJ+NnysmQypUZ0r1SsbviVoWZnBlDCc2eVIs67DKx EN77GSwALFatdW+tMM2sUhwog8HpSjgQdqEdmU9Z5gKs6SY51P62OsaCPEElzl72 ASYr3FEtiwsTgpyjDv4P04p+2cPLnXFFL5onSdircI4siVX+QxPpXGZYVi5kc3lK uxBMmBR8jCwnLPRPPvbtWA/u/K7VbrhAjaeMgHrsGLf4sFWW98ij8dW8nHz3vbJI RkCk05CkvA6yAmJMeLHTN6c8tEn8Ul8dmi6bye8bvEWdYk7aFOAik6Jv8li0F1ic YQY4KFDi9ylT8xTBISnQyyfTAx94F4HblLBpKa2cgPrZvlUhhKjoBlhmYd9qT8yX s5KxYuldt8NT6O1u4xGNUAG2i7eou7UKNwYxQM54FisNeVvtE5Y= =Wbcs -----END PGP SIGNATURE----- --KBvphtwT6ImGcIumDptbTHrLF4FefcSm7-- From nobody Wed Nov 6 13:17: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 349EC12002F; Wed, 6 Nov 2019 13:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net header.b=m2zzKKIo; dkim=pass (1024-bit key) header.d=juniper.net header.b=XMjbFCQh 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 T9jDRHYIBNWm; Wed, 6 Nov 2019 13:17:42 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 E94C0120120; Wed, 6 Nov 2019 13:17:42 -0800 (PST) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA6LCdKe004544; Wed, 6 Nov 2019 13:15:53 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=1H/y2ZHAiI0cQMvlu5gieiWmSuXe4XCRbqunPs+RpOE=; b=m2zzKKIojXf6Aqsq0IGGXC1ZrP1QitrM2RdUdAlMA6QwlCKWxPEWFaTawJgvrPq7ME6F P2aYEcRhgpFM+mB9Wjo6Io8GodyMe2JNSdxG3goc8JZkzLDouo3mMH50aSVlgpk0XXe8 2ODkW+OTeA31YOEEUO6Y6vq5DrLe/oYT42cc3Km4EXm/g7tG6s0fPUi+xHUitkp7n410 RE5851DwHlPggHWwjPTanzGSgOcSm3q4py06q6PNSSBJYS5YGZxZp3gcJOHjQj4odvvf IdI5GHtl7KnSU8DIovvs7Ht6o80y5ILuzTWIAP2pLFp13qoU+SejgP4GJoaONeT+KU8p HA== Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp2053.outbound.protection.outlook.com [104.47.32.53]) by mx0a-00273201.pphosted.com with ESMTP id 2w41vd8feb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Nov 2019 13:15:53 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AovCWOveXntDx3EorM0SymsV12OTM0FTktJS3qoViX0JFU6Cafkj/0mt/ULpMbATfZ3GFy1ylU1SIPPR3MR7anpRBKf7FBpwrSJiaUVaQ9p2LZdV0dd+CIieQrMPYmRMq2Ziq2WGIHE60SgdXIKAsUXb2vtQc2IrUd8ulwEIbXb9gwc7nJDGlBhGSgxFpwp76NIWa9aLBkbrv4KSYYW327vmKjximOhb9hq1lgcqdH9r5vtJAAiVUnzHDZ6S0DupLvA6CquuRbTF09xxBAH3BP+1h2vL/zhiNzSL8uvT8McX2Ybx+K+u9oxIO2Nsx4C8LG+5dTAEVjfY6vt0IUzyaQ== 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=1H/y2ZHAiI0cQMvlu5gieiWmSuXe4XCRbqunPs+RpOE=; b=j9B+6Z+mnnO9/LJpq4Abk3Q2I3kPh7lI7m11AMjTQWYLz9eR6IvHmjvQhuOU7R2OoNSMOEl0kl3TXcdMYlvUN9hFzreckyT3qi5egjkzg28UWesRVzFDciR4Kqk24RqcBXp2XaPPIrFVo8n5L19OpCM1BJ/KfuFLpkMRH65cBLSaFgyRI0h2bzHGQ5+RMHjCbLstFcEf4tNRVLpwdAjoW7a24U1wG81MkdwMNPow8khnv2du8s+MOyFroy3XhDSKlduTMxzgvx5zGIVp1HAI/FpUl0PsEgWAhZ1dbHiqx0phXOm7+b1RUTiV2JIsCAmgxl1rwV/STol6bR/352a7DQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1H/y2ZHAiI0cQMvlu5gieiWmSuXe4XCRbqunPs+RpOE=; b=XMjbFCQhyC4CV32504k1wMGHzjsTkjp07a/FG6waHbMIRla6o+amNsi6wooISgvYKGjuRHpzsQpcnVAodttoiFaHp0MbEkdcVrQzrNCzp+qtZN30bnIvQLH7b6y9jgAjsNBole4lOOPDaeYg/g5IafTQuQTZxSV2vIjPv3BfMsM= Received: from SN6PR05MB5613.namprd05.prod.outlook.com (52.135.109.221) by SN6PR05MB4925.namprd05.prod.outlook.com (52.135.117.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Wed, 6 Nov 2019 21:15:51 +0000 Received: from SN6PR05MB5613.namprd05.prod.outlook.com ([fe80::1cff:aada:b864:8c83]) by SN6PR05MB5613.namprd05.prod.outlook.com ([fe80::1cff:aada:b864:8c83%7]) with mapi id 15.20.2430.020; Wed, 6 Nov 2019 21:15:51 +0000 From: Antoni Przygienda To: Carsten Bormann CC: "hackathon@ietf.org" , "cbor@ietf.org" , "t2trg@irtf.org" , Deborah Brungard , Alvaro Retana Thread-Topic: [hackathon] Formal Languages at the Hackathon Thread-Index: AQHVlIpUHHz09UBtGESbEgrp8q5at6d+R96A//+ODYCAAIvGgP//fCCAgADEEoD//32PgA== Date: Wed, 6 Nov 2019 21:15:51 +0000 Message-ID: <43EC5C77-63A3-4B9A-95FC-5C4880CD14C7@juniper.net> References: <4BD0608C-A277-4130-B85C-D7A75FAEFD8F@smcquistin.uk> <26630BB7-A8A6-4A35-BF22-22CEDFDBE3E3@tzi.org> <19B88297-3EB0-4FDD-86A0-E6118729312F@juniper.net> <867BC0C8-651A-4EDA-8C24-2E7C877BF624@tzi.org> In-Reply-To: <867BC0C8-651A-4EDA-8C24-2E7C877BF624@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Enabled=true; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Name=Juniper Business Use Only; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Enabled=true; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ContentBits=0; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Method=Standard; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ActionId=ddf1c02c-e473-4a50-82bd-0000bb1c81ce; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SetDate=2019-11-06T21:14:35Z; user-agent: Microsoft-MacOutlook/10.1f.0.191103 x-originating-ip: [66.129.239.12] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 235e7869-8883-435b-5abb-08d762fe80a2 x-ms-traffictypediagnostic: SN6PR05MB4925: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(136003)(39860400002)(346002)(366004)(189003)(199004)(66946007)(99286004)(71190400001)(2906002)(14454004)(6506007)(86362001)(6436002)(53546011)(5660300002)(229853002)(6486002)(66066001)(3846002)(71200400001)(76176011)(6246003)(186003)(476003)(486006)(11346002)(446003)(6306002)(6512007)(4326008)(256004)(2616005)(305945005)(8936002)(6916009)(478600001)(8676002)(316002)(81166006)(81156014)(102836004)(6116002)(54906003)(58126008)(76116006)(26005)(7736002)(36756003)(966005)(66556008)(91956017)(64756008)(66476007)(33656002)(66446008)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR05MB4925; H:SN6PR05MB5613.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DFHBnBrclb9A6ry/SmiGC1pyus9c7ID50f9Z12g87f9wDE+sijvd0P+F8S890cfsfY8zLGjMjqQHJuLBwjEGC/hbP1JXxCgwYykZnJ7Kk3OAxug2wchXrnvZMxzzP5Drnoy/w3pvdA6qd2pqTRPs+1FOvrXJ2wmVCmebqrzeLUWCOIGlf472ocR08dwFtomz095CV0Ziw862URR+V04+43RjsEVs09RcIkVx/nfNDIwewmTOPLVJt/WnhltYYUz2Re68+XNai/ljLpdbYTZ3KSpMPeKi2om9KZG3kJGdPbCDq2WsDuu0gCECS6w6svjTUYA3T4vZSx/iE3hUl0cZFN1jVVFEOBgJjx34dhhxdUxHK1H/erRX8NUnIHVFjh+uANnIrUU84iSVE92v0/2CJ0tDea4w5ZM7pxNESCXQMchs3lxg8Q5fMt4vtL6niCbBjQ5HF3HFqn/6AslrTDSSFa4Coa3nVm98SjfDRtswqG8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 235e7869-8883-435b-5abb-08d762fe80a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 21:15:51.4703 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 08g/ckK9yrzO+IRR+LuDTmjV4WNK+X4yQ0dH+t8V6oHF/fC1ZVmytl7Vm9aysUYJ X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB4925 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-06_07:2019-11-06,2019-11-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 phishscore=0 priorityscore=1501 mlxscore=0 suspectscore=0 spamscore=0 clxscore=1015 bulkscore=0 impostorscore=0 malwarescore=0 mlxlogscore=999 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911060208 Archived-At: Subject: Re: [Cbor] [hackathon] Formal Languages at the Hackathon 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, 06 Nov 2019 21:17:45 -0000 QWxsIGNvcnJlY3QsIGV4Y2VwdCB0aGUgImZpdCBvbiBvbmUgc2xpZGUiIGZvciB0aGUgd2hvbGUg bW9kZWwgaXMgcHJvYmFibHkgd29ya2luZyBmb3IgYW55dGhpbmcgdGhhdCBpcyBub3QgYSByZWFs IHdvcmxkIHByb2JsZW0gX18gdW5sZXNzIEkgbWlzdW5kZXJzdG9vZCAuLi4gDQoNCi0tLSB0b255 IA0KDQrvu79PbiAxMS82LzE5LCAxOjAyIFBNLCAiQ2Fyc3RlbiBCb3JtYW5uIiA8Y2Fib0B0emku b3JnPiB3cm90ZToNCg0KICAgIE9uIE5vdiA2LCAyMDE5LCBhdCAxODoyMCwgQW50b25pIFByenln aWVuZGEgPHByekBqdW5pcGVyLm5ldD4gd3JvdGU6DQogICAgPiANCiAgICA+ID4gICAgV2hlbiB0 aGUgY29tcGxleGl0eSBvZiB0aGUgZGF0YSBiZWluZyBtb2RlbGVkIGRvbWluYXRlcyB5b3VyIHRo aW5raW5nIOKApg0KICAgID4gIA0KICAgID4gVG9ueeKAmXMgZG9nbWE6IOKAnENvbXBsZXhpdHkg b2YgYW55IHN1Y2Nlc3NmdWwgdGVjaG5vbG9neSBfYWx3YXlzXyBnb2VzIHVwIHdpdGggdGltZeKA nSDwn5iJIPCfmIkNCiAgICANCiAgICBJbmRlZWQsIHRoYXTigJlzIHdoeSBJIHRhbGtlZCBhYm91 dCDigJxkb21pbmF0ZXMgeW91ciB0aGlua2luZ+KAnSAoYXMgb3Bwb3NlZCB0byDigJxzaG91bGQg ZG9taW5hdGUgeW91ciB0aGlua2luZ+KAnSkuDQogICAgDQogICAgQW4gaW50ZXJlc3RpbmcgZWZm ZWN0IG9mIGhhdmluZyBhIGdyZWF0IEZEVCB0ZWNobmlxdWUgaXMgdGhhdCBpdCBiZWNvbWVzIG11 Y2ggZWFzaWVyIHRvIGhhbmRsZSBjb21wbGV4aXR5Lg0KICAgIEEgZm9sbG93LW9uIGVmZmVjdCBp cyB0aGF0LCBhcyBpdCBpcyBzbyBtdWNoIGVhc2llciB0byBwdXQgaW4gY29tcGxleGl0eSwgeW91 IGRvIHB1dCBpbiBtb3JlIG9mIHRoYXQuDQogICAgV2hpY2ggd2lsbCBodXJ0IHlvdSBzb29uZXIg dGhhbiB5b3UgdGhpbmsgKCop4oCmDQogICAgDQogICAgU28gSSBzdHJvbmdseSBiZWxpZXZlIHRo YXQgYSBwcmVyZXF1aXNpdGUgb2YgdXNpbmcgRkRUIHN1Y2Nlc3NmdWxseSBpcyB0aGF0IHRoZSBm b3JtYWwgbW9kZWwgb2YgeW91ciBzaGlueSBuZXcgUkZDIHNob3VsZCBub3cgZml0IG9uIG9uZSBz bGlkZS4gIChXaGljaCBhY3R1YWxseSB3b3JrcyBvdXQgZm9yIFJGQyA3MDcxICgrKSEpDQogICAg DQogICAgR3LDvMOfZSwgQ2Fyc3Rlbg0KICAgIA0KICAgICgqKSBJIHN0aWxsIHJlbWVtYmVyIHdo ZW4gSSBmaXJzdCByZWFkIHRoZSBBU04uMSBmb3IgR1NNIE1BUC4gIEFsbCA5NTAgcGFnZXMgW0lJ UkNdIG9mIGl04oCmDQogICAgKCspIGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODYxMCpwYWdlLTYxX187SXchOFdvQTZSakM4MWMhVHdy V2lDUjZqOFJEbGNQZmFJU0l4VlY3eGpSbmFTMDRZTDBMbktaa2YzWHhhSGVYeE01M21zQ3lwMlFN YUEkIA0KICAgIA0KICAgIA0KDQo= From nobody Fri Nov 8 02:01:38 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 C99E5120A19 for ; Fri, 8 Nov 2019 02:01:32 -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, 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 CJ3bmuLpirt5 for ; Fri, 8 Nov 2019 02:01:29 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30049.outbound.protection.outlook.com [40.107.3.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5186D1209F9 for ; Fri, 8 Nov 2019 02:01:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hBjaRdxaO+asZQD+5kDPSWd/98pdEV0n8kWEkmYroh9o1Mi9lCfqkCb8JTsv3z9tKWzld45QeqVX2xjW1V4pHeerZHQdyxj4JupyB/lr+tNUbLksTDoMkmrSevIs3x2uEOnKmsMNAavIQ+AXDKJyCX6Zw2/V7J+24PD9MgN5Jp5FG1zL3DLIAfswYTsR7RyNNspTgQDnBhQXECVqO/jz6Jv+XYVBG4RbnN/mnRbQ2FVdNtanpkmwvbq53656ekvemz2yD8HPeJvMbIPE87AIit/+fZ53Pvs1xNYcu/nlt4u+gKLhu7wFG3Uq+5d+n6wvqtjtBn/iBGJzJMJi+GB4HA== 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=pq2KNL/elM6guSpaRZz7O8kk9mowXyoDchfj0ewXcA8=; b=T93/5JcMmVvOG6/B5hC/MMKW7rfSkEpxU0eZWZdRzeWs/ne0zQAdw/lE69W/KfH/DTI9PZd/iNrKZA3jjk7vC+XKGdpFflnkGNWhqXGI5WNbhRnTuBOjcnzz6d3UOvL81NdNjOPgrqaVDIRMNHJt1hxeCO7VAtuA0hPmDaBBRR1MevhgPL2p+oKwfUxzDolGYuziaxVTsHcsUMuKF2S6eAYqlfcSJ7QilTxQseHQsSJZ1FLLE7zMAMP5Kxft4jNxKYUTLIOUg9RcsDIJYZefT6ouPudN3Or4oKj7nzjAqEMqP9au4lXQDX+DuNupip2tdbRAW6W7QBiMMXJwhE0Hcw== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pq2KNL/elM6guSpaRZz7O8kk9mowXyoDchfj0ewXcA8=; b=oxDPS6XV/b5/BCk6pPxducyPo6hPVz2eAUA3/IY+akwZcu1xaalYsYRtLbrxVox3ngsuCq13CgZLswN+2GsGbKPM3k71MWcYP9Ur50RdivZ0/6/deqcZYMUJc0xPm147qGcJIExa8KlOca7Uy1RiNizzbBerHr2rzTxG7vTAlsQ= Received: from VI1PR07MB5469.eurprd07.prod.outlook.com (20.178.14.214) by VI1PR07MB4046.eurprd07.prod.outlook.com (52.134.25.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.15; Fri, 8 Nov 2019 10:01:27 +0000 Received: from VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76]) by VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76%6]) with mapi id 15.20.2451.013; Fri, 8 Nov 2019 10:01:27 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: Preparing for WGLC of 7049bis Thread-Index: AQHVlht8CEIex/NzckqgWSlhJ64yTQ== Date: Fri, 8 Nov 2019 10:01:26 +0000 Message-ID: <20A00C16-26F5-461E-88ED-CB0C1E15633F@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: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8809241c-64c7-438e-62bc-08d764329ec0 x-ms-traffictypediagnostic: VI1PR07MB4046: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0215D7173F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(39860400002)(396003)(366004)(376002)(199004)(189003)(44832011)(36756003)(486006)(71190400001)(71200400001)(6916009)(478600001)(14454004)(966005)(256004)(66946007)(76116006)(91956017)(25786009)(66476007)(66556008)(64756008)(66446008)(86362001)(5660300002)(316002)(6116002)(26005)(8676002)(5640700003)(33656002)(2501003)(81166006)(8936002)(186003)(2351001)(3846002)(81156014)(6436002)(6486002)(6306002)(1730700003)(2906002)(476003)(305945005)(7736002)(6512007)(66066001)(6506007)(99286004)(102836004)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4046; H:VI1PR07MB5469.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: ONVWAntxqiQCIqzDC3NaSOmvv7GCdnMFN2SbdIQz6Zs4QeEX+PhI7E5vW+R+slQ/hUsY2W8QPCtD3/nM55Q2sEvh2A61m3avLXd/DSj6+woEZwUsXmWkG2yx4zKV9tN87+T6Cuk91wVm+CwkBi2D2o3F+9wWQucvRh2pF4qzbpw/fwIc/C3733pUC+29J9/qb/JncrJFloDMgmY3zwl0oRLBFYc7fZPuqdQ99c0/5ezHt8BbG/uSqljd0O8UBtJJ0JeFru0AEUEwrWlGouLUsId07fZzI/fS2xJFoV4mfy0lFCDk5IsK8JnHCTWi106O3rlFH6rcAJuj+rkPwJ73Sr9pfahlMZHxkjTY4SzPmvjHqd8TTGlYIP9jdXXIjNny916Ron2VTclT3LSNKkCo2fEuj+i64CyzIWf8s44Y/ZKzxi3SbBPYLY39D+CAs3YH x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <791D75085AEE9B47B3B489DF16475203@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8809241c-64c7-438e-62bc-08d764329ec0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2019 10:01:26.8926 (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: 0llE6KMyGkEmPsBHiE5z2uxlFD5WdzmYVRD+g8fSC3aSVkLPcM0Pq8lnsY9NzElzyPyg1mR6YdCovSSGmT6v+i/qlQUlmkzznaU8YnFsOm/A2BJMu5mMEYBOXBg1oAib X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4046 Archived-At: Subject: [Cbor] Preparing for WGLC of 7049bis 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, 08 Nov 2019 10:01:36 -0000 UHJldmlvdXMgcmV2aWV3ZXJzIG9mIDcwNDliaXMsDQoNCkFzIHdlIGFyZSBwcmVwYXJpbmcgdG8g c3RhcnQgV0dMQyBvbiB0aGlzIGRvY3VtZW50LCBwbGVhc2UgdGFrZSBhIHNlY29uZCB0byBnbyB0 aHJvdWdoIHRoZSBpc3N1ZXMgdGhhdCB3ZXJlIGNsb3NlZCBpbiB0aGVzZSB2ZXJzaW9ucyBhbmQg cmFpc2UgYW55IGNvbmNlcm5zIGFib3V0IHBvaW50cyBub3QgYmVpbmcgYWRkcmVzc2VkLCBpZiB5 b3UgZmluZCBhbnkuIA0KVW5sZXNzIG1ham9yIGNvbmNlcm5zLCBXR0xDIHdpbGwgc3RhcnQgb24g Tm92ZW1iZXIsIDE0dGguDQoNClRoYW5rcywNCkZyYW5jZXNjYQ0KDQrvu79PbiAwNS8xMS8yMDE5 LCAwMDozNSwgIkNCT1Igb24gYmVoYWxmIG9mIENhcnN0ZW4gQm9ybWFubiIgPGNib3ItYm91bmNl c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2Fib0B0emkub3JnPiB3cm90ZToNCg0KICAgIFJpZ2h0 IGJlZm9yZSB0aGUgSS1EIGRlYWRsaW5lLCBJIGhhdmUgc3VibWl0dGVkIHR3byBuZXcgdmVyc2lv bnMgb2YgNzA0OWJpcw0KICAgIA0KICAgIFZlcnNpb24gLTA4Og0KICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNib3ItNzA0OWJpcy0wOA0KICAgIENvbnRh aW5zIGFsbCB0aGUgY2hhbmdlcyB0aGF0IHdlIGhhZCBkb25lIGFib3V0IGEgd2VlayBhZ28sIHNv IHNob3VsZCBiZSByZWxhdGl2ZWx5IHN0YWJsZS4NCiAgICANCiAgICBWZXJzaW9uIC0wOToNCiAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jYm9yLTcwNDli aXMtMDkNCiAgICBoYXMgYWxsIHRoZSBibGVlZGluZyBlZGdlIHN0dWZmIHRoYXQgaGFzIG5vdCBo YWQgYXMgbXVjaCByZXZpZXcuDQogICAgDQogICAgVGhlc2Ugd2VyZSBzdWJtaXR0ZWQgc2VwYXJh dGVseSBzbyB5b3UgY2FuIGxvb2sgYXQgdGhlIGNoYW5nZXMgc2VwYXJhdGVseS4NCiAgICANCiAg ICBPZiBjb3Vyc2UsIGlmIHlvdSB3YW50IHRoZSBmaXJlaG9zZToNCiAgICANCiAgICBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1jYm9yLTcwNDliaXMtMDcmdXJs Mj1kcmFmdC1pZXRmLWNib3ItNzA0OWJpcy0wOQ0KICAgIA0KICAgIEl0IHdvdWxkIGJlIGdyZWF0 IHRvIGdldCBzb21lIHJldmlldyBzbyB3ZSBjYW4gZGVjaWRlIHdoZXRoZXIgLTA5IGlzIHRoZSBX R0xDIHZlcnNpb24uDQogICAgKEkgaGF2ZSBkb25lIHNvbWUgaXNzdWUgcHJvY2Vzc2luZywgYnV0 IG5vdCB5ZXQgYSBncmFuZCByZS1yZWFkLg0KICAgIEV4cGVjdCBzb21lIFdHTEMgY29tbWVudHMg ZnJvbSBtZSBhcyB3ZWxsIDstKQ0KICAgIA0KICAgIFRoZXJlIGFyZSBhIGZldyByZW1uYW50IGlz c3VlcyBhdDoNCiAgICANCiAgICBodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3YxL3VybD9r PTA4NjI0ZTJiLTU0ZTg2Y2ZkLTA4NjIwZWIwLTBjYzQ3YWQ5M2RjYy03NDg5NWZhODk3OTJmYzJi JnE9MSZlPWNkYTNmOWYxLTNlY2ItNDY5MC1iMmU3LWZiMWY0MzdjOGRmMyZ1PWh0dHBzJTNBJTJG JTJGZ2l0aHViLmNvbSUyRmNib3Itd2clMkZDQk9SYmlzJTJGaXNzdWVzDQogICAgDQogICAgd2hp Y2ggSSBiZWxpZXZlIGNhbiBiZSBjbG9zZWQsIGJ1dCBiZWZvcmUgdGhhdCBJJ2QgbGlrZSB0byBo ZWFyIHNvbWUgc3VwcG9ydCBmb3IgY2xvc2luZyB0aGVtLg0KICAgIA0KICAgIEdyw7zDn2UsIENh cnN0ZW4NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KICAgIENCT1IgbWFpbGluZyBsaXN0DQogICAgQ0JPUkBpZXRmLm9yZw0KICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Jvcg0KICAgIA0KDQo= From nobody Sun Nov 10 06:30:00 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 8C5F91200B2 for ; Sun, 10 Nov 2019 06:29:58 -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 TL7H7qzxwjat for ; Sun, 10 Nov 2019 06:29: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 3053712004A for ; Sun, 10 Nov 2019 06:29:56 -0800 (PST) Received: from [192.168.217.102] (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 479xH63Wlkz100F; Sun, 10 Nov 2019 15:29:54 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 595088992.224501-67581a70b2082339ef9e80ab556bdb4c Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sun, 10 Nov 2019 15:29:53 +0100 Message-Id: To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] cddl tool 0.8.10: Fix validating bignums, stricter about text vs. byte strings 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, 10 Nov 2019 14:29:58 -0000 I just pushed version 0.8.10 of the cddl tool, now with fewer bugs in = validating bignums and more strictness about text vs. byte strings. As usual, update with gem update Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Nov 14 02: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 3E43C120142; Thu, 14 Nov 2019 02:41:19 -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 csUvuoorLHNA; Thu, 14 Nov 2019 02:41:17 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80082.outbound.protection.outlook.com [40.107.8.82]) (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 84C2F1200FB; Thu, 14 Nov 2019 02:41:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HcagEKVNhDTqdRVK+JHLjLHb7xSWd2nrJoQ2Ck/VAMpEWGHcz3pn1VpEdpeWY3YFp8FqbYx8xE4qZBvMM75DPZgD8YZok6LcqdGPGRgv5cIRRXnMJ/eGmA0TaltEl1d9JJPRu0zHFnnzHAr1XdDp4Lm/X4DdszBK+sN8qIR19zn2+cWH8YwELmQPcPXBaRMQiJm7Nse/2wha4UuwuVRLED4g8yPTowRMdyXBU2UewRgYCILduTYhebsBTm/5DIOs5UGAaZnmGTcSCQbvloGJL72VWOZ9n16GuULiQfkmVFGGS735QBW0wW1F+OJH61b6CeMoik67PNETYqsLv4n14g== 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=NmmGuuwcYpqA/MN2jLeTb8yo572v9qmr6rUnbKFh0HQ=; b=ZjhxCfT/Oaiokhtk5QBuQB2CrjOixkw9ckqBlQOHS6+bjPdPGm/gKP/DBKK9uvCQ5DdQUjk1mhtfbKs0+7J0x3NjkUozfEkJyD1IhGoEMPlxjQ54q813dP4K0fb9eKILcJaZipmmG0baBE1WTgMRIG/eZU4V68ryPV/MGxCOT0ikXhyxGt36S7b0N7+jiD8gZPfAqZu9qDBhk8QsqQyy6MXzfZr+EUzX9+tosytg0qg69C3j093+lRRIM6OVJw/9OFr3pudqqgrTXibtKDLvDrZ5LGvqEmCvsOcRAKpGATVYbtQWIYWHcLoB9XKmGwG3z373xZjkH9vbXC2D9r/a8w== 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=NmmGuuwcYpqA/MN2jLeTb8yo572v9qmr6rUnbKFh0HQ=; b=G+bFO8cz3hb5uDX0FZRI3Fdia/J8rDhvAMl8xZ4Pof1WWqFCBxq+XqtTiv3fd9ehg/CC9n6zox39x5erc1L86ZatF2AwpzAUapbxn0pKGHsl/G+MuXUQgnAnWU9+meGZi6VEDQjMoYSYh39HmdprQSWDqPFid3mWxI3R/iq9D9o= Received: from VI1PR07MB5469.eurprd07.prod.outlook.com (20.178.14.214) by VI1PR07MB4526.eurprd07.prod.outlook.com (20.177.56.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.9; Thu, 14 Nov 2019 10:41:11 +0000 Received: from VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76]) by VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76%6]) with mapi id 15.20.2451.024; Thu, 14 Nov 2019 10:41:11 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" , "draft-ietf-cbor-7049bis@ietf.org" Thread-Topic: =?utf-8?B?8J+UlCBXR0xDIG9uIGRyYWZ0LWlldGYtY2Jvci03MDQ5YmlzLTA5?= Thread-Index: AQHVmtgHlP3xTHM9I0+UjjjMBCp1ag== Date: Thu, 14 Nov 2019 10:41:11 +0000 Message-ID: <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: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8f684b8c-f094-41bf-c847-08d768ef2a4b x-ms-traffictypediagnostic: VI1PR07MB4526: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 02213C82F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(376002)(39860400002)(396003)(136003)(199004)(189003)(71200400001)(71190400001)(36756003)(7736002)(2906002)(54906003)(316002)(6916009)(3846002)(6116002)(99286004)(33656002)(6486002)(966005)(8936002)(4744005)(2351001)(66946007)(476003)(2616005)(66476007)(66556008)(64756008)(6436002)(66446008)(478600001)(5640700003)(236005)(54896002)(6512007)(6306002)(606006)(66066001)(486006)(14454004)(44832011)(2501003)(5660300002)(256004)(91956017)(76116006)(25786009)(102836004)(6506007)(450100002)(4326008)(26005)(1730700003)(81156014)(81166006)(186003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4526; H:VI1PR07MB5469.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: B0wpNFKAvYeTE0S1CayqlEOSU/9Z0vYVJtNi2v/CUtuXVnWgiuQLksRRHHP6NqYo3vxsHK9S74Vuie2LVrxXmubLI9Gb+zXQuKcKTFMq7W86LRau1g+GJbT/d19d0FUc3Ki6qBb+vw6lN1givTxQFwftpLHDYJZD4L4fhLpx3hck2x8G4/E87EiryYJGtKhcjiev/Nl3Ofq7zNLwnflASTzJ1Gig0HLtwNZtnhLeezMNSyRkt9VIyCa44MKqtctIcOBaH7uahSOmKqp0eyOYeWgHPdMX3MPlHgQLCb5MgkbezlrjnLcOxqlYlapD7zo2kUyWjf/oloiHIrK0Oa7mAglcJnw9l+JRqNAKTl6sWX5bSn77vHzhxygKcoul9z7f4HaqkqSCEqqU+3hpCX8v0EtyBDvCjIG9I/ALqfmaFEwYyv/imWUHWb0nyJj4y+e4 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_293AFF31D0EF45D69B9DE8136481C404ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8f684b8c-f094-41bf-c847-08d768ef2a4b X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2019 10:41:11.1267 (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: +vUKKbxO6kZaN+TNaF30UoF7+G1RIZGgYSeX/2LcB36AP0R+ZMRGGazN7FC6J5UWiHLPaOkcwEFgAeg6f+F1rEUjNiW5+DQDjKDYL3y5dTJbKXoTz1pp4h7EpmcAzJqq X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4526 Archived-At: Subject: [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: Thu, 14 Nov 2019 10:41:20 -0000 --_000_293AFF31D0EF45D69B9DE8136481C404ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q0JPUiB3ZywNCg0KVGhpcyBzdGFydHMgYSBmb3VyIHdlZWtzIFdHIGxhc3QgY2FsbCBvbiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jYm9yLTcwNDliaXMtMDkgLCBlbmRp bmcgb24gKlRodXJzZGF5LCAxMiBEZWNlbWJlciouDQpQbGVhc2Ugc2VuZCBpbnB1dHMgdG8gdGhl IG1haWxpbmcgbGlzdCB0aGF0IHlvdSBoYXZlIHJlYWQgdGhlIGRvY3VtZW50IGFuZCBkbyBvciBk byBub3QgZmVlbCBpdCBpcyByZWFkeSB0byBwcm9ncmVzcywgYWxvbmcgd2l0aCBhbnkgaXNzdWVz IHRoYXQgeW91IGJlbGlldmUgbmVlZCB0byBiZSBkZWFsdCB3aXRoLg0KDQpXZSB3aWxsIGRpc2N1 c3MgYW55IG9wZW4gaXNzdWVzIHdl4oCZdmUgZ290dGVuIGF0IHRoZSBmMmYsIFRodXJzZGF5LCAy MSBOb3ZlbWJlci4NCg0KQ0JPUiBDaGFpcnMNCkppbSAmIEZyYW5jZXNjYQ0K --_000_293AFF31D0EF45D69B9DE8136481C404ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <3B9C2D39F0F6C84F813E1C33B8013DEF@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q0JPUiB3Zyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoaXMgc3RhcnRzIGEgZm91ciB3 ZWVrcyBXRyBsYXN0IGNhbGwgb24NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWNib3ItNzA0OWJpcy0wOSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtY2Jvci03MDQ5YmlzLTA5PC9hPiAsIGVuZGluZyBvbiAqPGI+VGh1cnNkYXks IDEyIERlY2VtYmVyPC9iPiouDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGxlYXNlIHNlbmQgaW5wdXRz IHRvIHRoZSBtYWlsaW5nIGxpc3QgdGhhdCB5b3UgaGF2ZSByZWFkIHRoZSBkb2N1bWVudCBhbmQg ZG8gb3IgZG8gbm90IGZlZWwgaXQgaXMgcmVhZHkgdG8gcHJvZ3Jlc3MsIGFsb25nIHdpdGggYW55 IGlzc3VlcyB0aGF0IHlvdSBiZWxpZXZlIG5lZWQgdG8gYmUgZGVhbHQgd2l0aC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldlIHdpbGwgZGlzY3VzcyBhbnkgb3Bl biBpc3N1ZXMgd2XigJl2ZSBnb3R0ZW4gYXQgdGhlIGYyZiwgVGh1cnNkYXksIDIxIE5vdmVtYmVy LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q0JPUiBDaGFpcnM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SmltICZhbXA7IEZyYW5jZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_293AFF31D0EF45D69B9DE8136481C404ericssoncom_-- From nobody Sun Nov 17 23:06:30 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 C83E21208E2 for ; Sun, 17 Nov 2019 23:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smcquistin-uk.20150623.gappssmtp.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 sVsEwTY5cvrP for ; Sun, 17 Nov 2019 23:06:26 -0800 (PST) Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (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 87BBA120947 for ; Sun, 17 Nov 2019 23:06:26 -0800 (PST) Received: by mail-pg1-x542.google.com with SMTP id r18so9145543pgu.13 for ; Sun, 17 Nov 2019 23:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smcquistin-uk.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Tgtn+aPKxk8CKpIua84F7MDBMuF8xubrQ8hZRM0d5xI=; b=OuVZYpmGd/S+JBhx4KvgOk53/ZrcrBr8NMVvQ4hQzcFcAaIGN0S0auSfvrtTqQ1IMg WO/hHeliG/CsizPj1f+Div9sxBcLKb4cpQsGZYpxydwIY4UJF3kAspwSBzp+vBd9GVGS D1BheE9A01Us6/AIW+FrTje3aI0j6Dx3CEqTzDC+lbR3CFE6wYQlQ0nr/eB1B5M/m/jP fOCC5M+t5eCYSemBUeYb2OtvavU/rQbwh2DQIToW0XbXndmfCIqmaqLIe7HHMpPykiGb KZ9BNhO8qKPypXs+Kr3rp/TsMPp3uABNPxKzDrxIl3gtt6sco3q1WnPX+G6QVyhxzA2k QNCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Tgtn+aPKxk8CKpIua84F7MDBMuF8xubrQ8hZRM0d5xI=; b=eaTZyj2YZ4eEjjmnTVjBKKRma+bU5j3bF16POpQM7i2GCIuU4L5dWzlgE0CPMg3Rd4 +xOkrkAg6mXmkGmGlV2x4d8UetFCGmqycnsyrVNXwlZWMO3yACoJl7phgivI892qZG6E hkzpQ57nQS41ShwRfoofMOC7LJVGMIPffYbji2EmK/L09HTUf8dIsQacXMD00wq1LS/H 0p4Q4aFJ3apXKgFkt9yxSPhShiYZXfchgr+5h3+80I2FNm9f9eqVZavpb/fv3J/nCtun AWAWXESq5Mhuw8MJht3fnIdkW4Zz5vMsWFhdHsN2NCGOL2K7WXMrKmf4gKEV+fh4qoUX 9HhA== X-Gm-Message-State: APjAAAWUMKaVsW/o1mGA6Cwo7s1J3CPgUU0xRt4yMDiEB45Ttq0y0m+G 9r78zccb6xBJ3JjKVA5KNQMRaw== X-Google-Smtp-Source: APXvYqyruwEN3RJRLK8b38nReiC0AqgCbqGSxUkMsxXvIAIDnAGg7IDfGdKHPb2b7BHoMBQZuAibVw== X-Received: by 2002:a63:68c3:: with SMTP id d186mr14710243pgc.301.1574060785903; Sun, 17 Nov 2019 23:06:25 -0800 (PST) Received: from dhcp-98be.meeting.ietf.org (dhcp-98be.meeting.ietf.org. [31.133.152.190]) by smtp.gmail.com with ESMTPSA id f24sm17087902pjp.12.2019.11.17.23.06.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 23:06:24 -0800 (PST) From: Stephen McQuistin Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_37E31E01-4A46-46B8-BB67-817DB3D0CF58" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Date: Mon, 18 Nov 2019 15:06:19 +0800 In-Reply-To: Cc: Ted Lemon , Carsten Bormann , Deborah Brungard , "t2trg@irtf.org" , Alvaro Retana , "cbor@ietf.org" , "hackathon@ietf.org" , Antoni Przygienda To: Marc Petit-Huguenin References: <4BD0608C-A277-4130-B85C-D7A75FAEFD8F@smcquistin.uk> <26630BB7-A8A6-4A35-BF22-22CEDFDBE3E3@tzi.org> <19B88297-3EB0-4FDD-86A0-E6118729312F@juniper.net> <867BC0C8-651A-4EDA-8C24-2E7C877BF624@tzi.org> <76A4AEEE-7773-4031-988E-00466B23C15E@fugue.com> X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Cbor] [hackathon] Formal Languages at the Hackathon X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 07:06:30 -0000 --Apple-Mail=_37E31E01-4A46-46B8-BB67-817DB3D0CF58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, Given the amount of discussion about this, a new mailing list has been = created: https://www.ietf.org/mailman/listinfo/fdt = (fdt@ietf.org = ) The list is for the discussion of formal languages, as they pertain to = IETF documents. This includes discussion of the requirements of these = techniques, and of their adoption within the IETF. In addition, a reminder that we=E2=80=99re holding an informal side = meeting on Thursday at 8pm. This=E2=80=99ll be at The Winery at CHIJMES = (Google Maps: https://g.page/thewinerysg ) = =E2=80=94 CHIJMES is across the road from the meeting hotel; once there, = The Winery is downstairs. If you=E2=80=99re planning to come along, let = us know so that we don=E2=80=99t miss anyone. Thanks, Stephen > On 7 Nov 2019, at 05:13, Marc Petit-Huguenin = wrote: >=20 > Maybe we need a new mailing-list to discuss formal languages... >=20 > On 11/6/19 1:11 PM, Ted Lemon wrote: >> This is getting kind of long for the hackathon mailing list (not that = I object to formal languages!). >>=20 >>> On Nov 6, 2019, at 10:02 PM, Carsten Bormann wrote: >>>=20 >>> On Nov 6, 2019, at 18:20, Antoni Przygienda wrote: >>>>=20 >>>>> When the complexity of the data being modeled dominates your = thinking =E2=80=A6 >>>>=20 >>>> Tony=E2=80=99s dogma: =E2=80=9CComplexity of any successful = technology _always_ goes up with time=E2=80=9D =F0=9F=98=89 =F0=9F=98=89 >>>=20 >>> Indeed, that=E2=80=99s why I talked about =E2=80=9Cdominates your = thinking=E2=80=9D (as opposed to =E2=80=9Cshould dominate your = thinking=E2=80=9D). >>>=20 >>> An interesting effect of having a great FDT technique is that it = becomes much easier to handle complexity. >>> A follow-on effect is that, as it is so much easier to put in = complexity, you do put in more of that. >>> Which will hurt you sooner than you think (*)=E2=80=A6 >>>=20 >>> So I strongly believe that a prerequisite of using FDT successfully = is that the formal model of your shiny new RFC should now fit on one = slide. (Which actually works out for RFC 7071 (+)!) >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>> (*) I still remember when I first read the ASN.1 for GSM MAP. All = 950 pages [IIRC] of it=E2=80=A6 >>> (+) https://tools.ietf.org/html/rfc8610#page-61 >>>=20 >>> _______________________________________________ >>> hackathon mailing list >>> hackathon@ietf.org >>> https://www.ietf.org/mailman/listinfo/hackathon >>=20 >> _______________________________________________ >> hackathon mailing list >> hackathon@ietf.org >> https://www.ietf.org/mailman/listinfo/hackathon >>=20 >=20 >=20 > _______________________________________________ > hackathon mailing list > hackathon@ietf.org > https://www.ietf.org/mailman/listinfo/hackathon --Apple-Mail=_37E31E01-4A46-46B8-BB67-817DB3D0CF58 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all,

Given the = amount of discussion about this, a new mailing list has been = created:

https://www.ietf.org/mailman/listinfo/fdt (fdt@ietf.org)

The list is for the = discussion of formal languages, as they pertain to IETF documents. This = includes discussion of the requirements of these techniques, and of = their adoption within the IETF.

In addition, a reminder that we=E2=80=99r= e holding an informal side meeting on Thursday at 8pm. This=E2=80=99ll = be at The Winery at CHIJMES (Google Maps: https://g.page/thewinerysg) =E2=80=94 CHIJMES is across = the road from the meeting hotel; once there, The Winery is downstairs. = If you=E2=80=99re planning to come along, let us know so that we don=E2=80= =99t miss anyone.

Thanks,

Stephen

On 7 Nov 2019, at 05:13, Marc = Petit-Huguenin <marc@petit-huguenin.org> wrote:

Maybe = we need a new mailing-list to discuss formal languages...

On 11/6/19 1:11 PM, Ted Lemon wrote:
This is getting kind of = long for the hackathon mailing list (not that I object to formal = languages!).

On Nov 6, 2019, at 10:02 PM, Carsten Bormann <cabo@tzi.org> wrote:

On Nov 6, 2019, at 18:20, Antoni Przygienda = <prz@juniper.net> = wrote:

 When the = complexity of the data being modeled dominates your thinking =E2=80=A6

Tony=E2=80=99s dogma: = =E2=80=9CComplexity of any successful technology _always_ goes up with = time=E2=80=9D =F0=9F=98=89 =F0=9F=98=89

Indeed, that=E2=80=99s why I talked about =E2=80=9Cdominates = your thinking=E2=80=9D (as opposed to =E2=80=9Cshould dominate your = thinking=E2=80=9D).

An interesting effect = of having a great FDT technique is that it becomes much easier to handle = complexity.
A follow-on effect is that, as it is so much = easier to put in complexity, you do put in more of that.
Which will hurt you sooner than you think (*)=E2=80=A6

So I strongly believe that a prerequisite of = using FDT successfully is that the formal model of your shiny new RFC = should now fit on one slide.  (Which actually works out for RFC = 7071 (+)!)

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

(*) I still remember when I first read the = ASN.1 for GSM MAP.  All 950 pages [IIRC] of it=E2=80=A6
(+) https://tools.ietf.org/html/rfc8610#page-61

_______________________________________________
hackathon mailing list
hackathon@ietf.org
https://www.ietf.org/mailman/listinfo/hackathon

_______________________________________________
hackathon mailing list
hackathon@ietf.org
https://www.ietf.org/mailman/listinfo/hackathon



_______________________________________________
hackathon mailing list
hackathon@ietf.org
https://www.ietf.org/mailman/listinfo/hackathon

= --Apple-Mail=_37E31E01-4A46-46B8-BB67-817DB3D0CF58-- From nobody Tue Nov 19 05:11:48 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 EBF2B1208BB for ; Tue, 19 Nov 2019 05:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 wv2F57DjTWxK for ; Tue, 19 Nov 2019 05:11:46 -0800 (PST) Received: from p3plsmtpa09-09.prod.phx3.secureserver.net (p3plsmtpa09-09.prod.phx3.secureserver.net [173.201.193.238]) (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 C115A12087E for ; Tue, 19 Nov 2019 05:11:46 -0800 (PST) Received: from [172.16.134.137] ([101.100.166.3]) by :SMTPAUTH: with ESMTPA id X3IFiVvCdvE5rX3IGivJXz; Tue, 19 Nov 2019 06:11:45 -0700 From: Laurence Lundblade Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <03E530C9-4B38-497A-BB4B-91488842C7F3@island-resort.com> Date: Tue, 19 Nov 2019 21:11:42 +0800 To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfFp1/gdb4j50H9rZ9Svkvm27uvPBUzKUj7GDrQX7MEzG8c5iUrngv6ATqryZcS+Q7XlFa0QB9ftKY9yhdBDdXtLmbmcQOTw9wGf6pzvM/xac1JcRUgX/ 8/VSP/N9qDBY0a+lf0KZyaMs6dRBaGS8ctvwl75ELIvMf9On73BDxa/I Archived-At: Subject: [Cbor] Validity checking 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, 19 Nov 2019 13:11:48 -0000 I=E2=80=99m not sure if this should be filed as an issue or not, so = I=E2=80=99ll put it in email first. Here=E2=80=99s three classes of validity checks: 1) Easy - Check whether the type of a tagged item is right, for example that = tagged content of a tag 0 (string date) is a string Checks in the class are easy and take no extra resources except a few = lines of code. Any decoder author Is likely to implement this check for tagged types they support because = it is sort of the obvious thing to do. 2) Medium - Check for duplicate keys in a map Check in this class require writing a some special code and may use a = lot of extra resources, particularly memory 3) Should not be done by a generic decoder (IMO) - Check MIME structure - Check unicode characters - Check for valid base64 - Check for valid date string It would be costly and inconvenient to do these in a generic CBOR = decoder, but not at all for a MIME decoder, unicode renderer or base 64 = decoder, so it makes almost no sense for a generic CBOR decoder to = implement them. It would be waste of time and resources. I don=E2=80=99t think it useful to talk of validity checking or not = validity checking generic decoders as in the latest section 5.4. (IMO) = only an insane decoder would check all validity as it would one that = includes a MIME parser, base64 decoder and such. Many generic decoders = will do no validity checking at all and be perfectly OK because they = don=E2=80=99t decode tagged types and don=E2=80=99t do duplicate = checking. LL From nobody Thu Nov 21 04:52:24 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 E21A21208C3 for ; Thu, 21 Nov 2019 04:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 L73zArEEARuc for ; Thu, 21 Nov 2019 04:52:21 -0800 (PST) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 D254C120043 for ; Thu, 21 Nov 2019 04:52:20 -0800 (PST) Received: by mail-qv1-xf2a.google.com with SMTP id y18so1339375qve.2 for ; Thu, 21 Nov 2019 04:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=9c+lPOCjysvM8bbfKuxwHaK90ygyxvwcWmaEEuK4b+E=; b=WY22PDEtl+wr90L8B0a4p1JJQnoIUaDiCM1coh9P/1CmEWxP8AtWGZ0wKlO7W3YCeT +w1lDYCQa4flgFGLOyMPW6NThhxxlApPP+54uRL92MiB7Scn7+K+ggcW6kjfUDKhhA9U QG5dF0bB509XRkhfBPcc3rkMs5SX8ZWQntk1f1p9gnqn8zaWC0dMPtdOna7SCn5YqYAk mBtTTmKOOX+qmVUK+ciLRwaVAijqrAxyOe+IwMSktgUCALit4Nfy0I65bosvt/uHZ5Kj UUUwYcRUjaHyvQ7MB3nOCAdtRyAUOE8VKSMiQNLgEV6MDznVhXzQX7jIw6GY4tVz08JC AxeQ== 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=9c+lPOCjysvM8bbfKuxwHaK90ygyxvwcWmaEEuK4b+E=; b=JpATpFwzWwxa8SP33HNn3b87MwQp2XZdDTm+eT+8y79nd/e4gfo/yYXJtwQqRutyqT b3DOForoZf54WO7R3RYGRPHqKUQzO1KYC/x7LlgkWsst4z5fFaKawcU1l22etD1SzwHH VCK5PdX80HHaW9XscqkC/XXxoqLJHGyTSDI3ELnQ1lbfiK03tyjHVmpPIsV037iok4ys 366ooFIC6vzJC9goXKq5sNkFIA7TGzqpFFVhnLGnAp4PnyofTuNN1wrjphMOVVQ/zEVA +cP1kAZOmpHPsz0+dj8AHvLX3zztX2zoXspDnMjzpgygzuu63509RTB8layYNuhdbTyV 9U6Q== X-Gm-Message-State: APjAAAW3supCk0Pp7VakeUY7VTnrelqc5CVXkH3arMNiAsDeUsIY/6HJ qiB0sA0fW0/JkyhYuHoTl7rK1ur24XVGYcINn4xocg/6R3pmO4sc X-Google-Smtp-Source: APXvYqz/ItuRkv+FWRg4O6dKPKoGpblAjt9n1lQ2WxjAvjNZX+U7qw73rlZL7zcZ6htUhYHpEPNhAcPQNDvYXimliLU= X-Received: by 2002:a0c:edcc:: with SMTP id i12mr7960618qvr.20.1574340738882; Thu, 21 Nov 2019 04:52:18 -0800 (PST) MIME-Version: 1.0 From: Jeffrey Yasskin Date: Thu, 21 Nov 2019 20:52:07 +0800 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="0000000000007f89b30597dac470" Archived-At: Subject: [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: Thu, 21 Nov 2019 12:52:23 -0000 --0000000000007f89b30597dac470 Content-Type: text/plain; charset="UTF-8" Re https://github.com/cbor-wg/CBORbis/issues/63, we had a long discussion today at IETF106 about what CBORbis should say about how protocols handle the (invalid) situation in which a CBOR map contains two entries with the same key. Clearly basic-validating parsers will return an error. The disagreement comes from what if anything to require from non-validating parsers. An interesting piece of background information comes from CVE-2013-4787 and the ZIP format: A ZIP central directory can have a single filename multiple times (with no mention of this possibility in the specification ). The Android signature checker (in Java) checked the last occurrence, while the package loader (in C) used the first. It takes two mistakes for that kind of vulnerability to happen: 1) The implementer has to parse the format twice with two different parsers instead of parsing once and operating over that parse result twice. 2) The format has to fail to say how to deal with invalid input. We have control over (2). CBORbis currently says: "A CBOR-based protocol MUST define what to do when a receiving application > does see multiple identical keys in a map. The resulting rule in the > protocol MUST respect the CBOR data model: it cannot prescribe a specific > handling of the entries with the identical keys, except that it might have > a rule that having identical keys in a map indicates a malformed map and > that the decoder has to stop with an error. Duplicate keys are also > prohibited by CBOR decoders that enforce validity (Section 5.4)." A) Leaving this alone is one of the possibilities. B) CBOR itself could say that a protocol implementation with a non-validating decoder MUST use the *first* entry with a particular key and discard the rest. (Note that this works even with a streaming decoder, since it's a requirement at the protocol level.) This would ban three kinds of implementations: 1) Ones that build up a native map from the full content of the CBOR map, and unconditionally overwrite any existing entry with the next entry read from the CBOR map. These can be fixed by checking whether an entry with the key is already present before writing to it. Some native map APIs might not be able to do this without a redundant lookup. 2) Ones that initialize a native structure with default values (as opposed to "missing") and then overwrite those values with the entries read from the CBOR map. These can be fixed by adding a "missing" value to all the native structure fields, which might increase the storage needed. 3) Ones that perform some real-world action as they stream each CBOR map entry and never store the entries at all. I don't see a way to get those to ignore duplicates. I also worry about the real-world effect of performing one of those actions twice if it was important to use a map instead of an array. C) CBOR could require protocols to use the *last* entry with a given key. This requires any implementation to scan to the end of a map before using any of the content, so it's probably a bad idea. It is potentially easier to implement in a decoder that builds up a native map of the content. D) CBOR could allow protocols to leave the behavior of duplicate keys unspecified if they explicitly declare that the fields are not security-sensitive. I prefer B and then D. What do other people think? Jeffrey --0000000000007f89b30597dac470 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Re=C2=A0https://github.com/cbor-wg/CBORbis/issues/63, we had a long disc= ussion today at IETF106 about what CBORbis should say about how protocols h= andle the (invalid) situation in which a CBOR map contains two entries with= the same key.

Clearly basic-validating parsers will return an error. The disagreement comes from what if anythi= ng to require from non-validating parsers. An interesting piece of backgrou= nd information comes from=C2=A0CVE-2013-4787 and the ZIP format: A ZIP = central directory can have a single filename multiple times (with no mentio= n of this possibility in the specification). The Android signature checker= (in Java) checked the last occurrence, while the package loader (in C) use= d the first. It takes two mistakes for that kind of vulnerability to happen= : 1) The implementer has to parse the format twice with two different parse= rs instead of parsing once and operating over that parse result twice. 2) T= he format has to fail to say how to deal with invalid input. We have contro= l over (2).

CBORbis=C2=A0currently says:

"A CBOR-b= ased protocol MUST define what to do when a receiving application does see = multiple identical keys in a map. The resulting rule in the protocol MUST r= espect the CBOR data model: it cannot prescribe a specific handling of the = entries with the identical keys, except that it might have a rule that havi= ng identical keys in a map indicates a malformed map and that the decoder h= as to stop with an error. Duplicate keys are also prohibited by CBOR decode= rs that enforce validity (Section 5.4)."

A) Leaving this alone is one of the possibilities.

<= div>B) CBOR itself could say that a protocol implementation with a non-vali= dating decoder MUST use the *first* entry with a particular key and discard= the rest. (Note that this works even with a streaming decoder, since it= 9;s a requirement at the protocol level.) This would ban three kinds of imp= lementations:
1) Ones that build up a native map from the full co= ntent of the CBOR map, and unconditionally overwrite any existing entry wit= h the next entry read from the CBOR map. These can be fixed by checking whe= ther an entry with the key is already present before writing to it. Some na= tive map APIs might not be able to do this without a redundant lookup.
2) Ones that initialize a native structure with default values (as op= posed to "missing") and then overwrite those values with the entr= ies read from the CBOR map. These can be fixed by adding a "missing&qu= ot; value to all the native structure fields, which might increase the stor= age needed.
3) Ones that perform some real-world action as they s= tream each CBOR map entry and never store the entries at all. I don't s= ee a way to get those to ignore duplicates. I also worry about the real-wor= ld effect of performing one of those actions twice if it was important to u= se a map instead of an array.

C) CBOR could requir= e protocols to use the *last* entry with a given key. This requires any imp= lementation to scan to the end of a map before using any of the content, so= it's probably a bad idea. It is potentially easier to implement in a d= ecoder that builds up a native map of the content.
D) CBOR could allow protocols to leave the behavior of duplicat= e keys unspecified if they explicitly declare that the fields are not secur= ity-sensitive.


I prefer B and then = D. What do other people think?

Jeffrey
--0000000000007f89b30597dac470-- From nobody Thu Nov 21 21:28:49 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 4FDB112022D; Thu, 21 Nov 2019 21:28:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157440052618.32312.15810062675489872843@ietfa.amsl.com> Date: Thu, 21 Nov 2019 21:28:46 -0800 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2019-12-18 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: Fri, 22 Nov 2019 05:28:46 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2019-12-18 from 16:00 to 17:00 UTC. Agenda: TBD Information about remote participation: WebEx details will be sent to the mailing list before each call. The CBOR working group will have conference calls running Day: Wednesday Dates: 18 Dec 2019, 15 Jan 2020, 29 Jan 2020 Time: 16:00 – 17:00 UTC We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. From nobody Thu Nov 21 21:29:37 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 D5ED412022D; Thu, 21 Nov 2019 21:29:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157440057483.32468.3160843183861247004@ietfa.amsl.com> Date: Thu, 21 Nov 2019 21:29:34 -0800 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-01-15 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: Fri, 22 Nov 2019 05:29:35 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2020-01-15 from 16:00 to 17:00 UTC. Agenda: TBD Information about remote participation: WebEx details will be sent to the mailing list before each call. The CBOR working group will have conference calls running Day: Wednesday Dates: 18 Dec 2019, 15 Jan 2020, 29 Jan 2020 Time: 16:00 – 17:00 UTC We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. From nobody Thu Nov 21 21:29:57 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 164B0120BF0; Thu, 21 Nov 2019 21:29:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157440059505.32289.4864924334331782890@ietfa.amsl.com> Date: Thu, 21 Nov 2019 21:29:55 -0800 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-01-29 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: Fri, 22 Nov 2019 05:29:55 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2020-01-29 from 16:00 to 17:00 UTC. Agenda: (No agenda submitted) Information about remote participation: WebEx details will be sent to the mailing list before each call. The CBOR working group will have conference calls running Day: Wednesday Dates: 18 Dec 2019, 15 Jan 2020, 29 Jan 2020 Time: 16:00 – 17:00 UTC We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialling nor US toll free ("800" numbers), but you can use the WebEx app to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. From nobody Fri Nov 22 18:00: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 17480120180 for ; Fri, 22 Nov 2019 18:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 6kMDvmCoPVNV for ; Fri, 22 Nov 2019 18:00:03 -0800 (PST) Received: from p3plsmtpa07-04.prod.phx3.secureserver.net (p3plsmtpa07-04.prod.phx3.secureserver.net [173.201.192.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 A3B93120168 for ; Fri, 22 Nov 2019 18:00:03 -0800 (PST) Received: from [172.19.249.135] ([38.98.37.136]) by :SMTPAUTH: with ESMTPA id YKiHi3su1Q4JfYKiNij4Ak; Fri, 22 Nov 2019 19:00:02 -0700 From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4E416485-5BF0-4C6D-B865-31F33140BE6F" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 23 Nov 2019 09:59:52 +0800 In-Reply-To: Cc: cbor@ietf.org To: Jeffrey Yasskin References: X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfBoQ5/ea9wICwsr+RBCCe+Seo/P0WLvm2TcSKQNZo9s7ntqCO8eMnbQF28lv9ZkNKKOCATUTwpSK2pYtmjDBgXBkUUdeIEL5bTjCw8IkN1cVusx8L6qN C22DdQ6zHWS9NJw7628pT480w7F0ce61MxUdFeDadPMauQP9lTumInNBHakG1kx6ithCy+/QsrTnqPRG0Il7Db81TGX4CzzlzeW1LtnQEb/Oks3gbYrV339b 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: Sat, 23 Nov 2019 02:00:05 -0000 --Apple-Mail=_4E416485-5BF0-4C6D-B865-31F33140BE6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here=E2=80=99s a rough proposed text: The protocol designer should make a choice for maps as to whether = duplicates are allowed or not, particularly as to whether duplicates = would cause security or functionality problems. The protocol designer should only require duplicate detection when = necessary as it can have the following implications: Some generic decoders do not support duplicate detection because the = underlying facilities in their programming environment to represent maps = can=E2=80=99t detect duplicates Some generic decoders do not support duplicate detection because it = requires more code and is not required It requires more resources to implement: 1) memory to store all the keys = in the map, 2) more code, 3) more CPU time, as much as O(n^2). This is = particularly an issue with big maps in constrained environments. It is suggested that protocol designers require duplicate detection only = no the particular maps for which there is an issue. Decoders will typically fall into one of these categories: Full duplicate detection Pass all items up to caller, allowing the caller to implement duplicate = detection or not No duplicate detection A generic decoder should identify which it is. Some may support more = than one, selectable by configuration. Here=E2=80=99s why. I see no value in take first or take last over duplicate detection. In = all three all, the keys encountered must be recorded and processed. If = the map is large this will take a lot of memory. In all cases there is = some extra code and CPU. CPU time is worse than O(n), perhaps O(n^2). It = doesn=E2=80=99t matter if the use case is streaming or not. It is the = memory, code and CPU time that matter. (Take last can only be = implemented by decoding the whole map, as it is only after decoding the = whole map that it can know it has encountered the last; in a way you = cannot do the last for a streaming decoder). This is a guess =E2=80=94 I don=E2=80=99t think map libraries that = don=E2=80=99t support duplicate detection commonly support take first. = I suspect some do take first, some do take last and some do take random. = To me that makes any mention of take first or take last in the = specification not very valuable especially as it doesn=E2=80=99t have = much memory, CPU or code advantage over duplicate detection. LL= --Apple-Mail=_4E416485-5BF0-4C6D-B865-31F33140BE6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Here=E2=80=99s a rough proposed text:

The protocol designer should = make a choice for maps as to whether duplicates are allowed or not, = particularly as to whether duplicates would cause security or = functionality problems.

The protocol designer should only require duplicate detection = when necessary as it can have the following implications:
  • Some generic decoders do not = support duplicate detection because the underlying facilities in their = programming environment to represent maps can=E2=80=99t detect = duplicates
  • Some generic decoders do not support = duplicate detection because it requires more code and is not = required
  • It requires more resources to implement: 1) = memory to store all the keys in the map, 2) more code, 3) more CPU time, = as much as O(n^2). This is particularly an issue with big maps in = constrained environments.
It is suggested = that protocol designers require duplicate detection only no the = particular maps for which there is an issue.

Decoders will typically fall into one = of these categories:
  • Full duplicate detection
  • Pass all items up = to caller, allowing the caller to implement duplicate detection or = not
  • No duplicate detection
A generic decoder should identify which it is. Some may = support more than one, selectable by = configuration.

Here=E2=80=99s why.

I see no value in take first or take = last over duplicate detection. In all three all, the keys encountered = must be recorded and processed. If the map is large this will take a lot = of memory. In all cases there is some extra code and CPU. CPU time is = worse than O(n), perhaps O(n^2). It doesn=E2=80=99t matter if the use = case is streaming or not. It is the memory, code and CPU time that = matter.  (Take last can only be implemented by decoding the whole = map, as it is only after decoding the whole map that it can know it has = encountered the last; in a way you cannot do the last for a streaming = decoder).

This = is a guess =E2=80=94 I don=E2=80=99t think map libraries that don=E2=80=99= t support duplicate detection commonly support  take first. I = suspect some do take first, some do take last and some do take random. = To me that makes any mention of take first or take last in the = specification not very valuable especially as it doesn=E2=80=99t have = much memory, CPU or code advantage over duplicate detection.

LL
= --Apple-Mail=_4E416485-5BF0-4C6D-B865-31F33140BE6F-- From nobody Sat Nov 23 01:11: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 CCD4812090A for ; Sat, 23 Nov 2019 01:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.251 X-Spam-Level: X-Spam-Status: No, score=-9.251 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.249, 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 hJUmli4o5aCj for ; Sat, 23 Nov 2019 01:11:35 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 96DE7120908 for ; Sat, 23 Nov 2019 01:11:35 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id r20so10827661qtp.13 for ; Sat, 23 Nov 2019 01:11:35 -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=JlrYV7ve1IiQjUyiUtJlA6/QuP1+8de94x6p4lzuQU8=; b=gBMybBuTPEVYwZV8P2pEDIfZ1sLs1tdxhj7ZlFeR7jzptHc3DliUdg6IkGrTU5Ae9L 1i19APyTCHSC10+DEb3dHPS4ZLapJ4VmLyJLiX1tdttZS1H2b1ceF+VzPZ62/CSmpXzm dPuPa2lBrwUUycy2yGaOGdonPkdysVePvTZVI= 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=JlrYV7ve1IiQjUyiUtJlA6/QuP1+8de94x6p4lzuQU8=; b=Ygdx/3lEd9Zt/OBvZv0HzPIKCyXQRXZz8fM8dSoBL75apXe7TeW9xQsnk43+jltQZj UfJ6o3zg5zHBwWU7C6E7CuFZOaxiyACsspj3nilMTKgA1YaXz1skJTtNIW+aAb+XXRqX +uFY0MBOxQ0bRgU1kJA/2WYgkvvoHc+mvxuZa69TvpoJS3e0JaHoKs745dMGW/Wt4LW4 FrxURPEBzt/WHHjTUw7Q0ux0IPmcuCJlz+bsdPC+j7w8RdqZQZjk6NRTdCc+raQxTsRt 3MBTL3I9ruL3sh3eD6Ue/aR7Trt9fJxEfJP7ZrYKlS4dWWRWRUqm+kvnly23UadB8wqZ I7CA== X-Gm-Message-State: APjAAAXKaHzSlua6cjjVt8HM+oZ/WsKeXRmAwHP7TrVRvcWmwtXKmyI0 qoxBiha5QbxhHC5dJqGG0F9pxa+v51SH0KV0vNsAPUDOOFJlOjCM X-Google-Smtp-Source: APXvYqxRcsfjyNVa9E6uwtlmWL4yA4Y+LZpxR9GqCW7fXvxnT3Go01NH2aN92iSS8jWpnkBXniGPrDGSfTzSwvdRJU8= X-Received: by 2002:aed:37c6:: with SMTP id j64mr2161577qtb.364.1574500293957; Sat, 23 Nov 2019 01:11:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Sat, 23 Nov 2019 17:11:22 +0800 Message-ID: To: Laurence Lundblade Cc: Jeffrey Yasskin , cbor@ietf.org Content-Type: multipart/alternative; boundary="000000000000b8db0c0597ffea77" 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: Sat, 23 Nov 2019 09:11:37 -0000 --000000000000b8db0c0597ffea77 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 23, 2019 at 10:00 AM Laurence Lundblade wrote: > Here=E2=80=99s a rough proposed text: > > The protocol designer should make a choice for maps as to whether > duplicates are allowed or not, particularly as to whether duplicates woul= d > cause security or functionality problems. > > The protocol designer should only require duplicate detection when > necessary as it can have the following implications: > > - Some generic decoders do not support duplicate detection because the > underlying facilities in their programming environment to represent ma= ps > can=E2=80=99t detect duplicates > - Some generic decoders do not support duplicate detection because it > requires more code and is not required > > > - It requires more resources to implement: 1) memory to store all the > keys in the map, 2) more code, 3) more CPU time, as much as O(n^2). Th= is is > particularly an issue with big maps in constrained environments. > > It is suggested that protocol designers require duplicate detection only > no the particular maps for which there is an issue. > > Decoders will typically fall into one of these categories: > > - Full duplicate detection > - Pass all items up to caller, allowing the caller to implement > duplicate detection or not > - No duplicate detection > > A generic decoder should identify which it is. Some may support more than > one, selectable by configuration. > > I don't think generic decoders are relevant here. Protocol implementations often accumulate their input into a data structure even if they use a streaming decoder to read the input. Any such protocol can detect duplicates (of the keys it uses at all) for at most the cost of an extra bit per field. Here=E2=80=99s why. > > I see no value in take first or take last over duplicate detection. In al= l > three all, the keys encountered must be recorded and processed. If the ma= p > is large this will take a lot of memory. In all cases there is some extra > code and CPU. CPU time is worse than O(n), perhaps O(n^2). It doesn=E2=80= =99t > matter if the use case is streaming or not. It is the memory, code and CP= U > time that matter. (Take last can only be implemented by decoding the who= le > map, as it is only after decoding the whole map that it can know it has > encountered the last; in a way you cannot do the last for a streaming > decoder). > > This is a guess =E2=80=94 I don=E2=80=99t think map libraries that don=E2= =80=99t support duplicate > detection commonly support take first. I suspect some do take first, som= e > do take last and some do take random. To me that makes any mention of tak= e > first or take last in the specification not very valuable especially as i= t > doesn=E2=80=99t have much memory, CPU or code advantage over duplicate de= tection. > I think you make a good point that if a protocol is going to specify "take first", it can probably specify "error on duplicate key" for the same cost. That might imply some much simpler text: "Protocols based on CBOR SHOULD fail with an error if a map contains a > duplicate key, except that if the key isn't used at all, they MAY ignore = it > instead. Protocols that do not reject duplicate keys MUST (?) document wh= y > the cost of rejecting duplicates is too high and why accepting them will > not lead to security vulnerabilities. An array might be a better choice f= or > such protocols." Do we have any concrete examples of protocols or formats built on CBOR that don't store anything while parsing their input? One of those might provide a good example of a protocol that shouldn't reject duplicates. Jeffrey --000000000000b8db0c0597ffea77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Nov 23, 2019 at 10:00 AM Laurence= Lundblade <lgl@island-resort.c= om> wrote:
Here=E2=80=99s a rough proposed text:

The protocol des= igner should make a choice for maps as to whether duplicates are allowed or= not, particularly as to whether duplicates would cause security or functio= nality problems.

The protocol designer should only= require duplicate detection when necessary as it can have the following im= plications:
  • Some generic decoders do not support duplicat= e detection because the underlying facilities in their programming environm= ent to represent maps can=E2=80=99t detect duplicates
  • Some generic = decoders do not support duplicate detection because it requires more code a= nd is not required
  • It requires more resources to implement: 1) memory to store= all the keys in the map, 2) more code, 3) more CPU time, as much as O(n^2)= . This is particularly an issue with big maps in constrained environments.<= /li>
It is suggested that protocol designers require duplica= te detection only no the particular maps for which there is an issue.
=

Decoders will typically fall into one of these categori= es:
  • Full duplicate detection
  • Pass all items up to= caller, allowing the caller to implement duplicate detection or not
    • No duplicate detection
A generic decoder should ident= ify which it is. Some may support more than one, selectable by configuratio= n.

I don't thi= nk generic decoders are relevant here. Protocol implementations often accum= ulate their input into a data structure even if they use a streaming decode= r to read the input. Any such protocol can detect duplicates (of the keys i= t uses at all) for at most the cost of an extra bit per field.
Here=E2=80=99s why.

=
I see no value in take first or take last over duplicate detecti= on. In all three all, the keys encountered must be recorded and processed. = If the map is large this will take a lot of memory. In all cases there is s= ome extra code and CPU. CPU time is worse than O(n), perhaps O(n^2). It doe= sn=E2=80=99t matter if the use case is streaming or not. It is the memory, = code and CPU time that matter. =C2=A0(Take last can only be implemented by = decoding the whole map, as it is only after decoding the whole map that it = can know it has encountered the last; in a way you cannot do the last for a= streaming decoder).

This is a guess =E2=80=94 I d= on=E2=80=99t think map libraries that don=E2=80=99t support duplicate detec= tion commonly support =C2=A0take first. I suspect some do take first, some = do take last and some do take random. To me that makes any mention of take = first or take last in the specification not very valuable especially as it = doesn=E2=80=99t have much memory, CPU or code advantage over duplicate dete= ction.

I think you make a good = point that if a protocol is going to specify "take first", it can= probably specify "error on duplicate key" for the same cost. Tha= t might imply some much simpler text:

"Protocols base= d on CBOR SHOULD fail with an error if a map contains a duplicate key, exce= pt that if the key isn't used at all, they MAY ignore it instead. Proto= cols that do not reject duplicate keys MUST (?) document why the cost of re= jecting duplicates is too high and why accepting them will not lead to secu= rity vulnerabilities. An array might be a better choice for such protocols.= "

<= /div>
Do we have any concrete examples of protocols or formats built on= CBOR that don't store anything while parsing their input? One of those= might provide a good example of a protocol that shouldn't reject dupli= cates.

Jeffrey
--000000000000b8db0c0597ffea77-- From nobody Sat Nov 23 07:21:55 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 91E93120116 for ; Sat, 23 Nov 2019 07:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwlNqwWYRjCy for ; Sat, 23 Nov 2019 07:21:51 -0800 (PST) Received: from p3plsmtpa06-09.prod.phx3.secureserver.net (p3plsmtpa06-09.prod.phx3.secureserver.net [173.201.192.110]) (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 6F0EF1200B9 for ; Sat, 23 Nov 2019 07:21:51 -0800 (PST) Received: from [10.86.0.74] ([45.56.150.43]) by :SMTPAUTH: with ESMTPA id YXELi8ky2Xf0IYXELicbL1; Sat, 23 Nov 2019 08:21:50 -0700 From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B634E199-74B2-4A14-AFEE-0FF99865E609" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 23 Nov 2019 07:21:49 -0800 In-Reply-To: Cc: Jeffrey Yasskin , cbor@ietf.org To: Jeffrey Yasskin References: X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfNaX6II8ldZcz/TGAMVkA5R9shhcbtMSducBkF5d874PpyHf+jo9Ut4LcNhVVzEKkMNqN6/wi8onvZQLMWTlvataL2HPofnt7Qhmz1bVEol/vkImn+4f o3uVfkgMbGK6XmT889gaPW/r5QdeiErJp/8oYhdHY/ZwmyIVgaFGtrrxtdZNduNQ0cdX3T6y4KdzcMyGNQiX+djiUfNDAFK0R5CK7try41bH0iUokfdgvtBl bPNksb88iLb58nxEI0nF8w== 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: Sat, 23 Nov 2019 15:21:53 -0000 --Apple-Mail=_B634E199-74B2-4A14-AFEE-0FF99865E609 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 23, 2019, at 1:11 AM, Jeffrey Yasskin = wrote: >=20 > On Sat, Nov 23, 2019 at 10:00 AM Laurence Lundblade = > wrote: > Here=E2=80=99s a rough proposed text: >=20 > The protocol designer should make a choice for maps as to whether = duplicates are allowed or not, particularly as to whether duplicates = would cause security or functionality problems. >=20 > The protocol designer should only require duplicate detection when = necessary as it can have the following implications: > Some generic decoders do not support duplicate detection because the = underlying facilities in their programming environment to represent maps = can=E2=80=99t detect duplicates > Some generic decoders do not support duplicate detection because it = requires more code and is not required > It requires more resources to implement: 1) memory to store all the = keys in the map, 2) more code, 3) more CPU time, as much as O(n^2).. = This is particularly an issue with big maps in constrained environments. > It is suggested that protocol designers require duplicate detection = only no the particular maps for which there is an issue. >=20 > Decoders will typically fall into one of these categories: > Full duplicate detection > Pass all items up to caller, allowing the caller to implement = duplicate detection or not > No duplicate detection > A generic decoder should identify which it is. Some may support more = than one, selectable by configuration. >=20 > I don't think generic decoders are relevant here. Protocol = implementations often accumulate their input into a data structure even = if they use a streaming decoder to read the input. Any such protocol can = detect duplicates (of the keys it uses at all) for at most the cost of = an extra bit per field. My intention was that =E2=80=9Cpass all items up=E2=80=9D covers your = case.=20 My QCBOR + t_cose implementations work exactly as you describe to = implement dup detection in COSE header parameters. It=E2=80=99s the data = structures that hold the COSE header params that are used to detect the = duplicates, not the generic decoder (QCBOR). This seems like a good way = to handle this problem for lots of use cases.=20 >=20 > Here=E2=80=99s why. >=20 > I see no value in take first or take last over duplicate detection. In = all three all, the keys encountered must be recorded and processed. If = the map is large this will take a lot of memory. In all cases there is = some extra code and CPU. CPU time is worse than O(n), perhaps O(n^2). It = doesn=E2=80=99t matter if the use case is streaming or not. It is the = memory, code and CPU time that matter. (Take last can only be = implemented by decoding the whole map, as it is only after decoding the = whole map that it can know it has encountered the last; in a way you = cannot do the last for a streaming decoder). >=20 > This is a guess =E2=80=94 I don=E2=80=99t think map libraries that = don=E2=80=99t support duplicate detection commonly support take first. = I suspect some do take first, some do take last and some do take random. = To me that makes any mention of take first or take last in the = specification not very valuable especially as it doesn=E2=80=99t have = much memory, CPU or code advantage over duplicate detection. >=20 > I think you make a good point that if a protocol is going to specify = "take first", it can probably specify "error on duplicate key" for the = same cost. That might imply some much simpler text: >=20 > "Protocols based on CBOR SHOULD fail with an error if a map contains a = duplicate key, except that if the key isn't used at all, they MAY ignore = it instead. Protocols that do not reject duplicate keys MUST (?) = document why the cost of rejecting duplicates is too high and why = accepting them will not lead to security vulnerabilities. An array might = be a better choice for such protocols.=E2=80=9D I think I=E2=80=99d invert it and say that protocols that require = duplicate detection for security reasons should describe that = requirement in security considerations so the implementor gets a good = solid hint that they need to worry about it. There is lot of text implying that duplicates are bad, but I think it = would be worth being explicit. You are an idiot if you design a protocol that considers duplicate input = valid or necessary. Duplicate map keys are always an error in CBOR and = will not work with many generic decoders. >=20 > Do we have any concrete examples of protocols or formats built on CBOR = that don't store anything while parsing their input? One of those might = provide a good example of a protocol that shouldn't reject duplicates. Duplicates will / must only occur in error situations. It is always = right to reject encoded CBOR that has duplicates. The main thing is that when duplicates have security implications for = the protocol, that must be called out and the implementor told to do = something about them.=20 To say it more in prose: They should either use a generic CBOR decoder = that errors out on duplicates, or a CBOR decoder that passes duplicates = up so the protocol implementation on top of CBOR can do the detection. = What they must not do is use a decoder that does take first, take last = or randomly takes one of the occurrences. LL --Apple-Mail=_B634E199-74B2-4A14-AFEE-0FF99865E609 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 23, 2019, at 1:11 AM, Jeffrey Yasskin <jyasskin@chromium.org> wrote:

On Sat, Nov 23, 2019 at 10:00 AM = Laurence Lundblade <lgl@island-resort.com> wrote:
Here=E2=80=99s a rough proposed = text:

The protocol designer should make a choice for maps as to = whether duplicates are allowed or not, particularly as to whether = duplicates would cause security or functionality problems.

The protocol designer = should only require duplicate detection when necessary as it can have = the following implications:
  • Some generic decoders do not support duplicate detection = because the underlying facilities in their programming environment to = represent maps can=E2=80=99t detect duplicates
  • Some = generic decoders do not support duplicate detection because it requires = more code and is not = required
  • It requires more resources to implement: 1) = memory to store all the keys in the map, 2) more code, 3) more CPU time, = as much as O(n^2).. This is particularly an issue with big maps in = constrained environments.
It is suggested = that protocol designers require duplicate detection only no the = particular maps for which there is an issue.

Decoders will typically fall into one = of these categories:
  • Full duplicate detection
  • Pass all items up = to caller, allowing the caller to implement duplicate detection or = not
  • No duplicate detection
A generic decoder should identify which it is. Some may = support more than one, selectable by = configuration.

I don't think generic decoders are = relevant here. Protocol implementations often accumulate their input = into a data structure even if they use a streaming decoder to read the = input. Any such protocol can detect duplicates (of the keys it uses at = all) for at most the cost of an extra bit per = field.

My intention was that =E2=80=9Cpass all items = up=E2=80=9D covers your case. 

My= QCBOR + t_cose implementations work exactly as you describe to = implement dup detection in COSE header parameters. It=E2=80=99s the data = structures that hold the COSE header params that are used to detect the = duplicates, not the generic decoder (QCBOR).  This seems like a = good way to handle this problem for lots of use = cases. 



Here=E2=80=99= s why.

I see = no value in take first or take last over duplicate detection. In all = three all, the keys encountered must be recorded and processed. If the = map is large this will take a lot of memory. In all cases there is some = extra code and CPU. CPU time is worse than O(n), perhaps O(n^2). It = doesn=E2=80=99t matter if the use case is streaming or not. It is the = memory, code and CPU time that matter.  (Take last can only be = implemented by decoding the whole map, as it is only after decoding the = whole map that it can know it has encountered the last; in a way you = cannot do the last for a streaming decoder).

This is a guess =E2=80=94 I don=E2=80=99t= think map libraries that don=E2=80=99t support duplicate detection = commonly support  take first. I suspect some do take first, some do = take last and some do take random. To me that makes any mention of take = first or take last in the specification not very valuable especially as = it doesn=E2=80=99t have much memory, CPU or code advantage over = duplicate detection.

I think you make a good point that if a = protocol is going to specify "take first", it can probably specify = "error on duplicate key" for the same cost. That might imply some much = simpler text:

"Protocols based on CBOR SHOULD fail = with an error if a map contains a duplicate key, except that if the key = isn't used at all, they MAY ignore it instead. Protocols that do not = reject duplicate keys MUST (?) document why the cost of rejecting = duplicates is too high and why accepting them will not lead to security = vulnerabilities. An array might be a better choice for such = protocols.=E2=80=9D

I think I=E2=80=99d invert it and say = that protocols that require duplicate detection for security reasons = should describe that requirement in security considerations so the = implementor gets a good solid hint that they need to worry about = it.

There is lot of text implying = that duplicates are bad, but I think it would be worth being = explicit.

You are an idiot if you design a protocol that = considers duplicate input valid or necessary. Duplicate map keys are = always an error in CBOR and will not work with many generic = decoders.


Do we have any concrete examples of = protocols or formats built on CBOR that don't store anything while = parsing their input? One of those might provide a good example of a = protocol that shouldn't reject = duplicates.


Duplicates will / must = only occur in error situations. It is always right to reject encoded = CBOR that has duplicates.

The main = thing is that when duplicates have security implications for the = protocol, that must be called out and the implementor told to do = something about them. 

To say = it more in prose: They should either use a generic CBOR decoder that = errors out on duplicates, or a CBOR decoder that passes duplicates up so = the protocol implementation on top of CBOR can do the detection. What = they must not do is use a decoder that does take first, take last or = randomly takes one of the occurrences.

LL

= --Apple-Mail=_B634E199-74B2-4A14-AFEE-0FF99865E609-- From nobody Sat Nov 23 09:11:27 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 80F3212082A for ; Sat, 23 Nov 2019 09:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLy0kY4eHRUM for ; Sat, 23 Nov 2019 09:11:24 -0800 (PST) Received: from p3plsmtpa06-06.prod.phx3.secureserver.net (p3plsmtpa06-06.prod.phx3.secureserver.net [173.201.192.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9AF120133 for ; Sat, 23 Nov 2019 09:11:24 -0800 (PST) Received: from [10.86.0.74] ([45.56.150.43]) by :SMTPAUTH: with ESMTPA id YYwNiPM5FtvENYYwOiSCd6; Sat, 23 Nov 2019 10:11:24 -0700 From: Laurence Lundblade Message-Id: <92F6E676-5669-46C1-9C4E-54719BBB5A7F@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_561B23A6-03D4-477A-83F4-E69DE0C41133" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 23 Nov 2019 09:11:23 -0800 In-Reply-To: Cc: Jeffrey Yasskin , cbor@ietf.org To: Jeffrey Yasskin References: X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfECwjPyTizuA8Xc0QwQ/vej0lxAaKW19fXhyR2RMBCipTKfzUm1+rFriLCkDvTcV03vP2XQukFY3hlZBtCa0/3g2bBNl3fkTUrw9aBf+uFkFXyshApOb RG4Aq6jLRzU4d7ExCt4GYUlEHXpWTfxLvXuU09gCmXBJtdgzOVHABRjCJ4g7lilbExbSR2thx+bGIgzPjwFNsyKFNPxT47vAfIrl1NiHLIyUGMRqmzBJ5pui JlLipyS6CEVL/Gxg5D6qfw== 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: Sat, 23 Nov 2019 17:11:25 -0000 --Apple-Mail=_561B23A6-03D4-477A-83F4-E69DE0C41133 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 23, 2019, at 7:21 AM, Laurence Lundblade = wrote: >=20 > To say it more in prose: They should either use a generic CBOR decoder = that errors out on duplicates, or a CBOR decoder that passes duplicates = up so the protocol implementation on top of CBOR can do the detection. = What they must not do is use a decoder that does take first, take last = or randomly takes one of the occurrences. To be really explicit (for my brain too), it is never right for normal = behavior of a CBOR protocol to rely on take first. It is *always* right = to error out when duplicates are detected. LL= --Apple-Mail=_561B23A6-03D4-477A-83F4-E69DE0C41133 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Nov 23, 2019, at 7:21 AM, Laurence Lundblade <lgl@island-resort.com> wrote:

To say it more in prose: They = should either use a generic CBOR decoder that errors out on duplicates, = or a CBOR decoder that passes duplicates up so the protocol = implementation on top of CBOR can do the detection. What they must not = do is use a decoder that does take first, take last or randomly takes = one of the occurrences.

To be really explicit (for my brain too), it is never right = for normal behavior of a CBOR protocol to rely on take first. It is = *always* right to error out when duplicates are detected.

LL
= --Apple-Mail=_561B23A6-03D4-477A-83F4-E69DE0C41133-- From nobody Sat Nov 23 17:58: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 0CD71120045 for ; Sat, 23 Nov 2019 17:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 QcGruVf6-ILt for ; Sat, 23 Nov 2019 17:58:30 -0800 (PST) Received: from gabriel-vm-2.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 A697F120013 for ; Sat, 23 Nov 2019 17:58:29 -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.uni-bremen.de (Postfix) with ESMTPSA id 47LCxb4YNkz10v2; Sun, 24 Nov 2019 02:58:27 +0100 (CET) From: Carsten Bormann Content-Type: multipart/alternative; boundary="Apple-Mail=_4C6CCCAB-B84C-4A20-B584-D55731D32961" X-Mao-Original-Outgoing-Id: 596253505.3359489-d319903be5de4787878440f67b132e9a Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sun, 24 Nov 2019 02:58:27 +0100 Message-Id: References: To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] Fwd: [Technical Errata Reported] RFC7049 (5917) 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, 24 Nov 2019 01:58:33 -0000 --Apple-Mail=_4C6CCCAB-B84C-4A20-B584-D55731D32961 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Whoops. Which brings up the idea: Maybe we can start a campaign alerting the = implementers to our WGLC? I started in https://github.com/fxamacker/cbor/issues/46 = , but there are three score = implementations remaining=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: Carsten Bormann > Subject: Re: [Technical Errata Reported] RFC7049 (5917) > Date: November 24, 2019 at 02:44:28 GMT+1 > To: RFC Errata System > Cc: Paul Hoffman , iesg@ietf.org, = faye.github@gmail.com >=20 > This errata report is correct. >=20 > We fixed this in the 7049bis document (which is currently in = working-group last call) in revision f3bde9d: = https://github.com/cbor-wg/CBORbis/commit/f3bde9d . Unfortunately, it = didn=E2=80=99t occur to us to also supply an errata report, which should = have been done. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On Nov 24, 2019, at 02:06, RFC Errata System = wrote: >>=20 >> The following errata report has been submitted for RFC7049, >> "Concise Binary Object Representation (CBOR)". >>=20 >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid5917 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Faye Amacker >>=20 >> Section: Appendix A >>=20 >> Original Text >> ------------- >> simple(24) | 0xf818 =20 >>=20 >> Corrected Text >> -------------- >>=20 >>=20 >> Notes >> ----- >> This example violates RFC 7049 section 2.3 Floating-Point Numbers and = Values with No Content. =20 >>=20 >> The incorrect example in Appendix A clearly uses a value <32 which is = not allowed. >>=20 >> First, RFC 7049 section 2.3 has a table that shows: >> | 24 | Simple value (value 32..255 in following byte) | >>=20 >> Next, RFC 7049 section 2.3 says: >> As with all other major types, the 5-bit value 24 signifies a single- >> byte extension: it is followed by an additional byte to represent the >> simple value. (To minimize confusion, only the values 32 to 255 are >> used.) >>=20 >> Wikipedia is also currently incorrect by having an interpretation = based on the incorrect example from RFC 7049 Appendix A instead of the = text from RFC 7049 Section 2.3. >>=20 >> Credits: This problem was first reported at = https://github.com/fxamacker/cbor/issues/46 >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party =20 >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC7049 (draft-bormann-cbor-09) >> -------------------------------------- >> Title : Concise Binary Object Representation (CBOR) >> Publication Date : October 2013 >> Author(s) : C. Bormann, P. Hoffman >> Category : PROPOSED STANDARD >> Source : IETF - NON WORKING GROUP >> Area : N/A >> Stream : IETF >> Verifying Party : IESG >=20 --Apple-Mail=_4C6CCCAB-B84C-4A20-B584-D55731D32961 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Whoops.

Which brings up the idea: Maybe we can start a campaign = alerting the implementers to our WGLC?
I started = in https://github.com/fxamacker/cbor/issues/46, but there = are three score implementations remaining=E2=80=A6

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


Begin = forwarded message:

From: = Carsten Bormann <cabo@tzi.org>
Subject: = Re: [Technical = Errata Reported] RFC7049 (5917)
Date: = November 24, 2019 at 02:44:28 = GMT+1
To: = RFC Errata System <rfc-editor@rfc-editor.org>
Cc: = Paul Hoffman <paul.hoffman@vpnc.org>, iesg@ietf.org, faye.github@gmail.com

This errata report is = correct.

We fixed this in the 7049bis = document (which is currently in working-group last call) in revision = f3bde9d: https://github.com/cbor-wg/CBORbis/commit/f3bde9d . =  Unfortunately, it didn=E2=80=99t occur to us to also supply an = errata report, which should have been done.

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


On Nov 24, 2019, at = 02:06, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

The following errata report has been submitted for = RFC7049,
"Concise Binary Object Representation (CBOR)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5917
--------------------------------------
Type: = Technical
Reported by: Faye Amacker = <faye.github@gmail.com>

Section: = Appendix A

Original Text
-------------
simple(24) =             &n= bsp;     | 0xf818  

Corrected Text
--------------


Notes
-----
This = example violates RFC 7049 section 2.3 Floating-Point Numbers and Values = with No Content.  

The incorrect = example in Appendix A clearly uses a value <32 which is not = allowed.

First, RFC 7049 section 2.3 has a = table that shows:
| 24 =          | Simple value = (value 32..255 in following byte)   |

Next, RFC 7049 section 2.3 says:
As with all = other major types, the 5-bit value 24 signifies a single-
byte extension: it is followed by an additional byte to = represent the
simple value.  (To minimize confusion, = only the values 32 to 255 are
used.)

Wikipedia is also currently incorrect by having an = interpretation based on the incorrect example from RFC 7049 Appendix A = instead of the text from RFC 7049 Section 2.3.

Credits: This problem was first reported at = https://github.com/fxamacker/cbor/issues/46

Instructions:
-------------
This = erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified = or
rejected. When a decision is reached, the verifying = party  
can log in to change the status and edit the = report, if necessary.

--------------------------------------
RFC7049 = (draft-bormann-cbor-09)
--------------------------------------
Title =             &n= bsp; : Concise Binary Object Representation (CBOR)
Publication Date    : October 2013
Author(s) =           : C. = Bormann, P. Hoffman
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: IETF - NON WORKING GROUP
Area =             &n= bsp;  : N/A
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG


= --Apple-Mail=_4C6CCCAB-B84C-4A20-B584-D55731D32961-- From nobody Sun Nov 24 02: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 7DFE212012A for ; Sun, 24 Nov 2019 02:49:11 -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.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TLiAQzxyzczB for ; Sun, 24 Nov 2019 02:49:09 -0800 (PST) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 A1DB312012C for ; Sun, 24 Nov 2019 02:49:09 -0800 (PST) Received: by mail-qv1-xf2c.google.com with SMTP id cv8so4597286qvb.3 for ; Sun, 24 Nov 2019 02:49:09 -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=D1zSoC2UF6+sm0Jb58JdETnwZpQc7ScWw+QOcIqL5cA=; b=IigGZs4upYzAIaXohQW6Lqxc9QLLbirkG/mH35xJU2hyyqp3ruTwSAgbGetptbNqh/ ZKw25fGlFUCTVIXs4Bg8q2M1/QfYhA8jCTVblwNHk3+jO01iJ85FHiHNbB+Xwnx2TSI+ V2hHx1RHqozZtB7no/04Cy6kFSdRh2Xcs8uWk= 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=D1zSoC2UF6+sm0Jb58JdETnwZpQc7ScWw+QOcIqL5cA=; b=PsHowx26t1D/hr7qch8neHrl93qsze1CsFn+Wvi94sPNcdJPEfqT7i8NDParj+VL7I Or5BCkN3eMW3xu72EcbEI66s+F61mq02PZFBXtvezrJ4qx4kxIEsQ/94UHD+uOnRSmYB ZtKFL+Dr+arIfeFmPL+om/3CGUpJHcVT2QHpX64HOT5ST6qWg7TdgXmhX0z24NIaOx6r dPfntI67Ti4ddVciTyZjsiHtNrdyc/aE+2OQ0DJgfd1RRLIq4ZAnDONUHzMwYYKdK80x VJAZ84lELv1hXapCF40RYGWTWOHQ7ypuBVvU+WLwKtuLYqtYn96TKJcWitwPrFkd29Up tgfg== X-Gm-Message-State: APjAAAVbTjTG/7SsCG/pr/J3Y+1qpQXi/GK3sB9g2v6GBguNjRH7UtGs js3fJInH+vYBITt/0HGF9869auapwqhxS2Y0nZq2yg== X-Google-Smtp-Source: APXvYqx5QBYssMh35jwHtdCkU6kep0hD/EZQprBmZBpvbSbiid6umR9cMZ4OSaAEtaW8oFD+jAvE5hPRtlt+AtQHPCU= X-Received: by 2002:a0c:fa0a:: with SMTP id q10mr21691022qvn.193.1574592547856; Sun, 24 Nov 2019 02:49:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Sun, 24 Nov 2019 02:48:56 -0800 Message-ID: To: Laurence Lundblade Cc: Jeffrey Yasskin , Jeffrey Yasskin , cbor@ietf.org Content-Type: multipart/alternative; boundary="0000000000007b97c90598156577" 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: Sun, 24 Nov 2019 10:49:11 -0000 --0000000000007b97c90598156577 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Comments inline: On Sat, Nov 23, 2019 at 7:21 AM Laurence Lundblade wrote: > On Nov 23, 2019, at 1:11 AM, Jeffrey Yasskin > wrote: > > On Sat, Nov 23, 2019 at 10:00 AM Laurence Lundblade > wrote: > >> Here=E2=80=99s a rough proposed text: >> >> The protocol designer should make a choice for maps as to whether >> duplicates are allowed or not, particularly as to whether duplicates wou= ld >> cause security or functionality problems. >> >> The protocol designer should only require duplicate detection when >> necessary as it can have the following implications: >> >> - Some generic decoders do not support duplicate detection because >> the underlying facilities in their programming environment to represe= nt >> maps can=E2=80=99t detect duplicates >> - Some generic decoders do not support duplicate detection because it >> requires more code and is not required >> >> >> - It requires more resources to implement: 1) memory to store all the >> keys in the map, 2) more code, 3) more CPU time, as much as O(n^2).. = This >> is particularly an issue with big maps in constrained environments. >> >> It is suggested that protocol designers require duplicate detection only >> no the particular maps for which there is an issue. >> >> Decoders will typically fall into one of these categories: >> >> - Full duplicate detection >> - Pass all items up to caller, allowing the caller to implement >> duplicate detection or not >> - No duplicate detection >> >> A generic decoder should identify which it is. Some may support more tha= n >> one, selectable by configuration. >> >> > I don't think generic decoders are relevant here. Protocol implementation= s > often accumulate their input into a data structure even if they use a > streaming decoder to read the input. Any such protocol can detect > duplicates (of the keys it uses at all) for at most the cost of an extra > bit per field. > > > My intention was that =E2=80=9Cpass all items up=E2=80=9D covers your cas= e. > > My QCBOR + t_cose implementations work exactly as you describe to > implement dup detection in COSE header parameters. It=E2=80=99s the data = structures > that hold the COSE header params that are used to detect the duplicates, > not the generic decoder (QCBOR). This seems like a good way to handle th= is > problem for lots of use cases. > Yep, that's the model I'm thinking of. I'm clearly struggling to put it into understandable spec language. > I think you make a good point that if a protocol is going to specify "tak= e > first", it can probably specify "error on duplicate key" for the same cos= t. > That might imply some much simpler text: > > "Protocols based on CBOR SHOULD fail with an error if a map contains a >> duplicate key, except that if the key isn't used at all, they MAY ignore= it >> instead. Protocols that do not reject duplicate keys MUST (?) document w= hy >> the cost of rejecting duplicates is too high and why accepting them will >> not lead to security vulnerabilities. An array might be a better choice = for >> such protocols.=E2=80=9D > > > I think I=E2=80=99d invert it and say that protocols that require duplica= te > detection for security reasons should describe that requirement in securi= ty > considerations so the implementor gets a good solid hint that they need t= o > worry about it. > There's an interesting difference of approach here. It's plausible to say that protocol designers should pick the secure design only when they realize their design has security implications, but I prefer to say that they should pick the secure design unless they think about it and realize the design doesn't have security implications. I think the second will get us noticeably more security in a world where designers don't have time to think about every aspect of every piece of their design. There is lot of text implying that duplicates are bad, but I think it would > be worth being explicit. > > You are an idiot if you design a protocol that considers duplicate input > valid or necessary. Duplicate map keys are always an error in CBOR and wi= ll > not work with many generic decoders. > > I wouldn't say "idiot", just "wrong". The spec already says you "MUST NOT" do this, but I'm not opposed to making that statement more direct. Thanks, Jeffrey --0000000000007b97c90598156577 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comments inline:

On Sat, Nov 23, 2019 at 7:21 AM Laurence Lundblade <lgl@island-resort.com> wrote:
On Nov 23, 2019, at 1:11 AM, Jeffrey Yasskin <jyasskin@chromium.org> wrote:=

On Sat, Nov 23, 2019 at 10= :00 AM Laurence Lundblade <lgl@island-resort.com> wrote:
Her= e=E2=80=99s a rough proposed text:

The protocol designe= r should make a choice for maps as to whether duplicates are allowed or not= , particularly as to whether duplicates would cause security or functionali= ty problems.

The protocol designer should only req= uire duplicate detection when necessary as it can have the following implic= ations:
  • Some generic decoders do not support duplicate de= tection because the underlying facilities in their programming environment = to represent maps can=E2=80=99t detect duplicates
  • Some generic deco= ders do not support duplicate detection because it requires more code and i= s not required
  • It requires more resource= s to implement: 1) memory to store all the keys in the map, 2) more code, 3= ) more CPU time, as much as O(n^2).. This is particularly an issue with big= maps in constrained environments.
It is suggested that= protocol designers require duplicate detection only no the particular maps= for which there is an issue.

Decoders will typica= lly fall into one of these categories:
  • Full duplicate det= ection
  • Pass all items up to caller, allowing the caller to implemen= t duplicate detection or not
  • No duplicate detection
=
A generic decoder should identify which it is. Some may support more t= han one, selectable by configuration.
=

I don't think generic decoders are relevant here. P= rotocol implementations often accumulate their input into a data structure = even if they use a streaming decoder to read the input. Any such protocol c= an detect duplicates (of the keys it uses at all) for at most the cost of a= n extra bit per field.

<= div>My intention was that =E2=80=9Cpass all items up=E2=80=9D covers your c= ase.=C2=A0

My QCBOR + t_cose implementations work = exactly as you describe to implement dup detection in COSE header parameter= s. It=E2=80=99s the data structures that hold the COSE header params that a= re used to detect the duplicates, not the generic decoder (QCBOR).=C2=A0 Th= is seems like a good way to handle this problem for lots of use cases.=C2= =A0

Yep, that's the m= odel I'm thinking of. I'm clearly struggling to put it into underst= andable spec language.=C2=A0
I think you make a goo= d point that if a protocol is going to specify "take first", it c= an probably specify "error on duplicate key" for the same cost. T= hat might imply some much simpler text:

"Protoc= ols based on CBOR SHOULD fail with an error if a map contains a duplicate k= ey, except that if the key isn't used at all, they MAY ignore it instea= d. Protocols that do not reject duplicate keys MUST (?) document why the co= st of rejecting duplicates is too high and why accepting them will not lead= to security vulnerabilities. An array might be a better choice for such pr= otocols.=E2=80=9D
I think I=E2=80=99d invert it and say that protocols that requ= ire duplicate detection for security reasons should describe that requireme= nt in security considerations so the implementor gets a good solid hint tha= t they need to worry about it.

= There's an interesting difference of approach here. It's plausible = to say that protocol designers should pick the secure design only when they= realize their design has security implications, but I prefer to say that t= hey should pick the secure design unless they think about it and realize th= e design doesn't have security implications. I think the second will ge= t us noticeably more security in a world where designers don't have tim= e to think about every aspect of every piece of their design.
There is lot of text implying = that duplicates are bad, but I think it would be worth being explicit.

You are an idiot if you design a protocol that c= onsiders duplicate input valid or necessary. Duplicate map keys are always = an error in CBOR and will not work with many generic decoders.
<= /blockquote>
=C2=A0
I wouldn't say &qu= ot;idiot", just "wrong". The spec already says you "MUS= T NOT" do this, but I'm not opposed to making that statement more = direct.

Thanks,
Jeffrey
--0000000000007b97c90598156577-- From nobody Sun Nov 24 03:24: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 BE3D912012A for ; Sun, 24 Nov 2019 03:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.24 X-Spam-Level: X-Spam-Status: No, score=-9.24 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.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 lNDZtRCR6VP2 for ; Sun, 24 Nov 2019 03:24:01 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 342A2120128 for ; Sun, 24 Nov 2019 03:24:01 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id y39so13780335qty.0 for ; Sun, 24 Nov 2019 03:24: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=CfWuL7SBpBqVOfbR3S0nKkr7z5BM+6c4BN4ugkT0RNw=; b=A2VmWH4Suo35/iYihe90gvYawfpG94DfPMGZPM/s3xNvqhtZ2ww46YhnL63ygrfUz/ t819/XAMF85Ffdk2tpeeLa0kxEzj8fF6wYMsNiAuT3HBPL5rkB+uNc6YQh4pgtRowZVo mzkOHwrMYcmJsdFlTfBYWUyM5Qbb4gwMG69Z0= 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=CfWuL7SBpBqVOfbR3S0nKkr7z5BM+6c4BN4ugkT0RNw=; b=E8u8QVj3vm9Pg0AXXfSIndNSBW4kb4ao9EVPkk1G2TYyOdoGrZgOTEPcwPWSbjp7C7 neUgepxxv5kAy9Yuqaet9mthPCoSO2op6hMZ9+bdxoQyL5C2lJs9QLwT/WP3hCYkrOjx JVpvEm5uXz+9FeQexGDpfF83f3rkwwp7E9tZmk934QytCHS/has4G9dhrUk2sey0wozm FRVJuvo2ru7cKHwupN0Hm1zyf5gzWe214GzshPWNiAHQLrzC0+Tg2Vj+LZKxFKFOKP1y PSeBsDi+aHBQm7cxP3XQ77NS18ja4Vmk3uW20cKoneTzWuYmOA10XhPHvSFt6+VETU8/ FeXg== X-Gm-Message-State: APjAAAWcnwDV+V9yaH+741WrmEp3SzETNRm3lRXTHx+lIZxa+1o3IrSQ wv/l/iazpSokNE1CNPUuGoNBe6oI9AHAOymGYUQQHA== X-Google-Smtp-Source: APXvYqzuSFmqroOQOHUF4MpS9WsYL8bQ9Aa5Ns85euD0wc6mWXydLPJjtvipcS7V+n02h2AXDttCYf+lAZ1xhcVE2yc= X-Received: by 2002:ac8:138b:: with SMTP id h11mr6444943qtj.153.1574594639366; Sun, 24 Nov 2019 03:23:59 -0800 (PST) MIME-Version: 1.0 References: <293AFF31-D0EF-45D6-9B9D-E8136481C404@ericsson.com> In-Reply-To: <293AFF31-D0EF-45D6-9B9D-E8136481C404@ericsson.com> From: Jeffrey Yasskin Date: Sun, 24 Nov 2019 03:23:47 -0800 Message-ID: To: Francesca Palombini Cc: "cbor@ietf.org" , "draft-ietf-cbor-7049bis@ietf.org" , "cbor-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002584e4059815e2d6" 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: Sun, 24 Nov 2019 11:24:04 -0000 --0000000000002584e4059815e2d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry I've been so lax with incremental reviews. Here's a complete set of comments covering all of https://tools.ietf.org/html/draft-ietf-cbor-7049bis-09 (although I only skimmed the appendices). Overall, this is way better than RFC 7049. Thanks to everyone who worked on improving it! 1. Introduction - "The format defined here follows some specific design goals that are not well met by current formats." <- "Follows" doesn't really work. Maybe "pursues"? "Satisfies"? - "It is important to note that this is not a proposal that the grammar in RFC 8259 be extended in general, since doing so would cause a significan= t backwards incompatibility with already deployed JSON documents." <- This= is probably not necessary anymore. It could be removed entirely or replaced with "This format is not an extension of the grammar in RFC 8259." 3.1. Major Types - In Table 1, can we spell out "Major Type" instead of "mt"? 3.4. Tagging of Items - I'm not sure what "while retaining its structure" accomplishes here. Can we remove it? - "That is, a tag is a data item consisting of a tag number and an enclosed value. The content of the tag (the enclosed data item) is the d= ata item (the value) that is being tagged." might be unnecessary. I think it= 's covered by the earlier text in this section. If it's still needed, it should probably move earlier to where we define tagged data. It doesn't = fit next to the discussion of what it means to put a tag inside a tag. - "it can just jump over the initial bytes of the tag (that encode the tag number)" isn't quite right: it's not just skipping it, it's reporting bo= th the tag number and value to the application. Maybe "Understanding the semantics of tags is optional for a decoder: it can present the tag numb= er and content to the application without interpreting the tag as a whole." 3.4.1. Date and Time - The next two sections seem like they should be subsections. 3.4.3. Epoch-based Date/Time - "An application that requires tag number 1 support may restrict" has a lowercase MAY, which has an ambiguous effect after RFC 8174. Do we want = MAY or can? 3.4.4. Bignums - This section has a forward reference to "preferred encoding", which should cite section 4.1. I note that 4.1 uses "preferred serialization" instead, so maybe we should switch this section to that term. - "and preferred encoding never makes use of bignums that also can be expressed as basic integers (see below)." <- This seems inconsistent wit= h "In the generic data model, bignum values are not equal to integers from the basic data model". If they're not the same value at the data model level, they can't be alternate encodings of each other. 3.4.5. Decimal Fractions and Bigfloats - "Decimal fractions (tag number 4) use base-10 exponents; the value of a decimal fraction data item is m*(10**e). Bigfloats (tag number 5) use base-2 exponents; the value of a bigfloat data item is m*(2**e)." is redundant with the first paragraph of the section. - This section also suggests that integers be used instead of integral bigdecimals and bigfloats. That only works if the specific data model sa= ys they're equivalent. Maybe we should say specific data models SHOULD make them equivalent and then SHOULD set the preferred encoding to the intege= r version? 3.4.6.2. Expected Later Encoding for CBOR-to-JSON Converters - This section only defines the tags obliquely and never says what tag 23 means. I suggest starting sentences with the tag number, e.g. "Tag numbe= r 21 means the contained byte string is expected to be encoded in base64ur= l without padding ... Tag number 22 means ..." 3.4.6.3. Encoded Text - "Tag numbers 33 and 34 are for base64url- and base64-encoded text strings" should maybe have "respectively"? 4.1. Preferred Serialization - "1_000_000_000" has enough digits that maybe we should use 10**9 (or 109 in v3) instead. 4.2. Deterministically Encoded CBOR - "Some protocols may want" has a lowercase "may". Consider "might". 4.2.1. Core Deterministic Encoding Requirements - This section says "Floating point values also MUST use the shortest form that preserves the value, e.g. 1.5 is encoded as 0xf93e00 and 1000000.5 = as 0xfa49742408.", but 4.2.2 says "If a protocol allows for IEEE floats, th= en additional deterministic encoding rules might need to be added." We shou= ld only put the float rule in one of these sections. 4.2.2. Additional Deterministic Encoding Considerations - "the deterministic format would not allow them" isn't clear what "them" is. Do we mean "would not allow the data to be tagged"? Or should we jus= t say that the deterministic format for the protocol needs to specify whet= her the tag is or is not present? - The "If a protocol includes a field that can express floating-point values" paragraph also assumes "=E2=80=A6 and the protocol's specific da= ta model declares integers and floating point values to be interchangeable". - The "A protocol might give encoders the choice of representing a URL ..." item feels like it's repeating the "CBOR tags present =E2=80=A6" pa= ragraph. Maybe we should move it to an example in that paragraph? - Maybe the ""Protocols that include floating, big integer, or other complex values need to define extra requirements on their deterministic encodings. For example:" introductory sentence belongs at the top of the whole section. 5. Creating CBOR-Based Protocols - "This section discusses" might read better as "The rest of this section" since it's after a bit of the section. 5.2. Generic Encoders and Decoders - "Even though CBOR attempts to minimize these cases, not all well-formed CBOR data is valid" is redundant with a lot of text from earlier in the document. - I wonder if this whole subsection is out of place. It reads like a definition of generic en/decoders rather than a consideration for design= ing protocols. Maybe it should be a subsection of "Terminology"? 5.3. Validity of Items - "The first layer that does process the semantics of an invalid CBOR item MUST take one of two choices:" covers our discussion of duplicate map ke= ys. Right now, our requirements aren't consistent with the requirements in t= his section, so we should make sure to incorporate this section when we reso= lve those. 5.3.2. Tag validity - "might present this tag to the application in a similar way to how it would present a tag with an unknown tag number" seems to suggest that it= 's wrong to replace the invalid tag with an error marker or to stop process= ing entirely, even though that's what 5.3 suggests. 5.5. Numbers - "the JavaScript number system treats all numbers as floating point" is no longer true: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global= _Objects/BigInt - "a compact application should accept" uses a lowercase "should" and would seem to discourage compact applications that check for a deterministic decoding. Do we mean that accepting wider encodings is lik= ely to make the application more compact? - "The preferred encoding for a floating-point value is the shortest floating-point encoding" is redundant with section 4.1, although it does include more detail. I *think* I'd rather put the whole definition of th= e preferred encoding in 4.1 instead of having some of it in protocol considerations. 5.6. Specifying Keys for Maps - "probably should be limited" -> "may need to be limited" or "the specification is probably simpler if"? To avoid BCP 14 terms. - We're already discussing the question of duplicate keys in another thread. - "except to specify that some, orders" has an extra comma. - "be enough reason on its own" -> "on their own" - The "should consider using small integers as keys" has the downside that it makes it harder for humans to understand the meaning of the data with= out the schema. "for constrained devices" might protect the rest of us from that downside, but would it make sense to say it explicitly? 5.6.1. Equivalence of Keys - This section might be shorter if it just says that map keys are duplicates if they have the same value in the generic data model or if t= he specific data model for the protocol (Section 2.2) says they're equivale= nt. The rest of the section just duplicates information that's already in Section 2. The note in the last paragraph does still seem useful. 8.1. Encoding Indicators - "Note that the encoding indicator "_" is thus an abbreviation of the full form "_7", which is not used." is confusing where it is. It might m= ake more sense if we swap its paragraph with the previous one and move it to after the definition of "[_ 1, 2]". - "As a special case, byte and text strings of indefinite length" doesn't seem like a special case to me. It's just the way you represent the encoding of an indefinite-length byte or text string. 9.2. Tags Registry - Did we decide not to tighten registration for the 256=E2=80=9365535 spac= e? 9.3. Media Type ("MIME Type") - Is there a reason this section switches to artwork in the middle? 9.4. CoAP Content-Format - Could this section link to https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#c= ontent-formats ? Appendix A. Examples - This starts with some references to Unicode code points, which could use the new tag. Appendix F. Changes from RFC 7049 - This looks quite incomplete. Jeffrey On Thu, Nov 14, 2019 at 6:41 PM Francesca Palombini wrote: > CBOR wg, > > > > This starts a four weeks WG last call on > https://tools.ietf.org/html/draft-ietf-cbor-7049bis-09 , ending on **Thur= sday, > 12 December**. > > Please send inputs to the mailing list that you have read the document an= d > do or do not feel it is ready to progress, along with any issues that you > believe need to be dealt with. > > > > We will discuss any open issues we=E2=80=99ve gotten at the f2f, Thursday= , 21 > November. > > > > CBOR Chairs > > Jim & Francesca > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > --0000000000002584e4059815e2d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Sorr= y I've been so lax with incremental reviews. Here's a complete set = of comments covering all of https:= //tools.ietf.org/html/draft-ietf-cbor-7049bis-09=C2=A0(although = I only skimmed the appendices). Overall, this is way better= than RFC 7049. Thanks to everyone who worked on improving it!


1.=C2=A0 Introduction

  • "The format defined here follows som= e specific design goals that are not well met by current formats." <= ;- "Follows" doesn't really work. Maybe "pursues"? = "Satisfies"?

  • "It is important to note = that this is not a proposal that the grammar in RFC 8259 be extended in gen= eral, since doing so would cause a significant backwards incompatibility wi= th already deployed JSON documents." <- This is probably not necess= ary anymore. It could be removed entirely or replaced with "This forma= t is not an extension of the grammar in RFC 8259."


=

3.1.=C2=A0 Major Types=

  • In Table 1,= can we spell out "Major Type" instead of "mt"?<= /span>


3.4.=C2=A0= Tagging of Items

  • I'm not sure what "while retaining its structure" accom= plishes here. Can we remove it?

  • "That is, a tag i= s a data item consisting of a tag number and an enclosed value. The content= of the tag (the enclosed data item) is the data item (the value) that is b= eing tagged." might be unnecessary. I think it's covered by the ea= rlier text in this section. If it's still needed, it should probably mo= ve earlier to where we define tagged data. It doesn't fit next to the d= iscussion of what it means to put a tag inside a tag.

  • = "it can just jump over the initial bytes of the tag (that encode the t= ag number)" isn't quite right: it's not just skipping it, it&#= 39;s reporting both the tag number and value to the application. Maybe &quo= t;Understanding the semantics of tags is optional for a decoder: it can pre= sent the tag number and content to the application without interpreting the= tag as a whole."


3.4.1.=C2=A0 Date and Time

  • The next two sections seem like they s= hould be subsections.


3.4.3.=C2=A0 Epoch-based Date/Time

  • "An application that require= s tag number 1 support may restrict" has a lowercase MAY, which has an= ambiguous effect after RFC 8174. Do we want MAY or can?

    <= /li>


3.4.4.=C2=A0 Bignums<= /font>

  • This section= has a forward reference to "preferred encoding", which should ci= te section 4.1. I note that 4.1 uses "preferred serialization" in= stead, so maybe we should switch this section to that term.

  • "and preferred encoding never makes use of bignums that also can= be expressed as basic integers (see below)." <- This seems inconsi= stent with "In the generic data model, bignum values are not equal to = integers from the basic data model". If they're not the same value= at the data model level, they can't be alternate encodings of each oth= er.


3.4.5.=C2=A0 Decimal Fractions and Bigfloats

  • "Decimal fractions (tag number 4) us= e base-10 exponents; the value of a decimal fraction data item is m*(10**e)= . Bigfloats (tag number 5) use base-2 exponents; the value of a bigfloat da= ta item is m*(2**e)." is redundant with the first paragraph of the sec= tion.

  • This section also suggests that integers be used= instead of integral bigdecimals and bigfloats. That only works if the spec= ific data model says they're equivalent. Maybe we should say specific d= ata models SHOULD make them equivalent and then SHOULD set the preferred en= coding to the integer version?

<= font face=3D"arial, sans-serif">

3.4.6.2.=C2=A0 Expected Later Encoding for CBO= R-to-JSON Converters

  • This section only defines the tags obliquely and never says what t= ag 23 means. I suggest starting sentences with the tag number, e.g. "T= ag number 21 means the contained byte string is expected to be encoded in b= ase64url without padding ... Tag number 22 means ..."


3.4.6.3.=C2=A0 Enco= ded Text

    &qu= ot;Tag numbers 33 and 34 are for base64url- and base64-encoded text strings= " should maybe have "respectively"?


    <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:5pt"><= span style=3D"color:rgb(0,0,0);background-color:transparent;font-variant-nu= meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-s= pace:pre-wrap">4.1.=C2=A0 Preferred Serial= ization

      &quo= t;1_000_000_000" has enough digits that maybe we should use 10**9 (or = 10<sup>9</sup> in v3) instead.


    4.2.=C2=A0 Deterministically Encoded CBOR

    • "Some protocols= may want" has a lowercase "may". Consider "might"= .


    4= .2.1.=C2=A0 Core Deterministic Encoding Requirements

    • This section says "Floating p= oint values also MUST use the shortest form that preserves the value, e.g. = 1.5 is encoded as 0xf93e00 and 1000000.5 as 0xfa49742408.", but 4.2.2 = says "If a protocol allows for IEEE floats, then additional determinis= tic encoding rules might need to be added." We should only put the flo= at rule in one of these sections.


    4.2.2.=C2=A0 Additional Deterministic Encodi= ng Considerations

    • "the deterministic format would not allow them" isn't c= lear what "them" is. Do we mean "would not allow the data to= be tagged"? Or should we just say that the deterministic format for t= he protocol needs to specify whether the tag is or is not present?

    • The "If a protocol includes a field that can express floa= ting-point values" paragraph also assumes "=E2=80=A6 and the prot= ocol's specific data model declares integers and floating point values = to be interchangeable".

    • The "A protocol migh= t give encoders the choice of representing a URL ..." item feels like = it's repeating the "CBOR tags present =E2=80=A6" paragraph. M= aybe we should move it to an example in that paragraph?


    • 5.=C2=A0 Creating CBOR-Based Protocols

    • "This section discusses&quo= t; might read better as "The rest of this section" since it's= after a bit of the section.


    5.2.=C2=A0 Generic Encoders and Decoders

    • "Even though CB= OR attempts to minimize these cases, not all well-formed CBOR data is valid= " is redundant with a lot of text from earlier in the document.=

    • I wonder if this whole subsection is out of place. It reads = like a definition of generic en/decoders rather than a consideration for de= signing protocols. Maybe it should be a subsection of "Terminology&quo= t;?


    5.3.=C2=A0 Validity of Items

    • "The first layer that does process the semantics of = an invalid CBOR item MUST take one of two choices:" covers our discuss= ion of duplicate map keys. Right now, our requirements aren't consisten= t with the requirements in this section, so we should make sure to incorpor= ate this section when we resolve those.


    5.3.2.=C2=A0 Tag validity

    • "might present th= is tag to the application in a similar way to how it would present a tag wi= th an unknown tag number" seems to suggest that it's wrong to repl= ace the invalid tag with an error marker or to stop processing entirely, ev= en though that's what 5.3 suggests.


    5.5.=C2=A0 Numbers

    =

    • "the JavaScript number s= ystem treats all numbers as floating point" is no longer true: = https://developer.mozilla.org/en-US/docs/Web/JavaScript/Ref= erence/Global_Objects/BigInt

    • "a compact appli= cation should accept" uses a lowercase "should" and would se= em to discourage compact applications that check for a deterministic decodi= ng. Do we mean that accepting wider encodings is likely to make the applica= tion more compact?

    • "The preferred encoding for a = floating-point value is the shortest floating-point encoding" is redun= dant with section 4.1, although it does include more detail. I *think* I= 9;d rather put the whole definition of the preferred encoding in 4.1 instea= d of having some of it in protocol considerations.


      • <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:5pt"><= span style=3D"color:rgb(0,0,0);background-color:transparent;font-variant-nu= meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-s= pace:pre-wrap">5.6.=C2=A0 Specifying Keys = for Maps

        &qu= ot;probably should be limited" -> "may need to be limited"= ; or "the specification is probably simpler if"? To avoid BCP 14 = terms.=C2=A0

      • We're already discussing the question= of duplicate keys in another thread.

      • "except to = specify that some, orders" has an extra comma.

        • <= li dir=3D"ltr" style=3D"list-style-type:disc;color:rgb(0,0,0);background-co= lor:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;= vertical-align:baseline;white-space:pre">

        &q= uot;be enough reason on its own" -> "on their own"=

      • The "should consider using small integers as keys"= has the downside that it makes it harder for humans to understand the mean= ing of the data without the schema. "for constrained devices" mig= ht protect the rest of us from that downside, but would it make sense to sa= y it explicitly?


      5.6.1.=C2=A0 Equivalence of Keys

      • This section might be shorter if it ju= st says that map keys are duplicates if they have the same value in the gen= eric data model or if the specific data model for the protocol (Section 2.2= ) says they're equivalent. The rest of the section just duplicates info= rmation that's already in Section 2. The note in the last paragraph doe= s still seem useful.


      8.1.=C2=A0 Encoding Indicators

      • "Note that the encoding indicato= r "_" is thus an abbreviation of the full form "_7", wh= ich is not used." is confusing where it is. It might make more sense i= f we swap its paragraph with the previous one and move it to after the defi= nition of "[_ 1, 2]".

      • "As a special cas= e, byte and text strings of indefinite length" doesn't seem like a= special case to me. It's just the way you represent the encoding of an= indefinite-length byte or text string.


      9.2.=C2=A0 Tags Registry

      • Did we decide not to t= ighten registration for the 256=E2=80=9365535 space?

        • =


      9.3.=C2=A0 Media Type (&q= uot;MIME Type")

      • Is there a reason this section switches to artwork in the middle?<= /font>


      9.4= .=C2=A0 CoAP Content-Format


      Appendix A.=C2=A0 Examples

      • This starts with some references to Unicode code = points, which could use the new <u> tag.

      <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:5pt"><= span style=3D"color:rgb(0,0,0);background-color:transparent;font-variant-nu= meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-s= pace:pre-wrap">

      Appendix F.=C2=A0 Changes from = RFC 7049

        Thi= s looks quite incomplete.



      Jeffrey

On Thu, Nov 14, 2019 at 6:41 PM Fra= ncesca Palombini <francesca.palombini=3D40ericsson.com@dmarc.ietf.org> wr= ote:

CBOR wg,

=C2=A0<= /span>

This starts a four we= eks WG last call on https://tools.ietf.org/html/draft-ietf-cbor-7049bis-09 , en= ding on *Thursday, 12 December*.

Please send inputs to= the mailing list that you have read the document and do or do not feel it = is ready to progress, along with any issues that you believe need to be dea= lt with.

=C2=A0<= /span>

We will discuss any o= pen issues we=E2=80=99ve gotten at the f2f, Thursday, 21 November.

=C2=A0<= /span>

CBOR Chairs=

Jim & Francesca

_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
--0000000000002584e4059815e2d6-- From nobody Sun Nov 24 10:21:48 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 DE07A120041 for ; Sun, 24 Nov 2019 10:21:47 -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 WuXIQtwiCYEB for ; Sun, 24 Nov 2019 10:21:46 -0800 (PST) Received: from p3plsmtpa12-05.prod.phx3.secureserver.net (p3plsmtpa12-05.prod.phx3.secureserver.net [68.178.252.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C2912001E for ; Sun, 24 Nov 2019 10:21:46 -0800 (PST) Received: from [10.86.0.10] ([45.56.150.43]) by :SMTPAUTH: with ESMTPA id YwW0ip5gmABThYwW1iWPkT; Sun, 24 Nov 2019 11:21:45 -0700 From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6BF7025F-D4BF-44DE-8BC8-110F861176B0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 24 Nov 2019 10:21:44 -0800 In-Reply-To: Cc: Jeffrey Yasskin , cbor@ietf.org To: Jeffrey Yasskin References: X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfDK7nkFfGkVLlDySW6bP1tGG17TCYagFVzJbDMjPNcOoMV0RnXxDOCu2jgpIurBzgWxcDiAqrpeCfJNm3dnBYsSww9VPpFFsTHH0g4mzvoTmLvEEJAyE dqyfjL08sVJAoi4zwYR5waFZSeS6mjbzMKhzfvsO/IwkyJogOwFon7+nEkRVU2Ppz1jtDBMf9P2nfqR7fKxQvSzODhj1z5ZwtvtnMB8Bz6jW4IOTvxklRlu/ q0uFlUKcuJo7EcbiTKVyZw== 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: Sun, 24 Nov 2019 18:21:48 -0000 --Apple-Mail=_6BF7025F-D4BF-44DE-8BC8-110F861176B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 24, 2019, at 2:48 AM, Jeffrey Yasskin = wrote: >=20 >> I think you make a good point that if a protocol is going to specify = "take first", it can probably specify "error on duplicate key" for the = same cost. That might imply some much simpler text: >>=20 >> "Protocols based on CBOR SHOULD fail with an error if a map contains = a duplicate key, except that if the key isn't used at all, they MAY = ignore it instead. Protocols that do not reject duplicate keys MUST (?) = document why the cost of rejecting duplicates is too high and why = accepting them will not lead to security vulnerabilities. An array might = be a better choice for such protocols.=E2=80=9D >=20 > I think I=E2=80=99d invert it and say that protocols that require = duplicate detection for security reasons should describe that = requirement in security considerations so the implementor gets a good = solid hint that they need to worry about it. >=20 > There's an interesting difference of approach here. It's plausible to = say that protocol designers should pick the secure design only when they = realize their design has security implications, but I prefer to say that = they should pick the secure design unless they think about it and = realize the design doesn't have security implications. I think the = second will get us noticeably more security in a world where designers = don't have time to think about every aspect of every piece of their = design. I don=E2=80=99t know how many generic decoders exist that really can=E2=80= =99t do or support duplicate detection. I also don=E2=80=99t know how = many use cases there are that can=E2=80=99t afford duplicate detection. = If there are few of both, then making no duplicate detection the = exception that needs to be called out seems right. I have been thinking about CWT and EAT as examples. Maybe EAT should say = that duplicate detection should be required unless a profile of EAT says = it is not, the secure choice. For the most part EAT will be processed on = servers where there is clearly no resource issue. The only issue would = be the implementation environment (Java, PHP, Python=E2=80=A6). EATs might be decoded on constrained devices sometimes, but that is = rare. In that case a profile can relax the requirement. EATs are always signed so duplicates would only come from bad = implementations. There are plenty of ways that am implementation can go = wrong other than duplicating keys that are completely undetectable. >=20 > There is lot of text implying that duplicates are bad, but I think it = would be worth being explicit. >=20 > You are an idiot if you design a protocol that considers duplicate = input valid or necessary. Duplicate map keys are always an error in CBOR = and will not work with many generic decoders. > =20 > I wouldn't say "idiot", just "wrong". The spec already says you "MUST = NOT" do this, but I'm not opposed to making that statement more direct. Pardon my wording. Certainly, I do not want that as normative text. >=20 > Thanks, > Jeffrey --Apple-Mail=_6BF7025F-D4BF-44DE-8BC8-110F861176B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 24, 2019, at 2:48 AM, Jeffrey Yasskin <jyasskin@chromium.org> wrote:

I = think you make a good point that if a protocol is going to specify "take = first", it can probably specify "error on duplicate key" for the same = cost. That might imply some much simpler text:

"Protocols based on CBOR SHOULD fail = with an error if a map contains a duplicate key, except that if the key = isn't used at all, they MAY ignore it instead. Protocols that do not = reject duplicate keys MUST (?) document why the cost of rejecting = duplicates is too high and why accepting them will not lead to security = vulnerabilities. An array might be a better choice for such = protocols.=E2=80=9D

I think I=E2=80=99d = invert it and say that protocols that require duplicate detection for = security reasons should describe that requirement in security = considerations so the implementor gets a good solid hint that they need = to worry about it.

There's an interesting difference of = approach here. It's plausible to say that protocol designers should pick = the secure design only when they realize their design has security = implications, but I prefer to say that they should pick the secure = design unless they think about it and realize the design doesn't have = security implications. I think the second will get us noticeably more = security in a world where designers don't have time to think about every = aspect of every piece of their = design.

I don=E2=80=99t know how many generic decoders = exist that really can=E2=80=99t do or support duplicate detection. I = also don=E2=80=99t know how many use cases there are that can=E2=80=99t = afford duplicate detection. If there are few of both, then making no = duplicate detection the exception that needs to be called out seems = right.

I have been thinking about = CWT and EAT as examples. Maybe EAT should say that duplicate detection = should be required unless a profile of EAT says it is not, the secure = choice. For the most part EAT will be processed on servers where there = is clearly no resource issue. The only issue would be the implementation =  environment (Java, PHP, Python=E2=80=A6).

EATs might be decoded on constrained devices = sometimes, but that is rare. In that case a profile can relax the = requirement.

EATs are always signed = so duplicates would only come from bad implementations. There are plenty = of ways that am implementation can go wrong other than duplicating keys = that are completely undetectable.


There is lot of text implying that duplicates are bad, but I = think it would be worth being explicit.

You are an idiot if you design a protocol that considers = duplicate input valid or necessary. Duplicate map keys are always an = error in CBOR and will not work with many generic = decoders.
 
I wouldn't say "idiot", just = "wrong". The spec already says you "MUST NOT" do this, but I'm not = opposed to making that statement more direct.

Pardon my wording. Certainly, I do not want that = as normative text.


Thanks,
Jeffrey

= --Apple-Mail=_6BF7025F-D4BF-44DE-8BC8-110F861176B0-- From nobody Sun Nov 24 14:11: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 E77D11200C4 for ; Sun, 24 Nov 2019 14:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-sXLnlLRvs5 for ; Sun, 24 Nov 2019 14:10:59 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650117.outbound.protection.outlook.com [40.107.65.117]) (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 9F80712003E for ; Sun, 24 Nov 2019 14:10:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kDnYUhZP70Wbg+mlaYyOc3zDqjoNTffiqBkL6bHRCvzbIxEodeL8T24cwQUR2ALbjWrHhRvqDVW1UNtPUyJFX9Yv/xCSk0/Jm2O6WkYeXzPr37NuivmdXCk/J0OQ6irejNM+GtdwSRJiXfi0/sPPyZVkClmcl5EATLMkQuNIO7Z4cUXiP7pWWMwPtST9MrEoM3ds61hMezPsV0XXZvYE4fDj9GT423ZHIha611JWar8TvZQJuysd7UibjUEYwmT9Px7I4Ab/Ah3ij2lj9BmQyC8DpNQhHC2e3UaGqt3J1meOjuUdwT+XmUCa6NZuOoY9IjXaToFBlaMq3NBaowipUw== 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=ha9IWPuJjFb4TxLJNUW3Mf4Rakx/WLgdJ5NMc+UKl4Q=; b=SKx4aO+tkfB/eAiIzWoUN6y1DQ4boTKfBsDaFoD30Eu2IsHe6xa62Jd+y/l/uMN9/ojCnXvf/8/2+RWTW3mujnGUVlJkqqQgWclTPiXf7EMdqnZrGEN1T0bWMwoyB9Oazv/TusXSzH7hNwfuLASTM9H32cCa4tGmzm2JWRbCbSRYkAXHijj+GzfIuR0ytfbwDNjdQorchdB0UvatKGXLKxGeuh5jC35UTAJl43o30fMnYUpQpunvRO5bjbYAkR5hBYpdDsTLdTjD6Q1qzOZLdyJsXtH/VYMeEyDje4X5oSy35uB4KIBCdrx+j7K+EDDwRBKiCdr/16qh3BzlsU1XlA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ha9IWPuJjFb4TxLJNUW3Mf4Rakx/WLgdJ5NMc+UKl4Q=; b=Uvxl5FnEdJrfyOFPZq1WdFUae+akzLFov4LsRK9xtNdVsFh+EW9VkDIAbThv3GRTiICeA36hJ/q4vz9hTNztvWVrlJeStpueUYt8VUZ4pmDv6IOAu0Qp1PZwSqBCbt9n3YjcjSAp7ecTbhtd4kxO6J1Ngm7g7PkOnIVAUXAWqwA= Received: from DM6PR00MB0569.namprd00.prod.outlook.com (20.179.51.12) by DM6PR00MB0845.namprd00.prod.outlook.com (20.179.167.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2525.0; Sun, 24 Nov 2019 22:10:57 +0000 Received: from DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::2cfe:cf2c:2101:86be]) by DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::2cfe:cf2c:2101:86be%9]) with mapi id 15.20.2526.000; Sun, 24 Nov 2019 22:10:57 +0000 From: Mike Jones To: Laurence Lundblade , Jeffrey Yasskin CC: Jeffrey Yasskin , "cbor@ietf.org" Thread-Topic: [EXTERNAL] Re: [Cbor] Handling duplicate map keys Thread-Index: AQHVoGqK3tfbfd3j3UaGZbBcN3tqC6eYAo4AgAB4jwCAAGeBgIABRhYAgAB+gwCAAD+nYA== Date: Sun, 24 Nov 2019 22:10:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=dabd4818-01b3-4b86-86ca-000086860efd; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-11-24T22:09:33Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.93.218] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4d39a00f-8ea1-4a35-64cb-08d7712b2ea1 x-ms-traffictypediagnostic: DM6PR00MB0845: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:626; x-forefront-prvs: 02318D10FB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(346002)(376002)(39860400002)(136003)(199004)(189003)(54906003)(25786009)(110136005)(71200400001)(71190400001)(53546011)(6506007)(7696005)(76176011)(186003)(55016002)(6306002)(54896002)(102836004)(236005)(26005)(316002)(6436002)(3846002)(66066001)(229853002)(9686003)(66446008)(33656002)(14454004)(8936002)(66946007)(478600001)(10290500003)(6116002)(790700001)(22452003)(5660300002)(256004)(7736002)(4326008)(2906002)(8676002)(52536014)(66476007)(99286004)(66556008)(81166006)(81156014)(64756008)(74316002)(10090500001)(446003)(6246003)(8990500004)(86362001)(76116006)(14444005)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0845; H:DM6PR00MB0569.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yIUxBJss6rTyjLjAxAtKCkxHIU8mBDxKdoGy7qaHwwW+pmgNrVnmnmSIFQAI6NVmeiaFW2QzpMU2uNPg+n587vqKnqXdqYJzf1zDbJ4AV/+nOV0lLaiaFD1mZpLgVAG8ejASEjV8T2XUTCgLTXb+oENvnrAfwYPdv2gYY5HWdeBpzvbCqLSkKT60ScmUv/RKKHoCtKAgsrU2f3miaRiSZuv4OEI2shSp3h9kcxOoqQlFF+xbUNiwQrhOpfUUZKWpwE6fzGHcEf5UhywJpV5wOyEGpU9x/bU1Iuu54yiWMmQhkNpzXZehabVGgIyhJC8vFenO4nAjHZds2CZqRmRDyaDP5GJEhLLpHoT5tKNxSDWxz1CgizphXomJUx5SsUZE7IsmGz/uTanObcB4EfwbC54a7qt/9pW8KjFd7cHx35aXyvAjFb9hjNvcNtTirL/b x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0569D44CC35DD2AFEA56C621F54B0DM6PR00MB0569namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4d39a00f-8ea1-4a35-64cb-08d7712b2ea1 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2019 22:10:57.5396 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6sQF0xxmwxQlfMVedreHWoIIcPeNBqNxt7ahnjRCvOjcsXtuLVlnExgMs5iLgclYIqmsThH7wmfkiVR0j6akaw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0845 Archived-At: Subject: Re: [Cbor] [EXTERNAL] Re: 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: Sun, 24 Nov 2019 22:11:03 -0000 --_000_DM6PR00MB0569D44CC35DD2AFEA56C621F54B0DM6PR00MB0569namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZHZvY2F0ZSB3b3JkaW5nIHRoYXQgc2F5cyB5b3UgTVVTVCBOT1QgY3JlYXRlIHByb3RvY29s cyBvciBzcGVjaWZpY2F0aW9ucyB0aGF0IGNvdW50IG9uIGFueSBiZWhhdmlvciBmb3IgZHVwbGlj YXRlIG1hcCBrZXlzIG90aGVyIHRoYW4gcmVqZWN0aW5nIHRoZSBpbnB1dC4gIEFueXRoaW5nIGVs c2Ugb3BlbnMgdXAgYSBQYW5kb3Jh4oCZcyBCb3ggb2Ygbm9uLWludGVyb3BlcmFiaWxpdHkuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LSBNaWtlDQoNCkZyb206IENCT1IgPGNib3ItYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9m IExhdXJlbmNlIEx1bmRibGFkZQ0KU2VudDogU3VuZGF5LCBOb3ZlbWJlciAyNCwgMjAxOSAxMDoy MiBBTQ0KVG86IEplZmZyZXkgWWFzc2tpbiA8anlhc3NraW5AY2hyb21pdW0ub3JnPg0KQ2M6IEpl ZmZyZXkgWWFzc2tpbiA8anlhc3NraW49NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPjsgY2Jv ckBpZXRmLm9yZw0KU3ViamVjdDogW0VYVEVSTkFMXSBSZTogW0Nib3JdIEhhbmRsaW5nIGR1cGxp Y2F0ZSBtYXAga2V5cw0KDQoNCg0KDQpPbiBOb3YgMjQsIDIwMTksIGF0IDI6NDggQU0sIEplZmZy ZXkgWWFzc2tpbiA8anlhc3NraW5AY2hyb21pdW0ub3JnPG1haWx0bzpqeWFzc2tpbkBjaHJvbWl1 bS5vcmc+PiB3cm90ZToNCg0KSSB0aGluayB5b3UgbWFrZSBhIGdvb2QgcG9pbnQgdGhhdCBpZiBh IHByb3RvY29sIGlzIGdvaW5nIHRvIHNwZWNpZnkgInRha2UgZmlyc3QiLCBpdCBjYW4gcHJvYmFi bHkgc3BlY2lmeSAiZXJyb3Igb24gZHVwbGljYXRlIGtleSIgZm9yIHRoZSBzYW1lIGNvc3QuIFRo YXQgbWlnaHQgaW1wbHkgc29tZSBtdWNoIHNpbXBsZXIgdGV4dDoNCg0KIlByb3RvY29scyBiYXNl ZCBvbiBDQk9SIFNIT1VMRCBmYWlsIHdpdGggYW4gZXJyb3IgaWYgYSBtYXAgY29udGFpbnMgYSBk dXBsaWNhdGUga2V5LCBleGNlcHQgdGhhdCBpZiB0aGUga2V5IGlzbid0IHVzZWQgYXQgYWxsLCB0 aGV5IE1BWSBpZ25vcmUgaXQgaW5zdGVhZC4gUHJvdG9jb2xzIHRoYXQgZG8gbm90IHJlamVjdCBk dXBsaWNhdGUga2V5cyBNVVNUICg/KSBkb2N1bWVudCB3aHkgdGhlIGNvc3Qgb2YgcmVqZWN0aW5n IGR1cGxpY2F0ZXMgaXMgdG9vIGhpZ2ggYW5kIHdoeSBhY2NlcHRpbmcgdGhlbSB3aWxsIG5vdCBs ZWFkIHRvIHNlY3VyaXR5IHZ1bG5lcmFiaWxpdGllcy4gQW4gYXJyYXkgbWlnaHQgYmUgYSBiZXR0 ZXIgY2hvaWNlIGZvciBzdWNoIHByb3RvY29scy7igJ0NCg0KSSB0aGluayBJ4oCZZCBpbnZlcnQg aXQgYW5kIHNheSB0aGF0IHByb3RvY29scyB0aGF0IHJlcXVpcmUgZHVwbGljYXRlIGRldGVjdGlv biBmb3Igc2VjdXJpdHkgcmVhc29ucyBzaG91bGQgZGVzY3JpYmUgdGhhdCByZXF1aXJlbWVudCBp biBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzbyB0aGUgaW1wbGVtZW50b3IgZ2V0cyBhIGdvb2Qg c29saWQgaGludCB0aGF0IHRoZXkgbmVlZCB0byB3b3JyeSBhYm91dCBpdC4NCg0KVGhlcmUncyBh biBpbnRlcmVzdGluZyBkaWZmZXJlbmNlIG9mIGFwcHJvYWNoIGhlcmUuIEl0J3MgcGxhdXNpYmxl IHRvIHNheSB0aGF0IHByb3RvY29sIGRlc2lnbmVycyBzaG91bGQgcGljayB0aGUgc2VjdXJlIGRl c2lnbiBvbmx5IHdoZW4gdGhleSByZWFsaXplIHRoZWlyIGRlc2lnbiBoYXMgc2VjdXJpdHkgaW1w bGljYXRpb25zLCBidXQgSSBwcmVmZXIgdG8gc2F5IHRoYXQgdGhleSBzaG91bGQgcGljayB0aGUg c2VjdXJlIGRlc2lnbiB1bmxlc3MgdGhleSB0aGluayBhYm91dCBpdCBhbmQgcmVhbGl6ZSB0aGUg ZGVzaWduIGRvZXNuJ3QgaGF2ZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMuIEkgdGhpbmsgdGhlIHNl Y29uZCB3aWxsIGdldCB1cyBub3RpY2VhYmx5IG1vcmUgc2VjdXJpdHkgaW4gYSB3b3JsZCB3aGVy ZSBkZXNpZ25lcnMgZG9uJ3QgaGF2ZSB0aW1lIHRvIHRoaW5rIGFib3V0IGV2ZXJ5IGFzcGVjdCBv ZiBldmVyeSBwaWVjZSBvZiB0aGVpciBkZXNpZ24uDQoNCkkgZG9u4oCZdCBrbm93IGhvdyBtYW55 IGdlbmVyaWMgZGVjb2RlcnMgZXhpc3QgdGhhdCByZWFsbHkgY2Fu4oCZdCBkbyBvciBzdXBwb3J0 IGR1cGxpY2F0ZSBkZXRlY3Rpb24uIEkgYWxzbyBkb27igJl0IGtub3cgaG93IG1hbnkgdXNlIGNh c2VzIHRoZXJlIGFyZSB0aGF0IGNhbuKAmXQgYWZmb3JkIGR1cGxpY2F0ZSBkZXRlY3Rpb24uIElm IHRoZXJlIGFyZSBmZXcgb2YgYm90aCwgdGhlbiBtYWtpbmcgbm8gZHVwbGljYXRlIGRldGVjdGlv biB0aGUgZXhjZXB0aW9uIHRoYXQgbmVlZHMgdG8gYmUgY2FsbGVkIG91dCBzZWVtcyByaWdodC4N Cg0KSSBoYXZlIGJlZW4gdGhpbmtpbmcgYWJvdXQgQ1dUIGFuZCBFQVQgYXMgZXhhbXBsZXMuIE1h eWJlIEVBVCBzaG91bGQgc2F5IHRoYXQgZHVwbGljYXRlIGRldGVjdGlvbiBzaG91bGQgYmUgcmVx dWlyZWQgdW5sZXNzIGEgcHJvZmlsZSBvZiBFQVQgc2F5cyBpdCBpcyBub3QsIHRoZSBzZWN1cmUg Y2hvaWNlLiBGb3IgdGhlIG1vc3QgcGFydCBFQVQgd2lsbCBiZSBwcm9jZXNzZWQgb24gc2VydmVy cyB3aGVyZSB0aGVyZSBpcyBjbGVhcmx5IG5vIHJlc291cmNlIGlzc3VlLiBUaGUgb25seSBpc3N1 ZSB3b3VsZCBiZSB0aGUgaW1wbGVtZW50YXRpb24gIGVudmlyb25tZW50IChKYXZhLCBQSFAsIFB5 dGhvbuKApikuDQoNCkVBVHMgbWlnaHQgYmUgZGVjb2RlZCBvbiBjb25zdHJhaW5lZCBkZXZpY2Vz IHNvbWV0aW1lcywgYnV0IHRoYXQgaXMgcmFyZS4gSW4gdGhhdCBjYXNlIGEgcHJvZmlsZSBjYW4g cmVsYXggdGhlIHJlcXVpcmVtZW50Lg0KDQpFQVRzIGFyZSBhbHdheXMgc2lnbmVkIHNvIGR1cGxp Y2F0ZXMgd291bGQgb25seSBjb21lIGZyb20gYmFkIGltcGxlbWVudGF0aW9ucy4gVGhlcmUgYXJl IHBsZW50eSBvZiB3YXlzIHRoYXQgYW0gaW1wbGVtZW50YXRpb24gY2FuIGdvIHdyb25nIG90aGVy IHRoYW4gZHVwbGljYXRpbmcga2V5cyB0aGF0IGFyZSBjb21wbGV0ZWx5IHVuZGV0ZWN0YWJsZS4N Cg0KDQoNClRoZXJlIGlzIGxvdCBvZiB0ZXh0IGltcGx5aW5nIHRoYXQgZHVwbGljYXRlcyBhcmUg YmFkLCBidXQgSSB0aGluayBpdCB3b3VsZCBiZSB3b3J0aCBiZWluZyBleHBsaWNpdC4NCg0KWW91 IGFyZSBhbiBpZGlvdCBpZiB5b3UgZGVzaWduIGEgcHJvdG9jb2wgdGhhdCBjb25zaWRlcnMgZHVw bGljYXRlIGlucHV0IHZhbGlkIG9yIG5lY2Vzc2FyeS4gRHVwbGljYXRlIG1hcCBrZXlzIGFyZSBh bHdheXMgYW4gZXJyb3IgaW4gQ0JPUiBhbmQgd2lsbCBub3Qgd29yayB3aXRoIG1hbnkgZ2VuZXJp YyBkZWNvZGVycy4NCg0KSSB3b3VsZG4ndCBzYXkgImlkaW90IiwganVzdCAid3JvbmciLiBUaGUg c3BlYyBhbHJlYWR5IHNheXMgeW91ICJNVVNUIE5PVCIgZG8gdGhpcywgYnV0IEknbSBub3Qgb3Bw b3NlZCB0byBtYWtpbmcgdGhhdCBzdGF0ZW1lbnQgbW9yZSBkaXJlY3QuDQoNClBhcmRvbiBteSB3 b3JkaW5nLiBDZXJ0YWlubHksIEkgZG8gbm90IHdhbnQgdGhhdCBhcyBub3JtYXRpdmUgdGV4dC4N Cg0KDQoNClRoYW5rcywNCkplZmZyZXkNCg0K --_000_DM6PR00MB0569D44CC35DD2AFEA56C621F54B0DM6PR00MB0569namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPkkgYWR2b2NhdGUgd29yZGluZyB0aGF0IHNheXMgeW91IE1VU1QgTk9UIGNy ZWF0ZSBwcm90b2NvbHMgb3Igc3BlY2lmaWNhdGlvbnMgdGhhdCBjb3VudCBvbiBhbnkgYmVoYXZp b3IgZm9yIGR1cGxpY2F0ZSBtYXAga2V5cyBvdGhlciB0aGFuIHJlamVjdGluZyB0aGUgaW5wdXQu Jm5ic3A7IEFueXRoaW5nIGVsc2Ugb3BlbnMgdXAgYSBQYW5kb3Jh4oCZcyBCb3ggb2Ygbm9uLWlu dGVyb3BlcmFiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IENCT1IgJmx0O2Nib3It Ym91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkxhdXJlbmNlIEx1bmRi bGFkZTxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE5vdmVtYmVyIDI0LCAyMDE5IDEwOjIyIEFN PGJyPg0KPGI+VG86PC9iPiBKZWZmcmV5IFlhc3NraW4gJmx0O2p5YXNza2luQGNocm9taXVtLm9y ZyZndDs8YnI+DQo8Yj5DYzo8L2I+IEplZmZyZXkgWWFzc2tpbiAmbHQ7anlhc3NraW49NDBnb29n bGUuY29tQGRtYXJjLmlldGYub3JnJmd0OzsgY2JvckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBbRVhURVJOQUxdIFJlOiBbQ2Jvcl0gSGFuZGxpbmcgZHVwbGljYXRlIG1hcCBrZXlzPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiAyNCwgMjAxOSwgYXQgMjo0 OCBBTSwgSmVmZnJleSBZYXNza2luICZsdDs8YSBocmVmPSJtYWlsdG86anlhc3NraW5AY2hyb21p dW0ub3JnIj5qeWFzc2tpbkBjaHJvbWl1bS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHlvdSBtYWtlIGEgZ29vZCBw b2ludCB0aGF0IGlmIGEgcHJvdG9jb2wgaXMgZ29pbmcgdG8gc3BlY2lmeSAmcXVvdDt0YWtlIGZp cnN0JnF1b3Q7LCBpdCBjYW4gcHJvYmFibHkgc3BlY2lmeSAmcXVvdDtlcnJvciBvbiBkdXBsaWNh dGUga2V5JnF1b3Q7IGZvciB0aGUgc2FtZSBjb3N0LiBUaGF0IG1pZ2h0IGltcGx5IHNvbWUgbXVj aCBzaW1wbGVyIHRleHQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtQcm90b2NvbHMgYmFzZWQg b24gQ0JPUiBTSE9VTEQgZmFpbCB3aXRoIGFuIGVycm9yIGlmIGEgbWFwIGNvbnRhaW5zIGEgZHVw bGljYXRlIGtleSwgZXhjZXB0IHRoYXQgaWYgdGhlIGtleSBpc24ndCB1c2VkIGF0IGFsbCwgdGhl eSBNQVkgaWdub3JlIGl0IGluc3RlYWQuIFByb3RvY29scyB0aGF0IGRvIG5vdCByZWplY3QgZHVw bGljYXRlIGtleXMgTVVTVCAoPykgZG9jdW1lbnQgd2h5IHRoZSBjb3N0IG9mIHJlamVjdGluZw0K IGR1cGxpY2F0ZXMgaXMgdG9vIGhpZ2ggYW5kIHdoeSBhY2NlcHRpbmcgdGhlbSB3aWxsIG5vdCBs ZWFkIHRvIHNlY3VyaXR5IHZ1bG5lcmFiaWxpdGllcy4gQW4gYXJyYXkgbWlnaHQgYmUgYSBiZXR0 ZXIgY2hvaWNlIGZvciBzdWNoIHByb3RvY29scy7igJ08bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIEnigJlkIGludmVydCBpdCBhbmQgc2F5 IHRoYXQgcHJvdG9jb2xzIHRoYXQgcmVxdWlyZSBkdXBsaWNhdGUgZGV0ZWN0aW9uIGZvciBzZWN1 cml0eSByZWFzb25zIHNob3VsZCBkZXNjcmliZSB0aGF0IHJlcXVpcmVtZW50IGluIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIHNvIHRoZSBpbXBsZW1lbnRvciBnZXRzIGEgZ29vZCBzb2xpZCBoaW50 IHRoYXQgdGhleSBuZWVkIHRvIHdvcnJ5IGFib3V0IGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZXJlJ3MgYW4gaW50ZXJlc3RpbmcgZGlmZmVyZW5jZSBvZiBhcHByb2FjaCBoZXJlLiBJdCdzIHBs YXVzaWJsZSB0byBzYXkgdGhhdCBwcm90b2NvbCBkZXNpZ25lcnMgc2hvdWxkIHBpY2sgdGhlIHNl Y3VyZSBkZXNpZ24gb25seSB3aGVuIHRoZXkgcmVhbGl6ZSB0aGVpciBkZXNpZ24gaGFzIHNlY3Vy aXR5IGltcGxpY2F0aW9ucywgYnV0IEkgcHJlZmVyIHRvIHNheSB0aGF0IHRoZXkgc2hvdWxkIHBp Y2sgdGhlDQogc2VjdXJlIGRlc2lnbiB1bmxlc3MgdGhleSB0aGluayBhYm91dCBpdCBhbmQgcmVh bGl6ZSB0aGUgZGVzaWduIGRvZXNuJ3QgaGF2ZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMuIEkgdGhp bmsgdGhlIHNlY29uZCB3aWxsIGdldCB1cyBub3RpY2VhYmx5IG1vcmUgc2VjdXJpdHkgaW4gYSB3 b3JsZCB3aGVyZSBkZXNpZ25lcnMgZG9uJ3QgaGF2ZSB0aW1lIHRvIHRoaW5rIGFib3V0IGV2ZXJ5 IGFzcGVjdCBvZiBldmVyeSBwaWVjZSBvZiB0aGVpciBkZXNpZ24uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCBrbm93IGhvdyBtYW55IGdlbmVyaWMgZGVjb2Rl cnMgZXhpc3QgdGhhdCByZWFsbHkgY2Fu4oCZdCBkbyBvciBzdXBwb3J0IGR1cGxpY2F0ZSBkZXRl Y3Rpb24uIEkgYWxzbyBkb27igJl0IGtub3cgaG93IG1hbnkgdXNlIGNhc2VzIHRoZXJlIGFyZSB0 aGF0IGNhbuKAmXQgYWZmb3JkIGR1cGxpY2F0ZSBkZXRlY3Rpb24uIElmIHRoZXJlIGFyZSBmZXcg b2YgYm90aCwgdGhlbiBtYWtpbmcgbm8gZHVwbGljYXRlIGRldGVjdGlvbg0KIHRoZSBleGNlcHRp b24gdGhhdCBuZWVkcyB0byBiZSBjYWxsZWQgb3V0IHNlZW1zIHJpZ2h0LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgYmVlbiB0aGlu a2luZyBhYm91dCBDV1QgYW5kIEVBVCBhcyBleGFtcGxlcy4gTWF5YmUgRUFUIHNob3VsZCBzYXkg dGhhdCBkdXBsaWNhdGUgZGV0ZWN0aW9uIHNob3VsZCBiZSByZXF1aXJlZCB1bmxlc3MgYSBwcm9m aWxlIG9mIEVBVCBzYXlzIGl0IGlzIG5vdCwgdGhlIHNlY3VyZSBjaG9pY2UuIEZvciB0aGUgbW9z dCBwYXJ0IEVBVCB3aWxsIGJlIHByb2Nlc3NlZCBvbiBzZXJ2ZXJzIHdoZXJlIHRoZXJlDQogaXMg Y2xlYXJseSBubyByZXNvdXJjZSBpc3N1ZS4gVGhlIG9ubHkgaXNzdWUgd291bGQgYmUgdGhlIGlt cGxlbWVudGF0aW9uICZuYnNwO2Vudmlyb25tZW50IChKYXZhLCBQSFAsIFB5dGhvbuKApikuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVBVHMg bWlnaHQgYmUgZGVjb2RlZCBvbiBjb25zdHJhaW5lZCBkZXZpY2VzIHNvbWV0aW1lcywgYnV0IHRo YXQgaXMgcmFyZS4gSW4gdGhhdCBjYXNlIGEgcHJvZmlsZSBjYW4gcmVsYXggdGhlIHJlcXVpcmVt ZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5FQVRzIGFyZSBhbHdheXMgc2lnbmVkIHNvIGR1cGxpY2F0ZXMgd291bGQgb25seSBjb21lIGZy b20gYmFkIGltcGxlbWVudGF0aW9ucy4gVGhlcmUgYXJlIHBsZW50eSBvZiB3YXlzIHRoYXQgYW0g aW1wbGVtZW50YXRpb24gY2FuIGdvIHdyb25nIG90aGVyIHRoYW4gZHVwbGljYXRpbmcga2V5cyB0 aGF0IGFyZSBjb21wbGV0ZWx5IHVuZGV0ZWN0YWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIGxvdCBvZiB0ZXh0IGltcGx5aW5nIHRoYXQgZHVwbGlj YXRlcyBhcmUgYmFkLCBidXQgSSB0aGluayBpdCB3b3VsZCBiZSB3b3J0aCBiZWluZyBleHBsaWNp dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPllvdSBhcmUgYW4gaWRpb3QgaWYgeW91IGRlc2lnbiBhIHByb3RvY29s IHRoYXQgY29uc2lkZXJzIGR1cGxpY2F0ZSBpbnB1dCB2YWxpZCBvciBuZWNlc3NhcnkuIER1cGxp Y2F0ZSBtYXAga2V5cyBhcmUgYWx3YXlzIGFuIGVycm9yIGluIENCT1IgYW5kIHdpbGwgbm90IHdv cmsgd2l0aCBtYW55IGdlbmVyaWMgZGVjb2RlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkbid0IHNheSAmcXVvdDtpZGlvdCZxdW90OywganVzdCAm cXVvdDt3cm9uZyZxdW90Oy4gVGhlIHNwZWMgYWxyZWFkeSBzYXlzIHlvdSAmcXVvdDtNVVNUIE5P VCZxdW90OyBkbyB0aGlzLCBidXQgSSdtIG5vdCBvcHBvc2VkIHRvIG1ha2luZyB0aGF0IHN0YXRl bWVudCBtb3JlIGRpcmVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGFy ZG9uIG15IHdvcmRpbmcuIENlcnRhaW5seSwgSSBkbyBub3Qgd2FudCB0aGF0IGFzIG5vcm1hdGl2 ZSB0ZXh0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxicj4NCkplZmZyZXk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_DM6PR00MB0569D44CC35DD2AFEA56C621F54B0DM6PR00MB0569namp_-- From nobody Sun Nov 24 20:35: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 7DAD9120236 for ; Sun, 24 Nov 2019 20:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 x2dYrX7fyuEB for ; Sun, 24 Nov 2019 20:35:53 -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 7BBE9120233 for ; Sun, 24 Nov 2019 20:35:52 -0800 (PST) Received: from Jude (50.76.105.153) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 24 Nov 2019 20:35:47 -0800 From: Jim Schaad To: 'Jeffrey Yasskin' , 'Laurence Lundblade' CC: 'Jeffrey Yasskin' , References: In-Reply-To: Date: Sun, 24 Nov 2019 20:35:44 -0800 Message-ID: <052d01d5a349$ceaecd00$6c0c6700$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_052E_01D5A306.C08FABB0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGmCDypdlfUUa/DzG+fZ+sR9lBVUQLz1JhnAeN/E+4ChiYl2gHbbvNUp7C7SIA= Content-Language: en-us X-Originating-IP: [50.76.105.153] 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: Mon, 25 Nov 2019 04:35:55 -0000 ------=_NextPart_000_052E_01D5A306.C08FABB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: CBOR On Behalf Of Jeffrey Yasskin Sent: Sunday, November 24, 2019 2:49 AM To: Laurence Lundblade Cc: Jeffrey Yasskin ; Jeffrey = Yasskin ; cbor@ietf.org Subject: Re: [Cbor] Handling duplicate map keys =20 Comments inline: =20 On Sat, Nov 23, 2019 at 7:21 AM Laurence Lundblade = > wrote: On Nov 23, 2019, at 1:11 AM, Jeffrey Yasskin > wrote: =20 On Sat, Nov 23, 2019 at 10:00 AM Laurence Lundblade = > wrote: Here=E2=80=99s a rough proposed text: =20 The protocol designer should make a choice for maps as to whether = duplicates are allowed or not, particularly as to whether duplicates = would cause security or functionality problems. =20 The protocol designer should only require duplicate detection when = necessary as it can have the following implications: * Some generic decoders do not support duplicate detection because the = underlying facilities in their programming environment to represent maps = can=E2=80=99t detect duplicates * Some generic decoders do not support duplicate detection because it = requires more code and is not required * It requires more resources to implement: 1) memory to store all the = keys in the map, 2) more code, 3) more CPU time, as much as O(n^2).. = This is particularly an issue with big maps in constrained environments. It is suggested that protocol designers require duplicate detection only = no the particular maps for which there is an issue. =20 Decoders will typically fall into one of these categories: * Full duplicate detection * Pass all items up to caller, allowing the caller to implement = duplicate detection or not * No duplicate detection A generic decoder should identify which it is. Some may support more = than one, selectable by configuration. =20 I don't think generic decoders are relevant here. Protocol = implementations often accumulate their input into a data structure even = if they use a streaming decoder to read the input. Any such protocol can = detect duplicates (of the keys it uses at all) for at most the cost of = an extra bit per field. =20 My intention was that =E2=80=9Cpass all items up=E2=80=9D covers your = case.=20 =20 My QCBOR + t_cose implementations work exactly as you describe to = implement dup detection in COSE header parameters. It=E2=80=99s the data = structures that hold the COSE header params that are used to detect the = duplicates, not the generic decoder (QCBOR). This seems like a good way = to handle this problem for lots of use cases.=20 =20 Yep, that's the model I'm thinking of. I'm clearly struggling to put it = into understandable spec language.=20 I think you make a good point that if a protocol is going to specify = "take first", it can probably specify "error on duplicate key" for the = same cost. That might imply some much simpler text: =20 "Protocols based on CBOR SHOULD fail with an error if a map contains a = duplicate key, except that if the key isn't used at all, they MAY ignore = it instead. Protocols that do not reject duplicate keys MUST (?) = document why the cost of rejecting duplicates is too high and why = accepting them will not lead to security vulnerabilities. An array might = be a better choice for such protocols.=E2=80=9D =20 I think I=E2=80=99d invert it and say that protocols that require = duplicate detection for security reasons should describe that = requirement in security considerations so the implementor gets a good = solid hint that they need to worry about it. =20 There's an interesting difference of approach here. It's plausible to = say that protocol designers should pick the secure design only when they = realize their design has security implications, but I prefer to say that = they should pick the secure design unless they think about it and = realize the design doesn't have security implications. I think the = second will get us noticeably more security in a world where designers = don't have time to think about every aspect of every piece of their = design. =20 [JLS] It also gets fun in some other ways. It might not matter for the = protocol I am designing, because I always reflect back the input that I = use to the client application. That means it does not matter what the = duplicate behavior is right up to the point in time where I decide that = I am going to apply COSE to it. I now have multiple potential behaviors = that are required for the application =20 Jim =20 =20 There is lot of text implying that duplicates are bad, but I think it = would be worth being explicit. =20 You are an idiot if you design a protocol that considers duplicate input = valid or necessary. Duplicate map keys are always an error in CBOR and = will not work with many generic decoders. =20 I wouldn't say "idiot", just "wrong". The spec already says you "MUST = NOT" do this, but I'm not opposed to making that statement more direct. =20 Thanks, Jeffrey ------=_NextPart_000_052E_01D5A306.C08FABB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: = CBOR <cbor-bounces@ietf.org> On Behalf Of Jeffrey = Yasskin
Sent: Sunday, November 24, 2019 2:49 AM
To: = Laurence Lundblade <lgl@island-resort.com>
Cc: Jeffrey = Yasskin <jyasskin=3D40google.com@dmarc.ietf.org>; Jeffrey Yasskin = <jyasskin@chromium.org>; cbor@ietf.org
Subject: Re: = [Cbor] Handling duplicate map keys

 

Comments inline:

 

On Sat, Nov 23, 2019 at 7:21 AM Laurence Lundblade = <lgl@island-resort.com> = wrote:

On Nov 23, 2019, at 1:11 AM, Jeffrey Yasskin <jyasskin@chromium.org> = wrote:

 

On Sat, Nov 23, 2019 at 10:00 AM Laurence Lundblade = <lgl@island-resort.com> = wrote:

Here=E2=80=99s a rough proposed = text:

 

The protocol designer should make a choice for maps as = to whether duplicates are allowed or not, particularly as to whether = duplicates would cause security or functionality = problems.

 

The protocol designer should only require duplicate = detection when necessary as it can have the following = implications:

  • Some generic decoders do not support duplicate detection = because the underlying facilities in their programming environment to = represent maps can=E2=80=99t detect duplicates
  • Some generic decoders do not support duplicate detection = because it requires more code and is not = required
  • It requires more resources to implement: 1) memory to store = all the keys in the map, 2) more code, 3) more CPU time, as much as = O(n^2).. This is particularly an issue with big maps in constrained = environments.

It is = suggested that protocol designers require duplicate detection only no = the particular maps for which there is an = issue.

 

Decoders will typically fall into one of these = categories:

  • Full duplicate detection
  • Pass all items up to caller, allowing the caller to = implement duplicate detection or not
  • No duplicate detection

A generic decoder should identify which it is. Some = may support more than one, selectable by = configuration.

<= p class=3DMsoNormal> 

I don't think generic decoders are relevant here. = Protocol implementations often accumulate their input into a data = structure even if they use a streaming decoder to read the input. Any = such protocol can detect duplicates (of the keys it uses at all) for at = most the cost of an extra bit per = field.

 

My intention was that =E2=80=9Cpass all items = up=E2=80=9D covers your case. 

 

My QCBOR + t_cose implementations work exactly as you = describe to implement dup detection in COSE header parameters. = It=E2=80=99s the data structures that hold the COSE header params that = are used to detect the duplicates, not the generic decoder = (QCBOR).  This seems like a good way to handle this problem for = lots of use = cases. 

 

Yep, that's the model I'm thinking of. I'm clearly = struggling to put it into understandable spec = language. 

I think you make a good point that if a protocol is = going to specify "take first", it can probably specify = "error on duplicate key" for the same cost. That might imply = some much simpler text:

 

"Protocols based on CBOR SHOULD fail with an = error if a map contains a duplicate key, except that if the key isn't = used at all, they MAY ignore it instead. Protocols that do not reject = duplicate keys MUST (?) document why the cost of rejecting duplicates is = too high and why accepting them will not lead to security = vulnerabilities. An array might be a better choice for such = protocols.=E2=80=9D

<= /blockquote>

 

I think I=E2=80=99d invert it and say that protocols = that require duplicate detection for security reasons should describe = that requirement in security considerations so the implementor gets a = good solid hint that they need to worry about = it.

 

There's an interesting difference of approach here. = It's plausible to say that protocol designers should pick the secure = design only when they realize their design has security implications, = but I prefer to say that they should pick the secure design unless they = think about it and realize the design doesn't have security = implications. I think the second will get us noticeably more security in = a world where designers don't have time to think about every aspect of = every piece of their design.

 

[JLS]=C2=A0 = It also gets fun in some other ways.=C2=A0 It might not matter for the = protocol I am designing, because I always reflect back the input that I = use to the client application.=C2=A0 That means it does not matter what = the duplicate behavior is right up to the point in time where I decide = that I am going to apply COSE to it.=C2=A0 I now have multiple potential = behaviors that are required for the application

 

Jim

 

 

There is lot of text implying that duplicates are bad, = but I think it would be worth being = explicit.

 

You are an idiot if you design a protocol that = considers duplicate input valid or necessary. Duplicate map keys are = always an error in CBOR and will not work with many generic = decoders.

=

 

I wouldn't say "idiot", just = "wrong". The spec already says you "MUST NOT" do = this, but I'm not opposed to making that statement more = direct.

 

Thanks,
Jeffrey

------=_NextPart_000_052E_01D5A306.C08FABB0-- From nobody Mon Nov 25 15:57:27 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 74E2B120CDB for ; Mon, 25 Nov 2019 15:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.484 X-Spam-Level: ** X-Spam-Status: No, score=2.484 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_SBL_CSS=3.335, 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 tNKl2NbT3ZAa for ; Mon, 25 Nov 2019 15:57:24 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602C6120FC8 for ; Mon, 25 Nov 2019 15:57:24 -0800 (PST) Received: from dooku.sandelman.ca (unknown [194.42.227.53]) by relay.sandelman.ca (Postfix) with ESMTPS id CB60B1F480 for ; Mon, 25 Nov 2019 23:57:21 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 055311376; Mon, 25 Nov 2019 16:02:30 +0800 (+08) From: Michael Richardson To: cbor@ietf.org In-reply-to: References: Comments: In-reply-to Laurence Lundblade message dated "Sat, 23 Nov 2019 07:21:49 -0800." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 25 Nov 2019 09:02:30 +0100 Message-ID: <32467.1574668950@dooku.sandelman.ca> 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: Mon, 25 Nov 2019 23:57:25 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Laurence Lundblade wrote: > My intention was that =E2=80=9Cpass all items up=E2=80=9D covers your= case. python, ruby, lua, java, etc. dictionaries can not "pass all items up" The reason why JSON is so successful is because it maps into native dictionaries (maps) trivially. In order to pass things up, a different structure will be necessary, at which point many developers and protocol designers will see no value in CBOR over a bespoke binary encoding. It is this refusal to define a specific algorithm for dealing with duplicat= es that is leading to security issues. It's not the duplicates themselves that is the problem, it is the ambiguity. I am less afraid to declare an answer and make some decoders non-compliant. I think that they will get fixed. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl3bipUACgkQlUzhVv38 QpB/rAf/aC0rpBLoFcf35HFj5LfCgb+LPyTSToQr462pMN1jOh0mwzda6r5CLUed P0UdaP6h8YoCx1lpjFBGaGKfnV0QmQMhqY6nSrfAjPIsPFvmrIP2ZxPCKS1SfWbH xvol72oMKqHjfaGcLPDb/L1izulVtuI0kJZGItm5A3+r57SgvT57zv14IuG3eaJl 5TNcT+gc0n6DrbvMVVbtvpyeP7gXV+QPndeaxMRrIZFnbXpT3uJoLgLmYfvfxCVu NiPVBHXzmgc/Y8JhgU4nCuP3MJy5YEbWamWQ6qZyWaUePDy724MhWDO6ru7h8L6a fc4NZ3Ow1TMB+8MIoy/9Ar6TgjR4Wg== =z6T0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 25 17:36:33 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 C594C120F9C for ; Mon, 25 Nov 2019 17:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_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 Hnj9oh2ljafY for ; Mon, 25 Nov 2019 17:36:30 -0800 (PST) Received: from p3plsmtpa06-03.prod.phx3.secureserver.net (p3plsmtpa06-03.prod.phx3.secureserver.net [173.201.192.104]) (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 5FE7B12006F for ; Mon, 25 Nov 2019 17:36:30 -0800 (PST) Received: from [192.168.1.80] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id ZPmHi6i921oMRZPmHiPTdT; Mon, 25 Nov 2019 18:36:29 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Laurence Lundblade In-Reply-To: <32467.1574668950@dooku.sandelman.ca> Date: Mon, 25 Nov 2019 17:36:28 -0800 Cc: cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0A1548F5-98A0-46AB-8CDA-991F83AB2DD8@island-resort.com> References: <32467.1574668950@dooku.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfBmJVtEnv7IenvwWO/1TwHE4cjZj1St0uZ1K9eyyZCkvJQJoU/vSiGgC9wTenlubyEY2djayg4rqqUQwcd6HODWhyNw6wEnYePmzygLxK23CqeqdZqhv lfFIjTg5TkYULjG9IimQ6RS9w443+i7LirB93CNDh8zOT58BTE0UGtVWOMG4uUQSfvmurRj9IQdh0DWUoN1ghQYZUMpwUcVcVfM= 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: Tue, 26 Nov 2019 01:36:32 -0000 Hi Michael > On Nov 25, 2019, at 12:02 AM, Michael Richardson = wrote: >=20 >=20 > Laurence Lundblade wrote: >> My intention was that =E2=80=9Cpass all items up=E2=80=9D covers your = case. >=20 > python, ruby, lua, java, etc. dictionaries can not "pass all items up" > The reason why JSON is so successful is because it maps into native > dictionaries (maps) trivially. Yes, they fall into one of the other two categories: - They do duplicate checking and return an error - They return no error and are either take first, take last or take = random >=20 > In order to pass things up, a different structure will be necessary, > at which point many developers and protocol designers will see no = value in > CBOR over a bespoke binary encoding. >=20 > It is this refusal to define a specific algorithm for dealing with = duplicates > that is leading to security issues. It's not the duplicates = themselves that > is the problem, it is the ambiguity. >=20 > 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 From nobody Tue Nov 26 06:37:24 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 20763120882; Tue, 26 Nov 2019 06:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 AAWZJcx7sRjL; Tue, 26 Nov 2019 06:37:20 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70041.outbound.protection.outlook.com [40.107.7.41]) (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 D1D6C12081E; Tue, 26 Nov 2019 06:37:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VLIKxHVAneEDZU6Z//+tcWUb0tMTsphIlrOwr1dcdLwhwGrmpIxfQZlDrfBJyn9hDVnBGkvY421tqITcxhlcUgJqy/qCoucHuu6NtGaJevfjO3tgHGpRocf9wEtJZYlWodQMXR4Pq/tzEFFZDbkUibaYv69/1p4NLwLgM7GPdmmVTLCBKjv02LCm1FBAqJzNetE7DprHOT1NzRZEygUADKYSWnZVehce42ajXYQpAXDbt+zEA3h7ObbgOxFNPWVVtIpJypKk7E88jnJsGMakquCIA+rJjD7Mroz5tVj1txWoEKHOX46N2qKsDbTp8bL/Bwgiwl4gvGiLAkejIuWQOA== 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=/hNs47hiYpc5TMRJ1fjfOWoA/zM7s2oinAUA04rDuwo=; b=NoT200+RXmSp78nv8zNMOvTiY+Z6+rKDCu9Y304lCo2gumFudgyOZ0WjwGmbA2xqm3uuetc5/wKMugpeTbKeRnZNDE+CFnsSH3MhbvbMLzTTeviwweUKzb99/Ew1w1S9HqHfr0nYpfIlF46GuG2b/BYFb0JuJMRB6vkrM7e6WvI8k1nDytyYup905YQHOuvumgG+StlLl/whfQDxMDLkg+W4an+x1XHLi8X5N/i4meh53Zp/fFvNl2SPQHoCxFabqC/aHkqvBYsIc/pfvefbDovYRWzyj4GxRJ2jqtPzR2XcI2KXWuGjdhndtZoaCwfV4YoZC2tOc7VAIY5AaAlF5Q== 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=/hNs47hiYpc5TMRJ1fjfOWoA/zM7s2oinAUA04rDuwo=; b=UuhLUz1Zbwwqmby4AJ69LWvGq1ZLtsIQ5qv4GNt152Z/zgC5UHczUY2qGIUols2D/TjpuDEDPUxQKtAcKQWdD+PmR94zU2auIhTQrZuubhTTozOJURTds3uDI0GDtEC8FpJ2rW06q1pehV2fx6gQ0ZVjdP7oKTeNadA2QL7lic8= Received: from AM0PR07MB5460.eurprd07.prod.outlook.com (20.178.22.87) by AM0PR07MB5828.eurprd07.prod.outlook.com (20.178.114.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.10; Tue, 26 Nov 2019 14:37:17 +0000 Received: from AM0PR07MB5460.eurprd07.prod.outlook.com ([fe80::95b8:d2ab:36fc:a1cc]) by AM0PR07MB5460.eurprd07.prod.outlook.com ([fe80::95b8:d2ab:36fc:a1cc%6]) with mapi id 15.20.2495.014; Tue, 26 Nov 2019 14:37:17 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: IETF 106 minutes Thread-Index: AQHVpGcAEtuJJ7VknEGtSjlKtfoGdQ== Date: Tue, 26 Nov 2019 14:37:17 +0000 Message-ID: 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: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5d83b79f-47a4-4fcd-e001-08d7727e2306 x-ms-traffictypediagnostic: AM0PR07MB5828: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(366004)(136003)(396003)(199004)(189003)(186003)(26005)(9326002)(2616005)(44832011)(8936002)(2906002)(7736002)(6506007)(102836004)(6436002)(6486002)(4326008)(5640700003)(6306002)(54896002)(6512007)(86362001)(450100002)(236005)(25786009)(71200400001)(1730700003)(2351001)(66476007)(5660300002)(4744005)(2501003)(66946007)(66446008)(478600001)(966005)(76116006)(91956017)(7116003)(14454004)(66556008)(64756008)(33656002)(3846002)(99286004)(6116002)(8676002)(81166006)(81156014)(316002)(66066001)(36756003)(606006)(71190400001)(256004)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5828; H:AM0PR07MB5460.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: H4UEVw6/CP1tDpXbbu2InNR96n2RbarwEHe6k/Jv9zKjRaIyMQJIZvMBzSHKKkxtn1bF5nRNv8+5jZq4Fy4xMyeIF6Pk/iMhmx9sevfJASRqAFhUUzp2tVruqMAO95W96Xv0t9rSiWtyI+DRkyzBfdTOklSTM1pOZd10Pbp6ExQXADmj6CeGAaIbrE4LE+Gkp3QR/GkYpjYw140s7TX0rwztCTzYqA2YcLoAEQ2u6wmjZFL7Y9iTlPvJEpZNzDChJG7OYKqHLODouulhZRqqh6NovOz4pHlSL0ukj++WSvvShbRpp2RCi26a3KXzrm4PY3esr4NwtQe+fPAjlJl2fctf82aK8qUc0CPUm0ru4J0biuRQdlCLQ2DB6RtmhHrpOlgX49onGpd5BckT1foD7McZRsWSEmBNjjazN+FFnk7zJpiqr2YuRi10diSnbHq82TEOQoG0C1HGsrfg5K2aimvw8sBFebTqAv/mgSpSPQE= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_C3908D189BBE4E2AA578A9678FE4B372ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5d83b79f-47a4-4fcd-e001-08d7727e2306 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2019 14:37:17.4823 (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: gzxEUKvigXbyEGCtJvtxAPArgN877cKZaTTu6gDPWdz2bmeDTRee56PjdXX60kugEuBY9YPT8rjFEWks+UAZVNUfPFYFoVOBzfGM4JAfirhsm8XnY6luG7MqY2+kAZVr X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5828 Archived-At: Subject: [Cbor] IETF 106 minutes 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, 26 Nov 2019 14:37:22 -0000 --_000_C3908D189BBE4E2AA578A9678FE4B372ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkhlcmUgYXJlIHRoZSBtaW51dGVzIGZyb20gSUVURiAxMDYuIFRoYW5rIHlvdSBNaWNo YWVsIGZvciBjYXB0dXJpbmcgdGhlIGRpc2N1c3Npb24hDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbWVldGluZy8xMDYvbWF0ZXJpYWxzL21pbnV0ZXMtMTA2LWNib3ItMDANCg0KVGhl IG1pbnV0ZXMgY29udGFpbiBhIGxpbmsgdG8gdGhlIHlvdXR1YmUgcmVjb3JkaW5nOg0KDQpodHRw czovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92PTNsSlo0ZFp1YVBBDQoNClBsZWFzZSBsZXQgdGhl IGNoYWlycyBrbm93IGlmIHlvdXIgY29tbWVudCB3YXMgbm90IGNhcHR1cmVkIGNvcnJlY3RseSBh bmQgbmVlZHMgdG8gYmUgYW1lbmRlZC4NCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQo= --_000_C3908D189BBE4E2AA578A9678FE4B372ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <9153DB4144A36643B34F1D62B28F5466@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhlcmUgYXJlIHRoZSBtaW51dGVzIGZyb20g SUVURiAxMDYuIFRoYW5rIHlvdSBNaWNoYWVsIGZvciBjYXB0dXJpbmcgdGhlIGRpc2N1c3Npb24h PGJyPg0KPGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv bWVldGluZy8xMDYvbWF0ZXJpYWxzL21pbnV0ZXMtMTA2LWNib3ItMDAiPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDYvbWF0ZXJpYWxzL21pbnV0ZXMtMTA2LWNib3ItMDA8 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBtaW51dGVzIGNvbnRh aW4gYSBsaW5rIHRvIHRoZSB5b3V0dWJlIHJlY29yZGluZzoNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVm PSJodHRwczovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92PTNsSlo0ZFp1YVBBIj5odHRwczovL3d3 dy55b3V0dWJlLmNvbS93YXRjaD92PTNsSlo0ZFp1YVBBPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5QbGVhc2UgbGV0IHRoZSBjaGFpcnMga25vdyBpZiB5b3VyIGNvbW1l bnQgd2FzIG5vdCBjYXB0dXJlZCBjb3JyZWN0bHkgYW5kIG5lZWRzIHRvIGJlIGFtZW5kZWQuPGJy Pg0KPGJyPg0KVGhhbmtzLDxicj4NCkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C3908D189BBE4E2AA578A9678FE4B372ericssoncom_-- From nobody Thu Nov 28 08:36:08 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 B3261120859 for ; Thu, 28 Nov 2019 08:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.284 X-Spam-Level: X-Spam-Status: No, score=-0.284 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 XmmpRzRtvXPR for ; Thu, 28 Nov 2019 08:36:05 -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 2E4A412089E for ; Thu, 28 Nov 2019 08:36:04 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-08v.sys.comcast.net with ESMTP id aMk5iVgOJ7jwaaMlwiNCfV; Thu, 28 Nov 2019 16:36:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1574958964; bh=5yYQK9QG/WonaU/1HjtB1FQ0hsj5fKcVQfQntRFOY5M=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=HxzBJesavJZoXjLv+aPMz2afUt8hO6wf+TpfKJbI4/0M3oogLMKpc0kxzkC6GYDDx kDsJK+f7nVrYnvdYKhmBUQTrP8zIxoZ4AayqfZ3QvCBEhFg06qg7KNM37DskmLpKvU U+M3ct0Qj6F3KKuqzQBwsDV9N8y+2UDiNnxj9fOEXqSj0yQoCl3A94tR4VSmRMaUFZ 8Tfi351Poura58LfUFVmr7RZHjkRj8twN8EmgRN2s7ksS+GTCIzP3BTiyWq3RR7jdi fFH+PT2QrpvpB219H7lQENQNQz9HQz0nXgr8MYDJ27Ip+1rGP5sDlmoKKWXfr9YukR Tj6d+HP/vA1BA== Received: from hobgoblin.ariadne.com ([173.23.6.42]) by resomta-ch2-05v.sys.comcast.net with ESMTPA id aMloiulinkg1MaMlpi7GIE; Thu, 28 Nov 2019 16:36:02 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedufedrudeijedgkeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffushestddttddttddttdenucfhrhhomhepfihorhhlvgihsegrrhhirggunhgvrdgtohhmucdlffgrlhgvucftrdcuhghorhhlvgihmdenucfkphepudejfedrvdefrdeirdegvdenucfrrghrrghmpehhvghlohephhhosghgohgslhhinhdrrghrihgrughnvgdrtghomhdpihhnvghtpedujeefrddvfedriedrgedvpdhmrghilhhfrhhomhepfihorhhlvgihsegrlhhumhdrmhhithdrvgguuhdprhgtphhtthhopegtsghorhesihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd 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 xASGZubp027384 for ; Thu, 28 Nov 2019 11:35:56 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id xASGZuIh027381; Thu, 28 Nov 2019 11:35:56 -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: cbor@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 28 Nov 2019 11:35:55 -0500 Message-ID: <87k17k3qms.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [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: Thu, 28 Nov 2019 16:36:07 -0000 This is a small thing, and perhaps its been settled, but I couldn't find anything in the archives about it: The media type registration for application/cbor in RFC 7049 says that there's no magic number for CBOR. But section 2.4.5 defines a CBOR tag that whose purpose is to implement a magic number, 0xd9_d9_f7. And this is carried forward into 7049bis-09. It seems to me that the registration should be corrected. Dale From nobody Thu Nov 28 08:56:42 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 D96DE120885 for ; Thu, 28 Nov 2019 08:56:40 -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 rUu6LLSE1KFH for ; Thu, 28 Nov 2019 08:56:39 -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 C8B3412085C for ; Thu, 28 Nov 2019 08:56:38 -0800 (PST) Received: from client-0012.vpn.uni-bremen.de (client-0012.vpn.uni-bremen.de [134.102.107.12]) (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 47P3h50B2Fzym8; Thu, 28 Nov 2019 17:56:36 +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: <87k17k3qms.fsf@hobgoblin.ariadne.com> Date: Thu, 28 Nov 2019 17:56:37 +0100 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 596652932.0968421-6d1d80a021a6473b90c9ad17cdb41263 Content-Transfer-Encoding: quoted-printable Message-Id: <953945BD-E435-4DDA-BC0A-EE7A8C4C36C6@tzi.org> References: <87k17k3qms.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3445.9.1) 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: Thu, 28 Nov 2019 16:56:41 -0000 Hi Dale, On Nov 28, 2019, at 17:35, Dale R. Worley wrote: >=20 > This is a small thing, and perhaps its been settled, but I couldn't = find > anything in the archives about it: The media type registration for > application/cbor in RFC 7049 says that there's no magic number for = CBOR. > But section 2.4.5 defines a CBOR tag that whose purpose is to = implement > a magic number, 0xd9_d9_f7. And this is carried forward into > 7049bis-09. It seems to me that the registration should be corrected. Good point. However, not all CBOR carries this magic number. With the tag, you can have that magic number if you like. (Actually, you can register your own tag to have your own magic number, = too; see for example the =E2=80=9CRAINS=E2=80=9D tag 15309736 which = happens to pop up a =E9=9B=A8 [rain] character at the start of the data = item.) I don=E2=80=99t know if there is a way to say that =E2=80=9Cthere is an = optional magic number defined that can be used by applications that want = to use it=E2=80=9D in a media type registration. So far, not a lot of applications have picked up using the 55799 magic = number. Gr=C3=BC=C3=9Fe, Carsten